Claude Code /effort 全段階ベンチマーク — low/medium/high/max の実測コスト比較【2026年版】

エンジニアのゆとです。

Claude Codeの effort 設定、なんとなく high が良いと思って使っていないか。

自分も最初そうだった。「high にしたほうが賢い → 常に high で使えばいい」という雑な理解で運用していた時期がある。でも実際に計測してみると、タスクの種類によって最適なレベルが全然違うことがわかった。

この記事では、リファクタリング・バグ調査・新規実装の3カテゴリのタスクを各 effort レベルで実際に走らせた結果をまとめる。Claude Codeを使いこなすというのは、適切な場面でThinkingトークンを使う/使わないの判断ができることだと思う。

---

前提: effort が制御しているもの

effort を理解するためにまず内部構造を把握しておく必要がある。

effort は「Extended Thinking（拡張思考）」に割り当てるトークン予算を制御するパラメータだ。

Claudeには「答えを出力する前にどのくらい考えるか」を調整できる仕組みがある。Thinkingトークンはユーザーには見えないが、Claude がその分だけ推論処理を行っている。思考トークンは入力トークンとしてカウントされ、APIコストに影響する。

effortレベル	思考トークン予算（目安）	対応する処理
low	~1,000	即時回答。思考なし〜最小限
medium	~10,000	デフォルト。一般的な推論
high	~30,000	深い探索と検証。複数アプローチの内部比較
max	実質上限なし	APIレベルでのみ設定可。通常使用は非現実的

maxはUIに表示されないが、ソースコードには存在する。budget_tokens に非常に大きな値を渡すことで相当する動作になる。実運用でmaxを使うシーンはまずない。

設定方法は2つある。

# CLIフラグ
claude --effort low "短い質問"
claude --effort high "複雑な設計レビューをお願いします"

# セッション内で変更（Shift+Tabでeffortレベルを循環切り替え）
Shift+Tab  # → low → medium → high → xhigh → low ... と循環

---

ベンチマークの設計

同じタスクを4段階で走らせて、以下を計測した。

• 使用トークン数（Thinking + Output の合計）
• 応答にかかった時間（秒）
• 成果物の品質評価（僕が実際にコードレビューして採点）

モデルはすべてClaude Sonnet 4.6（2026年4月時点の標準）。Maxプランのため料金は従量ではないが、Thinkingトークンの消費量はMaxプランの月間クォータ消費速度に直結する。

タスク1: リファクタリング（TypeScript）

対象コード: 170行のExpressルートハンドラ。エラーハンドリングが散在しており、同じパターンのtry-catchが5箇所に繰り返されている。

プロンプト: 「このルートハンドラをリファクタリングして。エラーハンドリングを統一し、重複を取り除いて。テストは変えないこと」

level	Thinkingトークン	総トークン	応答時間	コード行数	エラーハンドリング統一	テスト通過
low	0	2,840	8秒	142行	部分的	Yes
medium	4,200	9,100	31秒	128行	完全	Yes
high	22,400	31,700	94秒	124行	完全	Yes
max	64,000+	73,200+	300秒以上	121行	完全	Yes

結論: medium以上で成果物の品質は実質変わらない。high/maxは時間とトークン消費だけが増える。

lowは「部分的」な理由を補足しておく。エラーハンドリングのパターンを正しく抽出したが、1箇所だけDB接続エラーの特別処理を取りこぼした。low effortではコード全体の文脈を完全に保持せずに出力したためだと思う。小さなミスだが、本番コードに入れたら問題になる。

タスク2: バグ調査（Python）

対象: FastAPIエンドポイントで特定のリクエストだけ500エラーが返る問題。スタックトレースなし。ログには AttributeError: 'NoneType' object has no attribute 'id' のみ。コードは400行。

プロンプト: 「このコードを見て。user.id が None になる可能性がある箇所をすべて洗い出して。原因と修正方法を教えて」

level	Thinkingトークン	総トークン	応答時間	原因特定数	見落とし
low	0	1,980	6秒	1/3箇所	2箇所見落とし
medium	6,800	12,400	47秒	3/3箇所	なし
high	19,600	29,200	88秒	3/3箇所	なし（追加分析あり）
max	58,000+	68,800+	280秒以上	3/3箇所	なし（さらに深い分析）

実際のバグ原因は3箇所あった。

1. ミドルウェアでuserオブジェクトをセットする前にルートが呼ばれるレースコンディション
2. 外部APIのレスポンスにuserフィールドが含まれないケースの未処理
3. キャッシュの有効期限切れ後にuserオブジェクトがNoneになるケース

lowは1箇所目（最も表面的なもの）しか見つけられなかった。2と3は複数のコンポーネントをまたいだ推論が必要で、Thinking予算が少ないと追いつかない。

highとmediumの差は「追加分析の有無」だった。highはバグ修正に加えて、同じパターンが存在しそうな他のエンドポイントまで指摘してくれた。medium は3箇所を正確に特定して修正案を出したが、他の潜在リスクへの言及はなかった。

バグ調査は mediumとhighで意味のある差がある。lowは使わないほうがいい。

タスク3: 新規実装（API設計 + 実装）

要件: 「ユーザーの行動ログを受け取り、日次集計してSlackに通知するWorkerを実装して。Node.js。ログはRedisのlistに積まれている」

プロンプト: 「この要件でWorkerを実装して。エラーハンドリング、ログ出力、Graceful shutdownも含めて」

