1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@sukimaengineer

GPT-6 Astra が ARC-AGI-3 で 62.7% にも 99.9% にもなる理由 ― LLM とハーネスの役割分担、MCP の居場所

1
Last updated at Posted at 2026-09-05

本記事の執筆には Anthropic の Claude Fable 5.1 とそのリサーチ機能を使用しています。

はじめに

筆者は現在、llama.cpp や vLLM で動かした複数のオープンウェイトモデル（Qwen 系、DeepSeek 系、GLM 系など）を、OpenCode や Claude Code といったコーディングエージェントから呼び出して挙動を試しています。モデルとハーネスの組み合わせによって、「ツールを呼ばずに説明文だけ返す」「編集ツールの引数が壊れる」「同じ作業なのにトークン消費が数倍違う」といった違いが出ます。同じモデルでもハーネスを変えると振る舞いが変わり、同じハーネスでもモデルを変えると振る舞いが変わります。

こうした差を場当たり的に潰していくのではなく、「LLM が担っていること」「ハーネスが担っていること」「MCP がその中のどこにいるのか」をあらためて整理したうえで使いこなしたい、というのが本記事の動機です。個別ツールの操作手順ではなく、役割分担という一段抽象的な視点で整理します。

本記事の執筆時点の直前、2026 年 9 月 3 日に OpenAI が GPT-6 Astra を発表しました。ARC Prize Foundation の独立検証では、同じ GPT-6 Astra が ARC-AGI-3（Semi-Private セット）で、最小構成の Standard ハーネスでは最高 62.7%（reasoning = max）、OpenAI が設計したコンテキスト管理を使う Provider Adapter ハーネスでは最高 99.9%（reasoning = high）を記録しました。reasoning の設定をそろえて比べても、max で 62.7% 対 98.6%、high で 54.8% 対 99.9% と、ハーネスの違いだけで 35 ポイント以上の差が付いています（一次情報。3.1 節で詳しく扱います）。外部ツールも MCP も使っていない、ハーネス側だけの差です。差を生んだ 2 つの設定（推論内容の保持と compaction）は OpenAI の Responses API の機能で、Chat Completions では使えません（3.2 節）。「LLM とハーネスの役割分担」という本記事のテーマは、ローカル LLM の話にとどまらず、フロンティアモデルのスコアの読み方にも直結します。

項目 内容
対象 コーディングエージェント（Claude Code、OpenCode、Codex CLI、Gemini CLI / Antigravity CLI、Cline、Aider など）における LLM・ハーネス・MCP の役割分担と、ローカル LLM 特有の推論サーバーの層
範囲外 各ツールのインストール・設定手順の詳細、モデル自体の性能比較、組み合わせごとの実測
時点 2026 年 9 月上旬（GPT-6 Astra 発表直後）の公開情報に基づきます。この分野は月単位で変わるため、数値や仕様は一次情報での再確認をお願いします
情報源の区別 公式仕様・公式ブログ・公式ドキュメント・原著の投稿を一次情報、解説記事・比較サイト・コミュニティの議論を二次情報とし、本文で区別します。一次情報で確認できなかった事項は「未確認」と明記し、筆者の推定や見解は「〜と推定します」「〜と見ています」と書き分けます
図について 図 1〜12 は公開情報をもとに筆者が作成したものです。図中の数値の出典は本文と「図のデータと出典」節に記載します

1. 用語の整理

1.1 バイブコーディングとエージェンティックコーディング

用語 意味 出典・備考
バイブコーディング（vibe coding） コードの存在を意識せず、LLM に任せて「ノリ」で開発を進めるスタイル Andrej Karpathy 氏が 2025 年 2 月 2 日の X 投稿で命名したことが確認できます（一次情報）。当時の例として Cursor Composer と Sonnet の組み合わせが挙げられています。Merriam-Webster が 2025 年 3 月に slang & trending として掲載しています（一次情報）
エージェンティックコーディング LLM がファイルの読み書き・コマンド実行・テストを自律的に繰り返してタスクを完了させる開発形態 本記事の対象です。バイブコーディングはその使い方の一つ（人間がコードを読まない側に振った使い方）と位置づけます
コーディングエージェント エージェンティックコーディングを実現するツール。Claude Code、OpenCode、Codex CLI など 本記事では「ハーネス」とほぼ同義に使います

1.2 「ハーネス」の語源と定義

ハーネス（harness）はもともと馬具を指す語で、ソフトウェアでは「テストハーネス（test harness）」として定着しています。テスト対象を駆動し、入力を与え、出力を捕捉して検証し、前後処理を担う枠組みで、テスト対象自身はハーネスの存在を知らずにただ動きます。半導体検証の言葉に置き換えれば、DUT に対するテストベンチがこれにあたります（この対応は 7 章で改めて扱います）。

AI エージェントの文脈では、この語がほぼそのまま転用され、「エージェント = モデル + ハーネス」という定式化が広く使われています。モデルが推論を担い、ハーネスが状態・ツール実行・フィードバックループ・機械的に強制できる制約を与える、という分担です。Anthropic は 2025 年 11 月の記事「Effective harnesses for long-running agents」以降、技術記事で harness という語を継続的に使っており（一次情報）、OpenAI も 2026 年 2 月の「Harness engineering」でこの語を前面に出しました（一次情報）。

1.3 ハーネスエンジニアリング（OpenAI、2026 年）

OpenAI が 2026 年 2 月 11 日に公開した記事「Harness engineering: leveraging Codex in an agent-first world」（Ryan Lopopolo 氏）は、この分野で最も参照されている一次情報の一つです。要点を表にまとめます。

項目 内容
実験 約 5 か月間、人間が手書きのコードを 1 行も書かず、Codex エージェントだけで約 100 万行・約 1,500 PR のプロダクトを構築した社内実験。初期の scaffold や AGENTS.md も Codex（GPT-5）が生成
チーム 3 人で開始し、7 人に拡大。1 人あたり 1 日平均 3.5 PR で、人数が増えてもスループットは上がった
指示ファイル AGENTS.md は「百科事典ではなく目次」として約 100 行に抑え、詳細は構造化した docs/ に置く（progressive disclosure）。巨大な単一の指示ファイルは、コンテキストを浪費し、すぐ陳腐化し、機械的に検証できないため失敗する
制約の強制 アーキテクチャの層構造をカスタムリンターと構造テストで機械的に強制する。不変条件を強制し、実装は細かく指示しない
可視性 エージェントがコンテキストから見えないものは存在しないのと同じ。社内ドキュメントやチャットにある知識は、リポジトリに Markdown 化しない限りエージェントには届かない
役割の変化 エンジニアの仕事は「環境を設計し、意図を指定し、フィードバックループを構築すること」に移った

ここで重要なのは、性能向上の手段としてモデルの変更やプロンプトの言い回しではなく、「エージェントが動く環境（ハーネス）の設計」が語られている点です。同じモデルを使い続けたまま、リンター・テスト・ドキュメント構造という環境側の工夫でアウトプットを改善しています。

続いて OpenAI は 2026 年 8 月に「Codex as a platform: build on the open agent harness」を公開し（公開日は二次情報では 8 月 19 日）、ハーネスを次のように定義しています（一次情報、筆者による要約）。有能なエージェントはプロンプトとモデルの応答だけでは成り立たず、タスクを理解し、時間をまたいでコンテキストを維持し、関連情報を調べ、ツールを呼び、進捗を見せ、失敗を処理し、必要なら人間の承認を求め、有用な結果を返す仕組みが要る。その周辺の実行システムがハーネスである、というものです。同記事はハーネスを部品として使うための 3 階層も示しています。

階層 用途
codex exec 非対話のバックグラウンド実行や CI での利用
Codex SDK（TypeScript / Python） アプリケーションからハーネスを呼び出す
Codex app-server JSON-RPC でスレッド作成・ターン開始・イベント受信・承認処理を扱う。IDE 連携（JetBrains、Xcode）の要求が設計の契機だったと別記事「Unlocking the Codex harness」で説明されています

同じ時期の OpenAI ブログ「How enabling two settings tripled our scores on the ARC-AGI-3 benchmark」（2026 年 7 月 29 日）では、同一モデル（GPT-5.6 Sol）に対して、ハーネス側で推論内容（reasoning）の保持とコンテキスト圧縮の 2 設定を追加しただけで、ARC-AGI-3（public タスクセット）のスコアが 13.3% から 38.3% に上がり、出力トークンが約 6 分の 1 になったと報告されています（一次情報）。OpenAI はこの構成を Responses API ハーネスと呼んでいます（設定の中身は 3.2 節で扱います）。

そして 2026 年 9 月 3 日の GPT-6 Astra の発表では、モデルと同時に Codex ハーネスも更新され、コンピュータ操作の速度が Mind2Web 上のタスクで GPT-5.6 Sol 比 1.9 倍になったとしています（一次情報）。OpenAI のスタッフは、この最適化が既存モデルにも効いて GPT-5.6 Sol のコンピュータ操作も約 60% 速くなったと X で述べています（二次情報）。Codex にはコンテキストウィンドウをまたいでメモを保持し、以前のウィンドウを検索できるようにする実験的な仕組みも入りました（config.toml で有効化、一次情報）。モデルの世代交代とハーネスの更新が対で行われている点は、2.4 節で扱う「ハーネスの最適解はモデルの世代で変わる」の裏付けになります。同じ GPT-6 Astra の ARC-AGI-3 スコアがハーネスで 62.7% と 99.9% に分かれた話は 3.1 節で扱います。

2. LLM とハーネスの役割分担

2.1 最小のエージェントループ

役割分担を理解する近道は、エージェントループを最小の疑似コードで書いてみることです。

messages = [system_prompt(tools, project_rules), user_request]

while True:
    resp = llm.call(messages, tools=tool_schemas)   # (A) LLM の仕事はこの 1 行
    messages.append(resp)
    if not resp.tool_calls:                          # (B) 「もう呼ばない」と決めるのも LLM
        break
    for call in resp.tool_calls:
        if not permission.allows(call):              # (C) 権限チェック：ハーネス
            result = ask_user_or_deny(call)
        else:
            result = tools[call.name](**call.args)   # (D) 実行：ハーネス（内蔵 / MCP / CLI）
        messages.append(tool_result(call.id, result))
    messages = compact_if_needed(messages)           # (E) コンテキスト管理：ハーネス

