メインコンテンツへスキップ
← ブログに戻る
チュートリアル2026年5月30日by K.hirano

Claude Code の /effort 完全ガイド|low〜maxの使い分けと『コストが増える本当の理由』

Claude Code の /effort(low〜max・ultracode・auto)は「賢さ」ではなく「トークンの気前よさ」のレバー。モデル別の推奨スタートと、Opus 4.8 でコストが増えた気がする原因を『トークナイザ』と『effort』の2軸に切り分ける考え方を、公式一次情報と v2.1.156 の実機確認で解説します。

#Claude#ClaudeCode#Anthropic#LLM#AIエージェント

この記事は「Claude Opus 4.8 は何が変わった?ベンチより「正直さ」と並列エージェントが本命だったBlogClaude Opus 4.8 は何が変わった?ベンチより「正直さ」と並列エージェントが本命だったClaude Opus 4.8 で本当に変わったのは、ベンチの数ポイントではなく『正直さ』と並列サブエージェントでした。公式ベンチ、4つの新機能、OpenRouter の実トラフィックを重ねて、価格据え置きの今回のアップデートを乗り換え目線で整理します。」で触れた effort 制御を、独立した1テーマとして掘り下げる実用ガイドです。Opus 4.8 の全体像から押さえたい方は、先に親記事を読んでおくと本記事の位置づけが掴みやすくなります。

この記事は Claude 公式の Effort / Pricing / Model configuration ドキュメント(2026年5月時点)を一次ソースとして参照し、Claude Code 最新版(v2.1.156)の実機で /effort の選択肢・既定値・設定永続性を確認したうえで執筆しています。仕様は更新される場合があるため、最終的な挙動は公式ドキュメントの最新版をご確認ください。

/effort は「賢さ」ではなく「Claude がトークンをどれだけ気前よく使うか(思考・ツール・出力すべての丁寧さ)」のレバーです。迷ったらモデル別の推奨スタートで選べばよく、Opus 4.8 のコーディングは xhigh、汎用は high、Sonnet 4.6 は medium。「最近コストが増えた気がする」原因は『トークナイザ(4.6→4.7 で最大+35%・以降据え置き)』と『effort(自分で回すノブ)』の2軸に分けて考えれば切り分けられます。4.7→4.8 で換算レートは増えず、むしろツール用システムプロンプトは 675→290 トークンに減っています。

目次

/effort って結局なに? ―― 賢さとコストを1本のレバーで動かす設定

Claude Code を使っていて、/effort と打つとこんな選択肢が出てきたことはありませんか。

terminal
/effort  [low | medium | high | xhigh | max | ultracode | auto]

見慣れない xhighmax、さらには ultracodeauto まで並んでいて、「とりあえず一番強そうな max にしとけばいいのかな?」と思った人も多いはずです。結論から言うと、それは多くの場合ハズレです。

/effort(エフォート=努力度)は、ひとことで言えば「Claude がトークンをどれだけ気前よく使うか」を決めるレバーです。公式ドキュメントの表現を借りると、effort は "how eager Claude is about spending tokens"(どれだけ積極的にトークンを使うか)を制御します。レベルを上げれば深く考え、たくさんツールを呼び、丁寧に説明します。下げれば即答し、ツール呼び出しをまとめ、簡潔に返します。

ポイントは、これが思考(thinking)だけの設定ではないことです。公式は effort が「応答内のすべてのトークン」に効くと明記しています。

  • テキストの応答・説明
  • ツール呼び出しとその引数
  • 拡張思考(有効な場合)

つまり effort を下げると、Claude はツールを呼ぶ回数そのものを減らし、複数の操作を1回のツール呼び出しにまとめ、前置きなしで作業に入ります。「賢さのつまみ」ではなく「全体の動きの丁寧さ・徹底度のつまみ」だと捉えるのが正確です。

7つの選択肢を一望する

まずは全体像です。公式の定義(platform.claude.com の effort ドキュメント)をそのまま整理しました。

レベル正体ざっくり何者か
lowAPI の effort 値最も効率的。トークンを大きく節約する代わりに能力は少し落ちる
mediumAPI の effort 値バランス型。そこそこ節約しつつ実用品質を保つ
highAPI の effort 値高能力。パラメータを指定しないのと同じ挙動。多くのモデルの既定値
xhighAPI の effort 値長時間作業向けの拡張能力。Opus 4.8 / 4.7 のみ
maxAPI の effort 値制約なしの最大能力。最も徹底した推論
ultracodeClaude Code 独自設定(API の effort ではない)xhigh を送りつつ、自律的なマルチエージェント・ワークフローを許可する
autoリセット指示現在のモデルの既定 effort に戻す

