エージェントの成績はモデルの重みだけで決まるわけではありません。ループ、ツール、文脈管理、検証、権限といったハーネスを追加しても、成績は一様に向上しません。古い「モデルができない」という前提が残っていると、現在のモデル能力を過小評価してしまいます。
📑目次
同一 GPT-5 でも、Terminal-Bench 2.1 は Terminus 2 で 35.2%、Codex CLI で 49.6% です。差は約14ポイントで、重みは同じです。数値は査読前の arXiv:2609.01437 が報告しています。足す前に、削る対象と、不可逆操作の境界を分ける判断が必要です。
足す前に削る対象と境界を分ける
この記事では、ハーネス負債をテクノロジー投資の増額問題ではなく、古い能力前提の問題として扱います。採用の可否は、同一モデルでの成功率と実行トークン数で判断します。
ハーネスはモデルの外側のランタイム
定義は Agent = Model + Harness
ハーネスは、モデル内部の推論ではありません。ツール呼び出し、記憶、状態、実行環境、フィードバックを担う周囲のランタイムです。Wikipedia の Agent harness は、関係を Agent = Model + Harness と書いています。包む対象が非決定的なので、捏造や早期完了からの回復も設計対象になります。
独立研究の arXiv:2609.00006（Barbaste ら、2026年7月15日投稿）も同じ式を使います。ハーネスはループ、ツール、文脈管理、安全制御、オーケストレーション、拡張面で LLM を外界へつなぐ、と定義しています。
11実装の解剖
解剖対象はClaude Code、Codex CLI、Gemini CLI、OpenHandsなど11の実装と、対比となるmeta-harnessです。これらを7つの正準サブシステムに整理しています。
横断観察は実装寄りです。
- 約400万行の Python / TypeScript / Rust で、汎用エージェント枠の import はありません。
- コード検索はベクトル埋め込みではなく、決定的な手段です。
- SKILL.md は 11件中9件、MCP は8件、ACP は6件です。
著者は、2026年前半にハーネスがtoolからplatformへと転換したと主張しています。
この分類は百科とプレプリントの整理です。製品 SDK の標準分類ではありません。プロンプトやコンテキストの調整より広い運用環境、という位置づけに留めます。失敗の止め方そのものは、ハーネス設計でエージェント失敗を止める手順 側の論点が近いです。
「ハーネスを足す」がテクノロジー投資として一様に効かない理由
ハーネスを追加することはテクノロジー層への投資に見えます。しかし重みを固定したままハーネスだけ変えると、成績は大きく変わります。上がる方向に限られるわけではありません。
同一 GPT-5 でも約14ポイント差
HarnessDev（arXiv:2609.01437） は、同一 GPT-5 の Terminal-Bench 2.1 を Terminus 2 で 35.2%、Codex CLI で 49.6% と報告しています。
Creation 実験の規模は次のとおりです。
- creator LLM は6つ
- ドメインは4つ
- 下流は 2,207 instances
生成ハーネスはコードと検索・調査では成熟した人手参照に劣り、執筆と機械学習実験では並ぶか上回ります。実行トークンは大きくばらつき、高トークンは高成績を保証しません。
Evolution は一様改善ではない
Evolutionの側でも一様な改善は見られません。改善は不安定で、held-outデータへの移転は部分的です。論文は、実行モデルへの依存が強いと指摘しています。自動でハーネスを進化させても、開発セットでの上昇だけでは採用の根拠にはなりません。
体積よりタスク適合
適合の話は体積の話と別です。JIT-Agent（arXiv:2608.25593） は、タスク適応ハーネスで DeepSeek-V4-Flash が GPT-5.6 を DeepSearchQA で +9.1、OdysseyBench で +4.3 と報告しています。GLM-5.2 は最大 +20.2 です。固定スキャフォールドを積む操作と、タスク適合の生成は別物です。
| 観察 | 数値 | 読み方 |
|---|---|---|
| 同一 GPT-5 / Terminal-Bench 2.1 | Terminus 2 35.2% / Codex CLI 49.6% | 重み固定でもハーネスで約14ポイント差 |
| HarnessDev Creation | コード・検索は人手参照に劣る。執筆・ML実験は並ぶ/上回る | 足した生成ハーネスが常に強いわけではない |
| HarnessDev Evolution | 改善は不安定。held-out は部分移転。実行モデル依存 | 進化ループを回しても一様改善ではない |
| JIT-Agent 適応生成 | DeepSearchQA +9.1 / OdysseyBench +4.3 / GLM-5.2 最大 +20.2 | 固定スキャフォールド増よりタスク適合 |
| Anthropic 実験スキャフォールド（二次） | 同一モデルで標準の2倍超 | 向きを誤ると半減もあり得る |
数値の出典と査読前の読み方
出典：arXiv:2609.01437、arXiv HTML、arXiv:2608.25593、AI Heroes（2026年9月時点）
制限を先に置きます。HarnessDev と JIT-Agent は査読前です。自動生成ハーネスの評価であり、人手ハーネス全般の失敗証明ではありません。実験スキャフォールドが標準の2倍超、という数字は Anthropic 報告の二次引用です。
常時稼働のコスト判断は、ハーネス体積とは別軸です。常時稼働AIは起動・停止・上限・観測を1枚に書いてからGPUを予約する では、起動条件と上限を先に書く手順を扱っています。
ハーネス負債は古い「できない」仮定
古い能力仮定のスナップショット
ハーネス負債は、当時のモデル限界を映したスナップショットです。残っている主な場所は次のとおりです。
- ツールラッパ
- オーケストレーション
- 太い system prompt
AI Heroes の分析（Marco Lobo）は、モデルがもう自分でできることへの古い仮定の積み上げ、と定義しています。オーケストレーションを足すことは、多くの場合、修正の逆です。
公式側も同じ方向です。Anthropic の Managed Agents 解説は、ハーネスが「Claude が単独ではできない」仮定をコード化すると書いています。モデルが上がると、その仮定は腐ります。頻繁に疑わないと、足場が死重になります。
context reset はモデルが変わると死重になる
実例は context reset です。Sonnet 4.5 の context anxiety 向けに入れた reset は、同じハーネスを Opus 4.5 に載せると死重になりました。
reset は不安を止めますが、次が増えます。
- オーケストレーション
- トークン
- 遅延
長時間アプリ向けハーネス設計は、compaction より reset の方が核心には効く一方、コストは無料ではない、と書いています。自己評価は甘くなるので、評価役の分離の方が扱いやすい、とも述べています。
伸びた層と横ばいの層
二次数値も、伸びた層と横ばいの層が分かれます。AI Heroes が引く Opus 4.6 対 4.5 では次です。
- Terminal-Bench 2.0 が 59.8% から 65.4%
- OSWorld が 66.3% から 72.7%
- SWE-bench Verified は 80.9% から 80.8% でほぼ横ばい
過設計になっている層が、モデル側で伸びた層と重なっています。
- プロンプト変更のみで SWE-bench Verified は 80.84% から 81.4%
- BrowseComp は、ツール出力をコードでフィルタすると 45.3% から 61.6%
一次は Anthropic 側の報告で、ここでは二次引用として扱います。
運用面では、脳と手の分離がレイテンシに効いているとAnthropicは報告しています。
- p50 TTFT は約60%減
- p95 は90%超減
資格情報は実行サンドボックスに置きません。Git トークンは初期化時、MCP はプロキシ経由の vault です。社内手順の固定は Skills と Eval の話に近いです。社内AIエージェントのSkillsとEval設計｜合格基準を作る方法 では、合格基準を先に置く観点を扱っています。
削る足場と残す境界の確認手順
能力の穴埋めか、結果の境界か
ハーネスを追加する前に、部品を1行で分類します。能力の穴埋めであれば再テストの対象です。結果を変える境界であれば残す候補です。モデルがリリースされるたびに、「できない」という前提が強い部品を3つ選び、新モデルで再実行します。90日のパイロットより、2週間削除して2週間実トラフィックで検証する方が、腐った前提を早く発見できます。
確認手順は次の7項
確認手順は次の7項です。
- 部品ごとに「これは能力の穴埋めか、結果の境界か」を1行で書く。穴埋めなら再テスト対象。境界なら残す候補。
- モデルリリースのたびに、「できない」仮定が強い部品を3つ選び、新モデルで再実行する。
- 削る候補を列挙する。bash とエディタで足りる専用検索ツール、全ツール結果の生コンテキスト回流、手書きオーケストレーション、万一のための太い system prompt。
- 残す候補を列挙する。不可逆操作と外部状態変更の確認ゲート、上書き前の鮮度チェック、構造化ログ、権限境界、顧客向け・金銭操作の人承認。
- 資格情報を実行サンドボックスに置かない。Git トークンは初期化時、MCP はプロキシと vault。
- ハーネスを足すなら、同一モデルで before / after のタスク成功率と実行トークンを両方見る。トークン増だけで採用しない。
- 自動でハーネスを進化させる場合、held-out と別実行モデルで落ちないかを見る。開発セットの上昇だけでは不十分。
採用は成功率とトークンで見る
出典：Anthropic Managed Agents、AI Heroes、arXiv:2609.01437（2026年9月時点）
採用判断はシンプルです。同一モデルで成功率が上がり、トークン増加が説明できる場合にのみ残します。説明できないトークン増加は、古い前提の残滓として疑います。
筆者の観点
ハーネスを足す提案は、機能追加に見えます。実際の分岐は、能力の穴埋めか、結果の境界かです。前者はモデル更新で腐ります。後者は、金銭、顧客向け操作、不可逆な外部書き込みのように、失敗のコストが非対称な面です。
査読前の数値を製品選定の最終根拠にはしません。有用なのは、同一重みでハーネスを変えたときに成績が実際に動くという方向性です。導入前にbefore/afterを同じタスクセットで取得し、トークン数も並べて比較します。resetや評価役の分離は、レイテンシとオーケストレーションの増加とセットで評価します。
よくある質問
Q1. ハーネスエンジニアリングはプロンプトを長くすることですか
いいえ。モデル外側のループ、ツール、文脈、検証、権限の設計です。プロンプトとコンテキストはその一部です。
Q2. ハーネスを足せば同じモデルでも必ず強くなりますか
なりません。同一 GPT-5 でも Terminal-Bench 2.1 は 35.2% と 49.6% に分かれます。生成ハーネスはコードと検索で人手参照に劣る報告があります。
Q3. 何を削り、何を残しますか
能力の穴埋め（専用ツール、生結果の全回流、太いプロンプト）は再テストして削ります。不可逆操作の確認と権限は残します。
Q4. context reset は常に必要ですか
いいえ。Sonnet 4.5 向け reset は Opus 4.5 では死重になりました。モデルが変わったら前提を疑います。
Q5. 電通総研の分類をそのまま使えますか
発見記事の整理であり、業界標準ではありません。定義と数値は Anthropic 公式と arXiv を優先します。
関連記事:
まとめ
ハーネスはモデルを実務に繋ぐランタイムです。古い「できない」仮定の積み上げは、成績を抑えます。足す前に削ります。
次の作業は具体的です。「できない」仮定の強い部品を3つ再テストし、能力足場は削り、不可逆操作の境界は残します。採用は同一モデルの成功率とトークンで判断します。
著者
krona23
IT業界20年以上の実務経験を持ち、日本国内有数のPVを誇る大規模Webサービスで事業部長・CTOを複数社で歴任。Windows/iOS/Android/Webと技術の変遷を経験し、現在はAIネイティブへの変革に注力。DevGENTでは、AIコードエディタ・自動化ツール・LLMの実践的な使い方を日英西3言語で発信中。
コメントを残す