AIコーディングの費用差は最大5倍、ハーネス選びで何が変わるのか

AIコーディングエージェントの活用が進む中で、多くの方はモデル自体の知能や性能に注目しています。しかし、モデルにどのツールを渡し、どのように指示を与えるかを司る「ハーネス」の違いによって、作業成功率はほぼ同等でありながら利用費用に最大5倍の開きが出ることが研究で報じられています。この記事では、公開された検証データをもとに、ハーネスがもたらす影響と実務上の着眼点を整理してお伝えします。

モデルを動かす「ハーネス」とは何をしているのか？

AIによる自動プログラミングを評価する際、大規模言語モデル（LLM）自体のパラメータや処理能力ばかりが話題にのぼりがちです。しかし、実際のコーディングエージェントはモデル単独で完結しているわけではありません。モデルが外部と対話し、コードを読み書きして修正を実行するためには、周辺環境を仲介する制御基盤が必要です。この役割を担うソフトウェアが「ハーネス」と呼ばれています。

ハーネスは主に以下の処理を管理しています。

• モデルにどのツール（ファイル閲覧、ファイル書き換え、ターミナルコマンド実行など）を提供するか
• タスクの説明や動作ルールを、どのような指示文や仕様定義としてモデルのコンテキスト（入力情報）に渡すか
• モデルから出力されたコードやコマンドを解析し、実際の開発環境でどのように実行・制御するか

カリフォルニア大学バークレー校とAI評価サイト「Arena」の共同研究チームは、このハーネスの違いがエージェント全体の費用や性能にどれほど影響を与えるかを調査したプロジェクト「HarnessTax」を公開しました。今回の分析内容は、GIGAZINEの報道および研究チームの公開資料に基づいています。

この研究では、「Claude Code」「Codex CLI」「Pi」という3種類のハーネスが比較対象となりました。対象となったモデルは、Claude Fable 5、Claude Opus 4.8、Claude Sonnet 4.6、Claude Haiku 4.5、GPT-5.6 Sol、GPT-5.6 Luna、そしてオープンウェイトモデルのKimi K3という合計7種類です。これらを組み合わせた21通りの構成を用いて、厳密なベンチマークテストが実施されました。

成功率はほぼ互角でも費用には最大5倍の差が出る

共同研究チームが実施したテストでは、ソフトウェア修正能力を測定する「SWE-bench Lite」と、コマンドライン上の複雑な作業を評価する「Terminal-Bench 2.0」の2つのベンチマークが使用されました。各ベンチマークから無作為に選ばれた30個のタスクに対し、21パターンの組み合わせでそれぞれ3回ずつ試行が行われています。各ハーネスの標準設定をベースに高い推論強度の設定を適用し、1試行の上限は100ターンに制限されました。

その結果として判明したのが、ハーネスの違いはタスクの成功率よりも費用にかなり強い影響を与えるという事実です。

同じモデルを利用している場合、どのハーネスを選んでも成功率の平均的な差は、SWE-bench Liteではプラスマイナス2％以内、Terminal-Bench 2.0でもおおむねプラスマイナス5％以内に収まりました。しかし、タスクを完了するために消費されたトークン費用には、最大で5倍もの開きが生じました。研究チームは、ほぼ同等の成果を得るために余分な費用を支払ってしまうこの現象を「ハーネス税（Harness Tax）」と名付けています。

具体的な例として、Claude Fable 5の数値を挙げます。Claude Code環境で動かした場合の成功率は97.8％で、Codex CLIやPiで動かした場合は96.7％でした。Claude Codeの方が1.1ポイント高い成功率を示したものの、要した費用はPiの約2倍に達しています。SWE-bench Liteで共通利用できるモデルを比較した幾何平均でも、Claude Codeの費用はPiの約2倍、Codexの約1.6倍でした。Terminal-Bench 2.0においても、Claude CodeはPiと比べて約1.5倍の費用がかかっています。

なぜ同じターン数でもコストに2倍の差がつくのか？

エージェントがタスクを解決する際、モデルとの対話往復回数である「ターン数」が同等であっても、支払うトークン費用が同じになるとは限りません。

たとえばClaude Fable 5をSWE-bench Liteで実行した際、タスク解決までにかかった平均ターン数はPiが15.4回、Claude Codeが15.3回と、実質的に差がありませんでした。それにもかかわらず費用が約2倍になった背景には、1ターンあたりに処理されるトークン量の違いが存在します。

