Claude Opus 5.5のeffortをSWE-bench Proの点差と費用で選ぶ

Claude Opus 5.5のeffortは、APIで何も指定しなければmediumで動きます。長い実装タスクを解くSWE-bench Proの測定では、highを基準にするとmediumは約2.5点低く、費用は約70%です。lowは約8点低く費用は約3分の1、xhighは約1.4点高く費用は2.5倍になります。

この記事では、これらの数字がどの条件で出たものか、費用の絶対額はいくらか、読み違えやすい点はどこかを順に見ます。Opus 5との違いや使い分けの方針そのものはClaude Opus 5のeffort使い分け方に書いています。

Opus 5.5のeffortは何が既定なのか

highが既定のモデルが多いなか、Opus 5.5とHaiku 5.5だけはmediumが既定です。effortのリファレンスには、既定値を明示的に指定した場合の動きも書かれています。Opus 5.5で"medium"を渡すのは、effortを省略するのと完全に同じ挙動です。

なお、同じくmediumが既定のHaiku 5.5では、lowをチャットや短いツール作業、単純で大量のリクエスト向けに使う想定です。

Opus 5までのOpusはhighが既定でした。Opus 5のコードをそのまま移すと、effortを書いていないリクエストは1段階低い設定で動きます。移行手順の全体はClaude Opus 5.5とはにまとめています。

SWE-bench Proの測定条件はどうなっているか

数字を使う前に、条件を押さえておきます。出典はAnthropicの「Optimizing for cost and intelligence」ページとその参照文献の注記で、条件は次のとおりです。

• 問題セットは、Anthropicの評価環境に合わせて選んだ482問の部分集合です。Opus 5.5の比較にはそこから4問を除いた478問を使っています
• 公開リーダーボードのスコアとは比べられません。Opus 5.5のシステムカードにあるSWE-bench Proの値とも別物です(あちらはmaxで別の問題セット)
• low・medium・highは2回の平均、xhighは1回の実行です
• 実行日は2026年9月19〜20日で、1ターンの出力上限は16,384トークンです。この上限で打ち切られた試行はxhighで2件、ほかの設定では0件でした

xhighだけ1回の実行で、しかも2件が上限で途中終了している点は覚えておく価値があります。約1.4点という差は、2回平均のlow〜highほど固くありません。

effortごとの点差と費用を並べるとどうなるか

比較の基準はhighです。この部分集合での正答率と、費用の絶対額は次のとおりです。

元の資料で「解けた1問あたり」として載っているのはlowの$0.12とmediumの$0.22で、highの$0.29は「1問あたり」(失敗した問題の費用も含む)です。単位をそろえるため、表の「1問あたり」はlowとmediumを正答率で換算し($0.12×0.874、$0.22×0.928)、highの「解けた1問あたり」は$0.29÷0.953で求めています。xhighの絶対額は載っていません。

読み取れることは3つあります。

1. mediumは、約2.5点を手放して費用を約3割減らす位置です
2. lowは点差が約8点と大きく、費用の下がり方(約3分の1)に対して精度の落ちが目立ちます
3. xhighは点が上がるものの、費用が2.5倍になります

長い実装タスクは、effortが精度を実際に買う領域です。effortを下げれば品質は保てる、という一般則は成り立ちません。

点差と費用の比が数字ごとに合わないように見えるのはなぜか

表のドル額をそのまま割ると、比率が本文と食い違って見えます。lowは$0.12÷$0.29で約41%、mediumは$0.22÷$0.29で約76%になり、「約3分の1」「約70%」と合いません。

原因は単位の取り違えです。$0.12と$0.22は「解けた1問あたり」、$0.29は全件をhighで回したときの「1問あたり」で、別の量を割っています。1問あたりに直すと、lowは$0.12×0.874≒$0.105で、$0.29の約36%(約3分の1)です。mediumは$0.22×0.928≒$0.204で約70%になります。換算すれば、ドル額と比率はどちらも一致します。

自分でコストを試算するときも、「解けた1問あたり」と「1問あたり」のどちらの値かを確かめてから割ってください。ドル額から試算する手順はOpus 5.5のタスクコストを試算する方法にあります。

研究・知識労働の課題でも同じ傾きなのか

WideSearch・DeepWideSearch・BrowseComp・GDPvalという研究・知識労働のベンチマークも測られています。ただし使ったのはClaude Fable 5で、Opus 5.5ではありません。

• lowは精度が1〜3点下がる代わりに、タスクあたりの費用が3分の1〜半分になる
• mediumは既定と同じ精度を、費用の約70〜87%で出す
• 既定はmediumに対して、測れる差をどの課題でも生まなかった

つまり曲線はほぼ平らです。SWE-bench ProでのOpus 5.5の曲線は急で、同じ「effortを下げる」という操作でも、課題の種類で結果が逆になります。

