Claudeのモデル選びはタスク単価で比べる — 実測で見る4モデル

Claudeのモデルは、トークン単価の安い順に選ぶと外れることがあります。Anthropicの実測では、トークン単価が5倍のClaude Fable 5.1もlowなら、SWE-bench Pro部分集合の解決1件あたりでClaude Sonnet 5を下回りました。払うのは、トークンではなく終わったタスクだからです。

トークン単価はなぜ判断材料として弱いのか

価格表で、この記事の計測に出てくるモデルの入力と出力は次のとおりです(100万トークンあたり)。

最上位のFable 5.2はSonnet 5の4倍、Opus 5.5の2倍です。Fable 5.1の単価はFable 5.2の1.25倍で、Sonnet 5の5倍、Opus 5.5の2.5倍になります。この表だけ見ると、Fableは最後の選択肢に見えます。

現行のラインアップは、安い順にHaiku 5.5、Sonnet 5.5、Opus 5.5、Fable 5.2です。以降の計測表でFable 5.1と書いてある行は、Fable 5.1で測った結果です。

Sonnet 5.5も入力$2・出力$10で、Sonnet 5と同じ単価です。Sonnet 5の$2/$10は発売時に導入価格として告知されましたが、そのまま標準価格になりました。2026年9月1日に予定されていた$3/$15への値上げは行われません。

ところが能力の高いモデルは、少ない仕事でタスクを終えます。ターン数が減り、検索や自分の文脈の読み直しが減り、やり直しも減るためです。トークン単価の上乗せを、仕事量の少なさが打ち消すことがあります。

SWE-bench Pro部分集合の実測で何が起きたか

Anthropicは、SWE-bench Proの部分集合で各モデルを走らせ、利用者が請求される形で価格を付けました。この部分集合は公開リーダーボードの点数と比較できません。次の数字は、この計測の中だけで意味を持ちます。

下の3行は、別の話です。Opus 5.5の既定は、Fable 5.1の既定と解決率が並びました(92.8%と92.3%は、実行ごとのばらつきの範囲内)。解決1件あたりは約5分の1です。

つまり上位モデルが常に勝つわけではありません。この計測で安かったのは、Opus 5.5の既定と、Fable 5.1を抑えたlowでした。

逆転しないケースもある

作業の種類が変わると、順位も変わります。

調査系は、Opus 5を加えても同じ向きです。既定のOpus 5は71%を1タスク$6.71で出し、既定のFable 5.1(65%、$7.12)を上回りました。調査でFable 5.1が価格に見合うのは、lowのときだけです。

Haiku 4.5は、答えを機械で検査できる大量処理向きで、長いエージェントループには向きません。後継のHaiku 5.5は、GPQA Diamondで85%(Opus 5.5とSonnet 5.5は91%)を出し、正解1件あたりのコストはOpus 5.5の約20分の1でした。料金や退役日などの仕様はClaude Haiku 4.5の料金と仕様で確認できます。

GPQA Diamondの92%には条件が付いています。Opus 5.5の2回の実行は、fallbacks: "default"でサーバー側フォールバックを有効にしたものです。安全性チェックにかかった生物学の6問のうち、5問はOpus 5が代わりに答え、1問は拒否のままでした。フォールバックを切ると、Opus 5.5は1回の実行で5〜6問を拒否します。拒否を不正解に数えると、点は91%です。

新しい世代への切り替えでも同じ見方が要る

モデルIDを新しいものに替えるのは、いちばん安い改善策です。ただし効き方は作業の難しさで変わります。

公式の計測では、Opus 4.7、Opus 4.8、Opus 5のトークン単価は同じです。それでもSWE-bench Pro部分集合では、Opus 4.8がOpus 4.7と同じ解決率を14%安く出し、Opus 5はさらに12ポイント多く解決して1件あたり21%高くなりました。Opus 5をlowで使うと、Opus 4.8の既定を上回りながら、解決1件あたりは約30%に収まります。

Sonnet 5はSonnet 4.6より、1タスクで使うトークンが増えます。それでも単価が下がった分が上回り、解決1件あたり15%安く、解決率は5ポイント高くなりました。Fable 5.1はFable 5と同じ点を、解決1件あたり43%安く出しています。大半はキャッシュ読み取りの単価が下がったためです。

Fable 5.1からFable 5.2への更新は、作業で向きが分かれます。SWE-bench Pro部分集合のうち、参照解がネットワークなしでも通る463問の結果です。既定のhighでFable 5.2が96.3%を解決1件あたり$1.39、Fable 5.1の既定が92.4%を$1.17でした。Fable 5.1の数字はネットワークありで採点したものなので、そろっているのは問題の集合だけです。Fable 5.2はlowにすると94.6%を$0.39で解決し、Fable 5.1の既定より多く解いて費用は約3分の1です。調査系のDeepResearch Bench IIでは、Fable 5.2はどのeffortでもFable 5.1より20〜61%安く、点数は4.7〜7.0ポイント低くなりました。

