近年、LLMベースのエージェントは単なる受動的な質問応答から、自律的に環境を認識し、長期的なタスクを完遂するシステムへと移行しています。このような機能的要件を満たすため、現在のエージェントは「認知エンジン」である基盤モデル（\(M\)）単体ではなく、ツール呼び出しや状態管理を担う周辺環境「実行ハーネス（\(H\)）」との結合システムとして定義され、実装上は \(A_\text{LLM} = \langle M, H \rangle\) と定式化されます。

一方で、MMLU-ProやGPQA Diamondといった静的なQAベンチマークにおいて、モデルのパラメータ数拡大による性能向上は飽和しつつあります。複雑なマルチステップタスクでは、計算資源の追加が必ずしも直接的な精度向上に結びつかない「リソース対効果の境界（Resource-Performance Boundary）」に直面しており、モデル単体のスケールアップだけでは埋められない信頼性のギャップが顕在化しています。

本記事では、エージェントの性能ボトルネックが「基盤モデル」から「実行ハーネス」へと移行している現状を紐解き、次世代のエージェントシステムを設計するための実践的な指針を解説します。

1. エージェントエンジニアリングの4つのパラダイム

LLMを組み込んだエージェントシステムの開発は、単一の指示の工夫から複雑な実行システムの構築へと急速に進化してきました。この進化は、エンジニアが「何を最適化の対象とするか」によって、大きく4つのパラダイムに分けることができます。

まずは、これら4つの進化の段階を以下の表で整理してみます。

フェーズ	パラダイム	最適化の対象	主な課題・限界
Phase 1	Prompt Engineering （プロンプト）	単一の指示の記述方法	知識不足や動的な状態管理の限界
Phase 2	Context Engineering （コンテキスト/ワークフロー）	情報の構築・提供プロセス	実行中のエラー検知や軌道修正の欠如
Phase 3	Harness Engineering （ハーネス）	実行インフラ・制御ループ全体	手作業による設計の限界
Phase 4	Agent-Native Training & Co-Evolution （エージェント・ネイティブ学習）	モデル自身と実行環境の共進化	未成熟な評価指標・安全性

このように、課題を解決するために最適化の焦点がモデルの入力から周辺環境、そしてモデル自身のパラメータへと移行していることがわかります。

コンテキストを「関数」として捉える数理的意味

Phase 2の段階では、モデルに与えるコンテキストを静的なテキストではなく、動的に構築される情報のエコシステムとして扱います。これを数式で定式化すると、以下のようになります。

$$C = A(c_1, c_2, \dots, c_n)$$

ここで、\(C\) は最終的にモデルへ渡されるコンテキストを表します。\(c_1, \dots, c_n\) は、検索された外部文書、過去の記憶データ、ツールの説明、タスクの現在状態など、様々な構成要素を指します。そして \(A\) は、これらの情報を選択し、要約・圧縮して組み合わせる「組み立て関数」です。

つまり、エンジニアの役割は「どのように質問するか」から、「必要な情報をどのタイミングでどう組み合わせて提供するか」を設計することへとシフトしました。

ハーネス・エンジニアリングの最前線

現在主流になりつつあるPhase 3では、情報を与えるだけでなく、実行中のエラー検知や復旧といった制御の仕組みを構築します。

その最前線にあるのが、「コンポジション可能（Compositional）なマルチモデルハーネス」というアプローチです。これは、すべての処理を1つの巨大な基盤モデルに任せるのではなく、計画立案、ツールの実行、結果の検証、コード生成などを、それぞれ得意な専門モデルに振り分けて連携させる仕組みです。適材適所でモデルをルーティングすることにより、コストや処理時間を抑えつつ、より信頼性の高い長期的なタスクの完遂を実現できます。

次世代への展望：能力の「内部化」

さらに先のPhase 4として、エージェントの振る舞いをモデル自身に学習させる動きが進んでいます。

ここで重要になるのが「内部化（Internalization）」という概念です。これまで、ツールの呼び出し方や計画の立て方、エラー時の検証や復旧手順などは、実行ハーネス側でルールやワークフローとして実装していました。しかし次世代のアプローチでは、強化学習などを通じて対話的な環境でモデルを訓練し、これらのエージェント的な能力をモデルのパラメータ自体に直接組み込むことに取り組んでいます。

