Claude Code に Dynamic Workflows という機能がある。サブエージェントを何十体も並列で走らせて、コードベース全体の監査とかフレームワーク移行みたいな重い作業を自動でやってくれるやつだ。
で、ふと思った。Codex CLI にも同じようなのあるの？
調べようと思ったけど、どうせならこの Workflow 機能自体を使って調べてみるか、ということで 5 エージェント並列の調査ワークフローを書いて回してみた。この記事はその結果をまとめたもの。
先に結論
完全な同等機能は Codex CLI にはない。
ただし「マルチエージェント v2」で最大 8 並列のサブエージェントは走る。Symphony という外部オーケストレーション仕様もある。「全くできない」わけじゃないけど、根本のアーキテクチャが違うので同じ体験にはならない。
この先で、何が違うのか・何ならできるのかを具体的に書いていく。
そもそも Dynamic Workflows って何
2026 年 5 月 28 日、Opus 4.8 と同時に出たリサーチプレビュー機能。
ひとことで言うと、「オーケストレーションのロジックを JavaScript で書いて、サブエージェントの並列実行を制御する仕組み」。
従来のやり方だと、Claude がターンごとに「次は何する？」って判断して、中間結果が全部コンテキストウィンドウに積まれていく。10 ファイルくらいならいいけど、100 ファイル超えるとコンテキストが溢れて精度がガタ落ちする。
Workflows はこの問題を「計画をコードに移す」ことで解決した。ループ、分岐、中間結果はスクリプトの変数に持つ。Claude のコンテキストには最終結果だけ返る。これで 1000 エージェントまでスケールできる。
コアになる関数は 4 つ
| 関数 | やること |
|---|---|
agent(prompt, opts) |
サブエージェントを 1 体生成。schema で構造化出力を強制できる |
parallel(thunks) |
全部終わるまで待つバリア。最大 16 並列 |
pipeline(items, ...stages) |
ステージ間バリアなしのストリーム処理。こっちがデフォルト推奨 |
workflow(name, args) |
別の保存済みワークフローを呼ぶ（1 階層まで） |
TypeScript は使えない。純粋な JavaScript のみ。Date.now() や Math.random() もダメ（レジューム機能のための制約）。
今回書いた調査ワークフロー
こんなスクリプトを書いた。
export const meta = {
name: 'codex-workflow-research',
description: 'Codex CLIにworkflow相当機能があるか調査',
phases: [
{ title: 'Claude Code Workflow調査' },
{ title: 'Codex CLI調査' },
{ title: '統合分析' },
],
}
// フェーズ1: Claude Code側を2エージェント並列で調査
phase('Claude Code Workflow調査')
const [docs, examples] = await parallel([
() => agent('Workflow機能のドキュメント・仕組みを調査', {
label: 'workflow-docs', schema: DOCS_SCHEMA
}),
() => agent('実際のスクリプト例と使用事例を調査', {
label: 'workflow-examples', schema: EXAMPLES_SCHEMA
})
])
// フェーズ2: Codex側も2エージェント並列
phase('Codex CLI調査')
const [features, roadmap] = await parallel([
() => agent('Codexのマルチエージェント・ワークフロー機能を調査', {
label: 'codex-features', schema: FEATURES_SCHEMA
}),
() => agent('最新動向・ロードマップ・GitHub Issueを調査', {
label: 'codex-roadmap', schema: ROADMAP_SCHEMA
})
])
// フェーズ3: 全結果を1エージェントに渡して統合分析
phase('統合分析')
const synthesis = await agent(
`以下の調査結果を統合して比較分析:\n${JSON.stringify({docs, examples, features, roadmap})}`,
{ label: 'synthesis', schema: SYNTHESIS_SCHEMA }
)
return synthesis
（実際はスキーマ定義がもっと長いけど省略）
5 エージェントが約 15 分で完了。各エージェントがそれぞれ Web 検索して、合計 30 万トークンくらい使った。1 エージェントあたり 6 万トークン。結構食う。
Codex CLI のマルチエージェント機能
調査してわかったのは、Codex CLI にもマルチエージェントはあるということ。2026 年 3 月に GA になっている。
# config.toml
[agents]
max_threads = 6 # 同時実行数（デフォルト6、最大8）
max_depth = 1 # ネスト深度（再帰fan-out防止）
job_max_runtime_seconds = 1800
ビルトインで default（汎用）、worker（実装特化）、explorer（読み取り特化）の 3 種類のエージェントがいて、TOML ファイルでカスタムエージェントも定義できる。
自然言語で「各レビュー観点ごとにエージェントをスポーンして、全部終わったら要約して」みたいに指示すると、Codex が勝手に分割・並列実行・統合をやってくれる。
ここまではそこそこ似てる。 じゃあ何が違うのか。
根本的に違うところ
「コード」か「お願い」か
これが一番デカい違い。
Claude Code の Workflow は JavaScript でオーケストレーションを書く。for 文で回す、if で分岐する、変数に中間結果を貯める——プログラミング言語の表現力がそのまま使える。
// 2ラウンド連続で新規発見ゼロなら終了
while (dry < 2) {
const found = await parallel(FINDERS.map(f => () =>
agent(f.prompt, { schema: BUGS })))
const fresh = found.filter(Boolean)
.flatMap(r => r.bugs)
.filter(b => !seen.has(key(b)))
if (!fresh.length) { dry++; continue }
// ...検証ロジックが続く
}
Codex のマルチエージェントは 自然言語で「お願い」する。GPT が「ここは分割したほうがいいな」と判断してサブエージェントをスポーンする。制御はモデル任せ。
どっちがいいかは場面による。でも「このループを必ず 3 回以上回して、各ラウンドで重複除去して、2 ラウンド連続ゼロなら止める」みたいな精密な制御は、コードじゃないとできない。プロンプトで伝えても「まぁ十分見つけたし終わりでいいか」ってモデルが判断しちゃう可能性がある。
コンテキストの使い方
Claude Code: 中間結果はスクリプト変数に持つ。コンテキストに入るのは最終 return 値だけ。
Codex: 親エージェントのコンテキストにサブエージェントの結果が蓄積される。
10 エージェントくらいならどっちも問題ない。100 エージェントだと Codex 側はコンテキストがきつくなる。Claude Code は 1000 エージェントまでいける（理論上）。
品質検証パターン
ここが個人的に一番面白かった。
Claude Code の Workflow には Adversarial Verify というパターンがある。バグや脆弱性を見つけたら、別のエージェント 3 体に「これ本当にバグ？反証してみて」と投げる。過半数が「いや、これはバグじゃない」って言ったら除外する。
const votes = await parallel(Array.from({length: 3}, () => () =>
agent(`反証してみろ: ${claim}`, { schema: VERDICT })))
const survives = votes.filter(Boolean)
.filter(v => !v.refuted).length >= 2
これがコードとして確実に実行されるのがポイント。Codex でも「検証してください」ってプロンプトに書けるけど、モデルが「まぁ大丈夫でしょ」ってスキップするリスクがある。
Codex が勝ってるところもある
公平に書かないとフェアじゃないので。
/goal: セッションをまたぐ永続化
Claude Code の Workflow はセッション内限定。Claude Code を閉じたら途中結果は消える。
Codex の /goal 機能（v0.128.0〜）はセッション間で永続化される。18 時間放置して 14/18 の機能を一人で実装した、っていう事例もある。これはすごい。
クラウド実行
Claude Code は完全にローカル。マシンの電源切ったら終わり。
Codex App はクラウドの分離コンテナで動く。リモートコントロールもできる（スマホから QR ペアリング）。
Symphony: イシュートラッカー連携
OpenAI が 2026 年 4 月に出したオープンソース仕様。Linear みたいなイシュートラッカーをコントロールプレーンにして、複数の Codex エージェントを協調させる。GitHub Stars 15K 超え。社内で PR ランディング率 500% 向上って報告もある（ほんとかよ）。
Claude Code にはこういう外部システム連携の仕組みが今のところない。
機能比較表
| Claude Code | Codex CLI | |
|---|---|---|
| オーケストレーション | JS コードで制御 | 自然言語で指示 |
| 並列数 | 最大 16、1 ラン 1000 | 最大 8 |
| パイプライン |
pipeline() バリアなし |
なし |
| 構造化出力 | schema オプション | --output-schema（バグあり） |
| 品質検証 | コードで確実実行 | プロンプト頼み |
| レジューム | セッション内のみ | セッション間で永続 |
| クラウド実行 | なし | Codex App |
| Issue 連携 | なし | Symphony |
| 保存・共有 |
.claude/workflows/ に JS |
Skills（手順書。制御フローなし） |
使い分けの方針
雑にまとめると:
- コードベース全体の監査、大規模マイグレーション、100 ファイル超えの一括処理 → Claude Code Workflows 一択。コンテキスト管理と品質保証パターンが段違い
- CI/CD 連携、Issue 駆動の自動化、一晩放置の長時間タスク → Codex のほうが向いてる。クラウド実行と /goal の永続化が効く
- 数ファイルの修正、普通のコードレビュー → どっちでもいい。Workflow 使うほどの規模じゃない
ちなみにこの調査自体が Workflow のいいデモになってて、5 エージェントがそれぞれ独立して Web 検索→構造化出力→統合分析、というパイプラインを 15 分で走らせてくれた。手動でやったら 2 時間はかかったと思う。
おまけ: Workflow を書く時のハマりどころ
実際に何回か回してわかったこと。
-
TypeScript 書くな。型注釈入れた瞬間パースエラーで落ちる。
const x: string[]じゃなくてconst x = []で - Date.now() 使えない。レジューム機能のためにスクリプトの決定論性が必要で、非決定的な関数は全部禁止されてる
- schema は書いたほうがいい。「JSON で返して」ってプロンプトで頼むより、schema オプション使ったほうが桁違いに安定する。不一致時は自動で 2 回リトライしてくれる
- pipeline() と parallel() を間違えるな。独立した処理は pipeline()（バリアなし、速い）。全結果を集めて重複除去とかしたい時だけ parallel()（バリアあり、遅い）
- エージェントがモックデータ捏造する問題。try/catch の中でエラーを握りつぶして嘘データを返すことがある。CLAUDE.md に「Error handling: fail loud, never fake.」って書いておくと防げる