AI要件定義は例外条件を先に決める
# AI要件定義は例外条件を先に決める
AIに要件定義を任せると、最初の出力はだいたい整って見える。画面、項目、遷移、文言。通常系だけを並べるなら、かなりうまい。
ただ、現場で止まるのはそこではない。止まるのは、例外が出た瞬間だ。権限が足りない。期限を過ぎた。外部送信が必要になった。承認者が不在になった。ここで迷うと、きれいに見えた要件はすぐ崩れる。
要件定義で先に閉じるべきなのは、機能一覧ではなく例外条件だ。AIは空白を埋めるのが得意だが、空白を埋めてよいかどうかまでは勝手に決めてくれない。
OpenAIの Agent evals や Safety in building agents が示しているのも、結局はここだ。出力を増やす前に、評価とガードレールを置く。MCP でも Resources と Tools を分けるのは、読む文脈と動かす手段を混ぜないためだ。RDRA も 要件定義の進め方 で、最初に目的と関係性を固める発想を取っている。
例外条件を後回しにすると、AIは勝手に補完する
たとえば「申請を登録できるようにしたい」という要件があったとする。AIはたいてい、入力欄を増やし、保存ボタンを置き、確認画面を足してくれる。通常系だけなら、見た目はそれで十分だ。
でも、実務ではそこから先が問題になる。
- 申請者が退職済みならどうするか
- 承認者が休暇中なら誰が代わるか
- 締切を過ぎた申請は止めるのか、再送するのか
- 外部システムに送る前に人間確認を入れるのか
この4つが決まっていないと、設計に入った瞬間に解釈が割れる。AIは「たぶんこうだろう」で埋める。人間も「おそらくこれでよさそう」と受ける。後で直すと、画面だけでなく状態遷移や権限設計まで崩れる。
RDRA の考え方でも、要件定義は単なる項目埋めではない。関係性と条件を整理し、変更起点を見える形にする作業だ。例外条件を先に置くと、変更がどこに飛ぶかが見えやすくなる。
先に決めるのは、3種類の例外条件
例外条件は何でもかんでも書けばいいわけではない。実務で効くのは、だいたい次の3種類だ。
1. 権限の例外
誰が読めて、誰が書けて、誰が送れるか。ここが曖昧だと、AIは操作を広げすぎる。
たとえば社内向けの業務AIであれば、閲覧は許可しても、送信は人間だけに残すことがある。あるいは、下書きは作れても、請求や承認に触る操作は止めることもある。
OpenAI の Safety in building agents が強調しているように、未確認の入力や危険な操作は、そのままツール呼び出しに流さない方がいい。要件定義でも同じで、権限の例外は最初に閉じる方が安全だ。
2. 状態の例外
同じ申請でも、下書き、申請中、差戻し、承認済みでは扱いが変わる。AIがこの状態差を雑に処理すると、画面上は動いても運用で破綻する。
状態の例外は、次のように書くとわかりやすい。
- この状態では編集可
- この状態では再申請可
- この状態では自動送信不可
- この状態では人間レビュー必須
MCP の Resources と Tools を分ける発想は、ここでも役に立つ。状態の確認と、状態を変える操作を混ぜない。確認できることと 、実行できることを分けると、例外条件が整理しやすい。
3. 外部接続の例外
外部送信、API連携、メール送信、ファイル共有。ここは事故が起きやすい。
「送れる」こと自体より、「どの条件なら送っていいか」を決める方が先だ。
- 顧客名が未確定なら送らない
- 送信先が1件でも欠けたら止める
- 添付がある場合は人間承認に戻す
- 重要文面は自動送信しない
OpenAI の Agent evals の考え方でいえば、ここは評価ケースに落としやすい。送ってよい条件と、止める条件が書けていれば、レビューは速くなる。
例外条件は、レビューを速くするための道具
例外条件を先に書くと、レビューで聞くことが減る。逆に、例外がない要件は、あとから質問が増える。
よくある確認は、だいたいこの4つに集約される。
- これは誰が判断するのか
- どこで止めるのか
- 何をもって失敗とみなすのか
- 失敗したときに、どこへ戻すのか
この4つが見えていれば、AIに要件を渡しても暴れにくい。レビュー側も、賛成か反対かではなく、まだ決まっていないものを露出させるだけで済む。
RDRA の ビジュアル分析 は、要件のつながりを見える化して影響範囲を追う発想だ。例外条件を先に書くと、この可視化がさらに効く。どこで止まるか、どこに戻るかが、最初から追えるからだ。
実際の要件書で見るなら、こういう一行が効く。
- 権限外の操作はここで止める
- 例外が2つ以上重なったら自動処理しない
- 外部送信の直前は人間承認に戻す
- 未確定の条件が残るなら設計に渡さない
この4行があるだけで、AIは「それっぽい完成形」を勝手に作りにくくなる。人間側も、承認するか止めるかを判断しやすい。
明日から使うなら、この順番で十分
大きなテンプレートは要らない。要件書の先頭に、次の順番で3行足すだけでいい。
- 通常系で確定していること
- 例外条件として止めたいこと
- 人間が判断する境界
この順番にすると、AIは通常系を埋める前に 、例外を見に行くようになる。要件定義の品質は、情報量よりも、止める線の明確さで決まる。
たとえば「申請フローを作る」なら、完成形を先に盛るより、まずこう決める。
- 申請者が編集できるのは「申請中」だけ
- 承認待ちになったら編集不可
- 差戻し時は再申請扱い
- 外部連携は承認後だけ
この線があれば、画面数もAPI数も自然に決まる。AIに項目を増やさせる前に、例外条件で輪郭を閉じる。順番を逆にすると、だいたい膨らむ。
まとめ
AI要件定義で先に決めるべきなのは、機能の数ではない。例外条件だ。
通常系はAIがうまく埋める。だが、権限、状態、外部接続の例外は、人間が先に線を引かないと危ない。そこを閉じておくと、要件は設計に渡しやすくなり、レビューも速くなる。
要件定義は、全部を決める作業ではない。AIが勝手に決めてはいけない場所を、先に決める作業だ。
