「Opus は高い、Sonnet は物足りない」をやめる ─ effort という第3のツマミ

SHARE

TL;DR

  • effort は「どれだけ考えるか」を制御するパラメータ。モデルが単価の段差なら、effort は消費量のつまみ
  • Opus 4.7: low/medium/high/xhigh/max の5段階（デフォルト xhigh）
  • Opus 4.6 / Sonnet 4.6: low/medium/high/max の4段階（デフォルト high）
  • コスパの有力候補は「Sonnet + max」または「Opus + medium」。目的別の象限で選ぶ
  • 設定の優先順位は 環境変数 CLAUDE_CODE_EFFORT_LEVEL → settings.json の effortLevel → モデルデフォルト
  • Max + Sonnet では auto mode が使えない。Proactive 出力スタイル・許可ルール・PreToolUse フック・Sandbox の4つを組み合わせて代替できる

目次

「高いか物足りないか」という二択から抜け出す

「Opus を使うと月末にトークンが尽きる。でも Sonnet では複雑なリファクタリングが中途半端に終わる」──このジレンマで消耗した経験があるなら、Claude Code のコスパ設計に3本目の軸が加わったことを知っておくと状況が変わります。

  • モデル: 単価の段差（Sonnet < Opus）
  • effort: 消費量のつまみ（low < medium < high < xhigh < max）

Anthropic は 2025年11月の Opus 4.5 発表で2つの変化を加えました（公式発表）。

  1. Opus 専用の利用上限を撤廃。Claude と Claude Code のユーザーが同じ Opus にアクセスできるようになった
  2. 入力 $5/M・出力 $25/M への大幅値下げ。従来比で Opus を「買いにくい」価格ではなくなった

さらに同発表によれば、Opus 4.5 を medium effort で動かすと Sonnet 4.5 と同等の性能を示しながら出力トークンが 76% 削減、max effort でも Sonnet 4.5 比 +4.3pp・48% 削減という数字が出ています。

「Opus は使えない」という前提自体が変わった今、effort の扱いを知っているかどうかでコスパが大きく変わります。

effort とは何か ─「どれだけ考えるか」のノブ

effort は Claude Code が「適応的推論（adaptive reasoning）」にどれだけリソースを割くかを制御するパラメータです（公式 model-config）。

  • 低 effort: 単純なタスクには速答し、複雑と判断した場合に少しだけ推論する
  • 高 effort: 毎ステップで積極的に推論する。難しいタスクほど効果が出る

Opus 4.7 は常に適応的推論を使います。Opus 4.6 と Sonnet 4.6 では、環境変数 CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1 を設定すると旧来の固定思考予算の動作に戻せます。

各モデルで使えるレベルと用途は次のとおりです。

レベルOpus 4.7Opus 4.6 / Sonnet 4.6使いどころ
low○○短い・スコープ限定・速度優先
medium○○コスト重視。知性をある程度犠牲にできる
high○○（デフォルト）バランス。知性が必要な作業の最低ライン
xhigh○（デフォルト）×（high にフォールバック）ほとんどのコーディング・エージェントタスク
max○○難しいタスクの一段上の推論。セッション限定

max はセッションの中でだけ有効で、settings.json の effortLevel には書けません（書いても無視されます）。xhigh は Opus 4.7 専用のレベルで、Opus 4.6・Sonnet 4.6 で指定すると high に自動的に落ちます。

次の象限図はモデルと effort の組み合わせがコストと能力にどう対応するかを概念的に示したものです。

quadrantChart title "Model x Effort: Cost vs Capability" x-axis "低コスト" --> "高コスト" y-axis "低能力" --> "高能力" quadrant-1 "高能力・高コスト" quadrant-2 "高能力・低コスト" quadrant-3 "低能力・低コスト" quadrant-4 "低能力・高コスト" Opus-xhigh: [0.85, 0.90] Opus-high: [0.70, 0.80] Opus-medium: [0.55, 0.70] Sonnet-max: [0.50, 0.75] Sonnet-high: [0.35, 0.60] Sonnet-medium: [0.25, 0.50] Sonnet-low: [0.15, 0.35] Opus-low: [0.45, 0.55]

「Sonnet + max」が第2象限（高能力・低コスト）に位置するのは、Sonnet の単価の安さと max effort の推論量を組み合わせた場合の特性を表しています。あくまで概念的なマッピングなので、実際の結果はタスクの性質で変わります。

2本のツマミで象限を選ぶ

モデルの選び方

日常のコーディング補助なら Sonnet 4.6 で十分なケースが多いです。複雑な設計判断・大規模リファクタリング・多段階のアーキテクチャ検討には Opus 4.7 が力を発揮します。

opusplan は設定不要のビルトインモデルエイリアスです。次のように呼ぶだけで使えます（公式 model-config）。

/model opusplan # セッション中に切り替え
claude --model opusplan # 起動時から指定

動作は Plan Mode の有無で変わります。

