Claude Codeのeffort設定を全段階検証 — low/medium/high/maxとultrathinkの使い分け
Claude Codeのeffort設定（low/medium/high/max）を実際に検証。コード品質・処理時間・トークンコストの変化、ultrathinkとの関係、Opus/Sonnetでの挙動の差、実務での最適な使い分けを詳しく解説。
エンジニアのゆとです。
Claude Codeに effort という設定があるのを知っている人は多い。でも「highにすると賢くなる」くらいの認識で、具体的に何がどう変わるかまで把握している人は少ないんじゃないかと思う。
自分が実際に同じタスクを各段階で走らせて確認した結果をまとめる。Qiitaに「effortに実は4段階ある」という記事があって、それで初めてmaxの存在を知ったくらいには、公式ドキュメントの情報は断片的だ。
effortとは何か
effortはClaude Code（およびClaude API）の「思考の深さ」を制御するパラメータだ。
内部的には「Extended Thinking（拡張思考）」のトークン予算を調整している。low/medium/highで段階的にThinkingに使えるトークン量が変わり、それが応答の品質・速度・コストに直接影響する。
2026年3月時点でのeffortレベル：
| レベル | 説明 |
|---|---|
| low | 思考トークン最小。高速・低コスト |
| medium | デフォルト設定（Sonnet 4.6のデフォルト） |
| high | 深い思考。Opus 4.6の旧デフォルト |
| max | APIレベルでのみ実質的に制御可能。UI非表示 |
重要な変更点として、2026年3月のアップデートでOpus 4.6のデフォルトがhighからmediumに変更された。コスト面での配慮だと思う。
設定方法
Claude Code内では /model コマンドからeffortを変更できる。
/model表示されるモデル選択画面でeffortスライダーが出てくる。Sonnet 4.6でもOpus 4.6でも設定可能になった（以前はOpus専用だった）。
CLIからの指定：
claude --effort low "簡単な質問"
claude --effort high "複雑な設計レビューをお願いします"APIから直接指定する場合：
response = client.messages.create(
model="claude-opus-4-6-20260301",
thinking={"type": "enabled", "budget_tokens": 16000}, # high相当
max_tokens=4000,
messages=[...]
)実際に検証してみた
同じタスクを low / medium / high で実行してどう変わるか試した。
テスト1: バグ検出
約200行のTypeScriptコードに意図的にバグを5箇所仕込んで、各effortレベルで検出させた。
結果：
| effort | 検出バグ数 | 応答時間 | 出力トークン数 |
|---|---|---|---|
| low | 2/5 | 約4秒 | 〜800 |
| medium | 3/5 | 約9秒 | 〜1,500 |
| high | 5/5 | 約24秒 | 〜4,200 |
highが唯一全部見つけた。lowとmediumが見逃した2箇所は、関数の副作用による間接的なバグで「読み込んで一見正しそうに見える」タイプだった。
出力量がhighで約17倍というのはZennの記事でも同様の数字が出ていて、おそらく傾向として正しい。
テスト2: アーキテクチャ設計レビュー
Expressアプリのディレクトリ構造を見せて「問題点と改善案を指摘して」というプロンプト。
- low: 「ルーターとコントローラーが混在している」程度の浅い指摘
- medium: サービス層の欠如、エラーハンドリングの一元化不足まで指摘
- high: 上記に加えて「テストが書きにくい構造になっているのでDI（依存性注入）を検討すべき」「認証ミドルウェアの配置が適切でなくセキュリティリスク」など設計の奥まで踏み込んだ
同じコードベースを見せているのに、lowとhighでは「見えている解像度」が明らかに違う。
テスト3: 簡単な質問
「このTypeScriptの型エラーを直して」という明確な1問。
どのeffortレベルでも答えは同じだった。正解が一意に決まる問題では、思考トークンを増やしても出力は変わらない。lowで十分、むしろlowが速くて正解。
ultrathinkとの関係
2026年3月にv2.1.68でultrathinkが復活した。
ultrathinkはプロンプトに含める「魔法の言葉」で、そのターンだけeffortをhighに引き上げる効果がある。
ultrathink このアーキテクチャの問題点を全部洗い出してeffortのグローバル設定とultrathinkの違い：
- effortグローバル設定: セッション全体に適用
- ultrathink: そのターンだけ
自分の使い方は「普段はmediumで、ここ一番の判断のときだけultrathinkを使う」。毎回highにすると応答時間と（APIの場合は）コストが重くなるので、必要なときだけ上げる運用が合っている。
ちなみにultrathinkを消した理由は不明だが、コミュニティの反発でv2.1.68で復活した。それだけ「ここ一番でブーストしたい」というニーズが強いということだと思う。
maxレベルについて
公式UIには表示されないが、API的には「max」というレベルが存在する。
Qiitaの調査記事によると、maxはソースコード内に存在し、budget_tokensに非常に大きな値を設定することで相当するらしい。ただ実運用で使う機会はほぼない——コストと時間が跳ね上がる。
あえて使うとしたら「クリティカルなセキュリティ審査」「一回だけの重要な設計決定」くらいだと思う。
コストへの影響
APIの従量課金を使っている場合、effortによるコスト変化は無視できない。
Thinking（拡張思考）のトークンは入力トークンとして計上される。highでは数千〜数万のThinkingトークンが追加される。
Claude 3.5/3.7系の場合、Thinkingトークンは通常の入力と同じ $3/Mトークン（キャッシュなし）。100回のhigh effortリクエストで、mediumと比べると数ドル〜十数ドルの差が出ることもある。
Maxプランを使っている場合でも、high effortは「月の使用量」の消費速度が速くなる体感がある。
実務での使い分けガイド
具体的なシチュエーション別：
high / ultrathink を使うべき場面：
- アーキテクチャ設計のレビュー・決定
- セキュリティに関わるコードのレビュー
- 複雑なバグの原因調査
- DBスキーマ設計（後から変えにくいもの）
- 未知の技術スタックへの移行計画
medium（デフォルト）でいい場面：
- 普段のコード生成・補完
- テスト作成
- ドキュメント生成
- リファクタリング（明確な指示がある場合）
low でいい場面：
- 明確な1問1答
- フォーマット変換（JSON→CSV等）
- 変数名の提案
- コメント追加
effort高い = 常に良い、ではない
やってみて気づいたことを正直に書く。
high effortで「賢くなりすぎて余計なことを言う」ケースがある。明確な指示に対してhighで走らせると、指示通りに実行する代わりに「この設計はそもそも問題があります」という余計な提言が来ることがある。
シンプルなタスクにはシンプルなeffortが合っている。
あと、highは応答が遅い。数十秒待つのが毎回のことになると、体験として重くなる。コーディングのリズムが崩れる。自分は「考えさせたい問題」のときだけ意図的にhighを使うようにして、日常の補助タスクはmediumに戻すようにした。
まとめ
- effortはlow/medium/high/maxの4段階。UIから操作できるのは最初の3つ
- Thinking（拡張思考）のトークン予算を調整している
- 複雑な推論・設計判断にはhigh。シンプルな補助タスクにはlow/medium
- ultrathinkでターン単位のブーストが可能
- APIコストを使っている場合はhigh多用に注意
- 「high = 常によい」ではなく、タスクの複雑さに合わせて使い分ける
記事が見つかりません:
記事が見つかりません:
