Ultracode と Effort レベル：Claude Code を限界まで引き上げる
Claude Code の effort レベル（low〜xhigh）と ultracode を解説。オプトインの方法、+500k などのトークン予算ディレクティブ、エージェント単位の effort、全開にすべき場面を整理。
Claude Code の歴史の大半において、大きなダイヤルは 1 つ——どのモデルを使うか——だけでした。Fable 5 時代には 2 つ目のダイヤルが加わり、日々の作業ではこちらのほうが重要かもしれません。/effort は、どのモデルを選んだかとは独立に、各ステップでモデルがどれだけ深く推論するかを制御します。そしてこのダイヤルの最上部に位置するのが ultracode（ウルトラコード）です。Claude Code が速度やコストへの最適化を完全にやめ、あらゆる実質的なタスクでマルチエージェントワークフローのオーケストレーション（協調実行の指揮）を始めるモードです。
本ガイドでは、4 つの effort レベル、ultracode が実際に何を変えるのか、大規模な実行が暴走しないよう抑えるトークン予算ディレクティブ、そして——同じくらい重要な——すべてをオフにしておくべき場面を扱います。
Effort が実際に制御するもの
/effort はセッションの推論 effort（どれだけ考えるか）を設定します。どのモデルが応答するかは変わりません——それは /model の役割です。変わるのは、そのモデルが行動する前に各ステップへどれだけ思考を費やすかです。
トレードオフは単純です。
more effort → deeper reasoning per step
→ more tokens, more latency
→ better answers on hard problems
less effort → faster, cheaper turns
→ perfectly fine for mechanical work/model も /effort もセッションの途中で切り替えられ、保存を選べばどちらもデフォルトとして持続します。したがってワークフローはこうなります。まず妥当なデフォルトを設定し、特定のタスクがデフォルトより多く（あるいは少なく）値するときにダイヤルへ手を伸ばす。
どのモデルを動かすかも同時に検討しているなら、モデル選択ガイドと合わせて読んでください。モデル階層と effort レベルは別々の 2 つのダイヤルであり、面白い構成は両者の組み合わせから生まれます。
4 つのレベル
/effort には low、medium、high、xhigh の 4 つのセッションレベルがあります。
レベルごとの公式スペックシートは存在しませんし、必要もありません。有用なメンタルモデルは、マルチエージェントワークフローの内部で effort がどう使われているかから得られます。安価で機械的なステージには低 effort、難しい検証や判断のステージには高い階層。同じロジックをセッションにも適用してください。
| レベル | 使いどころ |
|---|---|
| low | 機械的な作業：リネーム、フォーマット、ボイラープレート、「このファイルを読んで X を教えて」 |
| medium | 日常のコーディング：定型的な機能追加、素直な修正 |
| high | 本当に難しい問題：厄介なデバッグ、複数ファイルにまたがるリファクタリング、設計の検討 |
| xhigh | 最も難しい判断を要する作業：アーキテクチャの意思決定、敵対的検証、「絶対に間違えられない」場面 |
重要な変化はここにあります。品質対コストは、かつては選んだモデルの属性でした。いまはあなたが握るダイヤルであり、セッション単位で——そして後述するように、個々のサブエージェント単位で——調整できるのです。
Ultracode：xhigh に常時オーケストレーションを加えたもの
xhigh の上には特別な最上位設定があります。ultracode = xhigh の effort + 動的なワークフローオーケストレーションです。
この後半の要素こそが、程度の違いではなく種類の違いを生みます。ultracode をオンにすると、Claude Code は次のように指示されます。
- 最速でも最安でもなく、最も網羅的で正確な回答に最適化する
- 求められたときだけでなく、あらゆる実質的なタスクでマルチエージェントの Workflow オーケストレーションを使う
- トークンコストを明示的に制約ではないものとして扱う
実際には、「この diff をレビューして」といったタスクが、1 つのエージェントがファイルを読むだけの作業ではなくなり、スクリプト化された Workflow になります。変更全体に並列のファインダー（探索役）がファンアウトし、スケプティック（懐疑役）エージェントが各発見の反証を試み、生き残ったものを統合ステージが組み立てる。ワークフローは数十のエージェントを生成し、大量のトークンを消費し得ます——ultracode がオプトイン方式である理由はまさにここにあります。ハーネスは、この規模を明示的に要求するようあなたに求めます。あなたに代わって黙ってワークフロー規模のトークン請求を燃やすことは決してありません。
オプトインの方法
ultracode 自体には 2 つの有効化パスがあります。
-
キーワード。 プロンプトに「ultracode」を含めると、その場限りのオプトインになります。
ultracode: audit the payments module for correctness bugsこのターンだけがフルスケールで実行されます。次のターンは通常に戻ります。
-
セッショントグル。
/effortから ultracode を選ぶと、恒常的なオプトインになります——ダイヤルを下げるまで、セッション内のあらゆる実質的なタスクがこの扱いを受けます。
一段引いて見ると、ワークフローオーケストレーション全般には 3 つ目の扉もあります。ワークフローは、明示的に依頼したとき（「ワークフローを使って…」）や、呼び出したスキルがそれを指示したときにも実行されます。これらのオプトイン——ultracode、明示的な依頼、スキル——のいずれもなければ、Claude Code は個別のサブエージェントか単独作業をデフォルトとします。大規模なオーケストレーションは、常にあなたが自ら求めたものなのです。
トークン予算：「+500k」とハードシーリング
「トークンコストは制約ではない」という言葉は、その対抗策であるトークン予算ディレクティブを知るまでは不穏に聞こえます。プロンプトに目標値を直接書いてください。
ultracode +500k: find every place our API contract and the
OpenAPI spec disagreeこの +500k はそのターンにトークン目標を与えます。しかも単なる提案ではありません。ワークフロースクリプトの内部では budget オブジェクトとして現れます。
budget.total— 目標値（数値。ディレクティブが与えられなかった場合はnull）budget.spent()— これまでに消費したトークンbudget.remaining()— 残量
重要な性質は 2 つあります。
プールは共有される。 1 つの予算が、メインループとそのターン内のすべてのワークフローをカバーします。ネストしたワークフローに作業を分割しても超過はできません——すべてが同じ口座から引き落とされます。
シーリング（上限）はハード。 spent() が total に達すると、それ以降の agent() 呼び出しは throw します。よくできたワークフローは予算をチェックして優雅に縮退し、素朴なワークフローは実行の途中で死にます。というわけで、コードを見てみましょう。
エージェント単位の Effort：判断が生きる場所に投資する
ワークフロースクリプトの内部では、推論 effort はサブエージェント単位で設定します：effort: 'low' | 'medium' | 'high' | 'xhigh' | 'max'。大規模実行の経済性が実際に決まるのはここです。パターンはこうなります。
- 安価で機械的なステージ（検索、読み取り、整形）→ 低 effort、多くの場合は安価なモデルで
- 難しい検証・判定ステージ → 高い階層
以下は、この 2 つの考え方を組み合わせた予算ガード付きの発見ループです——安価なファインダーが、井戸が涸れるか予算ガードが作動するまで探索を続け、その後、見つかったものすべてに高価なスケプティックを投入します。（ワークフロースクリプトは、name、description、phases を宣言する export const meta = { ... } リテラルで始まります。以下の断片は本体部分です。）
phase('Discover');
let dryRounds = 0;
const seen = [];
while (dryRounds < 2) {
// budget is a HARD ceiling: once spent() reaches total,
// further agent() calls throw. Leave headroom for the
// verify phase instead of running into the wall.
if (budget.total && budget.remaining() < budget.total * 0.2) {
log(`Budget guard: ${budget.spent()} of ${budget.total} spent — moving on`);
break;
}
const round = await parallel([
() => agent(
`Hunt for correctness bugs in the payments module.
Already seen: ${seen.join('; ') || 'none'}.
Report only NEW findings, or the word NONE.`,
{ label: 'hunt-correctness', model: 'haiku', effort: 'low' }
),
() => agent(
`Hunt for error-handling gaps in the payments module.
Already seen: ${seen.join('; ') || 'none'}.
Report only NEW findings, or the word NONE.`,
{ label: 'hunt-errors', model: 'haiku', effort: 'low' }
),
]);
const fresh = round.filter(Boolean).filter(r => !r.trim().startsWith('NONE'));
if (fresh.length === 0) dryRounds += 1;
else { dryRounds = 0; seen.push(...fresh); }
}
phase('Verify');
const verdicts = await parallel(
seen.map(finding => () => agent(
`Try to REFUTE this finding. Confirm only if you cannot:
${finding}`,
{ label: 'skeptic', effort: 'xhigh' }
))
);支出の形に注目してください。何ラウンドも回る可能性のあるループは低 effort の Haiku を使い、xhigh は、誤った判定が実際に高くつく検証ステージのために温存されています。ファインダーには既出の発見が伝えられるので、古い発見を焼き直して売り込むことはありません。そしてループは、空のラウンドが 2 回連続して初めて停止します——effort と ultracode のチュートリアルとその姉妹編（品質パターン）で詳しく扱われている「loop-until-dry」パターンです。
Ultracode を使うべきでない場面
強力なダイヤルの失敗モードは、上げっぱなしにすることです。次の場面では ultracode を避けてください。
- 些細な編集。 リネーム、タイポ修正、設定の微調整に必要なのは 1 つのエージェントと低い effort です。そのためにオーケストレーションされたワークフローを立ち上げるのは純粋な無駄です。
- 会話的なターン。 「この関数は何をする？」「どちらのアプローチが好み？」はコンテキストから答えられます。ファンアウトするものが何もありません。
- 単一の事実の参照。 答えがどのファイルにあるか分かっているなら、直接読むほうがどんな委譲にも勝ります。
- 高速なイテレーションを求めるすべての作業。 ultracode は網羅性と正確性に最適化しますが、それはまだスケッチ段階にいるときの素早いフィードバックループとは正反対のものです。
経験則：ultracode は、見落としが高くつき、探索空間が 1 つのエージェントのコンテキストより大きいタスクのためのものです。それ以外はすべて、通常の effort のほうがうまく——そして劇的に安く——動きます。コスト全体の視点はコスト最適化のチュートリアルを参照してください。
3 つのレシピ
監査。 ultracode +500k: audit the auth module for security issues. これは ultracode のホームグラウンドです。網羅性こそがすべてである、規模不明の発見作業。上のスニペットのような loop-until-dry の形、すべての発見に対する敵対的検証、そして——よくできたワークフローはカバレッジが制限された際に何を落としたかをログに残すため——予算ガードが打ち切ったものについての正直な報告が期待できます。
移行。 ultracode: migrate every deprecated API call in src/ to the new client. ファイルを並列に変更するエージェントには、agent() 呼び出しに isolation: 'worktree' が必要です。各エージェントが新しい git worktree を受け取るので互いを踏み荒らすことがなく、変更がなければ自動的に削除されます。worktree はエージェントごとに実際のセットアップ時間とディスクを消費します——まさに、あのキーワードを打ち込むときにあなたが同意している規模です。
リサーチスイープ。 ultracode: map every place we handle currency rounding, and how. マルチモーダルなスイープ（一斉探索）です。並列エージェントがそれぞれ異なる方法で検索し（ファイルの場所で、内容で、エンティティで、時間で）、その後に「何が欠けている？」と問う網羅性クリティックの回答が次のラウンドの種になります。スイープは低 effort の安価なモデルが担い、最終的な統合には高価な処遇を与えます。
持ち帰るべきこと
Effort レベルは、回答の品質を、モデルに焼き付けられたものからタスク単位で制御できるものへと変えました。ultracode はそのダイヤルの頂点です。xhigh の推論に常時ワークフローオーケストレーションを加えたもので、本気で消費するがゆえに明示的なオプトインの背後にゲートされ、丁寧な注意書きではなくハードシーリングとして強制される予算ディレクティブによって制限されています。
身につける価値のあるスキルは「常に ultracode を使う」ことではありません。自分のタスクのうち、どれがダイヤルを回すに値するタスクなのかを見分けることです。監査、移行、リサーチスイープには「はい」。いま直そうとしているタイポには「いいえ」。
さらに深く知りたい方へ。Effort レベルと Ultracode のチュートリアルでは予算ガード付きループをハンズオンで扱い、Workflow とは何か？では ultracode の土台となるオーケストレーション層を解説しています。