ここで一番大事な切り分けは、lowmax の5つは API レベルの effort 値で、ultracodeauto は Claude Code の操作概念だということです。ultracode はモデルに送る effort としては xhigh と同じで、それに「ワークフローを自律起動してよい」という権限がくっついたもの。auto はそもそも effort の値ではなく「既定に戻せ」というリセットボタンです。この2つは「Claude Code の新effortモード徹底解説|max・ultracode・autoと『呪文ultrathink』の正体BlogClaude Code の新effortモード徹底解説|max・ultracode・autoと『呪文ultrathink』の正体Claude Code の /effort に増えた max・ultracode・auto と、プロンプトに紛れ込ませる呪文 ultrathink を、公式が明言した『ultracode は API の effort レベルではない』を起点に解剖。overthinking・自律ワークフロー・永続性と優先順位の罠まで、誤解されやすい論点を一次情報で正します。」(シリーズ②)で深掘りするので、ここでは「別カテゴリ」とだけ覚えてください。

そして地味に重要なのが、モデルによって使える段階が違う点です。

モデル使える effort
Opus 4.8 / Opus 4.7low medium high xhigh max
Opus 4.6 / Sonnet 4.6low medium high maxxhigh なし)
Sonnet 4.5 以前effort 非対応

xhigh は Opus 4.8 と 4.7 だけの特権です。もし Opus 4.6 で xhigh を指定しても、公式仕様では「指定値以下で対応している最高レベルに自動で落ちる」ので、high として動きます。エラーにはなりません。

どの状況でどれを選ぶ? ―― 公式推奨に基づく判断フロー

ここが本題です。「で、結局どれを使えばいいの?」に公式ガイダンスで答えます。

Anthropic は Opus 4.8 についてこう明言しています(effort ドキュメントの原文)。

Start with xhigh for coding and agentic use cases, use high for most other intelligence-sensitive workloads, and step down to medium or low only when you've measured that the lower level holds quality on your evals.

訳すと「コーディングやエージェント用途では xhigh から始めよ。それ以外の知性が要る作業は highmediumlow への引き下げは、eval(評価)で品質が落ちないと確認できたときだけにせよ」。

つまり Opus 4.8 をコードに使うなら、既定の high よりもむしろ xhigh が推奨スタート地点なのです。これは後で効いてくる重要な点なので覚えておいてください。

各レベルの使い所を、公式の「When to adjust」記述に沿ってフロー化するとこうなります。

  • 短い・スコープ明確・知性をあまり要さない(分類、ルックアップ、定型処理、大量バッチ) → low。速度とコストを最優先する場面です。
  • コスト重視で、多少の知性は犠牲にできる平均的なワークフローmedium。Sonnet 4.6 の公式推奨デフォルトはこれです。
  • 複雑な推論・難しいコーディング・品質が速度やコストより大事high。Opus 4.8 の既定であり、汎用の安全牌。
  • 30分を超える長時間のエージェント作業・反復的なツール呼び出し・詳細な探索やWeb検索xhigh。公式は「数百万トークン規模」の作業を想定すると書いています。
  • 本物のフロンティア級の難問max。ただし乱用厳禁(理由は後述)。

モデル別の推奨デフォルトを一枚にまとめます。

モデル既定 effortコーディング推奨スタート
Opus 4.8highxhigh
Opus 4.7xhighxhigh
Sonnet 4.6high(だが公式は medium 推奨)medium

なお xhighmax で長時間回すときは、思考とツール呼び出しのために max_tokens を大きめ(公式は 64k トークンを出発点に推奨)に取っておくのがコツです。狭いと思考の途中で詰まります。

コストの2軸を切り分ける ―― 「トークナイザ」と「effort」は別物

ここからが、多くの人が混乱して損をしているポイントです。「Opus 4.8 にしてから、なんだかトークン消費が増えた気がする」という感覚。これ、原因が2つあって、それぞれ発生源がまったく違います

軸①:トークナイザ(換算レート) 同じ文章が「何トークンに化けるか」の換算レートです。公式 pricing ページにこんな注記があります。

Opus 4.7 and later use a new tokenizer compared to previous models... This new tokenizer may use up to 35% more tokens for the same fixed text.

「Opus 4.7 以降は新しいトークナイザを使い、同じ固定テキストで最大35%多くトークンを消費しうる」。つまり同じプロンプトでもトークン数が最大1.35倍にカウントされるわけです。単価(入力 $5 / 出力 $25)は据え置きでも、実コストは膨らみます。

軸②:effort(生成量) Claude が「どれだけ生成するか」。xhighmax を選ぶと、思考トークン・ツール呼び出し・出力テキストが増えます。これは自分で回すノブであって、モデルに強制されるものではありません。

この2軸を混同すると、「Opus 4.8 にしたらトークナイザのせいで勝手に増えた」と誤解しがちです。正しく切り分けるとこうなります。

