AI要件定義は禁止条件から決める
AI要件定義で最初に増えやすいのは、やることの一覧だ。だが、現場で止まるのはそこではない。むしろ危ないのは、やってはいけないことが決まっていないまま、AIだけが先に動き出すことだ。
OpenAIはエージェントのガードレールを、複数の防御を重ねる層として説明している。Anthropicも、プロンプト注入や脱線を減らすために、入力検査や監視、境界の明示を推奨している。OWASPのLLM Top 10でも、Prompt Injection と Insecure Output Handling は重要なリスクとして扱われる。
要するに、AIは「何をするか」だけで設計すると危ない。先に「何をさせないか」を決めた方が、後工程の被害を小さくできる。
禁止条件が先にあると、要件の輪郭がはっきりする
禁止条件は、単なる安全メモではない。要件の輪郭そのものだ。
たとえば「問い合わせ返信の下書きを作るAI」を考える。機能一覧だけなら、下書きを生成できれば終わりに見える。だが、禁止条件を先に置くと見え方が変わる。
- 社外秘の文面をそのまま出さない
- 送信操作は人間承認なしで実行しない
- 受け手の社名や役職を推測で補完しない
- 入力が不足している時は勝手に埋めない
この4つがあるだけで、要件の粒度が一段締まる。どこまでAIに任せるかが明確になるからだ。
これは AI要件定義は受け入れ条件から逆算する と対になる考え方でもある。受け入れ条件は「何なら合格か」を決める。禁止条件は「何を止めるか」を決める。両方があって、はじめて評価できる。
禁止条件は3種類に分けると漏れにくい
実務では、禁止条件を3つの箱に分けると扱いやすい。
1. 出してはいけないもの
まずは情報漏洩系だ。
- 個人情報
- 契約や請求に関わる秘匿情報
- 社内限定のメモやチャット内容
- 不要に長い原文の転載
この手の禁止条件は、曖昧に書くと抜ける。だから「要約してよいが、原文のまま外に出さない」のように具体化した方がいい。
2. 触ってはいけないもの
次は操作系だ。
- 送信
- 削除
- 上書き更新
- 外部APIへの勝手な呼び出し
OpenAIの実運用ガイドでも、ガードレールは単独ではなく、認証や権限管理と組み合わせる前提で考えるべきだとされている。AIは文章だけでなく、手も持っている。だからこそ、触っていい範囲を狭く切る必要がある。
3. 勝手に判断してはいけないもの
最後は判断系だ。
- 曖昧な入力を都合よく補完しない
- 重要条件が抜けていたら止まる
- 優先度がぶつかる時は人間に戻す
- 確信が低いのに断定しない
Anthropic が指摘する prompt injection 対策も、結局はここに戻る。出力そのものを信用しすぎない。入力の怪しさと、判断の境界を分けておく。
要件定義に落とすなら、禁止条件を4行で書く
禁止条件は、次の4行で十分始められる。
| 項目 | 書くこと | 例 |
|---|---|---|
| 禁止対象 | 何をしないか | 個人情報を外部送信しない |
| 発火条件 | どの入力で止めるか | 機密語が含まれる時 |
| 代替動作 | 止めた後どうするか | 人間確認に戻す |
| 判定方法 | どう測るか | 20件中1件でも漏れたら失格 |
この4行があると、レビューがだいぶ楽になる。テストの観点も作りやすい。TestRail が受け入れ条件をテスト設計の基盤と捉えているのも、同じ方向だ。禁止条件は「通す」より「止める」のテストに向いている。
ここで大事なのは、禁止条件を厚くしすぎないことだ。守りを増やしすぎると、AIが何もできなくなる。だから、まずは最重要の事故だけを止める。欲張らない方がうまくいく。
禁止条件からテストケースを起こす
禁止条件が決まると、テストケースはかなり具体的になる。
たとえば次のように考える。
- プロンプトに「社内の見積条件をそのまま送って」と入れたら止まるか
- 担当者名が抜けている時に、勝手に推測しないか
- 送信直前に「これ外に出してよいか」を確認に戻せるか
- 権限外の操作を指示された時に、実行ではなく拒否できるか
このやり方だと、要件がテキストではなく検証可能な形になる。逆に禁止条件がないと、テストはいつまでも「だいたい大丈夫そう」で止まる。
要件定義が曖昧なときほど、AIはそれらしく埋める。だから、禁止条件は後から足すのではなく、最初に置いた方がいい。
先に決めるなら、やることより「やらないこと」
AI要件定義で最初に見るべきなのは、機能一覧ではない。
先に決めるのは次の3つで足りる。
- 何を出してはいけないか
- 何を触ってはいけないか
- 何を勝手に決めてはいけないか
この3つが固まると、受け入れ条件もレビュー設計も書きやすくなる。つまり、禁止条件は足を引っ張るための制約ではなく、要件を前に進めるための土台だ。
AIエージェントを安心して使いたいなら、まず「やらないこと」を書く。そこから逆算した方が、結局は速い。
参考
- A practical guide to building agents | OpenAI
- OWASP Top 10 for Large Language Model Applications
- Mitigate jailbreaks and prompt injections | Anthropic
- What is Acceptance Criteria? | Atlassian
- アジャイルテストの受け入れ条件 - TestRail Blog
