Claude Codeの動的ワークフローについて
今回は、2026年5月末にClaude Codeへ追加された動的ワークフロー（Dynamic Workflows）について、その仕組みと使いどころを備忘録として整理します。
動的ワークフローは、2026年5月28日にOpus 4.8と同時に発表された機能で、本記事執筆時点（2026年6月）ではリサーチプレビュー（research preview）として提供されています。仕様は変わる可能性があり、お使いのバージョンによって挙動が異なる場合があります。
この記事のターゲット
Skills・サブエージェント・Hooksまでは把握したが、動的ワークフローが何を解決するのか掴みたい方
長時間・大規模・並列の作業でClaude Codeの応答が安定しないと感じている方
複数のサブエージェントを協調させる仕組みの全体像を知りたい方
動的ワークフローとは
動的ワークフロー（Dynamic Workflows）は、Claude自身がタスクごとに専用のハーネスをその場で書き起こし、複数のサブエージェントを生成・協調させて処理する仕組みです。ハーネスの実体は、サブエージェントを起動・調整するためのいくつかの専用関数を含むJavaScriptファイルです。標準のJavaScript（JSON、Math、Arrayなど）も使えるため、エージェント間で受け渡すデータの加工もコード側で行えます。
通常のClaude Codeは、計画と実行を同じコンテキストウィンドウの中で進めます。多くのコーディング作業ではこれで十分ですが、長時間に及ぶ作業、大量の並列処理、構造化された検証が必要な作業では、ひとつのコンテキストに詰め込みすぎて品質が落ちることがあります。動的ワークフローは、作業をタスクごとに分割し、それぞれを独立したコンテキストを持つサブエージェントに任せることで、この問題を構造的に避けます。
ハーネスエンジニアリングの考え方（モデル＋ハーネス）でいえば、これまで固定的だったハーネス部分を、実行時にClaudeが動的に組み立てる、という発展形にあたります。
コンテキストが長くなると起きる失敗モード
公式の解説では、ひとつのコンテキストで複雑な作業を長く続けるほど顕在化する、3つの失敗モードが挙げられています。
エージェントの怠慢（agentic laziness）
複雑な多段階タスクの途中で、部分的な達成のまま「完了した」と宣言してしまう
自己優先バイアス（self-preferential bias）
自分が出した結果を、検証・採点する場面でも好意的に評価してしまう
目標のドリフト（goal drift）
多数のターンや圧縮（compaction）を経るうちに、当初の目的や「やってはいけないこと」が少しずつ失われる
動的ワークフローは、独立したコンテキストと焦点を持つ別々のClaudeに作業を分けることで、これらを構造的に抑えます。たとえば、作る担当と検証する担当を別のサブエージェントに分ければ、自己優先バイアスは起きにくくなります。
静的なワークフローとの違い
Claude Agent SDKや claude -p を使って複数のClaude Codeを協調させる、静的なワークフローは以前から作れました。ただし静的なワークフローは、あらゆるケースに対応するために汎用的にならざるを得ません。動的ワークフローは、Opus 4.8の能力を前提に、目の前のタスク専用のハーネスをその都度組み立てる点が異なります。
基本のAPI
ワークフローの中心になるのは、サブエージェントを扱う3つの関数です。
関数 | 処理内容 |
|---|---|
| サブエージェントを1体起動する。使うモデルや、独立したワークツリーで動かすかどうかも指定できる |
| 複数の処理を並列に実行し、すべて終わるのを待ってから次へ進む |
| 各項目がステージを独立に流れていく。全体の完了を待たない |
parallel() と pipeline() の違いは、次へ進む前にすべての結果が必要かどうかです。必要なら parallel()、不要なら pipeline() のほうが速く、コストも抑えられます。エージェントごとにモデルを選べるのも特徴で、難しい推論にはOpus、安価な探索にはHaiku、といった割り当てができます。
6つのパターン
公式 の解説では、ワークフローを組むときによく使われ、組み合わせられる6つのパターンが紹介されています。
公式の解説でも、実際のワークフローはこれらのパターンを2〜4個組み合わせて構成されることが多い、と説明されています。たとえば公式が挙げている例では、高速なJavaScriptランタイムであるBun（Oven社のプロダクト）をZigからRustへ書き直す大規模な移植に、分割・敵対的検証・反復のパターンが使われているようです。
分類して振り分ける
まず分類エージェントがタスクの種類を判定し、種類に応じて処理を振り分ける
分割して統合する
作業を多数の小さな単位に分け、それぞれをエージェントに並列で処理させ、最後にひとつの結果へ統合する
敵対的検証
あるエージェントの出力を、別のエージェントが基準に照らして批判的に検証する
生成して絞り込む
アイデアを多数生成し、基準や検証で絞り込み、重複を除いて質の高いものだけを残
トーナメント
同じ課題に複数のエージェントが別々のやり方で挑み、2つずつ比較して勝ち残りを決める
完了するまで繰り返す
作業量が事前に読めないタスクで、停止条件を満たすまでエージェントの起動を繰り返す
使い方と運用
動的ワークフローは、Claudeに「ワークフローを作って」と頼むか、トリガー語の ultracode を使うことで起動できます。途中で中断されても、セッションを再開すれば続きから処理されます。
作ったワークフローは保存でき、~/.claude/workflows に置いて使い回したり、スキル（Skill）に同梱して配布したりできます。繰り返し実行し たいワークフローは /loop と組み合わせられ、使用量を抑えたいときはトークン予算を指定できます。同時に動かせるエージェント数や1回の実行あたりの総数には上限が設けられています（執筆時点で同時最大16、1回あたり合計1,000）。
注意点として、動的ワークフローは通常のセッションより多くのトークンを消費しがちです。公式も「ベストプラクティスはまだ発展途上」と述べており、すべての作業に必要なわけではありません。通常のコーディング作業の多くは、5体の検証エージェントを並べるような構成を必要としません。「この作業は本当に追加の計算資源を要するか」を一度考えてから使うのが、現時点では現実的です。
まとめ
動的ワークフローについて押さえておきたいポイントは次の4つです。
Claude自身がタスクごとに専用のハーネス（JavaScript）を組み立て、複数のサブエージェントを協調させる仕組み
ねらいは、長時間・大規模・並列の作業で起きる3つの失敗モード（怠慢・自己優先バイアス・目標ドリフト）を構造的に抑えること
中心となるAPIは
agent()・parallel()・pipeline()の3つトークン消費は増えやすく、リサーチプレビュー段階。通常の作業には過剰なことも多いので、使いどころを選ぶ
固定的だったハーネスを実行時に動的に組み立てるという点で、これまでのSkillsやサブエージェントの延長線上にありつつ、一段抽象度の高い仕組みだと捉えられます。
