AI-DLCを完全理解する第3回: 「何を作るか」を決める ― 要件定義はここまで進化した

吉田真吾 (@yoshidashingo) です。

これだけは覚えて帰ってね💡

AI-DLC (AI-Driven Development Life Cycle) は要件定義を「質問ファイル方式」で進める ― チャットではなくファイルで対話する

要件の詳細度は問題の複雑さに応じて3段階に適応する (Adaptive Depth)

ユーザーストーリーはINVEST原則に準拠し、23ステップで計画→生成する

IEEE 830からアジャイルの3C、EARS記法、DDDのユビキタス言語まで ― 要件定義の歴史的な知見との共通点がAI-DLCに見られる

引用元：AI 駆動開発ライフサイクル:ソフトウェアエンジニアリングの再構築 | Amazon Web Services ブログ

現場を把握したら、次は「何を作るか」

第2回では、AI-DLCがプロジェクトの出発点を自動で把握する仕組みを解説しました。Workspace Detectionで現場の状態を調べ、必要ならReverse Engineeringで既存コードを読み解きます。

現場を把握したら、次のステップは「何を作るか」を決めることです。AI-DLCでは、この工程を2つのステージに分けています。

Requirements Analysis (要件分析) : プロダクトオーナーの視点で、機能要件と非機能要件を洗い出す
User Stories (ユーザーストーリー) : 要件をユーザー視点の物語に変換し、受け入れ基準を定義する

Requirements Analysisは14ステージ中のALWAYS (常時実行) ステージです。どんなプロジェクトでも、何を作るかを明確にする工程は省略できません。一方、User StoriesはCONDITIONAL (条件付き実行) ステージで、純粋なリファクタリングやインフラ変更など、ユーザーに直接影響しない作業ではスキップされます。

Requirements Analysis: 「プロダクトオーナー」になるAI

Requirements Analysisステージでは、AIがプロダクトオーナーの視点に立って要件を整理します。プロダクトオーナーとは、アジャイル開発で「何を作るか」の優先順位を決める責任者のことです。

9ステップの流れ

このステージは9つのステップで構成されます:

リバースエンジニアリング結果の読み込み (Brownfieldの場合) : 第2回で生成された既存システムの設計文書を参照します
ユーザーリクエストの分析: 依頼の明確さ (明確/曖昧/不完全) 、種類 (新機能/バグ修正/リファクタリングなど7分類) 、スコープ、複雑さを判定します
要件の深度決定: 問題の複雑さに応じて、Minimal / Standard / Comprehensiveの3段階を選択します
現在の要件の評価: ユーザーが提供した情報 (意図説明、既存ドキュメント、参考資料) を整理します
完全性の分析: 機能要件・非機能要件・ユーザーシナリオ・ビジネスコンテキスト・技術コンテキスト・品質属性の6領域を網羅的に評価します
明確化のための質問を生成: 不明確な領域について、質問ファイルを作成します
要件ドキュメントを生成: 最終的な要件定義書 (requirements.md) を作成します
状態追跡の更新: aidlc-state.mdを更新します
ログと承認要求: 完了を報告し、ユーザーの明示的な承認を待ちます

Adaptive Depth: 3段階の深度

Adaptive Depthは、第2回で触れた「リスクに応じて対応を変える」という原則を具体化した仕組みです。ステップ3の「深度決定」として、AI-DLC全体を貫く設計原則の1つになっています。

深度	使用条件	要件ドキュメントの内容
Minimal	要件が明確でシンプル。バグ修正や小規模な変更	基本的な理解の記録。質問は最小限
Standard	要件に不明点がある。通常の複雑さ	機能・非機能要件を網羅。質問ファイルで不明点を解消
Comprehensive	複数のステークホルダーが関与。高リスクまたはミッションクリティカル	要件トレーサビリティ付きの詳細な要件定義。複数回の質問ラウンド

深度が変わっても、生成される成果物の種類は同じです。Minimalでもrequirements.mdは作成されますし、Comprehensiveでも作成されます。変わるのは中身の詳細度であって、成果物の有無ではありません。

AI-DLCの仕様書はこの原則を端的に表現しています:

「Create exactly the detail needed for the problem at hand — no more, no less.」 (目の前の問題に必要な詳細度を、過不足なく生成せよ)

質問ファイル方式: AI-DLCの特徴的な仕組み

Requirements AnalysisとUser Storiesの両方に共通する、AI-DLCならではの仕組みがあります。質問ファイル方式です。

チャットで聞くのではなく、ファイルで聞く

通常のAIアシスタントは、不明点があればチャットで「認証方式はどうしますか？」と聞きます。AI-DLCはこれを禁止しています。代わりに、専用のMarkdownファイルに質問を書き出し、ユーザーにそのファイル内で回答してもらいます。

具体的にはこんな形式です:

## Question 1
認証方式はどれを採用しますか？

A) ユーザー名とパスワード
B) ソーシャルログイン (Google, Facebook) 
C) シングルサインオン (SSO) 
D) 多要素認証
E) Other ([Answer]: タグの後に記述してください) 

[Answer]:

ユーザーは[Answer]: の後ろに選択肢の記号を記入します。すべての質問に答えたら「完了」と伝え、AIがファイルを読み込んで次に進みます。

なぜチャットではダメなのか

この設計には3つの理由があります。

1. 監査証跡が残る

チャットのやり取りは流れていきますが、ファイルに残した質問と回答はaidlc-docs/ディレクトリに永続的に保存されます。「なぜこの要件にしたのか」を後から追跡できます。これは第1回で解説したaudit.mdによる監査ログと同じ思想です。

2. 選択肢で回答を構造化できる

自由記述の回答は曖昧になりがちです。「だいたいAとBの中間くらい」「たぶんCかな」― AI-DLCはこのような曖昧な回答を検出し、追加の質問で解消を促す設計になっています。選択肢形式にすることで、回答の明確さを構造的に担保します。

3. 矛盾検出と追加質問が可能

AI-DLCには、回答の矛盾と曖昧さを検出する仕組みがあります。例えば「バグ修正」と答えたのにスコープが「システム全体」だった場合、矛盾を指摘する追加質問ファイル (例: requirements-clarification-questions.md) をAIが生成します。すべての矛盾が解消されるまで次のステップに進めません。

この矛盾検出と密接に関連するのが、AI-DLCの仕様書で「overconfidence prevention (過信防止) 」と呼ばれる設計方針です。AIが「たぶんこうだろう」と推測して先に進むのを防ぎ、確認すべきことは徹底的に確認します。矛盾検出が「人間の回答の曖昧さ」を防ぐ仕組みなら、過信防止は「AIの推測の曖昧さ」を防ぐ仕組みです。

一方、ファイルベースの対話はチャットと比べて往復のコストが高く、素早い確認には向きません。また、Markdownファイルを直接編集する必要があるため、技術者以外のステークホルダーが回答者になる場合はファイル編集自体がバリアになりえます。AI-DLCはこれらのトレードオフを認識した上で、監査証跡と構造化を優先する設計判断をしています。

User Stories: 23ステップの全容

Requirements Analysisで要件が固まったら、次はUser Storiesステージです。要件をユーザー視点の物語に変換する工程です。

そもそもユーザーストーリーとは何か

ユーザーストーリーは、ソフトウェアの機能をユーザーの視点から記述する手法です。Kent Beckが1997年にExtreme Programming (XP) の一部として導入し、2001年にはConnextra社のXPチームが現在広く使われるテンプレートを考案しました。

「As a [ユーザーの役割], I want [実現したいこと], so that [得られる価値]」

このテンプレートが強力なのは、技術的な「どう作るか」ではなく、ビジネス的な「なぜ必要か」を記述させる点にあります。「ログイン画面にOAuth2.0を実装する」ではなく、「利用者として、Googleアカウントでログインしたい。パスワードを覚える手間を省くために」と書きます。

Planning (前半) とGeneration (後半)

AI-DLCのUser Storiesステージは、23ステップを前半のPlanning (14ステップ) と後半のGeneration (9ステップ) に分けています。

Planning (ステップ1〜14) では

