Terminal-Bench 3.0で見るeffortの効き方 — Claude Codeでの使い分け

effortは、モデルに「どれだけの計算量を使ってよいか」の目安を渡すつまみです。Claude Code向けの開発者ブログ「Using Claude Code: Spending your effort」(Thariq Shihipar、2026年9月25日公開)は、これを検証と判断の量の調整として説明しています。高く設定すると、Claudeはエッジケースを試し、自分の判断で動く場面が増えます。

ブログは、Opus 5.5での自前の比較実験と、コミュニティ発のベンチマークTerminal-Bench 3.0の結果を並べて、この主張を支えています。ここではその数字を読み解き、Claude Codeでの設定に落とします。

effortは「頑張り度」ではなく「どこまで自分で確かめるか」

筆者はeffortを、依頼の締め切りに例えています。12時間ぶっ通しで取り組めと言われれば、全力で作り込むと受け取るでしょう。1時間と言われれば、条件を満たす最良のものを早く出し、そこから往復で直す前提になります。3時間は要ると押し返し、3時間かけて仕上げる選択もあります。

effortもこれと同じ読み方ができます。どのレベルでもClaudeは依頼を妥当にこなそうとします。違いは、高いほど自分で判断し、自分で検証する範囲が広がる点です。

この整理は、Claude Codeの設定ドキュメントの説明とも合います。ドキュメントは、Opus 5.5とFable 5.1でのテストで、高いレベルのClaudeはエッジケースを多く試し、回答前の検証も増え、自分で下す選択も増えたと書いています。低いレベルは、ユーザーが各結果を見て次を指示する作業向けに、出発点を早く返します。

つまり、effortを上げると「賢くなる」というより、「確認を省かなくなり、聞き返さなくなる」。後者は見落とせません。ユーザーが同席しているなら、聞き返してもらったほうがよい場面もあるからです。

同じ依頼でもeffortで所要時間は約45倍変わる

Opus 5.5で同じ依頼を複数のレベルで走らせると、所要時間は次のように開きました。

lowからmaxで所要時間は約45倍です。作られるアプリの作り込みも、Claudeが代わりに下した設計判断の数も増えます。簡単な土台から自分で育てたいならlow、一発でClaudeの最良案が欲しいならmaxが向く、という整理です。

条件を変えると差の出方が変わります。

仕様を詰めると、effortが埋めていた「判断の余白」が減ります。差が縮むのは当然の結果で、先の要点の裏返しでもあります。余白が大きい依頼ほどeffortの影響が大きく、小さい依頼ほど影響が小さい。

もう1つの例は、Claude Codeの/configメニューの再設計です。方針はほぼ決まっている依頼で、lowは1分で、考え方を伝えるが見た目はClaude Codeに似ていないスケッチを返しました。maxは28分で、Claude Codeらしい見た目のモックアップと、複数の操作フローの説明まで出しています。ブログの筆者は、方向性をつかむ目的なら低いeffortで足りると見ています。

Terminal-Bench 3.0で見ると、効くのは「穴が多い」仕事

おもちゃの例では、どのレベルでも完了します。完了できるかどうかが分かれる難しい課題を見るために、Terminal-Bench 3.0を取り上げます。コミュニティから提供されたタスクで構成され、セキュリティ、ハードウェア、ML、科学、ソフトウェア、運用、メディアに大別されます。

タスクの例です。どれも、日常の依頼より大がかりです。

• ハードウェア(retro-console-soc): FPGAに収まる8ビットゲーム機をVerilogで作り、テストROMを描画する
• 科学(takens-embedding-lean): タケンスの埋め込み定理をLean 4で形式証明する
• ML(mp-checkpoint-consolidation): MoEチェックポイントの16シャードを1ファイルに統合し、基準のlogitsを再現する
• 運用(intrastat-meldung): 企業の月末EU貿易統計の申告を一貫して実行する
• メディア(layout-config-recreation): ポスター画像を編集可能なレイアウトファイルに作り直す

html-js-filterで何が起きたか