4.6 → 4.74.7 → 4.8
トークナイザ(換算レート)新トークナイザ導入で最大+35%据え置き("4.7 and later" = 同じトークナイザ。追加増なし)
effort(生成量)xhigh/max を選べば増える(=自分のノブ)

ここが今回いちばん伝えたい事実です。「+35%」は 4.6→4.7 で一度きり起きた段差であって、4.8 はそれを引き継いでいるだけ。4.7 から 4.8 に上げても、換算レートがさらに膨らむことはありません。「Opus 4.7 で新トークナイザになったばかりなのに、4.8 でさらに増えるの?」という不安への答えは、ノーです。増えるのは「あなたが effort を上げたときだけ」です。

Opus 4.8 は本当に重いのか ―― tool用システムプロンプト290トークンの衝撃

「とはいえ最新の Opus 4.8 はいちばんトークンを食うんでしょ?」と思いますよね。ところが、公式 pricing ページの「ツール利用時のシステムプロンプト・トークン数」の表を見ると、でした。

モデルツール用システムプロンプト(auto / none)
Opus 4.7675 トークン
Opus 4.6497 トークン
Opus 4.8290 トークン(4.7 の半分以下)

Claude Code はほぼ常にツールを使うので、この「ツールを有効にするための裏側のシステムプロンプト」は毎リクエストに乗ってきます。それが Opus 4.7 の 675 トークンから、4.8 では 290 トークンへと、半分以下に削減されているのです。

さらに 4.8 は adaptive thinking(適応的思考)で「考える必要があるときだけ考える」挙動が洗練され、単純なステップでは思考をスキップして無駄な思考トークンを減らします。

これらを合わせると、結論はこうです。同じ effort なら、Opus 4.8 は 4.7 より総トークン消費がむしろ減る方向。「最新だから重い」は思い込みで、実態は「最新だからオーバーヘッドが軽い」。重くなるのは、繰り返しますがあなたが effort レバーを上げたときだけなのです。

実機で確かめた『設定の罠』 ―― 永続性と auto の使いどころ

ここからは、筆者が手元の環境(Claude Code を最新版に更新した状態)で実際に確認した運用上の罠です。

罠①:settings に書ける effort・書けない effort がある 設定ファイルの effortLevel に永続化できるのは low medium high xhigh の4つだけ。maxultracode はセッション限定で、設定ファイルには書けません(max だけは環境変数 CLAUDE_CODE_EFFORT_LEVEL 経由なら例外的にセッションへ固定できます)。「max を常用設定にしたい」と思っても、正攻法では毎セッション指定が必要、というわけです。

罠②:モデルを切り替えると effort がリセットされる 公式仕様で「Opus 4.8 や 4.7 を初めて起動したとき、以前に別モデルで設定した effort があってもそのモデルの既定に戻す」とあります。Opus 4.8 なら high、4.7 なら xhigh に。だから「さっき max にしたのにモデル切替後に戻ってる!」は仕様どおりの挙動です。

罠③:auto はリセットボタン ここで auto の出番です。/effort auto を実行すると、現在のモデルの既定 effort に戻ります。前のセッションで max まで上げていたのを素早く標準へ戻したいときの「お掃除ボタン」として使うのが正しい使い方です。

そして実際に確認してハッとしたのが、筆者の設定が effortLevel: xhigh になっていたこと。最初は「最大に振りすぎでは?」と焦ったのですが、前述のとおりOpus 4.8 のコーディング用途では xhigh こそ公式推奨スタート地点。むしろ教科書どおりの設定でした。xhigh は「極端な最大」ではなく「コードを書かせるなら標準」――この感覚のズレこそ、今回の記事で一番伝えたかったことかもしれません。本当の最大は max で、そちらは別の慎重さが要ります(続編で詳しく解説します)。

まとめ ―― 明日から使えるチートシート

長くなったので、持ち帰り用に圧縮します。

  • /effort は「賢さ」ではなく「トークンの気前よさ=思考・ツール・出力すべての丁寧さ」のレバー
  • 迷ったらモデル別の推奨スタートで。Opus 4.8 のコーディング → xhigh、汎用 → high、Sonnet 4.6 → medium
  • コスト増の原因は2軸。トークナイザ(4.6→4.7 で+35%・以降据え置き)と effort(自分のノブ)。4.7→4.8 で換算レートは増えない
  • Opus 4.8 はむしろ軽い。ツール用システムプロンプトは 4.7 の675→290トークン。同 effort なら総消費は減る方向。
  • maxultracode は設定に書けずセッション限定auto は既定に戻すリセットボタン。
  • 速度が欲しい場面では遠慮なく /effort low に下げる。effort は固定するものではなく、タスクごとに動かすものです。

