AIに要件定義を任せると何が壊れるか
「AIを使えば要件定義が速くなる」という話を、何度聞いただろうか。
正直なところ、速くはなる。ヒアリング内容の整理、ユースケースの洗い出し、仕様書の初稿生成——これらのタスクは、適切に使えばAIが確実に支援してくれる。
ところが、プロジェクト後半になってから問題が出てくることがある。「動いているが、使えない」システムができていたり、「要件に書いていないこと」で現場が混乱していたりする。
AIを使って要件定義のスピードを上げたにもかかわらず、なぜそうなるのか。
複数のAI駆動プロジェクトを経験してきた結果、いくつかのパターンが見えてきた。
「10倍速く間違える」という問題
まず前提として押さえておきたい視点がある。
AIは、コードを書くスピードを何倍にもできる。要件さえ正しければ、実装速度の向上はそのままプロジェクトのスピードアップになる。
ところが、要件が間違っていたらどうか。
AIは10倍の速さで間違ったコードを作り続ける。修正コストも、技術的負債も、10倍のペースで積み上がる。
ツールが速くなればなるほど、上流の品質が結果に与える影響は大きくなる。要件定義の失敗は、AI時代においては昔より深刻になり得る。
よく起きる5つの失敗パターン
1. あいまいさが構造的に引き継がれる
「ユーザーが使いやすいUIにする」「パフォーマンスを改善する」——こういった記述は、会議でよく出てくる言葉だ。
人間であれば、文脈から「だいたいこういう意味だろう」と補完できる。ところがAIはこういった表現を、あいまいなまま「要件」として受け取ってしまう。
結果、仕様書の中にあいまいな表現が残り、実装フェーズでエンジニアが都度解釈する羽目になる。AIが生成した仕様書は体裁が整っているため、「ちゃんとした文書がある」という安心感が生まれる。それが却ってレビューの目を緩ませることもある。
2. 「書かれていないこと」が落ちる
要件定義で本当に難しいのは、ステークホルダーが「言葉にしていない前提」をすくい上げることだ。
例えば、「メールで通知する」という要件に対して、「営業時間外は送らない」「エラー時はリトライする」「受信者が削除していたらどうするか」——これらは書かれていないことが多い。
人間のファシリテーターは、こうした暗黙の前提を引き出す質問を投げかけながら要件を精緻化していく。AIは与えられた情報から仕様を作ることは得意だが、「何が足りないか」を能動的に掘り起こすのは苦手だ。
実装してから「そこまで考えていなかった」が出てくるのは、たいていこのパターンだ。
3. 矛盾が後から発覚する
要件は一度に決まらない。ヒアリングを重ねるにつれ、異なる部門から矛盾した要求が出てくることもある。
「管理者はすべてのデータを見られる」「個人情報は担当者しか見られない」——これは単純な例だが、現実のプロジェクトではもっと複雑な形で矛盾が潜んでいる。
AIが個別のヒアリング内容をそれぞれ仕様化すると、矛盾した記述が並んだ仕様書ができあがる。体裁が整っているだけに、見落としやすい。
実装後のテストフェーズで「どっちが正しいんですか？」と聞かれて、ようやく発覚するケースも多い。
4. ステークホルダーの「政治」は処理できない
これはツールの問題というより、組織の問題だ。
要件定義は、単なる機能の洗い出しではない。「誰がその機能の優先度を決めるか」「どの部門の意見が通るか」「誰が承認権限を持っているか」——こうした組織上のダイナミクスを処理するプロセスでもある。
AIは、ステークホルダーマップを作ることはできる。しかし、根回しはできないし、部門間の利害調整もできない。
要件が曖昧なまま放置される背景には、「誰が決めるか」が明確でないことが多い。この問題はAIではなく、プロジェクト管理と組織設計の話だ。
5. 要件と実装が乖離していく
AIが仕様書を作り、AIがコードを生成する——このサイクルが速く回ると、要件と実装の間に少しずつズレが生じていく。
コードが更新されても仕様書が更新されない。仕様書が更新されてもコードに反映されない。気づいたときには、「どちらが正しいのか分からない」状態になっていたりする。
これは従来のソフトウェア開発でも起きていた問題 だ。ただ、AIでサイクルが速くなるほど、ズレが拡大するスピードも上がる。
AIが要件定義を「うまくこなせない」根本的な理由
上記のパターンに共通する構造がある。
AIは、与えられた情報を処理することは得意だ。しかし情報を取りに行くことは苦手だ。
要件定義において本当に必要なのは、ステークホルダーが「まだ言語化できていないこと」を引き出し、矛盾を発見し、優先順位を合意し、承認を取り付けるプロセスだ。これは情報処理ではなく、コミュニケーションと合意形成のプロセスだ。
AIは「仕様書を作る」ことはできる。しかし「正しい合意に到達する」ための探索は、まだ人間がリードしなければならない。
では、どうするか
「AIには向かないから使わない」という話ではない。
むしろ逆で、AIを使うからこそ、要件定義の構造を厳密にしておく必要がある。
ひとつの方向性は、要件を「AIが読める形式」で書くことだ。自然言語の仕様書をそのまま渡すのではなく、ユースケース・受け入れ条件・依存関係を構造的に記述する。 この構造が明確であれば、AIはエラーを指摘したり、見落としを検出したりする方向で力を発揮できる。
もうひとつは、要件定義を「AIを使ってレビューする」プロセスとして設計することだ。AIに作らせるのではなく、人間が決めた要件をAIがチェックする。矛盾の検出、網羅性の確認、影響範囲の洗い出し——これらはAIが得意な領域だ。
私たちが実践している仕様駆動開発（SDD）は、このアプローチに近い。AIが理解できる構造に要件を落とし込み、実装との整合性を継続的にチェックできる状態を保つ。速さと品質を両立するための設計だ。
AIを使えば要件定義が「うまくいく」わけではない。AIは、正しく設計された要件定義プロセスをより速く、より精度高く実行することを助けてくれる。
逆に言えば、プロセスが曖昧なままAIを使っても、曖昧さが速く増幅されるだけだ。
AI時代の要件定義で問われるのは、ツールの選択よりも、プロセスの設計力だと感じている。
アツメルでは、AI駆動開発の上流から下流まで一貫して支援しています。要件定義の構造化から実装まで、気になる方はお問い合わせからご連絡ください。
