AIエージェントの権限設計: 読む、書く、実行するをなぜ分けるべきか

1. 概要: 権限設計は運用設計である

多くの会社は、「AIが答える」段階から「AIが会社のツールを使う」段階へ急ぎすぎます。Notionを開き、Google Driveを検索し、CRMの行を更新し、メールの下書きを作り、ワークフローを起動するデモは魅力的です。しかし、接続するツールが増えるたびにリスクの形も変わります。

OpenAIのエージェント安全ガイドは、MCPツールを使うとき、読み取りや書き込みを含む操作をユーザーが確認できるように承認を有効にしておくべきだと説明しています。OWASPも、過剰な権限、過剰な自律性、プロンプトインジェクション、機密情報の漏えいをLLMやエージェントの主要リスクとして扱っています。

実務上の答えは、建物の入館カードのように権限を設計することです。来客カードはロビーだけを開けます。社員カードはオフィスを開けます。経理の鍵は支払い承認まで開けるかもしれません。AIエージェントにも、会社システムに触れる前に同じ分離が必要です。

2. 用語をやさしく言う: 権限、範囲、役割、ログ

権限とは、AIに渡す鍵です。ある鍵は一つの部屋だけを開け、別の鍵は複数の部屋を開け、危険な鍵は建物全体を開けます。範囲とは、その鍵でどこまで見られるか、どんな行動までできるかを決める線です。

役割とは、鍵についている職務名です。サポート下書きエージェント、経理レビューエージェント、創業者補助エージェントは、同じモデルを使っていても同じ権限を持つべきではありません。

最小権限とは、目的に必要な最小の鍵だけを渡す考え方です。ポリシーを要約するAIに、ポリシーフォルダの編集権限は不要です。メールの下書きだけを作るAIに、実際の送信権限は不要です。

期限付き認証とは、期限が切れる貸し出し鍵です。永久のマスターキーを渡す代わりに、一つの作業や一つのセッションだけで使える短いアクセスを渡します。

監査ログとは、領収書や防犯カメラの記録に近いものです。AIが何を読み、何を変え、どのツールを呼び、誰が承認したのかを残します。

• 読む: AIがポリシー文書、チケット、議事録、顧客記録などの情報を見る権限。
• 書く: AIが下書き、内部メモ、CRM項目、チケット状態、スプレッドシート行、提案文書を作成または編集する権限。
• 実行する: AIが送信、決済、削除、公開、署名、注文、招待、外部API呼び出しのように、戻しにくい行動を起こす権限。
• MCP: AIアプリケーションを外部データ、ツール、ワークフローにつなぐ標準的な接続方式。
• 人の承認ゲート: AIがいったん止まり、人が次の行動を確認するチェックポイント。

3. 読む権限: 行動より先に知識接続から始める

読む権限は、最初に価値が出やすい層です。エージェントが一般論ではなく会社の文脈で答えられるようになります。SOP、返金ポリシー、製品仕様、過去チケット、オンボーディング文書、顧客履歴、議事録を読めるからです。

ただし、読む権限は無害ではありません。OpenAIは、接続されたツールに対してモデルが想定以上のデータを共有してしまうprivate data leakageのリスクを説明しています。OWASPも機密情報漏えいをLLMアプリケーションの主要リスクに含めています。だから読む権限にも範囲が必要です。

実務基準はシンプルです。その役割の新入社員に見せられるものからAIに見せます。サポートAIは顧客チケットとポリシーを読めてもよいですが、給与、創業者の個人メモ、非公開の投資資料、秘密鍵まで読む必要はありません。

• 良い読み取り範囲: 公開ポリシー、承認済みSOP、顧客向け文書、分類済みチケット、製品FAQ、機密でない知識ノート。
• 危険な読み取り範囲: 生のメールボックス全体、非公開DM、給与、法務紛争、認証情報、健康情報、未公開財務、すべてのファイルへのアクセス。
• 読み取り管理: ソース許可リスト、文書の機密度ランク、検索ログ、個人情報フィルター、回答の引用元表示。

4. 書く権限: 下書きと公式記録を分ける

書く権限では、多くのチームが境界をあいまいにします。下書きは公式記録ではありません。CRM更新案は実際のCRM更新ではありません。返金メモは返金実行ではありません。

最も安全な中間層は、下書き専用の書き込みです。AIは返信案、入力フォーム、タグ提案、レビュー用テーブル、内部メモを作れます。ただし最終反映は、人または明確なルールが担当します。

この段階ではレビューコストも見えてきます。AIが自由に大量に書くと、チームは隠れた誤りを探す時間を払います。良い書き込み権限は、小さな変更、確認できる出典、見えるdiffを残すべきです。