ユーザーストーリーが本当に必要かを評価します (High/Medium/Skipの3段階判定)
ストーリー計画を作成し、質問ファイルで不明点を解消します
ストーリーの分解方法を5つの選択肢から提示します:
- User Journey-Based: ユーザーの操作フローに沿って分解
- Feature-Based: システムの機能単位で分解
- Persona-Based: ユーザータイプごとに分解
- Domain-Based: ビジネスドメインごとに分解
- Epic-Based: 大きなエピックを階層的にサブストーリーに分解
ユーザーの承認を得てから生成に進みます

Generation (ステップ15〜23) では

承認された計画に基づき、ストーリーとペルソナを生成します
生成されたストーリーはstories.mdとpersonas.mdに保存されます
すべてのストーリーはINVEST原則に準拠します
最終的にユーザーの承認を得て完了します

INVEST原則の組み込み

INVEST原則はBill Wakeが2003年に提唱した、良いユーザーストーリーの6つの条件です。

基準	意味	チェック内容
Independent	独立性	他のストーリーに依存せずに実装できるか
Negotiable	交渉可能性	チームの対話で詳細を調整できる余地があるか
Valuable	価値性	完了時にユーザーに具体的な価値を提供するか
Estimable	見積可能性	実装工数を概算できる程度に具体的か
Small	小ささ	1回のイテレーションで完了できるサイズか
Testable	テスト可能性	明確な受け入れ基準でテストできるか

AI-DLCは、ストーリー生成の必須成果物としてINVEST準拠を明示的に要求しています。ステップ4で「Ensure stories are Independent, Negotiable, Valuable, Estimable, Small, Testable」と定義されており、AIが自律的にストーリーを生成する際のチェックリストとして機能します。

既存手法との比較: 要件定義の進化をたどる

AI-DLCの要件定義アプローチには、ソフトウェア工学の40年以上の歴史を持つ手法との共通点が多く見られます。主要な手法との対比を見てみましょう。

IEEE 830: ドキュメント中心の原点

1984年、IEEEがソフトウェア要求仕様書 (SRS) の標準「IEEE 830」を発表しました。数回の改訂を経て、1998年の改訂版が最も広く参照され、2011年にはISO/IEC/IEEE 29148に統合されました。

IEEE 830は、要件を「機能要件」「非機能要件」「インターフェース要件」に分類する枠組みを確立しました。しかし、IEEE 830に基づくドキュメント中心のアプローチは、実運用では数百ページの仕様書が生み出されることがあり、それを全員が読んで理解するとは限りません。「書くこと＝理解すること」ではないのです。

AI-DLCはIEEE 830の分類体系を受け継いでいます。Requirements Analysisのステップ5では「Functional Requirements」「Non-Functional Requirements」を評価項目として明示的に列挙しています。しかし、ドキュメントを一括で書き上げるのではなく、質問ファイルによる対話的なプロセスで要件を段階的に洗練します。

Ron Jeffriesの3C: 対話を重視する転換点

2001年、Ron JeffriesがExtreme Programmingの文脈で「3C」を提唱しました。

要素	意味	従来との違い
Card (カード)	要件を短く書いたカード	仕様書の代わりに、要件を思い出すためのメモ
Conversation (対話)	ステークホルダーとの議論	ドキュメントではなく、対話で共有理解を構築
Confirmation (確認)	受け入れ基準	完了条件を事前に明確化

3Cの核心は「ストーリーの本質はカードに書かれた文字ではなく、Conversationにある」という主張です。IEEE 830がドキュメントを成果物としたのに対し、3Cは共有理解そのものを成果物と位置づけました。

AI-DLCの構造は、3Cとよく対応しています

Card → stories.mdのテンプレートに基づく簡潔な記述
Conversation → 質問ファイル方式による人間とAIの対話プロセス (ステップ3〜10)
Confirmation → 各ストーリーに必須の受け入れ基準 (acceptance criteria)

ただし、AI-DLCでは「Conversation」の相手が人間同士だけでなく、AIエージェントも含まれます。AIが質問を生成し、曖昧さを検出し、フォローアップを促すことで、対話の質をシステマティックに担保します。この点がAI-DLCの3Cからの発展と位置づけられます。