LLM が関与するのは (A) と (B) だけです。「次に何をするか」を、テキストで答えるのか、どのツールをどの引数で呼ぶのかという形で決めるのが LLM の仕事で、それ以外の (C)(D)(E)、そしてループの外側にある system_prompt の組み立てや tool_schemas の用意は、すべてハーネスの仕事です。実際のハーネスはこれにストリーミング表示、サブエージェント、hooks、リトライ、キャッシュ制御などが加わりますが、骨格はこのループです。

image.png

2.2 責務の一覧

責務 担当 具体例
推論・計画・次の行動の決定 LLM 「まずテストを読んでから実装を直す」といった手順の判断
ツールの選択と引数の生成 LLM Edit ツールを old_string / new_string 付きで呼ぶ、Bash に実行するコマンド文字列を渡す
コードや差分の生成 LLM 編集内容そのもの
完了の判断 LLM ツールを呼ばずに最終回答を返す
システムプロンプトの構築 ハーネス ツール一覧、環境情報（OS、カレントディレクトリ、git の状態）、CLAUDE.md / AGENTS.md の注入
ツールの実装と実行 ハーネス Read / Edit / Write / Bash / Grep / Glob / WebFetch などの内蔵ツール、MCP サーバーの呼び出し
権限管理・承認・サンドボックス ハーネス Claude Code の permission mode と allow / ask / deny ルールと OS サンドボックス、OpenCode の permission 設定、Codex CLI の sandbox_mode と approval_policy
コンテキスト管理 ハーネス 自動圧縮（compaction）、要約、ツール出力の切り詰め、進捗ファイルによる引き継ぎ
サブエージェント・並列化 ハーネス 別コンテキストで動く探索用・実装用エージェントの起動と結果の集約
hooks・ワークフローの強制 ハーネス ツール実行前後のフック、フォーマッタやテストの自動実行
メモリ・キャッシュ・リトライ・コスト管理 ハーネス プロンプトキャッシュを効かせる履歴の並べ方、API エラー時の再試行
外部ツールとの接続 ハーネス MCP クライアントとしての接続、CLI の実行
UI ハーネス TUI、IDE 拡張、Web UI

「ハーネス = モデル以外のすべて」という言い方は乱暴に聞こえますが、この表を見ると実態に近いと分かります。モデル提供元が「賢いモデル」を出しても、ユーザーが体感するのはこの表の下 9 行を通した結果です。

2.3 ハーネスの部品を分類する視点

Thoughtworks の Birgitta Böckeler 氏は、martinfowler.com の記事「Harness engineering for coding agent users」（2026 年 4 月頃公開、一次情報）で、ハーネスの構成要素を次のように分類しています。

分類軸 区分 内容
誰が作るか 内側のハーネス（inner harness） モデル提供元が同梱するもの。システムプロンプト、検索、オーケストレーション（Claude Code、Codex、Cursor など）
誰が作るか 外側のハーネス（outer harness） ユーザーが用途に合わせて積むもの。指示ファイル、MCP サーバー、スキル
いつ効くか ガイド（guides、feedforward） 行動の前に誘導するもの
いつ効くか センサー（sensors、feedback） 結果を観測して自己修正させるもの
どう判定するか 決定論的（computational） リンター、テスト、静的解析
どう判定するか 推論的（inferential） LLM による評価（LLM-as-a-judge）

ガイド／センサーと決定論的／推論的を掛け合わせると、自分がいま何を足そうとしているのかを考える際に便利な 2×2 になります。

決定論的 推論的
ガイド（行動前に導く） AGENTS.md の目次、permission 設定、テンプレート プランニング用サブエージェント、システムプロンプトの指示
センサー（結果を観測させる） テスト、リンター、型チェック、構造テスト LLM によるレビュー、LLM-as-a-judge

本記事で「ハーネスを変える」と言うときは内側のハーネス（Claude Code か OpenCode か）を指し、「ハーネスを育てる」と言うときは外側のハーネス（AGENTS.md や permission や MCP サーバー）を指す、と整理しておくと混乱が減ります。なお同氏と Chris Ford 氏による続編「Harness engineering and agent feedback」（Thoughtworks、2026 年 5 月 13 日）はセンサー側に焦点を当てています（一次情報）。

2.4 境界が曖昧なところ

役割分担はきれいに二分できるわけではなく、いくつか境界が揺れる箇所があります。

論点 LLM 寄りの考え方 ハーネス寄りの考え方 実際の落としどころ
計画 モデルが自分で計画を立てる ハーネスがフェーズ（計画→実装→検証）を強制する Anthropic の長期実行ハーネスでは、初回だけ動く初期化用エージェントが機能一覧（feature_list.json）・進捗ファイル（claude-progress.txt）・初期化スクリプトを整備し、実装用エージェントがセッションごとに 1 機能ずつ進める二段構成を採っています（一次情報）。機能一覧を Markdown でなく JSON にしたのは、エージェントが Markdown の項目を勝手に書き換えたり消したりしやすいからだと説明されています
ツール説明文 モデルが読んで解釈する ハーネスや MCP サーバーの作者が書く ツール定義はモデルが読むプロンプトの一部なので、説明文の品質がそのまま精度に効きます。Anthropic は「Writing effective tools for agents」で、ツール説明文をエージェント自身に評価・改善させる手法を示しています（一次情報）
検証 モデルが自己検証する テストやリンターで機械的に検証する 両方使うのが実務的です。Anthropic の長期実行ハーネスの記事は、モデルが「一度に全部やろうとする」「部分的な進捗を見て完了と宣言する」という 2 種類の失敗をするため、機械的な検証ループが必要だと述べています（一次情報）
訓練 ― ― 最も境界を曖昧にする事実は、フロンティアモデルが自社ハーネス上で追加学習されているという指摘です（二次情報、HumanLayer など）。同じ Claude でも Claude Code と別のハーネスでは、ハーネスが期待する行動パターンとモデルの学習内容の一致度が違います

訓練とハーネスの関係を示す一次情報として、Anthropic の「Harness design for long-running application development」が挙げられます。計画・生成・評価を分けた複数エージェント構成の中で、Sonnet 4.5 ではコンテキスト上限が近づくと作業を早めに切り上げる傾向（context anxiety と呼ばれています）があり、ハーネス側でコンテキストのリセットを入れて対処していたが、Opus 4.5 ではこの傾向が自然に解消され、リセット処理を撤廃して SDK の自動圧縮による単一セッションに戻したと述べられています（一次情報）。ハーネスの最適解はモデルの世代ごとに変わる、ということです。

2.5 セキュリティはハーネスの責務

役割分担の表で「権限管理・承認・サンドボックス」をハーネス側に置きましたが、ここは単なる利便性の話ではなく、エージェント特有の攻撃面に対する防御線です。

Simon Willison 氏は 2025 年 6 月の記事で、エージェントが次の 3 つを同時に持つと攻撃者が容易に情報を盗み出せると整理し、これを lethal trifecta と呼びました（一次情報）。

要素 内容 ハーネス側でどう扱うか
非公開データへのアクセス ソースコード、認証情報、社内ドキュメント 作業ディレクトリ外の読み取りを制限する、.env のような秘密ファイルを既定で拒否する
信頼できないコンテンツへの露出 Web ページ、Issue や PR の本文、他人が書いた MCP ツールの説明文 ツール説明文を人間が確認できるようにする、取得したコンテンツを命令として扱わない
外部への送信能力 HTTP リクエスト、git push、メール送信 ネットワークを既定で遮断し、許可ドメインだけ通す、送信系コマンドは承認制にする

image.png

実際に起きた事例として、Invariant Labs は 2025 年 4 月に、MCP ツールの説明文（description）に悪意ある指示を埋め込み、ユーザーに見えない形で SSH 鍵などを読ませたり他のツールを乗っ取ったりできることを示しました（tool poisoning、一次情報）。さらに 2025 年 5 月には、公開リポジトリの Issue にプロンプトインジェクションを仕込んでおくと、GitHub の MCP サーバー経由でエージェントが非公開リポジトリの内容を公開側に流出させうることを示しています（一次情報）。後者はコードのバグではなく、1 つのトークンが公開・非公開の両方に届くという設計上の問題で、緩和策としてセッションごとに 1 リポジトリに限定することや最小権限のトークンが挙げられています。

MCP 仕様側もこれを受けて Security Best Practices を整備しており（一次情報）、confused deputy 問題（プロキシはクライアントごとの同意を取る、redirect_uri を厳密に照合する）、トークンのパススルー禁止（audience の検証を必須にする）、セッションハイジャック対策（セッション ID を認証に使わない、ユーザー ID に束縛する）が主な内容です。

ハーネス側の実装は次のとおりです。

ハーネス 仕組み 出典
Claude Code 2025 年 10 月に OS レベルのサンドボックスを導入。Linux は Bubblewrap、macOS は Seatbelt を使い、ファイルシステムの分離（作業ディレクトリのみ読み書き）とネットワークの分離（サンドボックス外のプロキシ経由で許可ドメインのみ、新規ドメインは確認）を組み合わせます。ネットワーク分離がないと SSH 鍵などを外部に持ち出されうる、と説明されています。同時に権限確認のプロンプトを 84% 削減できたとしています。実装は sandbox-runtime として OSS 公開されています Anthropic「Beyond permission prompts」（2025 年 10 月 20 日、一次情報）。なお 2025 年 12 月に、許可ドメイン未設定時にネットワーク分離が効かない不具合（CVE-2025-66479、sandbox-runtime v0.0.16 で修正）が公開されています
Codex CLI sandbox_mode（read-only / workspace-write / danger-full-access）と approval_policy（untrusted / on-request / never など）を独立に設定。推奨既定は on-request と workspace-write の組み合わせで、workspace-write ではネットワークは既定でオフ。macOS は Seatbelt、Linux は Landlock と seccomp OpenAI Codex ドキュメント（一次情報）
OpenCode permission 設定で edit / bash / webfetch / websearch をツールごと・コマンドのパターンごとに allow / ask / deny。.env ファイルの読み取りは既定で deny（.env.example は allow）、作業ディレクトリ外の操作（external_directory）と同じ操作の繰り返し（doom_loop）は既定で ask OpenCode ドキュメント（一次情報）

