Artificial Analysis Coding Agent Index v2.0：タスク単価で比較
Artificial Analysis Coding Agent Index v2.0を使い、予算と作業内容に合うモデルとエージェントの組み合わせを選びます。DeepSeek V4.1 Flash、GPT-6.1 Sol、GPT-6 Astra、Claude Opus 5.5を比較し、評価方法の変更とキャッシュを含むAPI費用を理解したうえで、自分のリポジトリで採用できる成果1件当たりの費用を測ります。
目次
Artificial Analysis Coding Agent Index v2.0をもとに選ぶなら、幅広いコーディング作業にはCodex + GPT-6.1 Sol (max)、API予算を最優先する場合はCodex + DeepSeek V4.1 Flash (max)から試してください。採用できる変更を得るために予算を増やせるなら、より高いスコアを記録したClaude Code + Claude Opus 5.5 (max)が比較候補になります。これは作業分野ごとのベンチマーク結果に基づく推奨であり、ドル建ての金額はAPI使用料を示します。サブスクリプション料金でも、本番の作業で必ず収まる費用でもありません。
この比較はArtificial Analysisの10月23日の発表に基づき、方法論と公開比較ページの確認時点は2026-10-25です。比較する単位はモデルとエージェントハーネスの組み合わせです。ハーネスとは、コンテキスト、ツール、処理の実行、モデルとのやり取りを管理するアプリケーションを指します。
注目の構成を比較する
この四つの構成から選び、さまざまな作業を混ぜて費用と成果を確かめるなら、GPT-6.1 Solが最初の比較対象として適しています。 DeepSeekはAPI費用を大きく抑えられる候補であり、Opusは総合スコアの高さを重視する場合の候補です。Astraを選ぶには、総合順位だけでなく、対象の作業で何が改善するのかという具体的な理由が必要です。
AAは発表で次の組み合わせを取り上げています。いずれも、報告された推論設定はmaxです。
| エージェントで使用するモデル | Index v2.0のスコア | FrontierCode v1.1のスコア | タスク当たりのAPI費用 |
|---|---|---|---|
| CodexでDeepSeek V4.1 Flashを使用 | 47.3 | 52.6% | $0.39 |
| CodexでGPT-6.1 Solを使用 | 54.1 | 49.4% | $1.50 |
| CodexでGPT-6 Astraを使用 | 54.7 | 49.3% | $7.04 |
| Claude CodeでClaude Opus 5.5を使用 | 61.7 | 56.0% | $11.42 |
金額は、ベンチマークの作業に対するUSD建ての平均費用です。Claude CodeとCodexの公開比較ページにも、2026-10-25時点で同じ四つの金額が掲載されています。ただし、同ページのスコア表示は丸められています。
ここでは発表で取り上げられた候補に絞って比較しています。ランキング全体を示した一覧ではなく、同等以上のスコアをより安く得られる別の構成がない、費用対効果の境界上の候補をすべて列挙したものでもありません。公開比較ページには、タスク当たり$0.16、丸めた総合スコア31のCodex + GPT-6 Luna (max)もあります。DeepSeekが最も安いのは上記の四つの中であり、評価された構成全体ではありません。
発表時のランキングではOpusが首位です。Claude Code + Sonnet 5.5 (max)が59.3、Muse Code + Muse Wonder Full (max)が58.9で続きます。順位が高いだけでは、自分の作業や予算に最も合う構成は決まりません。
完了させたい作業から選ぶ
最初に試す組み合わせを決めるときは、完了させたい作業に対応する個別ベンチマークのスコアを見てください。 総合指数では三種類の作業が同じ重みを持ちます。一方、自分のバックログでは、コード変更、ターミナル操作、リポジトリへの質問が同じ比率で並ぶとは限りません。
リポジトリへの変更を繰り返すなら、DeepSeekから試す
範囲が明確な変更を数多く処理し、各結果をテストとレビューで確認できるなら、Codex + DeepSeek V4.1 Flashから始めてください。FrontierCodeのスコアは52.6%で、Solの49.4%とAstraの49.3%を上回ります。総合指数では下回っていても、この分野の結果は異なります。
この結果は、順番に処理すべきパッチの作成を低コストの構成に任せてみる、という試行を後押しします。ただし、自分のプロジェクトでもその運用がうまくいくと実証した結果ではありません。採用できないパッチ、追加試行、レビュー担当者による修正の負担がAPI費用の節約を打ち消すなら、選択を見直してください。
コーディングとターミナル操作が混在するなら、Solを基準にする
コードの変更と開発環境の操作を行き来する作業では、Codex + GPT-6.1 Solを最初の比較基準にしてください。ベンチマークの試行当たり$1.11の追加費用で、DeepSeekより総合指数が6.8ポイント高くなっています。
公式比較に載るTerminal-Bench 4.0の丸めたスコアは、Solが53%、DeepSeekが28%です。この差は、ターミナル操作が多い作業でSolを先に試す根拠になります。ただし、自分のCI修復やデプロイスクリプトでも同じ差が出ることを示してはいません。DeepSeekがより低い総費用で採用基準を満たせるなら、DeepSeekを選んでください。
失敗の負担が大きいなら、Opusを基準の構成と比べる
不十分な結果による損失がAPI費用の増加より大きい作業では、Claude Code + Opus 5.5を試してください。発表された総合スコアは最高の61.7で、FrontierCodeもこの四つの中で最高の56.0%です。
ベンチマークの試行当たり$11.42という費用は、Solの$1.50の約7.61倍です。継続して使うかどうかは、タスクの種類ごとに判断してください。採用できる変更が増える、レビューにかかる時間が短くなる、再試行が減るといった改善を自分の比較で測り、その差が追加費用に見合う場合に採用を続けます。
Astraを検討するなら、対象の作業で優位性を確かめる
総合指数が54.1から54.7へ上がるという理由だけで、SolからAstraへ移行するのは勧めません。公表された費用は$1.50から$7.04へ増えます。追加の0.6ポイントに対し、支出は約4.69倍になります。
もちろん、作業の種類や比率によってはAstraが有利な場合もあります。たとえばTerminal-Benchの丸めたスコアはAstraが56%、Solが53%です。まずSolを使い、自分の作業で意味のある利点を確認してからAstraを選んでください。総合スコアの小さな差だけでは、その利点を裏付けられません。
スコアを成功率に読み替えず、予算を計算する
公表された費用に試行回数を掛け、作業内容に左右される見積もりとして扱ってください。 タスク数に指数の割合を掛けた値を、完了する修正件数と考えてはいけません。
例として、AAと同じ作業構成で、トークンの平均費用が変わらないと仮定し、1,000回試行した場合を計算します。
| エージェントで使用するモデル | 1,000回の試行に対するAPI費用の見積もり |
|---|---|
| CodexでDeepSeek V4.1 Flashを使用 | $390 |
| CodexでGPT-6.1 Solを使用 | $1,500 |
| CodexでGPT-6 Astraを使用 | $7,040 |
| Claude CodeでOpus 5.5を使用 | $11,420 |
計算は、試行回数に公表された試行当たりの平均API費用を掛けるだけです：attempts × reported mean API cost per attempt。この見積もりには、自分のインフラ、有料の外部ツール、人によるレビューの費用は含みません。採用できるプルリクエスト1,000件の費用を見積もったものでもありません。
指数の1ポイント当たりの費用を計算する場合は、公表された0–100の尺度を使います。
- DeepSeekの指数1ポイント当たり：
$0.39 / 47.3 ≈ $0.00825 - Solの指数1ポイント当たり：
$1.50 / 54.1 ≈ $0.02773 - Astraの指数1ポイント当たり：
$7.04 / 54.7 ≈ $0.12870 - Opusの指数1ポイント当たり：
$11.42 / 61.7 ≈ $0.18509
この比率は、発表時点のスコアと費用を一つの数値で表したものです。タスクを成功させるために必要な費用を示すものではありません。指数には異なる採点方式が組み合わされ、三つのベンチマークの重み付けと費用指標をまとめる方法も一致していません。比率の低さだけで選ぶと、安価であるために数字は良く見えても、性能そのものは自分の最低限の採用基準に届かない構成を選ぶ可能性があります。
予算配分や利用する構成を決める際には、自分で選んだタスク群を実行し、総支出を採用できた成果の件数で割る指標を測ってください。分子に入れるのは、成功した試行の料金だけではありません。失敗した試行にかかった支出や、より高性能な構成に切り替えて再処理した費用も含めます。
Coding Agent Index v2.0で変わった点
v2.0では、ソフトウェアエンジニアリングの評価項目が置き換わり、リポジトリに関する質問応答の採点が変更されました。 Terminal-Bench 4.0は指数v1.5から変更されていません。
公開されている指数の方法論では、次の構成が定められています。
| 評価項目 | タスク数 | 評価する作業 | 採点方法 |
|---|---|---|---|
| FrontierCode v1.1 Main | 100 | 実在するリポジトリへの変更 | 必須チェックに一つでも失敗するとゼロ。それ以外は70–100% |
| Terminal-Bench 4.0 | 66 | ターミナルを通じて完了する作業 | テストスイートの合格・不合格 |
| SWE-Atlas-QnA-AA | 124 | リポジトリの動作に関する質問への回答 | 採点基準をすべて満たした場合のみタスク合格 |
評価する異なるタスクの合計は290種類です。AAはそれぞれのタスクで三回の試行を実行し、その結果を平均して評価します。三回実行したうち最も良い結果だけを採用する方式ではありません。こうして得た三つのベンチマークのスコアを、さらに等しい重みで平均したものが総合指数です。
したがって、124問ある質問応答の項目が、66タスクのターミナル評価より大きな重みを持つわけではありません。また、指数61.7という結果は、一般的な開発チケットの61.7%を完了できるという意味でもありません。
FrontierCodeはメンテナーの要件を満たす変更を評価する
FrontierCodeはDeepSWE v1.1に代わる評価項目で、コードの品質も採点対象に含めます。Cognitionのベンチマーク設計では、機能が正しく動くかだけでなく、変更範囲やコード品質など、リポジトリのメンテナーの要件を満たすかを評価します。
AAが使うのは、100タスクからなる非公開のMainセットです。必須要件のどれか一つでも満たせなければゼロになります。すべての必須要件を満たすと、残りのチェック項目に応じて70–100%のスコアが付きます。
試行中もインターネットは利用できます。FrontierCode 1.1の利用ルールではドキュメントの参照は許可されていますが、解答に当たる資料の取得は試行が無効になる原因となります。AAはCognitionのスキャナーを修正したものを適用し、検出された試行にはゼロを付けます。
タスクセットの非公開化は、評価対象の内容が事前に知られてしまう経路を一つ減らします。ただし、元のリポジトリの解決策がオンラインに存在しないことまでは意味しません。
SWE-Atlas-QnA-AAは採点モデルと基準の文言を変更する
リポジトリについての質問自体は同じですが、採点方法が変わりました。AAは124タスクと1,306の基準を維持しつつ、127の基準を書き換えています。採点にはGPT-6 Lunaをxhighで使い、各基準につき五回の判定を行います。
公開されたデータセットと採点設定では、各基準の結果を多数決で決めます。タスクの合格には引き続きすべての基準を満たす必要があるため、技術的には妥当に見える回答でも、必要な詳細を一つ欠くだけで不合格になることがあります。
AAは、この修正によって各回答への判定がより一貫したものになると説明しています。数値を比較する際には、どの採点方式で得られたスコアなのかを区別してください。新しいスコアは変更後の基準と採点モデルによるもので、以前の組み合わせから得られる数値として扱うことはできません。
スコア低下がモデルの劣化を意味しない理由
指数のバージョン間での低下は評価方法の変更を反映しており、同じモデルの性能が悪化したとは読み取れません。 旧版の数値と比べる前に、まずv2.0内で構成を比較してください。
AAは公式発表のスレッドで、両バージョンに共通する21構成の平均指数が54.8から47.4へ下がり、21構成中20構成で低下したと報告しています。同じ構成群の平均は、DeepSWE v1.1では65.6%、置き換え後のFrontierCode v1.1では45.1%でした。
リポジトリの質問応答も平均58.8%から57.1%へ低下し、21構成中14構成でスコアが下がりました。Terminal-Benchは変わっていません。三項目を等しく重み付けすると、報告された各項目の変化から総合指数の7.4ポイント低下を説明できます。
計算式は次のとおりです：((45.1 - 65.6) + (57.1 - 58.8) + 0) / 3 = -7.4
測定の尺度が変わったということです。相対的な結果も変わります。採点が厳しくなっても、すべての構成から同じ点数が引かれるわけではありません。
API費用に含まれるものと含まれないもの
AAの費用指標はトークン課金をモデル化し、対応している場合はキャッシュも含めています。 ClaudeやChatGPTのサブスクリプション料金、変更をリリースするまでの開発作業全体の費用を表すものではありません。
費用とトークン使用量のセクションでは、キャッシュされていない入力、キャッシュ済み入力、キャッシュへの書き込み、出力を区別しています。公開ページでは、トークン使用量の内訳やキャッシュヒット率も確認できます。すべての入力トークンをキャッシュミスとして通常の入力単価で計算すると、この費用指標を正しく再現できません。
費用は各タスクの試行をひとまとめにして平均する一方、総合指数では三つのベンチマークをそれぞれ同じ重みで扱います。また、効率指標の平均を求める際に必要な計測値が欠けていれば、AAはその値を平均の対象から除外します。料金や使用量をゼロと仮定して穴を埋めることはありません。こうした集計方法の違いも、費用を指数で割った値を「解決した課題当たりの費用」と扱えない理由です。
実際の費用は、コンテキストの長さ、再試行、推論設定、プロバイダーのキャッシュ動作によって変わります。モデル名が同じように見えても、エンドポイントやハーネスが変われば、比較結果も変わる可能性があります。
AAによる単独のFrontierCodeモデル評価も区別してください。こちらではAAのStirrupハーネスを使っています。そのモデルスコアを、上で示したClaude CodeやCodexとの組み合わせのスコアに置き換えることはできません。
自分のリポジトリで小規模に比較する
バックログ全体をどちらかの構成に任せる前に、二つの候補を同じ採用基準で試してください。 小規模な試行の目的は、自分が処理したい作業の種類について、どちらの構成を使うか判断できる結果を得ることです。AAの非公開ベンチマークを再現し、同じ評価結果を得たと主張するための試行ではありません。
- 代表的な作業を選ぶ。 自動化したい分野から、実際のタスクを十件選んで始めます。どちらのエージェントも実行する前に、期待する動作と許容する変更範囲を書き出してください。
- 開始条件をそろえる。 リポジトリのコミット、タスクのプロンプト、使えるツール、権限を同じにします。CLIのバージョン、正確なモデルIDまたはリビジョン、推論設定、利用したプロバイダーへの接続経路を記録してください。
- 各構成を独立して実行する。 試行ごとに新しい作業コピーとセッションを使います。最も良く見えるパッチだけを残すのではなく、失敗した試行や追加の試行も記録します。
- 実際に使える成果かを評価する。 パッチでは関連テストを実行し、正しさ、変更範囲、保守性をレビューします。リポジトリへの質問では、回答をコードと照合し、必要に応じて実行結果の裏付けも確認してください。
- 採用できた成果と総費用を比べる。 API使用料、有料ツールの使用料、実行環境の費用を記録し、レビュー時間はチームで決めた時間単価で換算します。総支出を採用できた成果の件数で割ってください。サブスクリプション経由での利用を評価する場合は、月額などの契約料金と超過料金を別に記録します。
DeepSeekでは、モデルの実体にも注意が必要です。2026-10-25時点の公式APIドキュメントでは、モデル名はdeepseek-flashで、現在そのリクエストを処理するモデルはDeepSeek-V4.1-Flash-1017とされています。ランキング上の短い名称だけでは、新しく送るリクエストがAAの評価時と同じモデル実体を使うとは確認できません。
試行にBetterTokenを使う場合は、CodexとClaude CodeそれぞれのAPI連携ガイドに従い、その接続経路で発生した料金を測ってください。これはAPI経由の利用であり、各ベンダーのアプリケーションのサブスクリプションとは別です。
安い構成が採用基準を満たす分野では、その構成を使い続けてください。より高性能な構成には、採用できる成果の改善やレビュー作業の削減によって追加費用を正当化できる種類のタスクを任せます。
