AIエージェントと要件定義を分担する方法
「要件が曖昧だからAIに任せられない」は本当か
「うちのプロジェクト、まだ要件が固まっていないので、AIには向かないんですよね」
この台詞を、過去半年で何度聞いただろう。打ち合わせで出るたびに、少し違和感を覚える。
要件が曖昧なのは、AIに任せられない理由ではない。むしろ、要件を固める作業こそ、AIエージェントが一番力を発揮できるフェーズだと、我々は実務を通じて気づいた。
仕様書が書けるまでの過程 ── つまり「なぜ作るのか」「誰が使うのか」「何ができればOKなのか」を整理する作業 ── を、人間とAIエージェントがどう分担するか。今回はそのプロセスを具体的に書く。
---
要件定義で人間が本当に苦手なこと
まず、正直に言っておく。要件定義の失敗の多くは、人間同士のコミュニケーション問題だ。
ステークホルダーが「こういうシステムが欲しい」と言う。開発者が「わかりました」と応答する。ところが両者の頭に浮かんでいる絵は、まったく違う。これが何百万円もの手戻りを生む。
この問題の核心は3つある。
1. 言語化の非対称性
事業担当者は自分のやりたいことを「業務の言葉」で話す。開発者はそれを「システムの言葉」に翻訳しようとする。この翻訳作業で、大量のニュアンスが失われる。
2. 問いかけの漏れ
経験豊富なエンジニアでも、ヒアリング中に「あとで確認すればいい」と流してしまう質問がある。後になって「それ最初に聞いておくべきだった」と気づく。
3. 前提の暗黙化
ステークホルダーにとって当たり前すぎる前提は、言語化されない。「もちろん、それは〇〇の場合だけですよ」という条件が、後から出てくる。
AIエージェントは、この3つの問題に対してまったく別のアプロー チを取れる。
---
AIエージェントの問いかけ設計術
我々がプロジェクトで実際に使っているアプローチを説明する。
まず「なぜ」を5回掘る
AIエージェントに最初にやらせることは、目的の深掘りだ。
ステークホルダーが「在庫管理システムを作りたい」と言ったとする。AIエージェントはいきなり機能要件を聞きに行かない。
```
「在庫管理システムで解決したい、一番の困りごとは何ですか？」
→「発注のタイミングがわからなくて、欠品が起きる」
「欠品が起きると、具体的にどんな問題が発生していますか？」
→「顧客への納期遅延が月に3〜4件ある」
「その3〜4件は、どのような商品カテゴリで起きていますか？」
→「実は特定のベンダー2社の商品に集中している」
```
3つ聞いただけで、問題の輪郭が変わった。「在庫管理システム全体」ではなく、「特定 ベンダー2社の発注アラート機能」が本質かもしれない。
AIエージェントのこの問いかけの強みは、人間が「こんな当たり前のことを聞くのは失礼かな」と思って流すような質問も、躊躇なく聞けることだ。
「例外パターン」を徹底的に洗い出す
仕様書が薄くなる最大の原因は、例外ケースの漏れだ。
AIエージェントは、要件を受け取ったら必ず「正常系の反対」を聞く。
```
「ユーザーが操作を途中でキャンセルした場合、どうなりますか？」
「ネットワークが切れた状態での操作は想定しますか？」
「複数人が同時に同じデータを更新しようとした場合は？」
「そのルール、過去に例外があったことはありますか？」
```
これをやると、「あー、そういえば」という回答が必ず出てくる。人間のヒアリング担当者がこれを全部聞けるかというと、正直難しい。90分のミーティングで集中力を保ちながら、抜け漏れなく質問するのは疲弊する作業だ。
AIエージェントは疲れないし、忘れない。
矛盾を指摘する
ヒアリングの過程で、ステークホルダー自身が矛盾した要件を出してくることがある。
「スピード重視で開発したい」と言いながら、「既存システムとの完全互換が必要」とも言う。「コストを抑えたい」と言いながら、「機能は全部入れてほしい」とも言う。
人間のSEが指摘すると、関係が悪化することがある。「そこまで言うか」と思われたり、「じゃあどうすればいいんだ」と詰められたり。
AIエージェントは、フラットに事実として提示する。
```
「先ほどの回答と今の回答を照らし合わせると、
・スピード優先（3週間でリリース）
・既存システムとのデータ互換（工数+2週間相当）
という2つが同時に求められています。優先順位を確認させてください」
```
感情を挟まず、ファクトとして出す。これが人間には難しい。
---
人間がやるべきこと、AIに任せていいこと
誤解してほしくないのは 、要件定義をAIエージェントに丸投げしろという話ではないということだ。
役割分担は明確にある。
| 役割 | 人間 | AIエージェント |
|---|---|---|
| 場の設計 | ✓ | |
| 問いかけの実行 | | ✓ |
| 感情・文脈の読み取り | ✓ | |
| 矛盾・漏れの指摘 | | ✓ |
| 優先順位の判断 | ✓ | |
| 仕様書への整理 | | ✓ |
| 最終確認・承認 | ✓ | |
人間にしかできないことがある。ステークホルダーの顔色を見て、「今は深掘りしない方がいい」と判断すること。予算や政治的な背景を察知して、聞き方を変えること。「この要件、本当に必要ですか？」と笑いながら言えること。
AIエージェントは場の空気を読めない。だから、場の設計と最終判断は人間が持つ。AIエージェントは徹底的に漏れなく、疲れずに聞き続けることを担う。
この分担を意識するだけで、要件定義の質が変わる。
---
実際にやってみてわかった3つのこと
1. ヒアリングの時間が短くなる
従来、要件定義のヒアリングは3〜5回の打ち合わせが必要だった。AIエージェントが問いかけの設計を担当することで、1〜2回で同等の情報が取れるようになってきた。
ポイントは、ミーティング前にAIエージェントが「聞くべき質問リスト」を生成しておくことだ。アジェンダと一緒に事前共有しておくと、ステークホルダー側も考えを整理してきてくれる。
2. 仕様書の抜け漏れが減る
ヒアリング後、AIエージェントが会話ログから仕様書ドラフトを生成する。このとき、「回答されなかった質問」も一覧で出力する。
```
【未回答・要確認事項】
- キャンセル処理後のデータ保持期間（未確認）
- 権限ロールの階層構造（「要検討」との回答あり）
- モバイル対応の優先度（言及なし）
```
これを見ながら次のミーティングに臨む。抜け漏れが可視化されているので、「なんか足りない気がするけど何だろう」という漠然とした不安がなくなる。
3. ステークホルダーの信頼が上がる
これは意外な効果だった。
AIエージェントが整理した仕様書ドラフトを見て、「こんなに細かく整理してもらったのははじめて」という反応をもらうことが増えた。
要件定義の成果物が「なんとなく合意した内容」ではなく、「質問と回答の記録から自動生成された文書」であることで、後から「そんなこと言ってない」という揉め事が減る。会議録としての機能も果たす。
---
仕様駆動開発との接続
ここまで読んだ方は気づいているかもしれない。これは仕様駆動開発（SDD）の「上流フェーズ」の話だ。
SDDでは、コーディング前に仕様書（SPEC）を書く。その仕様書の質が、AIエージェントによるコード生成の精度を直接決める。
問題は、「誰が、どうやってSPECを書くか」という部分は、従来あまり語られてこなかったことだ。
ツールの話（cc-sdd、OpenSpec等）は充実しているが、「その前の段階」 ── ビジネス要件から仕様書へ変換するプロセス ── の設計が後回しにされがちだ。
要件定義フェーズでAIエージェントを使いこなすことで、SDD全体の品質が上がる。コーディングAIに「なんとなく実装してください」ではなく、「この仕様書に従って実装してください」と言えるようになる。
その差は、プロジェクトの後半になればなるほど大きく効いてくる。
---
「AIに要件定義はできない」という誤解
最後に、よく聞く誤解に触れておく。
「要件定義は人間の仕事だ。AIに任せたら、ビジネスの本質を見誤る」
この主張、半分は正しい。最終的な優先順位の判断、ビジネス上のトレードオフの選択は、人間がする。それは変わらない。
ただ、「AIに任せられない」の意味を広げすぎると、AIが一番得意な「漏れなく問いかける」「矛盾を指摘する」「情報を構造化する」という作業まで人間がやり続けることになる。
そこに人間のリソースを使い続けるのは、もったいない。
要件定義における人間の役割は、場を設計し、判断し、承認すること。AIエージェントの役割は、それを 支える質問と整理を、疲れずに行うこと。
この分担を設計できたとき、上流工程は「属人的な職人技」から「再現性のあるプロセス」に変わる。
---
まとめ
要件定義でAIエージェントを使う、というのは「AIに仕様書を書かせる」ことではない。
人間が見落としやすい問いかけを補完し、矛盾を可視化し、合意内容を構造化する。その3つを担わせることで、要件定義の精度が上がる。
SIer的な文化では、「上流こそ人間がやるもの」という信仰が根強い。でも、上流でこそAIを使いこなせているチームが、後の工程で圧倒的なアドバンテージを持つ。
もし要件定義のやり方をAI前提で見直したいなら、Atsumellに相談してほしい。「どこからAIに任せるか」の設計から、一緒に考える。
---
関連記事
