AI要件定義で最初に作るテストケース
# AI要件定義で最初に作るテストケース
AI要件定義の相談を受けると、最初に出てくるのは機能の話だ。
Slackを読ませたい。Gmailも見せたい。CRMにタスクを入れたい。カレンダーも触らせたい。並べ方としては自然だし、見た目にも分かりやすい。だが、現場で止まるのはそこではない。
本当に詰まるの は、「そのAIに何をさせるか」ではなく、「そのAIが正しく動いたと言える条件は何か」だ。ここを先に決めないと、あとから実装がいくら進んでも、誰も合格判定を出せない。
OpenAIの A Practical Guide to Building Agents や Agent evals が示しているのも、結局はそこだ。エージェントは動かすだけでは足りない。測れる形にして、振り返れるようにして、止める条件まで決める必要がある。
だからAI要件定義は、機能一覧から始めるより、テストケースから始めた方が早い。
テストケースが先だと、曖昧さが一気に見える
仕様書はきれいに見える。だが、AIに渡すとたいてい曖昧さが露出する。
たとえば「商談後のフォローを支援するAIエージェント」を作るとする。機能一覧だけなら簡単だ。
- メールを読む
- 返信案を作る
- タスクを起こす
- Slackに報告する
ここまでは誰でも書ける。ところがテストケースにすると、急に話が細かくなる。
- 社外秘の話題が混ざっていたらどうするか
- 返信すべき相手が複数いたら誰を優先するか
- 既にタスクがあったら重複を避けるか
- 危ない送信直前で止めるか
- いつ人間にエスカレーションするか
この違いは大きい。
機能一覧は「できそう」に見せる。テストケースは「決めていないこと」をあぶり出す。
アツメルでも、仕様をAIが扱いやすい形に切り直すと、初稿の作成時間が約40%短くなることがある。効いているのは魔法のプロンプトではない。先にケースを置いて、迷う余地を減らしているからだ。
AI要件定義で先に書くべき3種類のケース
AIの要件は、だいたい次の3種類に分けると崩れにくい。
| 種類 | 見るもの | 失敗しやすい点 |
|---|---|---|
| 正常系 | 何も問題がない時にどう動くか | 期待がふわっとしている |
| 判断分岐系 | 条件が曖昧、情報が足りない時にどうするか | AIが勝手に埋める |
| 停止系 | 危険な操作や不適切な入力をどう止めるか | 止める条件が書かれていない |
1. 正常系
これは一見、いちばん簡単だ。
ただしAIでは油断しやすい。たとえば「案件メールが来たら、フォロー文面を下書きする」と書いても、何を含めるかで結果は変わる。
- 件名は既存スレッドに合わせるのか
- 口調は顧客に合わせるのか
- 添付ファイルへの言及は入れるのか
- 担当者が複数いる時はCCをどうするのか
正常系のテストは、「普段ならこうなる」を具体化する作業だ。ここが曖昧だと、AIの出力は毎回それっぽいのに毎回少しずつ違う、という厄介な状態になる。
2. 判断分岐系
実務で一番価値が出るのはここだ。
AIは、条件が少し足りないだけで 勝手に補完する。人間が見れば「まあそうだよね」で済むことでも、業務では勝手な補完が事故になる。
たとえばこんなケースだ。
- 返信先が1件ではなく2件ある
- 期限が書かれていない
- 顧客名はあるが案件名がない
- 参照してよい資料と、見てはいけない資料が混ざっている
- 一見普通だが、実は送信前の確認が必要
この手のケースを先に書いておくと、要件定義は一段深くなる。
「AIが判断してくれる」ではなく、「どこまで判断してよいか」を決める話に変わるからだ。
3. 停止系
AI要件定義で抜けやすいのが、止める条件だ。
止める条件がないと、AIはどんどん前に進もうとする。便利そうに見えるが、危ない。
たとえば次のようなものは、最初からケース化しておくべきだ。
- 社外送信前に機密語が含まれていた
- CRM更新で重複候補が出た
- 日程変更がオーナー権限に触れる
- 個人情報の範囲が広すぎる
- 指示文に「急ぎ」「とにかく送って」だけが書かれている
ここを詰めると、要件は権限設計とつながる。
読むだけでよいのか、下書きまでか、保存までか、送信までか。線を引けるようになる。
テストケースは、そのまま権限表になる
AIの要件定義がうまくいかない理由の一つは、仕様書と権限表が別物として書かれていることだ。
本当は一緒に考えた方がよい。
たとえば、MCPの Resources と Tools の分け方は分かりやすい。読むための文脈と、動かすための手段を分ける。AI要件定義でも同じで、テストケースがその境界を言葉にしてくれる。
さらに OWASP Top 10 for LLM Applications を見ると、プロンプトインジェクションや過剰な権限付与は、机上の空論ではない。だから「読んでよい範囲」と「実行してよい範囲」をケースに落としておく意味がある。
このとき便利なのは、次の4項目だ。
- 参照してよいデータ
- 実行してよい操作
- 人間承認が必要な操作
- 失敗時の止まり方
この4つが書けると、AI要件定義はかなり実務的になる。逆に、この4つが書けないなら、まだ導入するには早い。
具体例は、朝会前の準備業務で十分だ
最初の題材は、大きくしなくていい。
朝会前に、今日の予定、期限が近いタスク、未返信候補、重要なSlack、商談メモをまとめる。これくらいの準備業務で十分だ。
この題材はテストケースが作りやすい。
| ケース | 入力 | 期待結果 |
|---|---|---|
| 予定が通常通り | カレンダーに3件、未返信2件 | 重要度順でまとめる |
| 期限が曖昧 | タスクに日付なし | 推測せず、要確認として出す |
| 機密が混入 | 外部向けNGのメモあり | マスキングして止める |
| 重複あり | 同じ案件の未返信が複数 | ひとつに束ねる |
| 送信前確認が必要 | 顧客名と送信文面が揃う | 人間承認に回す |
このくらいでいい。むしろ最初から完璧を狙うと、要件定義が重くなる。
アツメルでも、実際に効くのは「全部をAIに任せる設計」ではない。まずは読ませる、次に下書きさせる、最後に人間が確定する。この順番にすると、仕様の切り方が自然に決まる。
先にテストケースを書くと、会話が速くなる
テストケースから始めると、会話の質が変わる。
「この機能は要るか」ではなく、「このケースを通すために何が要るか」で話せるからだ。すると、関係者の認識もそろいやすい。
OpenAIの guardrails や、AIの実行設計に関する考え方を見ても、結局は同じところに戻る。危ない入力をどう止めるか。どこで人間に戻すか。どの出力を合格とするか。
AI要件定義を言い換えるなら、これは「AIに仕事を頼む前の採点表づくり」だ。
だから最初に書くべきなのは、機能一覧ではない。
1件でいいから、壊しにいくテストケースだ。
その1件が書けた時点で、要件はもう半分できている。
