ワークフローデザインパターン

本章では、オーケストレーションパターンを組み合わせて、実世界のドメインで使用される完全なワークフローを設計する方法と、さまざまなケーススタディについて解説します。

ワークフローとは

第2章 §4で学んだ5つのオーケストレーションパターン — プロンプトチェーン（パイプライン）、ルーティング、並列化（ファンアウト/投票）、オーケストレーター・ワーカー、および評価者・最適化者（検証してから適用） — は、単一の作業単位内でエージェント間の協力を構造化するための基本的な構成要素です。しかし実際には、単一のブロックだけでタスクを完了することよりも、複数のブロックを接続してレイヤー化し、1つの完全なフローにすることがはるかに一般的です。

ワークフローとは、「1つ以上のエージェントが協力して複雑なタスクを完了するプロセス全体」を指します。オーケストレーションパターンが「エージェントがどのように協力するか」に答えるなら、ワークフローは「プロセス全体がどのような順序と構造で進行するか」に答えます。ワークフローは通常、以下の3つの要素を組み合わせます。

• オーケストレーションパターンの組み合わせ — 一部のステージは順次的（パイプライン）、一部は並列（ファンアウト）、一部のブランチは条件的（ルーティング）です。
• ドメインルール — 「コードレビューではセキュリティとパフォーマンスの観点を別々に検証する必要がある」など、特定のビジネスドメインで求められるルール。
• 人間の承認ゲート — 第3章で学んだガードレールの原則に従い、不可逆的なポイントに到達する前に人間が確認するステップ。

本章では、第2章のパターンをすでに知っていることを前提としています。用語に不慣れな場合は、まず第2章 §4 オーケストレーションパターンと§4b 動的チーム編成をお読みください。次のセクションでは、パターンを超えて、ワークフローを構成する6つの構成要素について解説します。

ワークフローの構成要素

複雑なワークフローを分解すると、いくつかの繰り返し現れる構造的要素が見つかります。第2章の5つのパターンはエージェント同士がどのように協力するかに焦点を当てましたが、ここではワークフローの構造的な骨格に焦点を当てます。

これらの要素を組み合わせることで、ほぼすべての実世界のワークフローを表現できます。次のセクションでは、実際のドメインでこれらの要素がどのように配置されているかのケーススタディを見ていきます。

実世界のワークフロー事例

5つのドメインワークフローをケース別に紹介します。各ケースでは、コアパターンの組み合わせ、ステージフロー、担当エージェント、人間ゲートの位置を示します。ai-workspace-standardsで実装済みのバリアントに接続済みのケースも含まれています。

事例に共通するパターン

5つの事例からいくつかの共通構造が浮かび上がります。

• すべてのワークフローに人間ゲートがあります。自動化がどれほど進んでも、納品物の確定、マージ、デプロイなどの不可逆的な決定の前には人間の承認が必要です。これは第3章で学んだガードレールの実用的な適用ポイントです。
• ファンアウトには必ずファンインが続きます。並列ブランチに分岐した結果をそのまま並べておくと、消費者（次のステージのエージェント、または人間）が手動で統合しなければなりません。次のパイプラインステージにスムーズに移行できる単一の納品物を生成するために、明示的なファンインステージが必要です。
• 検証ステージがループするかエスカレーションするかでワークフローの複雑さが決まります。自動修正できる問題（フォーマット違反、タイポ）はループで解決され、判断が必要な問題（設計の欠陥、セキュリティ脆弱性）はエスカレーションで人間に引き渡されます。
• 単純なパイプラインはほとんど使われません。5つの事例はすべて「純粋に順次的」なワークフローではありません。少なくとも1つのポイントでルーティング（分岐）またはファンアウト（並列）が含まれています。

サブエージェントロスター — ワークフローを構成するエージェントのリスト

第2章では「エージェント」をロールとしてモデル化することを学びました。実際のワークスペースでは、これらのロールは具体的なファイルと階層の割り当てで定義され、ロスターに登録されます。AGENTS.mdのサブエージェントロスターは、この定義を一覧で示すテーブルです。

このテーブルの「並列実行」列は、第10章 §4で扱った階層調整ルールと併せて解釈する必要があります。例えば、docs-writerは設計が確定する前に並列でドキュメントを書くと後でやり直しになるリスクがあるため、「設計後」にのみ並列実行できます。一方、Auditorは「独立QA」であり、他のエージェントの作業に関係なくいつでも独立して実行できます。

