🤖 AI

From Question Answering to Task Completion: A Survey on Agent System and Harness Design

本サーベイは、基盤モデルと実行時ランタイムの結合が、6つの主要な責務からなる構成要素を通じて、システムの性能、信頼性、および汎用性をどのように決定づけるかを分析することにより、LLMベースのエージェントにおける受動的な質問回答から能動的なタスク完了へと焦点を移行させるモデルハーネス・フレームワークを提案するものである。

原著者： Jianyuan Guo, Zhiwei Hao, Chengcheng Wang, Cheng Fan, Tingzhang Luo, Hongguang Li, Ying Gao, Hefei Mei, Jiankun Peng, Rongjian Xu, Minjing Dong, Han Wu, Mengyu Zheng, Kai Han, Shiqi Wang, Chang Xu, Yu

公開日 2026-06-23

📖 1 分で読めます☕ さくっと読める

CC BY 4.0

原著者： Jianyuan Guo, Zhiwei Hao, Chengcheng Wang, Cheng Fan, Tingzhang Luo, Hongguang Li, Ying Gao, Hefei Mei, Jiankun Peng, Rongjian Xu, Minjing Dong, Han Wu, Mengyu Zheng, Kai Han, Shiqi Wang, Chang Xu, Yunhe Wang

原論文は CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) でライセンスされています。 ✨ これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。免責事項の全文を読む

本質的なアイデア：脳だけがすべてではない

想像してみてください。あなたは、ディナーパーティーのために複雑なフルコースを作るべく、世界クラスの優秀なシェフ（AIモデル）を雇いました。かつて人々は、重要なのはシェフがいかに賢いかだけだと考えていました。もしシェフがあらゆるレシピを知っていれば、料理は完璧になるはずだと。

しかし、この論文は**「シェフは物語の半分に過ぎない」**と主張しています。

もし、そのシェフに壊れたコンロ、食材なし、混乱したメニュー、そしてスープが焦げている時に教えてくれる人もいない状況を与えたら、たとえシェフが天才であっても、料理は失敗するでしょう。この「コンロ」「食材」「キッチンマネージャー」こそが、著者たちが**「ハーネス（Harness）」**と呼ぶものです。

この論文の主な主張は、**「エージェントの性能は、AIがいかに賢いかだけでなく、そのAIがどのような『キッチン（ハーネス）』と組み合わされているかによって決まる」**ということです。

成長の4段階

著者たちは、AIエージェントがどのように構築されてきたかを、子供の成長過程になぞらえて4つの段階で説明しています。

フェーズ1：プロンプトエンジニアリング（「優しくお願い」の段階）
- 比喩： あなたは、賢いけれど内気な生徒に質問に答えてもらおうとしています。「これについて説明してください」「例えばこうです」「ステップバイステップで考えてください」など、さまざまな聞き方を試します。
- 限界： 優しくお願いできる回数には限りがあります。もし生徒が答えを知らなかったり、答えを出すために図書館へ行き、本を開き、レポートを書く必要がある場合、ただ優しく聞くだけでは解決しません。
フェーズ2：コンテキストエンジニアリング（「図書委員」の段階）
- 比喩： 今度は、生徒が正しい本を見つける手助けが必要だと気づきました。あなたは、適切なページを検索し、要約して、生徒が回答する前にそれを手渡すシステムを構築します。
- 限界： あなたはまだ情報を手渡しているだけです。もし生徒が間違ったことを書き始めたり、気が散ったりしても、それを止めたり、内容をチェックしたり、間違いを修正したりするシステムを持っていません。
フェーズ3：ハーネスエンジニアリング（「プロジェクトマネージャー」の段階）
- 比喩： ここで大きな転換が起こります。単に指示を与えるのではなく、生徒の周りに完全なオペレーティングシステムを構築し始めます。
  - 観察（Observation）： 何が起きているかを見るためのカメラを与えます。
  - 制御（Control）： タイマーと停止ボタンを用意します。
  - 実行（Action）： キーボードとマウスを与えます。
  - 検証（Verification）： すべてのステップをチェックする教師を置きます。もし生徒がシステムを壊すようなコードを書いたら、システムは自動的にロールバックし、「やり直してください」と伝えます。
