
Claude Codeのeffort・ultracodeとは?設定方法と違い、使用量を減らす選び方【2026年10月】
「Claude Code の effort って何?」「ultracode と何が違うの?」「使っていたら、使用量の枠がすぐなくなった」。この記事は、そんな方に向けた effort と ultracode の解説です。
この記事を読むと、effort の5段階の意味、設定方法(/effort・--effort・settings)、9月末に変わった ultracode の仕組みと切り替え方、使用量・費用・時間の実測例、そして「合格する一番低い effort を選ぶ」という考え方まで、一通り分かります。
私は Claude Code と Codex を毎日使って、教材づくり、note・Gumroad への出品、画像づくりを自動化しています。使用量の枠は、実際に私も気にしています。そこで、公式ドキュメントで確かめたことと、他の人の報告や私の運用を、はっきり分けて書きます。全文無料です。
確認の日付は 2026年10月14日です。公式ドキュメントで確認できたものは「公式では」と書きます。ブログや X の投稿が1件だけの話、本人が自分で書いた数字は、そう分かるように書きます。更新が速い分野なので、コマンドや仕様は、最新の公式ドキュメントと /help で確かめてください。
この記事で分かること
effort とは何か。low・medium・high・xhigh・max の意味
既定の effort はいくつか(モデルによって違います)
設定方法:/effort、--effort、環境変数、settings
ultracode とは何か。effort との違い。9月末の変更点
ultracode をオン・オフする方法と、使えない場面
使用量・費用・時間の実測例(出典と確度つき)
「合格する一番低い effort を選ぶ」考え方と、試し方
作業ごとの選び方の早見
使用量の枠を溶かさないコツ
私の運用例(自動実行での effort の割り振り)
先に結論
effort は「考える量・作業の丁寧さ」を決める設定です。高いほど正確になりやすい反面、時間とトークンを多く使います
公式の説明では、Opus 5.5 の既定は medium です。まず既定のまま使い、足りない作業だけ上げるのが基本です
ultracode は effort の段階ではなく、「大きな作業を多数のサブエージェントに分けて進める」設定です。公式でも「モデルの effort レベルではない」と書かれています
一番高い設定が一番良いとは限りません。「合格する一番低い effort」を選ぶと、使用量が大きく減ります
ultracode は、その日一番難しい作業にだけ使います。終わったら /effort ultracode off で戻します
effortとは?
公式の説明:「どれだけ頑張るか」を決めるつまみ
effort は、Claude がどれだけ時間とトークンをかけて応答するかを決める設定です。Anthropic の API ドキュメントには、effort は「応答の丁寧さとトークンの効率を、1つのモデルのまま調整する」ものだと書かれています。
ポイントは2つあります。
effort は、考える部分(思考)だけでなく、すべての出力トークンに影響します。本文の説明、ツールの呼び出し、思考のすべてです。low では、ツール呼び出しが少なく、前置きが短く、返事が簡潔になります。高くすると、ツール呼び出しが増え、計画の説明が増え、変更の要約が詳しくなります
effort は「厳密なトークンの上限」ではなく、「行動の傾向を決めるサイン」です。low でも、難しい問題ではちゃんと考えます。ただし、高い設定より考える量が少なくなります
もう1つ、公式ドキュメントにある重要な注意があります。effort の目盛りは、モデルごとに調整されています。同じ「high」でも、モデルが違えば、考える量は同じではありません。モデルを変えたら、前のモデルの設定をそのまま持ち込まず、もう一度見直すのが公式の推奨です。
5段階の意味
Claude Code の公式ドキュメント(Model configuration)に載っている段階と、使いどころです。
low:すばやいやり取り、短い確認が前提の作業。ブレインストーミングや小さな名前の変更など。API の説明では、サブエージェントのような「単純で、速さと低コストが最優先」の作業にも向くとされています
medium:日々の作業で、範囲がはっきりしているもの。Opus 5.5・Sonnet 5.5・Haiku 5.5 の、Claude Code での既定です
high:検証が大事な作業や、境界の条件に気をつけたい作業。バグ修正など。多くのモデルの既定です
xhigh:より深い推論。トークンの使用量も増えます。長時間のエージェント作業や、コーディングに向くとされています
max:難しい問題向け。公式にも「max は効果が小さくなりやすく、考えすぎやすいので、広く使う前に試すこと」と書かれています
つまり、公式自身が「max はいつでも一番良いわけではない」と言っています。
使えるモデルと、使えないときの動き
公式ドキュメントでは、Opus 5.5・Sonnet 5.5・Haiku 5.5・Opus 5・Sonnet 5・Opus 4.8・Opus 4.7、Fable 5.1 と Fable 5 が5段階すべてに対応しています。Opus 4.6 と Sonnet 4.6 は xhigh がなく、4段階です。それ以外のモデルは、effort 自体に対応していません。
対応していない段階を指定したら、Claude Code は「指定より低くて、一番近い段階」に自動で落とします。たとえば Opus 4.6 で xhigh を指定すると、high で動きます。
既定の effort はいくつ?
公式の説明では、Claude Code は次の順で effort を決めます。上にあるほど優先です。
明示した指定:環境変数 CLAUDE_CODE_EFFORT_LEVEL、--effort フラグ、セッション中の /effort
保存された設定:モデルごとに保存されたレベル、または settings の effortLevel
モデルの既定:ほとんどのモデルは high。ただし Opus 5.5・Sonnet 5.5・Haiku 5.5 は medium、Opus 4.7 は xhigh
Opus 5.5 の既定が medium になった理由として、公式は「Anthropic のテストでは、Opus 5.5 の medium が、Opus 5 の high と同等か、それ以上だった」と説明しています。また、同じ段階でも Opus 5.5 のほうが 1 ターンで考える量が多い傾向がある、とも書かれています。Opus 5 から移るときは、前の high を持ち込まず、medium から始めるのが公式の案内です。
なお、API 側の説明では Sonnet 5.5 の既定は high とあり、Claude Code の説明(medium)と食い違って見えます。この記事は Claude Code のドキュメントに従います。迷ったら /effort を開いて、画面の表示を見てください。
effortの設定方法
セッション中に変える:/effort
Claude Code の中で次のように使います。
/effort
/effort high
/effort auto/effort(引数なし):スライダーが開きます。左右の矢印で選びます
/effort high:段階の名前を指定して、直接設定します
/effort auto:いま使っているモデルに保存したレベルを消して、既定に戻します
/model の画面にも、同じ effort のスライダーがあります。
保存される?されない?
ここは、つまずきやすい所です。公式の説明では、こうなります。
スライダーや /model の画面で Enter を押すと、そのレベルがモデルの既定として保存されます
s を押すと、このセッションだけに適用されます(v2.1.257 以降)
-p(1回だけ答える非対話モード)では、/effort はそのセッションだけで、保存されません
max は、環境変数 CLAUDE_CODE_EFFORT_LEVEL で指定しない限り、現在のセッションだけに適用されます
「max にしたはずが、次の日には戻っていた」のは、故障ではなく、この仕様です。
起動時に決める:--effort
claude --effort highその1回のセッションだけの設定です。毎回の起動を同じ設定にしたいなら、次の環境変数か settings を使います。
環境変数と settings
環境変数 CLAUDE_CODE_EFFORT_LEVEL:レベル名、または auto。優先順位が一番高い指定です
settings の effortLevel:low・medium・high・xhigh を指定できます。max は、この設定では受け付けられません。ultracode には専用の設定(後で説明します)があります
settings の modelSettings:モデルごとのレベルです。/effort で選ぶと、Claude Code が自動で保存します。書式は公式の設定リファレンスで確認してください
{
"effortLevel": "medium"
}注意点が1つあります。公式の説明では、Opus 5.5 では、ユーザー設定の直下に書いた effortLevel は効きません。この書き方は、Claude Code がモデルごとに保存する前の古い形で、Opus 5 以前のモデルでは今も効きます。Opus 5.5 以降のモデルは、/effort か /model の画面でレベルを選ぶまで、そのモデルの既定で始まります。プロジェクトの設定やローカルの設定にある effortLevel は、すべてのモデルに効きます。
「settings に書いたのに Opus 5.5 だけ medium のまま」という場合は、これが原因かもしれません。
スキルとサブエージェントに書く
スキルやサブエージェントの Markdown ファイルの先頭(frontmatter)に effort を書くと、そのスキル・サブエージェントが動くときだけ、セッションの設定を上書きできます。たとえば、点検専用のサブエージェントだけ high にして、セッション全体は medium のまま、という使い方です。ただし、環境変数 CLAUDE_CODE_EFFORT_LEVEL がある場合は、そちらが優先されます。
また、v2.1.292 以降では、Claude がサブエージェントを起動するときに、その1回ぶんの effort を指定できます。
ultrathinkとの違い
名前が似ているものに、ultrathink があります。公式の説明では、プロンプトのどこかに ultrathink と書くと、その1ターンだけ深く考えるよう Claude Code が指示を足します。セッションの effort の設定は変わらず、API に送られる effort のレベルも変わりません。「think hard」などの言い回しは、キーワードとして扱われません。
整理すると、次のようになります。
effort:セッション全体の、考える量の設定
ultrathink:1ターンだけ深く考えさせる、使い捨ての合図
ultracode:大きな作業を、多数のエージェントに分けて進めさせる設定(次の章)
ultracodeとは?
effortの段階ではなく、「進め方」の設定
公式の説明では、ultracode は「Claude Code の設定であり、モデルの effort レベルではない」ものです。オンにすると、Claude は大きな作業に対して、動的ワークフロー(dynamic workflows)を使って進めます。そのときの effort は、セッションが動いているレベルのままです。
動的ワークフローとは、Claude が作業ごとに書く JavaScript のスクリプトを、実行環境(ランタイム)が裏で動かし、多数のサブエージェントをまとめて動かす仕組みです。公式の例は、リポジトリ全体のバグ探し、500ファイルの移行、出典を突き合わせる調査などです。途中の結果はスクリプトの変数に入るので、Claude の会話には最終的な答えだけが残ります。作業の進み具合は、/workflows で見られます。
ultracodeのオン・オフ
公式ドキュメントに載っている方法です。
セッション中にオン:/effort ultracode。オフは /effort ultracode off
スライダーで切り替え:/effort のスライダーを開き、Tab キーで「Ultracode」を切り替えて、Enter で適用します
起動時にオン:claude --effort ultracode。このときは effort も xhigh で始まります(v2.1.203 以降)
いつもオン:settings に "ultracode": true
/effort ultracode
/effort ultracode offclaude --effort ultracodeこのほかに、1回だけ使う方法があります。プロンプトに ultracode という言葉を入れると、そのタスクだけがワークフローになります。
ultracode: src/routes/ の全エンドポイントを調べて、認証チェックの抜けを報告して入力欄の中で、キーワードが強調表示されます。間違って入れたときは、macOS は Option+W、Windows と Linux は Alt+W で、そのプロンプトだけ取り消せます。キーワード自体を無効にしたいなら、/config の「Ultracode keyword trigger」をオフにします。
「ワークフローを使って」「use a workflow」のように、自分の言葉で頼んでも、同じ扱いになります。
9月末の変更:独立したトグルになり、xhighに固定されなくなった
ここが、古い解説と新しい解説で食い違うところです。
最初の ultracode は、オンにすると effort が xhigh になる、という説明が多くありました。現在の公式ドキュメントでは、ultracode は effort とは独立したトグルで、/effort や settings でオン・オフしても、effort のレベルは変わらない、と書かれています。
公式ドキュメントには、/effort ultracode off と、ultracode を他の段階のまま使うことは、v2.1.284 以降とあります
変更履歴をまとめている X のアカウントも、CLI 2.1.284(9月28日)の更新として「ultracode を /effort の独立トグルにした(Tab、または /effort ultracode のオン・オフ)。xhigh を強制しなくなった」と投稿しています。私は変更履歴の原文は読めていないので、これは公式ドキュメントの記述と合う、という確認です
一方で、claude --effort ultracode で起動したときだけは、今も xhigh で始まります
つまり、いまは「medium のまま ultracode をオン」も、「high のまま ultracode をオン」もできます。ultracode と effort は、別々に選ぶものです。古い記事の「ultracode = xhigh 固定」は、現在の仕様とは違うので注意してください。
使えない場面
公式の説明では、ultracode は次の場面で使えません。
ワークフロー自体がオフのとき
使っているモデルが xhigh に対応していないとき
もう1つ重要なのは、-p(非対話モード)のプロンプトでは、ultracode というキーワードがワークフローを起動しないことです。自分で入力したプロンプト(対話の画面、IDE の拡張機能、リモートコントロールなど)でだけ有効です。定期実行のプロンプトや、Web からの入力で勝手に起動しないための仕様です。
動く規模の上限
公式ドキュメントにある、ランタイムの上限です。
同時に動くエージェントは、既定で最大16(CPU が少ない環境ではもっと少なくなります)
1回の実行で動くエージェントは、合計1,000まで
X には「ultracode は50体を超えることもある」という投稿もありますが、本人も「random」と書いていて、公式の数字ではありません。
切り方:ワークフローそのものをオフにする
ultracode をまるごと使えなくするには、ワークフローをオフにします。公式の方法は3つです。
/config で「Dynamic workflows」をオフにする
settings に "disableWorkflows": true を書く
環境変数 CLAUDE_CODE_DISABLE_WORKFLOWS=1 を設定する
組織の管理者は、managed settings で一括して止められます。止めると、/workflows や、ultracode のキーワード、/effort の Ultracode のトグルも消えます。
ultracodeで何が起きるか(費用の仕組み)
公式の説明が、とても正直です。ultracode をオンにすると、Claude は大きな作業ごとに、ワークフローを計画します。1つの依頼が、「コードを理解する」「変更する」「検証する」という複数のワークフローに分かれることがあります。そのため、同じ依頼でも、ultracode をオンにしないときより、トークンも時間も多く使います。サブスクリプションの場合、それは使用量の枠から引かれます。ultracode をオンにしたセッションは、オフのときより早く、5時間の枠や週の枠に当たると、公式にも明記されています。
さらに、ultracode をオンにすると、次のチェックが働かなくなります。
「Large workflow(大きなワークフロー)」の警告が出なくなります。通常は、25を超えるエージェントを予定したとき、または予想トークンが150万を超えたときに、警告が出ます
サブエージェントの同時起動数の上限(既定は20)が、効かなくなります
auto モードで、最初のワークフロー起動時に聞かれる確認が出なくなります
公式は理由として、「ultracode をオンにすること自体が、大きな実行への同意だから」と説明しています。言い換えると、安全装置が外れた状態です。だから、オンにしっぱなしにしないのが大事です。