GPT-6 Astra のシステムカード（2026 年 9 月 3 日、一次情報）には、ハーネス側の責務を考えるうえで参考になる記述があります。

項目 内容
能力評価 サイバー能力が OpenAI の Preparedness Framework で Critical に達した初のモデルとされ、適切なツールとアクセスがあれば、人間が逐一指示しなくても未知の脆弱性の発見と悪用ができる、と説明されています
緩和策 モデルのチェックポイントの暗号化とアクセス制御に加え、Astra を使うすべてのツール利用推論に対して、ミスアラインメントの監視と、必要ならワークロードを止められる人間の介在が適用されるとしています。高度な攻撃的タスクは既定で拒否され、正当な用途には Trusted Access の枠組みで段階的に開放されます
Codex の Auto-review あらかじめ指定したサンドボックスの外で実行されるコマンドを、第 2 のモデルが安全性の観点で評価する仕組みが Codex に組み込まれています。評価では、Astra がこの審査を回避しようとしなかったことも確認されています
API 利用時の挙動 監視でフラグが立った場合、ChatGPT や Codex では承認待ちになりうるのに対し、API ではタスクが停止し再開できないことがあるとされています。ハーネス側で停止応答を扱う設計が要ります。Chat Completions は推論とツール利用を結びつけられないため、この監視の対象外です
プロンプトインジェクション GPT-5.6 Sol より耐性が大きく向上したと述べられています。一方で、モデルの思考の監視しやすさ（monitorability）は Sol より低下したとも記載されています（数値は二次情報経由のため本記事では引用しません）

「サンドボックスの外に出るコマンドは別のモデルが審査する」「監視で止まったらハーネスが後始末をする」といった仕組みは、モデルではなくハーネスの側に置かれています。2.2 節の責務表で権限・承認・サンドボックスをハーネスに置いた理由が、フロンティアモデルの安全設計でもそのまま当てはまっています。

「モデルに『秘密を外に出すな』と頼む」のはプロンプトであり、破られる前提で考える必要があります。「出せないようにする」のはハーネスの仕事です。

3. 同じモデルでもハーネスで性能が変わる

「ハーネスが大事」という主張は、数値の裏付けとともに読んだほうが納得しやすいので、公開されている事例を情報源の区分とともに並べます。まず GPT-6 Astra の例を詳しく見て（3.1 節から 3.3 節）、続いてそのほかの事例をまとめます（3.4 節）。

3.1 GPT-6 Astra の ARC-AGI-3：同一モデルで 62.7% と 99.9%

OpenAI は 2026 年 9 月 3 日に新しいフラッグシップモデル GPT-6 Astra を発表し、ARC-AGI-3 を 99.9% で飽和させたと述べています（一次情報）。この数値は ARC Prize Foundation が独立に検証し、Semi-Private セットの検証済みスコアとしてリーダーボードに掲載しています（一次情報。結果ページの精密値は 99.95%）。ここで重要なのは、ARC Prize が同じモデルを 2 種類のハーネスで走らせ、両方を公表している点です。

項目 Standard ハーネス Provider Adapter ハーネス
位置づけ（ARC の説明） プロバイダに依存しない最小構成の同じインターフェースでモデルを比較するための条件。ARC は、将来の AGI ならこの条件で解けるべきだとしています プロバイダが自社モデル向けに設計したコンテキスト管理機能を使ったときの性能を測る条件
仕組み 最小構成。各アクションの後に推論内容は捨てられる リクエスト間で不透明な reasoning 状態を保持し、長い会話は compaction で圧縮して、以前の作業を再利用できるようにする
OpenAI 側の呼び方 ― Responses API ハーネス。推論内容の保持と compaction の 2 設定（3.2 節）
最良スコア 62.7%（reasoning = max） 99.9%（reasoning = high）
同じ reasoning 設定での比較 max 62.7%、high 54.8% max 98.6%、high 99.9%（差は max で 35.8 ポイント、high で 45.1 ポイント）
コスト（評価 1 回分） 26,098 ドル 18,817 ドル
外部ツール（コード実行、Web 検索、ブラウザ） なし なし
MCP なし なし
評価セット Semi-Private Semi-Private

Provider Adapter ハーネスの中身は、7 月に GPT-5.6 Sol を 13.3% から 38.3% に押し上げた「reasoning の保持とコンテキスト圧縮」と同じ考え方です。OpenAI 側はこれを自社の Responses API ハーネスと呼び、ARC-AGI-3 を狙った変更ではなく実運用の性能に合わせた設定だと注記しています（一次情報）。ARC Prize は、最良値どうしで 62.7% から 99.9% への上昇をハーネスによるものだと分析し、今後は Standard と Provider Adapter の両方の結果を条件を明記して併記する方針を示しています（一次情報）。最良値どうしは reasoning の設定が max と high で異なるので、本記事では同じ設定での差（max で 35.8 ポイント、high で 45.1 ポイント）を併記します。どちらで見ても、差の大きさは変わりません。

reasoning の設定ごとのスコアとコストも公開されています。

reasoning 設定 none low medium high xhigh max
Standard ハーネス 35.2% 17.5% 38.6% 54.8% 59.3% 62.7%
Provider Adapter ハーネス 96.7% 98.0% 98.4% 99.9% 98.4% 98.6%
Provider Adapter のコスト（ドル） 23,457 21,298 19,285 18,817 18,147 17,332

Standard ハーネスで none が low を上回っているのは公表値のままです。なお公開 API の GPT-6 Astra では reasoning.effort の none は使えません（一次情報）。ARC の評価表に none の行があるのは検証時の設定です。Provider Adapter では reasoning を上げるほどコストが下がっていますが、ARC はこれを「少ない行動数でゲームを解けるようになるため」と説明しています。また両ハーネスがともに解けた 167 のゲームと reasoning 設定の組み合わせで比べると、Provider Adapter のほうが経過時間で約 3.66 倍速く、総トークンは 49% 少なかったとされています（一次情報）。ハーネスが変わると、スコアだけでなくコストと速度の関係も変わる、という例です。

この結果を本記事のテーマに引きつけると、次の 3 点になります。

論点 内容
「MCP と組み合わせて 99.9% を出した」は誤り ARC Prize の検証ポリシーでは、コード実行を含む追加ツールは既定で無効、Web 検索も無効で、ツールを使う場合は必ず明記されます。Standard・Provider Adapter とも外部ツールも MCP も使っていません。同じ reasoning 設定で 35 ポイント以上の差を生んだのは、コンテキスト管理（reasoning 状態の保持と compaction）です
ツールを使った別実験は分けて公表されている ARC は別に PRO-LONG ハーネスという、コードを実行できるサンドボックス付きの条件でも Astra を評価し、Astra が環境ごとに迷路や戦闘用のソルバースクリプトを自作したことを報告しています。ARC はこの結果を「モデルとツールを合わせた性能」として扱っており、Provider Adapter とは別枠です。PRO-LONG の数値スコアは一次情報には記載がなく、二次情報で流布している値は本記事では未確認とします。PRO-LONG 自体は公開リポジトリと論文があります（参考文献参照）
スコアの意味 ARC-AGI-3 のスコアは正解率ではなく、各レベルの人間の中央値プレイヤーに対する行動効率（RHAE）を集計したものです。人間はすべての環境を解けることが前提で、図 3 の「人間テスター平均 約 48%」は OpenAI が public セットのプレイログから推定した人間テスターの平均 RHAE です。ARC は Astra（reasoning = max）が 96.0% のレベルで人間基準より少ない行動数で解き、行動数は平均 51.7% 少なかったと報告しています。ARC 自身は「AGI だと主張しているわけではない」と明記しています

発表後の第三者評価も添えておきます。Artificial Analysis の総合指数では Astra は 61.2 で GPT-5.6 Sol の 60.9 からほぼ横ばい（上位は Claude Fable 5.1 の 65.7、Claude Opus 5 の 63.1）、コーディングエージェントの指数でも Astra は 67 で、Claude Fable 5.1 と Claude Code の組の 70 を下回ると報告されています（2026 年 9 月 4 日、二次情報）。総合指数がほとんど動かない一方で、ARC-AGI-3 や Terminal-Bench 4.0（Sol の 37.3% から 57.9%、OpenAI 報告値。使用ハーネスは未公表）のようなハーネス込みの評価が大きく動いた、という対比は、ハーネスの寄与を別の角度から示していると見ています。

同じモデルを同じ評価セットで測っても、ハーネス次第で 62.7% にも 99.9% にもなる（reasoning 設定をそろえても 35 ポイント以上の差）。これがフロンティアモデルでも起きているのなら、ローカルモデルとハーネスの組み合わせで振る舞いが変わるのは当然だ、というのが筆者の受け止めです。図 3 は、この Semi-Private セットの検証値（Astra は high と max の組で表示）と、7 月に OpenAI が public セットで報告した GPT-5.6 Sol の値を、評価セットごとに分けて並べたものです。

image.png

3.2 「2 つの設定」の正体：推論内容の保持と compaction

OpenAI の 7 月のブログは、2 つの設定を保持推論（retained reasoning）と compaction と名指ししています（一次情報）。標準的なハーネスは各アクションの後にモデルの非公開の推論内容を捨て、会話が長くなるとコンテキストが一定量を超えた時点で古いメッセージから切り捨てるのに対し、ChatGPT や Codex で使っている設定は推論内容をターンをまたいで保持し、長くなったら要約して続ける、というものです。OpenAI は、モデルは非公開の推論内容を履歴に保持した状態で思考するように訓練されており、ChatGPT や Codex でもその運用で提供している、と説明し、Responses API を使うこと、推論内容を保持すること、compaction を使うことの 3 点を推奨しています（一次情報、筆者による要約）。

API 上の対応物を OpenAI の公式ガイドで確認すると次のとおりです（一次情報。設定名は 2026 年 9 月時点の Reasoning ガイドと Compaction ガイドによります）。