- 結果： この論文は、この「キッチン（ハーネス）」を再設計するだけで、平凡なシェフに5つ星の料理を作らせたり、天才シェフをさらに優れたレベルに引き上げたりできることを示しています。
フェーズ4：共進化（「自己改善するチーム」の段階）
- 比喩： 今や、生徒とキッチンマネージャーはお互いに学び合っています。生徒はこの特定のキッチンで練習することで料理が上手くなり、キッチンマネージャーは生徒の料理を見て、管理の方法を向上させます。彼らは共に進化していくのです。

「キッチンの解剖学」（ハーネスの構成要素）

論文では、この「ハーネス」を、整理されたキッチンクルーのように6つの具体的な役割に分解しています。

観察（目）： AIは世界をどのように見ているか？ぼやけたスクリーンショットを見ているのか、それとも整理された明確なデータリストを見ているのか？
コンテキスト（記憶）： AIは何を覚えているか？会話の履歴すべてを流し込むのか、それとも最も重要なメモだけを渡すのか？
制御（指揮者）： 次に何が起きるかを誰が決めるのか？ AIが疲れるまでやり続けるのか、それともマネージャーがいつ止まるべきか、いつ助けを求めるべきか、いつタスクを切り替えるべきかを指示するのか？
実行（手）： AIは実際にどのように行動するのか？ボタンをクリックできるのか、それとも単に「クリックしました」と言うだけなのか？ハーネスはAIの言葉を実際の動作へと変換します。
状態（ファイルキャビネット）： AIは作業をどこに保存するか？下書きを書いたとき、それはファイルに保存されるのか、それとも画面が更新されると消えてしまうのか？
検証（安全検査員）： これは極めて重要です。AIが顧客にファイルを送る前に、安全チェックが行われるか？もしAIが危険な動きをした場合、システムはそれを阻止できるか？

なぜこれが重要なのか：「ボトルネック」の転換

論文では、AIがコンピュータのコードを修正したりウェブサイトを閲覧したりといった、実際の仕事を行わせる多くのテスト（ベンチマーク）を調査しました。

旧来の視点： AIの「脳」をもっと大きく、もっと賢くすれば、すべてが解決すると考えていました。
新しい視点： 論文によれば、「脳」はすでに限界に達しています。 脳を大きくしても、得られる改善はごくわずかです。現在の真のボトルネックは、**「ハーネス」**にあります。

証拠：

コーディングのテストにおいて、同じAIモデルでも、単純なハーネスでは成功率が**23%でしたが、より優れた設計のハーネスを用いると72%**まで上昇しました。
これは、フェラーリのエンジン（AI）を持っていても、自転車のフレーム（悪いハーネス）に乗せていたら、速く走れないようなものです。その同じエンジンをレーシングカーのシャシー（良いハーネス）に乗せれば、勝利を掴めるのです。

まとめ

私たちは、AIを単に質問に答える「チャットボット」として考える時代から、**「自律的な労働者」**を構築する時代へと移行しています。

信頼できる労働者を構築するには、単に最も賢い脳を選ぶだけでは不十分です。彼らが働く環境全体を設計しなければなりません。

彼らは何を見るのか？
どんな道具を持っているのか？
誰が彼らの仕事をチェックするのか？
ミスをしたときに、どのように復旧するのか？

論文は、AIの未来は単に巨大なモデルを作ることではなく、それらのモデルを取り巻くシステムのエンジニアリングをより良くすることにあると結論付けています。エージェントの品質は、モデルとそのハーネスとのパートナーシップによって決まるのです。

技術要約：質問回答からタスク完了へ：エージェントシステムとハーネス設計に関する調査