これにより、ハーネスはより高度な安全性（セーフティガード）の担保や外部システムとの連携に専念できるようになり、モデルとハーネスが共に進化していく（Co-Evolution）エコシステムが形成されると期待されています。

2. 6つの実行ハーネス・コンポーネント

エージェントシステムが複雑なタスクを完遂するためには、モデルを支える実行環境である「実行ハーネス」を体系的に設計する必要があります。この実行ハーネス（\(H\)）は、役割の異なる6つのコンポーネントから構成され、数式では以下のように定義されます。

$$H = \langle I_\text{obs}, C, L, I_\text{act}, S, V \rangle$$

それぞれのコンポーネントがどのように機能し、どのような設計上の課題があるのか、3つのグループに分けて解説します。

観測とコンテキスト: 環境の認識と情報の整理

• 観測インターフェース（\(I_\text{obs}\): Observation Interface）
  画面の表示状態やAPIの応答といった生の環境シグナルを、モデルが処理できる形式に変換します。ここでは「情報量の豊かさ」と「扱いやすさ」のトレードオフが重要な設計課題となります。詳細な情報を渡せば状況の理解（グラウンディング）は深まりますが、ノイズや処理コストが増加します。一方で、情報を圧縮しすぎると、モデルが次の行動を決めるための重要な手がかりを失うリスクがあります。
• コンテキストマネージャー（\(C\): Context Manager）
  入力枠（コンテキストウィンドウ）にどのような情報を、いつ、どのような形式で渡すかを管理します。単にモデルへの入力枠を拡大するのではなく、過去の記憶の選択、情報の圧縮、要約などを通じて内容を動的に更新します。長期的なタスクにおいて全ての対話履歴を保持し続けることは非効率であるため、現在のタスク状態に合わせて適切な情報だけを抽出する仕組みが求められます。

制御とアクション: 自律的な意思決定と操作の実行

• 制御ループ（\(L\): Control Loop）
  「観察・推論・行動」という一連のサイクルをオーケストレーション（統合管理）します。エージェントに自由な判断を委ねるほど予期せぬ状況に適応しやすくなりますが、本来の目的から逸脱する（ドリフトする）リスクも高まります。そのため、自律性の高さと実行の安定性のバランスをどうとるかが、長期タスクを成功に導く鍵となります。
• アクションインターフェース（\(I_\text{act}\): Action Interface）
  モデルが生成したテキストを、システム上で実行可能な実際の操作にマッピングします。ここではツールの「抽象度」の設計が問われます。細かすぎる低レベルな操作は汎用性が高い一方でエラーを引き起こしやすく、高レベルな操作は安全に機能しますが、エージェントが対応できる幅を狭めてしまう可能性があります。

状態ストアと検証: 継続性の担保と安全なガバナンス

• 状態・アーティファクトストア（\(S\): State and Artifact Store）
  実行計画や生成されたファイルの差分（diff）、ログなどを永続的に保存します。モデルのコンテキストウィンドウの制限を超えてこれらの中間生成物を保存することで、過去の試行錯誤を再利用できるようになります。これにより、長期間にわたるタスクの連続性を担保しています。
• 検証とガバナンス（\(V\): Verification and Governance）
  エージェントの行動を監視・テストし、必要に応じて制約をかける層です。長期間にわたる自律行動では、誤った操作の蓄積やシステムへの破壊的な変更といったリスクが伴います。そのため、サンドボックス（隔離された実行環境）を用いた安全な実行や、重要な操作に対する権限ゲート、問題発生時のロールバック（状態の巻き戻し）といった機能が不可欠になります。

3. タスク特性とハーネス構成のチューニング

実行ハーネスの6つのコンポーネントは、どのようなタスクを解決するかによって設計の重点（ボトルネック）が変化します。ここでは、タスクの複雑性と適用される環境の特性に応じて、ハーネスをどのようにチューニングすべきかを解説します。

タスク複雑性とボトルネックの移行