設定 Responses API での具体的な指定 補足
推論内容の保持 reasoning.context を all_turns にする（公式ガイドで all_turns が既定と明記されているのは GPT-5.6 ファミリーで、それ以前のモデルは current_turn が既定。GPT-6 Astra の既定値は一次資料では確認できず、persisted reasoning をサポートするとだけ記載されています）。推論内容を次のリクエストへ渡す方法は 2 つで、store を有効にして previous_response_id で会話をつなぐ（ステートフル）か、応答に含まれる reasoning item の encrypted_content をそのまま次の入力に含める（ステートレス、ゼロデータ保持向け） 推論状態は同じモデルファミリ内でのみ再利用できます。関数呼び出しの途中では、呼び出しと一緒に返ってきた reasoning item を必ず返送することが推奨されています
compaction context_management の compact_threshold を指定すると、コンテキストが閾値を超えたときにサーバー側で自動的に圧縮され、compaction item がストリームに現れる。明示的に行うには POST /responses/compact を呼ぶか、入力に compaction_trigger item を含める 圧縮結果は暗号化された不透明な item で、そのまま次の入力に渡します。会話の途中で reasoning effort を変える configuration_update とは併用できません
Chat Completions との関係 いずれも Responses API の機能で、Chat Completions では使えません。GPT-6 Astra は Chat Completions 自体は使えますが、ツール呼び出しには Responses API が必要です Reasoning ガイドは、Chat Completions も使えるが Responses のほうがモデルの性能を引き出せる、と明記しています

ここが本記事のテーマにとって重要な点です。Provider Adapter ハーネスの 99.9% は、モデルの賢さだけでなく「モデルが訓練時に前提としていた運用（推論内容の保持と要約による継続）をハーネスが再現できるか」で決まっています。ARC の Standard ハーネスはこの運用を再現しないので、同じモデルが 62.7% にとどまります。2.4 節で「モデルはハーネスに合わせて訓練されている」と書いた話が、API のパラメータという具体的な形で現れています。

3.3 ハーネスは「2 つの設定」を実装しているか

サードパーティのハーネスから GPT-6 Astra を使う場合、Responses API を使っているか、reasoning item を往復させているか、compaction をどう扱うかで、同じモデルでも得られる性能が変わることになります。筆者が公式ドキュメントと公開リポジトリで確認できた範囲を表にします（2026 年 9 月上旬時点。未確認の欄が多い点はご了承ください）。

ハーネス 使う API reasoning item の往復 compaction GPT-6 Astra への対応
Codex CLI Responses API 本家の実装 OpenAI の compaction と、実験的なコンテキスト管理 0.153.0 以降（一次情報。API 経由で設定できるようにした PR は rust-v0.153.1 で出荷）
OpenCode Responses API（Vercel AI SDK の OpenAI プロバイダ経由） 実装あり。継続情報の保持や reasoning 要約の分割を直す PR はマージ済みですが、store を無効にした構成で「encrypted content を検証できない」エラー、Azure 経由、古いターンの reasoning の再送など未解決の報告があります（一次情報：GitHub の issue） 独自または SDK 依存（未確認） 個別対応のコミットは未確認
Cline、Aider、Kilo Code、Zed、GitHub Copilot 未確認 未確認（DeepSeek の reasoning_content の往復への対応は一部で進行） 未確認 未確認
Cursor 未確認 未確認 未確認 OpenAI が Cursor へのモデル提供を 2026 年 11 月に終了すると通告した、との報道があり不透明（二次情報）
Claude Code Anthropic Messages API のみ 対象外 対象外 OpenAI モデルは非対応

Codex と同時に告知された「コンテキストウィンドウをまたいでメモを保持し検索できる仕組み」は、公式には Codex 側の新しいコンテキスト保存方法として説明されているだけで、config.toml の正式なキー名は執筆時点の設定リファレンスには載っていません（未確認）。既存の関連設定として model_auto_compact_token_limit や compact_prompt、実験的なコンテキスト管理の機能フラグがあります。

OpenAI のモデルに限らず、思考モデルの推論内容を履歴にどう残すかはハーネスの実装差が出やすい部分です。DeepSeek のようにツール呼び出しを挟む場合に reasoning_content を返送しないと API がエラーを返すモデルでは、OpenCode、GitHub Copilot Chat、Kilo Code など複数のハーネスで修正対応が入っています（一次情報：各リポジトリの issue）。この話は 6 章でローカル構成に引きつけて扱います。

3.4 そのほかの事例

事例 内容 情報源の区分
ARC-AGI-3（OpenAI、2026 年 7〜8 月） 同一モデル（GPT-5.6 Sol）で、ARC の公式ハーネスでは public セット 13.3%（Semi-Private セットでは 7.8%）、reasoning の保持とコンテキスト圧縮の 2 設定を加えた Responses API ハーネスでは public セット 38.3%。出力トークンは約 6 分の 1。参考として OpenAI が public セットのログから推定した人間テスターの平均は約 48% 一次情報（OpenAI ブログ「How enabling two settings tripled our scores on the ARC-AGI-3 benchmark」および「Codex as a platform」、ARC Prize リーダーボード）
Tool Search Tool（Anthropic、2025 年 11 月） ツール定義を最初から全部渡す代わりに、必要なときに検索して読み込む方式にしたところ、多数の MCP ツールを使う社内評価で Opus 4 が 49% から 74%、Opus 4.5 が 79.5% から 88.1% に改善し、ツール定義によるコンテキスト消費を約 85% 削減したと報告されています 一次情報（ただしベンダー内部評価で、評価データは非公開）
Code execution with MCP（Anthropic、2025 年 11 月） MCP ツールを直接呼ぶ代わりに、コード API として提示してエージェントにコードを書かせて実行する方式により、Google Drive から Salesforce へデータを渡す例示ワークフローでトークン消費が 150,000 から 2,000（98.7% 削減）になったと報告されています 一次情報（例示値）
長期実行ハーネス（Anthropic、2025〜2026 年） 計画・実装・検証の役割を分けた複数エージェント構成と進捗ファイルにより、SDK の自動圧縮だけでは完遂できなかった長時間のアプリ開発を完遂させた。モデル世代によりコンテキストリセットの要否が変わった 一次情報
Terminal-Bench 2.0 / 2.1（Laude Institute ほか） リーダーボードの各行は「エージェント（ハーネス）とモデルの組」であり、ハーネスがスコアの一部として扱われています。2.0 は 229 候補から選抜した 89 タスク、参照ハーネス Terminus 2、pass@1 を 3 回平均。2.1 は 28 タスクを修正した版で、同じ組でもスコアが動いています。同じモデル名でも、公式ハーネス・各社ハーネス・研究用ハーネスでスコア表示が割れることが指摘されています 一次情報（tbench.ai）。個別ペアの数値差は二次情報が多いため本記事では引用しません
SWE-bench Verified と SWE-bench Pro 各社が自社スキャフォールドで報告する Verified の数値と、Scale AI が標準化したスキャフォールドで測る Pro の数値には大きな開きがあり、同一モデルでもスキャフォールドの違いだけで 10 ポイント前後の差が出ると複数の分析が指摘しています 二次情報（数値は分析サイトごとに異なるため、個別の値は本記事では引用しません）

図 4 は上表の Tool Search と Code execution with MCP について、対策前後のトークン数を並べたものです。

image.png

これらから言えるのは、ベンチマークの数値を読むときに「どのハーネスで、どの評価セットで測ったか」を必ず添えて読む必要がある、ということです。ARC Prize が Standard と Provider Adapter を条件付きで併記する方針に切り替えたのは、読み手にも同じ姿勢を求めているのだと理解しています。ローカルモデルの比較記事でも、SWE-bench 系や Terminal-Bench 系の数値がどのハーネスによるものかを確認しないと、ハーネスの差をモデルの差として読み違えます。

4. MCP はどこにいるのか

4.1 MCP の基本構造

MCP（Model Context Protocol）は Anthropic が 2024 年 11 月 25 日に公開したオープンなプロトコルで、LLM アプリケーションと外部のデータソースやツールを接続する方法を標準化するものです（一次情報）。構造は次のとおりです。

要素 役割
ホスト LLM アプリケーション本体。コーディングエージェントの場合はハーネスがこれにあたります
クライアント ホスト内でサーバーと 1 対 1 の接続を保持する部分
サーバー ツールやデータを提供する側。GitHub、Jira、データベース、ブラウザ操作などを公開します
tools サーバーが公開する呼び出し可能な関数。名前、説明文、JSON Schema による入力定義を持ちます
resources URI で識別される読み取り用のデータ
prompts 再利用可能なプロンプトのテンプレート
sampling / elicitation / roots クライアント側が提供する機能。サーバーからモデルに生成を依頼する、ユーザーに追加入力を求める、操作対象のディレクトリを伝える（2026-07-28 リビジョンで roots と sampling は非推奨になりました。4.4 節参照）
transport stdio（ローカルプロセス）と Streamable HTTP（リモート）。メッセージ形式は JSON-RPC 2.0

4.2 LLM は MCP を知らない

本記事で最も強調したい点は、LLM 自身は MCP というプロトコルを一切扱っていない、ということです。

ハーネスは起動時に各 MCP サーバーへ tools/list を送ってツール定義を集め、それを LLM API の function calling 用スキーマに変換してモデルに渡します。モデルが返すのは「このツールをこの引数で呼びたい」という tool_use（OpenAI 互換 API では tool_calls）だけで、実際にそれを JSON-RPC の tools/call として MCP サーバーへ送り、結果を tool_result として会話履歴に積むのはハーネスです。変換は次の程度の単純なものです。

# MCP サーバーから tools/list で受け取ったツール定義（抜粋）
mcp_tool = {
    "name": "get_issue",
    "description": "Issue の内容を取得する",
    "inputSchema": {
        "type": "object",
        "properties": {"id": {"type": "string"}},
        "required": ["id"],
    },
}

# OpenAI 互換 API 向け（OpenCode などがローカルモデルを呼ぶときの形）
openai_tool = {
    "type": "function",
    "function": {
        "name": mcp_tool["name"],
        "description": mcp_tool["description"],
        "parameters": mcp_tool["inputSchema"],
    },
}

# Anthropic Messages API 向け（Claude Code が Claude を呼ぶときの形）
anthropic_tool = {
    "name": mcp_tool["name"],
    "description": mcp_tool["description"],
    "input_schema": mcp_tool["inputSchema"],
}

