このウィキで「ハーネス」という語を使うページは、それが何を含むのかについて一致していない。各ページが異なる答えを出している問い自体は、述べるだけなら簡単である。ハーネスとは、正確には何なのか。モデルの周りにあるものすべてなのか、ユーザーがカスタマイズする設定面なのか、エージェント構築ソフトウェアのスタックの中の 1 つの層なのか、エージェントループを生かし続けるインフラなのか、エージェントを構成するいくつかのコンポーネントの 1 つなのか、それとも上や横に別のレベルを持つオーケストレーションの 1 つのレベルなのか。このページは、それぞれの答えを、その拠り所とともに並べて示す。どれか 1 つを選ぶことはしない。
広い答え: モデルでないものすべて
最も広い定義は、「エージェント = モデル + ハーネス」（Agent = Model + Harness）と「モデルでないなら、それはハーネスだ」（if you’re not the model, you’re the harness）という言い回しに凝縮されている。Vivek（Viv）Trivedy による LangChain の投稿 エージェントハーネスの解剖学 は、モデルそのものではないコード、設定、実行ロジックのすべてをハーネスに数える。すなわち、システムプロンプト、説明文を伴うツール・スキル・MCP サーバー、ファイルシステム・サンドボックス・ブラウザといった同梱のインフラ、サブエージェントの生成・ハンドオフ・モデルルーティングといったオーケストレーションロジック、そして決定論的な実行のためのフックやミドルウェアである。この説明では、生のモデルは、ハーネスが状態、ツール実行、フィードバックループ、強制可能な制約を与えるまではエージェントではない。Trivedy はこれを、自分の考えでは境界の引き方として最もすっきりしたものだとして提示している。
この定式化は広く流通している。Addy Osmani の エージェントハーネスエンジニアリング は、これを Viv Trivedy に帰したうえで繰り返し、プロンプト、ツール、コンテキストポリシー、フック、サンドボックス、サブエージェント、フィードバックループ、回復経路をハーネスとして挙げる。「ハーネスエンジニアリング」（Harness Engineering）とは何か？ は同じ式を引用し、ハーネスを制約メカニズム、フィードバックループ、自動テスト、ワークフロー制御、ドキュメント標準として示したうえで、著者の言い方ではエージェントのために設計されたオペレーティングシステムだとする。11 の本番コーディングエージェントのソースコード研究である ハーネスエンジニアリング：コーディングエージェントの解剖、アーキテクチャ、進化 ― 11 システムのソースコード研究 は、「エージェントとはモデルにハーネスを加えたものである」を出発点の定義とし、ハーネスを、ループ、ツール、コンテキスト、安全制御、オーケストレーション、拡張面を通じてモデルを世界に結びつけるランタイムとする。
ベンダーやプロジェクトのドキュメントも、この語を同じ広い意味で使っている。エージェントハーネス は、Anthropic のドキュメントが Claude Code を、ツールを提供しモデルが見るコンテキストを管理する、モデルの周りの層として説明し、その層こそが「エージェント型ハーネス」（agentic harness）の指すものだとしていることを記録している。OpenHarness の README は、ハーネスを LLM を包んで機能するエージェントにする完全なインフラと呼び、「モデルがエージェントである。コードがハーネスである。」（The model is the agent. The code is the harness.）という一文で締めくくる。OpenAI の プラットフォームとしての Codex：オープンなエージェントハーネスの上に構築する は、有能なエージェントにはプロンプトとモデルの応答以上のものが必要だと論じ、その周囲の実行システム、すなわちタスクの理解、コンテキストの維持、ツールの呼び出し、失敗への対処、承認の要求をエージェントハーネスと名づける。ハーネスエンジニアリング は、エージェント型エンジニアリングのパターン のある章が、コーディングエージェントは言語モデルのためのハーネスそのものであると述べていることを記録している。
2 つの変種は、式を狭めることなく強調点を狭めている。HumanLayer の Skill Issue：コーディングエージェントのためのハーネスエンジニアリング は「コーディングエージェント = AI モデル + ハーネス」（coding agent = AI model(s) + harness）と書くが、ハーネスをエージェントの設定面、つまりスキル、MCP サーバー、サブエージェント、メモリ、AGENTS.md ファイルなどとして説明する。コーディングエージェントのユーザーのためのハーネスエンジニアリング は「モデル以外のすべて」という略式の言い方を取り、それをコーディングエージェントを使うという限定された文脈へ狭める。ハーネスの一部はエージェントの開発者によってエージェントに組み込まれており、ユーザーはそこに自分自身の外側のハーネス（outer harness）を加える。この投稿はそれを ガイドとセンサー の系としてモデル化している。
広い答えの形式化
いくつかの研究論文は、広い範囲を保ちながら、列挙の代わりに内部構造を与えている。
質問応答からタスク完遂へ：エージェントシステムとハーネス設計に関するサーベイ は、実装レベルのエージェントを、基盤モデルと実行ハーネスの結合として記述し、後者を 6 つの結合したランタイム上の責務として形式化する。観測インターフェース、コンテキストマネージャー、制御ループ、アクションインターフェース、状態と成果物のストア、検証とガバナンスである。このサーベイは、これが個々のツール、メモリモジュール、プロンプトテンプレート、ワークフロースクリプトのどれよりも広いと述べている。
エージェントハーネスとしてのコード：実行可能・検証可能・ステートフルなエージェントシステムに向けて は、ハーネスをモデルの周りにあるポリシー統制されたシステムとして捉え、その内部で動くコードとは区別する。コードはハーネスの内部にある実行可能な媒体であり、どのコードを実行し、信頼し、永続化し、再利用し、昇格させてよいかを決めるのはハーネスである。このサーベイはまた、本番のハーネスが学習データの供給源になりつつあることを指摘し、それによって「エージェント」と「エージェントの周りのハーネス」の境界が、それ自体として学習可能な面になるのだと述べている。
LLM エージェントにおける外部化：メモリ、スキル、プロトコル、ハーネスエンジニアリングの統一的レビュー はこの概念を最も遠くまで押し広げる。ハーネスとは、外部化されたメモリ、スキル、プロトコルが一体として有効に働く設計された認知環境（designed cognitive environment）であり、エージェンシーはモデル単体に宿るのではなく、モデルと環境の結合から生まれるとする。このレビューは、この概念がまだ固まりつつある段階だと述べ、自らの特徴づけを閉じた定義ではなく、繰り返し現れるパターンの統合として提示している。
エージェント型 AI コーディングツールのためのハーネスエンジニアリング：探索的研究 は、部品を列挙するのではなく語彙を層に分けることで線を引く。コンテキストとは 1 回のモデル呼び出しへの入力の全体であり、エージェントハーネスとは、エージェントループを駆動し、呼び出しのたびにそのコンテキストを組み立て、ツールスキーマを公開し、ターンごとの状態を管理する、モデルの周りのソフトウェアである。この読み方では、コンテキストを設計することはコンテキストエンジニアリングであり、ハーネスそのものをカスタマイズすることはハーネスエンジニアリングである。
ハーネスでないもの
ハーネスエンジニアリング：コーディングエージェントの解剖、アーキテクチャ、進化 ― 11 システムのソースコード研究 は、ここで取り上げる情報源の中で唯一、除外によってハーネスを定義している。この論文は、ハーネスとよく混同される 4 つのものを挙げる。
- スキャフォールド。ほぼ同義語として扱い、区別が役立つ場合には、「スキャフォールド」をループやレジストリといった構造的なコードに、「ハーネス」をそれを組み込んで出荷されるランタイム成果物に充てる。
- エージェント型フレームワーク。その内部で作業するランタイムではなく、エージェントを構築するためにインポートするライブラリである。
- SWE-bench のもののような評価ハーネス。モデルではなくエージェントを包む。
- オーケストレーター、すなわちメタハーネス。上からハーネス群を調整し、自前の編集ループは実装しない。
この論文は、メタハーネスをハーネスと同じサブシステムで採点することはカテゴリー錯誤だと述べる。こうした除外によって、この論文は以下のいくつかの説明と食い違う。この論文がハーネスと対比するフレームワークは、Harrison Chase がその上にハーネスを構築する層であり、この論文のメタハーネスは、Anthropic が別のものに使っているのと同じ語である。
スタックの中の層: フレームワーク、ランタイム、ハーネス
Harrison Chase の エージェントフレームワーク、ランタイム、ハーネス――なんてこった！ は、「ハーネス」を、モデルの周りのシステム一般ではなく、エージェント構築パッケージの階層の中の 1 つの位置を指すものとして使う。エージェントフレームワークは抽象化を提供し、その下のエージェントランタイムは本番用のインフラ、主に耐久実行（durable execution）を供給し、エージェントハーネスはフレームワークの上に位置して、デフォルトのプロンプト、ツール呼び出しの独自の方針に基づく処理、計画ツール、ファイルシステムへのアクセスを加える。つまり「必要なものが一式そろっている」（batteries included）。彼の例は、LangChain の上に構築された LangChain 自身の Deep Agents である。
この読み方では、ハーネスはモデルの補集合ではなく、3 つのカテゴリーの 1 つであるパッケージの一種である。Chase は、あらゆるコーディング CLI もある種のエージェントハーネスだと論じうることを認めている。彼は、この用語を自分が作ったわけではないこと、その定義はまだ明確でないこと、3 つの層の境界は曖昧であることを述べている。エージェントハーネス は、同じ会社のブログに後から載った Trivedy の定義が、Chase の階層よりはるかに広いことを記している。
この階層は、上のソースコード研究とは噛み合わない。Chase のハーネスはフレームワークの上に構築されるが、その研究はハーネスとフレームワークを、インポートするライブラリではなく内部で作業するランタイムとして区別し、調査した 11 のエージェントランタイムのどれも、LangChain、LangGraph、AutoGen のような汎用のエージェント型フレームワークをインポートしていないと報告している。
接続するインフラ: 耐久性のあるランタイムとしてのハーネス
Inngest のブログ投稿である エージェントに必要なのはフレームワークではなくハーネスである は、この語の工学的な意味、すなわちワイヤーハーネス、テストハーネス、安全ハーネスから出発する。つまり、自ら仕事をすることなく、コンポーネントを接続し、保護し、オーケストレーションする層である。この投稿の見立てでは、LLM がエンジン、ツールが周辺機器、メモリがストレージであり、ハーネスはそれらを接続し、失敗を受け止め、衝突を防ぎ、イベントをルーティングするものである。ハーネスが解決する問題、つまりリトライ、状態、並行性、可観測性、スケジューリングは、AI の問題ではなくインフラの問題として位置づけられている。
この投稿がハーネスと呼ぶものは、Chase がランタイムと呼ぶものに近い。Chase は耐久実行をエージェントランタイムの主要な関心事とし、そこで LangGraph に最も近いプロジェクトとして Temporal、Inngest、その他の耐久実行エンジンを挙げている。Inngest の投稿は、耐久性のあるイベント駆動のインフラが、この投稿の言うハーネスの問題をすでに解決していると論じる。この投稿は、自らが推奨するインフラのベンダーによって書かれている。
いくつかのコンポーネントの 1 つ
Anthropic による 2 つの説明は、エージェントを 2 つより多くの部分に分けており、どちらにおいてもハーネスはモデル以外のすべてではなく、その部分の 1 つである。
ハーネスエンジニアリング に記録されている、エージェントのガバナンスに関する Anthropic の投稿は、エージェントを 4 つに分ける。モデル、モデルが従う指示とガードレールとして定義されるハーネス、モデルが使えるサービスやアプリケーションであるツール、そしてエージェントが動く場所と到達できる範囲である環境である。ハーネスエンジニアリング はこれを、「エージェント = モデル + ハーネス」と競合するものではなく、その第 2 項の分解として示している。
Managed Agents のスケーリング：頭脳を手から切り離す は、Claude Managed Agents について別の三分割の線を引く。セッション（起きたことすべての追記専用ログ）、ハーネス（Claude を呼び出し、そのツール呼び出しをルーティングするループ）、サンドボックス（Claude がコードを実行しファイルを編集する場所）であり、それぞれが独自のインターフェースの背後にある。これが Brain/Hands/Session 分割 である。ハーネスはサンドボックスを他のツールと同じように呼び出し、セッションログがハーネスの外にあるため、失敗したハーネスは再起動して最後のイベントから再開できる。Anthropic は、認証情報をサンドボックスの外に置くことで、ハーネスが認証情報をまったく知らないようにしていると説明している。
どちらの読み方でも、広い答えがハーネスの内側に置くものが外側に置かれる。Trivedy の一覧にはツール、ファイルシステム、サンドボックスが含まれるが、ガバナンスの分割はツールと環境をそれぞれ独立したコンポーネントとし、Managed Agents の設計はサンドボックスと耐久性のあるセッションログをハーネスの中ではなく横に置く。
ハーネスのレベル
いくつかの情報源は、「ハーネス」を入れ子にできるもの、つまり同じシステムの中に複数存在しうるものとして使っている。
Gorinova らによる ポジション：コーディングベンチマークはエージェント型ソフトウェアエンジニアリングと噛み合っていない は、「エージェントハーネス」を、1 つのタスクに向けてツールとやり取りする言語モデルに使い、モデル、プロンプト、ツール、ループからなる設定可能な実行器として扱う。「コーディングエージェント」と呼ばれる成果物のほとんどは、この意味でのエージェントハーネスである。システムハーネスはその外側にある。上位の目標をタスクに変換し、それぞれを 1 つ以上のエージェントハーネスに振り分け、環境を管理し、出力をフィードバックに回す。ここでの内側のレベルは、広い答えのハーネスと同じ対象ではない。Gorinova らのエージェントハーネスはモデルを含むが、Trivedy のハーネスはモデル以外のすべてである。
メタハーネスはさらにその上のレベルであり、この語は 2 つの異なる設計に使われている。ソースコード研究では、それはハーネス全体、すなわち Claude Code、Codex、Cursor などを交換可能なコンポーネントとして包み、自前の編集ループを実装しないオーケストレーション層である。その例は Omnigent であり、著者たちはこれを、ハーネスがコモディティなコンポーネントになりつつあるという賭けとして読んでいる。Anthropic は Claude Managed Agents を別の意味で「メタハーネス」（a meta-harness）と呼ぶ。どのハーネスが動くかについて特定の立場を取らず、多くのハーネスがその上で動ける耐久性のあるセッションとサンドボックスのインターフェースを提供するシステム、という意味である。どちらの情報源も、もう一方の用法には言及していない。
コーディングエージェントのユーザーのためのハーネスエンジニアリング の外側のハーネスは、3 つ目の種類の外側の層である。オーケストレーターではなく、エージェントの開発者がすでに提供したハーネスの部分の周りに、ユーザーが加えるガイドとセンサーである。
ソフトウェアを越えて: 方法論的ハーネス
方法論的ハーネス は、エージェント型ソフトウェアエンジニアリングのための仕様駆動開発：人間–エージェントのチームワークをハーネスする による、この語をソフトウェアの外にまで広げる提案を記録している。この論文は、モデルの周りのソフトウェア、すなわちオーケストレーションループ、ツール、コンテキスト管理、メモリ、ガードレール、検証ループを技術的ハーネスと呼び、それは 1 つのセッションにおける 1 つのエージェントを統制するものだとする。そして、再現性、監査可能性、移転可能性、レビュー能力、調整といったチームレベルの性質には、2 つ目の方法論的ハーネス、すなわち仕様を中心とする、チームが所有する実践と成果物が必要だと論じる。著者たちは、自らのフレームワークを検証済みのモデルではなく、反証可能な仮説として説明している。
コーディングエージェントのユーザーのためのハーネスエンジニアリング は同じ方向へのより小さな一歩を踏み出している。人間の開発者は自らのスキルと経験を暗黙のハーネスとして持ち込むがコーディングエージェントにはそれがなく、ハーネスはそれを明示化しようとするものの、できることには限りがある、というのである。
隣接する語
ウィキにある他の 2 つの用語は、「ハーネス」によって定義されてはいないものの、同じ領域の多くをカバーしている。
エージェントスキャフォールド は、13 のオープンソースのコーディングエージェントのソースコードによる分類である スキャフォールドの内側：コーディングエージェントアーキテクチャのソースコードレベルの分類体系 を記録している。この論文は、コーディングエージェントにおいてモデルを囲むコード、すなわち制御ループ、ツール定義、状態管理、コンテキスト戦略をそのスキャフォールドと呼び、それを制御アーキテクチャ、ツールと環境のインターフェース、リソース管理に整理する。後のソースコード研究は、「スキャフォールド」と「ハーネス」を実務上ほぼ同義語として扱い、上で述べたスキャフォールドとランタイム成果物の区別を設けている。その例は、Mini-SWE-Agent のスキャフォールドが 100 行の Python であるのに対し、Claude Code のハーネスはターミナル UI、権限システム、プラグインエコシステムを備えた製品だというものである。
Harness-as-a-Service は、この語をその上に構築するものとして使う。これは Viv Trivedy に帰される捉え方で、補完結果を返す LLM API の上に構築することから、ランタイムを返すハーネス API の上に構築することへの移行を指す。Claude Agent SDK、Codex SDK、OpenAI Agents SDK がこの方向を示すものとして挙げられている。Chase と同じく、これはハーネスを、開発者が自ら書くものではなく入手するものとして扱うが、例は噛み合わない。Harness-as-a-Service のページは OpenAI Agents SDK をハーネス API の方向を示すものとして挙げるが、エージェントフレームワーク は Chase が OpenAI Agents SDK をエージェントフレームワークに分類していることを記録している。
答えが分かれるところ
並べてみると、これらの説明はいくつかの異なる軸に沿って食い違っている。
- 境界。 ツール、サンドボックス、実行環境、耐久性のある状態が、ハーネスの一部なのか、それともその横にあるコンポーネントなのか。Trivedy の一覧、Claude Code のドキュメント、OpenHarness の README はツールをハーネスの内側に置く。Anthropic のガバナンスの分割はツールと環境を別々のコンポーネントとする。Managed Agents の設計はサンドボックスとセッションログをハーネスの外に置き、ハーネスをモデルを呼び出してそのツール呼び出しをルーティングするループにまで縮める。
- ものの種類。 ハーネスは、あらゆるエージェントにおけるモデルの補集合なのか（広い答え）、設定面なのか（HumanLayer）、フレームワークの上にあるパッケージのカテゴリーなのか（Chase）、Chase ならランタイムに分類する種類の接続インフラなのか（Inngest）、開発者がサービスとして入手するものなのか（Harness-as-a-Service）。ソースコード研究は、ハーネスがフレームワーク、狭い意味でのスキャフォールド、評価ハーネス、メタハーネスのいずれでもないと付け加える。
- 範囲。 「ハーネス」が指すのは、1 つのタスクに取り組む 1 つのエージェントなのか、その上にあって多数に振り分けるシステムなのか（Gorinova ら）、ハーネス全体の上にある層なのか（2 つの意味でのメタハーネス）、ユーザーが加える外側の層なのか（外側のハーネス）、それともそのすべてを取り巻くチームの実践なのか（方法論的ハーネス）。
- 耐久性。 Anthropic の Managed Agents の投稿は、ハーネスが Claude が単独ではできないことについての想定を組み込んでおり、その想定はモデルの向上とともに古びる、という点から出発する。そのため、その設計はその上で動くハーネスについてではなく、Claude の周りのインターフェースについて特定の立場を取る。Osmani の投稿は、モデルが向上してもハーネスは縮むのではなく移動すると論じる。Trivedy の投稿は、ハーネスの機能の一部はモデルに吸収されるが、ハーネスエンジニアリングは引き続き有用だと見込んでいる。メタハーネスの著者たちは、ハーネスがコモディティになりつつあると読む。方法論的ハーネスの提案は、技術的ハーネスは価値が減っていき、方法論的ハーネスは価値が増していくと説明する。
情報源のいくつかは、自らの定義を暫定的なものとして断っている。Chase は明確な定義はまだ存在しないと言い、Trivedy は自らの境界を自分の考えでは最もすっきりしたものと呼び、外部化のレビューはこの概念がまだ固まりつつあるとし、メタハーネスの著者たちは Omnigent を確立したカテゴリーの代表ではなく、自分たちが知る最初のそうしたシステムと呼んでいる。