AI-DLC Workflow V2の14エージェント：誰が何を担当し、どう協働するか
14人のエージェント、多すぎない？ 少なすぎない？ 実は「11＋2＋1」という構成に明確な設計思想があります。エージェントの全貌とコラボレーションの仕組みを見ていきましょう。シリーズ第8回。
Series: AI-DLC Workflow V2の解説 (31 articles)
- …
- 8AI-DLC Workflow V2の14エージェント：誰が何を担当し、どう協働するか This article
1. はじめに
この記事はAI-DLC Workflow V2（以降V2）シリーズの第8回です。これまでの記事で、5フェーズ・33ステージの構成、スコープによるステージの出し入れ、Adaptive Composerによるカスタム構成、MemoryとLearning Loop、そしてKnowledgeの2層構造を見てきました。
ここまで「何を実行するか」「どう覚えるか」「何を知っているか」を扱ってきましたが、では「誰が実行するのか」はどうでしょうか。33のステージにはそれぞれ担当エージェントが割り当てられています。V2が採用する14エージェント体制の考え方と、彼らの協働パターンを見ていきます。
2. なぜ14エージェントか
モブ開発の発想
V2のエージェント設計は「少人数チーム、広い守備範囲（Small Mob, Broad Agents）」という原則に基づいています。人間のモブ開発チームを思い出してみてください。3〜5人の少人数が、要件定義からデプロイまでを一気通貫で担当します。各メンバーは複数の専門領域を横断する広い能力を持っています。
V2はこのモデルをAIエージェントに適用しています。数十の狭い専門家エージェントを並べるのではなく、11人の「広い守備範囲を持つドメインエキスパート」で構成しています。
多すぎず少なすぎない設計
仮に狭い専門家モデルをたくさん並べる方式の場合はどうでしょう？たとえばアーキテクチャ関連だけで「フィージビリティ判定エージェント」「ドメイン設計エージェント」「ユニット分割エージェント」「契約設計エージェント」「機能設計エージェント」「NFR要件エージェント」「NFR設計エージェント」と7つに分かれます。それぞれのknowledgeベースはほぼ同じ内容になるにもかかわらず、7回のハンドオフが発生します。
V2では、これらすべてをaidlc-architect-agentが担当します。1人のエージェントが7ステージ×3フェーズにまたがるため、文脈が自然に保持されます。
この設計がもたらす利点は3つあります。
- ハンドオフの最小化: エージェント境界は情報ロスの発生点です。同じエージェントがDomain DesignとFunctional Designの両方をリードすれば、明示的な引き継ぎ資料なしにコンテキストが維持されます
- サポート役による協働: セキュリティ専門エージェントやコンプライアンス専門エージェントを独立させるのではなく、既存のaidlc-devsecops-agentとaidlc-compliance-agentがサポート役として他のステージに参加します
- knowledge管理の効率化: エージェントごとにknowledgeディレクトリを管理する仕組み上、少数のエージェントは管理コストを下げます
14の内訳
14エージェントは3つのカテゴリに分かれます。
| カテゴリ | 数 | 役割 |
|---|---|---|
| ドメインエキスパート | 11 | ステージの実作業を担当 |
| レビュアー | 2 | 成果物のレビューのみ（作成しない） |
| コンポーザー | 1 | ステージ構成の提案（compose要求時に発動） |
では、それぞれを詳しく見ていきましょう。
3. 11のドメインエキスパート
全体一覧
11のドメインエキスパートの概要です。
| エージェント | ドメイン | リードするステージ |
|---|---|---|
| aidlc-product-agent | 要件定義、ユーザーストーリー、スコープ、市場調査 | intent-capture, market-research, scope-definition, requirements-analysis, user-stories |
| aidlc-design-agent | UX/UIデザイン、ワイヤーフレーム、アクセシビリティ | rough-mockups, refined-mockups |
| aidlc-delivery-agent | チーム構成、キャパシティ計画、デリバリー順序 | team-formation, approval-handoff, delivery-planning |
| aidlc-architect-agent | ドメイン設計、契約設計、NFR、コンポーネント分解 | feasibility, domain-design, units-generation, contract-design, functional-design, nfr-requirements, nfr-design |
| aidlc-aws-platform-agent | AWSインフラ、CDK/CloudFormation、コスト最適化 | infrastructure-design, environment-provisioning |
| aidlc-compliance-agent | 規制スキャン、データ分類、リスク評価 | なし（サポートのみ） |
| aidlc-devsecops-agent | 脅威モデリング、セキュリティスキャン、DevSecOpsパイプライン | なし（サポートのみ） |
| aidlc-developer-agent | コード実装、コード分析、データモデリング | reverse-engineering, code-generation |
| aidlc-quality-agent | テスト戦略、テスト生成、パフォーマンス検証 | build-and-test, performance-validation |
| aidlc-pipeline-deploy-agent | CI/CDパイプライン、デプロイ戦略、リリース実行 | practices-discovery, ci-pipeline, deployment-pipeline, deployment-execution |
| aidlc-operations-agent | オブザーバビリティ、インシデント対応、SLO追跡、フィードバックループ | observability-setup, incident-response, feedback-optimization |
ここで重要なのは、「リードするステージ数 = 0」のエージェントが2つあることです。aidlc-compliance-agentとaidlc-devsecops-agentは、他のエージェントがリードするステージにサポートとして参加します。独立したステージを持たないのは、セキュリティやコンプライアンスの観点は多くのステージに横断的に関わるものだからです。
フェーズ別の活動範囲
各エージェントがどのフェーズでどのように関与するかを見ていきましょう。
凡例: L = リード（そのステージの主担当）、S = サポート（他エージェントがリードするステージに参加）、×数字 = 該当フェーズでのステージ数、— = そのフェーズでは活動なし
| エージェント | Ideation | Inception | Construction | Operation |
|---|---|---|---|---|
| aidlc-product-agent | L×3, S×2 | L×2, S×1 | — | — |
| aidlc-design-agent | L×1 | L×1, S×2 | — | — |
| aidlc-delivery-agent | L×2, S×1 | L×1, S×1 | — | — |
| aidlc-architect-agent | L×1, S×1 | L×3, S×2 | L×3 | — |
| aidlc-aws-platform-agent | S×1 | S×1 | L×1, S×1 | L×1, S×1 |
| aidlc-compliance-agent | S×1 | — | S×2 | S×1 |
| aidlc-devsecops-agent | — | S×1 | S×3 | S×1 |
| aidlc-developer-agent | — | L×1, S×2 | L×1, S×1 | S×1 |
| aidlc-quality-agent | — | S×2 | L×1, S×1 | L×1 |
| aidlc-pipeline-deploy-agent | — | L×1 | L×1 | L×2 |
| aidlc-operations-agent | — | — | — | L×3 |
この表からいくつかのパターンが読み取れます。
aidlc-architect-agentが最も広い守備範囲を持ちます。Ideation、Inception、Constructionの3フェーズにまたがる10ステージ（リード7＋サポート3）に関与します。フィージビリティ判断から機能設計まで、設計の一貫性を1人のエージェントが担保する構造です。
aidlc-operations-agentはOperationフェーズに集中します。オブザーバビリティ、インシデント対応、フィードバック最適化の3ステージをリードし、フィードバックループを通じてaidlc-product-agentに運用知見を還元します。これがV2のライフサイクルを循環させる仕組みです。
aidlc-developer-agentは3フェーズにまたがります。Inceptionでのリバースエンジニアリング、Constructionでのコード生成、Operationでのデプロイ支援と、実装者としてのコンテキストを長期にわたって保持します。
4. 2人のレビュアー
レビュアーの位置づけ
11のドメインエキスパートに加えて、V2には2人のレビュー専任エージェントがいます。レビュアーは成果物を作成しません。ビルダー（ドメインエキスパート）が作成した成果物をレビューし、品質ゲートとして機能します。
| レビュアー | レビュー対象 | 観点 |
|---|---|---|
| aidlc-product-lead-agent | 要件定義、ユーザーストーリー、モックアップ | 完全性、ビジネスアラインメント、テスタビリティ |
| aidlc-architecture-reviewer-agent | 技術設計成果物 | 健全性、実装可能性、相互参照の整合性 |
レビューステップの流れ
レビュアーが発動するのは、ステージの定義に
reviewer:フィールドが宣言されている場合です。具体的にはこのような流れになります。- ビルダー（ドメインエキスパート）がステージの成果物を作成する
- コンダクターがレビュアーをサブエージェントとして起動する
- レビュアーはステージ定義、Q&A、成果物を読み込む（ビルダーのmemory.mdや計画は読まず、独立した判断を下す）
- レビュアーが
## Reviewセクションを追記し、READYまたはNOT-READYの判定を出す - NOT-READYの場合、ビルダーが修正 → レビュアーが再確認（最大2回まで）
- 上限回数に達しても未解決の指摘がある場合は、指摘を付記した状態で承認ゲートに進む
ここで重要なのは、レビュアーはワークフローをブロックしないということです。最終判断は常に人間が承認ゲートで下します。レビュアーは「この品質で承認していいですか」という材料を提供する役割です。
どのステージでレビュアーが発動するか
aidlc-product-lead-agentがレビューするステージは以下の通りです。
- intent-capture（インテント捕捉とフレーミング）
- rough-mockups（ラフモックアップ）
- refined-mockups（精緻モックアップ）
- requirements-analysis（要件分析）
- user-stories（ユーザーストーリー）
aidlc-architecture-reviewer-agentがレビューするステージは以下の通りです。
- domain-design（ドメイン設計）
- contract-design（契約設計）
- units-generation（ユニット生成）
- functional-design（機能設計）
- nfr-requirements（NFR要件）
- nfr-design（NFR設計）
- infrastructure-design（インフラ設計）
- code-generation（コード生成）
Ideation〜Inceptionの初期成果物にはプロダクトリード、Inception〜Constructionの技術設計にはアーキテクチャレビュアーという配置です。
5. Adaptive Composerエージェント
ドメインエキスパートでもレビュアーでもない、もう1人のエージェントがaidlc-composer-agentです。このエージェントについてはシリーズ第5回で詳しく扱いましたが、14エージェント体制の文脈で位置づけを整理しておきます。
Adaptive Composerはcompose要求（
/aidlc compose、コールドスタート時の提案、--report、--new-scope）があった時にコンダクターからディスパッチされます。タスクの「実装エントロピー」を5つの要素（意図の曖昧さ、構造の不確実性、検証エントロピー、リスク、未解決の前提）で見積もり、それに基づいてEXECUTE/SKIPグリッドを提案します。他の13エージェントと異なり、ワークフローのステージ内で実作業を行うことはありません。ワークフローの「形そのもの」を決める唯一のエージェントです。
6. 4つのコラボレーションパターン
ここまで「誰が何を担当するか」を見てきました。では、複数のエージェントが1つのステージでどう協働するのか。V2は4つのコラボレーションパターンを定義しています。
inline（29ステージ）
最も多く使われるパターンです。コンダクターが自身のコンテキスト内でリードエージェントとサポートエージェントのペルソナを引き受け、各エージェントの声を切り替えながらステージを進めます。サブエージェントのディスパッチは発生しません。
1
2
3
4
コンダクター
├── [リードの声で] 設計を作成
├── [サポートAの声で] セキュリティ観点を追加
└── [サポートBの声で] コスト観点を補足29/33ステージがこのパターンを使います。ステージの参加エージェントが少なく（リード1＋サポート0〜3）、コンテキストの統合コストが低い場合に適しています。
subagent（2ステージ）
Hub-and-spoke型の協働パターンです。リードエージェントがサブエージェントとしてディスパッチされ、サポートエージェントも別々のサブエージェントとして並列にディスパッチされます。各サポートエージェントは互いの作業を見ることができません（mutually blind）。最後にリードが全員の成果を統合します。
1
2
3
4
5
6
コンダクター
└── [dispatch] リード（aidlc-pipeline-deploy-agent）
├── [dispatch] サポートA（aidlc-quality-agent）── 並列
├── [dispatch] サポートB（aidlc-developer-agent）── 並列
└── [dispatch] サポートC（aidlc-devsecops-agent）── 並列
→ リードが統合このパターンを使うのはpractices-discovery（プラクティス発見）とcode-generation（コード生成）の2ステージです。practices-discoveryではリード1人＋サポート3人の並列構造になりますが、code-generationではサポートエージェントなしでリードが独立サブエージェントとしてディスパッチされます。subagentパターンの核心は「リードをコンダクターとは別のコンテキストで独立実行する」ことにあり、並列サポートの有無はステージの設計次第です。
pipeline（1ステージ）
チェーン型の協働パターンです。エージェントAの出力がエージェントBの入力になる直列構造です。
1
2
3
aidlc-developer-agent（コードスキャン）
→ 出力
→ aidlc-architect-agent（統合・アーキテクチャ分析）このパターンを使うのはreverse-engineering（リバースエンジニアリング）の1ステージだけです。Developer Agentがコードベースをスキャンし、その結果をArchitect Agentがアーキテクチャの観点で統合・分析します。前段の出力に基づいて後段が作業する、明確な依存関係がある場面です。
mob（1ステージ）
メッシュラウンド型の協働パターンです。リードがドラフトを作成し、全サポートエージェントが並列でフィードバックを出し、リードが統合します。未解決の論点があれば人間に判断を仰ぐか、2ラウンド目に進みます。
1
2
3
4
5
6
aidlc-product-agent（ドラフト作成）
→ [並列] aidlc-design-agent: UX観点
→ [並列] aidlc-developer-agent: 実装可能性
→ [並列] aidlc-quality-agent: テスタビリティ
→ aidlc-product-agent（統合）
→ 未解決あれば → 人間 or ラウンド2このパターンを使うのはuser-stories（ユーザーストーリー）の1ステージだけです。ユーザーストーリーは多角的な観点（ビジネス、UX、実装、テスト）の合意が必要な成果物であり、全員が発言するモブ形式が適しています。
パターンの分布
| パターン | ステージ数 | 特徴 |
|---|---|---|
| inline | 29 | コンダクター内でペルソナ切り替え。軽量 |
| subagent | 2 | Hub-and-spoke。独立した並列作業 → 統合 |
| pipeline | 1 | チェーン。直列の依存関係 |
| mob | 1 | メッシュラウンド。多角的合意形成 |
33ステージのうち29がinlineです。inlineはオーバーヘッドが小さく、ほとんどのステージはリードエージェント1人で十分に処理できるため、この分布は合理的です。subagent、pipeline、mobは、複数の独立した視点や明確な直列依存がある場面でのみ使われる、特化型のパターンです。
7. エージェントのカスタマイズ
V2のエージェントはそのまま使うこともできますが、チームの文脈に合わせてカスタマイズする手段も提供されています。
Knowledge追加（最も一般的）
エージェントに参照情報を追加する方法です。
aidlc/spaces/<space>/knowledge/<agent-name>/ディレクトリにmarkdownファイルを配置すると、そのエージェントが起動時に自動的に読み込みます。詳しくは第7回：Knowledgeで解説しています。1
2
3
4
5
6
7
aidlc/spaces/default/knowledge/
├── aidlc-shared/ # 全エージェントが読む
│ └── our-api-conventions.md
├── aidlc-developer-agent/ # Developer Agentのみ読む
│ └── db-migration-patterns.md
└── aidlc-architect-agent/ # Architect Agentのみ読む
└── our-microservices-rules.mdたとえば「うちのチームではDynamoDB Single Table Designを標準とする」という情報をArchitect AgentとDeveloper Agentに持たせたい場合、
aidlc-shared/に配置すれば全員が参照し、特定のエージェントだけに持たせたい場合はそのエージェント名のディレクトリに配置します。プラグインによるエージェント追加
plugins/<name>/ディレクトリにプラグインを配置すると、新しいエージェントとステージをワークフローに追加できます。プラグインは自身のステージ定義、センサー、ツール、テストを持つことができます。ステージとの統合
新しいエージェントをワークフローに組み込むには、ステージ定義に担当エージェント名を書き、グラフを再生成します。サブエージェントとして独立実行させる場合は、コンダクターの許可リストへの追加も必要です。
やってはいけないこと
.kiro/agents/（ハーネスによっては.claude/agents/）にあるフレームワーク同梱のエージェントファイルを直接編集してはいけません。AI-DLC Workflow本体のバージョンアップ時にリセットされます。カスタマイズはすべてknowledge追加かプラグインで行います。8. まとめ
ここまでで、V2を動かす14のエージェントの全体像が見えてきたのではないでしょうか。
設計思想は「少人数チーム、広い守備範囲」。11のドメインエキスパートが広い守備範囲でハンドオフを減らし、2人のレビュアーが独立した品質チェックを入れ、Adaptive Composerがワークフローの形を提案する。そしてステージの性質に合わせて4つの協調パターンが使い分けられます。
エージェントの振る舞いを自分たちのプロジェクトに合わせたくなったら、Knowledge追加かプラグインで対応できます。フレームワーク本体には手を入れずに済む設計です。
Series: AI-DLC Workflow V2の解説 (31 articles)
- …
- 8AI-DLC Workflow V2の14エージェント：誰が何を担当し、どう協働するか This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article