/effort メニューを開いたことのある人なら、low から max まで5段階のスケールを目にしたことがあるはずだ。5月19日公開のeffort 解説記事でも整理したとおり、xhigh と max が高負荷タスク向けの選択肢として並んでいた。
2026年5月28日、そのメニューに新しい項目が加わった。ultracode だ。ただし、これを「effort スケールのもう1段上」として理解すると、すぐに壁にぶつかる。API から --effort ultracode を渡しても無効であることがその代表例だ。
ultracode は effort レベルではなく、Claude Code 固有の設定だ。内部では xhigh effort を送りつつ、セッション中に最大 1,000 のエージェントを自動オーケストレーションする仕組みを有効にする。この記事では、公式ドキュメントをもとに定義・使い所・切りどき・組織制御までを整理する。
ultracode は effort スケールに含まれない
公式の model-config ドキュメントは次のように明示している（◎）。
> The /effort menu also offers ultracode. Ultracode is a Claude Code setting rather than a model effort level: it sends xhigh to the model and additionally has Claude orchestrate dynamic workflows for substantive tasks. It applies to the current session only. Set it through /effort, or pass "ultracode": true via --settings or an Agent SDK control request. It is not part of the effortLevel setting, the --effort flag, or CLAUDE_CODE_EFFORT_LEVEL.
「Claude Code setting」と「model effort level」は別物だ。API ドキュメントも同じ方向で補足している（◎）。
> Ultracode appears in Claude Code's effort menu, but it is not an additional API effort level. The values documented on this page are the complete set the API accepts.
つまり API が受け付ける effort 値は low / medium / high / xhigh / max の5種類のままで、ultracode はそこに加わらない。
ここから実務翻訳に踏み込む。CI パイプラインから claude コマンドを呼んでいる場合、--effort ultracode は無効だ。ultracode を有効にするには --settings '{"ultracode":true}' を渡すか、Agent SDK の control request に "ultracode": true を含める必要がある。effortLevel 設定変数や CLAUDE_CODE_EFFORT_LEVEL 環境変数に ultracode を書いても何も起きない。この区別は実装時に必ず確認してほしい。
また、ultracode が /effort メニューに表示されるのは xhigh をサポートするモデルのみだ。現時点では Opus 4.8 と Opus 4.7 に限られる。Opus 4.6 や Sonnet 4.6 を使っているセッションでは選択肢に現れない。
ultracode の実体：xhigh + dynamic workflow の2軸
ultracode を /effort で選択すると、Claude Code 側で2つのことが起きる。
1つ目は、モデルへの推論リクエストに xhigh effort が渡されること。これは単体でも選択できる effort 値だ。
2つ目が ultracode 固有の挙動だ。Claude が各タスクを「substantive task（ワークフローを立ち上げるに値する重要な作業）か否か」で判定し、該当すると判断した場合に自動で dynamic workflow を組む。公式は「Mid-conversation system messages 経由で Claude に workflow を投入する裁量を渡す」と説明している（◎）。
動作のイメージは次のようなものだ。ユーザーが「codebase 全体のバグを洗い出して修正してほしい」とリクエストすると、ultracode は1リクエストを3つの workflow に分解することがある。「コードを理解する workflow」「変更を加える workflow」「変更を検証する workflow」の連鎖だ。
dynamic workflow とは何か
この仕組みを正確に理解しておく必要がある。公式の workflows ドキュメントはこう定義している（◎）。
> A dynamic workflow is a JavaScript script that orchestrates subagents at scale. Claude writes the script for the task you describe, and a runtime executes it in the background while your session stays responsive.
ポイントは「Claude がそのスクリプトを書く」点だ。ユーザーがスクリプトを書くわけではない。Claude がタスクを受け取り、JavaScript のオーケストレーションスクリプトを自動生成し、runtime がそれを背景で実行する。
中間結果はスクリプト変数に留まり、Claude の context window には乗らない。最終的な回答だけが返ってくる。これにより context window の上限を超えた規模の処理を進められる。
規模感として、1 run あたり最大 1,000 エージェントが上限として設定されている（◎）。同時並列は最大 16 エージェントで、CPU コアの少ない機器ではさらに制限される。公式が例示するユースケースは次のようなものだ。
- codebase 全体のバグ検索と修正
- 500 ファイルの一括マイグレーション
- 複数ソースをクロスチェックするリサーチ
- 1つのハードな計画を複数の独立した角度からドラフトして比較する
Anthropic の公式ブログでは、Bun の作者 Jarred Sumner が dynamic workflows を使って Bun の Zig コードを Rust に書き換えた事例が紹介されている（◯）。750,000 行の Rust コードを 11 日（初回コミットからマージまで）で処理し、99.8% のテスト通過率を達成したとされる。ただし、これは ultracode 単体によるベンチマークではなく、dynamic workflow を活用した外部事例として紹介されているものだ。ultracode の性能指標として読まないよう注意が必要だ。
permission モードと ultracode の危険な組み合わせ
ここは薄く書けない部分だ。ultracode を使う前に必ず理解してほしい。
Auto Mode と ultracode を組み合わせたとき、workflow の approval（承認プロンプト）は「人間に確認なし」で連発される。公式の比較表を引用する（◎）。
| Permission mode | プロンプトが出るタイミング |
|---|---|
| Default / acceptEdits | 毎回（"Yes, and don't ask again" を選ぶと、そのプロジェクトで以後スキップ） |
| Auto | 初回起動時のみ記録、以後スキップ。ultracode 時は完全スキップ |
bypassPermissions / claude -p / Agent SDK | 出ない、即実行 |
Auto Mode を使っているセッションで ultracode をオンにした場合、workflow が大量の操作を承認なしで進めることになる。1,000 エージェントのスケールと組み合わせれば、意図しない大規模実行が起きるリスクは無視できない。
さらに重要な注記がある（◎）。
> The subagents the workflow spawns always run in acceptEdits mode and inherit your tool allowlist, regardless of your session's mode. File edits are auto-approved.
workflow が spawn する subagent は、セッションの permission mode に関わらず 常に acceptEdits で動く。session を plan mode にしても意味がない。workflow が組まれた瞬間に、subagent はファイル編集を自動承認で進める。
Auto Mode + ultracode の組み合わせ、および plan mode を信頼しての ultracode 使用は、事故の原因になる。本番に近い環境で試す際は bypassPermissions の使用範囲を事前に絞り込んでから実行することを強くすすめる。
コスト構造と使いどきの判断
ultracode のコストは2重構造だ。xhigh effort によるトークン消費の増加（base コスト）に加えて、自動投入される workflow が複数 subagent を並列実行する（base × N エージェント）。公式も一文で警告している（◎）。
> This applies to every task in the session, so each request uses more tokens and takes longer than at lower effort levels.
使いどきの目安を整理する。
ultracode が効果的な場面
- codebase 全体を横断する調査や変更で、Claude 自身がどんな構造になっているか事前に把握しきれないタスク
- 探索・変更・検証の3フェーズを一気に進めたいとき
- single conversation の context window に収まらない大規模調査
ultracode を使わないほうがいい場面
- 1ファイルの修正、テスト1本の追加など、範囲が明確なルーティン作業
- レビュー対応や人間とのやり取りが多いタスク（run 途中でユーザー入力できないため）
- Bedrock 経由で Haiku がリージョン制限でフォールバックする可能性がある環境（コスト爆発のリスク）
ルーティンに戻るとき、公式は「/effort high で戻れ」と明示している（◎）。
workflow キーワード単発という代替手段
セッション全体を ultracode 状態にしたくない場合、別の手がある。プロンプトの中に workflow という単語を入れるだけで、そのターンだけ workflow が起動する。公式の記述を引用する（◎）。
> To run a single task as a workflow without changing the session's effort level, include the word workflow anywhere in your prompt.
「この1回だけ大規模に並列処理したい」という場面では、/effort を変えずにプロンプトに workflow を添えるほうが制御しやすい。誤発火を防ぎたいときは Alt+W で workflow トリガーを無視できる。
利用要件と組織ガバナンス
動く環境
dynamic workflows は research preview 段階だ（◎）。
- 必須バージョン: Claude Code v2.1.154 以上
- 対応プラン: Pro / Max / Team / Enterprise すべて
- 対応インフラ: Anthropic API、Amazon Bedrock、Google Cloud Vertex AI、Microsoft Foundry
5月25日公開の Bedrock vs サブスク記事では、Auto Mode が Anthropic API に限定される点を取り上げた。Dynamic Workflows は Bedrock/Vertex/Foundry でも動く。ただし、xhigh をサポートするモデル（Opus 4.7 / 4.8）が当該プロバイダで使える前提だ。
Pro プランでは追加の操作が必要だ。/config の「Dynamic workflows」行でオンにしないと、ultracode は /effort メニューに現れない。公式ドキュメントに Pro 以外のプランに関する具体的な enable 手順の記載はないが、組織管理者は Claude Code admin settings から有効・無効を制御できる。
組織として無効化する方法
ultracode に起因するリスクを組織レベルで管理するには、次の方法がある。
/configで「Dynamic workflows」をオフ（persistent）~/.claude/settings.jsonに"disableWorkflows": trueを追記- 環境変数
CLAUDE_CODE_DISABLE_WORKFLOWS=1を設定 - managed settings の
"disableWorkflows": true（組織管理者向け） - Claude Code admin settings で管理
公式はこの OFF の効果を明示している（◎）。
> When workflows are disabled, the bundled workflow commands are unavailable, the workflow keyword no longer triggers a run, and ultracode is removed from the /effort menu.
workflows を無効化すると ultracode 自体が /effort メニューから消える。「並列 1,000 エージェントの動作は組織ポリシーとして許可しない」という判断をするなら、managed settings から一括で無効にできる。
まとめ
ultracode を1行で定義し直すなら「xhigh effort と、substantive task への dynamic workflow 自動投入権限を、Claude Code クライアントがセッションに付与する設定」だ。effort スケールの延長ではなく、effort とは別軸で動く Claude Code 固有の機能として理解する。
実務で最初に確認するのは Opus 4.7 / 4.8 を使っているか、v2.1.154 以上か、CI 等から渡す場合は --settings '{"ultracode":true}' の経路を使っているかの3点だ。
そのうえで、Auto Mode との組み合わせと subagent の acceptEdits 強制を把握し、試す環境の scope を意図的に絞る。大規模リファクタリングや codebase 横断の調査から始めるのが、ultracode の特性を体感しやすい入り口になる。
effort スケールの基礎については5月19日公開の effort 解説記事を参照してほしい。本記事はその続編として、5月28日リリースの ultracode と Dynamic Workflows を公式ドキュメントに基づいて整理したものだ。
コメント