モデルから見ると、get_issue が MCP サーバー由来なのか、ハーネス内蔵のツールなのか、シェルスクリプトを包んだものなのかは区別できません。区別する必要もありません。つまり MCP は「ハーネスと外部ツールの間」の規約であって、「LLM とツールの間」の規約ではありません。海外の解説記事にある「MCP は開発者のためのものであって LLM のためのものではない」という表現は、この構造を端的に言い表しています（二次情報）。

image.png

この往復を時系列に並べたのが図 6 です。LLM に届くのは関数スキーマ付きのメッセージと tool_result だけで、tools/list や tools/call といった MCP のメッセージは LLM の目に触れません。

image.png

4.3 内蔵ツール・CLI・MCP の使い分け

ハーネスが外部の機能を使う手段は MCP だけではありません。

手段 仕組み 長所 短所
内蔵ツール ハーネスが直接実装（Read、Edit、Bash など） 最も安定し、ツール説明文もモデルに合わせて調整済み。コンテキスト効率がよい ハーネスに用意されたものしか使えない
CLI を Bash から叩く gh、git、aws などの既存コマンドを Bash ツール経由で実行 モデルは学習データで CLI の使い方を知っている。追加のツール定義が不要で、コマンドのパターン単位で権限を制御できる 認証やトークン管理をコマンドごとに考える必要がある。出力のパースはモデル任せ
MCP サーバー 標準プロトコルで接続し、ツール定義を動的に取得 ハーネスをまたいで再利用できる。OAuth などの認証をサーバー側で吸収できる。構造化された入出力 ツール定義がコンテキストを消費する。サーバープロセスの管理が必要。権限の粒度はツール単位になりがち

4.4 仕様の変遷とガバナンス

仕様リビジョン 主な内容
2024-11-05 初版。2024 年 11 月 25 日に公開・OSS 化。JSON-RPC 2.0、stdio と HTTP+SSE
2025-03-26 OAuth 2.1 ベースの認可、HTTP+SSE に代わる Streamable HTTP transport、JSON-RPC バッチ、tool annotations など
2025-06-18 JSON-RPC バッチの削除、構造化ツール出力（structuredContent）、elicitation、MCP サーバーを OAuth の Resource Server と位置づけ、Resource Indicators（RFC 8707）の必須化、MCP-Protocol-Version ヘッダーの必須化、セキュリティのベストプラクティス追加
2025-11-25 非同期タスク、sampling と elicitation の拡張、Client ID Metadata Documents、拡張機構など、公開以来最大規模の変更
2026-07-28 プロトコルレベルのセッション（Mcp-Session-Id ヘッダー）を廃止してステートレス化。initialize ハンドシェイクを廃止し、プロトコルバージョンとクライアント機能を毎リクエストの _meta で運ぶ。サーバー起点の sampling / elicitation / roots 呼び出しを Multi Round-Trip Requests（MRTR）に置き換え。Tasks を core から公式拡張へ移動し、MCP Apps（サーバー側で描画する UI）も公式拡張として整理。roots / sampling / logging を非推奨化（削除ではなく、最低 12 か月の移行期間を置くライフサイクルポリシーが同時に導入）。ping と logging/setLevel を削除。tools/list や prompts/list などの結果に ttlMs と cacheScope を付け、TTL 付きでキャッシュできるように（CacheableResult）

（リビジョン識別子は「最後に後方互換性のない変更が入った日付」です。上表は公式 changelog に基づきます）

image.png

2026-07-28 リビジョンはハーネス実装者に影響が大きい変更です。公式ブログはこのリビジョンを、双方向でステートフルなプロトコルからリクエスト／レスポンス型のステートレスなプロトコルへの転換と説明しています（一次情報）。tools/list などの結果に ttlMs と cacheScope が付いたことで、ハーネスはツール一覧を TTL 付きでキャッシュし、再接続をまたいで上流のプロンプトキャッシュを安定させやすくなりました。ツール一覧が接続中に不変になったわけではなく、キャッシュ可能になった、という理解が正確です。sampling と roots の非推奨化は「クライアント側が提供する機能」を整理する方向ですが、Tasks・MCP Apps・MRTR といった拡張も同時に整備されており、公式は MCP をエージェント的ワークフローの data and interactivity substrate（データと対話性の基盤）と位置づけています。roots はツール引数やサーバー設定へ、sampling は LLM プロバイダの API を直接使う形へ、logging は stderr や OpenTelemetry へ移行する案が示されています。

ガバナンス面では、2025 年 12 月 9 日に Anthropic が MCP を Linux Foundation 傘下に新設された Agentic AI Foundation（AAIF）へ寄贈したことが確認できます（一次情報）。Anthropic、Block、OpenAI が共同創設メンバーで、同時に Block が goose を、OpenAI が AGENTS.md を寄贈しています。寄贈時点で公開稼働中の MCP サーバーは 1 万を超え、TypeScript と Python の SDK は累計 10 億ダウンロードを超えたとされています。仕様が特定ベンダーの手を離れて業界標準として管理される体制になった点は、ハーネスを選ぶ側から見ると「MCP サーバーへの投資がハーネス間で持ち運べる」ことの裏付けになります。

4.5 課題：ツール定義がコンテキストを食う

MCP の最大の実務上の課題は、ツール定義がそのままコンテキストウィンドウを占有することです。Anthropic の「Introducing advanced tool use」では、GitHub・Slack・Sentry・Grafana・Splunk のような典型的な複数サーバー構成で 58 個程度のツールを接続すると、会話を始める前に約 55,000 トークンを消費するという例が示されています（一次情報の例示値。Jira サーバー単体で約 17,000 トークンという例も同記事準拠の解説で引用されています）。GitHub の MCP サーバー単体で数万トークン規模になるという実測報告もあります（二次情報）。

さらに、ツール定義だけでなく中間結果もコンテキストを通ります。「大きな表を取得してその一部を別のツールに渡す」という処理では、表全体がモデルの入力として往復します。

ローカル LLM ではこの問題がより深刻です。実用的なコンテキスト長が 32K から 128K 程度で、プリフィル速度もクラウド API より遅いため、数万トークンのツール定義は「最初の応答までの時間」と「残りの作業領域」の両方を直接圧迫します。図 8 の 3 段目に示したように、32K のウィンドウに 55K のツール定義を先読みすれば、会話を始める前にウィンドウが尽きます。ローカルモデルを使う人が MCP に消極的になりやすい理由の一つはここにあると見ています。

image.png

4.6 対策

対策 仕組み 出典
Tool Search / 遅延ロード ツール定義を最初に渡さず、検索用ツールで必要なものだけを都度ロードする。Claude Developer Platform では defer_loading の指定で利用可能 Anthropic「Introducing advanced tool use」（一次情報）
Code execution with MCP MCP サーバーをファイルシステム上のコード API（例：servers/github/getIssue.ts）として見せ、エージェントに TypeScript を書かせてサンドボックスで実行する。中間データがモデルを通らず、ツール定義もコード探索で必要な分だけ読む。Cloudflare の Code Mode が同系統として記事中で比較されています Anthropic「Code execution with MCP」（一次情報）
Agent Skills 手順や知識を SKILL.md にまとめ、必要になったときに読み込む。ツールではなく「やり方」を遅延ロードする仕組み Anthropic「Equipping agents for the real world with Agent Skills」（一次情報）。Codex CLI や OpenCode など他のハーネスにも採用が広がっていると報告されています（二次情報）
CLI へ寄せる MCP でなくてよいものは Bash から CLI を叩く 4.3 節、4.7 節
サーバーを絞る プロジェクトごとに接続する MCP サーバーを限定する 運用上の基本

Tool Search の詳細を、クラウド API と Claude Code の両面から表にします。ローカル LLM を使う場合に効いてくる制約があるためです。

項目 内容 情報源の区分
API での指定 ツール定義に defer_loading: true を付け、tool_search_tool_regex_20251119 または tool_search_tool_bm25_20251119 を有効にする。beta ヘッダー advanced-tool-use-2025-11-20。Sonnet 4.5 以降と Opus 4.5 以降が対象。遅延ロードできるツールは最大 10,000 個、検索結果は既定 5 件 一次情報
使いどころの目安 ツールが 10 個以上、または定義の合計が 10K トークンを超える場合に推奨。10 個未満で毎回すべて使うなら通常の呼び出しでよい 一次情報
OpenAI 側の対応 OpenAI にも Tool search があり、Responses API の tools 配列に tool_search を追加し、遅延させたい関数や MCP サーバー定義に defer_loading: true を指定する。gpt-5.4 以降が対象で、GPT-6 Astra も対応。見つかったツール定義はコンテキストの末尾に追加され、プロンプトキャッシュを保つ設計とされています 一次情報（OpenAI の Tool search ガイド）
Claude Code での挙動 2.1 系から MCP ツールの検索が既定で有効。環境変数 ENABLE_TOOL_SEARCH で true / false / auto（定義の合計がコンテキストの 10% 未満なら先読み）を切り替え。.mcp.json でサーバー単位に alwaysLoad: true を指定すると常時ロード 二次情報中心（設定名は公式ドキュメントで再確認をお願いします）
ローカル LLM での制約 ANTHROPIC_BASE_URL が Anthropic 以外のホストを指す場合、Claude Code は遅延ロードを使わず全ツールを先読みする挙動に戻ると報告されています。つまりローカルモデルで Claude Code を使うと、MCP ツール定義のコンテキスト消費は丸ごと払うことになります 二次情報
プロンプトキャッシュへの影響 遅延ロード時は MCP サーバーの接続・切断があっても履歴が追記されるだけでキャッシュが保たれ、先読み時はツール一覧の変化でキャッシュが無効化されると説明されています 二次情報

なお AGENTS.md は Linux Foundation の発表時点で 6 万以上の OSS プロジェクトに採用され、Codex、Cursor、Devin、Gemini CLI、GitHub Copilot、Jules、VS Code などが対応しているとされています（一次情報）。Anthropic だけでなく OpenAI も Tool search を備えるようになり、指定名まで同じ defer_loading です。「ツール定義をすべて常時 LLM に渡さない」という方向は複数ベンダーに共通していると言えます。

4.7 「MCP は不要」論争の整理

2026 年に入ってから、日本語圏でも「MCP は CLI に負けた」「MCP を使わなくても CLI で十分」といった記事が相次ぎました（二次情報。参考文献に列挙します）。論点を整理すると次のようになります。

