AIエージェントの成績は、ハーネスとモデルのどちらで決まるのか。

ベンチマークの点数表を見て、次に入れるモデルを決めていませんか。

その点数のうち、どこまでがモデルの成績で、どこからがモデルを包んでいる実行環境の成績なのか。ここ数か月で、この切り分けを正面から測った研究が続けて出てきて、しかも結論がきれいに噛み合っていません。

同じモデルなのに、ハーネスを替えたら23.8点動いた

Harness-Bench は、北京大学と Qiyuan Tech の研究チームが2026年5月に公開したベンチマークです。設定を変えられるハーネス6種とAPI経由のモデル8種を格子状に組み合わせ、106個のサンドボックス化されたタスクを走らせています。総トラジェクトリ数は5,194本で、うち5,088本が6×8の格子分、残りの106本は別枠の集計分です。

結果として、ハーネス6種の総合スコアには無視できない開きが出ました。最上位は NanoBot の76.2、最下位は OpenClaw の52.4。差は23.8ポイントです。

GitHub - HKUDS/nanobot: Ultra-lightweight, open-source, self-hosted personal AI agent framework in Python with WebUI, tools, memory, MCP, multi-agent workflows, automation, and chat apps

Ultra-lightweight, open-source, self-hosted personal AI agent framework in Python with WebUI, tools, memory, MCP, multi-agent workflows, automation, and chat apps - HKUDS/nanobot

github.com

GitHub - openclaw/openclaw: The AI that really does things. Any OS. Any Platform. The lobster way. 🦞

The AI that really does things. Any OS. Any Platform. The lobster way. 🦞 - openclaw/openclaw

github.com

モデルの世代交代で語られる差が2〜4ポイント刻みだと考えると、この23.8という数字はかなり大きい。論文もこれを、モデルの実力ではなく設定レベルの変動として扱うべきだと書いています。

その23.8点は、ハーネスの実力差と呼べるのか

ここで一度立ち止まる必要があります。

この実験の設計上、各ハーネスは本来の実行挙動をそのまま保ったまま比較されています。タスク環境と予算と評価プロトコルは共通化されていますが、コンテキストの詰め方、ツール定義の書き方、権限の扱い、失敗したときの復帰方針は各ハーネスのままです。つまり23.8ポイントという差は、ハーネスというパラメータを1目盛り回した差ではなく、設計思想の違う製品を同じ課題に置いたときの差です。

この違いは実務上けっこう大事です。手元のハーネスの設定を1つ変えたら23.8ポイント動く、という話ではないからです。

もう1つ、読み落としやすい数字があります。Codex はこの格子とは別枠で、モデルと一体化したエージェントとして集計され、80.4を記録しています。ハーネス6種の最上位より上です。ハーネスを自分で組み替える自由と、組み合わせが作り込まれた状態で渡されることの価値は、必ずしも同じ方向を向きません。自分の現場が欲しいのはどちらでしょうか。

コストで測ると、ハーネスの差は逆向きに出る

同じテーマを、まったく別のチームがまったく別の切り口で測っています。

HarnessTax は、カリフォルニア大学バークレー校の Sky Computing Lab に所属するメリッサ・パンさんらによる検証です。モデル7種とハーネス3種を組み合わせた21ペアを、SWE-bench Lite と Terminal-Bench 2.0 で評価しています。ハーネスの内訳は Claude Code、Codex CLI、そして Pi の3つ。

こちらの結論は、Harness-Bench とかなり違います。成功率の差はおおむね±2〜5%の範囲に収まり、その代わりコストが最大5倍動いた、というものです。同じモデルに同じ問題を解かせて、達成率はほぼ同じなのに請求額が5倍違う。これが harness tax、ハーネスに払っている税という言い方の元になっています。

さらに面白いのが Pi の位置です。read、write、edit、bash の4つしかツールを持たない最小構成のオープンソースハーネスですが、コストと成功率の両方でパレートフロンティアに乗りました。

GitHub - earendil-works/pi: AI agent toolkit: unified LLM API, agent loop, TUI, coding agent CLI

AI agent toolkit: unified LLM API, agent loop, TUI, coding agent CLI - earendil-works/pi

github.com

