動作中のエージェント内でGPT-5をClaudeに入れ替えても、ほとんどの場合、ほぼ何も変わりません。リトライの処理方法、コンテキストウィンドウに何を入力するか、またはいつ停止するかを変えると、エージェント全体の動作が変わります。その差がすべてを物語っています。モデルは動作するエージェントの中で最も小さく、最も交換しやすい部分です。興味深いエンジニアリングは、それを包むすべての部分に宿っています。
このwrapperには今や名前があります。実務家たちは、固定されたスクリプトを実行するのではなく、時間をかけて行動を取るものにテキストジェネレーターを変える層を「harness」と呼ぶことで落ち着きました。この用語は2026年初頭にTwitterとエンジニアリングブログで急速に広まり、同じ言葉が読むたびに少しずつ異なる意味で使われるほど、緩く使われるようになりました。この記事では正確に定義します。harnessとは何か、何で構成されているか、「framework」や「scaffold」とどう違うか、そしてなぜagentの品質のほとんどがモデルではなくharnessに隠れているのか。
短いバージョン
- agent harnessとは、LLMを取り巻くソフトウェアであり、実行ループ、ツール、メモリ、コンテキスト、状態、エラー処理、ガードレールを管理します。 モデルはテキストを生成します。harnessは、モデルが何を見るか、何ができるか、いつ停止するか、そして何かが壊れたときに何が起きるかを決定します。
- 本番環境では、モデル呼び出しはシステムの表面積の中で最も小さな可視部分であることが多いです。よく構築されたharnessの中の弱いモデルは、粗雑なharnessの中の強いモデルを上回ることができます。特に長時間実行されるツール集約型のタスクでそれが顕著です。
- harnessにはおおよそ9から11の繰り返し使われるコンポーネントがあります。そのほとんどはモデルが直接触れることのないものです。
- "Harness"は"framework"と同じではありません。framework(LangGraph、agents SDK)はあなたが構築に使うライブラリです。harnessはそのライブラリが組み立てを助けてくれる実行レイヤーです。
Agent Harnessとは何か？
agent harnessとは、言語モデルを取り巻くソフトウェアインフラであり、実行ループ、ツールアクセス、メモリ、コンテキスト、状態の永続化、エラー処理、ガードレールを管理します。モデルはテキストを生成します。harnessは各ターンでモデルが何を見るか、どのアクションを取れるか、いつ停止するか、そしてステップが失敗したときに何が起きるかを決定します。
最もシンプルな表現はLangChainから来ています。彼らはこれを一つの方程式に集約しています： Agent = Model + Harness. モデルは知能を提供します。ハーネスは、その知能を現実の世界で機能させるものです。
「ハーネスとは、モデル自体ではないすべてのコード、設定、実行ロジックのことです。」
— LangChain, エージェントハーネスの構造
この境界を最も感じやすいのは、一つの質問を通じてです。エージェントが間違ったことをしたとき、モデル自身の推論が間違っていたのか、それとも周囲のシステムがモデルに間違ったコンテキスト、間違ったツール、または回復手段を与えなかったのかということです。実際のシステムでは、ほとんどの場合、後者です。モデルは不正な入力に対して正しく推論していました。ハーネスが入力を制御するものです。
重要なポイント: モデルが生成し、ハーネスが制御します。その分担が全体の概念です。
エージェントハーネスのコンポーネントとは何か?
すべての本番ハーネスは同じ繰り返しのパーツを組み合わせています。モデルをターンごとに駆動する実行ループ、行動できるようにするツールアクセス、ターン間のメモリ、現在見ているものに対するコンテキスト管理、セッション間で作業が存続するための状態永続化、失敗したステップのエラー処理、できることを制限するガードレールです。本番システムには検証ループとサブエージェントオーケストレーションが追加されます。
実務者が実際のシステムをどのように説明するかから導き出した有用なリスト:
- 実行/制御ループ: エージェントをターンごとに動かすもの。モデルを呼び出し、出力を読み、要求されたツールを実行し、結果を返し、停止条件まで繰り返す。
- Toolアクセス: モデルがアクセスできる関数、API、コード実行環境、ファイルシステム。
- メモリ: エージェントがターンとセッションをまたいで保持する情報。
- コンテキスト管理: 各ターンでモデルのウィンドウに詰め込まれるものと、オーバーフロー時に圧縮されるもの。
- 状態の永続化 / チェックポイント: エージェントの状態を保存し、クラッシュまたは一時停止した実行を再開できるようにすること。
- エラー処理: tool呼び出しまたはモデル呼び出しが失敗した場合のリトライ、フォールバック、リカバリ。
- ガードレール: エージェントが実行できる操作の制限（使用可能なツール、ステップ上限、出力検証など）。
- 検証ループ: エージェント（またはハーネス）が完了を宣言する前に自身の作業を確認すること。
- サブエージェントのオーケストレーション: 大きなタスクにおいてサブエージェントを生成し、委任し、結果を収集すること。
これらすべてが普遍的なわけではありません。実行ループ、ツール、コンテキスト処理、エラー処理は週末のプロトタイプにも登場します。状態の永続化、検証、サブエージェントのオーケストレーションはプロトタイプと本番システムが分かれる箇所です。プロトタイプはこれらを省略できますが、長期稼働する本番エージェントは省略できません。Anthropic による次のドキュメント: 長期稼働エージェント は本番環境専用の部分についての解説です。コンテキストウィンドウがリセットされた後にエージェントが進捗ファイルから理解を再構築する方法と、テストがループに組み込まれる方法を扱っています。
学術的なつながりを求める方のために、最近の エージェントアーキテクチャの調査 同じ仕組みをコアコンポーネントのより小さな形式タプルに畳み込んでいます。実務者のリストと調査のフレーミングは同じ構造に対する二つのズームレベルです。調査は圧縮し、上記のリストは展開します。9から11の数はほとんどの本番ハーネスが共有するコンポーネントとして扱ってください。批准された標準ではなく、この分野はまだ何も批准していません。
重要なポイント: エージェントの動作部品の大半はモデルではなくハーネスに存在します。モデルは多くのコンポーネントの一つに過ぎません。
なぜハーネスはモデルより重要なのか?
適切に設計されたハーネス内の弱いモデルは、設計の悪いハーネス内の強いモデルを頻繁に上回ります。理由は機械的であり、魔法ではありません。エージェントの end-to-end 信頼性は各ステップの信頼性の積であり、それらのステップの大部分（ツール選択、コンテキスト組み立て、エラー回復）はモデルではなくハーネスの仕事です。それらを改善すれば、内部にどのモデルがあっても、チェーン全体がより信頼できるものになります。
算術でこれを具体的に示します。10ステップのタスクで各ステップが99%の確率で成功すると仮定します。end-to-end の成功率は99%ではありません。0.99の10乗、約90%です。各ステップを99.9%に引き上げると、end-to-end は約99%に跳ね上がります。ステップごとの信頼性は複利で蓄積され、そのステップごとの信頼性は圧倒的にハーネスの属性です。だからこそ、エラー処理とコンテキスト管理を最適化することが、あるベンチマークで半ポイント優れたモデルに交換するよりも効果的なのです。
同じ方向を指す本番環境のシグナルがあります。 MongoDB、Vercel のケーススタディを引用, Vercel がエージェントのツールの大部分を削減し、より小さくクリーンなハーネスで同じモデルの成功率が急上昇するのを目撃したと報告しています。これは証明ではなく収束的な証拠として読んでください。これは1つの本番事例であり、制御された実験ではありませんが、上記の複利計算と調査研究と同じ方向を指しています。
これは、プラットフォームエンジニアとして私が何度も立ち返るヒューリスティックです。ボトルネックはコンテキストであり、モデルの生の能力ではありません。そして、現在のモデルのギャップを覆い隠すために構築されたスキャフォールドは、モデルが進化するにつれて取り込まれる傾向があります。ハーネスの耐久性のある部分（ループ、状態、リカバリー）を構築し、その下のモデルが自身のスケジュールで向上するのに任せてください。
重要なポイント: エージェントが失敗したとき、まずモデルではなくハーネスを疑ってください。その可能性が高いです。
ハーネス、スキャフォールド、フレームワークの違いは何か?
この3つは互換的に使われていますが、そうすべきではありません。A フレームワーク は LangGraph や agents SDK など、開発に使用するライブラリまたは SDK です。A harness はモデルを取り巻く実行・ガバナンス層であり、フレームワークがその組み立てを支援します。A scaffold 3つの中で最も曖昧で、harness のほぼ同義語として使われることもあれば、そのプロトタイプ版、あるいは特に prompt とツール説明のレイヤーを指すこともあります。
用語はまだ本当に定まっておらず、最も明快なやり方は一つを規定するのではなく、用法を整理することです。HuggingFace の エージェント用語集 これを直接述べています：
「これらの用語の多くはまだ普遍的に受け入れられた定義を持っておらず、異なるフレームワークが同じ単語を異なる意味で使用しています。」
— HuggingFace, エージェント用語集
| 用語 | 何を指すか | 関係 |
|---|---|---|
| Framework | ビルドに使うライブラリまたは SDK (LangGraph、エージェント SDK) | harness を組み立てるためのツール |
| Harness | モデルを囲む実行レイヤー: ループ、ツール、コンテキスト、状態、ガードレール | 出荷して実行するもの |
| Scaffold | ゆるく使われる: harness のほぼ同義語、またはプロトタイプレベル / プロンプト層バージョン | harness と重なる; 精度が低い |
| ループ | harness 内の実行サイクル | harnessのコンポーネント |
自分のシステムについて推論する際の実践的な結論：誰かが「framework」と言ったら、ライブラリを意味するのか実行中のものを意味するのか確認してください。誰かが「scaffold」と言ったら、harness全体を意味するのかprompt-and-toolレイヤーだけを意味するのか確認してください。ここでの価値は曖昧さの解消であり、最終的な答えを主張することではありません。
LangGraphはharnessパターンをどのように実装するか？
LangGraphはharnessパターンの人気のあるオープンソースPython実装です。エージェントの実行を、ノードとエッジの有向グラフとしてモデル化し、それらの間で型付きステートが流れ、すべての遷移がチェックポイント可能です。上記の抽象的なコンポーネントが掴みにくく感じる場合、LangGraphは実際のツールでそれらが具体的な形を取るのを見る場所です。
マッピングはほぼ一対一です。ノードとエッジが実行ループです: 各ノードは作業を行い、各エッジは次にコントロールがどこに行くかを決定します。ノード間で渡される型付きステートオブジェクトは、明示化されたcontext-and-stateコンポーネントです。チェックポイント(LangGraph saversを通じてstateを永続化します Postgresベースのものなど）はstate-persistenceコンポーネントです。設定可能なステップ制限は、誤動作しているエージェントが永遠にループするのを防ぐ停止条件のガードレールです。同じコンポーネントが、特定のライブラリによって名前付けられ、配線されています。
LangGraphエージェントを自分のサーバーで24時間稼働させたい場合、それは概念的な問題ではなくデプロイメントの問題です。参照: Linux VPS ガイド そのパスのために。ここでのLangGraphは単に解説済みの例です: "実行ループ"、"ステート永続化"、"ガードレール"が抽象概念ではなく、実際のコードで指し示せるものであることの証明です。
よくある質問
Agent Harnessとは何か？
agent harnessは、language modelをエージェントに変えるモデル周辺のソフトウェアです。実行ループ、ツールアクセス、メモリ、コンテキスト、ステート永続化、エラー処理、ガードレールを管理します。モデルはテキストを生成し、harnessはモデルが何を見るか、何ができるか、いつ止まるか、何かが失敗したときに何が起きるかを決定します。
エージェントハーネスはエージェントフレームワークと同じものですか？
いいえ。フレームワークは、LangGraphやエージェントSDKのように、構築に使用するライブラリまたはSDKです。ハーネスは、モデルを取り囲む実行とガバナンスの動作レイヤー（ループ、ツール、コンテキスト、状態、ガードレール）であり、フレームワークはその組み立てを支援します。フレームワークを使ってハーネスを構築します。
すべてのエージェントハーネスはどのようなコンポーネントを持っていますか？
ほとんどのハーネスは共通のコアを持ちます: 実行ループ、ツールアクセス、メモリ、コンテキスト管理、状態の永続化、エラー処理、そしてガードレール。プロダクションハーネスは検証ループとサブエージェントのオーケストレーションを追加します。プロトタイプはプロダクション専用の部分をスキップできますが、ループ、ツール、コンテキスト処理、エラー処理はほぼあらゆる場所に登場します。
「LLMはエージェントシステムの最も小さな部分である」はどういう意味ですか？
これは、エージェントの動作と信頼性の大部分がモデルではなくハーネスから来ることを意味します。エンドツーエンドの信頼性は各ステップの成功率の積であり、ほとんどのステップはハーネスの作業です。MongoDBはVercelのケーススタディを引用し、同じモデルでハーネスの変更だけで成功率が向上したと報告しています。これは、ハーネスを修正する方がモデルを修正するよりも効果的であるという証拠です。
あなたのエージェントの品質が宿る場所
ハーネスはエージェントの品質の大部分が宿る場所であり、あなたは今、自分のシステムの問題を特定するための語彙を持っています。ハーネスを定義し、そのコンポーネントを名前付けし、フレームワークやスキャフォルドと区別し、特定の障害がモデルの問題なのかハーネスの問題なのかを推論できます。
次にエージェントが誤動作したとき、まずハーネスレイヤーを調査してください。与えているコンテキスト、公開しているツール、設定している停止条件、失敗したステップからの回復方法。そのレイヤーを確認した後にのみ、より大きなモデルを検討してください。ほとんどの場合、その必要はありません。
