Claude Code effort 完全ガイド ― 全レベルの仕様と設定6方法

Claude Code effortが実際にコントロールしているもの――adaptive reasoning（適応的推論）の強度という設計

/effort は「どれだけ考えるか」を決める適応的推論（adaptive reasoning）の強度を設定するコマンドだ。モデルが各ステップで「思考するかどうか・どれだけ思考するか」をタスク難易度に応じて自ら判断する挙動シグナルであり、思考トークンの厳密な上限（budget）を指定するものではない。effortは応答全体のトークン傾向に影響し、そのスケールはモデルごとに調整されているため、同じレベル名でもモデルが異なれば実際の強度は異なる。

adaptive thinking は、問題の難易度をモデル自身が推定して思考トークンの消費量を動的に調整する仕組みだ。medium のような中間の強度でも、簡単なタスクでは少ない思考量で、複雑なタスクでは多めの思考量を自動的に使う。これが「思考トークンを固定値で指定する方式より優れている」理由の核心だ。固定上限の手動指定では、簡単なタスクにも過剰なトークンを割き続けるか、複雑なタスクで上限に当たって推論が途中で打ち切られるか、どちらかに陥る。adaptive thinkingはこの両方を避ける。

effort を上げることは、適応的推論の強度を引き上げる操作だ。最上位の max はトークン消費に制約を設けない最も深い推論を行うが、それでもすべてのタスクで最大思考量を強制するわけではない。ただし実際には effort が高いほど平均的な思考量は増大し、コストと待機時間も上昇する。

既定のeffortはモデルによって決まり、Fable 5・Sonnet 5・Opus 4.8・Sonnet 4.6 では high が既定となる（2026年4月時点ではOpus 4.7で xhigh が既定だった）（出典: Claude Code Docs — Model configuration）。モデルを切り替えると、そのモデルの既定effortが自動的に適用される場合がある。「モデルが劣化した」と感じたときは、まず現在のeffort設定（/effort の実行、またはロゴ横の「with … effort」表示）を確認することが診断の第一歩だ。

2026年4月のWeek 16アップデート（v2.1.105〜v2.1.113）でClaude Opus 4.7が登場し、highとmaxの間に位置する新レベルxhighが追加された。Opus 4.7に切り替えた際のデフォルトとして適用される（出典: Claude Code公式ドキュメント week 16）。また、引数なしで/effortと入力すると対話式スライダーが起動し、レベル名を覚えていなくても矢印キーで選択できるようになっている。

Claude Codeの基本的な使い方や導入手順については Claude Code入門ガイド および Claude Codeのインストール手順 を参照されたい。

low/medium/high/xhigh/maxで何が変わるか――5段階の実挙動比較

各レベルの特性を整理する。以下は公式ドキュメントとコミュニティの観測報告（出典: qiita.com/shohei_yamamoto、claude-world.com）を組み合わせた整理だ。

Claude Code effortレベル比較

effortレベル	推論強度の目安	応答速度	コスト感	主な用途
low	最小	最速	最低	整形・リネーム・定型コメント・大量バッチ
medium	標準	標準	標準	一般的なバグ修正・機能追加・ドキュメント生成
high（多くの現行モデルの既定）	高い	やや遅い	高め	設計レビュー・複雑なリファクタ・依存関係分析
xhigh（Opus 4.7で追加）	かなり高い	遅い	かなり高め	難解なアルゴリズム設計・再現困難なバグ調査
max	最大	最も遅い	最高	大規模アーキテクチャ変更・根本原因分析など一点集中タスク

「コスト感」について補足する。effortを上げるとthinking tokens（内部思考に消費されるトークン）が増大し、API経由で従量課金している場合は非線形にコストが上昇する。Anthropic APIの課金構造上、thinking tokensは出力トークンと同様にカウントされる。月次でどの程度の差になるかは利用頻度と選択するモデルに依存するため、Claude Code APIの料金体系で自分のユースケースに照らして確認してほしい。

モデルとeffortは独立したパラメータだが、組み合わせで挙動は大きく変わる。「Sonnet + high」対「Opus + medium」のどちらがコストと品質のバランスが良いかは、タスクの性質によって異なる。コマンド操作の詳細は Claude Codeのスラッシュコマンド一覧 に詳述している。

# レベルを直接指定
/effort low
/effort medium
/effort high
/effort xhigh
/effort max

# 引数なしで対話式スライダーを起動（Opus 4.7以降）
/effort

# デフォルト（auto）に戻す
/effort auto

effortをセッションをまたいで固定したい場合は、設定ファイルの effortLevel（low/medium/high/xhigh）、環境変数 CLAUDE_CODE_EFFORT_LEVEL、または起動時の --effort フラグを使う（max はセッション限定で effortLevel には設定できない）。優先順位は環境変数＞設定値＞モデル既定だ。なお CLAUDE.md は「もっと（少なく）考えて」といったソフトな指示は伝えられるが、effortレベルそのものを固定する手段ではない。max をCI/CDや大量バッチで常用すると想定外のコスト増を招くため、タスク性質に応じて明示的に切り替える設計が現実的だ。

