前置き：今回取り上げるのも「ハーネス」に関するサーベイです。最近、ハーネスに関する記事や論文を既にいくつかご覧になったかもしれません。その中には、先週私が解説した『エージェントハーネスエンジニアリング：エージェントの基盤工学に関するサーベイ｜CMU、イェール大学、Amazon』も含まれているでしょう。
先週の『エージェントハーネスサーベイ』は、「本格的に使えるエージェントには、外側に何を組み込むべきか」というシステムアーキテクチャの問いに答えるものでした。
一方、UIUC、Meta、スタンフォード大学によるこの最新サーベイが焦点を当てるのは、別の問題です。エージェントが長期タスク環境に投入されたとき、推論、行動、フィードバック、検証、そして協調を実際に結びつける操作対象とは何か？
その答えとして提示されるのが、コード化された実行プロセスです。
ここでいう「コード」とは、エージェントフレームワーク自体がコードで書かれているという（当然の）事実を指すのではありません。そうではなく、エージェントがタスクを実行する過程で継続的に生成、実行、修正、保存、共有する一連の中間生成物を指します。具体的なエンジニアリングの現場で言えば、Claude Codeが生成するPlan.mdや、成果物であるSkills.md、検証用のPythonファイルなどが該当します。
本記事では、原文で102ページ、478もの参考文献が引用されているこのサーベイから、Claude Codeからロボットエージェントまでを貫く基盤的な動作ロジックを、3つのトップ機関がどのように解き明かしているのか、その核心を最速で読み解いていきます。
この論文は「ハーネス」をどう定義しているか
技術的な詳細に入る前に、いくつかの中核的概念を明確にしておきましょう。
なぜ「足場（ハーネス）」が必要なのか？
純粋な大規模言語モデルはステートレスであり、本質的には次の単語を予測しているに過ぎません。長期タスクを実行できる「知的エージェント」へと進化させるには、モデルの周辺にソフトウェア基盤を層状に組み込む必要があります。この基盤には以下の要素が含まれます。
- ツールとAPIインターフェース
- 安全なサンドボックス実行環境
- 記憶とコンテキストの管理システム
- 検証機能と権限範囲
- 実行とフィードバックの制御ループ
この周辺システム全体を、研究者たちはエージェントハーネスと呼んでいます。
なぜ「コード」が最適なハーネス媒体なのか？
研究者たちは、コードが自然言語にはない3つの中核的特性を持つと指摘します。
実行可能性：コードはコンピュータ上で直接実行でき、明確な客観的結果を生み出します。
検査可能性：コードの実行プロセスはスタック、ログ、エラーを生成し、これらは正確に追跡・分析できます。
状態保持性：コード環境（ファイルシステム、データベースなど）は、タスクの進捗を持続的に保存できます。
これらの3つの特性に基づき、研究者たちはエージェントにおけるコードの役割を体系的に分解する3層アーキテクチャを構築しました。ハーネスインターフェース層、ハーネスメカニズム層、そしてマルチエージェント拡張層です。
論文では、コードをエージェントハーネスとして捉え、インターフェース層、メカニズム層、マルチエージェント層の3層に分解している。インターフェース層はコードに推論・行動・環境モデリングを担わせ、メカニズム層は計画・記憶・ツール・制御・最適化を担当し、マルチエージェント層はコードリポジトリ、テスト、軌跡、実行状態を協調の基盤とする。
第1層：ハーネスインターフェース
この層では、コードがエージェントと現実世界を繋ぐ基礎的なインターフェースとして機能します。具体的には、推論、行動、環境モデリングの3つの側面でその役割を果たします。
インターフェース層の核心は、モデルの出力を実行可能なプログラム、ツール呼び出し、状態追跡、フィードバック軌跡に接続することで、推論を検証可能にし、行動を実装可能にし、環境変化を観測可能にすることである。
論文では、推論、行動、環境モデリングにおけるコードの異なる役割に基づいて代表的な研究が整理され、この層がプログラム支援推論からロボット制御、GUI/OS操作、ソフトウェアエンジニアリング評価環境へと拡張されてきたことが示されている。
推論のためのコード
初期のエージェントは一般的に、純粋なテキストによる「思考連鎖（CoT）」に依存して推論を行っていましたが、これはしばしば論理エラーや計算の不正確さを招きました。推論プロセスをコードに変換することで、外部インタプリタやソルバーによるロジックの検証が可能になります。
プログラム委任推論：モデルは計算結果を直接出力する代わりに、Pythonスクリプトを生成し、それをPythonインタプリタに実行させます。このアプローチにより、高次の論理分解と低次の正確な計算が完全に分離されます。
形式検証と記号推論：Leanのような形式証明言語と組み合わせることで、エージェントのあらゆる推論ステップを機械検証器が自動的にチェックできるようにします。これは数学の定理証明や高セキュリティコードの検証において特に重要です。
コードベースの反復推論：エージェントは「コード生成 → コード実行 → エラーフィードバック取得 → コード修正」というクローズドループを通じて、実際の実行トレースを利用して次の推論の方向性を導き出します。
行動のためのコード
エージェントが物理世界（ロボット）やデジタル世界（ソフトウェアGUI）と対話する必要がある場合、コードはその実行媒体となります。
環境制約に基づくスキル選択：エージェントは低レベルの物理制御命令を直接生成するのではなく、物理法則に準拠した事前作成済みのコードスキルライブラリ（SayCanシステムなど）を呼び出し、動作の実現可能性を確保します。
プログラム化されたポリシー生成：エージェントは条件分岐やループを含む制御スクリプトを直接記述します。例えば、完全なPythonのビヘイビアツリーコードを生成し、ロボットアームの動きを詳細に制御します。
生涯学習型コードエージェント：エージェントは長期間の実行において、問題解決に成功した操作を新しいコード関数として継続的にカプセル化し、長期「スキルライブラリ」に保存することで（有名なVoyagerシステムのように）、持続的な能力進化を実現します。
環境モデリングのためのコード
環境の状態は複雑かつ動的であることが多く、純粋なテキストで正確に記述するのは困難です。コードは環境を操作可能なオブジェクトとして具象化できます。
構造化された世界表現：コード内のクラス、オブジェクト関係、あるいはツリー構造（WebページのDOMツリーなど）を用いて、現在の環境の空間的・論理的構造を正確に描写します。
実行軌跡に基づく世界モデリング：エージェントはコードの実行ログやテスト結果を読み取ることで、環境状態にどのような変化が生じたかを推測し、環境の動的変化に対する予測モデルを構築します。
検証可能な環境構築：ユニットテストやテストスタブ（Mock）などのコードエンジニアリング手法を活用し、エージェントのために客観的な正誤判断基準を備えたミニチュア世界を構築します。
第2層：ハーネスメカニズム
基盤となるインターフェースが整ったら、エージェントが数時間から数日に及ぶタスクで破綻しないようにするための、複雑なメカニズムが必要です。研究者たちはこれらのメカニズムを5つの主要モジュールに集約しています。
メカニズム層は、計画、記憶、ツール使用、制御ループ、ハーネス最適化の5つの問題領域をカバーし、エージェントの信頼性はモデルの判断、可変的なタスク状態、統制の取れたランタイム基盤の相互作用から生まれることを強調している。
エージェントの計画メカニズム
複雑なソフトウェアエンジニアリングタスクを処理するには、エージェントは明確な実行パスを持たなければなりません。計画メカニズムは、単一パスのステップ分解だけでなく、明示的な構造、マルチパス探索、あるいはシステムレベルのワークフローオーケストレーションを利用して、長期間タスクの実行軌跡を制御することもできる。
線形分解計画：大きなタスクを線形のステップリストに分解し（例：
PLAN.mdファイルを生成）、エージェントはそのステップに厳密に従ってコードを生成します。構造ベースの計画：コードリポジトリの依存関係グラフ（AST、クラス関係図）を利用して操作順序を導きます。エージェントは、この関数を修正すると他のどのファイルに影響が出るかを把握できるため、より安全な修正計画を立てられます。
探索ベースの計画：モンテカルロ木探索（MCTS）などのアルゴリズムを導入します。コード生成時に複数の可能性のある分岐を探索し、行き詰まった場合にはエラーメッセージを利用してバックトラックできます。
オーケストレーションベースの計画：理解、検索、コーディング、テストなどの異なるパイプライン段階にタスクを分割し、システムレベルのフロースケジューリングを通じてエージェントの次のアクションを制御します。
記憶とコンテキストエンジニアリング
数百万行規模のコードベースを扱う場合、大規模モデルはコンテキスト長の制限に非常に陥りやすいため、極めて強力なメモリ管理ソリューションが必要です。記憶層は、作業記憶、意味記憶、経験記憶、長期記憶、マルチエージェント記憶、そしてコンテキスト圧縮を、単一の状態管理問題に統合する。その目標は、限られたコンテキスト内にタスクの成否を左右する証拠を保持することである。
作業記憶：現在編集中の局所的な状態（例：現在のファイルの行番号、最新の数件のエラーログ）を厳格に管理し、無関係な情報でコンテキストが埋め尽くされるのを防ぎます。
意味記憶：検索拡張生成（RAG）技術を利用し、大規模なコードリポジトリから関連するクラス定義、APIインターフェース、履歴ドキュメントを正確に取り出します。
経験記憶と長期記憶：エージェントは過去にバグを調査した経験や、検証に成功したパッチなどを構造化された経験ベースに変換し、タスクを超えた知識の再利用を実現します。
コンテキスト圧縮とアンロード：ログが長すぎる場合、システムは自動的に粗粒度または細粒度の圧縮を行うか、あるいは完全なログを外部ファイルに保存し、プロンプトには重要なサマリーのみを保持します。
ツール使用
ツールはエージェントが外界を変える手段ですが、コードハーネスにおいては、ツールの使用は厳格に管理されなければなりません。
ツール層には、関数呼び出しや外部APIだけでなく、ターミナル、リポジトリ、サンドボックス、検証機能、複数ステップのワークフローも含まれる。重要な問題は、ツールを発見可能、呼び出し可能、監査可能にし、失敗時に回復できるようにすることだ。
機能指向ツール：モデルが不足している知識を補うために使用されます。例えば、外部APIを呼び出してドキュメントを検索したり、特定のライブラリ関数の使用法を問い合わせたりします。
環境対話ツール：エージェントがターミナルコマンド（Shell）の実行、ファイルの読み書き、コードリポジトリのナビゲートなど、実環境で直接操作することを許可します。
検証駆動ツール：コードリンター、型チェッカー、ユニットテストフレームワークを使用して、エージェントの出力に決定的で客観的なフィードバックを提供します。
ワークフローオーケストレーションツール：複数のサブツールの呼び出し順序を調整し、ツール呼び出し失敗時の例外回復を処理します。
計画-実行-検証ループ（PEVループ）
研究者たちは、エージェントのデバッグプロセスは本質的にサイバネティクスの問題であり、PEVループ（Plan-Execute-Verify）としてフレームワーク化されるべきだと指摘しています。PEVループは、計画、サンドボックス実行、静的/動的検証、権限制御を反復可能な状態遷移プロセスに組織化し、エージェントによる各変更を観測、判断し、必要に応じてロールバックしたり人間にエスカレーションしたりすることを可能にする。
計画：ユーザーの要求を明確な操作契約に変換し、修正すべき範囲を決定します。
実行：サンドボックス環境内で実行されなければなりません。隔離されたファイルシステムと段階的な権限制御により、エージェントの破壊的な操作がホストマシンのセキュリティに影響を与えないようにします。
検証：静的解析と動的テストを「決定的なセンサー」として利用します。テストが失敗した場合、エージェントはログに基づいて修正する必要があります。高リスク操作が含まれる場合は、人間の承認（Human-in-the-loop）を必須とします。
適応的ハーネスエンジニアリング
これはこの論文が提唱する非常に最先端の概念です。システムはコード自体の修正に留まらず、モデルの周辺にある「ハーネス」自体を自動的に最適化できるべきです。適応的ハーネスエンジニアリングは、プロンプト、検索戦略、ツール記述、検証機能、権限ルール、ワークフロー自体をすべて最適化可能な対象と見なす。ただし、これらの変更は軌跡の再実行、保留タスク評価、ガバナンスルールによる制約を経なければならない。
詳細なテレメトリ：エージェントのトークン消費量、レイテンシ、ツール呼び出し成功率、完全な実行軌跡を包括的に記録します。
進化エージェント：メタレベルのエージェントを特別に設置します。これはビジネスコードを書くのではなく、テレメトリデータを分析し、検索戦略を自動修正したり、プロンプトテンプレートを更新したり、サンドボックスルールを再構築したりすることで、システム全体をますます安定させます。
第3層：ハーネスの拡張
現実の極めて複雑なエンタープライズレベルの要求に直面すると、単一エージェントのコンテキストと能力は容易にボトルネックに達します。マルチエージェント協調（MAS）の導入は必然的な流れです。この段階で、コードは正式に、各エージェント間のコミュニケーション、協調、そして合意形成のための「共有基盤」となります。
マルチエージェント拡張層は、役割の専門化、共有コード基盤、実行フィードバック、適応的協調トポロジーを通じて、単一エージェントにおけるコンテキスト、専門能力、自己修正のボトルネックを緩和する。
役割分担
システムは人間のソフトウェア開発チームを模倣し、高度に専門化された役割を分割します。
プログラマー：具体的なコード記述を担当します。
テスター：意図的に困難なテストケースを作成し、プログラマーのコードの欠陥を積極的に探します。
レビュアー：アーキテクチャとコーディング規約の観点からコードをレビューします。
実行者：サンドボックス内でコードを実行し、客観的なエラーログを収集します。
プランニングマネージャー：全体的なタスク分解とプロセススケジューリングを担当します。
インタラクションモード
ペアプログラミング：2つのエージェントが共同でコードを構築します。1つはナビゲーションと計画を担当し、もう1つは具体的な実装を担当します。
レビューと修正：最も一般的なパターンです。検証エージェントが批評を行い、プログラミングエージェントがそれに基づいて修正します。
敵対的検証：ファジングなどの手法を用いて極端な入力を生成し、意図的にクラッシュを引き起こし、そのクラッシュ軌跡をプログラマーにフィードバックします。
推論討論：複数のエージェントが要求理解やコード規約に関して意見の相違がある場合、複数ラウンドの対話を通じて合意に達します。
中核拠点：共有プログラム状態
研究者たちは、現在の多くのマルチエージェントシステムが「チャット履歴」だけに依存して情報を伝達していることを厳しく指摘しています。これは深刻な「状態の発散」を引き起こし、異なるエージェント間で「現在のコードが実際にどのような状態か」について認識のズレが生じます。
将来のマルチエージェントシステムは、コードに基づいた客観的なグローバル共有状態を確立しなければなりません。
- それが実際のGitリポジトリを通じてであれ、メモリ内のブラックボードアーキテクチャを通じてであれ、あるいは完全な実行コンテキストを通じてであれ。
「合意」とは、単に複数のエージェントが互いに「良さそうだ」と言うことではなく、客観的に全テストがパスし、静的チェックに警告がなく、パフォーマンス指標が基準を満たしていることでなければなりません。
論文はさらに、マルチエージェント協調をワークフロー協調、共有リポジトリ状態、実行検証、適応的調整の4つの問題に分解し、協調は対話記録だけに留まらず、検査可能なプログラム状態に基づかなければならないと強調している。
最先端の5つの応用領域
「コードをエージェントハーネスとする」という理念は、現在、以下の5つの現実的な応用シーンで結実しつつあります。
論文では、応用シーンをコードアシスタント、GUI/OSエージェント、科学的発見、パーソナライゼーション、具現化エージェントに要約し、コードハーネスがソフトウェアエンジニアリングからデジタルインターフェース、科学研究パイプライン、物理世界制御へと拡張していることを示している。
AIプログラミングアシスタント
初期の単純なコード補完（初期のCopilotなど）から、GitHubのIssueを処理できる「自動化された研究開発スタッフ」（SWE-agent、OpenHandsなど）へと進化しました。これらは自律的にコードを取得し、エラーを読み取り、ローカルサンドボックスで継続的に試行錯誤し、最終的にPull Requestを提出できます。このプロセスにおいて、サンドボックス、テストフレームワーク、Gitバージョン管理がそれらのハーネスです。
GUI/OSエージェント
デスクトップやスマートフォンの画面でのクリック操作は、実行可能なコードスクリプト（PlaywrightスクリプトやDOMツリー操作など）に変換されつつあります。エージェントは画面のHTML構造やアクセシビリティツリーを読み取って環境を認識し、クリックやスワイプを実行するためのPythonコードを出力します。UIインターフェースは、コードによって操作される世界となります。
科学的発見
自動化されたラボでは、科学研究プロセスがシームレスに接続された「コードパイプライン」に統合されています。文献検索、仮説の提案から、Pythonシミュレーションプログラムの作成、実際の液体ハンドリングロボットを制御しての化学合成、実験データの処理に至るまで、科学研究のあらゆる段階をコードが貫いています（AI Scientistシステムなど）。
パーソナライズドレコメンデーションエンジン
エージェントはユーザーのリアルタイムフィードバックに基づいて、レコメンデーションシステムのポリシーコードを自動的に作成・修正し、ユーザーの好みを持続的なプログラム読み取り可能な状態オブジェクトとして蓄積できます。
具現化エージェント
ロボット工学の分野では、抽象的な行動意図が運動学的パラメータを含む実行可能な制御コードに変換されます。コードは安全境界として機能し、ロボットの動作（ロボットアームによる把持など）が物理法則に準拠していることを保証し、実世界に投入する前にシミュレーターコード内で問題を洗い出します。
早急に解決すべき課題と未解決の問題
将来性は広大ですが、研究者たちはこの分野が現在直面しているいくつかの中核的課題も冷静に指摘しています。
評価指標のボトルネック：現在の評価のほとんどは「テストケースがパスしたか」しか見ていません。しかし、これではエージェントが洗練された高品質なコードを書いたのか、それとも単にテストをすり抜けるためのパッチの寄せ集めで元のシステムアーキテクチャを破壊しただけなのかを区別できません。より深い意味的・アーキテクチャレベルでの評価が必要です。
不完全な実行フィードバック：コードが実行できる場合でも、セキュリティホールやパフォーマンス上の問題が潜んでいる可能性があります。現在の検証器は、このような非機能要件を扱う際には依然として非常に脆弱です。
後退を伴わない自己進化：システムがハーネスを自動修正したりコードを再構築しようとしたりする際、「破滅的忘却」に陥りやすく、古いバグを1つ修正した代わりに、新たなバグを10個持ち込むという事態が発生します。
マルチエージェント並行処理の意味的競合：複数のエージェントが同じコードベースの異なる部分を同時に修正する場合、それらの基盤となるビジネスロジックにおける暗黙的な競合をどのように解決するか？現在のテキストマージツール（Git mergeなど）では、深いレベルでのロジックの断裂を解決できません。
安全説明責任と人間の監視（Human-in-the-Loop Safety）：コードエージェントが本番環境や物理デバイスを直接操作する権限を取得する場合、高リスク操作に対する人間の絶対的な拒否権を確保する、強固な介入メカニズムを確立しなければなりません。
結論
この論文は、AI分野に対して極めて明確で、歴史的な意義を持つ「エージェントシステムエンジニアリングの青写真」を提供しています。
AIを真に複雑な現実世界へと導くためには、決して大規模モデル自身の計算能力の向上だけに頼っていてはなりません。「コード」をシステムの骨格、神経、そして筋肉としなければならないのです。大規模モデルは強力な「頭脳」を提供しますが、コードに基づいて構築されたエージェントハーネスは、この頭脳に安定したサンドボックス、現実的な物理フィードバック、信頼できる記憶メカニズム、そして複数役割の協調のための組織原理を与えます。この「実行可能、検査可能、状態保持可能」なコード基盤に深く根差してこそ、AIエージェントはデモレベルの玩具から、産業グレードの信頼できる生産性へと真に脱皮できるのです。
未来は既に到来しています。ご縁があれば、共に歩んでいきましょう！
＜本文終わり＞