LLM（大規模言語モデル）を自律的なAIエージェントとして動作させる際、モデル単体の力だけでは不十分です。モデルが自律的に推論し、ツールを呼び出し、環境に作用するためには、その周囲を取り囲むインフラストラクチャの構築が不可欠になります。

現在、ソフトウェア工学の分野において、この周辺レイヤーはしばしば「ハーネス」と呼ばれています。しかし、その使われ方は非常に曖昧です。たとえば、エージェントを開発するためのSDK（ソフトウェア開発キット）や、システムの性能を測定する評価フレームワークなど、様々な周辺技術と混同して語られることが少なくありません。

この記事では、最近の研究に基づき、AIエージェントを制御する「エージェント・ハーネス」の厳密な定義とその構成要件を解説します。

1. コンセプトの起源と歴史的背景

「ハーネス（Harness）」という言葉の由来を紐解くと、なぜこの用語がAIのインフラストラクチャに使われるようになったのかが直感的に理解できます。

英語の「Harness」は、荷馬車を引く馬に取り付ける「馬具（tack）」を語源としています。この概念をAIシステムのアナロジーとして当てはめてみましょう。強力な力を持つものの、放っておくと見境なく暴走してしまう「馬」が言語モデル（LLM）に相当します。そして、目的となる「荷車」が達成すべきタスクです。馬の無軌道な力を制御し、安全に荷車を引かせるための「馬具」こそが、AIシステムにおけるエンジニアリング層、すなわち「エージェント・ハーネス」に該当します。

これまでソフトウェア工学の世界では、この言葉は「テストハーネス」として広く定着してきました。また、機械学習の分野でも、モデルの性能を測定する「評価ハーネス（Eval Harness）」という用語が使われています。これら2つのハーネスに共通しているのは、システムが処理を終えた「事後」に、外部から結果を観察・測定する仕組みであるという点です。

一方で、この記事が扱う「エージェント・ハーネス」は、これらと根本的なパラダイムの違いがあります。AIエージェントは自律的にツールを呼び出したり、ファイルを書き換えたりと、環境に対して直接的に作用します。そのため、処理が終わってから結果を評価するだけでは不十分です。エージェント・ハーネスは、エージェントが行動を進めるのに合わせて「実行中（ランタイム）」に制御、制限、検証を実施します。

以下の表に、それぞれのハーネスの違いを整理しました。

用語	役割と対象	制御・観測のタイミング
テストハーネス	コードを制御・観測可能な状態で実行する	外部から事後に測定
評価（Eval）ハーネス	ベンチマーク課題を実行し、モデル性能を測定する	外部から事後に測定
エージェント・ハーネス	エージェントの行動を制御、制限、検証する	実行中（ランタイム）に内部から制御

2. ハーネスを定義する4つの必要十分条件とアーキテクチャ

あるシステムが「エージェント・ハーネス」として成立するためには、ランタイムにおいて4つのコア要素を兼ね備えている必要があります。このシステムの要件を厳密な論理式で表現すると、以下のようになります。

$$\text{System} = T_1 \land T_2 \land T_3 \land T_4$$

これは「4つの条件（T1〜T4）すべてを同時に満たさなければならない（論理積）」ということを意味します。いずれか一つでも欠けると、それはハーネスとは呼べません。それぞれの条件を具体的に見ていきましょう。

• T1. エージェントループ (Agent Loop)
  推論、行動、観察をランタイムで反復する適応型のループです。これを持たないシステムは自律的なエージェントではなく、プロンプトに対して一度だけ回答して停止する単なる「ジェネレーター（生成器）」に分類されます。
• T2. ツールインターフェース (Tool Interface)
  環境の単なる読み取りではなく、ファイルシステム等へ「変更・操作（alter）」を加える権限をモデルに提供します。この変更権限がなければ、モデルは外部環境に作用できず、自身のコンテキストウィンドウの枠内に閉じ込められたままになってしまいます。
• T3. コンテキスト管理 (Context Management)
  テキストがウィンドウサイズを超過した際に履歴を機械的に切り捨てるのではなく、タスクの内容や直近の観察に基づき「タスクを認識（Task-aware）」した上で、必要な情報を能動的に選択・管理する仕組みです。
• T4. 独立した制御メカニズム (Control Mechanism)
  実行の制御が、モデルの従順さ（プロンプトへの追従）に依存してはならず、独立的かつ決定的（deterministic）な処理でなければなりません。これは、エージェントが障害に直面した際、未完了のタスクを「成功した」と虚偽報告するような事態を確実に防ぐために不可欠です。