新顔の max ultracode、そして「呪文」ultrathink の正体は、続く「Claude Code の新effortモード徹底解説|max・ultracode・autoと『呪文ultrathink』の正体BlogClaude Code の新effortモード徹底解説|max・ultracode・autoと『呪文ultrathink』の正体Claude Code の /effort に増えた max・ultracode・auto と、プロンプトに紛れ込ませる呪文 ultrathink を、公式が明言した『ultracode は API の effort レベルではない』を起点に解剖。overthinking・自律ワークフロー・永続性と優先順位の罠まで、誤解されやすい論点を一次情報で正します。」(シリーズ②)で徹底解説します。

よくある質問(FAQ)

Q. 結局、どの effort から始めればいいですか? A. モデルとタスクで決めるのが正解です。Opus 4.8 でコーディングやエージェント用途なら xhigh、それ以外の知性が要る作業は high、Sonnet 4.6 は公式推奨どおり medium から。そこから「軽い作業は low に落とす」「品質が頭打ちなら下げる」と、タスクごとに動かしていくのが公式の考え方です。固定する設定ではありません。

Q. Opus 4.8 にしたらコストが増えた気がします。トークナイザのせいですか? A. 4.7→4.8 では換算レート(トークナイザ)は増えていません。新トークナイザによる最大+35%は 4.6→4.7 で一度きり起きた段差で、「4.7 and later」は同じトークナイザを共有しています。コストが増えたと感じるなら、原因はトークナイザではなく xhigh/max などで effort(生成量)を上げたか、扱う作業量そのものが増えたかのどちらかです。

Q. xhigh は最大に近い設定だから、常用すると重すぎませんか? A. xhigh は「極端な最大」ではなく、Opus 4.8 のコーディング用途における公式の推奨スタート地点です。本当の最大は max で、こちらは overthinking のリスクがあるため常用は非推奨。xhigh は「コードを書かせるなら標準」くらいの感覚で問題ありません。

関連記事

この記事を書いた人

HW系エンジニアとして20年以上、10,000件を超える顧客訪問と2,000件を超える単独ソリューション実績。AIツールを使った個人開発やIoT農園など、Raspberry Piを使ったオートメーション化なども実践中です!エンジニア専門結婚相談所も運営中、ClaudeCodeで解決できない心の課題も解決いたします!

出典

この記事は上記 Claude 公式ドキュメント(2026年5月時点)を一次ソースとして参照し、Claude Code 最新版(v2.1.156)の実機で /effort の選択肢・既定値・設定永続性を確認(検証日 2026-05-29)したうえで執筆しています。価格・トークナイザ・effort 仕様は公式ドキュメントの当日時点の記載に基づきます。

$5〜$20のGPT-6 Astra:OpenRouterで5経路、エラー率13倍
2026年9月5日
チュートリアル

$5〜$20のGPT-6 Astra:OpenRouterで5経路、エラー率13倍

同じGPT-6 Astraでも、OpenRouterの提供事業者で価格・速度・ツール呼び出しとJSON出力の失敗率が大きく変わります。

#OpenRouter#GPT-6 Astra#AIエージェント#構造化出力
Claude Codeを10時間放置で実測:177k再読は空ターン何回分か
2026年9月3日
開発ログ

Claude Codeを10時間放置で実測:177k再読は空ターン何回分か

約10時間放置したセッションの再開で 177k トークンが再書き込みされた実測を起点に、Claude Code で1時間キャッシュを空ターンで温め続ける価値を API 単価とサブスク枠の両面から損益分岐で計算しました。

#Claude Code#Claude#Anthropic#LLM#コスト削減
effort を途中で変えるとキャッシュはどうなる? Fable 5.1 と Opus 5 で実測した
2026年9月3日
開発ログ

effort を途中で変えるとキャッシュはどうなる? Fable 5.1 と Opus 5 で実測した

Fable 5.1 の値下げはキャッシュ読みだけ。Claude Code が TTL を決める仕組み、キャッシュを壊す操作と壊さない操作、effort 切替時の再書き込みを Fable 5.1 と Opus 5 の usage で実測しました。

#Claude Code#Claude#Anthropic#LLM#コスト削減
Fable 5.1 は『low で旧 max 超え』なのか|公式グラフ5枚をベンチ別に正直に読む
2026年9月3日
開発ログ

Fable 5.1 は『low で旧 max 超え』なのか|公式グラフ5枚をベンチ別に正直に読む

Claude Fable 5.1 の公式グラフ5枚をベンチ別に読み、low が旧 Fable 5 の max を超えたベンチと超えなかったベンチを表にしました。常用 effort の決め方と Pro/Max の課金条件も整理します。

#Claude#Claude Code#Anthropic#LLM#ベンチマーク

META-MARK × AI

ローカルAIを動かすGPU、ちゃんと選べていますか?

VRAM・性能・コスパをMetaScoreで数値化。AIアプリ別の推奨ハードウェア要件も確認できます。