タスクの複雑性が上がるにつれて、システムが直面する課題は変化します。単発の質問応答や単純な手順の実行であれば、モデルに適切な情報を渡す「コンテキストマネージャー（\(C\)）」が主なボトルネックとなります。

しかし、リポジトリ全体のリファクタリングや自律的な調査といった長期的なタスクへと複雑化すると、状況は一変します。過去の計画や中間生成物を長期間保持する必要が生じるため、「状態・アーティファクトストア（\(S\)）」の設計が重要になります。さらに、予期せぬエラーから立ち直るための「制御ループ（\(L\)）」や、予期せぬ動作を防ぐ監視の仕組みが新たなボトルネックへと移行していきます。

環境特性に応じたハーネスの設計指針

適用するドメインの性質によっても、重視すべきコンポーネントは異なります。代表的な3つの環境を例に挙げます。

• ソフトウェア環境（検証主導）
  コーディングタスク（例: SWE-bench）の最大の特徴は、コンパイラやテストコードといった「強力な正解判定（Strong oracle）」が存在することです。この環境では、テスト結果をフィードバックとして受け取り、コードを修正するサイクルが成功の鍵を握ります。したがって、「検証とガバナンス（\(V\)）」によるエラー検知と、「制御ループ（\(L\)）」によるテスト・修復ループの最適化が最重要になります。
• Web / GUI環境（グラウンディング主導）
  ブラウザ操作（例: WebArena）やデスクトップ画面の操作では、視覚的・構造的に複雑な状態を正確に把握（グラウンディング）する必要があります。ソフトウェア環境のような明確なエラーメッセージが得られないことも多いため、画面のHTMLやスクリーンショットをモデルが理解しやすい形に変換する「観測インターフェース（\(I_\text{obs}\)）」と、出力テキストを実際のクリック操作などに安全にマッピングする「アクションインターフェース（\(I_\text{act}\)）」の適切な抽象化がボトルネックとなります。
• 医療・ロボット環境（安全性主導）
  医療診断支援や物理ロボットの制御では、一度実行すると元に戻せない「不可逆なアクション（Irreversible actions）」を伴います。この環境では、高い自律性を追求することではなく、安全性の担保が最優先されます。そのため、「検証とガバナンス（\(V\)）」を厳格化し、重要な操作の前に人間の承認（権限ゲート）を必須にするなど、不確実な状況下では保守的にエスカレーションする（安全に停止して人間に判断を委ねる）設計が不可欠です。

タスク特性	失敗圧力（Failure pressure）	ハーネスの対応（Harness response）	重要コンポーネント
長期的なタスク（Long horizon）	状態のドリフト（State drift）	チェックポイント、要約、成果物管理	\(\mathcal{C}, \mathcal{S}, \mathcal{L}\)
部分観測（Partial observability）	状態が間接的にしか分からない	構造化された観測、グラウンディング、抽象化	\(I_{\text{obs}}, \mathcal{C}, I_{\text{act}}\)
強いオラクル（Strong oracle）	結果が検証可能	検証ループ、修復サイクル	\(\mathcal{V}, \mathcal{L}\)
弱い／遅延オラクル（Weak or delayed oracle）	成功が不確実	来歴管理、レビュー、承認プロセス	\(\mathcal{V}, \mathcal{C}, \mathcal{S}\)
不可逆な操作（Irreversible actions）	永続的な副作用	サンドボックス、ゲート、ロールバック	\(\mathcal{V}, I_{\text{act}}\)
高い自律性／低レイテンシ（High autonomy or low latency）	人間による修正が困難	ロギング、予算管理、コントローラ	\(\mathcal{V}, \mathcal{L}, I_{\text{obs}}\)

4. 実証的評価とベンチマークデータの解釈

エージェントの性能を正しく評価するためには、基盤モデル単体の能力だけでなく、「モデルと実行ハーネスの組み合わせ」としてスコアを解釈する必要があります。近年の実証データは、モデルの潜在能力を実際のタスク完遂力に変換する上で、ハーネス設計が極めて重要であることを示しています。

同一モデルにおけるハーネスの差

