Google、自己修正するAIコーディングエージェント公開

Google Developers Blogは9月2日、harness(ハーネス)エンジニアリングをテーマにした記事を公開した。筆者はShir Meir Lador氏。記事が示すharnessの定義は率直だ——LLMを包み込むすべての決定的なコンポーネント、つまりオーケストレーション層、実行サンドボックス、状態の永続化、検証ツールなどがすべて含まれるという。

冒頭で引用されるのは、ある数字の対比だ。OpenAIのある実験的プロダクトでは、手書きのコードがゼロ行で、エンジニア3人がモデル生成のコードだけで社内テスト版を作り上げ、リリースしたという。筆者がここから導き出す論点は、モデルの能力そのものではなく、モデルを制御可能なプロセスに閉じ込める構造の方にある。

手綱、目隠し、そしてトラック

記事は競馬の比喩を使う。モデルは馬、harnessはトラックと目隠しと手綱であり、それを一つの方向に走らせる役割を担う。

"The harness is composed of all the deterministic components that wrap the LLM."

harnessとは、LLMを包み込むすべての決定的なコンポーネントで構成される。

この定義は、これまで「プロンプトエンジニアリング」という名目でひとくくりにされてきた仕事の位置づけを変える。モデルの振る舞いを制約する方法は、突き詰めれば2つしかない。プロンプトに書き込むか、外側のコードに書き込むかだ。前者はモデルが自発的に従うことに頼るため、モデルが変わるたびに調整し直しが必要になる。後者はハードな制約であり、モデルが世代交代しても効き続ける。この1年でエージェント型プロダクトを作ってきたチームの多くは両方を試し、両方のコストを払ってきた。プロンプトに書いた「テストファイルを変更するな」という一文も、モデルは長いコンテキストの中で30ターン目あたりから、その指示を選択的に見なくなっていく。

3つの設計原則

厳格な境界。エージェントをサンドボックスに閉じ込め、本番データに触れる機会を与えない。記事のデモでは、エージェントは./sandboxディレクトリの中でしかファイルを書けず、境界を越える操作はそもそも実行されない。

修復ループ。エラーはそのまま人間に投げるべきではない。テストが失敗したら、harnessはきれいなログをモデルに差し戻し、モデル自身に直させる。ADK 2.0がここで用意しているのはグラフベースのワークフローだ——検証ステップ自体がグラフ内の1つのルーティングノードであり、実行が失敗すると制御フローが自動的に生成ノードへ戻る。オーケストレーションのコードにリトライロジックを手書きする必要はない。

段階的に発見できるリポジトリ構造。数千行の説明ファイルを一度にエージェントへ渡すのではなく、リポジトリをエージェントが一層ずつ潜っていける構造にし、必要に応じてコンテキストを発見させる。

併走するAntigravity SDKが担うのはローカル環境側だ——ワークスペースの境界を定め、同時にメモリの永続化を提供する。この2つのツールを組み合わせると、「エージェントがどこで動くか」と「間違えたときにどう戻すか」という2つの問題をカバーすることになる。

上限5回とそのスイッチ

デモの自己修復ループは一巡を通しで動かしている。エージェントが制限されたサンドボックス内でコードを書き、テストが自動実行され、テストが失敗し、ログが差し戻され、エージェントが修正し、再度実行する。上限は5回に設定されており、上限に達するとharnessがループを打ち切る。筆者はこれをkill switch(キルスイッチ)と呼ぶ。

この「5」は記事全体で最も実用的な数字だ。自己修復ループの典型的な失敗パターンは、モデルが2つのエラー状態の間を行ったり来たりし、トークンを消費し続けながら収束しないというものだ。ハードな上限を設けることは、モデルにも直せない場合があるとあらかじめ認め、問題を早めに人間の手に戻すことを意味する。このスイッチがなければ、暴走したループは誰も見ていない夜のうちに予算を使い果たしかねない。

これを今年上半期に流行したエージェントフレームワークと比べると、重心の移動がはっきり見えてくる。初期のフレームワークが語っていたのは主にオーケストレーションだった——複数のエージェントをどうつなぐか、役割をどう分けるか、メッセージをどう渡すか。今語られているのは検証と境界だ——実行をどこに置くか、エラーをどう還流させるか、いつ止めるか。前者が解決するのは「動かせるかどうか」で、後者が解決するのは「実プロジェクトで安心して走らせられるかどうか」だ。

中国拠点のチームにとって、ADK 2.0やAntigravity SDKという個別のツールはそのまま使えるとは限らないが、3つの原則はそのまま持ち帰れる。サンドボックス、修復ループ、段階的なコンテキストは、自前で作るどんなコーディングエージェントも避けて通れない課題であり、違いはそれを事前に設計しておくか、エージェントが一度テストファイルを消してしまってから後付けで直すか、それだけだ。

参考資料:Google Developers Blog、CocoLoop、ADKおよびAntigravity SDKのプロジェクトドキュメント。harnessの定義、3つの設計原則、5回という上限は原文に基づいて確認済み。手書きコードゼロ行およびエンジニア3人という数字は記事の記述からの引用。