AIが「聞いてくれる」要件定義 — ヒアリングエージェント設計の3つの鍵
# AIが「聞いてくれる」要件定義 — ヒアリングエージェント設計の3つの鍵
「AIがユーザーに自動でヒアリングしてくれる」——そんなデモを見る機会が増えてきた。
MCPを活用してAIが適切なタイミングで質問を投げ、要件を整理してくれる仕組みだ。大手テック企業がこぞって「AIが聞いてくれるインターフェース」を模索しているのは、もはや業界のトレンドになりつつある。
ただ、実際に導入しようとしたプロ ジェクトで共通してぶつかる壁がある。AIが質問しているのに、ちゃんとした要件が取れない。
これはモデルの問題ではない。ヒアリングの設計が足りないのだ。
「AIが質問する」だけでは失敗する3つの理由
LLMに「ユーザーから要件をヒアリングしてください」と指示すれば、それなりに質問は返ってくる。でも、それで取れた要件が使えるかどうかは別の話だ。
多くの現場で観察された失敗パターンを整理すると、3つに集約できる。
① 質問が発散する
「どんな機能が欲しいですか？」という開かれた問いから始まると、ユーザーの回答も発散する。AIはその回答にさらに乗っかって質問を続けるため、ヒアリングが終わった頃には構造化されていない大量のテキストが残るだけになる。
② 暗黙知を見逃す
ユーザーが言葉にしていない前提——「当然こうなるでしょ」という暗黙知——をAIは自動では拾えない。「在庫管理機能が欲しい」と言われても、その業務がどう動いていて何が課題なのかを引き出す問い返しがなければ、表面の要件しか取れない。
③ 矛盾を検出できない
「AとBの両方を実現したい」が実は矛盾しているケースは、要件定義の現場では日常茶飯事だ。単純なQ&Aフローでは、後から「なんでこんな設計になったんだっけ」という状況が生まれる。
ヒアリングエージェント設計の3つのポイント
これらの失敗を防ぐためには、「モデルに任せる」ではなく「ヒアリングそのものを設計する」という発想の転換が必要だ。
1. 質問を「構造化フロー」に載せる
自由な会話ではなく、ヒアリングの進行を設計する。たとえば以下のような4フェーズ構成が機能しやすい:
- Phase 1: 目的と背景（Why — なぜこれが必要か）
- Phase 2: 制約と非機能要件（What NOT — やってはいけないこと）
- Phase 3: 具体的な機能・ユースケース（What — 何が必要か）
- Phase 4: 優先度と期待アウトカム（Outcome — 何が達成されればいいか）
このフローをシステムプロンプトに定義し、AIが会話の状態に応じてフェーズを進行させる設計にすることで、質問の発散を防げる。
2. 「暗黙知を引き出す 問い返し」を設計する
良いヒアリングは「はい/いいえ」で答えられる質問では終わらない。ユーザーの回答に対して自動的に深掘りするパターンを設計することが重要だ。
ユーザーが「在庫管理機能が欲しい」と言ったとき、浅い質問は「どのような在庫管理機能ですか？」で終わる。深い問い返しは「現在、在庫管理はどのように行っていますか？その方法でどんな課題が起きていますか？月に何件程度の在庫操作が発生しますか？例外的な処理はありますか？」と展開する。
「現状の作業フロー」「発生している問題の頻度・影響」「例外ケース」——この3軸を引き出す問い返しパターンをあらかじめ設計しておくと、AIの質問の深さが変わる。
3. 「矛盾・不整合の検出ループ」を組み込む
ヒアリング中に矛盾が生まれることは避けられない。それをリアルタイムで検出するには、AIに「これまでの回答を構造化した要件メモ」を常に持たせ、新しい回答を既存の要件と照合させる設計が必要だ。
新しい要件が追加されるたびに既存の要件リストとの整合性を確認し、矛盾が検出された場合は具体的に提示してユーザーに確認を求める——このループをシステムプロンプトに組み込むことで、後から「この設計はどういう経緯だっけ」という状況が起きにくくなる。
「聞けるAI」は作れるか
ここまでの3つのポイントに共通しているのは、「AIに任せる」のではなく「AIがうまく機能するための構造を人間が設計する」という発想だ。
ヒアリングのフロー設計、問い返しパターンの定義、矛盾検出のロジック——これらはプロンプトエンジニアリングの話でもあるが、本質は要件定義のプロセス設計そのものだ。
AIが「何を聞けばいいか」を知っているのは、人間が「何を聞くべきか」を設計したからに過ぎない。
Atsumellが開発するKakusillでは、AIヒアリングアシスタント機能としてこれらのアプローチを実装している。構造化された質問フローと暗黙知の引き出し設計を組み合わせることで、要件定義の初稿作成工数を大幅に削減した実績がある。
まとめ
AIエージェントに要件を引き出させるためには、単に「質問してください」と指示するだけでは不十分だ。
- 質問の構造化: ヒアリングのフェーズを設計し、発散を防ぐ
- 暗黙知抽出の設計: 現状フロー・課題頻度・例外ケースを引き出す問い返しパターンを用意する
- 矛盾検出ループ: 要件メモと照合するルー プを組み込む
この3つを設計することで、AIのヒアリングは「使えるもの」になる。
AIを使った要件定義の高速化・品質向上に取り組まれている方は、ぜひAtsumellにお問い合わせください。現場での実践知をもとに、あなたのプロジェクトに合った設計をご提案します。
