「このプログラムの不具合を直して」とAIに頼むと、修正案だけが返ってくる場合と、ファイルを書き換えてテストまで進む場合がある。違いを生むのはモデルの賢さだけではなく、その出力を実際の操作へつなぎ、結果を受け取って次の判断へ戻す「ハーネス」という周辺の仕組みだ。「Agent = Model + Harness」という式は、回答を作る能力と、仕事を進める実行基盤の組み合わせを表している。ソフトウェアの試験環境に使われてきた言葉が、なぜAIエージェントにも使われるようになったのかをたどると、任せた仕事が本当に終わったかを判断する手がかりも見えてくる。
モデルの答えを、外の世界の操作へ
Agent = Model + Harness。日本語にすれば、「エージェント＝モデル＋モデルを動かす周辺の仕組み」である。LangChainのVivek Trivedyは、ハーネスをモデル以外のコード、設定、実行ロジックと定義している。ツールを呼び出す処理や会話履歴の管理に加え、処理を続けるか止めるかを決める仕組みも含まれる。LangChainの定義
モデルは与えられた情報から、文章やコード、次の操作案を生成する。しかし「このファイルを開く」という操作要求を出すことと、コンピューター上のファイルが開かれることは別だ。ハーネスはその要求を受け、対応する道具を実行し、読み取った内容やエラーをモデルへ渡す。モデルは届いた結果を踏まえて、次の操作を選ぶ。
したがって「ハーネスがなければ質問に答えるだけ」とは、モデル単体の出力が、そのまま外の世界への操作にはならないという意味だ。要約や計画を作れないという意味ではない。また、普段のチャット製品にも履歴を保持する周辺ソフトウェアがある。画面がチャット形式かどうかより、応答の先に実行と結果の受け渡しがあるかを見た方が分かりやすい。
式の「＋」は、部品を組み合わせれば必ず仕事が成功するという保証でもない。理解や判断を受け持つモデルと、その判断を実行可能にする仕組みの役割分担を示している。
バグ修正を最後まで進める仕組み
たとえば、表形式のデータを保存したCSVファイルを読み込むプログラムが、空欄を含む行で止まるとしよう。「空欄でも処理できるように直して」という依頼に対し、モデルへコードを貼り付ければ、修正案を得られるかもしれない。だが、その案をファイルへ反映し、動作を確かめる仕事は残る。
実行用のハーネスを備えたエージェントなら、許可された道具でコードとエラー記録を読み、モデルが作った修正を適用できる。続けてテストを動かし、「別の行でまだ失敗する」という結果が返れば、その情報をモデルの次の入力へ加える。モデルは原因を考え直し、再び修正を提案する。ここで起きているのは、回答の生成を、実行して確かめる往復へつなぐ処理だ。
Jianyuan Guoらのサーベイ論文『From Question Answering to Task Completion』は、実行ハーネスの仕事を次の六つに分けている。arXivで公開されたプレプリントによる整理であり、すべての製品が同じ六つの部品を持つという規格ではない
| ハーネスの役割 | バグ修正の例で担うこと |
|---|---|
| 観測 | ファイル内容やエラーを、モデルが読める情報として受け取る |
| コンテキスト管理 | 今の判断に必要なコードや履歴を選んで入力する |
| 制御ループ | 次の処理へ進む、再試行する、停止する手順を管理する |
| 操作 | ファイル編集やテスト実行の要求を道具へ渡す |
| 状態と成果物の保存 | 変更済みのファイルや未完了の作業を残す |
| 検証と統制 | 結果を確認し、権限や予算の範囲で処理を進める |
この分担で見ると、「修正案は正しそうなのに仕事が終わらない」理由も切り分けられる。古いコードを渡していれば入力の問題であり、編集要求が実行されていなければ操作の問題だ。失敗したテスト結果を渡さず同じ依頼を繰り返しても、モデルはどこを直し直せばよいか分からない。
長い作業では、途中の記録も結果を左右する。Anthropicは、最初に環境を整える担当と、その後に少しずつ実装する担当を分け、進捗ファイルと変更履歴を残す方法を報告した。次の処理が始まったとき、何が完成し、何が残っているかを読み直せるようにするためだ。会話を短く圧縮するだけでは、この引き継ぎは十分にならなかったという。
テストハーネスから、仕事を動かす基盤へ
ソフトウェア開発でいうテストハーネスは、試したいプログラムを一定の条件で動かし、結果を調べるための仕組みである。たとえば外部サービスの代わりに決まった応答を返す部品を用意し、テスト対象へ入力を渡して、期待どおり動くかを確かめる。テスト項目の集まりと、それを動かす設備は区別される。
OracleのJavaTestの文書でも、テスト群と、それらを実行・管理するハーネスを別の要素として説明している。対象のプログラムへ環境を与え、実行を制御し、挙動を観察する。この発想は、LLMを使うエージェントより前からあった。
機械学習でも、共通の課題をモデルへ与えて成績を測る「評価ハーネス」が使われる。EleutherAIのLanguage Model Evaluation Harnessは、その具体例だ。モデルを交換しても共通の枠組みで評価できるようにする。
Sanderson Oliveira de Macedoは、用語を検討したプレプリントで、馬具を意味するハーネスから、ソフトウェアのテスト用、機械学習の評価用、エージェントの実行用へと意味が広がった経緯を整理している。共通するのは、対象を周囲の環境へ接続し、動きを制御して観察する役割である。
| 用途 | 主な目的 | 結果の使い方 |
|---|---|---|
| テストハーネス | プログラムが条件どおり動くか試す | 不具合や合否を確認する |
| 評価ハーネス | モデルやエージェントの能力を測る | 課題ごとの成績を集め、比較する |
| エージェント・ハーネス | モデルを使って仕事を進める | 結果を次の判断へ戻し、修正や停止につなぐ |
表は、それぞれが何のために動くかを比較したものだ。テスト用の基盤も実行中に働くし、エージェントの実行基盤がテスト用の基盤を呼び出すこともある。「検査」と「仕事の進行」は組み合わせられる。
つまりAIへの転用は、既存のテストソフトをそのまま付け替えたという話ではない。対象を囲んで制御・観測するという考え方を、モデルが道具を使い続ける仕組み全体へ広げたものと捉えると、両者の関係を理解しやすい。
仕組みが先にあり、名前が広まった
推論と操作を往復させる研究は、「ハーネス・エンジニアリング」が話題になる以前から進んでいた。Shunyu Yaoらが2022年に初稿を公開したReActは、考える過程と行動を交互に組み合わせ、外部から得た情報で計画を更新する方式を示した。後のハーネスが管理する反復処理につながる考え方である。
2023年の英国政府報告書には、モデルの外側に「足場となるソフトウェア」を置く説明がある。モデルに大きな目標から計画を作らせ、ブラウザーなどの道具で各段階を実行させる。報告書は、このソフトウェアとモデルを組み合わせたシステムをAIエージェントと呼んでいる。式と同じ役割分担は、すでに言葉で表されていた。
ハーネスという呼称も、2026年に突然現れたわけではない。Anthropicの前述の実装報告は2025年11月26日に公開され、エージェント用の開発基盤を「汎用のエージェント・ハーネス」と説明していた。
2026年2月5日には、Mitchell Hashimotoが自身のAI活用を振り返り、失敗を見つけたら環境側を直す実践を「ハーネス・エンジニアリング」と呼んだ。たとえば、エージェントが読む作業指示を更新し、テストや画面の確認を行える道具を用意する。毎回同じ注意を人間が伝える負担を、再利用できる手順や検査へ置き換える発想だ。
同年3月10日のLangChainの記事は、「Agent = Model + Harness」を前面に出し、周辺機構を設計する仕事として説明した。ただし、これらは呼称の使用を確認できる記録であって、最初の発明者を確定する証拠ではない。モデルの外に道具と制御を置く実践が先にあり、その全体を設計・改善する対象として名前が共有されていった、と考えるのが自然だ。
「できました」を何で確かめるか
テストが全部通っても、依頼どおりに直ったとは限らない。CSVの空欄を読み飛ばす修正と、空欄を残して処理する修正は、どちらもプログラムを止めずに済む。しかし利用者が求めたのが後者なら、前者はデータを失う誤修正になる。モデルが同じ誤解から修正とテストを作れば、誤った処理のまま合格することもある。
Birgitta Böckelerは、行動前に方向を与える指示と、行動後に結果を知らせる検査を区別している。AIが生成したテストへの過信にも注意を促す。ハーネスには、モデルへ「正しく直して」と頼むほかに、何を正しいとするかを外から確かめる仕組みが必要になる。
実際の改善では、どこで失敗したかによって手を入れる場所が変わる。空欄の扱いが曖昧なら、指示を具体化する。必要な仕様が渡っていなければ、モデルが参照する情報、すなわちコンテキストを見直す。編集やテストが動かなかったなら、実行環境や権限を確かめる。ハーネスは、これらを仕事の流れとしてつなぐ設計対象になる。
「終わるまで続ける」だけでも不十分だ。失敗が続けば停止でき、許可の必要な操作では人へ判断を戻せるようにする。成果物と検証記録を残すことも含めて、どこまで任せるかを決める必要がある。
CSVの修正を任せるなら、「空欄を含む行も失わず処理する」という期待を先に決め、その条件を試した記録と実際の出力を確かめたい。期待する状態を明示し、結果を測って修正へ戻す経路を用意することで、説明を受け取る仕事から、確認できる成果を任せる仕事へ進める。