コマンドライン環境での操作を評価するベンチマーク「Terminal-Bench 2.0」のデータを見ると、この事実が明確に浮かび上がります。同じ基盤モデル（例: Gemini 3.1 ProやClaude Opus 4.6など）を使用した場合でも、組み合わせるハーネスを変えるだけで、タスク成功率に10%〜20%以上のブレが生じています。これは、適切なコマンドインターフェースの提供や、過去の実行状態を管理する仕組みといったハーネスの設計が、モデルの持つ推論能力をうまく引き出すために不可欠であることを示唆しています。

成功率以外のリソース指標

一方で、高い成功率を誇るハーネスが、必ずしも低コストで高効率であるとは限りません。実証データによれば、スコアを伸ばすために膨大な入力トークン（コンテキスト）を消費したり、タイムアウト率（Timeout Rate）を犠牲にしたりしているケースも存在します。たとえば、Claude Opus 4.6の検証において、あるハーネス（Meta-Harness）はタイムアウト率を低下させることに成功した一方で、別のハーネス（Terminus 2）と比較して約10倍もの入力トークンを消費していました。つまり、実運用においては単なるタスク成功率だけでなく、実行時間やコストのトレードオフも考慮してハーネスを選定する必要があります。

ソフトウェア環境でのハーネス思想比較

ソフトウェア開発環境を評価する「SWE-bench」では、アプローチの異なる様々なハーネスが提案されています。以下の表は、代表的な3つのハーネスの設計思想とその長所・短所を比較したものです。タスクの性質に合わせて、どの程度の自律性や制御の仕組みを持たせるかが鍵となります。

ハーネス	実行のループ形式	長所	短所
Agentless	固定パイプライン（バグの特定・修正・検証を段階的に実施）	動作が安定しており、低コストで再現性が高い	探索的なデバッグなど、柔軟な軌道修正が難しい
SWE-agent	ReAct型ループ（シェルやエディタを用いて対話的に試行錯誤を実施）	シンプルで汎用性が高い	長期間のデバッグになると動作が不安定になり、トークンコストも増加しやすい
OpenHands	汎用エージェント（ブラウザやファイル操作など幅広い環境を提供）	様々なコーディングタスクに柔軟に対応できる	モデルに与える選択肢（アクション）が多く、制御・管理のコストが高い

Web環境におけるハーネスの重要性

ブラウザ操作などを評価するWeb環境（WebArena）においては、ハーネスの設計がさらに決定的な意味を持ちます。この環境では、モデル単体での実行スコアと、Web操作に特化したハーネス（Web-Operatorなど）を使用した場合のスコアとの間に、最大で約40%（GPT-4oの例）という巨大なギャップが確認されています。

Web環境では、複雑な画面構造（DOM）の視覚的な理解や、Webページをまたいだ状態の追跡が求められます。そのため、単に推論力が高いモデルを使うだけではなく、生の画面情報をモデルが処理しやすい形式に変換（グラウンディング）し、安全なアクションへと導く「特化型ハーネス」の存在が、システム全体の成否を大きく左右するのです。

おわりに

最新のエージェントの性能は、基盤モデル単体の能力ではなく、モデルと実行ハーネスの相互作用によって決定されます。これからのエンジニアは、単なるプロンプトの調整から脱却し、状態管理やエラー検証、アクションの抽象化といった「システム全体の設計」に注力する必要があります。

また実運用においては、「タスク成功率（\(P_\text{succ}\)）」だけの評価から脱却しなければなりません。コスト（\(C\)）、レイテンシ（\(L\)）、リスク（\(R\)）といった制約を組み込み、「価値を意識した最適化（Value-Aware Optimization）」を進めることが求められます。

将来的には、実行トレース（\(E_t\)）を活用し、モデルとハーネスが共に進化していく時代へと向かいます。この自己進化ループは次のように表されます。

$$(\theta_{t+1}, \phi_{t+1}) = \text{VerifyRetain}(U(\theta_t, \phi_t, E_t))$$

モデル自体が検証やエラー回復の能力を内製化し、ハーネスと継続的に「共進化」していくエコシステムが、次世代エージェントの核心となります。

More Information

• arXiv:2606.20683, Jianyuan Guo et al., 「From Question Answering to Task Completion: A Survey on Agent System and Harness Design」, https://arxiv.org/abs/2606.20683