AIモデルは推論力が高まり、コンテキストウィンドウに収められる文章量も大きく増え、画像も読み取れるようになりました。それでも多くの大企業は、人に代わって複数の手順からなる作業をこなすAIエージェントに、実際の業務システムを自律的に操作させることをいまだに認めていません。妨げになっているのは知能ではなく認可です。ある時点でエージェントに何が許されているのかを、確信を持って言える人がいないのです。そこで広がりつつある答えが実行時認可です。エージェントが誰のために働き、何を頼まれたのかに基づいて、ツール呼び出しの一つひとつを、その呼び出しの瞬間に許可するかどうか判断します。
従来の権限モデルが通用しない理由
銀行のように規制を受ける企業は、セキュリティ、信頼、事業継続を最優先にしており、イノベーションは2番目、3番目、場合によっては4番目にとどまります。そのシステムは、何世代ものソフトウェアの上に積み重なったIDの孤島と認可方式の寄せ集めで、決まった通りに動くプログラムと予測可能な人間のオペレーターを前提に作られています。同じ依頼にも毎回違う反応を返しうる大規模言語モデル（LLM）は、この枠組みに収まりません。
あるWebサイトが利用者に代わって別のサイトで操作できるようにする標準規格、OAuthがその溝をよく示しています。OAuthの共同開発者によると、OAuthは静的なサイト間の委任を前提に設計されました。アプリは事前に登録され、利用者はブラウザーでリダイレクトされ、スコープ（権限のまとまり）はあらかじめ固定されます。一方、エージェントは実行のたびにたどる道筋が変わるため、タスクにどのツールが必要になるかを前もって知ることができません。
権限そのものも粗すぎます。Salesforceはかつて、広範なAPIスコープを1つしか用意していませんでした。AIモデルを外部のツールやデータにつなぐ標準規格Model Context Protocol（MCP）のNotion向けサーバーは、汎用のページ取得ツールを公開していますが、特定のサブデータベースだけに絞り込むのは容易ではありません。これほど粗い権限をエージェントに渡せば、ステージング環境でのいつものバグ探しが、本番データベースの消去で終わるおそれもあります。
人だけでなく取引を認可する
JPMorgan Chaseのグローバル最高セキュリティアーキテクトは、エージェントの権限を新人開発者のオンボーディングにたとえます。入社初日から本番環境へのコミット権限を与えられる人はいません。信頼できると示すにつれてアクセスが広がるのであり、エージェントも同じように自律性を勝ち取るべきだといいます。
同氏によれば、銀行は数十年前に同じような転換を済ませています。顧客が誰かを確かめるだけの段階から、取引の一つひとつを実行時に、その文脈の中で承認する段階へと移ったのです。紙の小切手がこの考え方をよく表しています。メモ欄には支払いの意図が記され、受取人、金額、日付が厳格な制限になります。エージェントの行動ごとに意図を記録すれば、セキュリティチームにも同じ効果があります。各ステップがなぜ起きたのかがわかり、障害の原因を早く突き止められるのです。
その文脈は、エージェント自身の申告ではなく、客観的なシグナルから得る必要があります。エージェントが、他のシステムから切り離された隔離環境であるサンドボックスの中で動いているか。リクエストがどこから、いつ、どの端末とクライアントソフトウェアから来ているか。対象のサーバーに未修正の高リスクな脆弱性が残っていないか。こうした情報とエージェントが表明した意図を、複数のシステムをまたいでリクエストを追う記録であるOpenTelemetryのトレースに加えれば、診断が速くなり、広く恒久的な権限ではなく、短時間で範囲を絞ったアクセスを与えられるようになります。
| 問い | 静的な権限 | 実行時認可 |
|---|---|---|
| アクセスはいつ決まるか | 事前に一度だけ | ツール呼び出しのたび |
| 何に基づくか | IDと事前設定のスコープ | ミッション、意図、その時点の文脈 |
| アクセスはどれだけ続くか | 広く常時有効 | 狭く短時間 |
| 行動はどう追跡されるか | 孤立したばらばらの判断 | 共通のミッションIDで結びつく |
ミッションがすべての行動に共通の目的を与える
そのOAuth共同開発者が率いるオープンなプロトコルAAuthは、単純なルールから出発します。エージェントは常に「人」のために動き、その「人」とは個人か法人のいずれかだというものです。エージェントは責任を負えないため、責任はエージェントを認可した側に残ります。
このプロトコルの中心にあるのがミッションです。作業を始める前に利用者とエージェントが合意する全体の目標を指します。有能なエージェントは、範囲や条件をはっきりさせるよう利用者に確認しながらミッションを取り決めます。その後の認可判断はすべてミッションに照らして確認され、持続するミッションIDがあらゆる取引とツール呼び出しに付いて回ります。そのため、セキュリティチームは後から、どの判断がどのミッションの下で下されたのかを正確に確かめられます。文脈があれば、同じ支払いが5秒差で2回実行されるといった、単独では正しく見える誤りも見つけられます。
意図には層があります。企業が開発者の生産性を高めるためにClaude Codeを導入するなら、それはビジネス上の意図です。エンジニアがステージング環境のバグを1つ直すよう頼むのは、取引単位の意図です。安全に動ける範囲は、この2つが重なる部分です。買い物の候補を提案するエージェントのセッションと、本番環境のバグを切り分けるセッションでは、必要な権限も、人間を呼び戻す基準も異なります。
個々のリソースに固定のアクセス権を結びつける従来のIDおよびアクセス管理（IAM）と違い、意図に基づくモデルは、部門ごとの意図を実行時に別々に評価します。ミッションは数週間続くこともあるため、認可の状態もその間ずっと保持しなければなりません。JPMorgan Chaseのセキュリティアーキテクトは、こうしたミッションの追跡はほとんどの企業でまだ始まったばかりだと注意を促しています。
作業役と監督役を分ける
ある社員が、インシデント対応のエージェントにCEOの受信箱を読むよう指示したとします。OAuthの共同開発者は、よくできたシステムならこの依頼を拒否するはずであり、作業をするエージェント自身に、自らの制限を取り締まる役を担わせてはならないと主張します。作業役に何を許すかは、独立した監督エージェントが決めるべきだというのです。役員のメールボックスを開くといった明白な違反は決定論的なルールで遮断できますが、社内の役員メッセージを外部ドメインに転送するようなグレーゾーンの依頼には、監督役の判断が必要です。同氏はさらに、作業エージェントを提供するベンダーにガードレールまで任せることは利益相反になると警告しています。
人間にすべてを承認させるのもうまくいきません。承認の依頼が延々と続くと同意疲れが起き、疲れた人は中身を見ずに承認するようになります。より良い設計は、決して起きてはならない行動について広い基本ルールを定め、人が実行前に手順を確認するヒューマン・イン・ザ・ループのレビューは、本当にリスクの高い判断のためにとっておくことです。エージェントが担う仕事が増えるにつれ、1件ずつ人が確認するやり方では追いつかなくなるとみられます。
レート制限より予算が効く
レストランの席を予約しようとしたあるAIエージェントは、1時間に200回APIを呼び出し、その結果、利用者のResyアカウントが停止されました。通常のソフトウェアなら、立て続けの200回のリクエストは明らかなバグであり、開発者がコードで修正します。しかしエージェントは目標を追い求め、何かに制約されない限り、成功するまで再試行を続けます。エージェントから見れば、その粘り強さは乱用ではなく、成功への最善の道なのです。
AAuthの答えは予算です。エージェントは、サービスに提示する認証情報であるアクセストークンを受け取りますが、このトークンは一定の時間が過ぎるか、決められた利用枠を使い切ると失効します。予算が尽きると制御は監督役に戻り、追加を認めるかどうかを監督役が決めます。標準的なHTTPのレート制限は、理由も調整の仕方も伝えずにエージェントを遮断するだけです。残りの予算をモデルのコンテキストに戻して伝えれば、エージェントは資源が限られていることを学び、人間と同じように呼び出しのペースを調整できます。
▲ 残り予算に合わせた呼び出しの調整
頭脳と手を切り離す
関連する設計パターンに、エージェントを頭脳と手に分ける方法があります。頭脳はLLMとその推論です。手はサンドボックスに閉じ込められたツールで、インターネットに直接アクセスできず、常時有効なAPI認証情報も持ちません。外に出ていくリクエストはすべて、サンドボックスの外にあるゲートウェイであるイグレスプロキシを通り、そこでAAuthなどのプロトコルがきめ細かなポリシーを適用します。知られている事例では、エージェントがディスクに保存された生の鍵を見つけ、承認されていない操作に使おうとしました。AnthropicやOpenAIをはじめとする主要な研究所も、決定論的な外部のガードレールとモデルの確率的な推論を組み合わせるこの2層構造に収束しつつあります。
この分離はコンテキストの肥大化も和らげます。MCPでよく見られる問題で、多すぎるツールの説明がコンテキストウィンドウを圧迫するというものです。いまのサブタスクに必要なツールだけをモデルに見せれば、モデルが文章を処理する単位であるトークンを節約でき、ハルシネーションも減らせます。さらに、単独では無害な2つのツールが組み合わさると危険になる「有害な組み合わせ」も防げます。たとえばエージェントがメールの下書きを作っている間はWeb検索と外部への送信手段を止めておき、下書きのレビューが終わってから送信ツールを戻します。
JPMorgan Chaseのセキュリティアーキテクトによると、権限を減らせば攻撃対象領域が小さくなり、エラーが減り、作業も速くなります。
▲ 出口が1つだけのエージェント用サンドボックス
監査証跡をエージェントの手の届かない場所に
監査ログと制御ポイントは、エージェントが回避したり改ざんしたりできないよう、エージェントの実行環境の外に置かなければなりません。あるAIプラットフォームでは、内部プロキシの設定の不備と監視の抜けによって、外向きの接続が誰にも監視されないまま開いていました。一元化したログには、どの人または組織が、どんな目的でエージェントの各行動を認可したのかを記録すべきです。
AIエージェントの認可に取り組む企業のCEOは、エージェントの運用は突き詰めればプロンプトエンジニアリングではなく法的責任の問題だと主張します。同氏の見方では、配備したエージェントが損害を出したときに誰が責任を負うかは既存の不法行為法と商取引法がすでに定めており、エージェントに特化した大がかりな新ルールは必要ありません。そうなると、改ざんできないログが、誰が行動を認可し、委任し、実行したのかを示す証拠になります。1979年のIBMのマニュアルは、その根本にある考えをすでに示していました。コンピューターは責任を問われることがないので、決して経営判断を下させてはならないというものです。意図が変わらずにシステム全体を伝わっていけば、調査担当者は障害の原因が人為的なミスか、エージェントか、ソフトウェアの欠陥かをすばやく見分け、影響範囲を封じ込められます。決済ネットワークには誤った金額の送金を正すルールがすでにありますが、AIエージェントにはまだ同等の標準がありません。
Webは役に立つエージェントとボットを見分けられない
Webは人のために作られました。ログインしていない訪問者がeBayで靴下1足に$50で入札するとき、販売者はログインを強制しない限り、それが買い物客の個人エージェントなのか悪意のあるボットなのかを簡単には見分けられません。人と機械を見分けるためのパズルであるCAPTCHAは、もはや最新のLLMエージェントを止められず、IPアドレスによる遮断は巻き添えの被害を生みます。2〜3年前、スペインでは、違法なサッカー中継サイトが正規のサイトとクラウドのIPアドレスを共有していたため、Vercelが全国で遮断されました。信頼できるエージェントを確実に見分ける方法がなければ、無害なエージェントの通信も同じ運命をたどりかねません。
エージェントによる商取引に向けて、JPMorgan Chaseのセキュリティアーキテクトは、Know Your Customer（KYC）のルールをKnow Your Agent（KYA）へ広げることを提案しています。販売者と銀行は、利用者、エージェント、それを運営する企業、取引を処理する当事者を確認し、それらを1本の検証可能なつながりとして結びつけます。買い物客は自分が設定した上限の範囲内でしかエージェントが購入しないと確信でき、販売者は注文ごとの目的を知ることができます。
OAuthの共同開発者は、異なる提供元のコンポーネントを組み合わせて使えるよう、特定のベンダーに依存しないオープン標準を求めています。かつてOpenID ConnectやTransport Layer Security（TLS）といったオープン標準がWeb上の商取引を広げたように、エージェントのWebはいま、連合型のプロトコルか、少数の大企業が運営する囲い込み型の環境かという選択を迫られています。
エージェントに鍵を渡す前にすること
高性能なモデルと信頼できるエージェントの間にある溝は認可の問題であり、いま使える設計上の工夫で狭めることができます。エージェントの導入を準備しているチームは、まず次のことから始めましょう。
- 新しく入った人と同じようにアクセスは段階的に与え、エージェントの信頼性が確かめられるにつれて広げます。
- タスクごとにミッションを定め、そのIDをすべてのツール呼び出しとログに付けます。
- 禁止すべき行動は決定論的なルールで遮断し、人による承認はリスクの高い手順だけに残します。
- 監督エージェントは作業エージェントから切り離し、作業エージェントのベンダーからも独立させます。
- 一律のレート制限を期限付きの予算に置き換え、残りの予算をエージェントに伝えます。
- ツールは常時有効な認証情報のないサンドボックスで動かし、外向きの通信はイグレスプロキシを経由させます。
- いまの手順に必要なツールだけを公開し、危険な組み合わせは止めます。
- 監査ログと制御ポイントは、エージェントが触れられるものの外に置きます。