タスク分類×effortレベルの判断マップ――AI対話システム開発の実例

仕様を理解した後に残る問いは「で、実際どのタスクに何を使えばいい？」だ。ここでは弊社（クリスタルメソッド株式会社）がバーチャルヒューマン・AIロープレ・AI面接システムを開発する中で蓄積した判断基準を、具体的なタスク分類として示す。

判断の基軸はシンプルだ。「この判断を間違えると後工程でコストがかかるか」という問いに対してYesならeffortを上げる。「試行錯誤の初期段階でスピードが優先か」という場面ではlowまたはmediumを選ぶ。

タスク分類×推奨effortレベル（AI対話システム開発の実例付き）

タスク分類	具体例（AI対話システム開発）	推奨effort	理由
定型コーディング・ボイラープレート生成	音声合成APIのリクエスト/レスポンス型定義、リップシンクデータのシリアライザ生成、アバター制御コンポーネントのスキャフォルド	low	パターンが決まっており推論深度は不要。生成速度が優先
コード整形・リネーム・軽微な修正	変数命名規則の統一、import文の整理、コメントの追加	low	ルールベースで機械的。medium以上は過剰
一般的なバグ修正・機能追加	音声認識の誤検出フィルタ修正、ターン検出ロジックの条件分岐追加	medium	adaptive thinkingが難易度を自動判定するため基本はこれで十分
対話フローの設計・状態管理ロジックのレビュー	マルチターン会話の状態遷移設計、ユーザー発話のインテント分類ロジックの妥当性確認	high	複数の状態と遷移条件を横断した多面的な推論が必要。mediumでは見落としが出やすい
複雑なリファクタリング・依存関係分析	モノリシックな対話エンジンのサービス分割、感情解析パイプラインのインタフェース再設計	high	影響範囲の追跡に深い推論が必要
感情解析パイプライン・アーキテクチャ検討	表情解析結果を対話タイムラインに統合する設計、リアルタイム性とバッチ処理のトレードオフ検討	xhigh / max	複数の技術的トレードオフを同時に検討する必要がある。コストを払う価値がある場面
大規模アーキテクチャ変更・根本原因分析	バーチャルヒューマンの接客・研修・面接練習の各ユースケースを横断するプラットフォーム設計の見直し	max	網羅的な影響分析に最大の推論量が必要な一点集中タスク

弊社が開発するDeepAI（バーチャルヒューマン・AIアバターソリューション）では、リップシンク・表情生成・音声合成・対話AIを組み合わせたシステムをClaude Codeで実装している。実装現場からいうと、ボイラープレート生成と型定義はlowで十分であり、生成速度の速さが体験として大きく効いてくる。対して対話状態管理のロジックレビューや感情解析パイプラインの設計判断にはhigh以上を使わないと、後から設計の穴が見つかるリスクが高い。

AIエージェント・AI対話システム開発でツール呼び出しを多用する場合は、ツールの実行ごとにトークンが消費される点も考慮が必要だ。effortをmaxにしたまま多数のツール呼び出しが発生するセッションを続けると、thinking tokensとツール呼び出しコストが重なってコストが急増する。長大なセッションでは定期的に/clearでコンテキストをリセットするか、タスク単位でセッションを分割する運用が現実的だ（Anthropic公式 “Claude Code Common workflows”）。

コスト意識のある運用パターン――既定を活かしつつ必要な場面だけレベルを調整する

実務上の基本は「モデルの既定を活かし、コストを抑えたい定型作業だけ下げ、難所だけ上げる」だ。現行モデルの既定は high で（2026年4月時点ではOpus 4.7が xhigh だった）、適応的推論が難易度を自動判定するため、多くの通常タスクは既定のままで過不足なく対応できる。

具体的な切り替えルールをセッション冒頭のタスク確認時に適用する習慣をつけると、品質とコストを両立しやすくなる。

• 基本はモデルの既定（多くの現行モデルでhigh）のまま。大半の通常コーディングはこれで対応できる
• 「この判断を間違えると後工程でコストがかかる」タスクに差し掛かったらhighに上げる。設計レビュー・複雑なリファクタリング・依存関係の影響分析がその典型だ
• xhigh/maxは一点集中のタスクに限定する。アーキテクチャ全体の見直しや根本原因が特定できていないバグの調査など、深い推論の恩恵が確実に大きい場面だけに使う
• 大量のファイルを横断するバッチ的な作業はlowに落とす。定型パターンの繰り返し作業では推論深度は品質に影響せず、速度とコストだけが変わる