最も分かりやすい例が、あらゆる手口で混入するJavaScriptを除去するHTMLサニタイザーを作るhtml-js-filterです。Fable 5.1は、lowでは5回中1回、xhigh(highとmaxの間のレベル)では5回中5回成功しました。¹

差は思考の深さというより、検証の工程がいくつ増えたかにあります。穴を突かれる性質のタスクだから、この工程が成否を分けました。

失敗の種類は半分しか減らない

図Bは、Fable 5.1の全結果をlowとmaxで比べたものです。各370回の試行で、1試行あたりのトークン数の中央値はlowが7.3万、maxが22.2万です。失敗の分類はモデルによる判定で、近似値だと断り書きがあります。

エッジケースの見逃しは、「手元では動く」「例にだけ合わせた」「惜しいが不正確」「自分のテストが拾えないバグ」の合計です。判断の誤りは、要件の読み違い、不完全な修正、分野のルールの誤り、解釈の選び違いの合計になります。

成功率は37.8%から57.8%へ約20ポイント上がり、トークンの中央値は約3倍です。見逃しが59から24に減る一方、判断の誤りは133から107にしか減りません。

失敗全体に占める判断の誤りの割合は、lowで230件中133件、maxで156件中107件です。割合で見ると、約58%から約69%に上がります。effortを上げて減らせるのは主に「確かめれば防げたミス」で、方針そのものを誤った試行は残ります。ブログも、effortは欠けているエッジケースによる失敗を減らすが、アプローチ自体が間違っている場合は直さない、とまとめています。

内訳の中には逆向きの動きもあります。「解釈の選び違い」は25件から47件に増えました。この点は個別には論じられていません。数字だけを読むと、失敗が別の型へ移った部分があるように見えます。

分野によって効き方が違う

図Cは、Fable 5.1の分野別の成功率をlow(下位2段階の合算)と上位(上位3段階の合算)で比べています。分野ごとのタスク数が少ないため、複数の設定を合算した値です。

差が大きいのはハードウェアとセキュリティで、コードレビューもこの側に入ります。運用とメディアは上げても低いままで、図には「ルールブック型の仕事は低いまま」という注記が付いています。タスク数が5件や4件の分野は、1タスクの成否で率が大きく動く点に注意が要ります。

なお7分野のタスク数の合計は74で、図Bの370回(74タスク×5回)と整合します。図Aの70タスクは、GPUを使う4タスクを除いたものです。

Opus 5.5で失敗がどう変わったか

Opus 5.5がlowで落ち、高いeffortで通った3つのタスクは、個々の実行の中身が紹介されています。

3つとも、高い側のClaudeは「自分の答えを疑う実験」を足しています。再現、別実装との突き合わせ、前提を変えての再実行です。

gsea-proteomicsについて、ブログは興味深い補足をしています。ユーザーが同席していれば、Claudeは前処理の方法をユーザーに聞いたかもしれません。同席しない場面だから、高いeffortが効いた、という整理です。

Claude Codeでの使い分け

目安は次のとおりです。設定ドキュメントの「Choose an effort level」の表も、同じ使い分けを載せています。

筆者が新機能開発で回している手順は、次の4段階です。

この手順は、先のフィットネスアプリの結果と筋が通っています。曖昧な依頼を高いeffortに渡すと、Claudeが代わりに決める部分が増えます。先にインタビューで仕様を詰めれば、低いeffortでも収まりのよい実装になり、検証の段だけ高くして穴を探す、という配分です。

レベルは途中で変えられます。新しいモデルはClaude Codeでプロンプトキャッシュを壊さずにeffortへ反応します。

/effort low
/effort high

/effortを引数なしで打つとスライダーが開き、レベル名を付けて打つとそのレベルに設定されます。設定の保存先や優先順位、sキーでそのセッションだけに適用する方法は、Claude Codeのeffortレベルの使い方にまとめています。

検証だけを高いeffortに任せる構成

ループの最後の段を、毎回セッション全体のeffortを上げて行う必要はありません。サブエージェントのフロントマターにはeffortを書けます。そのサブエージェントが動く間だけ、セッションのレベルを上書きできます(環境変数CLAUDE_CODE_EFFORT_LEVELには負けます。maxEffortLevelや組織の上限もかかります)。検証役を専用に置く場合の書き方の例です。