EARS記法: 安全重要システムからの知恵

2009年、Rolls-Royce社のAlistair Mavinらが「EARS (Easy Approach to Requirements Syntax) 」を発表しました。航空エンジン制御システムの要件定義から生まれた手法です。

EARSは、自然言語の要件にわずかな構文的制約を加えることで、曖昧さを大幅に減らします。5つのパターンがあります:

パターン	キーワード	例
Ubiquitous (普遍的)	なし	「システムは重さXXg以下とする」
Event-driven (イベント駆動)	When	「ミュートが選択されたとき、音声出力を抑制する」
State-driven (状態駆動)	While	「カード未挿入中、『カードを挿入してください』と表示する」
Unwanted behavior (異常系)	If...then	「接続が失われた場合、データをローカルに保存する」
Optional feature (オプション)	Where	「GPS機能を持つモデルでは、位置情報を記録する」

AI-DLCはEARSの構文パターンを明示的には採用していません。しかし、「テスト可能な受け入れ基準」や「曖昧さの排除」という目標は共有しています。特にAI-DLCの質問ファイルにおける矛盾検出 (「バグ修正なのにスコープがシステム全体？」) は、EARSが目指す要件の精密さと同じ方向を向いています。

DDDのユビキタス言語: 用語を統一する力

Eric Evansが2003年に『Domain-Driven Design』で提唱した「ユビキタス言語 (Ubiquitous Language) 」は、開発者とドメインエキスパートが共有する共通言語のことです。

開発者は「Userテーブル」「トランザクション処理」と言い、業務担当者は「顧客」「申込審査」と言います。同じものを指しているのに用語が違うと、要件の伝達で齟齬が生まれます。ユビキタス言語は、この溝を埋めます。

AI-DLCはユビキタス言語の概念を直接的には採用していませんが、要件定義プロセスの中で用語の統一を促す仕組みがあります:

ペルソナの定義: User Storiesステージでpersonas.mdの生成が必須とされており、各ユーザータイプが使う言語や文脈を定義します
ビジネスコンテキストの質問: 質問ファイルの必須カテゴリに「Business Context」があり、ビジネスゴールや成功基準を明確にする過程でドメイン用語が整理されます
ドメインベースの分解: ストーリー分解の5つの選択肢の1つに「Domain-Based」があり、DDDの考え方と直接的に接続しています

40年の進化を1枚の表にまとめる

ここまでの手法を時系列で並べてみましょう。

年代	手法	提唱者	アプローチ
1984年	IEEE 830	IEEE	ドキュメント中心。書いて渡す
2001年	3C	Ron Jeffries	対話中心。カード＋会話＋確認
2003年	INVEST	Bill Wake	ストーリーの品質基準
2003年	ユビキタス言語	Eric Evans	用語の統一
2009年	EARS	Alistair Mavin	構文テンプレートで曖昧さを排除
2025年	AI-DLC	AWS	AI支援型の構造化対話＋適応型深度

ドキュメント → 対話 → AI支援型の構造化対話。この進化の流れの中で、AI-DLCは新しい試みを提示しています。

まとめ

第3回は要件定義を担うRequirements AnalysisとUser Storiesについて説明しました。今回学んだことは以下です。

Requirements Analysis (9ステップ) でAIがプロダクトオーナーの視点に立って要件を整理し、Adaptive Depthで詳細度を調整します
質問ファイル方式は、チャットではなくファイルで対話することで、監査証跡・回答の構造化・矛盾検出を同時に実現します
User Stories (23ステップ) はPlanning→Generationの2段階で、INVEST原則に準拠したストーリーを生成します
要件定義は40年をかけて「ドキュメント → 対話 → AI支援型の構造化対話」へ進化してきました。AI-DLCはこの流れの中で新しい試みを提示しています

次回予告

第4回では、要件が決まったあとの「設計と分割」を取り上げます。Workflow Planning (どのステージを実行するか決める) 、Application Design (コンポーネントとサービスの設計) 、Units Generation (作業単位への分割) の3ステージを、SAFeのPI Planning、C4 Model、マイクロサービスの分割戦略と比較しながら解説します。