その大きな要因の1つが、モデルに最初に渡される「初期コンテキスト」の情報量です。初期コンテキストとは、エージェントが最初の推論を行うために読み込む指示文、ツールの定義仕様、タスク説明などのテキスト全体を指します。

7つのモデル全体を調査したところ、Claude Codeの初期コンテキストはPiの10倍を超えていました。Claude Codeでは指示文がかなり長く設定されているほか、ツールの仕様定義だけでも平均約7万7000文字という膨大な分量が含まれています。一方のPiは、read（読み取り）、write（書き込み）、edit（編集）、bash（コマンド実行）という4つのツールのみに絞り込まれたシンプルな構造を採用しています。

初期コンテキストが肥大化すると、モデルを呼び出すたびに読み込む入力トークンが増加し、それが累積費用を押し上げる要因になります。ただし、最終的な費用差は初期情報量だけで決まるわけではなく、プロンプトキャッシュの効き具合やモデル自身が生成する出力トークン数、後続の追加呼び出し回数なども絡み合って生じています。

公式提供のハーネスが最高性能とは限らない

一般的な感覚では、AnthropicのモデルにはAnthropic製のClaude Code、OpenAIのモデルにはCodex CLIというように、自社の開発環境に合わせて最適化された公式ツールを使うのが最も高い性能を発揮すると考えられがちです。しかし、研究データはその直感とは異なる挙動を示しました。

AnthropicとOpenAIの合計6モデルを2つのベンチマークで比較した12通りの検証において、最も高い成功率を記録したハーネスが自社公式以外のツールであったケースが、12通り中9通りに上りました。

• SWE-bench LiteにおいてClaude Sonnet 4.6を動かした場合、Codex CLIでの成功率は68.9％を記録し、公式であるClaude Codeの66.7％を上回りました（費用水準は同等）。
• Terminal-Bench 2.0においてGPT-5.6 Solを動かした場合、オープンソースのPiでの成功率は83.3％に達し、公式のCodex CLI（78.9％）を上回りました（費用はPiがCodex CLIの約半分）。

研究チームは、この結果について「モデルの能力が特定のハーネスに固定されているわけではなく、別のハーネスへ移しても十分に発揮されることを示している」と指摘しています。パレートフロンティア（一定の費用以下で達成できる最高成功率の境界線）で見ても、4つのツールしか持たないシンプルなPiが両方のベンチマークでフロンティア上に並び、優れた費用対効果を記録しました。

シンプルな構成が常に万能とは言えない理由

Piのような最小限のツール構成がコストと精度の両面で良好な結果を残したからといって、あらゆる場面でシンプルなハーネスが最善であるとは断定できません。研究チームもいくつかの前提条件と限界を明示しています。

まず、今回の検証結果は「SWE-bench Lite」と「Terminal-Bench 2.0」という2つのオープンソースベンチマークに限られた数値です。公開されているベンチマークタスクであるため、各モデルが事前の学習データとしてこれらのタスク内容をすでに閲覧していた可能性も否定できません。

また、実際の開発現場では、コードの修正や特定コマンドの実行にとどまらず、複雑なプロジェクト構造の把握、ドキュメントの検索、外部APIとの通信など、多岐にわたる処理が求められます。そうした実務環境においては、より多彩なツールや詳細な指示を備えたハーネスの方が、正確な推論や作業の安定性につながる可能性もあります。

機能が多ければ優れているわけではなく、逆にシンプルであれば無条件に正解というわけでもありません。重要なのは機能の数そのものではなく、作業内容に対してどのようなツールや指示が必要十分なのかを個別に見極めることです。

エージェント選定時に確認しておきたい比較の視点

今回の研究結果から得られる実用的な判断基準は、モデルのブランドや初期設定のツールを鵜呑みにせず、実際の消費トークンと成果を照らし合わせることです。

AIコーディングエージェントの導入や運用を検討する際は、以下の観点を確認することが有効です。

• 利用しているハーネスがどの程度の初期コンテキスト（ツール定義やシステム指示文）を毎回送信しているか
• 公式ツール以外の選択肢（Codex CLIやオープンソースのPiなど）を同一モデルに適用した際の費用効率
• 実際の開発作業に近いタスクにおいて、機能の多さが成功率向上に寄与しているか、あるいは余分な「ハーネス税」となっていないか

モデルの切り替えだけでなく、実行基盤であるハーネスの見直しによっても、作業品質を保ちながらコストを大幅に抑制できる余地が残されています。