/effort ultracode でワークフローが動き出した瞬間、次の疑問が浮かぶ。「これに自分たちで作った subagent や skill を組み込むにはどうする？」公式の workflows ドキュメントを読んでも、JavaScript script を直接書くための API リファレンスは見つからない——subagent を起動する関数の名前すら載っていない。
だが、直接 API がなくても workflow を制御する正規ルートは公式に4つ用意されている。research preview 段階だから API は安定しないが、その代わりに subagent と skill の既存 frontmatter 機構を経由した間接制御で十分実用的なレベルまで挙動を固定できる。
5月29日に書いた ultracode 記事は「設定」の話だった。本稿はその続編として「workflow の中身——とくに自分たちの subagent と skill を組み込む方法」を整理する。
公式が公開しているもの、していないもの
公式 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 が script を書く」点だ。ユーザーが手で workflow を書くための API リファレンス——subagent を起動する関数名、引数、並列化のプリミティブ——は公開されていない。Anthropic 公式ブログにも sample code は1つも載っておらず、engineering blog の Dynamic Workflows 専用ページも執筆時点では存在しない。
これは「未完成」ではなく 「Claude に書かせる前提で運用する」 という設計判断と読むのが正確だ。私たちユーザーがやるべきは、Claude が書いた script の挙動を 間接的に固定する こと——以下に挙げる4ルートがそのための公式ルートになる。
ルート1：プロンプトで subagent と skill を名指しする（最初の一手）
最も手軽で、最初に試すべき方法。workflow を起動するプロンプトに「この subagent を使え」「この skill を呼べ」と書くだけだ。
Run a workflow to audit every API endpoint under src/routes/ for missing auth checks.
Use the `security-reviewer` subagent for each endpoint and the `report-writer` subagent
to consolidate findings.Claude はこの指示を読み、security-reviewer を各エンドポイントに、report-writer を集約フェーズに割り当てた script を生成する。script の中身は Ctrl+G で editor に開けば確認できる。
最大の利点は 追加準備が要らない こと。.claude/agents/ にカスタム subagent を整備してあれば、その日のうちに workflow に組み込める。逆に欠点は 再現性が弱い こと——同じプロンプトでも Claude が選ぶ subagent が変わる可能性が残る。
ワークフローをとにかく動かしてみたい段階ではルート1で始める。再現性が気になりはじめたら次のルートに移ればいい。
ルート2：subagent frontmatter で挙動を固定する
.claude/agents/ を作り込んでおくと、workflow から呼ばれたときの挙動が 静的に保証 される。これがチーム運用の本命だ。
公式の sub-agents docs（◎）が認めている frontmatter フィールドは多いが、workflow 経由で意味があるのは次のものだ。
| フィールド | workflow 経由での役割 |
|---|---|
name | script から識別される識別子 |
description | Claude がどの subagent を選ぶかの判断材料 |
tools | 利用可能ツールの allowlist |
model | この subagent が呼ばれた瞬間にモデルが確定 |
effort | session の effort を上書き |
isolation: worktree | 別 git worktree で隔離実行 |
mcpServers | この subagent 専用 MCP server |
hooks | ライフサイクル hook |
skills | 起動時に skill 内容を context に preload |
特に model フィールドの効果が大きい。コスト管理を script に委ねず、subagent 側で固定できる。
---
name: heavy-reviewer
description: Reviews architectural decisions and proposes alternatives
model: opus
effort: max
isolation: worktree
tools: [Read, Grep, Glob]
---
あなたはアーキテクチャレビュー専門の subagent です。
コードを読み、設計の選択肢を3つ提示してください。これを .claude/agents/heavy-reviewer.md に置けば、workflow がこの subagent を呼ぶたびに Opus / effort=max / worktree 隔離 で動く。script がどんなロジックを組んでいてもこの設定が優先される。
ルート3：subagent の skills フィールドで skill を preload する
ルート2をさらに踏み込んだ方法。subagent の frontmatter に skills: を書くと、起動時に skill 本文が context に注入される。
公式 sub-agents docs より（◎）。
> Use the skills field to inject skill content into a subagent's context at startup. This gives the subagent domain knowledge without requiring it to discover and load skills during execution.
例えば API 実装専門 subagent に、社内コーディング規約 skill とエラーハンドリング skill を読ませる。
---
name: api-developer
description: Implement API endpoints following team conventions
model: sonnet
skills:
- api-conventions
- error-handling-patterns
---
Implement API endpoints. Follow the conventions and patterns from the preloaded skills.workflow が api-developer を spawn するたび、2つの skill が 自動で context に展開 される。workflow から skill を直接 invoke する API がない以上、subagent を経由させるのが今の正解になる。
なお公式は注記している（◎）。
> This field controls which skills are preloaded, not which skills the subagent can access: without it, the subagent can still discover and invoke project, user, and plugin skills through the Skill tool during execution.
preload は最適化であって access 制限ではない。subagent は実行中も Skill tool 経由で他の skill を呼べる。
ルート4：skill 側で context: fork を使い subagent を逆に起動する
ルート3が「subagent → skill」だったのに対し、これは「skill → subagent」の逆方向。skill 側に context: fork と agent: を書くと、その skill を呼んだとき自動で指定の subagent が spawn され、SKILL.md 本文がその subagent への task として実行される。
公式 skills docs より（◎）。
> Add context: fork to your frontmatter when you want a skill to run in isolation. The skill content becomes the prompt that drives the subagent.
例:
---
name: deep-research
description: Research a topic thoroughly in an isolated agent
context: fork
agent: Explore
---
Research $ARGUMENTS thoroughly:
1. Find relevant files using Glob and Grep
2. Read and analyze the code
3. Return a structured summaryworkflow が deep-research skill を呼ぶよう Claude に書かせれば、結果として裏で Explore subagent が動く。skill 単体としても使えるし、workflow に組み込んでも使える。
ルート3とルート4は方向が逆だが両立できる。subagent が skill を preload して、その skill 自体が context: fork で別の subagent を spawn する——という連鎖も理屈上は可能だが、次節で説明する「subagent はネスト不可」の制約が壁になる。
workflow を使う前に確認しておきたい制約
ここは薄く書けない。事故防止のため強めに警告する。
制約1：workflow 内 subagent は acceptEdits 強制
公式 workflows docs より（◎）。
> 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.
session を plan mode にしていても、subagent frontmatter で permissionMode: plan と書いても、workflow から spawn された subagent は 常に acceptEdits で動く。ファイル編集は自動承認になる。
実務的な事前準備:
.claude/settings.jsonのpermissions.allowを絞る- subagent frontmatter の
toolsで利用ツールを最小化 isolation: worktreeで書き込み先を切り離す
これらを workflow 起動前に整えておかないと、Claude が書いた script が想定外の範囲に手を入れる。
制約2：subagent は subagent を spawn できない
公式 sub-agents docs より（◎）。
> Subagents cannot spawn other subagents.
workflow から subagent への delegation は OK。だが subagent からさらに subagent を spawn することはできない。深いネストを想定した script を書いても runtime が拒否する。
複雑な階層が必要な場合は、workflow script 側で「phase 1: subagent 群 A、phase 2: subagent 群 B」のように分解する。深いネストは不要で、フェーズを分けるだけで済む。
起動経路と script の確認
公式が用意している起動経路は実質3つ（◎）。
- bundled の
/deep-research——Web search を fan-out して cited report を返す唯一の組み込み workflow workflowキーワード単発 ——プロンプトにworkflowという単語を含めれば、Claude が highlight して script 生成。誤発火はAlt+Wで無視/effort ultracodeセッション ——substantive task と判定されるたびに自動で workflow が組まれる（ultracode 記事参照）
起動時の approval プロンプトで View raw script を選べば、Claude が書いた script を読める。さらに Ctrl+G を押すと editor で開いて編集できる。私の運用では 必ず一度 Ctrl+G で開いて確認 している。書かれた指示が想定どおりに subagent を呼んでいるか、Skill tool が必要なのに tools から外れていないか、ここで確認できる。
気に入った run は /workflows ビューで s キーを押せば script を保存できる。保存先は .claude/workflows/（プロジェクト共有）か ~/.claude/workflows/（個人）。以後は / コマンドで再実行できる。
組織レベルで止める手段
Dynamic Workflows と ultracode はパッケージとして扱われる。組織方針で並列1,000エージェントの実行を許可しないなら、以下のいずれかで切る（◎）。
/configで「Dynamic workflows」を OFF~/.claude/settings.jsonに"disableWorkflows": true- 環境変数
CLAUDE_CODE_DISABLE_WORKFLOWS=1 - managed settings の
"disableWorkflows": true - Claude Code admin settings で組織配布
無効化すると bundled /deep-research も使えなくなり、workflow キーワードも反応しなくなり、ultracode が /effort メニューから消える。
まとめ
workflow に自分たちの subagent や skill を組み込む入口はルート1だ。プロンプトで名指しするだけで動く。チームで運用するなら subagent frontmatter を整備するルート2に移行する。skill との連携が出てきた段階でルート3・4を足せばいい。
Anthropic 公式ブログには Klarna の dead code 検出、CyberAgent の single subagent と agent team のギャップを埋める用途、Bun の作者 Jarred Sumner による Zig→Rust 書き換え（750,000 行を 11 日で merge、99.8% テスト通過）が紹介されている（◯）。ただしこれらはいずれも workflow 全体の事例であり、特定の subagent 構成や ultracode 単独によるベンチマークではない点には注意してほしい。
次に /effort ultracode を有効にする前に、自分のチームの subagent 群を /agents で一度眺めてみてほしい。description が薄い subagent、model や effort が未指定の subagent があれば、それが workflow に組み込んだときの再現性を左右する。本記事の4ルートはどれも、その下準備があってはじめて意味を持つ。
コメント