機能を足し込んだハーネスのほうが必ず強い、という前提はここで崩れます。いま使っているハーネスが抱えている巨大なシステムプロンプトは、解こうとしているタスクに対して本当に必要でしょうか。

2本の調査がすれ違う理由は、測っている軸の違い

「成功率が23.8点動く」と「成功率はほぼ動かずコストが5倍動く」は、一見すると矛盾しています。

割れている原因は、測っている対象が違うところにあります。Harness-Bench が使ったのは、実務での使い方から組み立てた106個の実行込みタスクで、ワークスペースを書き換えて成果物を出すところまでを見ています。HarnessTax が使ったのは SWE-bench Lite と Terminal-Bench 2.0 という既存のベンチマークです。タスクの性質が変われば、ハーネスが効く余地も変わります。

この読み方を裏から支えるデータもあります。Stop Comparing LLM Agents Without Disclosing the Harness は、チューレーン大学などの研究者らがハーネスの開示を求めた主張論文ですが、モデルを固定してハーネスだけを替えると Terminal-Bench 2 の pass@1 が69.7%から77.0%へ動いた例、SWE-bench Pro で同一モデルのままスキャフォールド、つまり足回りの実装側の違いだけで45.9%と55.4%に分かれた例を挙げています。

Claw-SWE-Bench の分解はもっと直接的です。ハーネスを固定してモデルを9種入れ替えたときの Pass@1 の幅が29.4ポイント、逆にモデルを固定してハーネスを入れ替えたときの幅が12.5ポイントから27.4ポイント。モデル要因とハーネス要因は、桁が違うどころか同じ土俵に並びます。しかもハーネス側の幅は、どのモデルを固定したかで倍以上ぶれています。

だから「ハーネスは効く」も「ハーネスは効かない」も、一般論としては成立しません。効き方は自分のタスクの形に依存します。

自分の環境でハーネスの寄与を測る最小手順

では、自分のところで確かめるには何をどう測ればいいのか。

論文と同じ規模は要りません。私が確かめるなら、まず固定するものを3つ決めます。モデルとそのバージョン、タスク集合、上限ターン数とタイムアウトです。タスク集合は合成問題ではなく、自分のリポジトリに実際に残っている issue を10件から20件ほど選ぶのが手っ取り早い。難易度がばらけるように選ぶのがコツです。

そのうえで、1回の試行で変える要素は1つだけに絞ります。候補はこのあたりです。

• CLAUDE.md や AGENTS.md に入れている指示の量
• 有効にしているツールやMCPサーバーの数
• 自己検証・リトライを挟むかどうか
• コンテキスト圧縮をどのタイミングで走らせるか

測る指標も、完遂率だけでは足りません。入出力トークン数と総コスト、それに失敗の内訳を必ず一緒に記録します。内訳というのは、ツール呼び出しの形式ミスで落ちたのか、コンテキストが溢れたのか、変更は入ったが検証を通っていないのか、という分類です。HarnessTax の結果が示しているのは、完遂率だけ見ていると差がないように見えて、コストで大きく負けている状態が普通に起こるということでした。

もう1つ、これを外すと結論がひっくり返ります。同じ設定で少なくとも3回は回して、ばらつきの幅を先に把握してください。エージェントの試行は1回ごとに軌跡が変わるので、1回の結果で「この設定のほうが強い」と決めると、ただの分散を実力差として読み違えます。

モデルを乗り換える前に、ハーネス側で確かめること

モデルの乗り換えは、見積もりよりコストが高い判断です。料金体系も、癖も、チームの慣れも全部作り直しになります。

一方でハーネス側の見直しは、ここまでの数字を踏まえると割のいい投資に見えます。優先順位をつけるなら、こうです。

1. 指示とツールの量を削って、成功率が落ちないか測る。落ちないなら、そのぶんはコストとして払っていただけの重さです
2. 失敗の内訳を記録する。ツール呼び出しミスとコンテキスト溢れは、モデルを上げるより設定側で直ることが多い
3. そのうえで差が埋まらない領域を特定してから、モデルの乗り換えを検討する

3本の研究が共通して言っているのは、エージェントの成績をモデル単体に帰属させられない、ということです。点数表を見るときは、その横に何のハーネスで測ったのかが書かれているかを先に確認する。書かれていない点数表は、モデルの成績表としては読めません。