AIに要件定義を手伝わせるプロンプトを、どう組むか。私はAI導入支援（FDE）の仕事で、要件定義書そのものをAIに書かせている。ただし「議事録を全部貼って、要件定義書を書いて」と一発で投げることはしない。段階を分けて渡し、出てきたものを7箇所で必ず自分の手で直す。
この記事では、実際に使っている入力の内訳、段階の分け方、そして「AIの出力を右から左に使うと事故る箇所」を具体的に書く。プロンプトの文面そのものより、何を渡して何を渡さないか、どこで人が介入するかの設計が効くというのが結論だ。
何を入力に渡しているか
要件定義書を書かせるとき、私がAIに渡している材料は4種類ある。
- ヒアリングの議事録: 現場の担当者・決裁者との打ち合わせで出た発言の記録
- 現行業務の説明: 今その業務がどういう手順で回っているか
- 既存システムの仕様: 連携先・データの持ち方・制約
- 顧客の願望メモ: 「こうなったら嬉しい」という要望のリスト
この4つが揃っているかどうかで、出力の質がはっきり変わる。特に効くのは現行業務の説明で、これが薄いとAIは一般的な業務フローを勝手に前提にした要件定義書を書いてくる。「要件が固まっていない案件を、FDEはどう進めるか」で書いた通り、ヒアリングの場での説明と実際の業務は食い違うことが多いので、実態を見てきた内容を明示的に渡す必要がある。
渡す前に必ずやるのが、固有名詞と機微情報を落とすことだ。議事録には企業名・担当者名・取引先名・具体的な金額が生で入っている。これをそのままAIに渡すのは守秘義務の観点で避けたいので、「A社」「担当者X」のように置き換えるか、その記述ごと削って渡す。手間だが、ここを面倒がると後戻りできない。
一発で書かせず、段階を分ける
材料が揃っても、全部まとめて渡して「要件定義書を書いて」とは言わない。段階を分けて渡している。
一発で書かせると、AIは材料の中から「それらしい」部分を拾って体裁の整った文書を作る。問題は、どこを拾ってどこを捨てたかが見えないことだ。出てきた要件定義書を読んでも、書かれていない要件が「議事録に無かったから」なのか「AIが落としたから」なのかが判別できない。段階を分けると、各段階の出力を人が確認してから次に進めるので、落ちた箇所に気づける。
分け方は案件によるが、材料の整理 → 構造の確定 → 本文の生成、という順序を守っている。特に構造（章立て・どの要件をどこに書くか）を人が確定させてから本文を書かせると、後の手戻りが小さい。構造まで含めてAIに任せると、案件の性質と合わない汎用的な目次が出てきて、それに合わせて中身を埋める作業が発生する。
AIの出力を右から左に使わない7箇所
ここが本題だ。出てきた要件定義書のうち、私が必ず自分の手で書き直す・足す箇所が7つある。いずれも「AIが間違える」というより、渡した材料に情報が無いのでAIには書けない箇所だ。
1. 利用者の解像度
AIは「利用者：営業部」で止める。実際に必要なのは、その業務を誰が、どの端末で、1日に何回やるかだ。1日3回の人と1日100回の人では、要件として必要な操作性が変わる。ここが曖昧なまま進むと、PoCで「動いた」のに現場では使われないものができる。
2. AIが間違えたときの業務フロー
AIを組み込むシステムの要件定義書は、放っておくと「AIが正しく動く前提」で書かれる。だが実際のAIはたまに間違える。「AI導入がPoC止まりで終わり現場定着しない3つの理由」で書いた通り、この「たまに間違える」を業務フローが受け止められないと導入が止まる。誰がどのタイミングで出力を確認し、間違っていたときにどう差し戻すか。この手順は人が業務に合わせて書くしかない。
3. 導入後に運用する人
体制図に「開発担当」「発注者」は書かれても、導入後に誰がこのシステムを運用するかが入らない。AIは議事録に出てこない役割を発明しないので、当然抜ける。ここを空欄のまま進めると、PoCが終わった瞬間に持ち主のいないシステムが残る。
4. やらないこと・撤退条件
AIは顧客の願望メモを全部要件に変換してしまう。スコープ外にするもの、そして「この条件を満たさなければ中止する」という撤退条件は、人が意図して書く必要がある。「AI案件のスコープ設計」で書いた通り、何をやらないかを最初に握らないと、準委任と成果コミットの境界が曖昧なまま進むことになる。
5. 稟議・情シス・予算の制約
日本企業には、承認経路・情報システム部門のルール・予算の期別の制約がある。これらはヒアリングの議事録にはまず出てこない（現場担当者にとっては当たり前すぎて言語化されない）ので、AIには書けない。「日本企業のAI導入で課題になる稟議・情シス・予算の3つの壁」で書いた通り、この3つは直列構造でどこか1つで止まれば導入が消えるので、要件定義書の段階で制約として明記しておく。
6. 願望と要件の切り分け
顧客の願望メモには「〜したい」が並んでいる。AIはこれを丁寧に要件へ変換するが、その願望が本当に必要なものかは判断しない。「顧客ヒアリングからプロトタイプまでを最短で回す型」で書いた通り、要望として語られたことと本当に困っていることは一致しないことがある。ここは人が切り分けて、要件から落とすものを決める。
7. 機微情報の混入チェック
入力側で固有名詞を落としていても、出力側に残ることがある。文脈から推測された固有名詞が書かれていたり、こちらが落とし忘れた記述がそのまま使われていたりする。納品前に必ず読み直す。
この型が効く理由
7箇所を並べて分かるのは、人が書く必要があるのは「材料に無かったこと」だけだということだ。逆に言えば、材料にあることの構造化と文章化はAIに任せてよい。要件定義書を書く作業時間のうち、この構造化と文章化が占める割合は大きいので、そこを任せた上で7箇所に集中する方が、全部自分で書くより精度が上がる。
もう1つは、段階を分けることでAIが落とした箇所に気づけるという点だ。一発で出てきた完成品を読んで抜けに気づくのは難しいが、段階ごとに確認していれば「この要件はどこで消えたか」を追える。
まとめ
- AIに要件定義書を書かせるときの入力は、議事録・現行業務の説明・既存システムの仕様・顧客の願望メモの4種類。渡す前に固有名詞と機微情報を落とす
- 一発で書かせず、材料の整理 → 構造の確定 → 本文の生成に段階を分ける。構造を人が確定させてから本文を書かせると手戻りが小さい
- 出力をそのまま使わないのは、利用者の解像度／AIが間違えたときの業務フロー／導入後の運用担当／やらないことと撤退条件／稟議・情シス・予算の制約／願望と要件の切り分け／機微情報の混入、の7箇所
- 7箇所に共通するのは「渡した材料に情報が無いのでAIには書けない」ことで、人はここだけに集中すればよい