状況使われるモデル
通常の会話・実装（Plan Mode 外）Sonnet
/plan コマンドで入る Plan Mode の計画フェーズOpus
計画承認後の実装フェーズ自動で Sonnet に切り替え

/model opusplan を設定してそのまま普通にコードを書く場合は Sonnet が動きます。Opus を計画に使いたいときは、別途 /plan で Plan Mode に入る必要があります（Classmethod 検証記事）。Plan Mode 内では /model を手動で切り替えなくても Opus → Sonnet の切り替えが自動で行われます。なお opusplan の Opus フェーズは 200K コンテキスト固定で、opus エイリアスで使える 1M 自動拡張の対象外です。

effort の使い方

同じモデルで effort を下げると何が起きるか、実務的な判断基準を整理します。

  • 単純タスク（テスト追加・変数名変更・コメント修正）: medium や low に下げても品質はほぼ維持されます
  • 複雑タスク（アーキテクチャ変更・バグの根本原因調査・パフォーマンス最適化）: high 以下にすると品質が下がるリスクがあります。下げるなら動作確認をセットで

次のフローで自分のタスクがどの象限に入るか確認してみてください。

flowchart TD S([タスク開始]) --> Q1{知性が必要か？<br/>複雑な推論・設計判断} Q1 -- Yes --> Q2{コストを抑えたいか？} Q2 -- Yes --> A1[Opus + medium<br/>または Sonnet + max] Q2 -- No --> A2[Opus + xhigh がデフォルト<br/>一段上なら Opus + max] Q1 -- No: 単純・反復 --> Q3{速度重視か？} Q3 -- Yes --> A3[Sonnet + low<br/>または Haiku] Q3 -- No --> A4[Sonnet + medium で十分]

Claude Code での effort 設定

effort を変える方法は複数あります。優先順位は次のとおりです（上が強い）。

  1. 環境変数（最優先）

export CLAUDE_CODE_EFFORT_LEVEL=xhigh

すべての設定を上書きします。auto を指定するとモデルデフォルトに戻ります。CI や特定プロジェクトで固定したいときに使います。

  1. settings.json の effortLevel

// ~/.claude/settings.json（ユーザースコープのデフォルト）
{ "model": "sonnet", "effortLevel": "high"
}

設定ファイルの階層については処方箋 #09「settings の読み込み階層」を参照してください。max はここには書けないので注意です。

  1. セッション起動時のフラグ

claude --model opus --effort xhigh

そのセッションの間だけ有効です。

  1. セッション中の /effort コマンド

/effort medium # 直接指定
/effort # 引数なしで矢印キーのスライダーが開く
/effort auto # モデルデフォルトにリセット

  1. スキル・サブエージェントの frontmatter

スキルの実行中だけ effort を上書きしたい場合は SKILL.md の先頭に YAML ヘッダ（前後を --- で囲む部分）を書きます。

name: heavy-analysis
description: 複雑なアーキテクチャを深く分析するスキル
model: opus
effort: max

この YAML ヘッダをスキル本文の前に配置すると、そのスキルが呼ばれている間だけ effort: max が適用されます。

ultrathink キーワード

effort のレベルを変えずに1ターンだけ深い推論を要求したいときは、プロンプトに ultrathink を含めます。

このアーキテクチャ図の問題点を ultrathink で洗い出してください

セッションの effort 設定自体は変わらないので、次のターンでは元のレベルに戻ります。「念のためもう一度深く考えてほしい」という場面に使いやすいです。

auto mode と Max × Sonnet の壁

auto mode の要件

auto mode（Claude が実行前に許可判定を自律的に行うモード）の利用条件は公式 permission-modes で確認できます。

プラン使えるモデル
MaxOpus 4.7 のみ
Team / Enterprise / APISonnet 4.6・Opus 4.6・Opus 4.7
Pro不可

Max プランで /model sonnet に切り替えると、ステータスバーから auto mode が消えます。これは仕様です。Max × Sonnet では auto mode は動きません。

なぜ Max × Sonnet で Sonnet を使いたくなるか

  • Opus 4.7 の消費が多い日にコストを抑えたい
  • 特定のタスクでは Sonnet の方が速くてコスパが良い
  • でも自律実行の感覚も失いたくない

このニーズには、auto mode の代替を組み合わせて対応します。

代替① Proactive 出力スタイル

出力スタイルを Proactive に切り替えると、Claude が「即実行・合理的な仮定で進む・確認より行動優先」に変わります。設定方法は2通りです。

# /config を開いて Output style → Proactive を選ぶ
/config
// .claude/settings.local.json に直接書く
{ "outputStyle": "Proactive"
}

公式 output-styles には「auto mode よりも強い自律実行のガイダンス」と書かれています。許可プロンプト自体は残る点が auto mode との違いです。出力スタイルはシステムプロンプトの一部としてセッション開始時に1度だけ読み込まれるため、変更を反映するには /clear か新しいセッションが必要です。

