プロンプトガチャはもう古い――「ハーネスの父」が明かす、AI駆動開発の極意：1年以上「コードエディタを一度も開いてない」

Googleは、AIエージェントによる開発をテーマにした解説動画「The Agent Factory」を要約した記事を公開した。Googleのエンジニアがエージェントハーネスの重要性を語っている。

[＠IT]

　Googleは2026年9月25日（米国時間）、AIエージェントによる開発をテーマにした解説動画「The Agent Factory」を要約したブログ記事を公開した。ゲストは、Google Cloudのソフトウェアエンジニアで、「エージェントハーネス」という用語を生み出したライアン・ロポポロ氏だ。

エージェントハーネスとは何か

　動画では、AIエージェントを「大規模言語モデル（LLM）とエージェントハーネスの組み合わせ」と定義している。ハーネスは、LLMを取り巻くもののうち、モデル自体を除く全てを指す。例えば「Google Antigravity」で「Gemini 3.8 Flash」を使って作業する場合、Gemini 3.8 FlashがLLMで、Google Antigravityがハーネスに当たる。

　「空はなぜ青いのか」という質問にはLLM単体でも答えられるが、「今日はレインコートを着るべきかどうか」という質問には必要なデータがないと答えられない。ハーネスは質問の意図をくみ取ってリアルタイムの気象ツールに問い合わせ、その結果を「コンテキスト」としてプロンプトに組み込んでモデルに渡し、根拠のある回答を生成させる。

　エージェントハーネスという用語は、自律型コーディングエージェントに関するロポポロ氏の取り組みから生まれた。ロポポロ氏は2025年5月以降、コードエディタを一度も開いておらず、Google Cloudに移ってからも自律型コーディングを続けている。個々のコード行を書いたり、レビューしたりせず、自然言語を使って作業し、プルリクエスト（PR）やドキュメント、スプレッドシートといった最終的な成果物が組織の基準を満たしているかどうかを判断している。

　ロポポロ氏は、「ハーネスエンジニアリングは、モデルが成功できる環境にモデルを置くための研究であり、実践だ。これを怠ると、私が『プロンプトを書いて祈る』と呼ぶ状態に陥る」と述べている。ハーネスに先行投資しておけば、エンジニアは長いプロンプトを書かずに済む。リポジトリに構造化されたドキュメントや明確なインタフェース、見つけやすいツールがそろっていれば、モデルはハーネスを使って関連するコンテキストを自ら取得し、大規模なコードベースでも人の監督なしに複雑なタスクを実行できるという。

　エージェントが失敗したとき、プロンプトを調整したり、再試行したりするだけでは、チーム全体に適用できる改善策にはならない。

　ロポポロ氏が勧めるのは「シフトレフト」で、介入を開発ライフサイクルのより早い段階、より低コストで対応を自動化できる段階に移すことだ。プロンプトからリポジトリのドキュメント、リンター、テスト、さらに上流の評価に移していく。

　次のターンでモデルが正しく推測することを期待するのではなく、基準を環境そのものに組み込む考え方で、リンターやテスト、「AGENTS.md」ファイルが、何を「良し」とするかを示す永続的な記憶となり、それを強制する役割も果たす。常に手取り足取り指示しなくても、エージェントが軌道を外れずに済むという。

　ロポポロ氏によると、事前学習データに数多く含まれるパターンに沿ったツールを渡すと、エージェントは力を発揮するという。標準的なコマンドラインインタフェースと組み合わせれば、推論を決定論的な処理に移し、コンテキストを集める負担をモデルから信頼できるツールに移せる。

独自のハーネスを作るより、ツールとコンテキストに投資

　ハーネスエンジニアリングの中心的な課題は、エージェントが長期間にわたって一貫した作業を続けられるようにすることだ。

　まずエージェントの作業範囲を絞り、人が確認しやすい変更範囲の小さいプルリクエストを作らせる。それを繰り返して「長期間安定して進められる」と分かれば、コードベース全体のプログラミング言語の移行のような大きな仕事まで自律的に任せられるようになる。

　RPG（ロールプレイングゲーム）のキャラクターに能力値を足すように、例えば新しくチームに加わった「React」アーキテクトが注意を払うことで、エージェントのフロントエンドの設計やパフォーマンスに関する能力値が上がる。各分野の知識が環境に組み込まれれば、エージェントは依頼に応じて必要なスキルを選び、バックエンドやフロントエンドの専門家として幅広い作業を進められるようになる。

