最新の Claude モデルの最大の魅力のひとつは、Claude Code においてプロンプトキャッシュを壊すことなく effort（処理の集中度）に応じて応答を変えられる点ですが、ユーザーからこれについて多くの質問をいただきました。effort とは具体的に何で、どのレベルをいつ使うべきなのか？そもそもなぜ effort が必要なのか？
この疑問に答えるため、私は eval（評価テスト）を深く掘り下げ、日常業務における effort の効果を自分で検証してみることにしました。
注：この記事に関するインタラクティブな図解や解説は、https://claude.dev/blog/spending-your-effort/ でご覧いただけます。
大まかに言うと、effort は「Claude がどれくらい検証やエッジケースのテストを行うか」、そして「自身の判断をどれだけ活用するか」を調整する優れた手段であることがわかりました。
effort を高く設定すると、ハードウェア、コードレビュー、セキュリティなど、検証やエッジケースのテストが特に有効な領域でより良い結果が得られました。
一方で、low や medium の effort は、作業を素早く終わらせ、Claude と密に連携しながら進めるのに最適でした。
通常のソフトウェア開発では、まずモデルに私へヒアリングさせ、次に low または medium の effort で実装し、構築された内容を確認してから、high の effort で検証を実行するというループを回しています。
effort とは何か？
大枠として、effort はタスクに対してどの程度の計算リソースを費やすかをモデルに伝える目安となります。これは、あなたが想定するタスクの難易度ともある程度関係しています。
こう考えてみてください。誰かに「12 時間ぶっ通しでこれをやってほしい」と頼まれたら、あなたは「とにかく全力でやり遂げればよいのだな」と解釈するでしょう。しかし同じタスクを「1 時間でやってほしい」と頼まれたら、まずは要件を満たす最良のバージョンを提示し、そこから改善を重ねていくことを前提にするはずです。
あるいは、「このタスクには『最低でも』3 時間は必要だ」と反論し、実際に 3 時間かけて成果物を提出するかもしれません。
effort もこれと同じように捉えてください。Claude は常にタスクを適切にこなそうとしますが、effort を高くするほど、判断や検証においてより自律的に行動するようになります。
effort の推移
Fable 5.1 と Opus 5.5 の effort カーブは過去最高の出来栄えで、各レベルでベンチマークスコアと消費トークン数が増加していきます。以下は、この記事のために私が実施した eval で計測した、effort 別の Terminal Bench 3.0 スコアのグラフです。
では、実際のところこれは何を意味するのでしょうか？それを確かめるため、いくつかのタスクを異なる effort レベルで試し、ベンチマークを細かく分析しました。
effort を活用した開発
モデルの仕組みを理解する最善の方法は、実際に試してみることです。Opus 5.5 で同じタスクを複数の effort レベルで実行し、どのような作業が行われるのかを観察しました。幅広い種類のタスクで検証しましたが、ここでは理解しやすいシンプルな例をいくつか紹介します。
仕様が曖昧な開発タスク
「個人用のフィットネス・ワークアウト記録アプリを作って」と Claude に依頼した場合、effort によってアプリの完成度が大きく変わるだけでなく、途中で Claude が行う意思決定の数も変化します。low effort では、フィットネスアプリは単なるログとシンプルなグラフにとどまります。effort を上げるほどアプリは複雑になり、詳細が追加されていきます。max effort にすると、ヒートマップまで備わります。
繰り返し改善するためのシンプルな土台が欲しいなら、low effort で十分です。一方、一発で Claude の最高品質の成果物が欲しい場合は max effort が適しています。
仕様がやや明確なデザインタスク
すでにかなり具体的な仕様があるものの、Claude と一緒にアイデアを広げたい場合はどうでしょうか？例として、Claude Code の /config メニューを再デザインするよう依頼してみました。どの effort でも、サブメニューの活用や検索機能の改善という基本的な方向性はほぼ同じでした。
low effort（所要時間 1 分）では、コンセプトは伝わるものの、あまり Claude Code らしくないインタラクティブなスケッチが出力されました。
max effort（所要時間 28 分）では、非常に Claude Code らしい見た目のモックアップに加え、さまざまな操作フローのウォークスルーが複数提示されました。
目的がフィードバックを与えながら改善を重ねることなら、low effort の方がずっと早くゴールに到達できます。しかし max effort は、最初からかなり洗練された成果物を出してくれます。今回のタスクに関しては、Claude の構想を把握するために low effort を使う方が好ましいと感じました。
仕様が詳細な開発タスク
では、Claude に多くの詳細情報を渡したらどうなるでしょうか？フィットネスアプリについて詳しくヒアリングするよう依頼し、その仕様書を異なる effort レベルの複数のモデルに実装させてみました。
この仕様書を与えた場合、モデル間の挙動はかなり似通っていることがわかりました。全体的に見た目や実装方法が似たデザインが出力されましたが、細部には違いがありました。max effort では、一部の仕様を簡略化するために少し時間をかけていました。
まとめ
通常のソフトウェア開発、特に新機能の開発においては、自分がどの程度関与したいかによって最適な effort レベルが大きく変わります。low effort なら、Claude がすぐに起点となるものを提示してくれます。effort を上げるほど多くの作業を進めてくれますが、その分 Claude がこちらに代わって前提条件を決めつけることも増えます。
機能開発において私がよく使っている、特に効果的なループは以下の通りです。
- Claude に仕様を渡し、不足している詳細についてヒアリングしてもらう
- low effort で実装させる
- 意図が正しく反映されているか確認し、必要に応じて low effort で修正を重ねる
- high effort で検証とテストを行う
難しいタスクにおける effort レベルの影響
もちろん、これまでの例はどれも簡単で、Claude が余裕でこなせるものでした。では、effort の差が「タスクを完了できるかどうか」を分けるような場合はどうでしょうか？
こうした難しい問題を見つけるにはベンチマークを見る必要があります。そこで、私が気に入っているコミュニティ主導のベンチマーク「Terminal Bench 3」を詳しく調べました。
Terminal-Bench 3.0 の問題は、おおまかにセキュリティ、ハードウェア、ML、科学、ソフトウェア、運用、メディアなどのカテゴリに分けられます。すべての問題はこちらから確認できます：https://github.com/harbor-framework/terminal-bench/releases/tag/v3.0.0 これらはコミュニティから提供されているため、誰でも貢献可能です。
これらのモデルが直面する問題の種類を把握するためにも、ぜひ一度目を通してみてください。多くのタスクの規模と野心的な内容に驚かされました。私が普段直面するタスクよりもはるかに複雑です。
たとえば、次のようなタスクが含まれています。
- ハードウェア (retro-console-soc)：小型 FPGA に収まり、テスト ROM を描画できる 8 ビットゲーム機を Verilog で構築する。
- 科学 (takens-embedding-lean)：Lean 4 で Takens の埋め込み定理を形式的に証明する。
- ML (mp-checkpoint-consolidation)：Mixture-of-Experts チェックポイントの 16 個のシャードを 1 つのファイルに統合し、参照 logit を再現できるようにする。
- 運用 (intrastat-meldung)：企業の月末 EU 貿易統計申告をエンドツーエンドで実行する。
- メディア (layout-config-recreation)：ポスター画像を編集可能なレイアウトファイルとして再構築する。
エッジケースが多いタスクでは高 effort が有効
Terminal Bench 3 の結果を読んで得られた最大の知見は、隠れたエッジケースが多いタスクには高 effort が最適ということです。
わかりやすい例が html-js-filter です。これは Terminal-Bench 3.0 のタスクで、ページに JavaScript を紛れ込ませるあらゆる手法を排除する HTML サニタイザーを作成するものです。Fable 5.1 は low で 1/5 だったスコアが、xhigh では 5/5 になりました。
low effort での典型的な試行は約 2 分で終了します。いずれの試行でも、ほぼ一発でフィルターを書き上げ、手書きの 1 ページだけでテストを行っていました。
一方、high effort の実行は約 33 分かかります。私が追跡した実行では、まず最初のドラフトを攻撃的な視点でレビューし、インストールされているパーサーのソースを読んでバグがないか確認し、入力と同じ出力が返るまで多数のクリーンなテストケースを実行し、標準的な XSS テストスイートを走らせ、最後にランダムドキュメントファザーを作成していました。
HTML サニタイザーのようにエッジケースが極めて多いものについては、この追加の労力をかける価値が十分にあります。パフォーマンス最適化やセキュリティレビューのように、本番環境での要求水準が高い複雑なタスクにおいても、徹底さを求めてトークンを多く消費するのは理にかなっています。
ただし、すべてのタスクでこのレベルの effort が必要なわけではありません。
下の図は、さまざまなモデルと effort レベルにおける Terminal-Bench 3.0 の全結果と、失敗のパターンを示しています。全体として、effort を上げるとエッジケースの見落としによる失敗（紫のブロック）は減る傾向がありますが、モデルのアプローチ自体が間違っている場合（青のブロック）は解決しません。
effort が特に効く問題領域
TerminalBench でこれらのモデルを評価して最も興味深かった点のひとつは、effort の恩恵を受けやすい領域とそうでない領域があったことです。内訳は次の図をご覧ください。
これを説明するため、Terminal Bench 3.0 の異なる領域から、Opus 5.5 が low effort では失敗し、high effort では成功した問題をいくつか選びました。主な理由は、high effort ではエッジケースのテストと考慮が行われたからです。
mvcc-lsm-compaction： クラッシュレポートをもとに、コンパクションを壊さずにストレージエンジンのバグを修正するよう求める Terminal-Bench 3.0 のタスクです。Opus 5.5 は low で 0/5 でしたが、xhigh では 4/5 になりました。
low（1 回の試行あたり約 1 分）では、ビルドや再現スクリプトの実行前にコードを編集してしまい、新しいテストで元のバグを検出できたかどうかの確認もしませんでした。
xhigh（約 11 分）では、まずクラッシュを再現し、コンパクションを一切行わない参照実装に対してランダム化テストを作成し、中途半端な修正ではテストが失敗することを確認していました。
cli-2ph-simple： Python で記述された CLI 線形計画法ソルバーを求める Terminal-Bench 3.0 のタスクです。Opus 5.5 は low で 0/5 でしたが、high では 5/5 になりました。
low の試行では、一発でソルバーを書き上げ、いくつかの小さな問題で確認しただけで 10k トークン前後で停止しました。最後のメッセージで、大きな問題では遅くなる可能性があると警告していましたが、実際に確認はしていませんでした。
high の試行では、別途用意したブルートフォースソルバーを基準にしてランダムな問題でテストを行い、さらに大きな問題で実行時間を計測しました。極端に時間がかかったりクラッシュしたりするケースにぶつかると、探索ロジックを作り直していました。
gsea-proteomics：プロテオミクスデータに対して遺伝子セットエンリッチメント解析（GSEA）を行い、8 つの治療法のうちどれがターゲット組織に類似しているかを特定する Terminal-Bench 3.0 のタスクです。Opus 5.5 は low で 0/5 でしたが、high では 4/5 になりました。
low effort では、妥当そうなデータ前処理方法をひとつ選んでそのまま解析を実行し、結果を報告するだけでした。
high では 2 種類の前処理方法を試し、有意な治療法のリストが変わることに気づき、正しい方を選ぶ前にその理由を掘り下げていました。
ユーザーがやり取りに参加していれば、問題の設定方法についてユーザーに質問したかもしれませんが、人間が介在しない場合は high effort の方が優れた結果を出します。
Claude Code で effort レベルを使い分けるタイミング
どの effort レベルをいつ使うかについての私の経験則は次の通りです。
- Low：ブレインストーミング、スケッチ作成、簡単な変更など、対話しながら素早い回答が欲しいとき。
- Medium：新機能の実装など、日常的なソフトウェア開発業務の大部分。
- High：検証が重要な作業やエッジケースが存在する作業（ブラウンフィールドのコードベースでのバグ修正など）。
- Max：アプリのエンドツーエンドでの構築と検証、重要ソフトウェアの脆弱性発見など、難しい問題を完全に自律して解決してほしいとき。
タスクに応じて、あるいは会話の途中でも、Claude Code の /effort コマンドを使って Opus 5.5 や Fable 5.1 の effort を切り替えてみてください。あなたの直感と一致するかどうか、ぜひ教えてください。
