AI-DLC Workflow V2のIdeation Phase: "作ってから考える"をやめる仕組み
「作りたいもの」が曖昧なまま実装に入って、途中で方向転換。そんな経験はありませんか？ AI-DLC Workflow V2のIdeation phaseは「そもそも何を、なぜ作るのか」を固めてから次に進む構造になっています。シリーズ第9回
Series: AI-DLC Workflow V2の解説 (31 articles)
- …
- 9AI-DLC Workflow V2のIdeation Phase: "作ってから考える"をやめる仕組み This article
1. なぜIdeationが必要なのか
課題: 意図が曖昧なまま走り出す
AI-DLC Workflow V2（以降V2）のIdeation phaseを見ていきます。このフェーズは「そもそも何を、なぜ作るのか」を固めるための工程です。
AIによるコード生成が高速になるほど、「とりあえず作ってみる」ハードルは下がります。しかしその結果、何が起きるでしょうか。意図が曖昧なままConstructionに突入し、途中で「そもそもこれ何のために作ってるんだっけ」と立ち止まる。スコープが際限なく広がる。技術的に不可能な方向に3日分の実装を積んでから気づく。これらはAIコード生成を使ったプロジェクトで繰り返し観察されるパターンです。
解決: コードを書く前に「問い」を立てる
V2はIdeation phaseという「コードを1行も書かないフェーズ」を設けました。「何を作るか」「なぜ作るか」「どの範囲で作るか」を人間とAIが対話で固める工程です。Constructionのコード生成はもちろん、Inceptionの要件分析やアーキテクチャ設計よりも手前に位置し、ここで固まった土台が後続フェーズの品質を左右します。
第4回 で5フェーズ・33ステージの全体像を示した際、Ideation phaseは「Validate the initiative（イニシアティブの検証）」と位置づけました。
仕組み: 7ステージの段階的検証と承認ゲート
では、その仕組みの全体像を見ていきましょう。Ideation phaseは7つのステージで構成されています。
| # | ステージ名 | 識別名 | リードエージェント | 実行条件 | 何が決まるか |
|---|---|---|---|---|---|
| 1.1 | Intent Capture & Framing | intent-capture | Product Agent | ALWAYS | プロジェクトの意図と利害関係者 |
| 1.2 | Market Research | market-research | Product Agent | CONDITIONAL | 競合分析とbuild-vs-buy判断 |
| 1.3 | Feasibility & Constraints | feasibility | Architect Agent | CONDITIONAL | 技術的実現可能性と制約 |
| 1.4 | Scope Definition | scope-definition | Product Agent | ALWAYS | スコープ境界とIntent Backlog |
| 1.5 | Team Formation | team-formation | Delivery Agent | CONDITIONAL | チーム構成とモブ計画 |
| 1.6 | Rough Mockups | rough-mockups | Design Agent | CONDITIONAL | ワイヤーフレームとユーザーフロー |
| 1.7 | Approval & Handoff | approval-handoff | Delivery Agent | ALWAYS | Initiative BriefとInceptionへの引き継ぎ |
各ステージの成果物が次のステージの入力になる連鎖構造を取り、段階ごとに承認ゲートを通過しながら具体化していきます。V2の設計原則「User decides, AI executes（人間が決定し、AIが実行する）」はこのフェーズでも同様で、すべてのステージで人間への質問と承認ゲートがあり、AIは情報を整理し選択肢を提示する役割に徹します。
この図ではALWAYSステージを実線の枠で、CONDITIONALステージを点線の枠で表しています。1.1 Intent Captureから始まり、条件に応じて1.2〜1.6を通過し、1.7 Approval & Handoffで承認を得てInception phaseに進む構造です。
2. 意図を捕まえる（Intent Capture & Framing）
課題: 一文の入力から何を読み取ればよいのか
ワークフロー全体の起点となるのがこのステージです。ユーザーが「/aidlc タスク管理APIを作りたい」と入力した瞬間を想像してみてください。この一文には、ビジネス課題も顧客像も成功指標も含まれていません。しかし曖昧なまま先に進めば、後続のすべてが推測の上に積み上がります。
解決: 構造化された質問で意図を引き出す
Product Agent（aidlc-product-agent）がリードし、Architect Agent（aidlc-architect-agent）がサポートとして技術的な観点を補います。エージェントはまず
intent-capture-questions.mdを生成し、以下のような問いを構造化して投げかけます。- どのようなビジネス課題を解決するのか
- 顧客は誰か（内部/外部）。どのような痛みを抱えているか
- 成功とはどのような状態か。どの指標で測るか
- このイニシアティブのトリガーは何か（市場圧力、技術的負債、規制、機会）
- 主要なステークホルダーは誰で、それぞれ何を重視しているか
- スコープや優先度を決定する人、影響を与える人は誰か
- ワークフローが選択したスコープは、ユーザーの意図する製品境界と一致しているか
すべての質問に「未定義」「該当なし」の選択肢があります。決まっていないことは決まっていないと答えればよく、無理に埋める必要はありません。
仕組み: ソースタグ・矛盾検出・センサー検証
ここからが仕組みの核心です。質問ファイルの冒頭には
## Sourcesセクションが置かれ、参照する情報源を明示的に登録します。1
2
3
4
## Sources
- [desc] Initial description: "タスク管理APIをユーザー認証付きで作りたい"
- [scope] Workflow-selected scope: `feature`.
- [memory:M1] `aidlc/spaces/default/memory/org.md#Way of Working`: "We use trunk-based development..."[desc]はユーザーの元の記述、[scope]はワークフローが選択したスコープ、[memory:M<n>]はメモリレイヤーから読み込んだルールです。回答が揃うと、Product Agentは矛盾検出を実行します。たとえば「顧客は社内チーム」と答えつつ「市場シェアの獲得」を成功指標に挙げた場合、その矛盾を検出し、追加質問で解消を図ります。
分析の結果、2つの成果物が生成されます。
- intent-statement.md（意図表明書） — Problem Statement、Target Customer、Success Metrics、Initiative Trigger、Initial Scope Signal
- stakeholder-map.md（ステークホルダーマップ） — 利害関係者、意思決定者 vs 影響者の区分、コミュニケーション要件
両方の成果物には共通ルールが適用されます。すべての主張ブロック（段落、リスト項目、表のデータ行）にソースタグを付与すること。確認できていないが有用な情報は
## Assumptions & Open Questionsセクションに[assumption]タグ付きで記載し、事実と区別します。仮定が残っている場合は追加の確認ステップが走り、「仮定を受け入れる」か「追加質問に変換する」かを選択できます。さらにProduct Lead Agent（aidlc-product-lead-agent）によるアドバイザリーレビューが最大2回反復します。
最後に、3つのセンサーが成果物を自動検証します。
| センサー | 検証内容 |
|---|---|
| claim-sources | すべての主張にソースタグがあるか、参照元がステートやメモリファイルと一致するか |
| required-sections | 必要なH2見出しが揃っているか |
| upstream-coverage | 上流の成果物への参照があるか（このステージは最上流なのでデフォルトでパス） |
センサーは成果物が書き込まれるたびに自動で発火し、結果がaudit logに記録されます。人間が承認する前に、機械的にチェックできることは機械に任せる設計です。
ここで固まるのは意図・ステークホルダー・成功指標の3点です。Ideation内のほとんどのステージがintent-statement.mdを入力として参照するので、フェーズ全体の方向性がここで決まります。
3. 市場と実現性を確認する（Market Research & Feasibility）
課題: 意図が固まっても「外の世界」と「技術の壁」が見えていない
Intent Captureでプロジェクトの意図が固まりました。しかし2つの問いが残っています。「同じ問題を解いている既存サービスはないのか」「技術的に本当に実現できるのか」です。この確認を飛ばして設計に入ると、完成間際で「既存SaaSを使えばよかった」や「この制約の下では不可能だった」と気づくことになります。
解決: 2つのCONDITIONALステージで外部と内部の実現性を検証する
V2はこの検証を2つの独立したステージに分けています。Market Research（1.2）が外部環境を、Feasibility & Constraints（1.3）が技術的実現性を担当します。どちらもCONDITIONALステージであり、プロジェクトの性質によってスキップされます。
| ステージ | 実行される場合 | スキップされる場合 |
|---|---|---|
| 1.2 Market Research | 外部市場ポジショニングやbuild-vs-buy検討が必要 | 内部ツール、バグ修正、リファクタリング |
| 1.3 Feasibility | 統合制約、規制要件、重大な技術的不確実性がある | 技術的リスクがないトリビアルな変更 |
スコープでいえば、
enterpriseとfeatureでは両方実行され、mvpではFeasibilityのみ、pocでは両方スキップされます。仕組み: マルチエージェント構成と成果物の連鎖
Market Research（1.2）の仕組み
Product Agentがリードし、以下を調査します。
- 市場に存在する競合製品やソリューション
- 競合の強み・弱み・価格モデル
- 関連する業界トレンドや規制の変化
- 顧客が最低限期待すること（テーブルステークス）と差別化要因
- Build（自作）vs Buy（購入）vs Partner（提携）の判断材料
成果物は
competitive-analysis.md、market-trends.md、build-vs-buy.mdの3つです。入力としてintent-statementを必須で受け取り、「この意図に対して市場はどうなっているか」を調べる構造になっています。Feasibility & Constraints（1.3）の仕組み
このステージの特徴はマルチエージェント構成です。Architect Agent（リード）に加え、AWS Platform Agent（AWSサービスの観点）とCompliance Agent（規制の観点）がサポートとして参加します。
たとえば「HIPAA準拠が必要」という制約をCompliance Agentが検出し、「その要件を満たすにはAWS GovCloudが必要」とAWS Platform Agentが補足し、Architect Agentが全体の実現可能性判断に組み込む、という流れです。
質問は以下の領域を網羅します。
- 既存システムとの統合対象
- 規制・コンプライアンス要件（PCI、HIPAA、SOC2、データレジデンシーなど）
- チームの技術スタックとスキルプロファイル
- 予算とタイムラインの制約
- 組織的ブロッカー（変更凍結、競合する優先事項など）
成果物は
feasibility-assessment.md（技術的実現可能性の評価）、constraint-register.md（制約の台帳）、raid-log.md（リスク・仮定・課題・依存関係の記録）の3つです。2つのステージの連鎖
Market Research → Feasibilityの順に実行されます。Feasibilityは
competitive-analysisとmarket-trendsをオプション入力として受け取るため、Market Researchの結果が技術的実現可能性の判断に反映されます。Market Researchがスキップされた場合でも、intent-statementだけでFeasibilityは実行可能です。ここで決まるのは「競合状況、build-vs-buy判断、技術的制約、リスクと依存関係」です。次のScope Definition（1.4）がこれらの情報をもとに現実的な境界を引きます。
4. スコープを引く（Scope Definition）
課題: 「何でもやりたい」が手戻りの温床になる
「何をしたいか」が固まり、「何ができるか」も見えました。しかしこの2つの間にギャップがあることは珍しくありません。やりたいことの全部は、予算やタイムラインや技術的制約の中で実現できない。あるいは実現できるが、優先順位をつけなければ全部が中途半端になる。In/Out境界を明示的に引かないまま次のフェーズに進むと、「これもスコープ内ですよね？」という問いが繰り返し発生し、いつまでもConstructionが始まりません。
解決: 境界と優先度を明文化する
Scope DefinitionはALWAYSステージです。Ideation phaseが走るすべてのスコープ（
enterpriseからmvpまで）で実行されます。スコープの境界を明示的に引くことは後続フェーズの品質を左右する決定だからです。Product Agent（リード）がスコープの境界を定義し、Delivery Agent（サポート）がデリバリーの観点から実現可能性とタイムラインを補足します。「やりたいこと」と「間に合うこと」のバランスを2つのエージェントが調整する構造です。
仕組み: scope-documentとintent-backlogの2層構造
質問は境界と優先度に集中します。
- 価値を届ける最小限のスコープは何か
- 必須の機能（must-have）と追加要望（nice-to-have）の区分
- 機能間の依存関係
- 順序の優先方針（リスク優先、価値優先、依存関係優先）
- 特定機能に紐づくハードデッドラインの有無
回答をもとに2つの成果物が生成されます。
scope-document.md（スコープ定義書） — 「何がスコープ内で、何がスコープ外か」を明確に記述します。In/Out境界が曖昧なままだと、Inception以降で手戻りが発生するため、この時点で線を引きます。
intent-backlog.md（Intent Backlog） — スコープ内の項目を優先度付きで整理したバックログです。MoSCoW（Must/Should/Could/Won't）、WSJF（Weighted Shortest Job First）、RICE（Reach, Impact, Confidence, Effort）などの優先度付け手法を使い、各項目に優先度の根拠を付与します。
「Won't Have（this time）」カテゴリが重要です。「今回はやらないが、将来検討する」項目の置き場であり、明示的にスコープ外と宣言して記録に残します。スコープが膨らむのを防ぐうえで「やらない」を書き留めておくことは不可欠です。
intent-backlog.mdはレコードディレクトリにgitコミットされるので、ワークフロー完了後も消えません。ただし次のインテント開始時に過去のWon't Have項目が自動提示されることはありません。振り返りたい場合は、該当インテントの
ideation/scope-definition/intent-backlog.mdを直接確認するか、メモリレイヤー（project.md等）に書き残しておく必要があります。Adaptive Composerとの関係
第5回 で解説したAdaptive Composerはステージ構成（EXECUTE/SKIP）を動的に組み替える仕組みです。Scope Definitionはそれとは異なり、プロジェクトの「製品境界」を定義するステージです。
- Adaptive Composer: 33ステージのどれを実行するかを決める（ワークフロー構造の制御）
- Scope Definition: プロジェクトとして何を含み何を含まないかを決める（製品境界の制御）
異なるレイヤーで動作しており、Adaptive Composerが決めたワークフロー構造の中で、Scope Definitionが製品境界を固めます。
入力として
intent-statementを必須、feasibility-assessmentとconstraint-registerをオプションで受け取ります。Feasibility（1.3）が実行されていれば制約情報がスコープ判断に反映されます。ここで決まるのは「プロジェクトのIn/Out境界と、優先度付きのIntent Backlog」です。scope-documentとintent-backlogは、Team Formation（1.5）、Rough Mockups（1.6）、Approval & Handoff（1.7）のすべてから参照される共通基盤になります。
5. チームとUIの準備（Team Formation & Rough Mockups）
課題: 「誰がやるか」と「どう見えるか」が宙に浮いたまま進む
スコープが固まっても、2つの問題が残ることがあります。ひとつは「この規模の仕事を誰がやるのか」。スキルギャップ、キャパシティ不足、チーム間の依存が見えていない状態で計画を立てるのは危険です。もうひとつは「UIの方向性が共有されていない」。テキストの要件だけでは「3画面で十分なのか」「サイドバーかトップナビか」のレベルですら認識がずれ、Inception以降で手戻りが起きます。
解決: 2つのCONDITIONALステージで実行体制とUIの合意を取る
V2はTeam Formation（1.5）とRough Mockups（1.6）を独立したCONDITIONALステージとして設けています。
| ステージ | 実行される場合 | スキップされる場合 |
|---|---|---|
| 1.5 Team Formation | チーム構成が計画上重要な場合 | ソロ開発者、小規模チーム |
| 1.6 Rough Mockups | ユーザー向けUIがある場合 | API/バックエンド/インフラのみ |
スコープでいえば、Team Formationは
enterpriseとfeatureで実行され、Rough Mockupsはenterprise、feature、mvpで実行されます。仕組み: 専門エージェントによる計画とレビュー
Team Formation（1.5）の仕組み
Delivery Agent（aidlc-delivery-agent）がリードします。技術選定や要件定義ではなく「誰が何をやるか」というデリバリー計画の領域だからです。質問は以下をカバーします。
- 利用可能なチームとメンバー、現在のキャパシティと稼働率
- 必要なスキル vs 利用可能なスキルのギャップ
- 同じ人材プールから引かれる競合イニシアティブ
- 望ましいチームトポロジーとタイムゾーン
- 外部パートナーやコントラクターの必要性
成果物は
team-assessment.md（チーム可用性評価）、skill-matrix.md（スキルマトリクス）、mob-composition.md（モブ構成計画）の3つです。これらはInceptionのDelivery Planning（2.9）で直接参照され、どのBoltをどのチームが担当するかの実行計画の基盤になります。Team Formationがスキップされた場合、Delivery Planningは「全BoltをAIエージェント（Developer Agent）が実行する」というデフォルト割り当てを適用します。
Rough Mockups（1.6）の仕組み
Design Agent（aidlc-design-agent）がリードし、Product Agent（aidlc-product-agent）がサポートとして製品要件の観点を補います。さらにProduct Lead Agent（aidlc-product-lead-agent）がレビューアとして品質を検証します。レビューはアドバイザリーレベルで最大2回反復します。Intent Capture（1.1）と同様にレビューアが設定されている数少ないステージです。
確認する内容は以下です。
- 主要なユーザーエントリーポイントとキー画面
- コアユーザーフロー（ハッピーパス）
- 情報階層の構造
- 既存のブランドガイドラインやデザインシステム
- サポートすべきデバイスやフォームファクター
- アクセシビリティ要件（WCAGレベル、スクリーンリーダー対応、キーボードナビゲーション）
成果物は
wireframes.md（低忠実度ワイヤーフレーム）とuser-flow.md（コアユーザーフロー）です。ワイヤーフレームには各画面ごとに1行のアクセシビリティ注記（見出しレベル、ランドマークリージョン、キーボードエントリーポイント）が含まれます。覚えておいてほしいのは、このステージは「ラフ」な段階だということです。InceptionのRefined Mockups（2.5）で詳細なUI仕様が改めて定義されます。
- 1.6 Rough Mockups（Ideation）: 機能仕様がまだ決まっていない段階で、画面構成とフローの「方向性」を合意する
- 2.5 Refined Mockups（Inception）: Requirements AnalysisとUser Storiesで機能仕様が決まった後に、コンポーネントレベルの「詳細」を確定する
2.5は1.6の出力（wireframes, user-flow）を入力として受け取り、機能仕様を重ねて詳細化する関係です。テキスト仕様やASCIIワイヤーフレームだけでは認識のズレが残る場合、このステージ内でHTML/CSS/JSの動くプロトタイプを生成させ、操作しながら方向性を確認するのも有効です。
6. 承認ゲートでInceptionへ（Approval & Handoff）
課題: 成果物がバラバラのまま次のフェーズに渡ってしまう
ここまでのステージで、意図・市場・実現性・スコープ・チーム・UIそれぞれの成果物が生成されました。しかしこれらが個別に存在するだけでは、Inception phaseの各ステージが「全体として何が決まったのか」を把握しづらくなります。また、成果物間で矛盾が残ったまま先に進むリスクもあります。
解決: 集約・検証・承認の3ステップで引き継ぐ
Approval & Handoff（1.7）はIdeation phaseの最終ALWAYSステージです。Delivery Agent（リード）とProduct Agent（サポート）が、ここまでの全成果物を集約し、整合性を検証し、人間の最終承認を得てInceptionに引き継ぎます。
enterpriseとfeatureスコープで実行されます。pocではIdeation phase自体がIntent Captureのみに短縮されるため到達せず、mvpでもこのステージはスコープ外です。仕組み: Initiative Brief・フェーズ境界検証・Go/No-Go判断
入力の集約
このステージが受け取る上流成果物は他のステージより多くなっています。
- 必須入力: intent-statement、stakeholder-map（1.1から）、scope-document、intent-backlog（1.4から）
- オプション入力: competitive-analysis（1.2から）、feasibility-assessment、constraint-register（1.3から）、team-assessment（1.5から）、wireframes（1.6から）
CONDITIONALステージの成果物はオプション入力として定義されているため、スキップされたステージがあっても動作します。
成果物の生成
集約した情報から2つの成果物が生成されます。
- initiative-brief.md（イニシアティブブリーフ） — Ideation phase全体の「ワンページャー」。意図と課題の要約、市場検証の概要、実現可能性とリスクのハイライト、スコープの境界、UIコンセプト（該当する場合）、チーム計画、Go/No-Goの判断材料を1つのドキュメントにまとめます
- decision-log.md（決定ログ） — Ideation phase中に行われたすべての決定を記録。「何を」「なぜ」「いつ」決めたかのトレーサビリティを提供します
フェーズ境界検証（Phase Boundary Verification）
Ideation → Inceptionの境界で自動検証が走ります。
- Intent → Scope → Intent Backlogの一貫性
- すべてのスコープ項目にFeasibilityの裏付けがあること
検証結果は
verification/phase-check-ideation.mdに書き出され、audit logにPHASE_VERIFIEDとして記録されます。検証に通らない場合、問題箇所が明示され、修正してから再度承認を試みる流れになります。Go/No-Go判断
最終ゲートでユーザーに提示される選択肢は3つです。
- Approve（承認） — Inception phaseに進む
- Request Changes（修正依頼） — フィードバックを付けて修正を要求する
- Reject Initiative（却下） — ワークフローを終了する
「Reject Initiative」はIdeation phase固有の選択肢です。他のステージの承認ゲートにはApproveとRequest Changesの2択しかありませんが、このステージではプロジェクト自体を中止する判断が可能です。市場調査や実現可能性評価の結果、「やらない」という結論に至ることも正当な成果だからです。
承認されれば、initiative-briefとdecision-logが引き継ぎ文書として機能し、Inceptionの最初のステージ（Reverse EngineeringまたはPractices Discovery）が始まります。
7. スコープ別の実行パターン
課題: すべてのプロジェクトに同じ検証を適用すると過剰か不足になる
バグ修正に7ステージのIdeationは不要です。一方、全社プラットフォームの構築で意図の記録だけで済ませたら、後続フェーズで確実に破綻します。プロジェクトの規模と性質によって「適切な検証量」が異なるという事実は、固定長のプロセスでは対応できません。
解決: スコープがIdeation phaseの「厚さ」を自動的に決める
V2ではスコープに応じてどのステージを実行するかが事前に定義されています。
| スコープ | 実行されるステージ |
|---|---|
| enterprise | 全7ステージ |
| feature | 全7ステージ |
| mvp | Intent Capture, Feasibility, Scope Definition, Rough Mockups（4ステージ） |
| poc | Intent Captureのみ（1ステージ） |
| bugfix, refactor, infra, security-patch | Ideation phase自体がほぼスキップ |
仕組み: ALWAYS/CONDITIONAL分類とAdaptive Composerの組み合わせ
この自動スケーリングを支えているのは2つの仕組みです。
ALWAYS/CONDITIONAL分類
- ALWAYS（必ず実行）: 1.1 Intent Capture、1.4 Scope Definition、1.7 Approval & Handoff
- CONDITIONAL（条件付き実行）: 1.2 Market Research、1.3 Feasibility、1.5 Team Formation、1.6 Rough Mockups
CONDITIONALステージのスキップ条件を整理します。
| ステージ | スキップ条件 |
|---|---|
| 1.2 Market Research | 外部市場ポジショニングが不要（内部ツール、バグ修正、リファクタリング） |
| 1.3 Feasibility | 技術的リスクが低く、統合制約や規制要件がない |
| 1.5 Team Formation | ソロ開発者や小規模チームで、構成計画が不要 |
| 1.6 Rough Mockups | UIがないAPI/バックエンド/インフラのみのプロジェクト |
Adaptive Composerによるカスタム構成
第5回 で解説したAdaptive Composerでカスタムスコープを構成する場合、7ステージのEXECUTE/SKIPを個別に制御できます。定義済みスコープのパターンが合わないプロジェクトでは、Composerでステージ構成を調整すればよいということです。
pocの設計意図
pocはIntent Captureだけが実行されて次のフェーズに進みます。「requirements-analysisだけでよくない？」と思うかもしれませんが、pocは「これ動く？」という1つの問いに答えるスコープです。requirements-analysisは「何を作るか」の要件整理であり、「そもそも何を証明しようとしているのか」の意図記録はintent-captureが担います。その問いを立てる起点として、最小パスに残されています。まとめ
Ideation phaseの各セクションで見てきた「課題→解決→仕組み」を振り返ります。
| # | ステージ | 課題 | 解決 | 主な仕組み |
|---|---|---|---|---|
| 1.1 | Intent Capture | 一文の入力から何を読み取ればよいか | 構造化された質問で意図を引き出す | ソースタグ、矛盾検出、センサー検証 |
| 1.2 | Market Research | 外部環境が見えていない | 競合とbuild-vs-buyを調査する | Product Agentによる市場分析 |
| 1.3 | Feasibility | 技術的な壁が見えていない | マルチエージェントで実現性を検証する | Architect + AWS Platform + Compliance |
| 1.4 | Scope Definition | 境界が曖昧でスコープが膨らむ | In/Outと優先度を明文化する | scope-document + intent-backlog |
| 1.5 | Team Formation | 誰がやるか宙に浮いている | キャパシティとスキルギャップを分析する | チーム評価 + モブ構成計画 |
| 1.6 | Rough Mockups | UIの認識がずれている | 低忠実度のワイヤーフレームで合意する | ワイヤーフレーム + ユーザーフロー |
| 1.7 | Approval & Handoff | 成果物がバラバラのまま次へ渡る | 集約・検証・承認の3ステップで引き継ぐ | Initiative Brief + フェーズ境界検証 |
Inception Phaseとの接続
Inceptionが読み込むIdeation成果物を整理します。
- intent-statement.md — Requirements Analysis（2.3）が受け取り、構造化された要件に変換する
- scope-document.md / intent-backlog.md — Scope Definitionの境界とBacklogがInception全体の枠組みになる
- feasibility-assessment.md / constraint-register.md — 技術的制約がDomain Design（2.6）に反映される
- wireframes.md / user-flow.md — Refined Mockups（2.5）の入力として詳細化される
- initiative-brief.md — Delivery Planning（2.9）がイニシアティブ全体の文脈を把握する際に参照する
「コードを書かないフェーズ」の価値
Ideation phaseはコードを生成しません。マークダウンの成果物と質問ファイルだけが出力です。「早くコードを書いてほしい」と感じるかもしれません。
しかし、ここで固めた意図・スコープ・制約がConstructionまで一貫して参照されることで、「何を作っているのかわからなくなる」「スコープが際限なく広がる」「技術的に不可能な方向に進んでしまう」といった問題を構造的に防いでいます。
すべてのステージに承認ゲートがあること。すべての主張にソースタグが付くこと。フェーズ境界でトレーサビリティが検証されること。これらが「人間が決定し、AIが実行する」の具体的な仕組みです。
pocなら1ステージで完了し、enterpriseなら7ステージすべてが走る。プロジェクトの規模と性質に応じて自動的にスケールする構造が、過不足のない検証を実現しています。Series: AI-DLC Workflow V2の解説 (31 articles)
- …
- 9AI-DLC Workflow V2のIdeation 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