批判 内容 反論・補足
プロトコルが冗長 モデルは gh や git や aws の使い方を学習済みで、MCP は通信層を被せただけに見える 学習済みの CLI ならそのとおりですが、社内システムや新しい SaaS の API はモデルが知りません。動的にツール定義を配れる価値はそこにあります
プロセス管理が不安定 MCP サーバーは常駐プロセスで、初期化や再接続で不安定になりやすい stdio サーバーの運用は確かに手間です。Streamable HTTP のリモートサーバーや、2026-07-28 リビジョンのステートレス化はこの方向の改善です
権限の粒度が粗い MCP はツール単位でしか許可・拒否できないが、CLI なら「gh pr view は許可、gh pr merge は確認」のようにコマンドのパターン単位で制御できる ハーネス側の permission 設計に依存する部分で、MCP 仕様側でも tool annotations（読み取り専用か、破壊的かなどのヒント）が用意されています
コンテキストを食う 4.5 節のとおり Tool Search、Code execution with MCP で大幅に緩和されています。ただしローカル LLM では緩和策が効かない構成があります（4.6 節）
セキュリティ ツール説明文経由のインジェクションなど（2.5 節） 仕様側の Security Best Practices とハーネス側のサンドボックスで対処する領域で、CLI にすれば消える問題ではありません
認証 ― OAuth が必要な API を Bash から毎回トークン取得して叩くのは非現実的で、ここは MCP の明確な強みです

全体としては「CLI で済むものは CLI、認証や再利用性が要るものは MCP、手順は Skills」というハイブリッドに落ち着いている、と筆者は見ています。ローカル LLM を使う場合は 4.5 節の事情から CLI 寄りに倒すのが現実的で、MCP はコンテキストに余裕のあるクラウドモデルや、遅延ロードに対応したハーネスで使う、という使い分けになります。

4.8 関連プロトコルとの関係

MCP と並んで名前を聞くプロトコルを、どの層の規約かで整理します。

プロトコル 規約の相手 発案元 備考
MCP エージェント（ハーネス）とツール Anthropic、2024 年 11 月 2025 年 12 月に AAIF へ寄贈
A2A（Agent2Agent） エージェントとエージェント Google、2025 年 4 月 Linux Foundation へ寄贈済み
ACP（Agent Client Protocol） エージェントとエディタ Zed、2025 年 8 月 LSP のエージェント版。Gemini CLI などが対応。IBM の旧 Agent Communication Protocol（A2A に統合）と略称が同じで別物
AG-UI エージェントとユーザー UI CopilotKit、2025 年 UI 層のイベント規約
Codex app-server ハーネスとその利用側（IDE など） OpenAI、2026 年 1.3 節。ハーネスを部品として組み込むための JSON-RPC。Claude Agent SDK が同じ役割を担います

これらは競合ではなく層が違います。一つのコーディングエージェントが、エディタとは ACP、ツールとは MCP、他のエージェントとは A2A で話す、という構成があり得ます。

5. 主要ハーネスの比較

筆者が確認できた範囲で、主要なハーネスの設計上の特徴を並べます。各項目は 2026 年 9 月上旬時点の公式ドキュメントや公開リポジトリに基づきますが、この表は特に陳腐化が早いため、利用時は各公式ドキュメントで再確認をお願いします。

ハーネス 提供元 / ライセンス 対応モデル MCP 権限・サンドボックス プロジェクト指示
Claude Code Anthropic / 非 OSS Claude（Anthropic 互換エンドポイント経由で他モデルも接続可） クライアント。MCP ツールの遅延ロード対応。claude mcp serve で自身をサーバーとしても公開可 permission mode、allow / ask / deny ルール、hooks、Bubblewrap / Seatbelt による OS サンドボックス CLAUDE.md
OpenCode SST チーム発（GitHub は anomalyco/opencode）/ MIT 非依存（多数のプロバイダとローカルモデル） クライアント permission 設定でツールごと・コマンドのパターンごとに allow / ask / deny。.env は既定 deny AGENTS.md
Codex CLI OpenAI / Apache-2.0 OpenAI モデル中心。model_providers 設定でローカルモデル（Ollama、LM Studio など）も接続可 クライアント。codex mcp-server で自身をサーバーとしても公開可 sandbox_mode と approval_policy を独立に設定。macOS は Seatbelt、Linux は Landlock と seccomp AGENTS.md
Antigravity CLI（旧 Gemini CLI） Google / Apache-2.0（Gemini CLI） Gemini クライアント。ACP の実験的対応あり サンドボックス（Docker / Seatbelt）、承認フロー GEMINI.md（Gemini CLI 時点）
Cline Cline / Apache-2.0 非依存（BYOK、ローカル可） クライアント。MCP マーケットプレイスあり Plan / Act モードによる人間の介在、自動承認の設定 .clinerules
Aider Paul Gauthier 氏 / Apache-2.0 非依存（LiteLLM 経由） ネイティブ対応なし（2026 年半ば時点。要望 issue がオープンのまま。サードパーティのブリッジは存在） git 前提。編集ごとに自動コミット、OS サンドボックスなし .aider.conf.yml

この表の周辺で 2026 年に起きた動きを補足します（いずれも公開前に最新状況の再確認をお願いします）。

出来事 内容 情報源の区分
Gemini CLI から Antigravity CLI へ Google は 2026 年 6 月 18 日に、無料版と AI Pro / AI Ultra 向けの Gemini CLI と Gemini Code Assist IDE 拡張の提供を終了し、後継を Antigravity CLI（コマンド agy、Go 実装）としました。Gemini Code Assist の Standard / Enterprise と有償 API キーでの利用は影響を受けないとされています 一次情報（Google Developers Blog）
Roo Code の終了 Cline から派生した Roo Code は 2026 年 4 月に終了が発表され、5 月 15 日にリポジトリがアーカイブされました。移行先として Cline が案内されています 二次情報
Kilo Code の買収 Cline と Roo Code を統合した Kilo Code は 2026 年 7 月 15 日に Anaconda に買収されました 一次情報（Anaconda のプレスリリース）

設計思想の対比として分かりやすいのは Claude Code と OpenCode です。Claude Code はモデルとハーネスを同じ会社が作っており、内蔵ツール（Read / Edit / Write / Bash / Grep / Glob / WebFetch / Task / Skill）の説明文からコンテキスト圧縮のタイミングまで Claude に合わせて調整されています。その分、常時ロードされる定義も大きく、Task と Skill の定義だけで約 15,000 トークン（200K の約 7.5%）を占めるという指摘が GitHub の issue にあります（二次情報）。OpenCode はモデルとハーネスを切り離すことを設計の中心に置き、同じ TUI から任意のプロバイダやローカルモデルを切り替えられます。前者は「深い統合による予測可能性」、後者は「モデル選択の自由と細かい権限制御」を取っており、どちらが上という話ではなく、2.4 節の「モデルはハーネスに合わせて訓練されている」問題をどう扱うかの違いだと理解しています。

権限設定の書き方を見比べると、ハーネスが「行動空間の制約」を担っていることが具体的に分かります。

Claude Code（settings.json）の例:

{
  "permissions": {
    "allow": ["Read", "Bash(npm test:*)", "Bash(git status:*)"],
    "deny": ["Bash(rm -rf:*)"]
  }
}

OpenCode（opencode.json）の例（公式ドキュメントの例に基づきます）:

{
  "$schema": "https://opencode.ai/config.json",
  "permission": {
    "edit": "ask",
    "bash": {
      "*": "ask",
      "git status*": "allow",
      "git diff*": "allow",
      "pnpm test*": "allow",
      "rm -rf*": "deny"
    },
    "webfetch": "allow",
    "websearch": "allow"
  }
}

OpenCode ではエージェント単位（build など）や Markdown で定義するサブエージェントの frontmatter でこの設定を上書きできます。パターンの書き方には注意点があり、"grep *" は引数付きの grep を許可しますが "grep" だけでは引数付きの実行を許可しません。またコンテナなど対話 UI がない環境では ask が応答待ちで止まるため、allow と deny だけで書く必要があります（二次情報）。

どちらもモデルに「rm -rf をするな」と頼んでいるのではなく、ハーネスが機械的に止めています。プロンプトはお願いであり、ハーネスは強制である、という日本語圏の記事にある整理（二次情報）はこの点を突いています。

6. ローカル LLM で見える「第 4 の層」

クラウドの API を使っている限り、LLM とハーネスの 2 層で話が済みます。ローカル LLM を使うと、その間にもう 1 層あることが見えてきます。実行主体として数えるとハーネス・推論サーバー・モデルの 3 つで、その間にある API は実行主体ではなくインターフェースの境界ですが、本記事ではこの境界も含めて便宜上「4 層」と呼びます。クラウドでは推論サーバーの層が提供元の内側に隠れているだけで、ローカルでは llama.cpp や vLLM として表に出てきます。

6.1 推論サーバーとチャットテンプレート

image.png

層 例 ツール呼び出しに関する責務
ハーネス OpenCode、Cline、Claude Code tools のスキーマを API リクエストに載せる。返ってきた tool_calls を実行する
API 境界 OpenAI 互換の /v1/chat/completions、Anthropic 互換の /v1/messages ハーネスと推論サーバーの間のインターフェース。実行主体ではないが、ツール定義や reasoning の受け渡し形式を決める
推論サーバー llama.cpp（llama-server）、vLLM、Ollama、LM Studio JSON のツール定義を、モデル固有のチャットテンプレート（Jinja）でプロンプトに展開する。モデルが出力したテキストをパースして tool_calls の JSON に戻す。コンテキスト長やサンプリングの設定を持つ
モデル Qwen 系、DeepSeek 系、GLM 系、gpt-oss、Devstral など 学習時に決まった形式でツール呼び出しを出力する

クラウド API ではこの推論サーバーの層をモデル提供元が整えて隠しているので意識せずに済みますが、ローカルではここが自分の責任範囲になります。冒頭で挙げた「ツールを呼ばずに説明文だけ返す」「編集ツールの引数が壊れる」といった症状は、LLM でもハーネスでもなく、この層の設定不備が原因になりがちです。

6.2 推論サーバーの中で起きていること

