社内AIエージェントは権限設計から
# 社内AIエージェントは権限設計から
「社内AIエージェントを作りたい」という相談で、最初に出てくる話題はだいたいツール連携だ。
Slackを読ませたい。Gmailを検索させたい。CRMを更新させたい。カレンダーも見てほしい。気持ちはわかる。使えるデータと操作先が増えるほど、AIが仕事をしてくれそうに見えるからだ。
ただ、実務で詰まるのはそこではない。
本当に先に決めるべきなのは、「そのエージェントは、どこまで知ってよくて、どこまで実行してよいのか」だ。人間の新人に仕事を渡す時も、いきなり全社のメールと請求書と顧客DBを開放しない。AIエージェントでも同じである。
むしろAIの場合は、人間より境界を明文化しなければならない。なぜなら、AIは空気を読んで止まるのではなく、与えられた指示と権限の範囲で動くからだ。
「できること」ではなく「任せてよいこと」を決める
社内AIエージェントの要件定義でありがちな失敗は、機能一覧から始めることだ。
- メールを検索する
- 議事録を要約する
- CRMにタスクを作る
- Slackに報告する
- 提案資料のたたきを作る
この粒度だけを見ると、どれも便利そうに見える。ところが、実装段階ではすぐに問いが細かくなる。
メール検索は誰のメールボックスまで許すのか。議事録要約に未公開の価格情報が含まれた時、どのチャンネルに出してよいのか。CRM更新は下書きまでか、保存までか。Slack報告はDMか、パブリックチャンネルか。提案資料に顧客名を出してよいのか。
ここを曖昧にしたまま「いい感じにやって」と渡すと、エージェントは便利になる前に怖くなる。
第一原理で考えると、AIエージェントとは「判断を含む自動化」だ。通常のRPAは決まったボタンを押す。エージェントは状況を読んで、次の行動を選ぶ。この違いがある以上、要件定義では機能より先に判断境界を決める必要がある。
OpenAIの A Practical Guide to Building Agents でも、実行ループ、ツール、ガードレール、人間の監督が別々の論点として整理されている。実装ライブラリの選定よりも、どの行動に監督を挟むかの設計が先に来る。
社内導入で使いやすい切り方は、業務を次の3段階に分けることだ。
- 読むだけ: メール、議事録、社内ドキュメント、CRM履歴を参照する
- 下書きする: メール文面、提案資料、タスク案、議事録要約を作る
- 確定する: メール送信、予定変更、CRM更新、外部サービスへの書き込みを行う
最初のエージェントは、読むだけと下書きまでで十分なことが多い。確定操作は、人間の承認を挟む。地味だが、この分離だけで社内の心理的な抵抗はかなり下がる。
参照権限は「部署」ではなく「 業務イベント」で切る
権限設計というと、営業部、管理部、開発部のような部署単位で考えがちだ。だが、AIエージェントでは部署単位が粗すぎる。
たとえば営業支援エージェントなら、営業部の全メールを読める必要はない。必要なのは、対象案件に関係するメール、カレンダー予定、議事録、CRMの活動履歴だ。逆に、同じ案件に関係するなら、営業、PM、経理の情報を少しずつ参照する必要があるかもしれない。
つまり権限は「誰の部署か」より「どの業務イベントに紐づくか」で切った方が実務に合う。
例を出す。
展示会後のフォローアップなら、エージェントに必要なのは来場者リスト、名刺情報、過去接点、送信テンプレート、送信済み履歴だ。会計データや人事情報は不要である。商談前の準備なら、対象企業の過去議事録、直近メール、提案資料、参加者プロフィールが必要になる。全CRMを自由検索させるより、対象Dealに紐づく情報だけを渡す方が安全で、回答もぶれにくい。
これは Model Context ProtocolのResources の考え方とも相性がよい。エージェントに世界中の情報を開け渡すのではなく、業務に必要なリソースを文脈として渡す。さらに Tools は、外部システムへ具体的なアクションを起こす入口として扱う。
読み取りリソースと実行ツールを分けて定義すると、要件定義の会話が一気に具体化する。
「このエージェントにCRMを触らせるか？」では広すぎる。「対象Dealの活動履歴は読める。新規Taskは作れる。ただしDealフェーズ変更は承認制」と言えば、関係者が判断しやすい。
実行権限にはリスク等級をつける
社内AIエージェントが価値を出すのは、最終的には実行まで踏み込んだ時だ。読むだけのAIは便利だが、人間の作業を大きく減らすには限界がある。
とはいえ、すべての実行を同じ扱いにしてはいけない。
タスク作成とメール送信ではリスクが違う。カレンダーの仮押さえと顧客への確定連絡も違う。CRMのメモ追記と商談フェーズ変更も違う。請求書作成や契約書送付は、さらに重い。
実行権限は、少なくとも次の4段階に分けると運用しやすい。
| 等級 | 例 | 推奨運用 |
|---|---|---|
| Level 0 | 要約、検索、候補抽出 | 自動実行 |
| Level 1 | タスク案作成、メール下書き、議事録整形 | 自動作成、送信や確定は人間 |
| Level 2 | CRMへのTask保存、社内Slack投稿、Drive保存 | 条件付き自動実行、ログ必須 |
| Level 3 | 顧客へのメール送信、予定変更、契約・請求関連 | 人間承認必須 |
OpenAI Agents SDKの Guardrails は、入力・出力・ツール呼び出しの前後にチェックを置く考え方を提供している。実務上は、これを単なる安全機能ではなく、業務権限の設計として扱うのがよい。
OWASPの Top 10 for Large Language Model Applications でも、プロンプトインジェクションや過剰な権限付与は主要リスクとして扱われている。社内利用だから安全、という前提は置かない方がいい。社内ドキュメントにも、外部メールにも、AIへの指示として解釈される文字列は混ざり得る。
だからこそ、実行ツールには「この操作は戻せるか」「外部に届くか」「お金や契約に関係するか」「個人情報を含むか」という観点でリスク等級をつける。等級が上がるほど、人間承認、ログ、差分表示、ロールバック手順を厚くする。
AIエージェント要件定義の成果物は「仕様書」より「権限表」
社内AIエージェントを作る時、長い仕様書から始める必要はない。むしろ最初に作るべきは権限表だ。
最低限、次の項目があれば議論を前に進められる。
- エージェント名
- 対象業務
- 成功条件
- 参照してよいデータ
- 実行してよい操作
- 人間承認が必要な操作
- 報告先
- ログに残す項目
- 失敗時の止まり方
たとえば営業フォローエージェントなら、成功条件は「期限切れタスクを減らす」「未返信候補を毎朝出す」になる。参照データはCRM Activity、直近メール、カレンダー。実行操作はTask作成まで。メール送信と商談フェーズ変更は承認制。報告先は営業チャンネル。ログは対象会社、判断理由、作成Task ID。失敗時はエラーだけで止めず、未処理リストを残す。
ここまで書けると、実装側はプロンプトより前にシステム設計ができる。データ取得、権限チェック、承認UI、監査ログ、例外処理をどこに置くかが見えてくるからだ。
逆に、この権限表が作れない業務は、まだエージェント化するには早い。業務の責任分界が曖昧なままAIを入れると、人間同士で決まっていないことをAIに押し付ける形になる。
小さく作るなら「朝会前の準備エージェント」から
最初の社内AIエージェントに向いているのは、外部送信を伴わない準備業務だ。
たとえば、朝会前に今日の予定、期限タスク、未返信候補、前日の重要Slack、商談前メモをまとめるエージェント。これは読み取り中心で、失敗しても外部影響が小さい。それでいて、毎日使えば価値が見えやすい。
ここで見るべきKPIは、AIの回答精度だけではない。
- 朝会準備にかかる時間が減ったか
- 期限切れタスクが減ったか
- 会議後のタスク化漏れが減ったか
- 人間が修正した回数はどれくらいか
- 承認待ちで止まる操作はどれくらいか
この数字を見ながら、Level 0からLevel 1、Level 2へ広げていく。いきなり「AI社員に全部任せる」より、業務イベントごとに権限を足す方が失敗しにくい。
アツメルでは、Kakusillで要件定義や仕様書をAIが扱いやすい形に正規化し、仕様書初稿の作成時間を約40%短縮する実績を出してきた。社内AIエージェントでも同じで、効くのは魔法のプロンプトではない。AIが読める業務構造と、人間が納得できる権限境界である。
社内AIエージェントを作るなら、最初の問いは「何ができるAIにするか」ではない。
「どの業務イベントで、何を読ませ、どの操作まで任せるか」だ。
ここが決まると、AIは急に現実の業務に接続し始める。
