第9章

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

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

本章の内容

オーケストレーションパターンとワークフローの関係 — パターンはブロック、ワークフローは完成品の組み立て
ワークフローを構成する6つの構成要素：ステージ、ブランチ、ファンアウト、ファンイン、ゲート、ループ
フロー図付きの5つの実世界ドメインワークフロー事例
サブエージェントロスター — 各エージェントの階層、並列実行可能性、書き込み権限
ロール境界マトリックス — どのシナリオでどのエージェントを使用するか
PMフェーズパイプライン — フェーズ0からフェーズ6までの実行ワークフロー
作業の性質に基づいて、どのパターンを選択し組み合わせるかを決定するガイド

ワークフローとは

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

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

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

オーケストレーションパターンはレゴブロックです。1つだけでも機能しますが、複数を組み合わせることではるかに複雑で有用な形状を作り出せます。ワークフローはその組み合わせの結果です。

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

ワークフローの構成要素

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

ステージ順次的に実行される作業の単位。ワークフローの最も基本的な構成要素。前のステージの出力が次のステージの入力になります。

ブランチ条件に基づいてパスが分岐するポイント。ルーティングパターンの実用的な適用 — 例えば、「小さな変更は軽量レビュー、大きな変更はフルレビュー」といった具合に、変更の性質に応じて異なるエージェントまたは次のステージにリクエストを送信します。

ファンアウト独立したサブタスクが同時に実行されるポイント。ファンアウトパターンの構造的表現。実行時間は最も遅いサブタスクに収束します。例：セキュリティ、パフォーマンス、可読性の観点を同時にレビューする。

ファンイン並列に実行された複数の結果を1つに集約するステージ。第2章では扱わなかった概念です。ファンインでは、どの結果を優先するか（投票）、それらをどのようにマージするか（集約/選択）を決定するルールが必要です。例：3人のレビュアーの意見を最終フィードバックに統合する。

ゲート次のステージに進む前に検証または人間の承認を必要とするポイント。第3章のガードレールの実用的な適用ポイント。元に戻しにくい操作（ファイル変更、デプロイ、PRマージ）の前に配置されます。

ループ検証ステージで却下された場合に前のステージに戻る繰り返し構造。評価者・最適化者パターン（検証してから適用）の構造的表現。無限ループを防ぐために最大リトライ回数を設定する必要があります。

これら6つの構成要素は、第2章の5つのパターンと1:1でマッピングされるわけではありません。単一のパターンに複数の構成要素が含まれる場合（例：ファンアウトパターン = ファンアウト + ファンイン）もあれば、単一の構成要素が複数のパターンに現れる場合（例：ゲートは検証してから適用とパイプラインの両方に現れる）もあります。

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

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

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

コードレビューソフトウェア開発

コアパターン: ルーティング → ファンアウト → ファンイン → パイプライン → 検証してから適用(ループ)

① 変更分析（ルーティング）: 変更ファイルの規模と種類を分析してレビュー範囲を決定します。単純なタイポ修正は高速パスに分岐し、 majorな機能変更はフルレビューパスに分岐します。
② 多角的レビュー（ファンアウト）: 専門レビュアーエージェントがセキュリティ、パフォーマンス、可読性の観点を同時に検証します。
③ 意見集約（ファンイン）: 統合エージェントが3人のレビュアーのフィードバックを1つのフィードバックレポートにまとめます。
④ 修正提案（パイプライン）: フィードバックに基づいてコード修正提案を生成します。
⑤ 最終承認（検証してから適用）: 修正されたコードを再レビューします。合格すれば人間の承認ゲートへ進み、却下されれば④にループバックします。

バリアント: co-developの6段階ガバナンスパイプラインと構造的に類似。第6章 §1を参照。

市場調査レポートコンサルティング · リサーチ

コアパターン: オーケストレーター・ワーカー → ファンアウト → パイプライン → 検証してから適用

① オーケストレーション（PM）: PMエージェントが調査範囲、対象市場、納品物フォーマットを定義し、ワーカーに委譲します。
② 並列調査（ファンアウト）: 3つのエージェントが市場規模分析、競合分析、技術動向調査を同時に実行します。
③ 集約とドラフト作成（パイプライン）: 3つの調査結果をドラフトレポートに統合し、可視化（チャート）を生成します。
④ クロス検証（検証してから適用）: 専門レビュアーがデータソース、論理的一貫性、欠落をチェックします。人間の承認ゲートを経て、最終レポートが確定します。

