
Claude Code に「ultracode」設定が登場——xhigh 推論 + 動的ワークフローで数百並列エージェントを自動指揮、Bun の Zig→Rust port も実証
はじめに
Anthropic は 2026 年 5 月 28 日、Claude Code に ultracode という新設定を投入しました。これは xhigh 推論レベル と 動的ワークフロー(dynamic workflows)自動オーケストレーション を同時に有効化する Claude Code 固有の設定で、/effort メニューから切り替えます。
同時にリリースされた dynamic workflows は、Claude が JavaScript スクリプト を動的に書き、ランタイムが 10〜数百の並列 subagent を背景実行するアーキテクチャです。Jarred Sumner(Bun の作者)はこれを使い、Zig→Rust の port を 11 日で約 75 万行・テストスイート 99.8% パス まで持っていきました。
この記事のポイント
ultracodeは Claude Code v2.1.154+ で利用可能な新設定。/effort ultracodeで xhigh 推論 + 動的ワークフロー自動判断 を ON- 動的ワークフロー本体は research preview。10〜数百の並列 subagent、最大 16 同時実行 / 1,000 agents per run
- 起動は 3 通り: ① プロンプトに
ultracodeキーワード(単発タスク用)、②/effort ultracode(セッション全体)、③/deep-research等の bundled workflow - Max / Team / API は default ON、Pro は
/configから手動 ON、Enterprise は default OFF - workflow 1 run は通常会話よりトークンを大幅に消費。
/workflowsで進捗・コスト確認、pで pause / resume 可能 - agent-skills の
spec-implementの dispatch モード(Codex sub-agents / Claude Code agent team / cmux dispatch / 単独実行)とは別レイヤーの並列化 /goalコマンド(v2.1.139+)は ターン跨ぎ自走、ultracode は ターン内並列、auto mode は tool 承認自動化 で、3 層を組み合わせると大規模 migration が無人で完走可能
ultracode と dynamic workflows は何が新しいのか?
これまで Claude Code には subagents / skills / agent teams という並列化の仕組みがありました。dynamic workflows はこれらと違い、Claude 自身がスクリプトを書いて、ランタイムが実行する 設計です。
公式ドキュメントの比較表を整理するとこうなります。
| Subagents | Skills | Agent teams | Workflows | |
|---|---|---|---|---|
| 実体 | Claude が spawn する worker | Claude が従う instructions | peer session を統括する lead agent | ランタイムが実行する script |
| 次に何を走らせるか決めるのは | Claude(ターンごと) | Claude(prompt 通り) | lead agent | script |
| 中間結果の置き場 | Claude のコンテキスト | 同上 | shared task list | script 変数 |
| 再利用できるもの | worker 定義 | instructions | team 定義 | オーケストレーション自体 |
| スケール | 数個 / ターン | 同上 | 少数の長時間 peer | 数十〜数百 agents / run |
| 中断時の挙動 | ターンが reset | 同上 | teammate は実行継続 | 同セッション内で resume 可能 |
最大の差は 「計画がコードに移る」 こと。Claude のコンテキストには最終回答だけが返り、loop / branching / 中間結果は script 側に隔離されます。これにより同じパターンを反復実行できるようになり、複数 agent による独立検証(adversarial review)が組み込めるようになりました。
ultracode 設定は、この dynamic workflows を Claude が「いつ使うか」自動判断するモード を ON にし、同時に推論レベルを xhigh に引き上げます。
3 つの起動方法
① プロンプトに ultracode キーワード(単発タスク用)
プロンプトに ultracode キーワードを含めると、その 1 タスクだけが workflow として実行されます。
ultracode: audit every API endpoint under src/routes/ for missing auth checks「use a workflow」などの自然言語要求でも同じ扱いになります(v2.1.160 より前のリテラルトリガーは workflow でした)。
Claude Code は入力欄でキーワードを highlight します。誤検知を解除したい場合は Option+W (macOS) / Alt+W (Win/Linux)、または backspace で取り消し。完全にトリガーをオフにするなら /config の「Ultracode keyword trigger」をオフに。
② /effort ultracode(セッション全体)
/effort ultracodeセッション全体で xhigh reasoning effort + 自動ワークフロー判断 が ON になります。Claude が各タスクで「workflow を起こすか」を勝手に判断し、1 リクエストが「コード理解 → 変更 → 検証」の 複数 workflow に分かれる こともあります。
セッション限り有効。新セッションでリセット。/effort high などで元に戻せます。xhigh effort をサポートするモデルでのみ表示されます。
③ bundled workflow(既存スクリプト実行)
例: /deep-research は research preview に同梱されている web 検索 + cross-check ワークフローです。
/deep-research What changed in the Node.js permission model between v20 and v22?保存した workflow も /<name> で同様に呼び出せます。
dynamic workflow の中身(ランタイムと制限)
ランタイムはスクリプトを isolated 環境 で実行し、中間結果は Claude のコンテキストではなく script 変数 に置きます。各 run のスクリプトは ~/.claude/projects/ 配下のセッションディレクトリにファイルとして書かれるので、後から開いて読んだり、編集して relaunch することも可能です。
主な挙動と制限
| 制約 | 理由 |
|---|---|
| 実行中のユーザー入力は受け取らない(permission prompts のみ pause 可能) | 段階間の sign-off が必要なら、各段階を別 workflow に |
| workflow 自身は filesystem / shell を直接触らない | agent が読み書き・コマンド実行、script は agent を coordinate |
| 最大 16 並列 agent(CPU コアが少ない環境ではより少ない) | ローカルリソースの上限 |
| 1 run あたり 1,000 agents まで | runaway loop の防止 |
進捗は /workflows ビューで phase ごとの agent 数・トークン総計・経過時間を確認可能。p で pause / resume、x で stop、r で agent restart、s でその run のスクリプトをコマンドとして保存できます。
承認モード
| Permission mode | 確認のタイミング |
|---|---|
| Default, accept edits | 毎回("Yes, and don't ask again" を選んだプロジェクトはスキップ) |
| Auto | 初回のみ。ultracode 有効時は完全スキップ |
Bypass permissions, claude -p, Agent SDK | 確認なし |
承認モードは launch prompt のみ制御し、workflow が spawn する subagent は常に acceptEdits モードで動作 します。
公式事例: Klarna / CyberAgent / Bun
公式ブログに 3 つの大型事例が紹介されています。
Klarna(Senior Engineering Manager: Alessio Vallero)
「dynamic workflows は大規模 codebase の discovery と review タスクで特に価値があった。従来の static analysis では拾えなかった dead code を検出 し、cleanup の機会を表面化させて、エンジニアの保守・refactoring を加速させた」
CyberAgent(Lead Systems Engineer: Ken Takao)
「dynamic workflows は 「単一 subagent を投げる」と「フル agent team を組む」の間 を埋めてくれる。plan→implementation がそのまま流れるので、可視性を失わずに長時間 run を信頼できる」
Bun の Zig → Rust port(Jarred Sumner)
| 項目 | 数値 |
|---|---|
| port 言語 | Zig → Rust |
| 期間 | first commit から merge まで 11 日 |
| 規模 | 約 75 万行の Rust |
| テストパス | 既存テストスイートの 99.8% |
複数の workflow を連携させた構成です。① Zig の各 struct フィールドに対する正しい Rust lifetime を mapping → ② 各 .zig の振る舞いと等価な .rs を 数百の agent が並列に、各ファイル 2 reviewer 付き で port → ③ fix loop で build と test suite を clean に → ④ 夜間 workflow で不要なデータコピー削減と各修正の PR 作成。本番投入はまだですが、すべて dynamic workflows で処理されています。
/goal コマンドとの関係——「ターン跨ぎ自走」と「ターン内並列」は別軸
Claude Code には /goal(v2.1.139+)という似た目的のコマンドがあり、よく ultracode と混同されます。実際は 抽象度が違う ので、併用前提で設計するのが正解です。
/goal は 完了条件付きの自走ループ です。「all tests in test/auth pass and the lint step is clean」のような自然言語の condition を渡すと、Claude がターンを跨いでその条件が満たされるまで動き続けます。各ターン終了後に 小さな高速モデル(デフォルト Haiku) が条件を評価し、未達なら次のターンが自動的に始まります。実装としては session-scoped な prompt-based Stop hook のラッパー です。
公式ドキュメントの比較表を整理するとこうなります。
| 機能 | 次のターンが始まるトリガー | 止まる条件 |
|---|---|---|
/goal | 前のターンが終わったとき | モデルが条件達成を確認 |
/loop | 一定の時間間隔 | ユーザー停止、または Claude が done と判断 |
| Stop hook | 前のターンが終わったとき | 自前のスクリプトまたはプロンプトが判断 |
ultracode + auto mode | (単一ターン内で workflow が走る) | workflow が終わる |
ultracode と /goal は別軸、併用がおすすめ
両者は competing ではなくレイヤーが違う 設計です。
/goal: セッション全体で ターン跨ぎの自走 を管理(横軸)ultracode: 各ターン内で 数十〜数百 agent の並列実行 を判断(縦軸)- auto mode: 単一ターン内の tool call 承認 を自動化
3 つを組み合わせると、3 層の自動化 が成立します。
# 大規模 migration を auto + ultracode + /goal で自走させる例
/effort ultracode
/goal すべての test/api/ 配下のテストがパスし、npm run typecheck が exit 0 を返すまで
# auto mode は permission モードで設定済みの想定これで「auto mode で tool 承認を自動」「ultracode で 1 ターン内が workflow なら数百 agent 並列」「/goal で目標達成までターン跨ぎで自走」が同時に効きます。Auto モードで ultracode が有効な場合、workflow 起動確認 prompt はスキップされます。/goal と併用すると、そのまま次ターンの自走にもつながります(skip の直接条件は Auto + ultracode、/goal は別レイヤー)。
トークン消費はこれら 3 つを組み合わせると大幅に増えやすいので、小さい slice で先に試す ことを公式も推奨しています。
/goal の効果的な条件の書き方
評価者(Haiku 等)は Claude が会話で surface した内容しか見られない(ツールを呼ばない)ので、「Claude が結果を会話に出すまで実行する」よう condition を書くのがコツです。
- 1 つの measurable end state: テスト結果、build exit code、ファイル数、空のキュー
- stated check: どう証明するか(例:
npm testexits 0、git statusis clean) - 制約事項: 途中で変えてはいけない条件(例: 「他のテストファイルは変更しない」)
- ターン / 時間境界:
or stop after 20 turnsのような節で暴走を防ぐ - 最大 4,000 文字
/goal の使い方
# Set
/goal all tests in test/auth pass and the lint step is clean
# Check(引数なし)
/goal
# Clear
/goal clear # aliases: stop, off, reset, none, cancel
# Non-interactive モード
claude -p "/goal CHANGELOG.md has an entry for every PR merged this week"セッション終了時の active goal は --resume / --continue で復元されますが、turn count / timer / token baseline はリセット されます。Achieved or cleared な goal は復元されません。
注意点として、/goal は workspace で trust dialog 承諾済み であることが必要です(評価者が hooks の一部として動くため)。disableAllHooks が設定されている環境や、managed settings で allowManagedHooksOnly がオンの環境では使えません。
agent-skills の spec-implement との関係
ZenChAIne の連載「実践!仕様書駆動開発」で扱った spec-implement も、4 つの dispatch モード(Codex sub-agents / Claude Code agent team / cmux dispatch / 単独実行)でワーカースキルを並列実行する仕組みを持っています。
両者は競合ではなく、抽象度の異なるレイヤー です。
| レイヤー | 役割 | 並列度 |
|---|---|---|
| spec-implement の dispatch | spec-code / spec-review / spec-test の role 分業を エージェント runtime(Codex / Claude Code / cmux)にマップ | 数役(implementer / reviewer / tester) |
| dynamic workflows | Claude Code 内で JavaScript script + agent runtime が数十〜数百の agent を統括 | 数十〜数百 |
実用的には次のような組み合わせが考えられます。
- spec-implement の Phase 6 Task Loop で
ultracodeを ON にしておけば、各[code]タスクの実装中に Claude が「これは workflow 化したほうが速い」と判断したら自動で並列化 - 大規模 migration の場合、
spec-implement --issue {N}を起動してから/effort ultracodeで workflow オーケストレーションも併用
ただし dynamic workflows は トークン消費が大きい ので、spec-implement のように workflow に書き起こせる粒度のオーケストレーションは、spec-implement 側でやったほうが追跡可能性が高いケースもあります。両方の選択肢を理解した上で使い分けるのが現実的です。
使用コストと無効化
コスト
workflow 1 run は通常の Claude Code セッションと比べて 大幅にトークンを消費 します。理由は単純で、agent 数が桁違いに増えるからです。
公式ドキュメントが推奨するコスト管理は次のとおりです。
- 小さな slice で試す: repo 全体ではなく 1 ディレクトリ、広い質問ではなく狭い質問
/workflowsで agent ごとのトークン使用量を確認、必要ならxで stop(完了済みの work はキャッシュ)- agent 上限 16 並列 / 1,000 agents が暴走を防ぐ
- モデル選択: workflow 内の各 agent はセッションのモデルを使う(script で stage 別に変更可能)
- ルーチン作業に小さなモデルを使っている場合、大きな run の前に
/modelを確認
usage / rate limit に通常通りカウントされます。
無効化
| 方法 | 効果 |
|---|---|
/config で Dynamic workflows をオフ | セッション横断で永続 |
~/.claude/settings.json に "disableWorkflows": true | 永続 |
CLAUDE_CODE_DISABLE_WORKFLOWS=1 環境変数 | 起動時に読まれる |
組織全体: managed settings の "disableWorkflows": true | 組織ポリシー |
無効化すると bundled workflow も使えなくなり、ultracode キーワードトリガーも消え、/effort メニューから ultracode の選択肢も消えます。
よくある質問
Q. ultracode と xhigh 推論は同じものですか?
A. 違います。xhigh は推論 effort のレベルで、ultracode は 「xhigh + 動的ワークフロー自動判断」 を組み合わせた Claude Code 固有の設定です。ultracode は xhigh をサポートするモデルでのみ /effort メニューに表示されます。
Q. ワークフローを書く必要がありますか?
A. ありません。Claude が prompt に応じてスクリプトを動的に生成 します。書かれたスクリプトは ~/.claude/projects/ 配下のセッションディレクトリに保存されるので、後から読んだり編集してから relaunch することも可能です。気に入った run は /workflows で s キーを押せば .claude/workflows/ または ~/.claude/workflows/ に保存され、/<name> で再利用できます。
Q. 全プランで使えますか?
A. 全有料プランで利用可能ですが、デフォルトの ON/OFF は異なります。Max / Team / API は default ON、Pro は /config から手動 ON、Enterprise は admin が有効化 する必要があります。
Q. 既存の /security-review や agent-skills の spec-implement と置き換えるべきですか?
A. 必ずしもそうではありません。dynamic workflows は 10〜数百 agent の超並列向け で、トークン消費も大きいです。spec-implement のような spec → 実装 → review → test の 役割分業オーケストレーション は、追跡可能性とコスト効率の面で従来手法のほうが向く場合があります。両方知った上で、タスクの大きさで使い分けるのが現実的です。
Q. workflow 実行中に途中で中断したら?
A. 同じセッション内であれば resume できます。完了済みの agent はキャッシュ結果を返し、残りは live で実行されます。/workflows で select して p を押すか、Claude に「同じスクリプトで再起動して」と頼めば OK。Claude Code セッションを抜けると次回起動時には fresh start になる点だけ注意です。
Q. PR / production にいきなり影響しますか?
A. しません。workflow が spawn する subagent は常に acceptEdits モードですが、launch 時の確認プロンプトを通過する必要があります(Auto モードや bypass permissions、claude -p を除く)。最初の launch では計画されたフェーズが提示され、Yes / No / View raw script を選べます。
まとめ
ultracode 設定と dynamic workflows は、Claude Code の並列化を「Claude が turn-by-turn 計画する」から「スクリプトが実行する」に切り替える 大きな転換点です。subagent / skill / agent team が「Claude のコンテキスト内で並列化」だったのに対し、workflows は コンテキスト外のランタイムで数百 agent をスケール します。
Bun の Zig→Rust port が 11 日で約 75 万行を捌いたという数字は、AI による大規模 codebase migration の現実味を一段引き上げました。一方で、トークン消費は重く、すべてのタスクが workflow 向きなわけではありません。ZenChAIne では、本連載で扱った agent-skills の spec-implement のような 役割分業オーケストレーション と、ultracode の 超並列スケール を、タスクの規模に応じて使い分ける運用を組み立てています。
/plugin install などの操作も不要で、Claude Code v2.1.154+ + 対応プラン であれば /effort ultracode か /deep-research で今すぐ 試せます。
参考ソース
- Introducing dynamic workflows in Claude Code - Anthropic Blog (2026-05-28)
- Orchestrate subagents at scale with dynamic workflows - Claude Code Docs
- Keep Claude working toward a goal (
/goal) - Claude Code Docs - Claude Code settings - 公式 docs
- Model config / effort levels - 公式 docs
- 実践!仕様書駆動開発 ③実装編 - ZenChAIne
- Anthropic releases Claude Opus 4.8 with dynamic workflows - Releasebot
- Claude Opus 4.8: Benchmarks, Effort & Dynamic Workflows - Digital Applied