ロール境界マトリックス — 「このタスクは誰がやるべきか」

複数のエージェントがいる場合、「このタスクを誰が処理すべきか」が曖昧になることがあります。以下のマトリックスは、その曖昧さを解消するロール境界を定義します。

このマトリックスの中核原則は「設計と実行の分離」です。architectは設計のみを行い、スクリプトを直接書くことはありません。automation-engineerはスクリプトを書きますが、構造を設計することはありません。docs-writerはドキュメントを検証しません — auditorが検証し、docs-writerはauditorのフィードバックを反映してドキュメントを改訂します。

PMフェーズパイプライン — ワークフローのガバナンスビュー

本章で扱ったワークフローパターン（ルーティング、ファンアウト、パイプラインなど）は、技術的構成要素の視点を表しています。実際のワークスペースでは、これらの技術パターンの上にガバナンスフェーズがレイヤー化されています。PMが管理する7つのフェーズを、ワークフローの視点から整理すると以下のようになります。

これら7つのフェーズは、§3のワークフロー事例と直接対応しています。例えば、「コードレビュー」事例の全体フローは、フェーズ1-2（分析）→ フェーズ4（レビュー実行）→ フェーズ6（QA）のミニチュアです。実践で新しいワークフローを設計する際、これらのフェーズを念頭に置くことで、「人間ゲートをどこに配置するか」「どのステージが並列実行に安全か」を体系的に決定しやすくなります。

手順スキーマ — ワークフローの宣言的SSOT (ADR-0063)

この章のパターンが「事例」なら、手順スキーマはその事例を 機械が読める宣言 に引き上げる装置だ。variantテンプレートの procedures/<name>/schema.yaml にワークフロー段階を {id, agent_key, skill_key, output_type, description} として記録し、段階間の関係は follows·enables·composes_with 型で宣言する(参照C参照)。

• 検証はリポジトリ整合性検査 — scripts/validate-procedures.ts がスキーマ形状、列挙型、閉じた _output-types.yaml 語彙、そしてすべての agent_key/skill_key が実在のエージェントファイル・スキルディレクトリに解決されるかを検査する。/sync は失敗時に停止する
• グラフとの接続 — 手順から導出されるグラフノード(procedure、output_type)とエッジ(step_uses_skill、step_by_agent、produces)は 生成プロジェクション だ。手で編集することは禁じられ、手順を直して再生成する
• カバレッジは (agent_key, phase) 単位 — エージェントフロントマターの phases: が必要なペアを宣言すると、実際の手順段階がそのペアを覆うかを scripts/procedure-coverage.ts が報告する。ギャップは決して自動填充されず、--tickets が決定論的キー(<variant>:<agent_key>:<phase>)のガバナンスチケットを登録して人が判断する

要するに、ワークフロー知識 — どのエージェントがどの段階で、どのスキルで、何を産出するか — が散文ではなく検証可能なデータになる。これがこの章のパターンと手順スキーマの違いだ。

2026年9月からは、この手順層の上にドメインステージ軸が重なり、活動をドメイン業務フローの段階にまとめ、RACIと判断ゲートで責任と判断まで宣言するDomain Operating Model構造が整った。詳細は第15章・Domain Operating Modelで扱う。

ワークフロー選択ガイド

新しいタスクにマルチエージェントワークフローを導入するには、どのパターンから始め、そこからどのように拡張するかを決定する必要があります。以下の意思決定ツリーが、最初のステップの選択をサポートします。

タスクタイプ別の開始パターン

意思決定ツリーの結果をタスクタイプ別に整理すると以下のようになります。

パターン組み合わせガイド

以下に、どのパターンを一緒に使用すると相乗効果を生むかのまとめを示します。

運用標準：薄い指示、明確な所有権、PR による変更

AGENTS.md はすべての規則を複製するファイルではなく、薄いディスパッチャである。重要な境界と参照先だけを置き、詳細なガバナンスは単一の正本に分ける。スキルは L0 標準、L1 テンプレート、L2 プロジェクトの所有権を区別し、L3 実行スナップショットは自動同期されない配布結果として扱う。

ブランチは pr/<timestamp>-<slug> 形式で作成する。/sync による変更も必ず PR、CI 検証、マージを経る。