• 低リスクの書き込み: 返信の下書き、通話要約、タグ提案、チェックリスト作成、レポート構成、レビュー待ち項目の入力。
• 中リスクの書き込み: CRMステージ変更、チケット状態変更、内部文書編集、共有スプレッドシートへの入力。
• 書き込み管理: ステージング領域、diff表示、担当者レビュー、ロールバック経路、項目ごとの権限、サンプルQA。

5. 実行権限: 外部に影響する行動は高リスク

実行権限は、AIが外の世界に影響を与える瞬間です。メール送信、カード決済、データ削除、ページ公開、契約作成、権限変更、本番API呼び出しは、法務、金銭、ブランド、顧客信頼のリスクを作ります。

OpenAIのエージェントガイドは、ツールのリスクを、読み取り専用か書き込み権限か、戻せるか、アカウント権限や金銭影響があるかで評価することを勧めています。言い換えると、戻しにくく、お金が動き、個人情報が見え、他人が見る内容が変わるほどリスクは上がります。

非エンジニアのチームでは、ルールは単純でかまいません。AIは提案できます。AIは下書きできます。AIは準備できます。しかし影響の大きい実行には、承認ゲート、名前のある責任者、ログが必要です。

• 必ず承認する行動: 外部メール送信、返金または決済、データ削除、顧客向けコンテンツ公開、契約署名、ユーザー招待、権限変更、本番デプロイ。
• 最初に避ける行動: 広いshellアクセス、秘密ファイルアクセス、決済実行、法的約束、大量メッセージ、破壊的な一括変更。
• 実行管理: 人の承認、高リスクの二重レビュー、回数制限、ドメイン許可リスト、期限付き認証、ロールバック計画、監査ログ。

6. 実際の導入に使う権限ラダー

安全な導入は、「エージェントを使わない」ことではありません。階段を作ることです。一つの反復業務から始め、前の段階が測定でき、ログに残り、十分に退屈なくらい安定してから次へ進みます。

x-inbox-routerで拾ったXのシグナルも、同じ運用問題を別角度から示しています。Tool Calling、MCP、Skillsは同じ意味ではなく別の層だという指摘がありました。また、Markdownのcompany OSとMCPツール接続は強力ですが、調査から実行に移る瞬間にsafeguardと責任者が必要だという例もありました。

Guildex式の権限ラダーは、この違いをツール接続の前に見える形にします。

• レベル0: ツールアクセスなし。貼り付けられた文脈だけで回答。
• レベル1: 承認済み知識を読む。出典を示すが記録は変えない。
• レベル2: 下書き専用で書く。キューやステージング領域にだけ結果を作る。
• レベル3: レビュー後に書く。承認後、限定された内部変更だけ反映。
• レベル4: 承認付きで実行する。高リスク行動は明示的な承認後に実行。
• レベル5: 狭い自動実行。戻せて、影響が低く、回数制限があり、繰り返し検証された行動だけ自動化。

7. 避けたい失敗パターン

一つ目の失敗はマスターキーアクセスです。便利だからという理由で、エージェントにすべてのファイル、すべてのチャンネル、すべてのツールを接続します。その結果は賢い社員ではなく、責任境界が見えない無制限の行為者です。

二つ目の失敗は隠れた行動です。見た目は要約や下書きなのに、一つのツール呼び出しでCRM行を変更し、メッセージを送り、リストをエクスポートします。運用者が境界を見られなければ、制御もできません。

三つ目の失敗は承認のふりです。人がきれいな要約だけを見て承認ボタンを押しますが、出典、変更内容、リスクは見えていません。本当の承認ゲートは、何が実行されるか、なぜ実行されるか、どのデータが使われたか、どう戻せるかを見せます。

• 読む、書く、実行するを一つの広い「AIツール権限」にまとめない。
• エージェントに認証情報、給与、非公開の法務フォルダを読ませない。本当に必要な場合だけ別途レビューする。
• ツール説明や外部テキストが、検証なしに権限ある行動を直接動かさないようにする。
• 要約だけを見て承認しない。出典、変更フィールド、影響を受けるユーザー、ロールバック方法を一緒に見る。
• 一つの成功デモを、永続的な本番権限にしない。

8. Guildex基準: エージェントより先に権限表を作る

実務用の権限表には六つの列が必要です。ソース、所有者、機密度、許可される行動、承認条件、ログの場所です。導入初期には、モデル名よりこの表のほうが重要です。

各ワークフローで問いましょう。AIは何を読む必要があるのか。何を下書きとして書けるのか。何をレビュー後に変更できるのか。何はまだ自動化してはいけないのか。

目的は会社を遅くすることではありません。責任が消えない形でAIを役立てることです。良い権限設計は、鍵、ゲート、領収書が見えるため、人がシステムを信頼できるようにします。