AI-DLC Workflow V2のInception Phase: "何を作るか"を実装可能な粒度に分解する
「要件は決まった。でも、どこから手をつければ？」 Inception phaseはこの問いに答えます。要件を分析し、ストーリーに分解し、ドメインを設計し、作業単位を切り出し、境界の契約を固め、実行順序を決める。Constructionが始まる前に「設計図」を完成させるフェーズです。シリーズ第10回。
Series: AI-DLC Workflow V2の解説 (31 articles)
- …
- 10AI-DLC Workflow V2のInception Phase: "何を作るか"を実装可能な粒度に分解する This article
1. なぜInceptionが必要なのか
課題: 要件と実装の間にある溝
Ideation phase で「何を作るか」の意図は固まりました。しかし、その意図がそのままコードにはなりません。「ユーザー認証を実装する」という要件ひとつ取っても、どのコンポーネントに分割するのか、既存コードとどう接続するのか、どの順番で着手すれば手戻りが少ないのか。この「要件と実装の間にある構造化の溝」を埋めないまま Construction に入ると、AIエージェントは文脈不足のまま推測でコードを生成し始めます。結果として手戻り、矛盾、スコープの肥大化が起きます。
解決: 段階的に分解し、各段階で検証する
AI-DLC Workflow V2（以降V2）のInception phaseは、この溝を9つのステージで段階的に埋めていきます。各ステージの出力が次のステージの入力になる連鎖構造を取り、ステージごとに承認ゲートが設けられているため、人間が確認・修正した上で次に進めます。
V1のInception phaseは「要件分析、ユーザーストーリー、ドメイン設計、Unit生成」の4ステージ構成でした。V2ではReverse Engineering、Practices Discovery、Contract Design、Delivery Planningが加わり9ステージに拡張されています。これはBrownfield対応、チームプラクティスの明文化、境界契約の明確化、実行計画の策定という4つの課題に対応するためです。
仕組み: 9ステージの一覧と実行条件
では、全体像を見ていきましょう。
| # | ステージ | リードエージェント | 何が決まるか | 実行条件 |
|---|---|---|---|---|
| 2.1 | Reverse Engineering | Developer | 既存コードの構造把握 | Brownfieldのみ |
| 2.2 | Practices Discovery | Pipeline Deploy | テスト方針・コードスタイル・デプロイ手順 | CONDITIONAL |
| 2.3 | Requirements Analysis | Product | 構造化された要件一覧 | ALWAYS |
| 2.4 | User Stories | Product | ユーザー視点のストーリーとペルソナ | ユーザー向け機能がある場合 |
| 2.5 | Refined Mockups | Design | UI仕様と操作フロー | UIプロジェクトの場合 |
| 2.6 | Domain Design | Architect | 論理的な構成要素（コンポーネント）とエンティティ所有・ADR | 新規コンポーネントがある場合 |
| 2.7 | Units Generation | Architect | 作業分解と依存DAG | enterprise, feature, mvp, workshop |
| 2.8 | Contract Design | Architect | ユニット間境界・公開APIの契約仕様 | ユニット間境界または外部公開APIがある場合 |
| 2.9 | Delivery Planning | Delivery | Bolt実行計画と順序の根拠 | 2.7と同一（セットで実行） |
全ステージが実行されるのは
enterpriseやfeatureスコープの場合です。bugfixやsecurity-patchなど軽量スコープではInceptionでReverse Engineering（Brownfield時）とRequirements Analysisだけを通り、設計・分解系のステージはスキップされます。スコープによる実行対象の絞り込みについては、記事末尾のセクション8で整理しています。Brownfieldプロジェクト（Initialization phaseのWorkspace Scanで既存コードありと判定されたもの）ではステージ2.1から始まり、Greenfieldではステージ2.2またはそれ以降から始まります。
2. 既存コードを理解する（Reverse Engineering）
課題: 既存コードの構造が共有されていない
Brownfieldプロジェクトでは、既存のコードベースがすでにあります。しかし、その構造やアーキテクチャ上の意図は、ドキュメントが古くなっていたり、そもそも書かれていなかったりします。この状態でAIエージェントが要件分析や設計に入ると、既存コードとの整合性を保てません。既存APIの重複実装、既存パターンからの逸脱、不要な依存の追加。いずれもコードベースを理解しないまま進めた結果です。
解決: コードを構造的にスキャンし、CodeKBとして永続化する
ステージ2.1では既存コードを機械的にスキャンし、9つのアーティファクトとして構造化されたCodeKBを生成します。このCodeKBは
codekb/ディレクトリに格納され、同じスペース内の後続インテントからも参照可能です。一度スキャンした知識は使い回せるため、インテントのたびにゼロからスキャンする必要はありません。仕組み: 2段階パイプライン
Reverse Engineeringは「パイプラインモード」で動作します。2つのエージェントが順番に作業する2段階構成です。
第1段階 — Developer Agent（コードスキャン）
パッケージ構造、ビルドシステム、API、依存関係、テスト構成、技術負債のシグナルをスキャンし、構造化された結果を返します。
第2段階 — Architect Agent（統合とCodeKB化）
スキャン結果を受け取り、以下の9つのアーティファクトとして整理・格納します。
| アーティファクト | 内容 |
|---|---|
| business-overview.md | ビジネスドメイン、目的、主要機能 |
| architecture.md | システムアーキテクチャ、パターン、コンポーネント関係（Mermaid図を含む） |
| code-structure.md | パッケージ構成、ファイル分類、コードパターン |
| api-documentation.md | 外部・内部API、エンドポイント、契約 |
| component-inventory.md | コンポーネント一覧と責務・依存 |
| technology-stack.md | 言語、フレームワーク、ライブラリとバージョン |
| dependencies.md | 外部依存、内部クロスパッケージ依存 |
| code-quality-assessment.md | テストカバレッジ、lint、CI/CD、技術負債 |
| reverse-engineering-timestamp.md | 実施日時とスコープ情報 |
再実行時には鮮度チェックが行われ、変更がなければ既存のCodeKBを再利用する選択肢も提示されます。後続のRequirements AnalysisやDomain DesignはこのCodeKBを前提として読み込むため、Inception phase全体の精度に直結するステージです。
3. チームの流儀を確認する（Practices Discovery）
課題: 暗黙のルールがAIに伝わらない
チームには「trunk-basedでsquash-merge」「テストはBDD」「linterの設定に従う」といった合意事項があります。しかし、これらが明文化されていなければAIエージェントはそれを知りません。コード生成時にチームの慣習と異なるパターンが混入し、レビューで差し戻される。この繰り返しは非効率です。
解決: 暗黙知を形式知に変換し、メモリレイヤーに永続化する
ステージ2.2ではチームの開発プラクティスを5つの領域で確認し、明文化します。確認された内容はメモリレイヤー（
team.md/project.md）に永続化され、Construction phase以降のすべてのステージで参照されます。「ALWAYS〜（必ず〜する）」「NEVER〜（決して〜しない）」と確認されたルールは、コード生成やレビューの判断基準として機能し続けます。仕組み: hub-and-spoke構成とインタビュー
このステージは「hub-and-spoke（ハブ＆スポーク）」というマルチエージェント構成で動きます。
- Lead（Pipeline Deploy Agent）が初期ドラフトを作成する
- 3つのSupport Agent（Quality、Developer、DevSecOps）がそれぞれ独立にレビューする — 互いの結果は見えません
- 人間インタビュー — 5つの領域について構造化された質問を提示し、チームの意思を確認する
- Lead統合 — すべてのフィードバックとインタビュー結果を統合し、最終版を作成する
確認される5つの領域は以下の通りです。
| 領域 | 例 |
|---|---|
| Way of Working | ブランチ戦略、マージ方式、PR運用 |
| Walking Skeleton | 最初のBoltでEnd-to-Endスライスを作るか否か |
| Testing Posture | TDD/BDD/テスト後書き、カバレッジ基準 |
| Deployment | デプロイ頻度、承認フロー、環境構成 |
| Code Style | linter設定、命名規則、フォーマッター |
ここで確認した「Walking Skeleton」と「Way of Working」は、ステージ2.9 Delivery Planningの計画に直接影響します。たとえば「Walking Skeletonを最初に走らせる」と確認されていれば、Bolt 1がWalking Skeletonとして計画されます。
4. 要件を構造化する（Requirements Analysis）
課題: 自然言語の意図は構造化されていない
Ideation phaseのIntent Capture（ステージ1.1）で記録されたユーザーの意図は自然言語です。「タスク管理APIを作りたい」「認証機能が必要」。こうした記述は人間には伝わりますが、後続のステージが機械的に参照するには曖昧さが残ります。何が機能要件で何が制約なのか、暗黙の前提は何なのか、矛盾はないのか。この構造化なしに設計に入ると、あとから「これは要件に含まれていたのか？」という問題が繰り返し発生します。
解決: 意図を構造化された要件一覧に変換し、後続ステージの共通入力にする
ステージ2.3はすべてのワークフローで実行される唯一のALWAYSステージです。Product Agentが自然言語の意図を「機能要件」「非機能要件」「制約」「前提」の4軸で整理し、
requirements.mdとして出力します。このファイルが後続すべてのステージの共通入力になるため、Inception phase全体の品質はここでの定義精度に依存します。仕組み: 4軸分類と曖昧さの検出
Product Agentが以下の軸で要件を整理します。
- 機能要件: システムが何をするか
- 非機能要件: パフォーマンス、セキュリティ、可用性など
- 制約: 技術的・ビジネス的な制約条件
- 前提: 暗黙に前提としている条件の明示化
Brownfieldプロジェクトでは、ステージ2.1の成果物（特にarchitecture.mdやcomponent-inventory.md）を入力として読み込み、既存システムとの整合性を確認しながら要件を定義します。曖昧な表現や要件間の矛盾がないか検証された上で承認ゲートに進み、人間が確認・修正してから次へ渡ります。
深さ（Depth）はMinimal/Standard/Comprehensiveで調整されますが、ステージ自体が省略されることはありません。
bugfixでもenterpriseでも、必ず通過します。5. ストーリーを切る（User Stories）
課題: 要件は「システム視点」であり「ユーザー視点」ではない
Requirements Analysisの出力は構造化されていますが、あくまでシステムの観点です。「認証APIを提供する」は要件としては正しいのですが、「誰が」「どんな状況で」「何を達成したいのか」は見えてきません。ユーザー視点が欠落した状態で実装に入ると、機能としては正しいが使いにくい、あるいはテストシナリオが書けないという問題が発生します。
解決: ユーザー視点のストーリーに変換し、テスト可能な受入基準を付ける
ステージ2.4ではProduct Agentがリードし、要件をユーザーストーリー形式に変換します。各ストーリーにはGiven/When/Then形式の受入基準が付与され、後続のテスト設計で直接使えるようになります。生成されるストーリーはINVEST基準（Independent、Negotiable、Valuable、Estimable、Small、Testable）に沿って検証されます。
仕組み: mob構成による多角的レビュー
User Storiesは「mobモード」で動作します。Product Agent（リード）がドラフトを作成し、3つのSupport Agentがそれぞれの観点からフィードバックを行います。
- Design Agent: ユーザー体験の観点。このストーリーで描かれる操作フローは自然か
- Developer Agent: 実装可能性の観点。このストーリーの粒度で実装に着手できるか
- Quality Agent: テスト可能性の観点。受入基準は具体的で検証可能か
成果物は以下の2ファイルです。
- stories.md: ユーザーストーリー一覧。ペルソナ、受入基準、優先度を含む
- personas.md: ペルソナ定義。ストーリーで参照されるユーザー像
ここで定義されたストーリーは、ステージ2.7（Units Generation）でUnitへのマッピングに使われ、Construction phaseでの実装対象になります。
なお、純粋なリファクタリングやインフラ変更など、ユーザー向け機能がないプロジェクトではこのステージはスキップされます。
6. ドメインを設計する（Domain Design）
課題: 要件やストーリーだけでは「どんな構成要素で作るか」が決まらない
要件が明確になり、ストーリーが切られても、それだけでは実装を始められません。「認証と通知はそれぞれ独立したコンポーネントなのか」「どのコンポーネントがどのエンティティ（データ）を所有するのか」「コンポーネント同士はどう呼び合うのか」。コードを書く対象となる論理的な構成要素（building block）の境界と責務が決まっていなければ、実装者ごとに異なる前提で作り始めてしまいます。
ここで、UI仕様が必要なプロジェクトではステージ2.5 Refined Mockupsが先に実行されることを補足しておきます。Ideation phaseのRough Mockups（ステージ1.6）で合意した画面構成の方向性を、Requirements AnalysisとUser Storiesで確定した機能仕様に基づいてコンポーネントレベルまで詳細化するステージです。操作仕様、デザインシステムマッピング、アクセシビリティチェックリストを生成し、Domain Designの入力に加えます。APIのみのプロジェクトやインフラ変更では省略されます。
解決: 論理的なコンポーネントを特定し、判断根拠をADRに残す
ステージ2.6ではArchitect Agentがリードし、システムを構成する論理的なコンポーネント（コードを書く対象の building block）を特定・詳細化します。各コンポーネントの責務・境界、コンポーネント間の呼び出し関係、そして各コンポーネントが所有するエンティティを定義します。判断根拠はADR（Architecture Decision Record）として記録され、「Context（背景）」「Decision（決定）」「Consequences（結果）」「Alternatives Rejected（却下した代替案）」を含むため、なぜその設計を選んだのかが後から検証可能です。
このステージが決めるのは「論理的な構成要素」であり、デプロイ形態（モノリスかマイクロサービスか）は決めません。それは次のUnits Generationの仕事です。また技術スタックの選定やNFRパターンもここでは扱わず、それぞれNFR・インフラ系のステージが担当します。エンティティも「どのコンポーネントが所有し、どんな識別子と属性を持つか」という所有・形状のレベルまでで、データ型やバリデーション制約といった詳細スキーマはConstruction phaseのFunctional Designに委ねられます。
仕組み: 2つの設計成果物とトレーサビリティ
Architect Agentが以下を生成します。
| ファイル | 内容 |
|---|---|
| components.md | コンポーネントのカタログ（責務・依存関係・所有エンティティ）。機械可読なYAMLブロックに加え、Mermaid図とサマリ表を含む |
| decisions.md | ADR（Architecture Decision Record） |
加えて、要件・ストーリーとコンポーネントの対応を記録した
traceability.jsonが出力され、すべてのストーリー（またはフォールバックとして機能要件）がいずれかのコンポーネントでカバーされていることが検証されます。Brownfieldプロジェクトでは、ステージ2.1で生成されたarchitecture.mdやcomponent-inventory.mdを読み込み、既存アーキテクチャとの整合性を確認しながら設計します。Greenfieldでは要件とストーリーが主な入力になります。
この成果物が次のステージ（Units Generation）の主要な入力です。コンポーネント定義がUnitの境界を決め、依存関係がDAGの構造を決めます。
7. 作業単位を切り出し、境界の契約を固め、順序を決める（Units Generation / Contract Design / Delivery Planning）
課題: 設計はできたが「何から着手すべきか」がわからない
Domain Designの出力は「何を作るか」のコンポーネント構造です。しかし、コンポーネント定義がそのまま作業の単位になるとは限りません。1つのコンポーネントが大きすぎて分割が必要な場合もあれば、複数のコンポーネントをまとめて1つの作業として扱うべき場合もあります。さらに、「auth-serviceが完成しないとdashboard-uiに着手できない」という依存関係を無視して並行作業を始めれば、待ちと手戻りが発生します。そして複数のユニットが連携する以上、ユニット間の境界を「どんなデータが、どんな形で、どのプロトコルで流れるか」まで固めておかないと、統合の段階で大きな手戻りが起きます。
解決: 実装可能な粒度に分解し、境界の契約を定め、依存関係から実行順序を導出する
V2ではこの課題をステージ2.7（Units Generation）、ステージ2.8（Contract Design）、ステージ2.9（Delivery Planning）の3段階で解決します。2.7で「何を、どんな粒度で作るか」を定義し、2.8で「ユニット間や外部との境界をどんな契約で結ぶか」を固め、2.9で「どの順番で、どうまとめて作るか」を計画します。Units GenerationとDelivery Planningは常にセットで実行され、
enterprise、feature、mvp、workshopスコープで動きます。仕組み: DAG定義からBolt計画へ
ステージ2.7 — Units Generation（Architect Agent）
コンポーネント設計を実装可能な作業単位（Unit of Work）に分解します。3つの成果物を生成します。
unit-of-work.md — 各Unitの定義です。名前、責務、境界、複雑さの見積もり（S/M/L/XL）、Unit種別（service/spec/ui/packaging/library）を記述します。
unit-of-work-dependency.md — Unit間の依存関係をDAG（有向非巡回グラフ）として記述します。YAML形式の機械可読ブロックを含みます。
1
2
3
4
5
6
7
8
9
10
11
12
13
units:
- name: api-gateway
kind: service
depends_on: []
- name: auth-service
kind: service
depends_on: [api-gateway]
- name: notification-service
kind: service
depends_on: [api-gateway]
- name: dashboard-ui
kind: ui
depends_on: [auth-service, notification-service]この例では、api-gatewayが依存なし、auth-serviceとnotification-serviceがapi-gatewayに依存、dashboard-uiが残り2つに依存しています。
unit-of-work-story-map.md — ステージ2.4で定義されたストーリーとUnitの対応関係を示します。すべてのストーリーがいずれかのUnitにマッピングされ、逆にすべてのUnitが少なくとも1つのストーリーに紐づいていることが検証されます。
ここで重要なのは、2.7が定義するのは「トポロジー（何が何に依存しているか）」であり、実行順序ではないという点です。実行順序を決めるのはステージ2.9です。
ステージ2.8 — Contract Design（Architect Agent）
Units Generationが描いた依存DAGを入力に、ワークフロー全体で一度だけ実行され、システムが守るべき「契約」を固めます（ユニット単位ではなく、境界の集合を一括で扱います）。契約とは境界を越える正式な取り決め——どんなデータが、どんな形（スキーマ）で、どのプロトコルを通じて流れ、異常時に何が起きるか——です。対象となる境界は2種類あります。
- ユニット間境界: システム内部で連携する提供側ユニットと利用側ユニットの取り決め。2つの会社の2チーム間のB2B契約のように、最初から正しくないと統合が手戻りの温床になります。
- 公開／外部API境界: システムの外部（別チーム、パートナー、一般公開）に対して公開するAPIの取り決め。単一ユニットのシステムでも、外部に公開するAPIがあれば、Code Generationの前にここで仕様を固めます。
成果物は
contract-summary.md一つで、すべての境界を一覧化し、各境界に対して同期REST/HTTPならOpenAPI、イベント駆動ならAsyncAPI、共有スキーマならスキーマ定義、といったspecブロックをインラインで埋め込みます。ユニット間境界も外部公開APIもない単一自己完結ユニットの場合は、このステージはスキップされます。ステージ2.9 — Delivery Planning（Delivery Agent）
依存DAGを入力として、Construction phaseの実行シナリオ全体を計画します。Delivery Agentが以下の判断を行います。
- Bolt構成: どのUnitをどのBoltにまとめるか
- Walking Skeleton指定: 最初のBoltでEnd-to-Endスライスを作るか（ステージ2.2で確認した方針に従う）
- 実行順序: リスク優先か、価値優先か、Walking Skeleton優先か
- 並列化の可否: 互いに依存しないBoltを並列実行（Batch）できるか
- 反復戦略: Stage-major（ステージ単位で全Unitを処理）か、Unit-major（Unit単位で全ステージを通す）か
成果物は以下の通りです。
| ファイル | 内容 |
|---|---|
| bolt-plan.md | Boltの順序、含まれるUnit、Walking Skeleton指定、各Boltの完了定義 |
| team-allocation.md | Boltごとのチーム割り当て |
| risk-and-sequencing-rationale.md | なぜこの順序なのかの根拠（WSJF、リスク分析など） |
| external-dependency-map.md | 外部依存とブロック関係 |
チーム割り当ては、Ideation phaseのTeam Formation（ステージ1.5）で定義されたチーム構成を読み込みます。
enterpriseやfeatureスコープではTeam Formationが実行されるためチーム情報が存在する一方、mvpやworkshopスコープではTeam Formationがスキップされ、全BoltをAIエージェント（Developer Agent）が実行するデフォルトが適用されます。Construction phaseが読み込むのは主にunit-of-work-dependency.md（何を作るか）とbolt-plan.md（どの順番で作るか）の2ファイルです。Bolt・Batch・Walking Skeletonの仕組みは、すべてこの2ファイルを起点として動いています。
8. スコープ別の実行パターン
ここまで9つのステージを見てきました。では、スコープによって実行パターンがどう変わるのか整理しておきましょう。
スコープとステージの対応
| スコープ | 2.1 Reverse Engineering | 2.2 Practices Discovery | 2.3 Requirements Analysis | 2.4 User Stories | 2.5 Refined Mockups | 2.6 Domain Design | 2.7 Units Generation | 2.8 Contract Design | 2.9 Delivery Planning |
|---|---|---|---|---|---|---|---|---|---|
| enterprise | BF時 | ○ | ○ | ○ | UI時 | ○ | ○ | ○ | ○ |
| feature | BF時 | ○ | ○ | ○ | UI時 | ○ | ○ | ○ | ○ |
| mvp | BF時 | ○ | ○ | ○ | UI時 | ○ | ○ | ○ | ○ |
| workshop | — | ○ | ○ | ○ | — | ○ | ○ | ○ | ○ |
| infra | — | ○ | ○ | — | — | — | — | — | — |
| bugfix | BF時 | — | ○ | — | — | — | — | — | — |
| security-patch | BF時 | — | ○ | — | — | — | — | — | — |
| poc | BF時 | — | ○ | — | — | — | — | — | — |
| refactor | BF時 | — | ○ | — | — | — | — | — | — |
凡例: ○=実行、BF時=Brownfield時のみ、UI時=UIプロジェクト時のみ、—=スキップ
読み取りのポイント
ステージ2.3（Requirements Analysis）はすべてのスコープで実行されます。これが唯一のALWAYSステージです。
ステージ2.7（Units Generation）と2.9（Delivery Planning）はセットで動き、
enterprise・feature・mvp・workshopという設計・実装を一通り行うスコープで実行されます。その間の2.8（Contract Design）も、ユニット間境界か外部公開APIがある場合に同じ4スコープで動きます。pocは「検証するだけ」というスコープなので、作業分解・契約定義・実行計画の策定はいずれも不要です。bugfixやsecurity-patchは、Requirements Analysis（Brownfieldならその前にReverse Engineering）で問題を構造化するところまでで、ドメイン設計・作業分解・契約定義・実行計画といった設計系ステージはスキップされます。問題の特定に集中し、以降のConstruction phaseで直接修正に入るスコープです。infraはPractices DiscoveryとRequirements Analysisまでを通り、ユーザー向け・設計系のステージはスキップします。成果物の連鎖構造
各ステージの出力が次のステージの入力になる連鎖構造を、簡略化して示します。
Requirements Analysis（2.3）の出力がUser Stories（2.4）とDomain Design（2.6）の両方に流れ、それらがUnits Generation（2.7）に合流します。Units Generationの依存DAGを入力にContract Design（2.8）が境界の契約を固め、Delivery Planning（2.9）が全体を束ねてConstruction phaseに渡す。この連鎖が「段階的分解と各段階での検証」を実現する構造です。
Inception phaseが完了すると、Constructionは
bolt-plan.mdとunit-of-work-dependency.mdを読み込んで実行を開始します。要件から実装計画までの変換が、各段階で人間の承認を経て完了した状態です。まとめ
Inception phaseは「要件とコードの間にある断崖」を、9つのステージで段階的に埋めていくフェーズです。
- 既存コードがあればまず構造を把握し（Reverse Engineering）
- チームの慣習を明文化し（Practices Discovery）
- 要件を構造化して抜け漏れを検出し（Requirements Analysis）
- 開発者に渡せる粒度のストーリーに分解し（User Stories）
- システムを構成する論理的なコンポーネントを特定し（Domain Design）
- 作業単位に切り出して依存関係を定義し（Units Generation）
- ユニット間や外部との境界の契約を固め（Contract Design）
- 実行順序を決定する（Delivery Planning）
各ステージの成果物が次のステージの入力になる連鎖構造をとり、1つの段階で曖昧さが残ったまま次に進むことを防いでいます。スコープによってステージの組み合わせが変わるため、
bugfixのような軽量な変更でもenterpriseのような大規模プロジェクトでも、必要十分な設計工程を経てConstruction phaseに入れる構造です。Series: AI-DLC Workflow V2の解説 (31 articles)
- …
- 10AI-DLC Workflow V2のInception Phase: "何を作るか"を実装可能な粒度に分解する 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