難しい作業では差が広がります。Terminal-Bench 3では3モデルとも1タスクに$8〜$15を使いますが、解決率は7%、15%、41%です。解決1件あたりのコストは$183、$63、$28と下がりました。Opus 4.8に対するOpus 5の21%高が、ここでは56%の節約に変わっています。旧モデルが失敗する作業ほど、更新の節約は大きくなります。

逆向きの例もあります。DeepResearch Bench IIでは、Fable 5からFable 5.1への更新で、1タスクあたりがhighで41%増えました(lowでは79%増)。入力と出力の単価は同じで、キャッシュ読み取りだけが4分の1です。新しいモデルがその作業でより多く動くためで、更新すれば必ず安くなるとは限りません。

Opus 4.8向けに書いたプロンプトは、Opus 5では1チケットあたり36%高くなりました。プロンプトを見直す監査をかけると、14%安くなり、正答率は92%から97%に上がっています。切り替えのときは、モデルIDと一緒にプロンプトも測り直す対象です。

同じ文章のトークン数は、Opus 4.7以降で約30%増えます。トークン単価どうしの比較は、新しいモデルを構造的に高く見せます。既存の移行手順はClaudeモデルの移行ガイドにまとまっています。

キャッシュを入れるとモデル間の差はどう縮むか

価格表のキャッシュ読み取りは、入力単価の10分の1が基本です。Opus 5.5とSonnet 5.5は20分の1($0.20と$0.10)、Fable 5.1は40分の1($0.25)まで下がります。Fable 5.2も40分の1($0.20)です。入力ではFable 5.1がSonnet 5の5倍、Fable 5.2が4倍です。ただしキャッシュ読み取りではFable 5.1が$0.25対$0.20の1.25倍、Fable 5.2はSonnet 5と同額になります。

エージェントは毎ターン、積み上がった会話全体を送り直します。40ターンのタスクなら、最初のターンの内容を40回送ります。タスクの費用はターン数のほぼ2乗で増えるので、読み取りの単価が全体を左右します。DeepResearch Bench IIの実行を、キャッシュの有無で値付けした結果が次のとおりです。

Anthropicの計測では、キャッシュ読み取りが1タスクの費用で最大の項目になることが多く、モデル選びの多くの判断より効くとされています。実際のエージェントの1日分のトラフィックで、入力のうちキャッシュから読まれる割合は中央値が84%、上位1割の構成は94%以上です。80%を下回るなら、キャッシュを壊す原因を探す目安になります。

キャッシュの保持時間にも選び方があります。Fable 5.2では、人が数分離れる程度の停止なら、5分キャッシュを保つ方が1時間キャッシュより約4.5〜19%安く済みました(ターンの1割で停止する場合と、毎ターンの前に6分停止する場合)。1時間が勝ったのは、毎ターンの前に45分停止した場合だけです。

ここまでのタスク単価の比較は、どれもキャッシュが効いている前提の数字です。キャッシュが効かない構成では、単価の高いモデルほど不利になります。

effortを動かすとタスク単価はどう変わるか

モデルを固定しても、effortで単価は動きます。計測結果から、作業の種類ごとに曲線の形が違うことが分かります。

Messages APIでの既定のeffortはモデルごとに違います。Opus 5.5とHaiku 5.5はmediumで、effortに対応するほかのモデルはhighです。Claude Codeでは、Fable 5.2、Opus 5.5、Sonnet 5.5、Haiku 5.5の既定がmediumで、Opus 4.7はxhigh、ほかのモデルはhighです。既定どうしの比較は、同じ水準の比較ではありません。Sonnet 5.5は水準が再調整されていて、同じhighでもSonnet 5と同じだけ考えるわけではありません。Sonnet 5での設定は持ち越さず、測り直します。

• 調査・知識労働系(WideSearch、DeepWideSearch、BrowseComp、GDPval。いずれもFable 5): lowで精度が1〜3ポイント下がり、コストは3分の1〜半分減ります。mediumは既定と同じ精度を約70〜87%のコストで出します。既定がmediumを上回った例は、4つのどれにもありません
• 長い調査(DeepResearch Bench II、Fable 5.1): low、medium、highでほぼ同じ点数のまま、1タスクあたりが$4.66から$7.12に上がりました
• 長い調査(DeepResearch Bench II、Fable 5.2): lowが54.5%で$1.49、mediumが55.0%で$2.16、highが57.7%で$4.82です。点数の伸びに比べて費用の伸びが大きい作業です
• 長時間のコーディング(SWE-bench Pro、Opus 5.5): highを基準に、mediumは約2.5ポイント低く約70%のコスト、lowは約8ポイント低く約3分の1のコスト、xhighは約1.4ポイント高く2.5倍のコストです

調査系では、上げて得られる点数が計測によって分かれます。コーディングでは、上げた分だけ点数が付いてきます。作業の説明文を読んでも、どちらの型か見分けられません。サンプルを取って測るしかありません。

effortは速さにも効きます。DeepWideSearchの1問あたりは、lowで4.5分、既定で7.9分でした。入力が単一のコンテキストに収まらないコーパスのベンチマークでは、Fable 5.1の1エピソードがlow、medium、highで15.2時間、17.5時間、19.9時間かかっています。