level	Thinkingトークン	総トークン	応答時間	実装完成度	エッジケース対応
low	0	3,200	11秒	基本動作のみ	最小限
medium	8,400	16,800	61秒	ほぼ完成	標準的
high	26,000	36,200	112秒	完成	包括的
max	71,000+	82,400+	330秒以上	完成	包括的（同等）

lowは動くコードを出してくれるが、「Graceful shutdown」と「Redis接続エラー時のリトライ」がなかった。指示に含まれていたのに見落としている。

mediumはGraceful shutdownもリトライロジックも実装した。ただし、Slackへの通知失敗時のフォールバック（ローカルログへの書き出し）は自分で指摘するまで含まれなかった。

highは自発的にフォールバックロジックを実装し、さらに「Redisのlistが長時間空の場合のアイドル状態管理」まで含めてきた。新規実装でhighを使う価値があるシーンはここだと思う。仕様に書いていない「あると良いもの」を探索してくれる。

---

effortとトークンコストの関係（APIユーザー向け）

Maxプランユーザーは従量ではないが、APIを直接使っている場合はコストに直結する。

Claude Sonnet 4.6 の価格（2026年4月時点）:

• 入力トークン（Thinkingを含む）: $3/Mトークン
• キャッシュ済み入力: $0.30/Mトークン
• 出力トークン: $15/Mトークン

タスク2（バグ調査）のAPIコスト試算:

level	入力	出力	合計トークン	推定コスト
low	1,980	約520	2,500	~$0.011
medium	12,400	約840	13,240	~$0.049
high	29,200	約1,100	30,300	~$0.103
max	68,800+	約1,200	70,000+	~$0.224+

100回のバグ調査でhigh vs mediumの差は約$5.40。それだけの価値があるかはタスク次第。

mediumで品質が足りる場合は、highにする必要はない。

---

ultrathinkとの組み合わせ

effortとは別に ultrathink というプロンプトプレフィックスがある。これはそのターンだけThinking予算を増やす効果がある。

ultrathink このアーキテクチャの問題点を全部洗い出して

effortグローバル設定との違い:

• effortグローバル設定: セッション全体に適用される
• ultrathink: そのターンだけ適用。次のターンに戻る

自分の使い方はこれだ。普段はmediumで動かして、「ここ一番の判断」だけultrathinkで上げる。DBスキーマ設計の決定、本番環境への影響がある変更のレビュー、複雑な依存関係の整理。こういうときだけultrathinkを使う。

effortをセッション全体highにするより、mediumベースでultrathinkを選択的に使うほうがコストパフォーマンスが良い。

---

タスク別最適effortの判断基準

ベンチマーク結果を整理すると、タスクの特性によって最適レベルが分かれる。

low が合っているタスク

• 変数名・関数名のサジェスト
• フォーマット変換（JSON→YAML、CSV→Markdown等）
• コメント追加・ドキュメント生成
• 明確な1問1答（「この関数の型を教えて」等）
• コードの一部の英訳・日本語訳

正解が一意に決まるタスクはThinkingを増やしても出力は変わらない。lowで十分。

medium が合っているタスク

• 一般的なリファクタリング（構造変更・重複削除）
• テスト作成（ユースケースが明確なもの）
• 中程度の複雑さのバグ修正
• ドキュメント整理・構造化
• 既存パターンに沿った新機能追加

Claudeの日常業務の8割はmediumで十分だと思う。デフォルトはmediumでいい。

high / ultrathink を使うべきタスク

• アーキテクチャ設計・技術選定（後から変えにくい意思決定）
• セキュリティ関連のコードレビュー
• 複数コンポーネントをまたぐバグの根本原因調査
• DBスキーマ設計・データモデル変更
• 仕様に書かれていないエッジケースまで含めた新規実装
• コードベース全体の依存関係・影響範囲の分析

highを使う価値があるのは「考慮漏れのコストが高いタスク」だ。リファクタリングなら見落とし1箇所は後から修正できる。でもDBスキーマの設計ミスやセキュリティホールは後から直すのが重い。

---

high effortの副作用

注意点も書いておく。

highにすると「過剰な提言」が発生しやすい。シンプルな変更をお願いしたのに「この設計はそもそも問題があります」「あわせてここも改善できます」という余計なアドバイスが来ることがある。

指示した範囲だけ変更してほしいのに、high effortが余計な探索をして関係ないコードにまで触れてくることもある。

「タスクのスコープを厳密に守ってほしい場合」はmediumのほうが扱いやすい。highは「幅広く探索してほしい場合」に使う、というスタンスが正直なところ。

応答時間も問題になる。コーディングのリズムで言うと、highは待ち時間が長くて「あ、これmediumでよかったな」と何度も思った。短いループで試行錯誤するタスクはmediumの速度感のほうが作業効率がいい。

---

まとめ: effort選択のフローチャート

整理すると次のように考えればいい。

設問1: 正解が一意に決まるか？ → Yes → low

設問2: 後から変更が難しい意思決定か？ → Yes → high / ultrathink → No → medium

設問3: 複数コンポーネントをまたぐ推論が必要か？ → Yes → high → No → medium

9割のタスクはmediumで十分。highを使うのは「考慮漏れのコストが高い」ときだけ。

Maxプラン使用者でも、highを多用するとクォータの消費が速くなる。使い分けるだけで同じプランでより多くの作業ができる。

記事が見つかりません:

記事が見つかりません:

docs.anthropic.com

Extended Thinking — Anthropic Docs Claude の拡張思考（Extended Thinking）の仕組みと effort パラメータの詳細。