1. 問題提起

大規模言語モデル（LLM）ベースのエージェントの分野は、受動的な質問回答（QA）から、能動的なマルチステップのタスク完了へと移行している。最先端のモデルは静的なベンチマーク（MMLU、GPQAなど）では飽和状態に達しているが、インタラクティブで長期的なエージェントタスク（SWE-bench、WebArenaなど）においては、著しい信頼性のギャップを示している。本調査が取り組む中心的な問題は、エージェントシステムの性能ボトルネックの所在を特定することである。著者らは、ボトルネックはもはや基礎モデルの推論能力のみにあるのではなく、モデルと環境の間の相互作用を媒介する実行時インフラストラクチャである**実行ハーネス（execution harness）**に移行していると主張している。本論文は、エージェントの品質（成功、効率、安全性、汎用性）は、モデル単独の関数ではなく、モデルとそのハーネスの結合から生じる創発的な特性であると断じている。

2. メソドロジーとフレームワーク

本調査は、エージェントエンジニアリングの進化を分析するために、モデル–ハーネスのレンズを採用している。これは新しいアルゴリズムを提案するものではなく、特定の概念的フレームワークを通じて、既存の文献、ベンチマーク、および産業界のレポートを統合するものである。

機能的視点 vs 実装的視点: 本論文は、エージェントの機能的定義（知覚、推論、行動、適応を行う目標指向のクローズドループシステム）と、実装的視点（LLMと実行ハーネスを結合したもの）を区別している。
形式的分解: 実行ハーネス（ $H$ $H$ ）は、以下の6つの結合された実行時責任のタプルとして定式化される：
1. 観測インターフェース ( $I_{obs}$ ): 生の環境信号（ログ、DOM、差分）をモデルが利用可能な観測情報へと変換する。
2. コンテキストマネージャー ( $C$ ): モデルのコンテキストウィンドウに入る情報のキュレーション、圧縮、および更新を行う。
3. 制御ループ ( $L$ ): ステップのスケジューリング、委譲、停止基準を含む、観察・推論・行動・フィードバックのサイクルをオーケストレートする。
4. アクションインターフェース ( $I_{act}$ ): モデルの出力を実行可能な操作（API、シェルコマンド、ツールコール）へとマッピングする。
5. 状態およびアーティファクトストア ( $S$ ): アクティブなコンテキストウィンドウを超えて、実行状態、計画、チェックポイント、および生成されたアーティファクトを保持する。
6. 検証とガバナンス ( $V$ ): 結果のチェック、安全制約の強制、権限管理、およびリカバリ/ロールバックの処理を行う。
進化論的分析: 文献は、主要な性能向上レバーが各段階でどのようにシフトしたかを分析しながら、エージェントエンジニアリングの4つの連続的なパラダイムに整理されている：
1. プロンプトエンジニアリング: 単一ターンの指示を最適化する（「表現」の問題に対処）。
2. ワークフローとコンテキストエンジニアリング: 情報のライフサイクルとツールの定義をキュレートする（「情報」の問題に対処）。
3. ハーネスエンジニアリング: フィードバック駆動の実行、状態保持、およびエラーリカバリのための実行時インフラストラクチャを設計する（「実行」の問題に対処）。
4. エージェントネイティブな学習と共進化: エージェント的な振る舞い（計画、検証）をモデルのパラメータ内に内在化させる（モデルとハーネスのペアを共同で進化させる）。

3. 主な貢献

本調査は、先行研究と比較して主に3つの区別を行っている：

進化を優先した統合: 静的なコンポーネントの分類学ではなく、エンジニアリングのボトルネックがプロンプト最適化から実行時システム設計、そして将来の共進化へと移行していく過程を追跡している。
ハーネス中心の視点: 実行ハーネスを第一級の技術的対象として扱い、上述の6つの実行時コンポーネントに分解している。ハーネスの設計が、基礎となるモデルが固定されている場合でも、信頼性と効率性を決定すると主張している。
経験的エビデンスの統合: 学術的なベンチマークと産業界の実践を結びつけ、実行時の設計選択（例：観測の成形、コンテキスト管理）がエージェントの性能に直接影響を与えることを経験的データを用いて示している。

具体的な貢献:

モデル中心のスケーリングの限界: モデルのスケーリングが、リソース・パフォーマンスの境界および静的ベンチマークにおける測定の飽和により、エージェント的タスクにおいて収穫逓減をもたらすことを分析している。
タスクとハーネスのマッピング: タスクの特性（ホライゾン、環境タイプ、自律レベル）を特定のハーネス構成にマッピングしている。例えば、ソフトウェアエンジニアリングのタスクは「検証」を、Web/GUIタスクは「観測」および「アクション」インターフェースを重視する。
ベンチマーク分析: SWE-bench、Terminal-Bench、WebArenaの詳細な経験的分析を提供し、以下を実証している：
- 同じバックボーンモデルであっても、ハーネスによって達成率が数十パーセント単位で変化する。
- インターフェース設計が最適であれば、最小限のスキャフォールド（例：mini-SWE-agent）が、複雑で多機能なランタイムの性能に匹敵、あるいは接近する場合がある。
- ベンダーが報告するスコアは、独自のハーネス最適化によりオープンソースの結果を上回ることが多く、「スキャフォールド」の重要性を浮き彫りにしている。

4. 結果と知見

ハーネスの影響: SWE-bench Verifiedの経験的エビデンスによれば、固定されたモデル（例：Claude 3.5 Sonnet）において、解決率はハーネスに応じて約33%から約53%まで変動する。同様に、Terminal-Bench 2.0においても、同じモデル（例：GPT-5.3-Codex）が異なるハーネス間で64.7%から78.4%まで変動する。
ボトルネックの移行: タスクが複雑になるにつれ（L2の短期的ホライゾンからL4のオープンエンドへ）、ボトルネックはモデルの推論から、状態管理、結果の検証、およびエラーからのリカバリを行うハーネスの能力へとシフトする。
コストと効率: 高い精度は、しばしば高いリソースコスト（トークン使用量、レイテンシ、タイムアウト）と相関する。論文は、「成功」はリトライ予算やコンテキストポリシーを含む実行時の構成に条件付けられていると指摘している。
マルチモデルおよび学習可能なハーネス: 最近の傾向として、組成的なランタイム（計画、コーディング、検証のために異なるモデルをルーティングする）や、実行時ポリシーがアーティファクトとして最適化される学習可能なハーネスへのシフトが見られる。

5. 重要性と主張

本論文は、分野が「プロンプトの工夫」を超え、完全なシステムの研究へと移行したと主張している。その重要性は、エージェント開発を再定義している点にある：

エージェントの品質は創発的である: 成功、効率、および安全性はモデルに固有のものではなく、モデルの能力、実行時インフラ、タスク構造、および評価設計の相互作用から創発するものである。
価値を考慮した評価の必要性: 著者らは、スコア中心のリーダーボードから、タスクの成功、コスト、レイテンシ、安全性、およびプロセス品質を共同で最適化する**価値を考慮した評価（value-aware evaluation）**への移行を提唱している。彼らは、コスト、レイテンシ、リスクに対する制約に対して効用をバランスさせる形式的な目的関数を提案している。
将来の方向性: 本調査は、検証およびリカバリの振る舞いがモデルパラメータに内在化されるエージェントネイティブな学習、およびモデルとハーネスが実行トレースから共同で更新される共進化への道を特定している。しかし、モデル設計とシステム設計の境界は依然として再交渉中であり、現実的な設定における信頼性は展開ニーズを下回っていることも謙虚に述べている。

結論として、本調査は、モデルの能力を信頼できる長期的なタスク完了へと変換する方法を制御するという意味で、実行ハーネスの理解が現在、エージェントエンジニアリングにおける中心的な課題であると論じている。