コア要素とオプション要素からなるアーキテクチャ

実際のアーキテクチャ設計においては、上記T1〜T4を必須の「コア要素（Core）」と位置づけます。その上で、システムが実際にどのような作業を実施したかを後から監査できる「可観測性（Observability）」、一時的なエラーをやり直す「再試行ロジック（Retry logic）」、セッションをまたいで情報を保持する「メモリ（Memory）」などを「オプション要素（Optional）」として組み込むことで、システムの堅牢性をさらに高めることができます。

「ガードレール」と「ハーネス」の明確な違い

ここで、よく混同されがちな「ガードレール」との違いを整理しておきましょう。ガードレールとは、トークン数の上限を設けたり破壊的なコマンドをブロックしたりと、エージェントの行動を「制限（Limit）」する役割を持ちます。つまり、ガードレールは先述した制御メカニズム（T4）の一部に過ぎません。

対して「ハーネス」は、コンテキストを管理して記憶を助け、再試行でエラーを乗り越えるなど、システム全体としてタスクの「実行を支援・可能にする（Enable/Help）」役割を持っています。ガードレールはハーネスの内側に存在しますが、ハーネスはガードレールという枠組みに収まるものではないという非対称性が、この2つを明確に分けています。

3. 周辺アーキテクチャとの明確な境界

前述した4つのコア要素（T1〜T4）は、システムがエージェント・ハーネスであるかどうかを判定するための厳密な基準となります。この基準を用いることで、エージェント開発において混同されがちな5つの概念との境界を、以下のように明確に切り分けることができます。

• エージェントフレームワーク（例: AutoGen, CrewAI）:
  複数のエージェントを構成し、役割を与えて協調させるための上位レイヤーです。推論と行動の適応的なループ（T1）や、環境を操作するツール（T2）は、下位で動く個々のエージェントのハーネスに属します。したがって、システム全体を統括するフレームワーク自体はハーネスではありません。
• エージェントSDK（ソフトウェア開発キット）:
  ツール呼び出しの仕組みや部品を提供する、いわば「原材料」です。開発者が自らコードを書いて実行時のループ（T1）を組み立てる必要があり、自律的に動作する「完成品」の状態で提供されているわけではないため、ハーネスからは除外されます。
• IDE（統合開発環境）のインライン補完プラグイン:
  開発者の入力に合わせて、カーソル位置からコードの続きを提案する機能です。コードの提案を行うだけで、システム自身が適応的なループ（T1）を回すことはありません。また、環境への自律的な変更（T2）や、独立した決定的制御（T4）も伴わないため、明確に区別されます。
• 評価用（Eval）ハーネス（例: SWE-bench）:
  モデルの性能を測定する評価スイートです。複数のテスト課題を順に回す外側のループは持っていますが、単一のタスク内で推論と行動を繰り返す「内側の適応的なループ（T1）」の実行は、評価対象のシステムに委ねています。実行の「事後」に外部から評価を下す役割にとどまるため、ランタイムで動作するエージェント・ハーネスとは異なります。
• オーケストレーター:
  複雑な処理を自動化する仕組みですが、事前に定められた固定のパイプライン（手順）に従って実行されます。直前の観察結果に基づいて次の行動を決める適応的なループ（T1）や、状況に応じて動的に情報を取捨選択するコンテキスト管理（T3）を欠いている点で、ハーネスとは異なります。

コンセプト	T1	T2	T3	T4	ハーネス（基準概念）との違い
エージェントハーネス	yes	yes	yes	yes	（基準となる概念）
エージェントフレームワーク	no	no*	no	no	複数のエージェントをまとめる仕組み。ループ処理・ツール・コンテキスト・制御はフレームワークではなく、調整対象のハーネス側に属する
エージェントSDK	no	yes	no	no	構成要素（ブロック）を提供するが、実行時にループを組み立てるわけではない
IDEプラグイン	no	no	no	no	カーソル位置からコードを提案するだけで、リポジトリを変更したりループを閉じたりはしない
評価ハーネス（Eval harness）	no	yes	no	no	コマンド実行やパッチ適用は行うが、観測しながらのループではなく、外側から実行後に評価するためT1を満たさない
オーケストレーター	no	yes	no	no	固定ステップを順番に実行するだけで、観測に基づく選択や適応的なループがない（T1とT3を満たさない）

4. 具体的なシステムへの適用

これまで解説してきた4つの必須要件（T1〜T4）は、単なる机上の空論ではありません。学術的に分析された代表的な6つのエージェント・ハーネス（Claude Code、Codex CLI、Aider、Cline、OpenHands、SWE-agent）は、いずれもこの要件を共通して満たしています。