単独コマンドの /output-style Proactive は v2.1.73 で非推奨化、v2.1.91 で削除されました。現在は /config か outputStyle 設定で切り替えます。

代替② 許可ルールで無確認範囲を広げる

// .claude/settings.json
{ "permissions": { "allow": [ "Bash(npm test)", "Bash(git status)", "Bash(git diff*)", "Bash(git add*)" ] }
}

リストに登録したコマンドはどのモードでも確認なしで実行されます。acceptEdits モード（ファイル編集を自動承認するモード）と組み合わせると「ファイル編集 + 許可済みコマンド実行」がどちらも無確認になります。

代替③ PreToolUse フックで「判定器」を自作

auto mode の本質は「ツール実行前に許可判定を挟む」ことです。PreToolUse フックでこれを自作できます（フックの基本構文は処方箋 #11「Hooks 入門」を参照）。

フックは標準入力から JSON を受け取り、permissionDecision（allow / deny / ask のいずれか）を返します。

#!/bin/bash
# .claude/hooks/pre-tool-guard.sh
# 危険な Bash コマンドをブロックする例
INPUT=$(cat)
COMMAND=$(echo "$INPUT" | jq -r '.tool_input.command // ""')
# 大量削除・強制プッシュ・DROP TABLE をブロック
if echo "$COMMAND" | grep -qE 'rm\s+-rf\s+[/~]|git push.*--force|DROP TABLE'; then echo '{"decision":"deny","reason":"危険な操作はブロックしました"}' ; exit 0
fi
# その他は許可
echo '{"decision":"allow"}' ; exit 0
// settings.json への登録
{ "hooks": { "PreToolUse": [{ "matcher": "Bash", "hooks": [{ "type": "command", "command": "bash .claude/hooks/pre-tool-guard.sh" }] }] }
}

permissionDecision（allow / deny / ask）を返す JSON が、フックから auto mode の判定器を模倣する仕組みです。

代替④ Sandbox で安全度を上げる

/sandbox # 有効化・無効化の切り替え

Sandbox はファイルシステムとネットワークを隔離します（macOS: Seatbelt / Linux: bubblewrap + socat）。許可ルールを広めに設定しても実害を限定できるので、自走範囲を広げるときのリスク低減に有効です（公式 sandboxing）。

4つの代替手段を整理します。

flowchart TD Q([Max + Sonnet で自走させたい]) --> A1 Q --> A2 Q --> A3 Q --> A4 A1[代替① Proactive 出力スタイル<br/>許可プロンプトは残る] A2[代替② 許可ルール<br/>事前承認リストで無確認範囲を広げる] A3[代替③ PreToolUse フック<br/>DIY 判定器] A4[代替④ Sandbox<br/>隔離でリスクを限定] A1 & A2 & A3 & A4 --> GOAL[auto mode に近い自走体験]

自分のコスパ設定を決める3つの質問

質問1: 今のタスクに深い推論が必要か

「はい」→ effort を high 以上に固定する（xhigh がほとんどの場面で正解）
「いいえ」→ medium か low で速度・コスト優先

質問2: 予算が気になるか

「はい」→ まず Sonnet + high を試す。次の候補は Opus + medium
「いいえ」→ Opus + xhigh（デフォルト）のまま使う。手を加えなくてもベスト設定で動いています

質問3: 許可プロンプトを減らして自走させたいか

Max + Opus 4.7 → auto mode を有効化
Max + Sonnet → 代替①〜④を組み合わせ
Pro → acceptEdits + 許可ルール + Proactive スタイルで近づける

今週やる 1 つ

現在の設定を確認し、Sonnet + high で1日動かしてみてください。

# 現在の設定を確認
/model
/effort
# Sonnet + high で新しいセッションを開く
claude --model sonnet --effort high
# トークン消費の変化を確認（Claude Code v2.1.105 以降）
/usage

「物足りなかった」と感じたタスクがあればメモしておき、そのタスクだけ max に上げる運用が次のステップです。

まとめ

  • モデル（単価の段差）と effort（消費量）の2本のツマミで、コスパは細かく調整できます
  • Opus 4.7 のデフォルトは xhigh。手を加えなくてもベスト設定で動いています
  • コストを抑えたいなら「Sonnet + high」または「Opus + medium」が最初の候補
  • max はセッション限定で、設定ファイルへの書き込み不可。1ターンだけ試したいなら ultrathink キーワードが手軽です
  • Max + Sonnet では auto mode が使えません。Proactive スタイル・許可ルール・PreToolUse フック・Sandbox の組み合わせで近づけられます

TL;DR（再掲）

effort はモデルの「どれだけ考えるか」をコントロールするパラメータです。「Opus か Sonnet か」の二択でなく、モデルと effort の2本のツマミで設定を微調整する── これが今の Claude Code でコスパを最大化する考え方です。

前の記事

1 回で終わらないタスクを「完了まで」自走させる ─ Clau…

次の記事

OSS ワークフロー 12 種の選び方 ─ Superpowe…