【追記：2026年6月12日】 本連載の執筆後、2026年6月12日に、米政府の輸出管理指令により、AnthropicはClaude Fable 5およびMythos 5へのアクセスを一時停止しました（同社はこの措置に異議を表明し、復旧を目指すとしています）。本文中のFable 5に関する記述は執筆時点のものとしてお読みください。ただし、本連載が扱う権限設計をはじめとする設計の考え方そのものは、特定のモデルの提供状況に左右されず有効です。Fable 5は論を進めるための代表的な事例として取り上げています。状況は流動的であり、最新の状況は一次情報をご確認ください。
前回は、モデル選定の話をした。どの賢さを、いくらで買うか。だが実は、エージェント構築で最初に答えを出すべき問いは、賢さでもコストでもない。
そのエージェントに、何をする権限を渡すのか。
なぜこれが先なのか。エージェントの事故は、ほとんどの場合「賢さが足りなかった」からではなく、「権限を渡しすぎていた」から起きるからだ。判断を間違えないモデルは存在しない。人間の従業員ですら間違える。組織が従業員のミスを致命傷にしないために権限と承認の仕組みを作ってきたのと同じことが、エージェントにも要る。むしろ、エージェントにこそ要る。
モデルは騙せても、権限は騙せない
エージェント特有の脅威に、プロンプトインジェクションがある。Webページやメール、ドキュメントの中に「こう動け」という指示を仕込んでおくと、エージェントがそれを本物の指示と取り違えて従ってしまう問題だ。提供元のAI企業自身が、この問題は当面なくならないと認めている。
ここで重要なのは、防御の主戦場がどこにあるかだ。「騙されにくいモデルを選ぶ」のは対策の一部にはなる。前回見たFable 5では、公開前に外部バグバウンティとレッドチーム組織が、安全分類器を含むシステム全体に対して1,000時間を超えるジェイルブレイク試行を行い、汎用的な突破口は見つからなかったと報告されている。ただし同時に、英国のAIセキュリティ研究所（UK AISI）が短い初期テスト期間内に突破へ向けた部分的な前進を見せたことをAnthropic自身が開示しており、同社は「あらゆる試行を恒久に防ぎきれるシステムは存在しにくい」とも認めている。「見つかっていない」と「存在しない」は別の話で、説得・誘導への耐性は確率的な防御にとどまる。
一方、権限は確率ではない。読み取り専用の資格情報しか持たないエージェントは、どれほど巧妙に騙されても、データを書き換えられない。送金する権限がなければ、送金できない。モデルの判断は説得されうるが、権限の境界は説得されない。 だから権限設計が、エージェントセキュリティの第一防衛線になる。
このテーマは先日、単発記事「合鍵を渡すな、委任状を書け」で自社の経理自動化を題材に詳しく書いた。要点だけ引き継ぐと──エージェントに自分のアカウントでログインさせる（合鍵を渡す）のではなく、何を・どこまでやってよいかを絞った許可を渡す（委任状を書く）。なりすましではなく、委任。今回はその委任状に「何を書くか」を、設計手順として整理する。
権限の4象限 — リスクの濃淡を地図にする
エージェントに渡しうる権限を、2つの軸で整理してみる。横軸は操作の性質（読むだけか、書き換えるか）。縦軸は影響の届く範囲（社内に閉じるか、社外に出るか）。
図の読み方を言葉で補っておく。
① 社内×読み取りは最も低リスクの象限だ。社内文書の検索や参照は、間違えても「変なものを読んだ」で済む。エージェント導入はここから始めるのが定石になる。
② 社外×読み取りは一見無害だが、注意が要る。外部のWebページやメールを「読む」行為こそが、プロンプトインジェクションの入口だからだ。読み取り自体の被害は小さいが、ここで拾った偽の指示が、他の象限の権限と組み合わさったときに事故になる。読む権限と書く権限を同じエージェントに同居させるなら、この経路を意識しなければならない。
③ 社内×書き込みから、リスクの質が変わる。データの作成・更新・削除は、間違いが残る。バックアップと取り消し手段があるか、操作ログが残るかが、この象限を許可する条件になる。
④ 社外×書き込みが最高リスクだ。メールの送信、コンテンツの公開、決済。社外に出たものは、原則として取り消せない。不可逆な操作は、エージェントの自律実行から最後まで外しておくべき領域であり、許可する場合も人間の承認をワンクッション挟む（human-in-the-loop）のが原則になる。この承認パターンはLangGraphなど主要なエージェントフレームワークで標準機能として用意されており、実装面のハードルは年々下がっている。
つまり権限設計とは、①から④へ向かう坂道のどこにエージェントを立たせるかを決める作業だ。そして坂の上に行くほど、「させること」ではなく「させないこと」の定義が仕事の中心になる。
「させないこと」リストの作り方
実務に落とすなら、エージェントの企画書には機能一覧と並べて「禁止事項一覧」を書く。出発点として汎用的に使えるリストを挙げる。
| させないこと | 具体例 | 理由 | |
|---|---|---|---|
| 認証情報を扱わせない | ID・パスワード・APIキーの入力や保管 | 漏えい時の被害が権限の全範囲に及ぶ。委任は範囲を絞ったトークンで行う（OAuthのToken Exchangeやエージェント向け委任の標準化も進行中） | |
| 不可逆操作を自律実行させない | 送信・公開・本削除・決済の確定 | 取り消せない操作は人間の承認を最終関門にする | |
| 金銭を動かさせない | 振込・支払い・契約の締結 | 誤りが直接の損失になる。参照と下書きまでに留める | |
| 権限そのものを触らせない | 共有設定・アクセス権・アカウント設定の変更 | 権限を変えられるエージェントは、自分の檻を開けられる | |
| 外部由来の指示に従わせない | Webページやメール内の命令文の実行 | 指示の正当な発生源を人間の入力に限定する |
ちなみに、こうした過剰な権限付与のリスクは本稿の発明ではない。OWASPのLLMアプリケーション向けセキュリティリスクTop 10でも「Excessive Agency（過剰な代理権の付与）」として体系化されており、エージェント固有の脅威を扱う新しいTop 10の整備も進んでいる。上のリストは、その国際標準を日々の企画書に落とすための実務版だと思ってもらえばいい。
このリストを眺めて、既視感を覚えた読者がいるかもしれない。前回紹介したFable 5は、サイバー攻撃や生物・化学などの高リスク領域で応答を遮断し、Claude Opus 4.8に引き継ぐ設計を持っていた（発生はセッションの5%未満とされ、切り替えはユーザーに通知される）。あれはモデル提供元が自社製品に書いた「させないことリスト」にほかならない。最先端のAI企業が、最強のモデルにまず禁止事項を実装してから世に出した──この順序自体が、権限設計の優先度を物語っている。
そして運用面の原則をひとつ。権限は「最初に絞って、実績に応じて段階的に開ける」。逆向き──最初に広く渡して、事故が起きてから絞る──は、必ず後悔する。①の象限で数ヶ月運用し、ログを眺め、誤動作の傾向を掴んでから③を検討する。④は最後まで人間の承認付き。地味だが、これが組織としての正しい坂の登り方だ。
権限設計は「一度きりの設定」ではない
まとめよう。
- エージェントの事故は賢さ不足ではなく権限過多で起きる。権限の境界はモデルの判断と違って「説得されない」第一防衛線になる
- 権限は「読む/書く × 社内/社外」の4象限で棚卸しし、低リスク象限から段階的に開ける
- 機能一覧より先に「させないことリスト」を書く。不可逆操作・金銭・権限変更・認証情報は原則として渡さない
ただし、ここまで読んで気づいた方もいるだろう。この設計は静的には完結しない。モデルの世代が変われば能力の範囲が変わり、「安心して任せられる境界」も動く。現にFable 5は、リクエストの内容に応じてモデル自体を切り替えるという、一段動的な制御を組み込んできた。
権限を固定の壁として建てるのではなく、状況に応じて能力を段階制御する──次回は、このフォールバック設計の考え方を、Fable 5の実装を教材に掘り下げる。
参考情報
この記事をシェアする
