AI要件定義は変更差分から始める
# AI要件定義は変更差分から始める
要件定義の打ち合わせで、最初に機能一覧が出てくることは多い。メールを読む、Slackを要約する、CRMにタスクを入れる。見た目は分かりやすい。だが、AI要件定義ではそこで止まると危ない。
AIは、人間が言わなかった前提を勝手に埋める。だから「何を作るか」より先に「現状から何が変わるか」を固めないと、出力はそれっぽいのに ズレたまま進む。差分が見えていれば、AIがどこまで読んで、どこで止まり、どこから人間に戻すかを切り分けられる。
OpenAIの A Practical Guide to Building Agents と Agent evals でも、エージェントを動かす前に評価と停止条件を設計する重要性が繰り返し示されている。MCPの Resources と Tools の分け方も同じだ。読む文脈と、動かす手段は分ける。AI要件定義でも、まず差分を言葉にした方が早い。
機能一覧だけでは足りない
「営業メールを要約して、返信案を作る」。この一文だけなら、いかにも要件定義らしく見える。だが、実務ではこれだけでは足りない。
たとえば、AIに何を読ませるのか。
- 返信が必要なメールだけか
- すでに処理済みのスレッドは除外するのか
- 添付ファイルも対象にするのか
- 社外秘のメモは見せてよいのか
次に、何をさせるのか。
- 要約だけで止めるのか
- 返信案まで作るのか
- タスクを起こすのか
- そのまま送信するのか
この差分が曖昧だと、AIは勝手にもっともらしい方向へ寄る。便利そうに見えるが、現場では困る。人間が欲しいのは「賢そうな文章」ではなく、「今の運用から何を変えるか」が読み取れる仕様だ。
差分は5つに分けると整理しやすい
AI要件定義の差分は、だいたい次の5つに分けると崩れにくい。
| 差分 | 見るもの | 例 |
|---|---|---|
| 入力差分 | 何を読ませるか | Gmailだけか、SlackやCRMも含めるか |
| 判断差分 | 何をAIに判定させるか | 未返信候補の判定、重要度の判定 |
| 出力差分 | 何を生成させるか | 要約、下書き、タスク、通知 |
| 権限差分 | どこまで実行してよいか | 読むだけ、下書きまで、送信は不可 |
| 停止差分 | どこで止めるか | 機密語、重複、オーナー権限、曖昧指示 |
この表のよいところは、会話が具体化することだ。
「AIが全部やってくれる」 ではなく、「どこまでなら任せてよいか」に話が移る。ここまで来ると、要件定義はだいぶ実務寄りになる。
特に重要なのは権限差分だ。AIは、読んでよい範囲と、動かしてよい範囲を混ぜると危ない。 OWASP Top 10 for LLM Applications が気にしているのも、まさにこの境界だ。読むだけなら許すのか。下書きまでなら許すのか。送信や更新は人間承認にするのか。先に線を引く必要がある。
朝会前の準備業務を例にすると、差分が見える
題材は大きくしなくていい。朝会前の準備業務で十分だ。
現状は、人が Gmail、Calendar、Slack、CRM を順番に開いて、今日の予定と未返信候補を15分ほど眺める。そこで重要なものを頭の中で並べ替え、必要ならメモを残す。
AIを入れた後は、同じ作業を3分で終わらせたい。要約だけでなく、優先度の高い案件、送る前に止めるべき文面、重複しているタスク候補まで出したい。
このときに書くべき差分は、機能名ではない。
- 何を基準に重要度を決めるか
- どの条件なら推測しないか
- 既存タスクと重複したらどうするか
- 機密が混ざったらどこで止めるか
この4点が書けると、テストケースも自然に出てくる。逆に、ここが曖昧なままなら、AIは「それっぽい朝会メモ」を作るだけで終わる。
アツメルでも、要件をAIに渡したときに効くのは、全部を任せる設計ではない。まず読む、次に下書きする、最後に人間が確定する。この順番にした方が、現場の差分が小さくなる。差分が小さいほど、運用は壊れにくい。
差分が書けると、レビューも速くなる
AI要件定義は、レビュー設計とも相性がいい。むしろ差分が書けない要件は、レビューもしづらい。
なぜか。
レビューでは、前提がズレていないかを見たいからだ。ところが機能一覧しかないと、「機能があるかないか」しか見られない。現状と目標の差分がないと、受け入れ条件も止める条件も判断しづらい。
ここで役に立つのが、 AI要件定義で最初に作るテストケース で触れた発想だ。壊しにいくテストケースを書けば、差分の抜けが見える。さらに 要件定義AIは「書く前にレビュー設計」を決めるべき理由 を見ても、結局は「どこで合格とするか」を先に固定 した方が速い。
差分があると、レビューは次の3つに分かれる。
- 受け入れ条件に合っているか
- 例外時の停止条件があるか
- 人間に戻す境界が明確か
この3つは、レビュー時に毎回効く。しかも、差分を起点にしているので、関係者同士の会話も短くなる。
実務で使うなら、4行で書く
最初から立派な要件書は要らない。まずは4行で十分だ。
- 現状: 何を人がやっているか
- 目標: 何をAIに変えたいか
- 差分: 何が変わるのか
- 停止条件: どこで止めるか
この4行が書けないなら、まだ要件定義は終わっていない。逆に、ここまで書けるなら、AIに渡しても大きく崩れにくい。
面白いのは、ここまでやると「AI要件定義は難しい」の意味が変わることだ。難しいのはAIそのものではない。現状を言語化せずに、いきなり未来の振る舞いだけを頼むことだ。
だから、AI要件定義は変更差分から始める方がいい。機能を並べる前に、何が変わるかを先に決める。そこからなら、テストケースもレビュー設計も権限設計もつながる。
