同じGPT-5.6でも、harnessを変えるだけで1件あたりのコストが2.3倍違った──個人が測ったharness横並び比較
モデルを固定してharness(エージェントの実行環境)だけを変え、結果の差を測ろうとする個人開発プロジェクトが2026年7〜8月にかけて複数立ち上がっている。実際に7つのharnessを24の実タスクで走らせたtreygoff24氏のベンチマークでは、Pi(74.0%・$0.93/成功)とClaude Code(73.8%・$2.14/成功)の合格率がほぼ同じでも、1件成功あたりのコストは2.3倍違っていた。
目次
「モデルの実力を測る」ベンチマークは数多くあるが、「同じモデルでもharness(エージェントを取り巻く実行環境・プロンプト・ツール構成)が違えば結果はどれだけ変わるのか」を測ろうとする動きは、まだニッチな領域だ。2026年7月から8月にかけて、この問いに個人で取り組んだプロジェクトが複数、GitHub上に現れている。
3行まとめ
- treygoff24氏の
personal-agent-benchmarkは、7つのCLI型コーディングharness×3種のGPT-5.6バリアント×24の実タスクという構成で約1,500回の試行を記録し、上位陣(Pi 74.0%・Claude Code 73.8%・Codex CLI 73.5%)の合格率がほぼ横並びである一方、1件成功あたりのコストはPiの$0.93からClaude Codeの$2.14まで2.3倍の開きがあったと報告している。NochnoyRitzar/harness-bench(5 harness×8タスク×3回)とDeDuva/duva-bench(model×harness×toolset×substrateの要因計画実験)は、いずれもインフラと計測の仕組みを厳密に検証済みと明記する一方、「本番の全120実験セッションはまだ実行していない」「Gate G2・G3は未実行、結果と呼べるものはまだ無い」と、結果そのものはまだ出ていないことを自ら明記している。- 比較そのものではなく「harnessがモデルに何を見せているか」を可視化する
sileod/agent-harness-xrayや、DSH・Harness X・Ouroboros・Prime Agentの4つを1枚の静的ページで並べた中国語圏の個人サイトsusyimes/agent-compareなど、切り口の異なる周辺プロジェクトも同時期に生まれている。
「自分の日常運用」で測った7 harness × 3モデル
もっとも実証データが充実しているのが、treygoff24氏が公開しているpersonal-agent-benchmarkだ。READMEにはこう明記されている。
"A personal, "as lived in" benchmark of seven CLI coding-agent harnesses running the three GPT-5.6 variants (sol / terra / luna), on 24 tasks mined from one person's real software projects, three attempts per harness-model-task cell. ~1,500 recorded attempts, hidden regression-test grading, and a blinded three-judge quality panel." （「7つのCLIコーディングエージェントharnessに、3種のGPT-5.6バリアント(sol/terra/luna)を走らせた、個人の“実生活に根ざした”ベンチマーク。1人の実際のソフトウェアプロジェクトから採った24タスクに対し、harness×モデル×タスクのセルごとに3回試行。約1,500件の記録済み試行、隠しリグレッションテストによる採点、盲検の3人審査員パネル」）
対象はCodex CLI・Claude Code・Cursor(cursor-agent)・OpenCode・Droid(Factory)・Pi・Oh My Pi(OMP)の7つ。「実験室のデフォルト設定ではなく、自分が日常使っているグローバル指示・スキル・MCPサーバーをそのまま各harnessに適用して測った」と明記されており、この選択が結果にどう影響したかも自己申告している。
修正後の結果表(2件の事後監査を経た数字)は次の通りだ。
| Harness | 採点対象 | 合格 | 合格率 | 未納品率 | インフラ損失 | 中央値(成功時) | $/成功 |
|---|---|---|---|---|---|---|---|
| Pi | 208 | 154 | 74.0% | 1.0% | 0 | 4.6分 | $0.93 |
| Claude Code | 214 | 158 | 73.8% | 0.9% | 2 | 4.8分 | $2.14 |
| Codex CLI | 215 | 158 | 73.5% | 0.9% | 1 | 4.1分 | $1.16 |
| OpenCode | 216 | 154 | 71.3% | 5.1% | 0 | 8.7分 | $2.50 |
| OMP | 214 | 148 | 69.2% | 1.9% | 1 | 6.4分 | $1.27(推定) |
| Droid | 161 | 109 | 67.7% | 0.0% | 52 | 3.8分 | $1.59 |
| Cursor | 164 | 105 | 64.0% | 7.3% | 30 | 7.9分 | $1.19(概算) |
合格率だけを見れば上位3つ(Pi・Claude Code・Codex CLI)は73〜74%台でほぼ横並びだが、成功1件あたりのコストはPiの$0.93からOpenCodeの$2.50まで、2.7倍の開きがある。同じ「合格率」という指標だけでharnessを選ぶと、コスト構造の違いを見落とすことになる、という実例だ。
README自身が、この結果に対する留保も明記している。
"Claude Code's judge cell carries a known selection bias: 12 of its attempts committed their fixes and left nothing in the worktree diff to judge; excluding them plausibly biases the score low." （「Claude Codeの審査対象セルには既知の選択バイアスがある。12件の試行は修正をコミットしてしまい、ワークツリーの差分に審査対象が何も残らなかった。これらを除外すると、スコアが低めに偏っている可能性が高い」）
Droid・Cursorのインフラ損失が突出して多い(52件・30件)点についても、「自分のリポジトリの契約者向けルールを、手元のツールのバグが原因で満たせなかったエージェントを、環境ブロックとして24件除外した」という監査記録がfleet-block-roster.jsonとして公開されている。数字を出すだけでなく、どのデータをなぜ除外したかを追跡可能な形で残している点が、このプロジェクトの信頼性を支えている。
「まだ結果は出ていない」と自ら書く2つのプロジェクト
一方、同時期に立ち上がった2つのプロジェクトは、計測基盤への作り込みは相当に厳密である一方、実際の比較結果はまだ出ていない。
NochnoyRitzar/harness-benchは、Claude Code・Codex・OpenCode・Pi・Aiderの5 harnessを、deepseek-v4-flashに固定して8タスク×3回(計120実行)測る設計だ。README中の「Status」節には、キャッシュヒットの整合性やコンテナの隔離、SIGKILL後のレジューム機能など8項目の受け入れ基準がすべてPASSしたことが記されている一方、こう釘を刺している。
"The full 120-run session has not been run. Everything is staged for it." （「120実行のフルセッションはまだ実行していない。すべてはそのための準備が整っている段階だ」）
DeDuva/duva-benchも同様に、計測基盤(ADPトラジェクトリの検証・グレーダーの権限分離)の1件のスモークテストは「2026年8月10日にgate G1を通過」と明記する一方、こう書く。
"Gates G2 and G3 are still unrun. No study has been executed and no report produced, so nothing here is a result about any agent." （「ゲートG2とG3はまだ未実行。研究はまだ何も実行されておらず、レポートも作られていないため、ここには“どのエージェントについての結果”と呼べるものは何も無い」）
両プロジェクトとも、「測定装置そのものが信頼できることを先に証明してから、初めて数字を出す」という順序に非常に慎重だ。この慎重さ自体は評価できるが、記事執筆時点(2026年8月27日)では、両者から「harnessごとの優劣」を示す具体的な数字はまだ得られない。
比較ではなく「透視」する周辺プロジェクト
比較表そのものではなく、harnessが実際にモデルへ何を送っているかを可視化する方向のプロジェクトもある。sileod/agent-harness-xrayは、コーディングエージェントが実行時にプロバイダへ送るリクエストのペイロード(システム/開発者/ユーザーメッセージ、ツールスキーマ、プロジェクトルール、取得済みコンテキスト)を捕捉するツールだ。
"Agent Harness X-Ray captures the provider-visible request payloads produced by coding agents. It focuses on what a harness sends to a model endpoint." （「Agent Harness X-Rayは、コーディングエージェントが生成する、プロバイダから見えるリクエストのペイロードを捕捉する。harnessがモデルのエンドポイントに何を送っているかに焦点を当てている」）
ダミーのAPIキーとローカルのダミーエンドポイントに向けてharnessを実行し、リクエスト本文をログとして残す、という実装だ。「比較」ではなく「情報開示」の切り口で、harnessの中身をブラックボックスのままにしない、という別の問題意識がうかがえる。
中国語圏の個人サイトも同じ4つの名前を比較している
やや毛色の違う例として、susyimes/agent-compareは、DSH(DeepSeek Harness)・Harness X・Ouroboros・Prime Agentという4つのharnessを1枚の静的HTMLページで比較する、ビルド不要・サーバー不要の個人プロジェクトだ。README(中国語)はこう説明する。
"材料截至 2026-08-17，数字以各官方仓库 / 论文 / 博客为准，并在页面上标了「厂商自报」或「适应集」等限定。" （「素材は2026年8月17日時点のもの。数字は各公式リポジトリ・論文・ブログに基づき、ページ上には『開発元の自己申告』『適応セット』などの限定条件を明記している」）
「進化のスペクトラム(設定を変えているだけか、状態を変えているか、構造を変えているか、コア実装まで変えているか)」という軸で4つを並べる、という設計思想が興味深い。ページはビルドツール不要でHTMLファイル1枚を共有すればそのまま動く作りになっている。
5本のうち、数字が出ているのは1本だけ
5つのプロジェクトを並べて紹介したが、実際に定量的な結果を伴っているのはtreygoff24氏の1件だけで、しかもそれは「GPT-5.6の3バリアントに対する、1個人の実プロジェクト24タスク」という限定的な条件下の結果だ。この記事を書くために5つのリポジトリのREADMEをすべて通読したが、「harnessの優劣」という一般的な結論を出せるだけの独立した追試や、業界標準と呼べる測定基準はまだ存在しないというのが実態だった。NochnoyRitzarとDeDuvaの2件が示しているのは、「厳密に測ろうとすると、測定装置の検証だけで数週間かかる」という、この種の比較実験そのものの難しさでもある。この記事自体も、5リポジトリのREADMEをcurlで読んだ範囲の情報にもとづいており、各プロジェクトのコードを実際にクローンして実行・再現したわけではない。
Prime AgentとDeepSeek Harnessについては別記事でも扱っている。
関連記事
出典・参照資料
AIニュースの解説を動画でも
YouTubeでは注目ニュースの背景を解説し、Xでは新着記事をお知らせしています。
コメント
まだコメントはありません。最初のコメントを書いてみませんか？
AIについて聞きたいことはありますか？
質問箱で無料で受け付けています。回答は公開され、他の方の参考にもなります。
質問箱を見る →新しい記事をメールで受け取る
AIの新しい発表を、出典付きで整理して届けます。
関連記事
ACP対応エージェントだけを集めた「レジストリ」──認証対応の39件をJSON1本で配布する仕組み
3つの違うharnessで、スキルもMCPサーバーも別々に登録し直す面倒を消そうとするCLI
GitHubにすら置かれていないコーディングエージェント「kaagum」──Guile言語・自前UIなし・ACP専用という徹底ぶり
1つのACPエージェントの中にClaude・Codex・Grokが同居する──『艦隊型』オーケストレータClaw Orchestrator
Claude Code・Codex・Hermesを1コンテナにまとめる「HarnessRouter」──自前サーバーで動かす統一プロトコル
81,481スターと11,203スター──MiniMax公式より大きい「個人製Agent Skills」を2つ確認する
Agent Client Protocol(ACP)とは──コーディングエージェントを「LSPのように」つなぐ標準規格
