AIエージェントに要件定義を渡した後に起きること — フィードバックループを設計する
# AIエージェントに要件定義を渡した後に起きること — フィードバックループを設計する
GWが明けた。チームで「よし、今期はAIを本格活用しよう」という機運が高まるタイミングだ。
要件定義にAIエージェントを使ってみた——しかし、うまくいかなかった。そういう声を、受託開発の現場で よく聞くようになった。
多くの場合、問題は「要件定義書をAIに渡した後」にある。渡した瞬間は「あとはAIがやってくれる」と期待する。しかし実際は、AIが生成した成果物を誰もレビューしない、フィードバックを返さない、だから次回も同じ精度のままになる。
要件定義にAIを活かすには、一方向に投げるのではなく、ループを設計することが鍵だ。
なぜ「渡しっぱなし」が機能しないのか
AIエージェントに要件定義書を渡す時、多くのチームが期待するのは「自動で仕様書や設計書を生成してほしい」という一回性の処理だ。
しかしAIが生成した成果物には、必ずといっていいほど「解釈のずれ」が含まれる。
- 背景情報が足りず、AIが誤った前提を置いている
- 業界固有の慣習をAIが知らない
- 要件の優先度が伝わっておらず、重要な機能が軽く扱われている
これはAIの限界ではない。むしろ当然だ。要件定義書は、それを書いた人間の頭の中にある文脈を省略して書かれることが多い。人間同士なら「察してくれる」部分を、AIは正直に「わからない」と扱う。
解釈のずれが放置されると、下流工程でどんどん増幅する。設計書のず れが実装のずれになり、テストのずれになり、最後にリリース直前の大規模修正になる。
ループの設計：3つのフィードバックポイント
AIエージェントに要件定義を渡した後、以下の3つのポイントでフィードバックループを組むことを推奨している。
①「前提の確認」ループ
AIに成果物を生成させる前に、一度前提を問い返してもらう。
具体的には、要件定義書を渡した直後に「この要件を実現するにあたって、私が補足すべき情報を3つ挙げてください」と指示する。
AIが返す質問リストが、そのまま「暗黙知の可視化」になる。「既存システムのデータ形式はどうなっていますか？」「このユーザーは社内ユーザーですか、一般ユーザーですか？」——これらの質問に答える行為が、要件定義書の精度を上げる。
このループを入れるだけで、後工程での手戻りが体感で3割近く減る。要件定義書が完成した「つもり」になっていた段階での穴を、AIが見つけてくれるからだ。
②「構造の検証」ループ
AIに要件を渡した後、生成された仕様書を元の要件に照合させる。
「この仕様書と元の要件定義書を比較し、カバーされていない要件と、要件と矛盾する仕様を指摘してください」という指示だ。
人間がレビューする場合と違い、AIは疲れない。100行の要件定義書と500行の仕様書を突き合わせても、一貫した基準で検証できる。「要件には書いてあるのに仕様に落ちていない」ケースや、「仕様の前提が要件と食い違っている」ケースを機械的に発見できる。
このプロセスは、従来のレビュー工数を大幅に削減する。ただし前提として、要件定義書と仕様書が同じ粒度・同じ構造で書かれている必要がある。「自然言語の要件定義書」と「箇条書きの仕様書」では比較しにくい。構造の標準化が先だ。
③「粒度の調整」ループ
AIが生成した成果物を見て、「粗すぎる」または「細かすぎる」と感じたら、フィードバックを言語化して返す。
「この機能の仕様が抽象的すぎて、実装時に迷う可能性があります。もう1段階具体化してください」あるいは「ここはすでに実装チームが熟知している部分なので、詳細は省いてください」という形だ。
ポイントは、このフィードバック自体を再利用可能な形で蓄積することだ。「このプロジェクトでは画面仕様はwireframe相当の粒度まで落とすこと」「エラーハンドリングはユーザー向けメッセージと開発者 向けログを分けて記述すること」——こうしたフィードバックを「プロジェクト固有のルール」としてシステムプロンプトやコンテキストに組み込むことで、AIの出力が回を追うごとに精度を増す。
ループを回すための「構造化要件定義書」
フィードバックループを設計しても、要件定義書そのものが自然言語の塊だと、AIがうまく扱えない場面が増える。
私たちが実践しているのは、要件定義書を以下の構造で書くことだ。
機能名
概要
（1-2文で目的を記述）
前提条件
- 前提1
- 前提2
正常系フロー
- ユーザーが〇〇をする
- システムが〇〇を返す
異常系・エッジケース
- ケース1: ○○の場合 → ○○を表示
- ケース2: ○○の場合 → ○○に遷移
制約・非機能要件
- パフォーマンス: 〇〇ms以内
- セキュリティ: 〇〇
この構造があると、AIは「前提条件」「正常系」「異常系」という軸でフィードバックを返しやすくなる。「この異常系で、〇〇のケースがカバーされていません」という指摘が具体的になるのだ。
GW明けに試したい、最初の一歩
難しく考える必要はない。
まず、手元にある要件定義書をそのままAIに渡し、「この要件定義書を見て、私が補足すべき情報を5つ挙げてください」と聞いてみることだ。
AIが返す5つの質問が、今の要件定義書の弱点を映す鏡になる。
要件定義にAIを活かすとは、AIに全部やらせることではない。AIを「問いを立てる相手」として使い、人間の思考を引き出すこと——そのループを設計することから始まる。
Atsumellでは、要件定義フェーズへのAI活用支援を行っています。「どこから始めればいいかわからない」という段階からご相談いただけます。まずはお問い合わせフォームからご連絡ください。
