AIに要件定義を手伝わせるプロンプトの型、段階を分ける理由と出力をそのまま使わない7箇所

AIに要件定義書を書かせるとき、出力をそのまま使うと事故る箇所が7つある——利用者の解像度の不足、AIが誤答したときのフロー、導入後の運用担当が決まっていない、やらないことが定義されていない、稟議・情シス・予算の制約が抜けている、願望が要件に化けている、機微情報の漏出、この7つだ。なぜこの7箇所か。渡した材料に情報が無いのでAIには書きようがないというのが本当の理由で、AIが間違えているわけではない。 ここが面白いのは、AIに書かせる時間を節約しても、結局人が7箇所に手を入れるなら、むしろ「何を渡すか、何を渡さないか、どこで人が介入するか」という設計こそが勝負だというメッセージだ。要件定義書という成果物より、その作り方のプロセスが事故を防ぐ。多くの企業は「AIにやらせれば早くなる」と思うが、早さはプロセスに込み込まれた判断時点で決まる。材料を渡す前に固有名詞を落とす、段階を分ける、構造を人が確定させてから本文を書かせる。この3つを握れば、AIは構造化と文章化という退屈な部分を引き受け、人は高度な判断に集中できる。 中小企業がAI導入支援を発注するときの指標もここにある。「うちの業務フローをAIに読ませれば、仕様書ができますか」という相談は多いが、できる・できないより「あなたの業務の7つの穴がAIに見えるか」を先に埋めなければ始まらない。運用担当を決めずに導入するプロジェクトは、完成した瞬間に誰も持ち主のいないシステムになる。要件定義の段階でそれを握るかどうかが、導入後の生死を分ける。