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

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

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

価格表で、4モデルの入力と出力は次のとおりです(100万トークンあたり)。

Fable 5.1はSonnet 5の5倍、Opus 5.5の2.5倍です。この表だけ見ると、Fable 5.1は最後の選択肢に見えます。

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

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

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

最初の2行が、トークン単価の逆転です。Fable 5.1のlowは解決率が11ポイント高く、解決1件あたりは35%安くなりました。

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

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

逆転しないケースもある

長い調査ループでは、上位モデルは「少ない仕事」ではなく「多い仕事」をします。DeepResearch Bench IIでは、Fable 5.1のlowがSonnet 5より10ポイント高い点(66%対56%)を出しました。ただし1タスクあたりは約4倍です($4.66対$1.20)。上位モデルが長い調査ループを回し、より大きな文脈を読むためです。

もう一方の端がHaiku 4.5です。GPQA Diamondの設問では、Opus 5.5の約5分の1のコストで答えましたが、正答率は63%で、Opus 5.5の92%に届きませんでした。長いコーディング作業ではさらに差が開いています。答えを機械で検査できる大量処理向きで、長いエージェントループには向きません。

順位は作業の種類で入れ替わります。価格表からは、どちらに転ぶか分かりません。

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

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

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

難しい作業では差が広がります。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.7以降で約30%増えます。トークン単価どうしの比較は、新しいモデルを構造的に高く見せます。既存の移行手順はClaudeモデルの移行ガイドにまとまっています。

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

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

• 調査・知識労働系(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に上がりました
• 長時間のコーディング(SWE-bench Pro、Opus 5.5): highを基準に、mediumは約2.5ポイント低く約70%のコスト、lowは約8ポイント低く約3分の1のコスト、xhighは約1.4ポイント高く2.5倍のコストです

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

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. 本番ログから実際の比率に近いタスクを抜き出し、成功の判定(テスト通過、チケット完了、行数一致など)を付ける。1タスクの費用は、usageの5種類のトークン数(未キャッシュ入力、5分と1時間のキャッシュ書き込み、キャッシュ読み取り、出力)にそれぞれの単価を掛けて、タスク内の全リクエストで合計する
2. モデル階層を、既定だけでなくeffort別にも走らせ、得点と費用の曲線を描く。複数モデルを組み合わせる構成は、単独モデルの曲線全体を超えなければならない
3. effortで埋まらない差が曲線に残るなら、その差に合う複数モデル構成を足して再測定する
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.1を使います。

計測の裏付けは3つあります。SWE-bench Pro部分集合では、Opus 5.5の既定がFable 5.1の既定と同等で、約5分の1でした。別のコーディング計測では、Opus 5.5が86.6%、Fable 5.1(medium、1回の実行)が84.2%で、1試行あたりは$0.84対$2.68です。図表を読むChartographyでは、Opus 5.5のlowが68.7点で1枚約$0.03、Fable 5.1のlowが62.5点で$0.15でした。

Haiku 4.5は、答えを機械で検査できる大量処理に向きます。

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

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