要件定義でAIが「効かない」プロジェクトの共通点
「AIを入れたのに、要件定義が全然楽にならない」
そういう声を、ここ最近よく聞く。ツールは試した、プロンプトも工夫した、でも結局レビューで大量の指摘が出て、人が書いたほうが早かった——そんな経験を持つPMやコンサルタントは、おそらく少なくない。
原因は「AIが未熟だから」ではない。むしろ逆だ。問題は、AIを使う側の「渡し方」にある。
自社で実際にAIエージェントを要件定義プロセスに組み込んできた経験から言うと、AIが効くかどうかは、ツールの性能よりもプロジェクトの「構造」に左右される。今回はその構造的な問題を3つに絞って整理し、現場で使える処方箋まで書いていく。
AI が上流工程で機能しない3つの構造的な問題
問題1: 要件が「暗黙知」のまま存在している
要件定義の場に慣れた人なら分かると思うが、議論の中の「重要な情報」は、たいてい資料には書かれていない。
「あの件は前回のMTGで合意した」「うちの業界では常識だから書かなくていい」「社長がやりたいことは空気で分かる」——そういう暗黙の前提が、日本の開発プロジェクトには山積している。
AIは文書に書かれたことしか読めない。暗黙知が多いプロジェクトにAIを入れても、AIが生成するのは「書かれた情報から推測した要件」であり、実際のステークホルダーの意図とは大幅にズレる。
これは、AIの問題ではなく、要件の可視化ができていないプロジェクトが持つ構造的な欠陥だ。AIが入ったことで初めて、「そもそも要件が言語化されていなかった」という事実が浮かび上がってくる。
問題2: AIに渡すインプットが定義されていない
「ChatGPTに要件書かせてみたけど、ざっくりしすぎて使えなかった」という話を聞く。こういうケースはほぼ例外なく、インプットの設計が曖昧だ。
AIに「要件を書いて」と頼むのは、新入社員に「いい感じの仕様書を作って」と言うのと同じだ。どんな優秀な人でも、背景情報なしでは動けない。
AIが要件定義で力を発揮するのは、以下の情報が事前に揃っているときだ:
- As-Is（現状）: 今の業務フローと、どこに摩擦があるか
- To-Be（理想）: 解決後にどういう状態になっていたいか
- 制約条件: 予算・スケジュール・法律・既存システムとの接続条件
- 非機能要件のヒント: 処理速度、可用性、セキュリティレベルなど
- ステークホルダーの優先度: 誰の何の問題を最優先で解くか
これらが構造化された形でAIに渡されていれば、AIは精度の高い要件のたたき台を出せる。逆に、MTGの音声データや議事録の断片だけを渡しても、AIはノイズに埋もれた情報から核心を拾うことができない。
問題3: 「完成」の基準がない
要件定義の成果物に「完成」はあるのか、という問いは哲学的に聞こえるが、実務的には重要だ。
AIが要件書のドラフトを生成した後、「これで十分か」を判断する基準が人間側にないと、レビューは果てしなく続く。「なんか足りない気がする」「もっと詳しく書けるはずだ」という感覚的なフィードバックは、AIには処理できない。
これはAIを使わ ないプロジェクトでも起きる問題だが、AIを入れると生成のスピードが上がる分、曖昧な基準が「高速で問題を再生産し続ける」状態になる。
要件定義の完成基準として使えるのは:
- 機能要件: ユーザーストーリーが「誰が / 何を / なぜ」の形式で書かれているか
- 非機能要件: 数値で表現できているか（「速いこと」ではなく「3秒以内」）
- 矛盾チェック: 別の要件と論理的に矛盾していないか
- テスト可能性: その要件は検証可能か
この基準があれば、AIに「この要件定義はこのチェックリストを満たしているか」と聞くことができる。つまり、AIを生成ツールではなく検証ツールとして使えるようになる。
AIが効いているプロジェクトは何が違うか
実際にAI要件定義がうまく機能しているプロジェクトを観察すると、2点が際立っている。
1. 「構造化」が先に来ている
AIにアウトプットを求める前に、情報の整理が終わっている。議事録はそのままではなく、論点別に整理されている。ステークホルダーへのヒアリングは、事前に設計したフレームに沿って行われている。
つまり、AIは「思考の補助」として使われており、「思考の代替」として使われていない。
2. AIの出力に対するレビュープロセスがある
「AIが書いたものをそのまま採用する」ではなく、「AIが出したものを人間がレビューし、承認する」フローが明確になっている。このフローがあると、AIの出力品質が安定する。なぜなら、「レビューで何が見られるか」をAIにも伝えられるからだ。
上流工程でAIを機能させる3つの処方箋
処方箋1: 要件を渡す前に「構造化」する
AIに要件を書かせる前に、以下のテンプレートで情報を整理する習慣をつける。
[背景・目的]
このシステムを作る理由、解決したいビジネス上の問題
[対象ユーザー]
誰が使うか（役職、業務内容、ITリテラシーレベル）
[現在の課題]
具体的なフロー、どのステップに時間/コストがかかっているか
[期待するアウトカム]
数値で表現できる成功指標
[制約]
スケジュール、予算、技術スタック、法規制この構造が揃った状態でAIに渡すと、アウトプットの質が劇的に変わる。実感として、このテンプレートを使うだけで「使えるたたき台率」が50%から80%以上に改善した案件もある。
処方箋2: AIに「照合」をさせる
AIは「書く」より「チェックする」ときのほうが精度が高い。これは少し意外に聞こえるかもしれないが、理由は明快だ——チェックには正解のフォーマットを渡せるから。
実務的な使い方:
- 要件書の各項目に対して「この要件はテスト可能か？YES/NOで答えよ」
- 「この機能要件に矛盾または未定義な部分はあるか？箇条書きで列挙せよ」
- 「このユーザーストーリーに対して、想定される例外フローを5つ挙げよ」
これはAIエージェントを「生成者」ではなく「批評者」として使う方法だ。AIエージェントと要件定義を分担する方法でも触れたが、役割分担が明確なほどAIは力を発揮する。
処方箋3: 「言葉の辞書」を先に作る
大企業や業界特有の用語が多いプロジェクトほど、要件定義でのすれ違いが多い。AIを入れると、この問題がさらに深刻になる。
「受注」「案件」「契約」——これらの言葉が社内で使われる意味は、部門によって異なることがある。AIは文脈から意味を類推しようとするが、業界固有の使い方には対応できないことが多い。
処方箋は単純だ: プロジェクト固有の用語定義をドキュメント化し、AIに渡す際のシステムプロンプトに含める。「このプロジェクトでは『受注』は発注書を受け取った時点を指す」という定義が一行あるだけで、AIの文脈理解は大幅に改善する。
AIが読める仕様書の書き方でも述べているが、AIに読んでもらう前提でドキュメントを設計することが、上流工程のAI活用の本質だ。
AIは上流を「楽にする」のではなく「可視化する」ツール
少し視点を変えて整理すると、AIを要件定義に入れると必ずこういうことが起きる: それまで隠れていた問題が表面化する。
暗黙知が多い、インプットが曖昧、完成基準がない——これらは別にAIがない時代から存在していた問題だ。ただ、人間の担当者が経験と気合でカバーしてきた。AIはそういった「人間のバッファ」が使えないので、構造的な問題がそのまま出力品質に反映される。
逆に言えば、AIが要件定義で機能しないということは、そのプロジェクトに構造的な問題があるというシグナルでもある。
「AIが使えない」と諦める前に、「AIが効かない理由は何か」を問うてみる価値がある。たいていの場合、そこに改善すべき本当のボトルネックが隠れている。
AI開発ツールはなぜ「上流」に向かうのかで触れた通り、上流工程の問題を解決しないまま下流でAIを使っても、手戻りのスピードが上がるだけだ。根本から変えるには、情報の構造化から始めるしかない。
まとめ
要件定義でAIが機能しないプロジェクトの共通点:
- 要件が暗黙知のまま — 書かれていないものをAIは読めない
- インプットが定義されていない — 構造化されていない情報からAIは精度の高い要件を出せない
- 完成基準がない — 判断軸がなければレビューは終わらない
処方箋:
- 要件を渡す前に構造化する
- AIに「生成」より「照合」をさせる
- 用語の辞書を先に作ってAIに渡す
AIは「魔法の要件定義ツール」ではない。しかし、正しくセットアップされたプロジェクトでは、AIはPM一人分の思考補助を確実に担える。その「正しいセットアップ」こそが、上流工程のAI活用で一番 重要なことだ。
アツメルでは、要件定義からAIが動ける形でドキュメントを構造化する「Kakusill」を開発しています。「上流工程のAI活用をどこから始めればいいか分からない」という方は、お気軽にご相談ください。
