AI駆動開発の要件定義。受け入れ条件とインセプション

AI駆動開発でも、要件定義は省けない

AIにコード生成を任せても、何を作り、何を合格とするかは自動では決まりません。曖昧な要望のままでは、生成された実装が意図と一致するかをテストできません。実装後に違いが見つかれば、要件、テスト、コードのどこを直すかも決められません。

AI駆動開発の要件定義では、長い文書を完成させてから実装へ渡すより、目的、制約、受け入れ条件を小さな実装単位へ結び付けます。AIが判断してよい範囲と、人へ戻す条件も要件です。インセプションで最初の境界を置き、実装とテストから得た情報で更新します。

1. 01意図を揃える対象者、課題、成果を言葉にする
2. 02境界を置く範囲、制約、判断者を決める
3. 03受け入れ条件を書く観察できる合否へ変える
4. 04小さく実装するテストとレビューで要件を更新する

インセプションで何を決めるのか

AI-DLCでは、実装前に要件や設計を具体化する工程をインセプションと呼びます。ここで受け入れ条件を持つユーザーストーリーと作業単位を整理し、成果物のつながりを検査するゲートを通してからコンストラクションへ進みます。インセプションは単なるアイデア出しではなく、後工程のAIが推測せずに実装できる材料を揃える位置です。

ただし、最初から全機能を確定する工程ではありません。実装を始めてもよい最小限の共通理解を作る工程です。利用者と解決する問題、最初のスコープ、既存システムとデータの制約、品質の基準、意思決定者を揃えます。

AWS Labsが公開するAI駆動開発ライフサイクル「AI-DLC」の現行文書は、2026年9月3日時点でライフサイクルを5フェーズ、33ステージに分けています。その中のインセプションには、既存コードの解析、要件分析、ユーザーストーリー、設計、作業単位への分解、契約設計、デリバリー計画が置かれています。フェーズの境界では、成果物の欠落や不整合を検査するゲートが動きます。

AI-DLCはAWS Labsが公開する1つの方法であり、公的な標準ではありません。ただし、AI駆動だから要件定義を短絡できるのではなく、後工程のAIが読める成果物へ変える、という考え方は参考になります。現行文書でも要件分析は常に実行するステージで、ユーザー向け機能では受け入れ条件を持つユーザーストーリーへ進みます。

最初に固定するもの、実装から学ぶもの

固定するのは、変更に費用がかかる境界と、チームが勝手に決めてはいけない条件です。画面の細部や文言は動くものを見て変えられますが、個人情報をどこへ送れるか、既存システムへ何を書き込めるか、誰が最終承認するかは先送りできません。

実装前に置くもの	小さな実装で確かめるもの
対象者と解決する問題	画面や対話の分かりやすさ
利用できるデータと禁止事項	実データでの出力の傾向
接続先、権限、承認の境界	操作の順番と確認にかかる時間
最初のスコープと変更の決定者	次の実装単位の優先順位
受け入れ条件と停止条件	条件を満たさない原因と改善案

IPAのアジャイル開発版モデル契約も、全体の要件や仕様を最初に確定せず、機能や優先順位を変更できる進め方を説明しています。一方、契約前には当面の目的、ステークホルダー、プロダクトビジョン、初期計画、完了基準、品質基準、初期バックログ、役割分担を確認します。変えられることと、始める前に合意することは両立します。

受け入れ条件は、第三者が合否を判定できる形にする

受け入れ条件は、担当者の頭の中にある「こう動いてほしい」を、観察できる結果へ変えます。「使いやすい」「正確に答える」では、AIもテスト担当者も合否を判定できません。入力、操作、期待する結果、例外、権限を組にします。

たとえば社内規程への質問に答える機能なら、「社員が規程の対象期間を含む質問をしたとき、参照した文書名と該当箇所を回答に表示する」「根拠を取得できないときは推測で回答せず、確認先を示す」「閲覧権限のない文書を検索結果へ出さない」と書けます。正解例だけでなく、答えてはいけない例と失敗時の動きも含めます。

生成AIの出力には揺れがあるため、1つの正解文と完全一致させるだけでは足りません。代表的な入力と期待する振る舞いを評価データとして残し、致命的な誤り、許容できる表現差、人へ戻す条件を分けます。評価方法や基準値を決められない部分は、決まったふりをせず未確定事項として担当者と期限を置きます。

