Claude Code effortはいつ上げる？公式データと手元検証で分かった使い分けの基準

Claude Codeのeffortとは？——「どれだけ考えさせるか」のつまみ

effortとは、Claude Codeが1つのタスクにどれだけ計算（思考と検証）を使うかの目安を指定する設定です。レベルは low・medium・high・xhigh・max の5段階で、公式ドキュメントによれば2026年9月時点の既定値はOpus 5.5がmedium、Opus 4.7がxhigh、Fable 5.1を含むその他の対応モデルはhighです。

Thariq氏はeffortを「その仕事に1時間かけてほしいのか、12時間かけてほしいのかを伝えるようなもの」と説明しています。なお、Claude Code自体の基本は入門ガイドにまとめています。

重要なのは、effortが「賢さのつまみ」ではなく「自律性のつまみ」だという点です。Thariq氏はこう書いています。

「Claudeはどのeffortでもタスクを妥当にこなそうとしますが、effortを上げるほど、判断と検証のためにClaudeが自分で動く量が増えます。」

"Claude will always try and do your task reasonably, but higher effort will involve Claude taking more independent action for judgement and verification."

Thariq Shihipar（Anthropic・Claude Codeエンジニア）— Using Claude Code: Spending your effort

つまりhighやmaxでは、Claudeが「テストを追加で書く」「別の方法でも確認する」「疑わしい箇所を自分で掘る」といった行動を増やします。その分、時間とトークンがかかります。公式ドキュメントは、折りたたまれて見えない思考トークンも全額課金対象であることと、maxは「考えすぎ（overthinking）になりやすいので、広く採用する前にテストを」と明記しています。

effortを上げると何が変わるのか——Claude Codeチームの実測データ

結論から言うと、effortを上げて大きく伸びるのは「エッジケース（例外的な条件）が多い仕事」で、「仕様がはっきりしている仕事」はあまり伸びません。Thariq氏はTerminal-Bench 3.0（エージェントの実務能力を測るベンチマーク）をFable 5.1でeffort別に走らせ、領域ごとの合格率を公開しました。

個別のタスクではさらに極端で、Webのセキュリティフィルタを実装する課題（html-js-filter）はlowで5回中1回しか成功しなかったものが最上位effortでは5回中5回成功しました。ただし所要時間は約2分から約33分に伸びています。高effortのClaudeは、パーサーのソースを読み、XSSのテスト一式を書き、ランダムな入力で総当たり検証（ファジング）まで行っていた、というのがThariq氏の観察です。

コスト面では、タスクあたりのトークン中央値がlowの73kからmaxの222kへ、およそ3倍になっています。時間も「仕様が曖昧なアプリを作る」課題でlow 1.5分に対しmax 67分、「設定メニューを設計する」課題で1分に対し28分と、桁が変わる例が示されています。

なぜmaxを常用してはいけないのか——effortが直せる失敗、直せない失敗

maxを常用してはいけない理由は、effortが減らせる失敗の種類が限られているからです。Thariq氏は失敗をタイプ別に数え、effortを上げると減るものと減らないものを分けて示しました。これがこの記事でいちばん重要なデータです。

「effortを上げるとエッジケースの見落としによる失敗は減る傾向にありますが、モデルが間違ったアプローチを取っている場合は直りません。」

"increasing effort tends to reduce failures due to missing edgecases, but does not fix when the model has the wrong approach."

Thariq Shihipar（Anthropic・Claude Codeエンジニア）— Using Claude Code: Spending your effort

言い換えると、effortは「丁寧さ」を買う設定であって、「正しい方針」を買う設定ではありません。方針そのものが間違っているときに必要なのは、より長い思考ではなく、より良い指示——何を作るのか、何を優先するのか、どこまでが範囲なのか——です。Claudeが的外れな方向に進んでいると感じたら、effortを上げる前にプロンプトとCLAUDE.mdを見直すほうが効きます。

手元検証：請求明細チェックをlowとhighで比べた結果

「エッジケースが多い仕事ほどeffortが効く」という主張は、コードの世界だけの話でしょうか。当研究所で、士業やバックオフィスの日常業務に近い課題で確かめました。結果は、Thariq氏のデータをそのままなぞるものでした。

用意したのは14行の仕入請求明細（CSV）です。そこに、消費税の計算ミス、軽減税率の誤適用、免税事業者への課税、端数の切り上げ、重複行、期間外の日付、税込金額の転記ミスの7件を仕込み、社内ルール7項目とともに「誤りをすべて列挙して」と同じプロンプトで、claude -p --effort low と --effort high（モデルはFable 5.1）を実行しました。

lowが見落とした行2は、税率欄には「10%」と書いてあるのに税額が8%で計算されている行でした。ルールに照らせば明らかな誤りですが、「税率欄と税額欄の整合」という一段深い確認をしないと見つかりません。まさにThariq氏の言う「見落としたケース」です。一方でlowも、免税事業者への課税や期間外の日付といった「ルールに直接当たる」誤りは全部拾っていました。手順が明確な部分はlowでも十分で、例外の見落としを潰したいならhighにする——この使い分けが業務でも成り立つことが確認できました。

effortはどう設定する？——5つの方法と優先順位

設定方法は5つあり、いちばん手軽なのはセッション中に /effort と打つ方法です。公式ドキュメントの内容を、優先順位が高い順に整理します。

{
  "effortLevel": "high",
  "modelSettings": {
    "claude-opus-5-5": {
      "effortLevel": "medium"
    }
  }
}

作業の途中で切り替えることもできます。/effort はClaudeが動いている最中でも実行でき、次のリクエストから新しいレベルが適用されます。キャッシュ済みのセッションでは警告が出る場合がありますが、AnthropicはOpus 5.5の公式ブログで、セッション中のeffort変更でキャッシュをリセットしない改善を挙げています。また、設定を変えずに「このターンだけ深く考えてほしい」ときは、プロンプトに ultrathink という語を含めると、そのターンに限って深い推論を求められます（think や think hard では効きません）。

士業・バックオフィスでの使い分け——当研究所の判断表

当研究所の見解として、業務でのeffortは「見落としが致命的な仕事は上げ、手順が明確な仕事は下げる」の一文で決められます。Thariq氏のデータと手元検証を、事務所や部署の日常業務に翻訳すると次のようになります。

コストの目安も持っておきましょう。Thariq氏の計測ではlow→maxでトークンが約3倍、当研究所の検証ではlow→highでAPI換算約14%増（所要時間は約2.3倍）でした。ProやMaxなどの定額プランでは金額ではなく利用枠の消費として効いてくるので、「午前中に書類チェックをhighで回し、午後の定型作業はmediumに戻す」といった運用が現実的です。逆に、maxを既定にしたまま定型作業を大量に回すのは、公式ドキュメントが注意する「考えすぎ」でトークンと時間を浪費する典型例です。

最後にもう一度。effortを上げても直らない失敗があります。Claudeが的外れな結果を返すとき、まず疑うべきは effort ではなく指示の曖昧さです。CLAUDE.mdとskillsの使い分けで業務のルールを固めたうえで、検証が重要な場面だけeffortを上げる——これが、費用対効果のいちばん高い使い方だと当研究所は考えています。

まとめ