AIエージェント要件定義は評価設計から
# AIエージェント要件定義は評価設計から
AIエージェントの相談を受けると、最初に出てくるのはたいてい機能の話だ。
Slackを読ませたい。Gmailも見せたい。CRMにタスクを入れたい。カレンダーも触らせたい。気持ちはわかる。できることを並べると、いかにも仕事が進みそうに見えるからだ。
でも、実務で止まるのはそ こではない。
本当に先に決めるべきなのは、「何ができるか」ではなく「何をもって成功とみなすか」だ。AIエージェントは単なるチャットボットではない。状況を読み、判断し、ツールを選び、場合によっては止まる。だから要件定義も、機能表より先に評価設計が要る。
OpenAIの A Practical Guide to Building Agents でも、エージェントはモデル・ツール・指示に加えて、ガードレールや評価の設計が重要だと整理されている。実装より前に、どこまで任せるか、どこで止めるか、どう測るかを決める発想だ。
まず決めるのは「合格ライン」
評価設計の第一歩は、正解を一つに決めることではない。
むしろ必要なのは、合格ラインを決めることだ。
たとえば「商談後のフォローを支援するAIエージェント」を作るなら、合格は「完璧な文面を出すこと」ではない。営業がそのまま使える下書きを出し、対象案件のタスク漏れを減らし、危ない送信は勝手にしないことだ。
ここでの評価軸は少なくとも3つある。
- 仕事が前に進んだか
- 間違って外に出してはいけ ないものを止められたか
- 人間の修正コストが減ったか
この3つがないと、AIの出来は印象でしか測れない。印象で回すと、最初は盛り上がるが、2週間後には誰も使わなくなる。
評価は4層で見ると崩れにくい
社内AIエージェントは、だいたい次の4層で評価すると見通しがよくなる。
| 層 | 見るもの | 失敗シグナル |
|---|---|---|
| 1. 仕事完了 | タスクを最後まで進められたか | 途中で止まる、やり直しが多い |
| 2. 安全性 | 読んでよい情報と、触ってよい操作を守れたか | 権限外の情報を参照する |
| 3. 修正コスト | 人間がどれだけ直したか | 下書きが使えずゼロから書き直す |
| 4. 速度 | 人手より速くなったか | 速いが雑、結局確認が重い |
OpenAIの Agent evals のように、まずベースラインを置く考え方は有効だ。評価項目を先に固定しておくと、改善したのか、ただ雰囲気が良くなっただけなのかが分かる。
評価は精度だけでも、速度だけでも足りない。社内利用では特に、安全性と修正コストを分けて見るのが効く。正答率が高くても、危険なメールを下書きしていたら意味がない。逆に安全でも、毎回人間が全部直すなら導入効果は小さい。
テストケースがない要件定義は、だいたい空振る
評価設計が弱いチームは、だいたいテストケースを後回しにする。
しかし、AIエージェントの要件定義はテストケースを先に書いた方が早い。
理由は単純で、エージェントは「曖昧な入力に対して、どこまで判断してよいか」を問われるからだ。仕様書だけでは抜ける。実際のケースに落とすと、急に論点が見える。
たとえば次のようなケースが必要になる。
- いつも通りの案件メールが来たとき
- 条件が曖昧で、追加確認が必要なとき
- 社外秘の話題が混ざっているとき
- 送信や更新の直前で止めるべきとき
- ユーザーが雑な指示を出したとき
この手のケースを先に作ると、要件定義の抜けが見える。たとえば「CRMにタスクを作る」と書いていても、どの条件で作るかが抜けていることが多い。タイトルだけなら簡単そうに見えるが、実運用では「重複はどうするか」「期限は誰が決めるか」「失敗時にどう戻すか」が本体になる。
OWASPの Top 10 for Large Language Model Applications が示すように、プロンプトインジェクションや過剰な権限付与は現実的なリスクだ。だからテストケースには、普通の成功例だけでなく、わざと壊しにいくケースも入れるべきだ。
権限設計と評価設計はセットで考える
権限が決まっていないAIエージェントは怖い。だが、権限だけ決まっていても十分ではない。
なぜなら、権限は「やってよいこと」の境界で、評価は「うまくやれているか」の確認だからだ。片方だけでは、導入後の会話が止まる。
たとえば、MCPの Resources と Tools の考え方は分かりやすい。読むための文脈と、実行するための手段を分ける。これに対して、評価設計は「その切り分けが本当に業務に効いているか」を確かめる役目を持つ。
OpenAIの Guardrails のように、危険な入力や高リスク操作を止める仕組みは重要だ。ただ、ガードレールを入れただけでは成功しない。止めるべきところで止まり、通すべきところで通っているかを見ないと、守りが強すぎて何も進まなくなる。
だから要件定義では、次を一緒に書くとよい。
- どのデータを読ませるか
- どの操作を任せるか
- どの条件で人間承認に切り替えるか
- 何件中何件を合格とするか
- 失敗したときにどこで止めるか
この5つが揃うと、権限表がそのまま評価表になる。実装側も楽だし、運用側も迷いにくい。
小さく始めるなら、朝会前の準備で測る
いきな り「AI社員に全部任せる」は危ない。最初は、外部送信を伴わない準備業務がちょうどいい。
たとえば、朝会前に以下をまとめるエージェントだ。
- 今日の予定
- 期限切れが近いタスク
- 未返信の候補
- 昨日の重要Slack
- 商談前メモ
この用途なら、評価もしやすい。
- 抜け漏れが減ったか
- 人間の確認時間が減ったか
- 危険な操作を勝手にしなかったか
- 修正回数が下がったか
ここで重要なのは、AIの出力が「それっぽい」かどうかではない。業務が軽くなったかどうかだ。
アツメルでも、仕様書や要件をAIが扱いやすい形に整えると、初稿の作成時間が目に見えて短くなる。効くのは魔法のプロンプトではなく、評価できる形に業務を切ることだ。AIは、評価できるものしか改善できない。
まとめると
AIエージェントの要件定義は、機能一覧から入ると外す。
先に決めるべきなのは、成功条件、失敗条件、権限の境界、そして測り方だ。評価設計が先にあると、実装は迷いにくくなるし、導入後の揉めごとも減る。
要件定義の段階で、「何ができる か」ではなく「何をもって合格とするか」を書く。これだけで、社内AIエージェントはかなり現実的になる。