使用量・費用・時間の実測例
ここからは、公式ではなく、他の人の報告です。確度を付けて並べます。数字は、その人の環境と、その時点のものです。
同じアプリを段階別に作らせた比較(Nate Herk さん、9月24日)
X の記事での報告です。Opus 5.5 に同じアプリを、段階を変えて作らせました。記事で確認できた3つです。
Max:2時間28分、約118万トークン、約50.38ドル
Ultracode:1時間35分、約60.6万トークン、約18.69ドル
Extra:1時間30分、約73.3万トークン、約25.92ドル。本人が一番気に入ったのはこれ
確度:単独の投稿で、各段階1回ずつの測定です。再現性は保証されません。「Extra」は記事での呼び方で、公式ドキュメントの段階名(xhigh など)と同じものかは、私は確認できていません。金額も本人の記載のままです。
ここから言えるのは、「一番高い設定が、一番速くて一番良い」とは限らない、という程度です。
ultracode の費用の中身は「検証」(複数の投稿)
Kei Nakazawa さんは、Opus 4.8 と ultracode で2〜3時間使った感想として、「実装後のセルフレビューが、実装本体の約3倍のトークンを使う」と書いています。「3倍」という数字は単独の投稿です
Alexvx さんの記事は、「1依頼が、理解・実装・検証の3つのワークフローになる。強力だが高い」と整理し、「一日中ではなく、そのセッションで一番難しい仕事にだけ使う」ことを勧めています(記事の要約のみ確認)
Shann さんも、「トークンを度外視するモード。軽い下書きには向かない」という趣旨を書いています
公式の説明(1依頼が複数のワークフローに分かれる)と、複数の人の体感が合っています。「3倍」という具体的な数字だけは、単独の報告です。
Opus 5.5 で、使用量の枠が思ったより減らなかった報告(9月下旬)
Theo さんが、Opus 5.5 の ultracode で /goal を13時間回しているのに、使用量がほとんど減らない、と投稿しました。翌日には「やっと少し減ってきた」と続報を出しています
Robin Ebers さんは、600エージェント・7000万トークンの掃除作業が、200ドルのプランの週の枠の25%で済んだと報告しています
Izuddin Helmi さんは、ultracode の調査1回が約4%だった、と書いています
確度:複数の投稿で「Opus 5.5 は枠を食いにくい」という点は一致していますが、理由の説明は無く、未確認です。逆に、Reddit には「Opus 5.5 が購読の枠を速く使う」という投稿もあり、サブエージェントを多用する人とそうでない人で、意見が割れています(再現できる測定はありません)。人によって、プラン、作業の内容、時期で、結果は変わります。
発売直後は、枠が30分で70%溶けた(Opus 4.8 の時期)
Opus 4.8 で ultracode が出た5月28日に、Max Weinbach さんが「100ドルのプランで、5時間の枠の約70%を30分で使う」と警告しました(単独の投稿)
6月1日に、Claude Code の公式アカウントが、Pro・Max の5時間枠と週の枠をリセットしました。理由は「一部のセッションが、過剰な並列サブエージェントを起動する問題を直した」で、ultracode とは名指ししていません
公式アカウントの発表なので、「枠のリセットと、並列サブエージェントの問題の修正」は確認済みです。ただし、ultracode が原因だったかどうかは、確認できていません。
105エージェントで枠が2回尽き、チームの組み方で完走(Vox さん、9月27日)
Opus 5.5 の動的ワークフロー105エージェントで、自分の投稿1,500件以上から、66個のスキルを作る作業を回した報告です。素材を読む71エージェントを8並列で回したら、1回の通しで約1,200万トークンを使い、上限に2回当たって数時間止まったそうです。そこで、構築と品質確認を3体ずつのグループに変え、effort も役割ごとに下げました。
読み込み:low
執筆:medium
レビュー:high
最終判断:xhigh
確度:単独の投稿で、数字は本人の申告です。ただ、考え方は参考になります。全員を最高設定にせず、役割ごとに分ける、という形です。
スライド生成で、maxはコスト2.1倍・時間2.3倍(太田賢一さん、10月3日)
Opus 5.5 でスライド生成の仕組みを作った人の記事です。effort は high が既定で、max にするとコストが2.1倍、時間が2.3倍になるのに、品質の上がりはわずかだった、とあります。確度は、単独の投稿(本人の測定。記事の本文は要約のみ確認)です。
「合格する一番低いeffortを選ぶ」という考え方
ここまでの話をまとめると、指針は1つです。合格する一番低い effort を選ぶ。これは、日本語の記事でも広まっている考え方で、ultracode と max の位置づけを整理した記事にも、同じ趣旨が書かれています。
公式の API ドキュメントも同じ方向です。Opus 5.5 には、「前のモデルの設定を持ち込まず、自分の評価で effort を試すこと」と書かれ、Claude Code のドキュメントにも「max は、広く使う前に試すこと」とあります。
「合格」を先に決める
「合格」は、感覚ではなく、先に決めておきます。例を挙げます。
テストがすべて通る
指定した形式(見出し・字数・ファイル名)に合っている
事実の誤りがない(出典が付いている)
手戻り(やり直しの依頼)が1回以内
たとえば教材の原稿づくりなら、「字数が範囲内」「見出しの構成が指定どおり」「誤字・事実の誤りがない」を、合格の条件にできます。
低いほうから試して、上げる
手順は、次の4つです。
同じ小さな依頼を用意する(自分の仕事で実際に頼むもの)
medium で実行して、合格条件を確かめる
不合格なら、どこが不合格かを見て、high に上げて、同じ依頼を出し直す
合格した段階を、その作業の標準にする。xhigh や max は、high で不合格が続いたときだけ試す
見るのは、合格・不合格のほかに、次の3つです。
手戻りの回数
かかった時間
/usage で見た、使用量の増え方
上げる前に、まず疑うこと
effort を上げる前に、次を確かめます。
依頼が曖昧ではないか。「何を、どのファイルに、どんな形で」が書かれているか。具体的に頼むほど、無駄な探索が減ります(公式のコスト管理のページにも、具体的な依頼が効率的とあります)
確かめる方法を渡しているか。テストや、期待する出力を書いておくと、Claude が自分で確認できます
会話が長すぎないか。長くなって精度が落ちたときは、effort より /clear のほうが効きます
浅い推論で間違えているときは、effort を上げるのが正解です。依頼が曖昧なときは、effort を上げても、同じ曖昧さの上で、お金をかけて考えるだけになります。
effortは、作業の途中で頻繁に変えない
API の説明では、会話の途中でトップレベルの effort を変えると、プロンプトキャッシュ(同じ内容を安く読み直す仕組み)が引き継がれない、とあります。Claude Code の /effort でも同じなのかは、私は確認していません。ただ、節約という点では、作業の最初に決めて、途中で何度も変えないほうが安全だと考えています。
作業ごとの選び方の早見
公式の表と、私の経験をもとにした目安です。モデルやプランで変わるので、あくまで出発点にしてください。
質問・フォルダの説明・名前の変更など:low か medium
普通の編集・原稿の整形・小さな機能追加(範囲がはっきりしている):medium(Opus 5.5 なら既定のまま)
バグ修正・検証が大事な作業・数ファイルにまたがる変更:high
長時間の自動実行・難しい実装・設計の見直し:xhigh(まず high で試して、不足したときだけ)
本当に難しい問題で、high や xhigh で何度も外したとき:max(そのセッションだけ)
リポジトリ全体の調査・数百ファイルの移行・出典を突き合わせる調査:ultracode(まず小さな範囲で試す)
1行の質問・軽い下書き:ultracode は使わない
サブエージェントに任せる単純な作業(検索・要約・整理):low か medium、モデルも軽いものに
点検(レビュー)専用のサブエージェント:high。frontmatter に書いておく
判断に迷ったら、「失敗したときの手戻りが大きいか」で考えます。手戻りが大きい作業(本番に出るもの、お金がかかるもの)は、段階を上げる価値があります。手戻りが小さい作業は、低く始めて、必要なら上げれば十分です。
使用量の枠を溶かさないコツ
公式のコスト管理のページと、実測の報告から、効くものを優先順に挙げます。
1. 作業が変わったら /clear
公式でも、「関係のない作業に移るときは /clear で新しく始める。古い文脈は、以降の毎回のメッセージでトークンを無駄にする」とあります。Claude Code は、毎回の依頼で会話全体を送ります。長い会話は、1行の質問でも、全体ぶんを使います。
2. 使用量を数字で見る
/usage で、セッションのトークンと、プランの使用量の内訳が見られます。サブスクリプションの場合、スキル・サブエージェント・プラグイン・MCP サーバーごとの割合や、「長い文脈」「キャッシュミス」のような行動の警告も出ます。数字は目安で、この PC の履歴から計算したものです(他の端末や claude.ai ぶんは含まれません)。体感ではなく、数字を見る習慣が大切です。
3. モデルを使い分ける
公式では、Sonnet はほとんどのコーディング作業をうまくこなし、Opus より安い。Opus は複雑な設計や複数ステップの推論に使う、と案内されています。Sonnet 5.5 については、Claude 公式が「Sonnet 5 より明確に上で、30%超速く、多くの作業で最大30%安い」と発表しています。担当者本人も、バグ修正の動画で「30%速く、使用量30%減」と投稿しています(本人が見せた1例です)。
モデルの使い分けは、別の記事(有料)で詳しく書いています。
4. サブエージェントのモデルを落とす
サブエージェントは、メインとは別に、それぞれリクエストを送ります。公式では、環境変数 CLAUDE_CODE_SUBAGENT_MODEL で、サブエージェントの既定のモデルを決められます。たとえば、メインは Opus、サブエージェントは軽いモデル、という分け方です。この変数は「既定」で、サブエージェント自身の指定や、Claude が渡すモデルのほうが優先されます。すべてを1つのモデルに揃えたいときは、CLAUDE_CODE_SUBAGENT_MODEL_FORCE=1 も一緒に設定します(v2.1.257 以降)。
X では、Fable 5.1 のときに、この設定でサブエージェントを Opus に落としたら消費がかなり減った、という投稿が複数出ていました。複数の投稿が一致しています。
5. ultracodeは「一番難しい仕事だけ」
ultracode は、同じ仕事でも使用量が大きくなる設定です。1日中オンにせず、そのセッションで一番難しい仕事のときだけオンにします。終わったら、/effort ultracode off です。
6. 小さな範囲で試してから、本番へ
公式のコストの説明にも、「大きな作業の前に、ディレクトリ1つや、狭い質問で、まずワークフローを試す」とあります。/workflows で、エージェントごとのトークン使用量が見られ、いつでも止められます(止めても、完了した作業は多くの場合残ります)。
7. 計画してから実装する
Shift+Tab で plan モードに切り替えると、Claude は調べて計画を立てるだけで、編集はしません。方向を間違えたまま実装すると、やり直しで使用量が二重にかかります。公式でも、複雑な作業の前に勧められています。方向が違うと気づいたら、Esc で止めます。
8. 全員を最高設定にしない(役割ごとに分ける)
Vox さんの例のように、読み込みは low、執筆は medium、レビューは high、最終判断は xhigh、と分けます。点検用のサブエージェントの frontmatter に effort: high を書く、などです。
私の運用:自動実行でのeffortの割り振り
私の作業場では、「依頼を裏で Claude Code に回す仕組み」を動かしています。そこで、effort とモデルを、2つの枠に分けています。
既定の枠:Opus 5.5 + effort medium
長文の枠:長い文章をまとめて何本も書かせる依頼だけ、Sonnet 5.5 + effort xhigh
実際の起動の形は、概念的には次のとおりです(実際には、出力の形式などの指定も付いています)。
claude -p --model claude-opus-5-5 --effort medium
claude -p --model claude-sonnet-5-5 --effort xhigh考え方は、「長文の量産は、モデルを軽くして使用量を抑え、その分 effort を上げる」という割り振りです。ここは正直に書くと、この2つを厳密に比べる実験をしたわけではありません。使いながら調整している設定で、いまの私の環境での話です。
ほかに、次のことを決めています。
既定の枠は、もともと公式の既定より1段上の high にしていました。ところが「使用量の減りが速い」と感じたので、2026年10月14日に公式の既定と同じ medium に下げました。この記事の「合格する一番低い effort」の考え方そのままです。むずかしい依頼だけ、その依頼の中で上げます
自動実行の枠では、max と ultracode は使っていません。参考までに、公式の仕様では、-p のプロンプトに書いた ultracode のキーワードはワークフローを起動しません。また、-p では、使用量の上限に当たったとき、ワークフローは一時停止せず、そのエージェントが失敗します
同時に動かす数と、1件の上限時間を決めています。1件は最長120分で止まります。同時に動かす数と、同じフォルダで同時に動かす数は、画面から変えられるようにしています。暴走して枠を溶かすのを防ぐ、保険の意味もあります
件数の多い繰り返し作業は、1件ずつ手順を決めて、同じ依頼の形で回します
この仕組みの全体像は、有料の記事で詳しく書いています。
よくある疑問
Q. ultracodeとmaxは、どちらが強い?
比べるものが違います。公式の説明では、max は「1回の応答で考える量を最大にする設定」、ultracode は「作業を複数のエージェントに分けて進める設定」です。考え方の整理としては、日本語の記事に「ultracode は xhigh に、分解・並列・独立した検証を足す設定で、max は思考を無制限にする設定」という説明があります(単独の記事)。難しい1つの問題には max、大きくて分けられる作業には ultracode、と考えると整理しやすいです。
Q. ultracodeにすると、必ず品質が上がる?
保証はありません。公式も「検証を重ねた、より信頼できる結果になりうる」という位置づけで、すべての作業が良くなるとは書いていません。X の報告も、「作る・検証・テスト・レビューが速い」という声と、「使いどころは限られる」という声に分かれています。小さな作業に使うと、使用量だけが増える可能性が高いです。
Q. 設定したのに、effortが変わらない
次を順に確かめてください。
CLAUDE_CODE_EFFORT_LEVEL が設定されていないか(優先順位が一番高いため、/effort の変更も負けます)
Opus 5.5 で、ユーザー設定の直下に effortLevel を書いていないか(効きません。/effort か /model で選び直します)
max を選んで、次のセッションに戻っていないか(max は、そのセッションだけです)
モデルが、その段階に対応しているか(Opus 4.6 では xhigh は high で動きます)
スキルやサブエージェントの frontmatter が、上書きしていないか
注意点
数字を一般化しない。実測例はすべて、その人の環境・プラン・時期のものです。同じ設定で、あなたの使用量が同じように変わる保証はありません
古い解説に注意。ultracode の説明は、9月末の変更の前後で食い違います。この記事は、公式ドキュメントに合わせています
ultracode は同意のうえで使う。大きな警告が出なくなり、同時起動の上限も効かなくなります。重要なファイルのある環境では、権限の設定とバックアップ(Git)を先に確認してください
公式を見る。コマンドや機能名は変わります。迷ったら /help と、公式ドキュメントの Model configuration・Dynamic workflows・Manage costs のページを確認してください
まとめ
effort は、考える量・丁寧さの設定。low・medium・high・xhigh・max の5段階で、モデルごとに目盛りが違う。Opus 5.5 の既定は medium
設定は /effort(Enter で保存、s でこのセッションだけ)、--effort、環境変数 CLAUDE_CODE_EFFORT_LEVEL、settings。max はそのセッションだけ。Opus 5.5 は、ユーザー設定直下の effortLevel が効かない
ultracode は effort の段階ではなく、動的ワークフローで大きな作業を分けて進める設定。v2.1.284 以降は、独立したトグルで、xhigh に固定されない。claude --effort ultracode で起動したときだけ xhigh で始まる
ultracode は、1依頼が複数のワークフローに分かれ、使用量が増える。警告や上限の一部も効かなくなる。一番難しい仕事だけに使い、終わったらオフにする
実測例では、「一番高い設定が一番良い」とは限らなかった。ただし、数字はどれも個人の報告で、再現は保証されない
選び方の基本は「合格する一番低い effort」。合格条件を先に決め、低いほうから試して、不合格のところで上げる
使用量を守る基本は、/clear、/usage で数字を見る、モデルを使い分ける、サブエージェントを軽くする、小さな範囲で試す
次の一歩は、普段の小さな依頼を、1つ選んで medium で試すことです。合格すれば、それが標準になります。
次に読む
Claude Codeの使い方・始め方入門(無料):インストールから最初の依頼まで
CLAUDE.mdの書き方(無料):毎回読む指示書を短く保つ方法
Claude Codeの使用量を減らすモデルの使い分け(¥100):Sonnet・Haiku・Opus の役割分担
Claude Codeを“社員”にする自動実行ボードの設計図(¥1,280):依頼を裏で自動実行する仕組みの作り方
このアカウントをフォローすると、Claude Code や Codex の新しい手順の記事が届きます。ぜひフォローしてください。
まさのAI実務ラボ|Codex・Claude Code では、有料記事が読み放題になります。Claude Code と Codex を使い分けて、道具や教材を作って売る手順をまとめて読みたい方はご覧ください。