要件定義の粒度 — AIエージェントに渡せる仕様と渡せない仕様
「AIに要件定義をやらせてみたら、なんか違う」という経験、ないだろうか。
ユーザーストーリーの整理はできる。機能一覧も出てくる。でも、その後に開発チームへ渡したときに「これって本当に使えるの？」という顔をされる。何かが抜けている感覚が拭えない。
この違和感の正体は、仕様の粒度にある。
AIエージェントに渡せる仕様と、渡してはいけない仕様がある。その境界を理解しないまま「AIに丸投げ」すると、精度の高いゴミが量産される。
「渡せる仕様」とは何か
Kakusillで要件定義支援をしていて気づいたのは、AIが得意なのは構造化されたインプットを整理する作業だということだ。
具体的には:
- 会議の書き起こしから「誰が何を言ったか」を整理する
- 類似する要件をグルーピングし、重複を取り除く
- ユーザーストーリーを「誰が・何をしたい・なぜ」の形式に統一する
- 矛盾する記述を検出して、問いかけを生成する
これらはすべて、インプットが明確で、アウトプットの形式が決まっている作業だ。AIはここで圧倒的に速い。
「仕様書初稿を40%短縮した」というKakusillの導入効果も、主にこの領域で生まれている。AI開発ツールが上流工程に向かう理由を考えると、この流れは必然とも言える。
「渡せない仕様」が存在する理由
問題はその次にある。
たとえば「ユーザーがなぜその機能を必要としているのか」という問いに対して、AIは回答を生成できる。でも、その回答が正しいかどうかを判断するのは人間しかできない。
正直なところ、要件定義の本質的な難しさは暗黙知にある。
営業担当が「顧客はこれを嫌がる」と直感的に知っている何か。開発経験10年のベテランが「これは後で絶対に変わる」と読む勘。組織の政治的な都合。これらは、ドキュメントに書かれていない。
AIは書かれていない情報を読めない。正確には、書かれていないものを「推定」はするが、その推定が正しいかどうかを担保できる根拠がない。
コードは読めるのに仕様は読めないのかという問いと同じ構造だ。AIにとって「書かれている」ことと「意図されている」ことの間には、常に溝がある。
ここに粒度の境界線がある。
3つの粒度レベルで整理する
実務的に考えると、要件は3つの粒度レベルに分けられる 。
レベル1: 記述可能・構造化済み（AIに最適）
- 機能の入力/出力の定義
- エラーケースの列挙
- APIのリクエスト/レスポンス仕様
- 画面遷移フローの文書化
これは完全にAIに任せられる。というより、AIにやらせた方が人間よりも速く・正確に仕上がることが多い。チェックに人間の時間を使えばよい。
レベル2: 解釈が必要（AIと人間のハイブリッド）
- ユーザーが「本当に」欲しいもの（表明ニーズの背後にある潜在ニーズ）
- 優先順位の根拠（なぜこれを先にやるのか）
- ステークホルダー間の合意ポイント（会議で「なんとなく決まった」こと）
AIは叩き台を作れる。でも、その叩き台が本当に意図を捉えているかどうかは、人間が確認しないといけない。ここをAIに「渡しきる」と、後になって「そういうつもりじゃなかった」が発生する。
参考として、AIエージェントに要件定義を渡した後に起きることでは、このフィードバックループの設計について詳しく書いた。
レベル3: 渡せない（人間が持つべき判断）
- ビジネス上の制約（予算・スケジュール・リソース）の現実的な解釈
- 組織の意思決定者が「YES」を言う条件
- 法的・コンプライアンス上のリスク判断
- 「この機能は作らない」という決断の根拠
特にレベル3が問題になる。AIは「何を作るか」を整理するのは得意だが、「何を作らないか」を決めるのは苦手だ。削る判断は、文脈と責任感を持った人間にしかできない。
粒度のミスマッチが起きると何が起こるか
「AIが要件定義をやってくれた」といってレビューせずに開発に渡すと、典型的なパターンとして2つの問題が起きる。
1. 網羅性の錯覚
AIは漏れなく機能を列挙する。でも、「この機能の裏側にある暗黙のルール」は書かれていない。開発者は「仕様書に書いてある通り」に作ったのに、「なんか違う」が発生する。
2. 決断の先送り
レベル2の「解釈が必要な仕様」をAIが「それらしい答え」で埋めてしまう。表面上は完成しているから、誰もそこが未決断だと気づかない。開発が終わって初めて「この仕様、誰が決めたんだっけ」となる。
AIに要件定義を任せると何が壊れるかでは、この失敗パターンをより詳しく分析している。どちらも、仕様書の構造的な問題ではなく、粒度の管理不足から生まれる。
実務での対処法
では、どうすればいいか。3点だけ挙げる。
「AIが書いた部分」と「人間が決めた部分」を明示する
仕様書の中に「この項目はAI生成・要確認」というフラグを入れる。全部書いてあるように見えても、意思決定の痕跡がないものは承認されていないとみなす。
レベル2の問いかけをAIに出力させる
AIに要件を整理させるとき、「仕様書を完成させる」のではなく、「整理できなかった問いを列挙する」ことを明示的に指示する。これにより、暗黙知を引き出す対話のきっかけになる。Kakusillの収集アシスタント機能はこのアプローチで設計している。AIが「聞いてくれる」要件定義の設計思想にも通じる考え方だ。
「削れるか？」を必ず人間が問う
AIに一度渡した要件は、AIの中で「必要なもの」として扱われる。でも、プロダクトの本質的な価値から考えると削ってもよいものが、要件の3割は含まれている（経験値だが、体感ではもっと多い）。「この機能は本当に必要か」を、人間が一度立ち止まって問う場を設ける。
粒度を意識した要件定義が、AI活用の「次のステージ」
「AIに要件定義をやらせてみたら、なんか違う」は、ほぼ確実に粒度の問題だ。
AIは構造化が得意で、解釈と判断が苦手だ。ここを理解した上で使えば、要件定義の速度と品質を同時に引き上げられる。逆に理解しないままだと、精度の高いドキュメントが量産され、なぜかプロジェクトが失敗する。
Atsumellがクライアントの要件定義支援で繰り返し見てきたのは、「AIを使っているのに上流が詰まっている」チームの共通点がここにあるということだ。ツールではなく、粒度の考え方を変えることが、AIネイティブな要件定義への入り口になる。
アツメルのAI要件定義支援について、気になる方はお気軽にご相談ください。
