AI-DLC Workflow V2の5フェーズ：33ステージの全体地図とスコープによる使い分け
AI-DLC Workflow V2は5フェーズ・33ステージで構成されている。でも全部やるの？ いいえ、スコープを選べば自動的に絞られます。この記事でフェーズの全体像を把握し、自分のプロジェクトに合った使い方を見つけてください。シリーズ第4回。
Series: AI-DLC Workflow V2の解説 (31 articles)
- …
- 4AI-DLC Workflow V2の5フェーズ：33ステージの全体地図とスコープによる使い分け This article
1. はじめに
この記事はAI-DLCシリーズの第4回です。第1回 ではV1からV2への設計の進化を、第2回 ではKiro CLIでのQuick Startを、第3回 ではClaude CodeでのQuick Startを扱いました。
今回のテーマは「5フェーズ・33ステージの全体地図」です。V2のワークフローがどう構成されているのか、各フェーズが何を担っているのか、そしてスコープによってどう絞り込まれるのかを見ていきます。
第2回でV2を動かしたとき、
/aidlcを実行するとInitializationが自動で走り、Intent Captureで対話が始まったのを覚えているでしょうか。あの体験の裏で33ステージのうちどれが動いていたのか。この記事を読むと、その全体像が見えてきます。2. V1の3フェーズ構成
V1は3フェーズで構成されていました（V1 README ）。
| フェーズ | 目的 |
|---|---|
| Inception | 何を作り、なぜ作るのかを決める。要件分析、ユーザーストーリー作成、ドメイン設計、ユニット分割 |
| Construction | どのように作るかを決め、実装する。詳細設計、コード生成、ビルド、テスト、品質保証 |
| Operations | デプロイと運用監視（V1時点では将来構想として位置づけ） |
シンプルな3段階で、プロジェクトの複雑さに応じて適応的に動作する設計でした。V2ではこの3フェーズがどう変化したのかを見ていきましょう。
3. V2で5フェーズになった背景
V2では3フェーズを5フェーズに再編しています。
変化のポイントは3つあります。
Initializationの分離
V1ではワークスペースの検出や状態初期化がフェーズの中に暗黙的に含まれていました。V2ではこれを独立したPhase 0として分離し、3ステージで自動実行します。ユーザー操作なしに完了するブートストラップ処理を、開発判断を伴うフェーズから切り離した形です。
IdeationとInceptionの分離
V1のInceptionは要件分析からドメイン設計・ユニット分割までを一つのフェーズで扱っていました。V2では「より粒度の細かい、組み合わせ可能な構成要素」という設計方針のもと、Ideation（意図の捕捉、実現可能性評価、スコープ定義、承認）とInception（要件分析、アーキテクチャ設計、ユニット分解、デリバリー計画）に分かれています。Ideationの最終ステージで承認を得てからInceptionに進む構造により、詳細化に入る前の判断ポイントが明確になっています。
Operationの実装
V1では将来構想だったOperationsフェーズを、V2では7ステージを持つ完全なフェーズとして実装しています。
4. Phase 0: Initialization
目的: ワークスペースをブートストラップする。
| # | ステージ | 説明 |
|---|---|---|
| 0.1 | Workspace Scaffold | インテントの記録ディレクトリを生成する |
| 0.2 | Workspace Detection | プロジェクトの言語・フレームワーク・ビルドシステムを検出する |
| 0.3 | State Initialization | ステートファイルと監査ログを初期化し、ルーティングを開始する |
3つのステージすべてが承認ゲートなしで自動実行されます。既存プロジェクトの言語・フレームワーク検出、状態ファイルの生成、監査ログの初期化がここで行われます。
第2回の記事で
/aidlcを実行した瞬間に走っていたのが、まさにこのフェーズです。ユーザーは何も意識する必要がなく、次のIdeationフェーズで初めて対話が始まります。5. Phase 1: Ideation
目的: イニシアティブを検証する。意図を捕捉し、実現可能性を評価し、スコープを定義し、承認を得る。
| # | ステージ | 説明 | 実行条件 |
|---|---|---|---|
| 1.1 | Intent Capture & Framing | ユーザーの説明から意図を構造化し、問題定義・顧客・成功指標を明確にする | 常に実行 |
| 1.2 | Market Research | 競合分析、Build vs Buy判断を行う | 条件付き |
| 1.3 | Feasibility & Constraints | 技術的実現可能性を評価し、制約とリスクを洗い出す | 条件付き |
| 1.4 | Scope Definition | 作る範囲・作らない範囲を定義し、インテントバックログを作成する | 常に実行 |
| 1.5 | Team Formation | チーム構成とモブ編成プランを決定する | 条件付き |
| 1.6 | Rough Mockups | ワイヤーフレーム、ユーザーフロー、コンセプトデッキを作成する | 条件付き |
| 1.7 | Approval & Handoff | Ideationフェーズの成果物を集約し、次フェーズへの承認を得る | 常に実行 |
このフェーズの核になるのは2つのステージです。
Intent Capture & Framing
ユーザーの説明から「何を実現したいのか」を構造化します。問題定義、ターゲット顧客、成功指標を明確にし、以降のすべてのステージの起点になります。第2回で体験した最初の対話がこれです。
Scope Definition
作る範囲と作らない範囲を定義します。ここで選ばれたスコープが、後続のどのステージを実行するかを決定します（スコープについては後のセクションで詳しく見ます）。
6. Phase 2: Inception
目的: 要件を詳細化する。コードベースの分析、要件の引き出し、ドメイン設計、作業単位への分解、コンポーネント間の契約定義、デリバリー計画の策定。
| # | ステージ | 説明 | 実行条件 |
|---|---|---|---|
| 2.1 | Reverse Engineering | 既存コードベースをスキャンし、構造を解析する | Brownfield（既存コードベースがある）プロジェクトのみ |
| 2.2 | Practices Discovery | チームの開発プラクティスを検出・確認し、ルールとして記録する | 条件付き |
| 2.3 | Requirements Analysis | 要件を構造化し、テスト可能な形式に整理する | 常に実行 |
| 2.4 | User Stories | ペルソナを定義し、ユーザーストーリーを作成する | 条件付き |
| 2.5 | Refined Mockups | 高精度モックアップとインタラクション仕様を作成する | 条件付き |
| 2.6 | Domain Design | システムの論理的な構成要素（コンポーネント）を特定・詳細化し、ADR（アーキテクチャ決定記録）を作成する | 条件付き |
| 2.7 | Units Generation | 要件をユニット（作業単位）に分解し、依存関係の順序を定義する | 常に実行 |
| 2.8 | Contract Design | コンポーネント間のインターフェース契約を定義する | 条件付き |
| 2.9 | Delivery Planning | ユニットをBoltにグルーピングし、実行順序を計画する | 常に実行 |
いくつかの代表的なステージを見ていきましょう。
Reverse Engineering
既存コードベースがあるプロジェクトで実行されます。開発エージェントがコードをスキャンし、アーキテクトエージェントがその結果を構造化して以降の設計判断に活用します。パイプライン方式（2つのエージェントが順番に処理する）で動作します。
Units Generation
要件をユニット（作業単位）に分解します。各ユニットは独立して設計・実装できる単位で、「AはBより先に完了する必要がある」といった依存関係の順序が定義されます。この順序が次のDelivery Planningで実行計画を決める入力になります。
Delivery Planning
ユニットをBoltにグルーピングし、実行順序を決めます。依存関係を考慮して並列実行可能なBoltを特定し、Constructionフェーズの実行計画を組み立てます。
7. Phase 3: Construction
目的: ソリューションを構築する。設計、実装、テストをレビュー可能な単位（スライス）で行う。
| # | ステージ | 説明 | 実行単位 |
|---|---|---|---|
| 3.1 | Functional Design | ビジネスロジックモデルとビジネスルールを設計する | Bolt単位 |
| 3.2 | NFR Requirements | セキュリティ・パフォーマンス・信頼性の非機能要件を定義する | Bolt単位 |
| 3.3 | NFR Design | 非機能要件の設計仕様を作成する | Bolt単位 |
| 3.4 | Infrastructure Design | インフラ仕様とIaCの設計を行う | Bolt単位 |
| 3.5 | Code Generation | アプリケーションコードとコードドキュメントを生成する | Bolt単位 |
| 3.6 | Build and Test | 統合テストを実行し、品質レポートを生成する | 全体で1回 |
| 3.7 | CI Pipeline | CI設定と品質ゲートを構築する | 全体で1回（条件付き） |
Constructionの特徴はBolt方式です。
ホワイトペーパーではBoltはスプリントに相当する高速イテレーションとして導入されましたが、V2の実装ではステージ3.1〜3.5を一つのユニット（または依存関係で結ばれた小グループ）に対して一巡させる実行単位として使われています。一度にすべてのユニットを実装するのではなく、Bolt単位で少しずつ積み上げていきます。
最初のBoltはWalking Skeleton、アーキテクチャを証明する最小のエンドツーエンドの単位です。これが承認されると、自律度選択プロンプト（ラダープロンプト）が一度だけ発動します。「残りのBoltを自律的に実行するか、毎回承認ゲートを設けるか」を選択でき、その選択はワークフロー終了まで維持されます。第1回で解説したインナーループ（AIによる自己検証）が本領を発揮するのは、ここで「自律的に実行」を選んだときです。
Build and Testは全Boltの完了後に一度だけ実行され、統合テストと品質レポートを生成します。
8. Phase 4: Operation
目的: デプロイと運用。デプロイパイプラインの構築、環境プロビジョニング、可観測性の設定、フィードバックループの確立。
| # | ステージ | 説明 | 実行条件 |
|---|---|---|---|
| 4.1 | Deployment Pipeline | デプロイパイプラインの設定、デプロイ戦略、ロールバック手順書を生成する | 条件付き |
| 4.2 | Environment Provisioning | 環境インベントリと検証レポートを作成する | 条件付き |
| 4.3 | Deployment Execution | デプロイを実行し、スモークテストとヘルスチェックを行う | 条件付き |
| 4.4 | Observability Setup | ダッシュボード、アラーム、SLO（サービスレベル目標）設定を構築する | 条件付き |
| 4.5 | Incident Response | SSMランブック、インシデント計画、エスカレーションマトリクスを作成する | 条件付き |
| 4.6 | Performance Validation | 負荷テストを実行し、非機能要件の検証マトリクスを作成する | 条件付き |
| 4.7 | Feedback & Optimization | SLOレポートとコスト分析を作成し、改善点を特定する | 条件付き |
7つのステージすべてが条件付き実行です。mvp、poc、bugfix、refactorスコープではフェーズ全体がスキップされます。
Deployment Pipelineはデプロイパイプラインの設定とデプロイ戦略、ロールバック手順書を生成します。Observability Setupはダッシュボード、アラーム、SLO設定を構築します。
最終ステージ（Feedback & Optimization）の承認でワークフローは完了します。改善点が見つかった場合は、新しいIdeationサイクル（Phase 1）として開始することもできます。
9. 9つのプリセットスコープ
ここまでで5フェーズの全体像を見てきました。でも「33ステージを毎回全部やるの？」と思った方、安心してください。V2ではこの仕組みを「スコーピング」と呼んでいます。定義済みスコープを選ぶだけで、ステートマシン上の経路（通るステージの組み合わせ）が決まります。プリセットスコープが9つ用意されており、選択するだけで実行ステージが自動的に絞られます。
| スコープ | 用途 | ステージ数 | 深度 |
|---|---|---|---|
| enterprise | 規制対応のエンタープライズ機能。完全な監査証跡とコンプライアンスレビューを含む | 33 / 33 | Comprehensive |
| feature | 任意サイズの新機能開発。スコープが特定できない場合のデフォルト | 33 / 33 | Standard |
| mvp | グリーンフィールドのMVP構築。設計・実装は完全に行うが、後半の運用ステージをスキップ | 23 / 33 | Standard |
| workshop | ワークショップ・研修用。スコープは事前決定済みの前提で、Ideationをスキップ | 26 / 33 | Standard |
| infra | インフラ変更（CDK更新、環境構築、コスト最適化）。ユーザー向けステージをスキップ | 13 / 33 | Standard |
| security-patch | CVEやセキュリティ脆弱性への対応。セキュリティ関連ステージを重点的に実行 | 10 / 33 | Minimal |
| poc | 実現可能性の素早い検証。大部分のIdeation・Inceptionをスキップ | 8 / 33 | Minimal |
| refactor | 機能変更なしのコード整理・再構成 | 8 / 33 | Minimal |
| bugfix | 特定のバグ修正。意図確認からコード生成・テストまでの最短経路 | 7 / 33 | Minimal |
スコープは
/aidlc実行時にプロジェクトの説明から自動推定されるか、--scope <name>で明示的に指定できます。ポイントは、同じフレームワークがプロジェクトの規模に応じて伸縮するということです。小さなバグ修正に33ステージを走らせる必要はなく、
bugfixを選べば7ステージで完結します。逆に規制対応の大規模機能ならenterpriseを選び、コンプライアンスやセキュリティレビューを含む全ステージを実行します。深度（Depth）の列にも注目してください。Comprehensive / Standard / Minimalの3段階があり、スコープごとにデフォルトが設定されています。これは各ステージが生成するアーティファクトの詳細度を制御します。
--depth <level>で上書きすることもできます。
10. まとめ
ここまでで、V2の5フェーズ・33ステージの全体像を見てきました。
- Initialization（3ステージ）: 自動ブートストラップ。ユーザー操作不要
- Ideation（7ステージ）: イニシアティブを検証する。意図の捕捉からスコープ定義まで
- Inception（9ステージ）: どう組み立てるかを固める。要件分析からデリバリー計画まで
- Construction（7ステージ）: Bolt方式でレビュー可能な単位（スライス）を積み上げる
- Operation（7ステージ）: デプロイパイプラインからフィードバックループまで
そして9つのプリセットスコープにより、7〜33ステージの間で実行範囲が自動的に調整されます。フェーズの全体像を把握した上で、自分のプロジェクトに合ったスコープを選ぶところから始めてみてください。
Series: AI-DLC Workflow V2の解説 (31 articles)
- …
- 4AI-DLC Workflow V2の5フェーズ：33ステージの全体地図とスコープによる使い分け 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