---
name: verifier
description: 実装後に検証とエッジケースの確認を行う
effort: high
---
 
実装を読み、再現手順とテストを自分で実行して結果を報告してください。
テストが元の不具合を実際に検出できるかも確認してください。

メインのセッションはmediumのまま、検証だけをhighで回せる構成です。先の成功例の共通点(再現してから直す、テストが元のバグを拾えるか確かめる)を、指示文に入れてあります。こうした指示文がどれだけ効くかは、出典では検証されていません。ここは構成の一例にとどまります。

数字を読むときの注意

数字には、前提条件がいくつも付いています。

• 数字はAnthropic社内の実行結果で、1タスク5回の試行です。Fable 5.1の本番用の安全介入はオフでした。Claudeの各製品では、Fable 5.1の保護機構が一部のセキュリティ関連の依頼をOpusに回すため、製品での挙動とは条件が違います
• セキュリティのタスクはインターネットなしで実行されました。タスクごとの件数は、公開リーダーボードやリリース時の発表と一致しません
• 個別の実例は個々の実行で、中間のeffortで走らせたものも含みます。「5回中4回」といった数字は、試行5回の小さな標本です
• 図Aの曲線のうち、Opus 5.5は他のモデルより約3週間後に走らせ、応答は12.8万トークンまでの制限が付き、GitHubとPyPIにはアクセスできない条件でした。Opus 5の「max」は、effort 120での実行です。モデル間の曲線を同じ土俵の比較として読むのは避けたほうがよい条件です
• 図Bの失敗の種類は、モデルによる判定で、近似値です

さらに、同じレベル名でも、モデルごとに内部の値が違います。設定ドキュメントは、effortの尺度がモデルごとに調整されていて、レベル名が同じでも基になる値は同じではないと書いています。Opus 5.5では、同じレベルでOpus 5より1ターンに多く考える傾向があり、Opus 5.5のmediumが既定です。Opus 5から移るときに、以前のレベルをそのまま持ち込まない目安もドキュメントにあります。Claude Opus 5.5とはも、既定モデルの変更点とあわせて参照できます。

「maxにしておけば安心」ではない理由

結論を、費用の面から読むと2つの点があります。

1つ目は、成功率の伸びとトークンの伸びが釣り合わないことです。図Bでは、成功率は約20ポイント、トークンは約3倍です。タスク単位の費用感はOpus 5.5のタスクコストを試算する方法で分解できます。依頼がすでに十分明確なら、高いeffortで増える費用のうち、どれだけが成否に効くかは小さくなります。

2つ目は、ドキュメントの注意書きです。maxには収穫逓減があり、考えすぎに陥りやすいので、広く採用する前に試すよう書かれています。maxが勧められる場面は、ユーザーが付かずに難題を解かせるときに絞られています。

整理すると、effortを上げる価値が高いのは、答えの正しさを自分のテストで確かめられるタスクです。穴の数が多く、穴の位置が事前に分からない仕事ほど、検証工程を増やす効果が出ます。ルールの解釈が成否を決める仕事は、effortを上げても方針の誤りが残る。その場合は、effortを上げる前に仕様と制約を詰めるほうが効きます。

Fable 5.1自体の仕様と価格は、Claude Fable 5.1の解説にあります。

まとめ

effortは、Claudeの自律度のつまみです。高いほど検証が増え、聞き返しは減ります。Terminal-Bench 3.0の結果は、その効果が「穴が多く、検証で潰せる仕事」に偏ることを示しています。ハードウェア、セキュリティ、レビューで大きく、運用やメディアのようなルールブック型では小さい。方針の間違いは、effortでは直りません。

日常の開発はmediumで回し、低いeffortで土台を作って、検証の段だけhighに上げる配分が、ブログの筆者のやり方です。ただし数字は社内の少数試行に基づくので、自分の仕事で/effortを切り替えて比べる前提で読むのが妥当です。

¹ 数字の前提条件は「数字を読むときの注意」にまとめています。