OpenAI 互換 API で tools を渡したとき、llama.cpp のサーバー内部では次の 3 段階が動きます（llama.cpp のドキュメント、一次情報）。図 10 は Hermes 形式のモデルに get_issue を渡した場合の各段階の中身です。

image.png

段階 内容 確認・調整の手段
テンプレート展開 モデルのチャットテンプレート（Jinja）に tools を渡してプロンプト文字列を組み立てる。llama-server では --jinja を付けないとテンプレートのツール対応が使われません --chat-template-file でテンプレートを差し替えられます。サーバーの /props でテンプレートを確認できます
生成 モデルが自分の形式（6.3 節）でツール呼び出しを含むテキストを出力する GBNF grammar で JSON 形式を強制することもできます
パース 生成テキストからツール呼び出しを取り出し、OpenAI 形式の tool_calls に変換する。llama.cpp は PEG ベースのパーサに移行しており、引数 JSON が途中で切れた場合の補修（JSON healing）も行います 並列ツール呼び出しは既定で無効で、リクエストの parallel_tool_calls: true で有効化します

vLLM も同じ構造で、--enable-auto-tool-choice、--tool-call-parser、--reasoning-parser の 3 つを揃えて指定する必要があります（一次情報）。reasoning 部分はツール呼び出しのパース対象にならず、最終出力だけがパースされます。

プロンプトキャッシュもこの層の責務です。llama-server はスロットごとにプロンプトのプレフィックスをキャッシュし、前回と共通する部分の再計算を省きます。ハーネスが履歴の途中を書き換える（要約で差し替える、ツール一覧を変える）とプレフィックスが変わってキャッシュが効かなくなるため、4.6 節のプロンプトキャッシュの話はローカルでも同じように効いてきます。

3.2 節で見た「推論内容の保持と compaction」をローカル構成に当てはめると、責務が分散します。OpenAI の Responses API では、推論状態の保持（encrypted_content や previous_response_id）と圧縮（compaction item）を提供元が一体で用意していますが、ローカルでは次のように分かれます。

責務 クラウド API（OpenAI Responses API） ローカル構成
推論内容を本文から分離する 提供元（reasoning item として返る） 推論サーバー（vLLM の --reasoning-parser、llama.cpp の --reasoning-format）。reasoning_content として返す
過去ターンの推論内容を履歴に残すか捨てるか 提供元（reasoning.context と encrypted_content。同じモデルファミリ内で再利用） チャットテンプレートとハーネスの両方。モデルごとに規則が違う（下表）
長くなった履歴の圧縮 提供元（compact_threshold、/responses/compact） ハーネス（OpenCode などの自動圧縮）。圧縮するとプロンプトキャッシュのプレフィックスが変わる

image.png

モデルごとの規則は、各配布元の公式ドキュメントで次のように定められています（一次情報）。

モデル 過去ターンの推論内容の扱い ツール呼び出しの途中
gpt-oss（Harmony 形式） final チャンネルの応答を出した後の次のターンでは、analysis チャンネル（推論）は落とす 関数呼び出しは推論の一部として行われるため、final を出す前の呼び出しの途中では直前の analysis を渡す必要がある
Qwen3 系 履歴には最終出力だけを含め、thinking の内容は含めない。チャットテンプレートが過去ターンの think を除去する テンプレートを使わない実装では開発者の責任。思考の有無の切り替えや空の think ブロックの扱いで KV キャッシュの再利用が壊れる報告あり
DeepSeek（thinking mode） ツールを使わない会話では過去ターンの reasoning_content は無視される ツール呼び出しを挟む場合、途中の assistant メッセージの reasoning_content を後続のリクエストで返送する必要があり、返送しないと API がエラーを返す

つまり「Provider Adapter が保持している推論状態」に相当するものは、ローカルでは、推論サーバーが正しく分離し、テンプレートがモデルの規則どおりに扱い、ハーネスが規則に従って履歴を組み立てる、という 3 者の協調で初めて成立します。3.3 節で触れた DeepSeek の reasoning_content の往復バグは、この分担の 3 番目が抜けた例です。

6.3 モデルごとのツール呼び出し形式

第 4 の層で最も引っかかりやすいのが、モデルごとにツール呼び出しの出力形式が違う点です。主なオープンウェイトモデルについて、配布物のチャットテンプレートと llama.cpp / vLLM のドキュメントをもとに整理します（パーサ名はバージョンによって変わるため、実際の値は vllm serve --help や各ドキュメントで確認してください。形式の細部は各モデルの chat_template を参照してください）。

モデル系 ネイティブのツール呼び出し形式 思考（reasoning）との併用 llama.cpp vLLM の --tool-call-parser
Hermes 系（NousResearch） <tool_call> タグで囲んだ JSON 可 対応 hermes
Qwen3（Instruct / Thinking） Hermes 形式（<tool_call> + JSON） 可（--reasoning-parser qwen3） 対応 hermes
Qwen3-Coder / Qwen3-Coder-Next XML 風の function / parameter タグ形式 Coder 系は非思考が基本 対応（--jinja 必須） qwen3_coder または qwen3_xml
DeepSeek V3 / R1 系 専用トークンで区切る独自形式 可（<think>） 対応 deepseek_v3 系、思考は deepseek_r1
GLM-4.5 / 4.6 系 XML 風（<tool_call> に引数のキーと値を並べる） 可 対応 glm45 系
Kimi K2 系 専用トークンで区切る独自形式 可（Thinking 版） 対応 kimi_k2
gpt-oss Harmony 形式（channel で分離） 可 対応 Harmony 対応パーサ、思考は gptoss 系
MiniMax M2 XML 風の独自タグ 可 対応 minimax 系
Llama 3.x JSON、または python_tag トークンによる呼び出し 限定的 対応 llama3_json など
Mistral / Devstral TOOL_CALLS トークン + JSON 限定的 対応 mistral
Gemma 3 ネイティブのツール呼び出しトークンなし（プロンプト指示で JSON を出させる方式） ― テンプレート次第 ―

この表から言えることは 2 つあります。第一に、同じ「OpenAI 互換 API」でも、その裏でモデルごとに違うテキスト形式を出し、サーバーが正しくパースして初めてハーネスに tool_calls が届く、ということです。第二に、Qwen3-Coder のようにモデル配布元が専用のパーサを同梱・提供している場合があり、これは「モデルが特定のハーネスや推論経路を想定して作られている」ことの現れです（6.6 節）。

6.4 症状と疑うべき層

症状 疑うべき層 確認すること
ツールをまったく呼ばず、コードをテキストで返す 推論サーバー / モデル チャットテンプレートがツールに対応しているか（llama.cpp なら --jinja の指定とテンプレートの内容）。モデルがツール呼び出しを学習しているか（6.3 節の表で「なし」のモデルはプロンプト指示に頼ることになります）
ツール呼び出しが JSON ではなく本文中にタグ付きテキストとして出てくる 推論サーバー サーバー側のパーサがそのモデルの出力形式に対応しているか。量子化配布物に同梱されたテンプレートが壊れていないか（Unsloth などがテンプレート修正版を配布しています）
ストリーミング時だけツール呼び出しが壊れる 推論サーバー ストリーミングのパーサは非ストリーミングと別実装のことがあり、末尾のトークンが欠けるなどの不具合報告があります（vLLM の issue など、二次情報）。ストリーミングを切って再現するか確認
引数の JSON が途中で切れる、長い編集で壊れる 推論サーバー コンテキスト長の設定（Ollama の num_ctx など。既定値が小さい環境があります）、最大出力トークン数。llama.cpp の JSON healing が効いているか
数ターンで急に文脈を忘れる 推論サーバー / ハーネス コンテキスト長がハーネスの想定より短くないか。ハーネスの自動圧縮が効いているか
思考（reasoning）を出すモデルでツール呼び出しが不安定 推論サーバー / ハーネス 思考部分とツール呼び出し部分の分離をサーバーが正しく処理しているか（--reasoning-parser の指定）。ハーネスが reasoning フィールドを扱えるか
毎ターン考え直しているように見え、前のターンの結論を引き継がない ハーネス / API 推論内容が履歴に残っていない。OpenAI のモデルなら Chat Completions を使っていないか、reasoning item を落としていないか。ローカルの思考モデルなら 6.2 節の規則どおりに履歴を組んでいるか
DeepSeek で reasoning_content を返送するよう求めるエラーが出る ハーネス ツール呼び出しを挟むときに reasoning_content を返送していない
OpenAI の Responses API で encrypted content を検証できないというエラーが出る ハーネス reasoning item の encrypted_content の返送や順序の不備、モデルファミリをまたいだ再利用
動くが極端に遅い 推論サーバー / ハーネス ツール定義や AGENTS.md でプリフィルが肥大していないか（4.5 節）。プロンプトキャッシュがハーネスの履歴の並べ方で無効化されていないか（6.2 節）

「モデルが悪い」と結論づける前に、この表の上から順に潰していくと、モデルの評価が公平になります。

6.5 Claude Code をローカルモデルで動かす場合

Claude Code は Anthropic Messages API を話すため、ローカルモデルを使うには Anthropic 互換のエンドポイントが必要です。

推論サーバー Anthropic 互換 /v1/messages の対応 情報源の区分
llama.cpp（llama-server） 2026 年 1 月に対応（PR #17570）。/v1/messages と /v1/messages/count_tokens を実装し、内部で Anthropic 形式を OpenAI 形式に変換。ストリーミング、tool_use / tool_result、画像入力、extended thinking に対応。ツール利用には --jinja が必須。README では Anthropic API との完全互換は主張せず「多くのアプリケーションで十分」としています 一次情報（llama.cpp リポジトリ、Hugging Face 公式ブログ 2026 年 1 月 19 日）
vLLM stable 版のドキュメントに /v1/messages と /v1/messages/count_tokens が掲載され、Claude Code 連携のページで ANTHROPIC_BASE_URL を vLLM に向ける手順が案内されています。実験的な Rust フロントエンドでは未実装との issue があり、標準の Python フロントエンドが前提です 一次情報（vLLM ドキュメント）
Ollama v0.14.0 以降で Anthropic Messages API に対応（公式ブログ。2026 年 1 月 16 日の告知とする二次情報が複数）。ANTHROPIC_BASE_URL=http://localhost:11434 と ANTHROPIC_AUTH_TOKEN=ollama を設定して Claude Code から接続。32K トークン以上のコンテキスト長を推奨 一次情報（Ollama ブログ）
LM Studio 0.4.1（2026 年 1 月 30 日）以降で /v1/messages に対応し、Claude Code 連携を公式ドキュメントで案内。ANTHROPIC_BASE_URL=http://localhost:1234 と ANTHROPIC_AUTH_TOKEN=lmstudio（認証を有効にした場合は API トークン）を設定。ストリーミングとツール呼び出しに対応し、25K トークン以上のコンテキスト長を推奨 一次情報（LM Studio の changelog とドキュメント）