バリアント: co-consultの7段階（フェーズ0-6）パイプライン構造に基づく。第6章 §2演習（G-1）で直接体験できます。

プレゼンテーション制作講義 · プレゼンテーション

コアパターン: パイプライン(長いパイプライン) + ファンアウト(中間の並列処理)

① 調査: トピックに関連する資料を収集し、ソースを検証します。
② ストーリーライン: 全体的なコンテンツフローとスライド構成を計画します。
③ デザイン: ビジュアルレイアウトとテーマを選択します。
④ 画像キュレーション + 図生成（ファンアウト）: イラストと図を同時に生成して時間を節約します。
⑤⑥⑦ ビルド・計測・エクスポート（パイプライン）: HTMLビルド → レイアウト計測 → PDFエクスポートの順次処理。
⑧⑨⑩⑩ 最終レビュー（検証してから適用）: 完成したPDFをクロスレビューし、人間の承認ゲートへ進みます。

バリアント: まさにco-deckの11段階（ステージ0-11）パイプライン。第6章 §2演習（G-2）の韓国食品グローバル化プレゼンテーションで直接体験できます。

課題トリアージ運用 · インシデント

コアパターン: ルーティング → オーケストレーター・ワーカー → エスカレーション

① 分類（ルーティング）: 受信した課題の緊急度と種類を分析してパスを決定します。バグは修正パス、機能リクエストは計画パス、セキュリティ問題は緊急パスに分岐します。
② 自動調査（オーケストレーター・ワーカー）: ワーカーエージェントが分類された課題をサブタスクに分解して調査します — 関連ログ検索、再現の試行、影響範囲の評価。
③ 優先度決定: 調査結果に基づいて優先度と担当者を推奨します。
④ エスカレーションまたは自動解決: 自動的に解決できる軽微な問題（例：設定エラー）は即座に修正し、複雑な問題は人間の承認ゲートにエスカレーションします。

インシデント管理専用のバリアントはまだありませんが、co-developのPMロールと第2章の障害対応パターン（リトライ、ロールバック、エスカレーション）を組み合わせることで実装できます。

PR作成と検証ガバナンス

コアパターン: パイプライン → 検証してから適用(ループ) → ゲート

① 変更収集: コミット履歴と差分を収集してPRのドラフト（タイトル、本文）を作成します。
② ルール検証（検証してから適用）: PRがCONSTITUTION.mdのルール（英語タイトル、特定のフォーマットなど）に準拠しているかを自動チェックします。違反がある場合は①にループバックして修正します。
③ 影響分析: 変更が他のファイル/機能にどのような影響を与えるかを分析し、PR本文に追加します。
④ 最終レビュー + 承認: PR全体を再レビューし、人間の承認ゲートへ進みます。承認されるとマージ保留状態に移行します。

ai-workspace-standardsのCONSTITUTION.mdで定義されたPRワークフローをエージェントが自動化する構造。第5章 §2 コアファイルと第8章 §1 デプロイとSSOTでデプロイパイプラインと合わせて解説されています。

事例に共通するパターン

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

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

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

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

エージェント	ファイル	階層	並列実行	書き込み権限
PMオーケストレーター	`agents/pm.md`	高	—	オーケストレーションのみ
整合性監査人	`agents/auditor.md`	中	独立QA	なし
ライフサイクルマネージャー	`agents/lifecycle-manager.md`	中	オンデマンドガバナンス	ガバナンス文書のみ（L0のみ）
テンプレートアーキテクト	`agents/architect.md`	高	設計フェーズ	なし
オートメーションエンジニア	`agents/automation-engineer.md`	低	順次	TypeScript (.ts) 自動化スクリプト
ドキュメントライター	`agents/docs-writer.md`	中	設計後	.mdファイルのみ
スキャフォールディング専門家	`agents/scaffolding-expert.md`	低	調査フェーズ	インストールスクリプトのみ（承認後）
セキュリティ・Git専門家	`agents/security-expert.md`	中	レビューフェーズ	フック設定のみ

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

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

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