待ち時間にも差が出ます。Fable 5のDeepWideSearchでは、1問あたりlowが4.5分、既定が7.9分でした。費用だけでなく、応答の速さが制約になる用途でも、effortは最初に動かす設定です。ただしこの時間はFable 5の値で、Opus 5.5のSWE-bench Proの所要時間は載っていません。

自分の課題がどちら側かは、課題の説明文だけでは分かりません。2〜3段階のeffortを自分のトラフィックの標本で試し、曲線から読むのが手順です。

mediumの正答率はFable 5.1の既定と並ぶのか

同じ部分集合で、上位モデルとの比較もあります。Opus 5.5の既定mediumは正答率92.8%で、Fable 5.1の既定の92.3%と並びます。差は実行のばらつきの範囲内です。

費用は大きく違います。解けた1問あたりの費用は、Opus 5.5が$0.22、Fable 5.1が$1.19で、約5分の1です。lowのOpus 5.5でも87.4%を$0.12で解いています。

ただし、この部分集合はOpus 5.5とFable 5.1のどちらも上限近くまで解ける問題が多い構成です。長期の研究ループのように、上位モデルが仕事量そのものを増やして点を取る課題には、この比は当てはまりません。順位は課題で入れ替わります。

失敗したときだけeffortを上げる運用は安いのか

測定した差を使うと、固定のeffortで全件を回さない運用も組めます。まずlowで全件を解かせ、検証に失敗した分だけhighでやり直す方式です。

Opus 5.5の同じ測定では、結果は次のとおりです。

失敗した最初の試行のぶんも費用に入っています。それでもlow起点なら全件highの約6割($0.17÷$0.29)、medium起点でも約8割($0.24÷$0.29)の費用です。向上したぶんの多くは2回目の試行がもたらしたもので、highの失敗をhighで再実行しても点はほぼ同じで、費用だけが増えます。狙うのは精度の向上ではなく費用の削減です。

条件も2つあります。成否を判定する仕組み(ここではベンチマーク自身のテスト)が必要で、通ってはいけない結果を通す検査器だと失敗を取りこぼします。もう一つは、失敗した課題が2回ぶんの待ち時間を使うことです。

自分の課題で曲線を引くには

測り方は、同じ課題の標本をeffortだけ変えて流すことです。リクエストはoutput_config.effortで指定します。

for e in low medium high xhigh; do
  curl -s https://api.anthropic.com/v1/messages \
    -H "x-api-key: $ANTHROPIC_API_KEY" \
    -H "anthropic-version: 2023-06-01" \
    -H "content-type: application/json" \
    -d "{\"model\":\"claude-opus-5-5\",\"max_tokens\":16000,
         \"output_config\":{\"effort\":\"$e\"},
         \"messages\":[{\"role\":\"user\",\"content\":\"<課題>\"}]}" \
    | jq --arg e "$e" '{effort: $e, usage}'
done

出力のusageを並べれば、effortごとのトークン量が比べられます。正答率は、自分のテストや採点基準で別に付けます。max_tokensは高いeffortで足りなくなるので、実際の課題では余裕を持たせてください。

測るときのキャッシュにも注意が要ります。セッションの途中でトップレベルのeffortを変えるとキャッシュが無効になり、比較が歪みます。effortごとに別のセッションで試すのが原則です。Opus 5.5にはメッセージ単位のoutput_configでキャッシュを保ったまま会話の途中でeffortを変える機能(ベータ)がありますが、これはこのページの測定とは別の話です。

effortを下げたほうが安い場面はあるのか

構成を増やす前に曲線を引く理由もあります。社内測定では、既定の単一モデルより安く見えた複数モデル構成が、同じモデルを低いeffortで動かしたときより高くつきました。たとえばFable 5のDeepWideSearchでは、lowがSonnet 5を作業役に置いたオーケストレーターと同じ精度を、29%低い費用で出しています。

Opus 5.5側の結論は反対向きに働きます。SWE-bench Proでは、lowに落とすと約8点を失います。構成を変えるより先に、effortを動かして曲線を見る。その曲線が平らなのか急なのかで、次の手が決まります。

まとめ

Opus 5.5の既定mediumは、SWE-bench Proではhighとの差が約2.5点で、費用が約3割軽い位置にあります。lowは費用の下がりが大きい反面、点を約8点失い、xhighは約1.4点を足すのに2.5倍かかります。

費用を抑えたいなら、検証で成否を判定できる課題では、低いeffortで流して失敗だけhighで再実行する形が有利でした。low起点なら全件highの約6割、medium起点でも約8割の費用で、同等以上の正答率(約97%)です。ただし、これは検証で成否を判定できるコーディング課題での測定です。自分の課題でmediumから1段ずつ振り、曲線の傾きを確かめてから決めるのが確実です。