　ロポポロ氏はまた、独自のエージェントハーネスを過度に作り込むと、フロンティアモデルが進化したときに技術的負債になり得ると指摘する。

　標準的なハーネスは、ファイルの読み込み、「grep」による検索、コマンドの実行といったプリミティブ（基本構成要素）を既に備えている。ツールとコンテキストの品質向上に力を注げば、新しいモデルを自由に採用でき、陳腐化しない部分に投資の効果を積み上げ続けられる。

　AIモデルの能力を過去の経験で決めつけず、できることを継続的に見直すべきだとロポポロ氏は述べる。半年前に失敗した作業も、現在のモデルならこなせる可能性がある。その変化に対応するには、特定のモデルに合わせた固定的な手順よりも、使えるツールと参照できるコンテキストを整えることが重要だとしている。

カスタムハーネスの作り方

　Googleのビリー・ジェイコブソン氏（シニアデベロッパーアドボケイト）は、特定のタスクに合わせてエージェントハーネスをカスタマイズする方法を紹介した。エージェントがうまく動かないときに原因を調べるには、自分でハーネスを作ってみるのが最善だと同氏は述べる。

　どのワークフローでも、ハーネスを設計する上で重要な判断は3つある。

• ループ：エージェントに何回反復させ、どの条件で終了させるか
• ツール：エージェントにどのツールを使わせ、いつ、どのように呼び出させるか
• メモリ：会話や作業のメモリがどれだけ重要で、いつ取り出したり、圧縮したりするか

　ジェイコブソン氏は、3つのカスタムハーネスを実演してみせた。

線形エージェントハーネス

　線形エージェントハーネスは、反復が不要なワークフロー向けのハーネスだ。対象を絞った検査、ファイルの変換、1回のやりとりで終わるデータ分析など、毎回同じ手順で実行させたい場合に適した方式だ。

クローズドループ型エージェントハーネス

　バグ修正やリファクタリングが必要なタスクでは、クローズドループ型のハーネスが、検証済みの解決策に至るまでの反復を支える。

　デモでは、エージェントが満たされていない要件に対応するためにコードを自動編集し、ハーネスが変更後のコードに対して単体テストを実行した。テストが失敗すると、実行環境は失敗ログと詳細なスタックトレースを取得し、その情報をエージェントの作業メモリに戻す。全てのテストが通るまでこの手順を繰り返す。ただし、無限ループや実行費用の増大を防ぐために反復回数は最大5回に制限されている。

安全対策付きハーネス

　独自の動作を加えたいが、実行を制御する基本部分を一から作り直したくない場合もある。

　例えば、Googleの「Agent Development Kit」（ADK）は、記憶の自動管理と実行時の安全対策を備えた土台を提供する。ジェイコブソン氏は、ADKのコンテキスト圧縮機能で過去の会話を要約し、長時間のデバッグでコンテキストが膨らみ過ぎるのを防ぐ例を示した。

　独自のフックでシェル操作を実行前に調べ、ファイルの再帰的な削除、データベースの削除、許可されていないリモートへの「git push」といった危険な操作を止める方法も紹介した。

　この構成なら、チームはツールを実行できる範囲を細かく制御しつつ、独自のハーネス全体を保守する負担を抑えられるという。

モデル、ハーネス、ナレッジのバランスが性能を左右

　Googleのスミタ・コラン氏（シニアデベロッパーリレーションズエンジニア）は、コーディングエージェントに必ずしも重い推論モデルは必要なく、高い性能はモデル、ハーネス、ナレッジという3つのレイヤーのバランスから生まれると説明する。

　コラン氏は、例としてレイヤー1（モデル）としてGemini 3.8 Flashを、レイヤー2（ハーネス）としてGoogle Antigravityを取り上げ、レイヤー3（ナレッジ）には、「Google Skills」リポジトリを紹介した。Google Skillsは、Google Cloudをはじめとする100以上の分野別パッケージを収録したエージェントスキルのリポジトリだ。

　特定のハーネスに依存せず、必要なときに対象分野の正確なコンテキストを注入することで、エージェントがクラウドの設定を“当て推量”で決めるのを防ぐ。

　Googleは、効果的なコーディングエージェントを作るには、「単に大規模なモデルに置き換える」という反射的な対応から脱却し、ツールや決定論的な検証の仕組み、モデルを更新しても価値を失わない整理されたコンテキストに投資すべきだと結論付けている。