月次のAPI使用量が気になる場合は、設定ファイルの effortLevel や環境変数 CLAUDE_CODE_EFFORT_LEVEL で既定レベルを明示し、チームの運用方針を CLAUDE.md に記述して共有する方法が有効だ。

# CLAUDE.md（チーム運用方針の記述例。effortの固定は effortLevel 設定／環境変数で行う）
## Agent behavior (guidance)
- Baseline: keep the model default (high on most current models)
- Use xhigh/max for: root cause analysis of critical bugs, full architecture redesign
- Drop to low for: large mechanical batch edits (formatting, renames)

よくある失敗パターン

パターン1：全部maxにして月末の請求で驚く。「品質が高いほど良い」という直感から常時maxを設定し、thinking tokensが積み上がって想定外のコストになるケース。定型コードの生成・整形・リネームでmaxを使っても品質は変わらない。コストだけが増える。

パターン2：lowにしすぎて設計品質が落ちる。コスト意識が高すぎて設計判断もlowやmediumで済ませ、後から設計の穴が見つかるケース。対話フロー設計や状態管理ロジックのレビューは推論深度が品質に直結するため、ここをケチると後工程の修正コストで相殺される。

「どのタスクが推論深度に敏感か」を把握していれば、この2つの失敗はどちらも防げる。前述のタスク分類表を判断の基準として使ってほしい。Claude Codeの料金プランの詳細については Claude Codeの料金プラン を参照されたい。

effortで解決できない問題と限界

effortを上げることで改善できるのは「推論の深さ」に起因する問題に限られる。以下のケースはeffort変更では解決しない。

• コンテキストウィンドウの不足：大量のファイルを同時に参照するタスクは、effortよりもコンテキスト管理（/clearやCLAUDE.mdによる絞り込み）が先決だ
• プロンプトの曖昧さ：指示が不明確な場合、effortをmaxにすると誤った方向への推論が深まるだけで精度は改善しない。前提条件・期待する出力形式・制約の3点を明示する習慣が先だ
• モデルの知識カットオフ：最新ライブラリのAPIに関する知識不足はeffortでは補えない。最新ドキュメントをfetchツール等でコンテキストに注入する必要がある
• ハルシネーション：推論量が増えると「もっともらしい誤答」として出力される可能性もある。effortを上げるほど誤答の確信度が高まるケースがあるため、出力の検証プロセスは別途必要だ
• ツール実行権限の不足：effortはモデルの推論深度の設定であり、ファイルアクセス・コマンド実行などのツール権限とは独立している

また、今後もバージョンアップに伴ってeffortの仕様は変わりうる。Opus 4.7でxhighが追加され、既定effortがモデルごとに設定されているように、使用バージョンのチェンジログと公式ドキュメントを定期的に確認する習慣が必要だ。Claude Codeのより広い文脈での活用については Claude Codeとは、ツール比較は Claude Code vs Cursorの比較 および Claude Code vs Codexの比較 も参考にしてほしい。

---

弊社DeepAIについて（利益相反の開示）

本記事は弊社（クリスタルメソッド株式会社）が運営するブログに掲載されている。弊社が開発するDeepAIは、実在の人物の容姿・表情・声・振る舞いをデジタル空間で再現するバーチャルヒューマン／AIアバターソリューションだ。リップシンク・表情生成・音声合成・対話AIを組み合わせ、接客・研修・面接練習・広報などの用途で活用される。ロープレ・面接練習機能では受講者の表情・感情・緊張度を発話タイムラインに沿って解析・可視化する機能を実装している。

本記事で示したClaude Code effortの使い分けは、DeepAIの実装過程で実際に直面した判断をもとにしている。特定製品の優劣を主張するものではなく、effort設定の判断基準として参考にしてほしい。DeepAIに関心がある場合は クリスタルメソッド株式会社のサイト を参照されたい。

参考文献

• Claude Code公式ドキュメント Week 16（April 13–17, 2026）— Opus 4.7とxhigh effort levelの追加: https://code.claude.com/docs/en/whats-new/2026-w16.md
• Claude Code Docs — Model configuration（effortレベル・既定・永続化の公式仕様）: https://code.claude.com/docs/en/model-config
• Claude CodeのEffort、実は4段階ある ― “max” の使い方と注意（Qiita / shohei_yamamoto）: https://qiita.com/shohei_yamamoto/items/f326f5c343a4a35e63bc
• Claude Codeくんのデフォルトeffort levelをmaxに固定する（Zenn / madebyjun）: https://zenn.dev/madebyjun/articles/8f7d6bb9286b95
• Claude Code 2026年4月アップデートまとめ（fixit.co.jp）: https://fixit.co.jp/tips/claude-code-2026-04-recap/
• Claude Code effort 設定でコスパ設計（python-engineer.co.jp、2026年5月26日）: https://python-engineer.co.jp