出力の上限も単価に効きます。上限を16,384トークンにすると、Fable 5.1の試行の43%が途中で打ち切られました。タスク単価は64,000トークンのときと同程度($21対$22)で、上限を絞っても安くはなっていません。

構成を変える前に、effortを下げる手があります。DeepWideSearchでは、Fable 5のlowが、Sonnet 5を作業役にしたオーケストレーター構成と同じ点を、29%安く出しました。単一モデルの既定より安く見えた複数モデル構成が、同じモデルを低いeffortで動かした場合より高くついた例もあります。

effortの各水準の意味と既定値はClaude effortとは — low〜maxの使い分け方に、Opus 5系での使い分けはClaude Opus 5のeffort使い分け方にあります。

失敗分だけ高いeffortで再実行する

結果を機械で検査できるなら、全タスクを低めのeffortで走らせ、失敗した分だけ上げて再実行する運用が安く済みます。

同じ実行結果からタスクごとに計算した数字は次のとおりです(Opus 5.5、SWE-bench Pro部分集合)。

失敗した最初の試行の費用も含めて、この数字です。通過率は少し上がり、費用は半分強に収まりました。上がった分の大半は2回目の試行によるものなので、公式はこの運用を「節約のために使う」ものとしています。

条件は2つあります。テストのように、失敗を判定できる信号が要ります。判定が甘いと、悪い結果がそのまま通ります。もう1つは待ち時間です。最初に失敗したタスクは2回分の実行時間がかかります。

自分のトラフィックで測る4つの手順

ここまでの数字はAnthropicの社内計測で、方向を示すものです。測る手順は次の4つです。

手順1の費用計算は、シェルで書くとこうなります(公式の例に沿った形。単価はOpus 5.5のもので、別モデルなら3つの値を書き換えます)。

INPUT_PER_MTOK=4.00
CACHE_READ_PER_MTOK=0.20
OUTPUT_PER_MTOK=20.00
 
jq -r --argjson in "$INPUT_PER_MTOK" \
      --argjson read "$CACHE_READ_PER_MTOK" \
      --argjson out "$OUTPUT_PER_MTOK" '
  .usage
  | (.input_tokens * $in
     + (.cache_creation.ephemeral_1h_input_tokens // 0) * $in * 2.00
     + (.cache_creation.ephemeral_5m_input_tokens // 0) * $in * 1.25
     + (.cache_read_input_tokens // 0) * $read
     + .output_tokens * $out) / 1e6
' response.json

1リクエストの費用が出たら、タスク単位で合計し、成功したタスク数で割ります。失敗したタスクの費用も分子に入れる点が要です。

# costs.tsv: 1行1タスク。列は task_id, cost_usd, passed(1/0)
awk -F'\t' '{c+=$2; p+=$3}
  END {printf "解決1件あたり: $%.3f (解決率 %.1f%%)\n", c/p, 100*p/NR}' costs.tsv

モデルごとに同じ集計を出し、effort別にも並べると、上の表のような比較ができます。評価データを使ってモデルとeffortを自動で探索する手順は、/claude-api hillclimbが扱っています。

結局どこから始めるか

出発点は次のとおりです。ほとんどのエージェント作業は、Opus 5.5の既定(medium)から始めます。難しい推論や長時間のエージェント作業、あるいはOpus 5.5を上のeffortで走らせても評価が足りない場合に、Fable 5.2を使います。

Claude Codeでは、gateway以外のセッションなら/model fableでFable 5.2を選べます。Claude appsのgatewayではfableがFable 5を指すので、/model claude-fable-5-2と指定します。

ユーザー設定に保存したclaude-fable-5-1は、Pro・Max・Ultraでは初回起動でfableのエイリアスへ移ります。Team・Enterpriseは組織の設定しだいで、移らないこともあります。移ったあとは、effortを自分で設定していなければFable 5.2の既定(Claude Codeではmedium)で始まります。Consoleアカウント、サードパーティー、project・local・managed設定のclaude-fable-5-1はそのままです。

SWE-bench Proの結果に加えて、別の計測が2つあります。コーディングでは、Opus 5.5が86.6%、Fable 5.2(medium、1回の実行)が88.9%で、1試行あたりは$0.84対$1.34でした。図表を読むChartographyでは、Opus 5.5のlowが68.7点で1枚約$0.03、Fable 5.1のlowが62.5点で$0.15、Opus 5のlowが49点で$0.16です。

DeepResearch Bench IIの44問(Messages APIの既定effort)では、Fable 5.2の1タスクあたりはSonnet 5.5の4.3倍でした。測れるほどの点数の向上はありませんでした。長い調査でFable 5.2をlowから測る理由はここにあります。

この表は「最初に測る候補」で、結論ではありません。同じ作業でもトラフィックが変われば、順位は入れ替わります。

Opus 5.5そのものの単価を、ターン数とキャッシュ読み取りに分けて試算する手順はOpus 5.5のタスクコストを試算する方法にあります。この記事はその手前で、どのモデルを候補にするかを決める段階を扱っています。