AIへ渡す要件には、文脈と禁止事項も入れる

人の開発者なら会話から補える前提も、AIには明示します。既存コードの構成、使うライブラリ、変更してよい範囲、守る設計規則、外部APIの契約、性能やアクセシビリティの条件です。ユーザーストーリーと受け入れ条件だけを渡し、リポジトリの規則を渡さなければ、機能は動いても既存の作り方から外れます。

要件ごとに、どの利用者のどの必要から生まれ、どのテストで確かめるかをつなぎます。AI-DLCのプロダクトエージェント文書も、要件をステークホルダーの必要へ追跡できること、テストで検証できること、AIが要件を作り足さないことを原則にしています。プロンプトの長さではなく、必要と検証のつながりが重要です。

AIが判断せず、人へ戻す条件

AI駆動開発では、確認質問を返す条件も工程に組み込みます。目的に複数の解釈がある、法務やセキュリティの判断が要る、既存仕様と新しい要件が衝突する、受け入れ条件を満たす方法が業務ルールを変える。この状態で推測して実装を続けないようにします。

• 業務判断: 優先順位と受け入れるリスクは、責任者が決める
• 制約判断: データ、権限、契約の不明点は、担当部門へ戻す
• 設計判断: 複数案の利点と欠点をAIに出させ、採用理由を人が残す
• 受け入れ判断: テスト結果と評価データを見て、次へ進むか決める

実装速度を上げる方法と、工程のどこに人の判断を残すかはAIコーディングとは何かで整理しています。要件定義では、その判断点を受け入れ条件と停止条件へ書き戻します。

受け入れ条件をAIへ渡す前の確認項目

受け入れ条件は、実装方法の指定ではありません。利用者から見える結果と、守る境界を示します。特定のライブラリや画面構造を理由なく固定すると、AIが選べる実装案を狭めます。反対に、業務上の結果だけを書いて非機能要件を省くと、速さ、権限、ログ、障害時の動きが実装者の判断に残ります。

• 利用者: 誰が、どの権限で操作するか
• 開始条件: どの入力や状態で処理が始まるか
• 期待結果: 画面、データ、通知がどう変わるか
• 例外: 入力不足、接続失敗、根拠不足でどう止まるか
• 証跡: 誰の操作とAIの出力を何に記録するか
• 対象外: 今回は実装せず、別の判断へ送るものは何か

この6項目を全機能へ機械的に埋める必要はありません。変更が利用者やデータへ与える影響に合わせて選びます。外部へデータを送らない画面文言の変更なら、データ処理の条件は不要です。AIが顧客情報を更新するなら、権限、監査、停止、復旧を省けません。

要件と実装の食い違いは、テスト結果から戻す

テストが落ちたとき、すぐにAIへコード修正を頼む前に、要件、テスト、実装のどこが誤っているかを分けます。要件に例外が書かれていなかったなら、コードだけを直すと判断の理由が残りません。受け入れ条件を更新し、関連するテストを変えてから再実装します。

期待結果を変える場合は、最初に合意した目的と矛盾しないかも確認します。目の前のテストを通すために条件を緩め続けると、完成した機能が最初の課題へ答えなくなります。AIは矛盾を見つける補助に使えますが、どの要求を優先するかは責任者の判断として記録します。

要件定義は、実装単位ごとに更新する

最初のスコープは、利用者が一連の流れを試せる最小の単位にします。画面だけ、データ処理だけと層で分けるより、入力から結果確認までを細く通します。動くものから得た事実を、次の受け入れ条件、制約、優先順位へ戻します。

更新時には、要件本文だけでなく関連するテスト、判断記録、対象外の一覧も変えます。古い受け入れ条件を残したままAIへ再実装を頼むと、文書どうしの矛盾をAIに解釈させることになります。誰が変更を承認し、どの成果物を同時に更新するかを決めておきます。

まだ何を作るべきか決まっていない場合は、要件を増やす前に、課題と選択肢を確かめます。作るかどうかの判断はプロダクトディスカバリーとは何か、AIを使った小さな実装から始める相談先はAI受託開発に整理しています。