ハーネスエンジニアリングとは、AI モデルを取り巻く「ハーネス」— 素のモデルを機能するエージェントへと変えるプロンプト、ツール、コンテキストポリシー、フック、サンドボックス、サブエージェント、フィードバックループ、復旧経路 — を設計し保守する分野である。Addy Osmani の投稿が Viv Trivedy に帰する定式化では、これは「エージェント = モデル + ハーネス」と要約される。モデルは入力の 1 つにすぎず、ハーネスはそれ以外のすべて、つまりモデルに状態、ツールの実行、フィードバックループ、強制可能な制約を与えるものである。
エージェントのガバナンスに関する Anthropic の投稿 信頼できるエージェントの実践（2026 年 4 月 9 日）は、同じ領域を 2 つではなく 4 つに分割し、ハーネスをその 4 つのうちの 1 つとして挙げる。この説明では、エージェントは次のものから構成される。モデル（タスクを可能にする知能であり、訓練によって形づくられる）、ハーネス（モデルが従う指示とガードレール — その例として、一定額を超えるものはすべてフラグを立てるようエージェントに指示することや、ユーザーの確認なしに経費を提出しないよう指示することが挙げられている）、ツール（モデルが利用できるサービスやアプリケーション）、そして環境（エージェントが動作する場所と、そこから到達できるファイル、ウェブサイト、システム。同じエージェントでも、社内ネットワーク内の会社のノート PC 上で動く場合と個人のスマートフォン上で動く場合とでは、データへのアクセスも懸かっているものも異なる）。いずれも、能力の源であると同時に監督の潜在的なポイントでもあると説明されている。
この 4 分割は「エージェント = モデル + ハーネス」と対立するものというより、その第 2 項を分解したものであり、そこに添えられた議論は注意をどこに向けるかについてのものである。この投稿は、AI ポリシーをめぐる議論の大半がモデルを中心に据えていること、中核的な能力がそこから生まれる以上それは理解できることを認めたうえで、よく訓練されたモデルであっても、設定の不十分なハーネス、過度に寛容なツール、あるいは露出した環境を通じて悪用されうると指摘する。上の定式化と併せて読むと、これは振る舞いの側からではなくセキュリティの側から述べられた、ハーネスエンジニアリングのための論拠である。
用法
この用語は、Claude Code、Cursor、Codex、Aider、Cline といったコーディングエージェントに適用される。Addy Osmani の投稿は、これらのエージェントからユーザーが体験する振る舞いは、根底にあるモデルが同じ場合でさえハーネスが何をするかによって大きく左右されると論じ、並べてみるとそれらは根底にあるモデル同士よりも互いに似て見える — モデルは異なるがハーネスのパターンは収束している — と観察している。この実践が扱う具体的な構成要素には、永続的な状態のためのファイルシステムと Git、汎用的な行動手段としての bash とコード実行、安全な実行のためのサンドボックス、セッションをまたいだ継続的な学習のためのメモリファイル（例：AGENTS.md）、コンテキストロットを緩和する技法（コンパクション、ツール呼び出しのオフロード、スキルの段階的開示）、長期的な実行のパターン（Ralph Loop、計画、プランナーと評価者の分離）、そしてモデルに覚えておいてもらうことに頼るのではなく、ルールを決定論的に強制するフックが含まれる。
中国語の公開チュートリアル self-harness は、同じ 3 つの用語を対比ではなく発展の順序として捉え、その順序を自らの中心的なテーゼとしている。まずプロンプトエンジニアリング、次に動的な情報管理としての コンテキストエンジニアリング、そして最後にシステムレベルのハーネスエンジニアリングである。その理論のセクションは、この分野がなぜ段階的にハーネスエンジニアリングへと進化するのかを扱うものとされ、3 者の進化に 1 章が充てられている。その主張が実際にどこまで論証されているかは、ここで保持している資料 — 各章ではなくリポジトリ自体の概要 — からは見えない。また、このチュートリアルには内容に誤りや欠落が含まれうるというアルファ版の注記が付されている。付随する実装である miniMaster は、ロールごとのメモリを別々に保持する、プランナー／実行者／検証者の 3 層ループを中心にハーネスを構築している。
ハーネスの評価
同じ分野について書いている Google のエンジニアリングチームは、ハーネスをどう評価するかはハーネスのエンジニアリングの一部であると論じる。彼らは、エンドツーエンドのベンチマークをモデルの性能を評価し、何をより深く調査すべきかを決めるための事実上の標準的手段として扱う一方で、反復のための道具としては不向きだと論じる。彼らの説明では、Terminal-Bench や DeepSWE のようなスイートを実行すると複合スコアが数パーセントポイント動くが、それがなぜ変化したのかは通常直接には分からない。彼らが提案する補完手段は 振る舞い評価 — エージェントが取る個別の観測可能な行動（どのツールを呼び出したか、どのファイルを変更したかなど）に対する、高速で決定論的な単体テスト風のアサーション — であり、彼らはこれをハーネスの動作に対する統合テストとして、またプロンプトの微調整、ツールスキーマの変更、モデルのアップグレードがエージェントを全体として悪化させたかどうかを示す反復のパートナーとして説明している。
彼らは評価を時間軸の上にも位置づける。エージェントを立ち上げ始めたチームは開発者の直感とドッグフーディングから始めるものであり、エージェントが自身のコードベースをドッグフーディングできるようになるまでは、そもそも評価を実行することに意味はないと彼らは論じる。彼らの結論は、2 種類の評価は互いに代替するものではなく補完し合うものであり、マクロなベンチマークが最終的な到達点を検証し、ミクロな振る舞い評価が安全で迅速な反復を可能にする、というものである。これは 1 つのチームが雇用主の開発者ブログで公開した推奨プラクティスであり、測定された比較ではない。
エージェント型エンジニアリングのパターン のある章は、「ハーネス」という語が何を指すのかについて最も平明な説明を与えている。コーディングエージェントとは言語モデルのためのハーネスそのものであり、ユーザーが目にすることのないプロンプトによって駆動され、呼び出し可能なツールとして実装された追加の能力でモデルを拡張するソフトウェアである。そう読むと、ハーネスは製品の周りに巻き付けられた層ではなく、製品を単なるテキスト補完エンドポイント以外のものにしているものそのものである。この章による構成要素の一覧もそれに応じて最小限である — ハーネスが組み立てて再生するチャットテンプレート形式のプロンプト、ハーネスが提供するツール定義、ハーネスが隠すシステムプロンプト、そしてハーネスが回すループ — そしてその控えめな結論は、単純なツールループは数十行で書けるが、良いツールループははるかに多くの作業を要する、というものである。AI コーディングエージェント を参照。
長時間稼働エージェントのための効果的なハーネス は、コンテキストウィンドウでは足りなくなる時間スケールでのハーネスエンジニアリングの実例であり、その教訓は状態をどこに置くべきかに関するものである。Anthropic は、汎用のハーネス上のフロンティアモデルは、コンパクションが利用可能であっても、高レベルのプロンプトから本番品質のアプリケーションを構築することにはやはり失敗すると報告している。そのため、そこで述べられているハーネスの作業はモデルのループの中にはまったくなく、その周囲の成果物にある。すなわち、起動スクリプト、進捗ログ、Git の履歴、そして イニシャライザーエージェント が一度だけ書き出す構造化された機能リストである。また、早すぎる完了に対するプロンプトレベルの対処も報告されている — エージェント自身の申告で機能を合格とするのではなく、ユーザーがするのと同じようにブラウザ自動化を通じてエンドツーエンドで機能を検証するよう指示するもの — であり、明示的にプロンプトで指示すればおおむね機能すると説明されている。
同じエンジニアリングチームによる後の投稿 長時間稼働するアプリケーション開発のためのハーネス設計 は、作業を行うエージェントとそれを評価するエージェントを分離すること自体を、ハーネスのレバーの 1 つとしている。その理由として述べられているのは、自分の出力を評価するよう求められたエージェントは、品質が明らかに凡庸な場合でも自信をもってそれを称賛しがちだということである。これは、ソフトウェアのテストに相当する二値的なチェックが存在しないデザインのような主観的なタスクで最も顕著だが、検証可能な結果を持つタスクでも見られる。分離によってその甘さが解消されるとは述べられていない。評価者もやはり LLM であり、LLM が生成した出力に寛大になりがちだからである。論点は、独立した評価者を懐疑的になるよう調整するほうが、生成者に自分の作業を批判的に見させるよりもはるかに扱いやすく、ひとたびそうした外部からのフィードバックが存在すれば、生成者はそれに対して反復するための具体的な手がかりを得られる、というものである。同じ投稿は、この調整を設定の一手順ではなく本物の作業として報告している。そのままの状態では Claude は QA エージェントとして不出来だったと述べられており、正当な問題を特定しておきながら、結局は自分を説得して作業を承認してしまう様子や、エッジケースを探るのではなく表面的にしかテストしない様子が観察されたという。
この説明はまた、評価者の価値を確定したものではなく条件付きのものとして扱っている。基盤となるモデルが改善するにつれ、以前は評価者のチェックを必要としていたタスクが生成者だけで確実にこなせる範囲に入り、そうしたタスクについては評価者は不要なオーバーヘッドとなった。この投稿が引き出すルールは、タスクが現行モデルの単独で確実にこなせる範囲を超えているときに、評価者はそのコストに見合う、というものである。
LLM エージェントにおける外部化：メモリ、スキル、プロトコル、ハーネスエンジニアリングの統一的レビュー は、この用語に実務家の視点ではなく定義的な枠組みを与え、「モデルの周りのすべて」よりもさらに踏み込んでいる。その説明では、ハーネスは有能なモデルの上に重ねられた実装上の便宜ではなく、外部化されたモジュールが一体となって有効に機能するための設計された認知環境である。このレビューは、エージェンシーはモデル単体の中に位置するのではなく、モデルと、その認知を行動へと組織化する環境との結合から創発すると論じる。同時に、この概念はまだ固まりつつある段階であることに注意を払い、自らの特徴づけを閉じた定義ではなく、現行のシステムに繰り返し現れるパターンの統合として提示している。
このレビューは、ハーネスの設計を 6 つの繰り返し現れる分析次元に分解し、それらを Permission（パーミッション）、Control（制御）、Observability（可観測性）と呼ぶ 3 つの運用面のもとにまとめている。これらは実装のチェックリストとしてではなく、ハーネスのアーキテクチャを比較するための枠組みとして提示されており、6 つのいずれもそれ自体は 外部化 の一形態ではない — それらは、メモリ、スキル、プロトコルを 1 つのシステムとして機能させる調整のためのインフラである。
- エージェントループと制御フロー — 時間的な骨格であり、終了、再帰、リソース消費に対するガバナンスを伴う。このレビューは、ステップ数、再帰の深さの上限、コストの上限、タイムアウトは副次的な安全対策ではなく、推論が展開される運用上の範囲を規定するものだと論じる。よく調整されたループがエージェントの信頼性を高めるのは、モデルを賢くすることによってではなく、ありうる実行経路の空間を制限することによってである。
- サンドボックス化と実行の分離 — このレビューはこれを単なるセキュリティの柵ではなく認知的な境界として読む。無関係な状態を取り除き、危険な行動を制限することで、モデルが推論しなければならない対象が変わるからである。
- 人間による監督と承認ゲート — 一般的なパターンとして、実行前の承認、実行後のレビュー、そしてリスクのシグナルが検出されるまではエージェントを自律的に動かすエスカレーションのトリガーの 3 つがある。この説明では、自律性はエージェントの二値的な性質ではなくハーネスの設定可能なパラメータであり、タスクごと、ツールごと、組織のポリシーごとに調整できる。
- 可観測性と構造化されたフィードバック — レビューはこれを、ハーネスが自らの動作から学習するための仕組みと呼ぶ。構造化されたトレースがなければ、実行結果をそれを生み出したモジュールへとつなぎ戻すループが機能せず、ハーネスは適応的なシステムではなく静的な足場にとどまるからである。
- 設定、パーミッション、ポリシーのエンコード — 外部化されたガバナンスとして説明される。本来ならプロンプトや事後的なフィルタリングに置かれるはずの制約が、ハーネスが実行時に強制する宣言的なルールとしてエンコードされ、ユーザー、プロジェクト、組織のスコープにわたって階層化されるため、同じベースのエージェントを、モデルやそのスキルの成果物を変えることなく異なるポリシー体制のもとで動かすことができる。
- コンテキスト予算の管理 — 単一のモジュールでは解決できない調整の問題として扱われる。メモリの検索、スキルの読み込み、プロトコルのスキーマ、ツールの説明、そしてモデル自身の推論トレースが同じ有限の割り当てを奪い合い、適切な配分は実行のフェーズによって変わるからである。
このレビューはまた、系譜の異なる製品のあいだで構造的に似たハーネスが収束していることを、分析上重要なものとして読む。それは、これらの次元が偶発的な実装上の選択ではなく、外部化されたエージェンシーの構造的な要件であることの証拠だと論じている。
エージェント型ハーネスエンジニアリング
エージェントハーネスとしてのコード：実行可能・検証可能・ステートフルなエージェントシステムに向けて は、この分野に Agentic Harness Engineering（エージェント型ハーネスエンジニアリング）という独自の名前を与え、隣接する 2 つの分野との対比によってそれを定義する。プロンプトエンジニアリングが指示を変え、コンテキストエンジニアリングがモデルに提示される証拠を変えるのに対し、エージェント型ハーネスエンジニアリングは運用環境そのものを分析の対象として扱う。このサーベイによるその環境の一覧もそれに応じて幅広く、ツールスキーマ、計画の成果物、メモリポリシー、検索戦略、サンドボックスの設定、検証センサー、パーミッションの階層、ルーティングルール、マルチエージェントのワークフロー、人間によるレビューのゲートが挙げられている。これが分析の単位として正しい理由についての論証は診断的なものである。コードエージェントで観察される失敗の多くは、モデルの生成からではなく、リポジトリのコンテキストの欠如、脆いツールインターフェース、弱い検証器、過剰なトークンコスト、不十分なリトライポリシー、あるいは噛み合わないパーミッションの境界から生じる、というのである。
このサーベイは既存の研究を 3 つの相補的な流れとして読む。コードハーネスの自動合成、ハーネスの設計をモデルに面したインフラに対する最適化問題として定式化すること、そしてエージェントのループがどこで失敗し、どの構成要素を変えるべきかを可観測性に基づいて診断することである。
その 3 つすべての基盤として挙げられているのがディープテレメトリー — モデルの判断、ハーネスの行動、環境の状態、結果をつなぐ構造化されたトレース — である。対比されているのは、最終的な回答や合否の結果だけを記録する浅いログである。ディープテレメトリーは、プロンプトと取得されたコンテキスト、トークン使用量とコスト、モデルとツールのレイテンシ、ツールの引数、パーミッションの要求、編集されたファイル、サンドボックスのスナップショット、コマンドの出力、テスト結果、スタックトレース、lint の警告、分岐の判断、却下された代替案、人間による介入、そして最終的なタスクの結果を記録する。サーベイの説明によれば、これによって得られるのは、ハーネスの改訂が場当たり的なデバッグではなく比較による診断になることである。シグナルが具体的な成果物に結び付けられているため、ハーネスのバージョン間で再生して比較できるのである。
このサーベイは、そのテレメトリーに基づいて動作するメタレベルのエージェントとして Evolution Agent を提案する。対象のリポジトリを編集するタスクエージェントとは異なり、Evolution Agent は後続のタスクエージェントが作業する際の運用条件を編集する。その出力は、改訂されたプロンプトテンプレート、検索ポリシー、より精密なツールスキーマ、追加された検証器、変更されたパーミッションルール、ワークフローのトポロジーの調整、あるいは新しい回帰テストでありうる。そのループは 5 つの段階からなる。軌跡を観察する、コスト、レイテンシ、無効な行動、テストの失敗、パーミッションの拒否を特定の構成要素に帰属させることで失敗モードを診断する、改訂の候補を提案する、改訂されたハーネスを保留されたタスクや再生されたトレースで評価する、そして以前に解決されたケースで後退することなく信頼性、コスト、安全性を改善する変更だけを昇格させる、というものである。
このサーベイは、これを無制約な自己改変と混同してはならないと明言し、統制されたハーネスの変異を主張する。すなわち、変更の候補はサンドボックスの中で評価され、固定された回帰スイートと比較され、監査可能な根拠とともに記録される。そして、パーミッションの境界、ネットワークアクセス、認証情報の扱い、デプロイの振る舞い、人間によるレビューの要件を変える変更は、有効化する前に人間の承認を必要とする。その枠組みでは、Evolution Agent 自身も、それが統制するエージェントと同じ Plan–Execute–Verify ループ に従う。
未解決の問題として、このサーベイはより難しい問いを率直に述べている。ハーネスの自動的な進化そのものが難しいのではなく、ハーネスが過学習すること、安全性を弱めること、コストを増やすこと、失敗を隠すこと、あるいはまれだが重要なタスクで後退することなく自らを改善できるかどうかが難しいのだ、と。提案されている規律は、ハーネスのあらゆる変異を安全性が決定的に重要なランタイムに対するコード変更のように扱い、変更契約を添えることである。その契約には、どの構成要素を変更するのか、どの失敗モードを対象とするのか、どのような改善を予測するのか、どの不変条件を保たなければならないのか、どの評価がそれを反証しうるのか、そしてどのようにロールバックできるのかを記す。これがなぜ重要なのかについて挙げられている例は、いずれもある指標が改善する一方で別の何かが悪化するケースである。ベンチマークの精度を上げる一方で幻覚による証拠を増やす新しい検索ポリシー、トークンコストを減らす一方でパーミッションの境界を弱める新しいツールスキーマ、仕様が不十分な解を受け入れることで合格率を上げる新しい検証器、といったものである。
適用される場面
この実践は、エージェントの誤りを孤立した出来事ではなく恒久的なシグナルとして扱う。観察された特定の失敗はルール、フック、あるいはチェックとしてエンコードされ、ルールが取り除かれるのは、より有能なモデルがそれを不要にしたときに限られる。そのためハーネスは、既製品としてダウンロードできるものではなく、自らの失敗の履歴によって形づくられるものだと説明される。この実践は、エージェントが複数のステップにわたってある程度自律的に作業することが期待される場面に適用される。Osmani の投稿は、Anthropic 自身の記事に帰している論点として、この考え方の過剰な適用の仕方も述べている。それは、モデルの改善に合わせて見直すのではなくハーネスの構成要素を恒久的なものとして扱うことであり、かつてモデルの限界を補っていた構成要素も、その限界がなくなれば無用の重荷になりうるからである。
Anthropic は 長時間稼働するアプリケーション開発のためのハーネス設計 でこの立場を直接、しかも注意喚起としてではなく一般原則として述べている。ハーネスのあらゆる構成要素は、モデルが単独ではできないことについての仮定をエンコードしており、そうした仮定は誤っている可能性があるうえ、モデルが改善するにつれてすぐに古びうるため、ストレステストに値する、というものである。この投稿が報告している 2 つの削除は、異なる経緯をたどった。コンテキストリセット は、この技法が補っていた コンテキスト不安 の振る舞いを Opus 4.5 がおおむね解消したため、新しいハーネスには最初から含められなかった。ビルドをスプリント単位に分解する仕組みは、後になって意図的に取り除かれた。ハーネスを一気に大幅に削ろうとした最初の試みが元の性能を再現できず、どの部分が重要な役割を担っていたのかを見分けるのも難しくなったため、著者は構成要素を 1 つずつ取り除いてそれぞれの影響を確認するやり方に切り替え、スプリントの構成はその方法で最初に取り除かれたものだった。この投稿は、根底にある考え方として Anthropic 自身の 効果的なエージェントの構築 から「可能な限り最も単純な解決策を見つけ、必要なときにのみ複雑さを増やす」という一節を引用し、興味深いハーネスの組み合わせの空間はモデルが改善しても縮小するのではなく移動するのだ、という立場で締めくくっている。
この用語とその「エージェント = モデル + ハーネス」という定式化は、Osmani の投稿によって Viv Trivedy に帰されており、同投稿はハーネスとは何か、そして各部分がなぜ存在するのかを最も明快に導き出したものとして Trivedy 自身の記事を挙げている。同投稿はまた、Dex Horthy、HumanLayer、Anthropic 自身のエンジニアリングチーム、Birgitta Böckeler にも依拠しており、自らをそれらの糸を 1 つにまとめる試みだと位置づけている。
関連用語
Ralph Loop、Harness-as-a-Service、コンテキストロット、コンパクション、AGENTS.md、振る舞い評価、イニシャライザーエージェント、AI コーディングエージェント、コンテキストリセット、コンテキスト不安、ガードレール、外部化、エージェントスキャフォールド、エージェントハーネス、Plan–Execute–Verify ループ