AI開発2026-05-15

AI要件定義は権限境界から考える

株式会社Atsumell|7分で読めます

# AI要件定義は権限境界から考える

AI要件定義の相談で、いちばん抜けやすいのは機能ではない。権限だ。

「メールを要約したい」「Slackを読ませたい」「CRMにタスクを入れたい」。この手の要望は自然だし、会話の入口としても分かりやすい。だが、要件定義の本当の論点は、そのAIが何を読めて、何を書けて、どこで止まるかにある。

ここが曖昧だと、AIは便利なふりをしたまま危ないところまで進む。逆に、権限境界を先に決めておくと、要件定義はかなり軽くなる。読む範囲、書く範囲、送る範囲、承認が必要な範囲を分けるだけで、議論の半分は終わる。

OpenAI の A Practical Guide to Building Agents や Agent evals でも、エージェントは「動くか」だけでは足りない。どこまで許すか、どこで止めるか、どう測るかを先に決める必要がある。MCP の Resources と Tools の分け方も同じだ。読める文脈と、実行できる手段は別にした方がいい。

まず決めるのは「読める範囲」

AIに何を読ませるかは、性能より先に決めるべきだ。

たとえば営業フォローのAIなら、Gmail、Calendar、Slack、CRM の全部を読めるようにしたくなる。だが、全部読める設計は危ない。読める範囲が広いほど、機密や個人情報が混ざる可能性も広がる。

ここで必要なのは、次のような線引きだ。

何を参照してよいか
何を参照してはいけないか
どの期間まで読むか
どの会社・案件だけを対象にするか

この段階で曖昧さを残すと、AIは「それっぽい要約」を返す。だが現場が欲しいのは、賢い文章ではなく、読む対象が明確な出力だ。

アツメルでも、要件定義で先に効くのは「全部見せる」より「見せる範囲を決める」ことだ。範囲が決まれば、後工程のレビューも一気に楽になる。

次に決めるのは「書ける範囲」

読むより危ないのは、書ける範囲だ。

AIが下書きを作るだけなら、まだ修正で済む。だが、タスク作成、カレンダー変更、CRM更新、外部送信まで許すと、事故の種類が増える。要件定義では、ここをひとまとめにしない方がいい。

書ける範囲は、少なくとも4段階に分けられる。

段階	許可すること	例
読むだけ	参照のみ	メール要約、会議メモ抽出
下書きまで	文面や候補生成	返信案、タスク案、要約案
保存まで	内部データに反映	CRMのドラフト登録、ToDo作成
送信/更新まで	外部や本番に反映	メール送信、予定変更、フェーズ更新

この表のポイントは、後ろに行くほど責任が重くなることを明示することだ。

AI要件定義が壊れる典型は、「便利だから送信まで欲しい」が先に来ることだ。だが、本当に必要なのは送信ではなく、送信してよい条件の定義だろうか。そこを分けないと、権限設計は最後まで曖昧なままになる。

最後に決めるのは「止める条件」

権限境界は、許可する線だけでは足りない。止める条件も必要だ。

たとえば次のような場面だ。

個人情報や機密語が混ざっていた
送信先が複数で優先順位がつけられない
同じ案件の既存タスクがすでにある
予定変更がオーナー権限に触れる
内容が曖昧で、AIが補完すると危ない

この止める条件は、AIの弱さを補うためではない。人間の判断が必要なところを、早く人間に戻すためにある。

OWASP Top 10 for LLM Applications が扱うリスクも、結局はこの境界管理に近い。プロンプトインジェクションや過剰な権限付与は、AIが賢いかどうかとは別問題だ。読めるものと、動かせるものが混ざると起きる。

実務では「3つの線」で十分

最初から複雑な権限表を作る必要はない。実務では、次の3つの線を引けば十分だ。

読んでよい線
書いてよい線
人間が止める線

この3つがあるだけで、要件定義の会話はかなり具体化する。

たとえば朝会前の準備業務なら、AIは重要なメールを読むことはできる。下書きは作れる。だが、外部送信は人間確認が必要にする。カレンダー変更も同じだ。候補日を出すのはよいが、主催者の予定を直接動かすのは止める。

このルールを先に決めると、レビュー設計もテストケースも自然に決まる。 AI要件定義で最初に作るテストケースで書いた正常系・判断分岐系・停止系は、この権限境界を実際のケースに落としたものだ。さらに AI要件定義は変更差分から始めると合わせると、現状と目標の差分の中で、どこまでAIに任せるかがはっきりする。