Claude CodeとCodexのモデル選び｜工程別のモデル＋エフォート早見表とベンチマーク8サイト
モデル選びのたびにウェブ検索していると、いつまでも判断が安定しない
Claude CodeやCodexでサブエージェントを組むとき、毎回ぶつかるのが「このステップにどのモデルを割り当てるか」です。設計や要件整理のような上流工程で安いモデルを使うと、後続の実装がまるごと間違った方向に進んでしまいます。かといって全ステップを最上位モデルで回すと、トークン単価は10倍以上に跳ね上がります。
やっかいなのは、この判断材料がすぐ古くなることです。モデルは数か月で世代交代し、料金も改定されます。そのたびにウェブ検索をかけ直すのは現実的ではありません。そこで、信頼できる第三者機関のベンチマークと公式の料金ページをリンク集として固定し、定期的に見に行くという運用に切り替えます。この記事はその定点観測リストです。
※本記事の数値・料金はすべて2026年9月6日時点で各公式ページ・リーダーボードを確認したものです。仕様変更が速い領域なので、実際の判断時はリンク先で最新値を確認してください。
第三者機関のベンチマーク8サイト
1. Artificial Analysis — 知能・価格・速度を1枚で比較する起点
artificialanalysis.ai/models。10種類の評価を合成したIntelligence Index（v4.2）に加えて、100万トークンあたりの価格、出力速度、初回トークンまでのレイテンシを同じ軸に並べています。643モデルが対象。知能スコア×価格の散布図が、費用対効果を考えるときの最初の一枚になります。確認時点の上位はClaude Fable 5.1が57、GPT-6 Astra（max）が55、Claude Opus 5が54でした。
2. Terminal-Bench — エージェントの実務に一番近い
tbench.ai/leaderboard。Stanford・Laude Institute・Harbor Frameworkが共同で運営し、ターミナル上でエージェントがタスクを完遂できるかを測ります。現行はv4.0。解決率だけでなくコストとトークン消費量、95%信頼区間まで併記されるのが特徴で、Claude CodeやCodexの使われ方に最も近いベンチマークです。
3. SWE-rebench — 1問あたりのコストが載っている
swe-rebench.com。実際のGitHubリポジトリから課題を継続収集し、学習データ汚染を避ける設計。「Cost per Problem（1問あたりのドル）」と「Tokens per Problem」の列があるため、費用対効果を直接読み取れます。2026年5月15日〜7月1日の期間（65リポジトリ・111問）ではFable 5が64.5%、Grok 4.5が63.8%、Opus 5が63.4%、GLM-5.2が62.9%、GPT-5.6 Solが62.3%。上位5モデルが2ポイント差に収まっており、精度だけでは差がつかない段階に入っていることが分かります。
4. SWE-bench — ベンダー発表を突き合わせる共通基準
swebench.com。Verified / Multimodal / Multilingual / Lite / Full の各リーダーボードを持つ定番。各社が発表資料で引用するのはたいていここのVerifiedなので、ベンダーの主張を横並びで検算する用途に向きます。
5. Vals AI — 自分の業務に近いタスクで測る
vals.ai/benchmarks。法務・金融・医療・コーディングなど業種別に40以上のベンチマークを公開しています。コーディング系だけでもVibe Code Bench、Code Migration、ProgramBench、Terminal-Bench 2.1などがあり、「移行作業が多い」「レガシー読解が多い」など自分のワークロードに近い項目を選んで見られるのが強みです。
6. Arena（旧LMArena） — 人間の投票による相対評価
arena.ai/leaderboard。人間の比較投票でモデルを順位付けする方式で、Agent・WebDev・Text など13前後のカテゴリ別リーダーボードがあります。自動採点では拾えない「出力の読みやすさ・扱いやすさ」を確認する補助として使います。
7. METR — 「何時間の仕事まで任せられるか」
metr.org/time-horizons/。非営利の評価機関METRが、人間なら何分・何時間かかるタスクまでモデルが自走できるかを50%成功率の時間軸で測っています。上流工程を任せられるかの判断に直結する指標です。最終更新は2026年5月8日、16時間を超える測定は現行タスクセットでは信頼できないと注記されています。
8. Aider Polyglot — コスト列の歴史的参照（更新停止中）
aider.chat/docs/leaderboards/。6言語225問のExercism課題を解かせ、正答率と一緒にベンチマーク完走にかかった実費（ドル）を載せた先駆けです。ただし確認時点で掲載はGPT-5世代までで更新が止まっており、最新モデルの判断には使えません。「正答率とコストを並べて見る」という発想の出発点として押さえておく位置づけです。
公式のモデル紹介ページ
第三者ベンチマークで当たりを付けたら、実際に指定できるモデル名とその日の料金は公式で確認します。
- Claude Codeのモデル一覧: code.claude.com/docs/en/model-config —
fable/opus/sonnet/haikuのエイリアス、プラン別の既定モデル、用途別の使い分けが載っています。 - Claude Codeのサブエージェント設定: code.claude.com/docs/en/sub-agents — エージェント定義の
modelに書けるのはエイリアス、フルモデルID（claude-opus-5など）、inherit。 - エフォートの公式解説: platform.claude.com/docs/en/build-with-claude/effort — レベル別の推奨とモデル別の対応状況。
- Anthropicの料金表: platform.claude.com/docs/en/about-claude/pricing — キャッシュ書き込み・読み出しの倍率まで記載。
- Codexのモデル一覧: learn.chatgpt.com/docs/models — Astra / 5.6 Sol / 5.6 Terra / 5.6 Luna / 5.3 Codex Spark と、reasoning effort（low〜max、ultra）の選び方。
- OpenAI APIの料金表: developers.openai.com/api/docs/pricing — キャッシュ入力の単価もここ。
2026年9月6日時点の料金早見表
| モデル | 入力（$/100万トークン） | 出力（$/100万トークン） |
|---|---|---|
| Claude Fable 5.1 | 10.00 | 50.00 |
| Claude Opus 5 | 5.00 | 25.00 |
| Claude Sonnet 5 | 2.00 | 10.00 |
| Claude Haiku 4.5 | 1.00 | 5.00 |
| GPT-6 Astra | 10.00 | 50.00 |
| GPT-5.6 Sol | 4.00 | 20.00 |
| GPT-5.6 Terra | 2.00 | 12.00 |
| GPT-5.6 Luna | 0.20 | 1.20 |
| GPT-5.3 Codex | 1.75 | 14.00 |
GPT-5.6 Solの価格は「少なくとも2026年11月21日まで」のプロモーション扱いと明記されています。またSonnet 5の$2/$10は当初2026年8月31日までの導入価格でしたが、その後に値上げ中止と正価化がアナウンスされました。期限付きの価格が混ざるので、料金は必ず確認日とセットで記録するのが安全です。
もうひとつ効くのがキャッシュです。Anthropicはキャッシュ読み出しが入力単価の0.1倍（Fable 5.1は0.025倍）、OpenAIもキャッシュ入力が通常入力の約0.1倍。同じ前提を何度も読ませるエージェントループでは、モデルを1段下げるよりプロンプトの先頭を固定してキャッシュを効かせるほうが削減幅が大きいことがよくあります。
上流工程と実行工程でモデルを分ける
「設計だけ賢いモデル、実装は安いモデル」という切り分けは、実は公式機能として用意されています。Claude Codeの opusplan エイリアスは、計画中はOpusで動き、実行フェーズに入ると自動でSonnetに切り替わります。上流の判断品質を落とさずに実行分のトークン単価を下げる、という発想がそのまま実装されたものです。
サブエージェント側の指定も押さえておきます。Claude Codeがサブエージェントのモデルを決める順番は、公式ドキュメントによると次の4段階です。
- 呼び出しごとに渡された
modelパラメータ - サブエージェント定義のfrontmatterの
model（inheritなら親会話と同じ） - 環境変数
CLAUDE_CODE_SUBAGENT_MODEL - 親会話のモデル
つまりエージェント定義に model を書いておけば、親をどのモデルで起動しても意図した割り当てが維持されます。逆に書き忘れると親のモデルに引きずられ、調査用の軽いエージェントまで最上位モデルで回ってしまいます。
基本方針は、要件整理・設計・レビュー方針の決定など「間違えると後続が全部やり直しになる」ステップに上位モデルを置き、定型実装・整形・一括変換・テスト実行のような検証可能なステップは中位以下に落とすことです。
もう一本の軸「エフォート（reasoning effort）」
モデル名と同じくらい効くのに見落とされがちなのが、思考にどれだけトークンを使うかを決めるエフォートです。モデルを1段上げる前に、まず同じモデルでエフォートを上げて足りるかを試すほうが安上がりになります。
Claude Codeでは /effort コマンド（引数なしでスライダー、/effort high で直接指定、/effort auto で解除）、起動時の --effort フラグ、環境変数 CLAUDE_CODE_EFFORT_LEVEL、settingsの effortLevel / modelSettings で設定できます。公式ドキュメントの説明は次のとおりです。
| レベル | 公式の位置づけ |
|---|---|
| low | 短く範囲が限定され、知能を要求されないレイテンシ重視のタスク。サブエージェント向け |
| medium | 多少の知能を犠牲にしてトークンを削りたいコスト重視の作業 |
| high | 既定値。トークン量と知能のバランス（Opus 4.7のみxhighが既定） |
| xhigh | 30分を超えるような長時間のエージェント作業・コーディング |
| max | 最難関向け。逓減しやすく考えすぎの傾向もあるため、広く採用する前に検証が必要 |
注意点が2つあります。ひとつはHaiku 4.5はエフォート非対応で、対応するのはFable・Opus・Sonnet系のみだということ。もうひとつは、会話の途中でトップレベルのエフォートを変えるとプロンプトキャッシュが無効化されることです。長いセッションでは最初に決めて固定するのが原則です。
Codex側はlow（デスクトップ表記はlight） / medium / high / extra high / max に加えて、複数のサブエージェントへ並列に仕事を割り振るultraがあります。既定はmedium、切り替えは /model のスライダーから。公式の原則は「必要な結果が出る範囲でいちばん低いreasoning effortを使う」です。
工程別のモデル＋エフォート早見表
以下は公式の推奨と料金差から組んだ出発点です。実測値ではないので、自分のリポジトリで1〜2週間まわして上下させる前提のたたき台として使ってください。
Claude Code単体で使う場合
| 工程 | モデル | エフォート |
|---|---|---|
| 調査・コード探索 | sonnet | medium |
| 要件整理・設計・方針決定 | opus（一続きで終わらない規模ならfable） | xhigh |
| 実装 | sonnet | high（既定） |
| テスト作成・実行 | sonnet | medium |
| コードレビュー・最終判断 | opus | high |
| 整形・一括変換・記録 | haiku | 指定なし（非対応） |
設計と実装をひとつのセッションで進めるなら、opusplan を選んでおけば上2段が自動で切り替わります。
Codex単体で使う場合
| 工程 | モデル | エフォート |
|---|---|---|
| 調査・コード探索 | 5.6 Luna | low〜medium |
| 要件整理・設計・方針決定 | Astra または 5.6 Sol | high〜max |
| 実装 | 5.6 Terra | medium〜high |
| テスト作成・実行 | 5.6 Luna | low |
| コードレビュー | 5.6 Sol | high |
| 大きな作業の並列分割 | Astra / 5.6 Sol | ultra |
Lunaは入力$0.20・出力$1.20とSolの20分の1近い単価なので、下流工程をLunaに寄せられるかどうかが総コストをいちばん左右します。
Claude CodeとCodexを併用する場合
| 工程 | 担当 | モデル＋エフォート |
|---|---|---|
| 要件整理・設計・タスク分割 | Claude Code | opus（大規模はfable）／xhigh |
| 計画書の作成 | Claude Code | opus／high |
| 実装・リファクタリング | Codex | 5.6 Terra／medium〜high |
| テスト作成・実行 | Codex | 5.6 Luna／low〜medium |
| コードレビュー | Codex | 5.6 Sol／high |
| 成果物の受け入れ判断・統合 | Claude Code | opus／high |
併用時のコツは、設計の結論を会話で渡さずファイルに書いてパスで渡すことです。実装側は作業中に何度でも読み返せますし、再開時にも前提が残ります。切り分けが妥当かは、SWE-rebenchの1問あたりコストとTerminal-Benchの解決率で年に数回チェックすれば十分です。
ベンチマークを読むときの4つの注意点
- スコア差が誤差の範囲かを見る。上位モデルは2ポイント差に密集していることが多く、その差でモデルを選び直す意味は薄いです。信頼区間が出ているリーダーボードを優先します。
- ハーネスが違えば結果も違う。エージェント系ベンチマークのスコアは「モデル＋足回り」の合計値です。同じモデルでもCLIやスキャフォールドが変われば数字は動きます。
- 汚染と飽和を疑う。長く使われたベンチマークほど学習データに混ざっている可能性があります。SWE-rebenchのように課題を継続更新するものを併用します。
- コスト列があるものを優先する。正答率だけのリーダーボードでは費用対効果は判断できません。Terminal-BenchとSWE-rebenchはこの点で価値が高いです。
まとめ：このページを定点観測リストとして使う
やることは3つです。まず費用対効果の当たりをArtificial Analysisの知能×価格で付ける。次にTerminal-BenchとSWE-rebenchで、エージェント運用時の解決率と1タスクあたりコストを確認する。最後に公式の料金ページとモデル一覧で、その日に実際に指定できるモデル名と単価を確定する。
そのうえで、上流はOpus / Fable相当、実行はSonnet / Terra相当、単純作業はHaiku / Luna相当という骨格を決め、opusplan やサブエージェント定義の model で固定してしまえば、毎回の調べ直しはほぼ不要になります。モデルの世代交代と料金改定は数か月おきに起きるので、このリンク集は四半期に一度ほど見直すのがちょうどよい間隔です。