シナリオ	使用するエージェント	使用しないエージェント
実装アプローチとフォルダ構造の設計	`architect`	`automation-engineer`
自動化スクリプト (.ts) の作成/変更	`automation-engineer`	`architect`
ドキュメントの更新	`docs-writer`	`architect`
テンプレートからの新規プロジェクトスキャフォールディング	`scaffolding-expert`	`automation-engineer`
セキュリティレビュー、Gitフック設定	`security-expert`	`architect`
ドキュメントの整合性クロス検証	`auditor`	`docs-writer`
複数エージェント間の作業オーケストレーション	`pm`	いずれの実行エージェント

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

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

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

フェーズ0プロジェクト初期化（PM専用） — ワークスペースの要件を評価し、エージェント/スキルを動的に生成してAGENTS.mdを更新します。ワークフロー: オーケストレーター単独

フェーズ1-2計画・アーキテクチャ（専門家自律） — PMがリクエストを分類し、Architectが実装計画 + ADRを作成し、調査エージェントが並列にディスパッチされます。ワークフロー: ルーティング → ファンアウト（並列調査）

フェーズ3設計ハンドオフ（バリアントごと） — Architectが承認済み計画を実行エージェントに引き渡します。エージェント間の自律的ハンドオフ。ワークフロー: オーケストレーター・ワーカー（ハンドオフ）

フェーズ4実行（専門家自律） — Automation Engineerが承認済み計画に従って実装し、Docs Writerがドキュメントを更新します。ワークフロー: パイプライン（順次実行）

フェーズ5ライフサイクルクロージャ（PM専用） — PMが変更されたアーティファクトのガバナンス記録を更新します。ワークフロー: オーケストレーター単独（記録）

フェーズ6品質保証（ワークスペース自律） — Auditorが自動的にqa-gate.tsを実行します。最大2回のイテレーション後にPMにエスカレーションします。ワークフロー: 検証してから適用（ループ）

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

ワークフロー選択ガイド

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

最初のパターンを選ぶためのものです。複雑な業務は上から下へ段階を設計しながら、パターンを自然に追加していきます。

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

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

タスクタイプ	依存関係	並列化可能	検証の必要性	推奨開始パターン
ドキュメント翻訳/要約	順次	×	中程度	`パイプライン`
コードレビュー	部分的	○	必要	`ルーティング → ファンアウト → 検証`
市場調査	部分的	○	必要	`オーケストレーター・ワーカー → ファンアウト`
バグ修正	順次	×	必要	`パイプライン + 検証してから適用`
課題トリアージ	なし	条件的	中程度	`ルーティング → オーケストレーター・ワーカー`
プレゼンテーション制作	部分的	○	必要	`パイプライン(長) + ファンアウト(中)`
PR作成	順次	×	必要	`パイプライン + 検証してから適用`
多言語コンテンツ生成	なし	○	中程度	`ファンアウト + ファンイン`

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

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

ファンアウト + パイプライン並列レビュー、多言語翻訳に続く後処理。ファンアウトが速度を提供し、パイプラインが順序を保証します。

ルーティング + ファンアウト課題トリアージ、サイズベースのレビュー。ルーティングが分類し、各パスで異なる並列タスクを実行します。

オーケストレーター・ワーカー + 検証複雑な分析、設計レビュー。PMが動的に配分し、結果が検証されます。

パイプライン + 検証 (ループ)コード生成、PR作成。順次的に書き込みますが、品質基準を満たさない場合は前のステージに戻ります。

ルーティング + オーケストレーターモデルの階層化。簡単なタスクは軽量モデルに、難しいタスクは強力なモデルに配分されます。

本章のワークフロー事例は、第4章演習のD-1（順次パイプライン）とD-2（動的チーム編成）、および第6章演習のG-1（co-consult）、G-2（co-deck）を通じて直接体験できます。第13章のキャップストーン演習では、本章の原則に基づいて「独自のワークフロー」を設計します。

← 前の章

8章 §5 · 高度化ロードマップ

次の章 →

10章 · L3プロジェクトアップグレード