しかしながら、これら6つのシステムを比較すると、設計思想に大きな違いがあることが分かります。すべてのシステムがコア要件を備えている一方で、特に「T4（独立した制御メカニズム）」の具体的な実装方法において、その個性が最も色濃く反映されています。実際のシステムがどのように要件を実装しているのか、具体的な違いを見ていきましょう。

• Aider:
  バージョン管理システム（Git）と深く統合されているのが特徴です。各実行ステップがコミットとして記録されるため、後から作業を監査しやすく、問題があれば変更を取り消す（ロールバックする）ことができます。これは、監査可能性と可逆性という形でT4（制御）を担保するアプローチです。
• OpenHands:
  安全に隔離された環境である「サンドボックス」内でエージェントを動作させます。この「決定論的な封じ込め（Deterministic containment）」により、モデル自身の意図やプロンプトへの追従性に関わらず、システムへの影響を防ぐ強力な制御（T4）を持っています。
• Cline:
  IDE（統合開発環境）の拡張機能として機能しつつ、コマンド実行などの機密性の高い操作の前に必ず人間の承認を求めるアプローチを採用しています。人間をシステムの一部に組み込む「Human-in-the-loop」によって制御（T4）を実現している点が特徴です。
• SWE-agent:
  制御（T4）ではなく、ツール（T2）の要件を具現化した代表例として注目すべきシステムです。エージェントがソフトウェア環境を効果的に認識し、変更を加えるための専用インターフェース「エージェント・コンピュータ・インターフェース（Agent-Computer Interface: ACI）」を実装しています。

なお、残るClaude CodeやCodex CLIも、破壊的な操作の前に確認を求める実行時のガードレールや、段階的な権限モードといった形で、独自の制御メカニズム（T4）を実装しています。

以上のように、必須となるコア要件は共通していても、開発者が「エージェントをどのように制御・支援するか」というアプローチの違いによって、システムの実装には様々なバリエーションが生まれています。

5. システム設計における4つの対立軸

実務でエージェント・ハーネスを設計・構築する際、開発者は以下の「4つの対立軸」に基づく決断を求められます。

• 軸1: 自律性 vs 制御 (Autonomy vs. Control)
  エージェントの自律性を高めれば処理速度は向上しますが、プロンプトインジェクションや予期せぬ動作などのセキュリティリスクが増大します。そのため、システムのどの部分に人間の承認や適切な監視を挟むかというトレードオフになります。
• 軸2: 広範 vs キュレーションされたコンテキスト (Broad vs. Curated Context)
  情報を漏らさないようリポジトリ全体をコンテキストに投入すると、「Lost in the middle（中間情報の欠落）」と呼ばれるモデルの性能劣化を招きやすくなります。一方で、RAG（検索拡張生成）やメモリ管理によって文脈を厳格に絞り込むには、計算コストや実装の手間がかかります。
• 軸3: 汎用 vs 特化 (Generalist vs. Specialized)
  幅広いタスクを処理できる汎用的なハーネスを目指すか、あるいは特定のビジネスロジックやドメインに特化した独自の検証器（Verifier）を組み込むかという設計の分かれ道です。
• 軸4: オープンな権限 vs 封じ込め (Open Permission vs. Containment)
  サンドボックスなどによる強力な封じ込め（Containment）は、安全性を担保する決定的な手段です。しかし、制限が強すぎると、正当なタスクの達成自体を阻害してしまう可能性があり、適切なバランスを探る必要があります。

おわりに

本記事では、AIエージェントの強力な力を制御し、安全な作業へと変換する「エージェント・ハーネス」の厳密な定義とその構成要件について解説しました。混同されがちな周辺技術との境界線を明確にすることで、開発プロセスにおいてどのレイヤーの課題に向き合っているのかを整理できたのではないでしょうか。

現在、言語モデル自体と、それを制御するハーネスとの間でレイヤーの分離が進んでいます。これにより、今後のLLMエンジニアリングにおける競争優位性は、単一の巨大で高価なモデルに依存することから、特定のタスクや課題に最適化された「堅牢なハーネス設計」へとシフトしていく可能性が高いと考えられています。

言語モデル単体の進化だけでは、真に信頼できる自律型システムは完成しません。本記事が、読者の皆様の堅牢なシステム設計の一助となれば幸いです。

More Information

• arXiv:2606.10106, Sanderson Oliveira de Macedo, 「What makes a harness a harness: necessary and sufficient conditions for an agent harness」, https://arxiv.org/abs/2606.10106