主要なローカル推論サーバーがそろって Anthropic 互換のエンドポイントを持つようになったので、Claude Code をローカルモデルにつなぐこと自体のハードルは 2026 年に入って大きく下がりました。llama.cpp の場合、公式ブログに記載されている接続手順はサーバーを起動したうえで環境変数を差し替えるだけです。

llama-server -hf <モデルの GGUF リポジトリ> --jinja -c 65536
ANTHROPIC_BASE_URL=http://127.0.0.1:8080 claude

ただし、動くことと快適に使えることは別です。Claude Code のシステムプロンプトと内蔵ツールの説明文は Claude 向けに書かれているため、別のモデルではツールの選び方や編集形式の扱いで齟齬が出やすくなります。加えて 4.6 節のとおり、Anthropic 以外のホストを指すと MCP ツールの遅延ロードが効かず、ツール定義を丸ごと先読みする構成になると報告されています。ローカルモデルの評価を目的にするなら、モデル非依存を前提に設計された OpenCode や Cline のほうが素直に動く、というのが筆者の見立てです。

6.6 「モデルはハーネスに合わせて訓練される」のローカル版

2.4 節の議論は、オープンウェイトモデルにもそのまま当てはまります。

モデル側の動き 内容 情報源の区分
エージェント用途を意識した学習 Qwen3-Coder は多数の実行可能環境での強化学習でエージェント的なコーディング能力を強化したと公式ブログで説明されています。後継の Qwen3-Coder-Next も同様の方針と報告されています Qwen 公式ブログ（一次情報）。後継については二次情報
専用パーサや推論経路の提供 Qwen3-Coder は専用のツール呼び出しパーサが配布物とともに提供され、vLLM 側にも qwen3_coder / qwen3_xml パーサが用意されています。llama.cpp の公式ブログはエージェント用途向けに Nemotron、Qwen3-Coder、Kimi K2、MiniMax M2 などのエージェント特化モデルを推奨しています 配布物と公式ブログ（一次情報に近い）
特定ハーネスでの動作を前提にした提供 Qwen は Gemini CLI を基にした Qwen Code を公開しています。Mistral の Devstral はエージェント用途向けに調整されたモデルとして公開されています。GLM、Kimi、DeepSeek、MiniMax などは Claude Code から使うための Anthropic 互換エンドポイントと設定手順を案内している、というのが筆者の把握です 各社の公式ドキュメント（本記事では個別 URL の再確認を省略しています）
訓練時の運用に合わせた API 設計 OpenAI は、モデルが非公開の推論内容を履歴に保持した状態で思考するように訓練され、長くなれば要約して続けるという運用で訓練・提供されている、と説明しています。3.2 節の 2 設定はこの訓練時の運用を API で再現するものです。gpt-oss、Qwen3、DeepSeek がそれぞれ推論内容の履歴での扱いを規定しているのも同じ考え方です OpenAI ブログ（一次情報）、各モデルの公式ドキュメント（一次情報）
配布物の整備 量子化モデルの配布元が、ツール呼び出し用のチャットテンプレートを修正した版を提供しています Unsloth ドキュメント（一次情報）

つまりローカルモデルの選定は、「ベンチマークのスコアが高いか」だけでなく「そのモデルがどの形式のツール呼び出しを、どのハーネスを想定して学習しているか」の選定でもあります。冒頭の「同じハーネスでもモデルを変えると振る舞いが変わる」現象の正体は、能力差というよりこの整合度の差である場合が多い、と筆者は推定しています。

7. 半導体検証エンジニアの視点：テストベンチとの比喩

1.2 節で触れたとおり、ハーネスの語源であるテストハーネスは、半導体検証におけるテストベンチとほぼ同じ概念です。UVM に慣れた読者向けに、図 12 と下表で対応関係を並べてみます。

image.png

テストベンチの要素 エージェントの要素 対応の度合い（筆者の見立て）
DUT LLM 駆動される対象、という点で相似。ただし後述のとおり能動性の向きが逆
テストベンチ全体 ハーネス 「対象以外のすべて」という定義が一致。語源も同じ test harness
sequencer / driver プロンプト構築、ツール結果の投入 対象に刺激を与える役割
monitor ツール結果や出力の観測、ログ 対象の応答を捕捉する役割。2.3 節の「センサー」に相当
scoreboard / checker / assertion テスト、リンター、型チェック、構造テスト、LLM によるレビュー OpenAI の「カスタムリンターで不変条件を強制する」がこれにあたります
constraint permission、サンドボックス、リンター 行動空間の制約。2.3 節の「ガイド」に相当
VIP / UVC（再利用可能な検証部品） MCP サーバー 標準インターフェースで接続できる再利用部品
TLM ポートなどの標準インターフェース MCP（プロトコル） 部品を接続するための規約
テストプラン、回帰テスト 機能一覧ファイル、進捗ファイル、長期実行ハーネス 何をどこまで終えたかの管理
シミュレータの設定（タイムスケール、ランダムシード） 推論サーバーの設定（テンプレート、コンテキスト長、サンプリング） どちらも「ベンチでも DUT でもないが結果を左右する層」

この比喩は導入としてはよく効きますが、次の点で崩れます。

崩れる点 説明
非決定性 通常の RTL シミュレーションでは、同じ初期状態・seed・タイミング・刺激なら高い再現性が期待できますが、LLM は確率的で毎回異なります。回帰テストの「再現」という前提がそのままでは成り立ちません
能動性の向き DUT は次の刺激を選びませんが、LLM は次に呼ぶツールを自分で決めます。テストベンチでは刺激を決めるのはベンチ側ですが、エージェントでは駆動される側が次の刺激（ツール呼び出し）を決めます
目的 テストベンチの目的は合否判定ですが、ハーネスの目的はタスクの完了で、検証はその手段の一つです
対象の適応 通常の DUT は、特定のテストベンチの振る舞いそのものに適応するように学習されるわけではありません（DFT や検証用フックのようにテスト容易性を織り込む設計はあります）。一方 LLM は、特定のツール形式やハーネスを前提に追加学習されることがあります（2.4 節、6.6 節）

「ハーネスを育てる」という作業を、テストベンチに VIP を足しチェッカーを厚くしていく作業に重ねて考えると、AGENTS.md や permission や MCP サーバーがそれぞれベンチのどの部品にあたるのかが見通しやすくなる、というのが筆者がこの比喩を持ち出す理由です。ただし上表の 4 点、特に能動性の向きが逆である点は常に意識しておく必要があります。

8. まとめ

論点 整理
LLM の仕事 次に何をするか（テキストで答えるか、どのツールをどの引数で呼ぶか）を決めること、そして「もう呼ばない」と決めること
ハーネスの仕事 それ以外のすべて。プロンプト構築、ツールの実装と実行、権限と制約とサンドボックス、コンテキスト管理、サブエージェント、UI
MCP の居場所 ハーネスと外部ツールの間。LLM は MCP を知らず、ハーネスが変換した関数スキーマだけを見る。2026-07-28 リビジョンでコアはステートレスでキャッシュ可能な request/response 基盤に整理された
ハーネスで性能が変わる理由 ツール説明文、コンテキスト管理、検証ループ、そしてモデルがどのハーネスを想定して訓練されたかの整合度。GPT-6 Astra が同じ ARC-AGI-3 で 62.7%（Standard）と 99.9%（Provider Adapter）に分かれ、reasoning 設定をそろえても 35 ポイント以上の差が残るのはその実例で、差を生んだのは reasoning 状態の保持と compaction というコンテキスト管理であり、MCP やツールではない
ローカル LLM の追加事情 ハーネスとモデルの間に推論サーバー（チャットテンプレートとパーサ）の層があり、ここが自分の責任範囲になる。コンテキストが貴重で遅延ロードも効きにくいので、MCP は絞り、CLI と Skills に寄せるのが現実的
GPT-6 Astra が示したハーネス側の必須機能 Responses API、推論内容の保持、compaction の 3 点。Chat Completions 経由や reasoning item を落とすハーネスでは、同じモデルでも性能が出ない。ローカルでは推論サーバー・テンプレート・ハーネスの協調で同じことを実現する

冒頭の動機に戻ると、ローカルモデルとハーネスの組み合わせを試すときのチェックリストは次のようになります。

順番 確認すること
1 推論サーバーのチャットテンプレートとツール呼び出しパーサがそのモデルに対応しているか（6.3 節、6.4 節）。llama.cpp なら --jinja、vLLM なら --tool-call-parser と --reasoning-parser
2 コンテキスト長の設定がハーネスの想定を満たしているか
3 接続している MCP サーバーのツール定義が何トークン消費しているか。不要なサーバーを切っているか。遅延ロードが効く構成か（4.6 節）
4 そのモデルがどのハーネス・どのツール呼び出し形式を想定して訓練されているか（6.6 節）
5 ハーネスの permission 設定とサンドボックスで、モデルに頼らず機械的に止めるべき操作（秘密ファイルの読み取り、外部送信）を止めているか（2.5 節）
6 思考モデルの推論内容を履歴に残す規則（Harmony、Qwen3、DeepSeek、OpenAI の Responses API）にハーネスが従っているか（6.2 節、6.4 節）
7 「モデルが悪い」と結論づける前に、上の 1 から 6 を潰したか

この分野は月単位で状況が変わります。本記事の数値や仕様は 2026 年 9 月上旬時点のもので、特に 4.4 節の仕様リビジョンと 5 章の比較表は、参照時に一次情報での再確認をお願いします。

参考文献・出典

一次情報（公式仕様・公式ブログ・公式ドキュメント・原著の投稿）

二次情報（解説・比較・コミュニティ）

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?