同じエージェントでも、利用者が違えば読める文書は違う

社内文書を探して要約するエージェントを考える。 営業担当者が顧客の契約書を検索する場合と、別部署の担当者が同じ質問をする場合では、返してよい文書が異なりうる。 これは本稿の想定例である。 エージェントが同じでも、利用者の閲覧範囲まで同じにしてよい理由にはならない。

さらに、検索した資料を外部へ送る仕事を追加すると、閲覧と送信の二つの許可が必要になる。 利用者がアプリへログインできたこと、エージェントを識別できたこと、対象の資料を送ってよいことは、それぞれ違う判断である。 入口だけで認証しても、その先が全社員の文書を読める共有接続なら、個人の閲覧範囲を守れるとは限らない。

筆者の見方では、エージェントIDの意義は、ソフトウェアに名前を付けるだけでは終わらない。 誰の依頼をどの権限で実行し、その委任をどこで取り消せるかを管理の対象にできることにある。 本稿では、専用ID、利用者の委任、接続先の認可を分け、担当者や権限が変わった後まで考える。

専用IDを、権限を付ける、止める、調べる単位にする

MicrosoftはBuild 2025の発表で、Copilot StudioやAzure AI Foundryで作るエージェントに固有のIDを割り当てるEntra Agent IDのプレビューを紹介した。 Ignite 2025のEntra関連発表では、Agent 365を通じたプレビューとして、エージェントの一覧管理、ライフサイクル管理、リソースへのアクセス保護を説明している。 識別から、そのIDを持つソフトウェアを管理する仕事へ広げた製品例と読める。

ただし、登録されたIDに何を許すかは別に決める必要がある。 想定の文書検索なら、検索処理だけを止めたいのか、同じエージェントによる送信も止めたいのかで、停止する対象が変わる。 ID、接続、許可する操作が対応していなければ、管理画面に名前があっても必要な範囲を切り離せない。

従来のサービスアカウントも、処理ごとに分けて権限を絞り、活動を追えるなら役に立つ。 専用のエージェントIDが必ず優れるとは言えない。 複数の仕事で一つの強い認証情報を共有すると、一つを止めるために他の仕事まで止まる、あるいは停止対象を見分けられないという問題が生じる。 比較するのは名称より、付与と停止と調査に使える単位である。

その単位には、人の責任も結び付けたい。 誰が目的を決め、誰が接続を設定し、誰が継続利用を見直すかを明らかにすれば、使われなくなった権限を残す理由を判断できる。 これは本稿の運用上の提案であり、登録しただけで不要な権限がすべて見つかるという製品の保証ではない。

定期処理の権限と、利用者から借りる権限を分ける

毎晩、決まった集計表を所定の場所へ保存する処理と、質問した利用者が読める契約書を探す処理では、権限の基準が違う。 前者には、組織が目的と保存先を定めた処理専用の権限を与える設計が考えられる。 後者では、誰が検索を依頼したかに応じた閲覧条件を保つ必要がある。 これは設計の比較であり、すべての製品が同じ方法で実装するという意味ではない。

AWSの2025年7月のAgentCore発表は、Identityがエージェントの固有の識別情報を作り、利用者やエージェントの文脈に応じたアクセスを扱うと説明する。 利用者に代わって外部サービスへアクセスする場合と、事前の同意に基づく場合が示され、利用者のトークンを保管する仕組みも紹介された。 発表の構成例を、あらゆる外部サービスで同じ許可が働く実証にはしない。

トークンは、アクセス先へ提示する認証情報である。 委任のために長期間使える外部サービスの認証情報を、モデルの会話へ渡す必要はない。 Auth0のToken Vaultの解説は、外部サービスのトークンを集中管理し、アプリがそのサービスの更新用トークンを直接扱わず、必要なアクセス用トークンを取得する構成を示している。 認証情報の保管と更新を、依頼を解釈するモデルから分ける具体例である。

この仕組みがあっても、取得した権限の範囲が広すぎれば問題は残る。 利用者が読める文書すべてを毎回必要とするわけではなく、読める文書を誰にでも送ってよいわけでもない。 依頼した人を確かめた上で、今回必要な対象と操作を絞ることが、委任を業務の目的に合わせる判断になる。

MCPへの許可と、その先のAPIへの許可は別の接続に属する

MCPの2025-11-25版の認可仕様は、HTTP接続で認可を扱う手順を定める。 サーバーは、提示されたトークンが自分向けに発行されたかを検証する必要がある。 別のAPIへアクセスするときは、そのAPI向けに発行された別のトークンを使い、クライアントから受け取ったトークンをそのまま転送してはならない。

文書検索なら、エージェントから検索用MCPサーバーへ入る接続と、そのサーバーから文書保管サービスへ入る接続を分けて見る。 前者で利用者を確認しても、後者が全社の文書を取得するなら、利用者の閲覧条件をどこで適用するかが残る。 保管サービスの権限判定を使うのか、検索処理が対象を制限するのかを説明できる設計が必要になる。

同仕様は、無効または期限切れのトークンには401、権限の不足には403を返すと定めている。 これらを検索結果のゼロ件へ置き換えると、利用者は「文書がない」のか「読めない」のかを見分けにくい。 許可を追加する必要がある場面と、資料を探し直す場面が混ざってしまう。 ただし、読めない資料の題名や本文まで説明してよいかは、別に制御する必要がある。

MCP全体で認可の実装は任意であり、このOAuthの手順は標準入出力によるローカル接続へ一律に要求されるものではない。 「MCP対応」だけでは認証方法も権限の範囲も分からない。 実際の接続方式と、そこで適用する許可を確かめたい。

一つの操作について、四つの問いをつなげる

ここまでの区別を、検索から外部送信への想定経路に沿って整理する。 次の四つは本稿の確認の視点であり、すべてを一つのトークンに入れる方式を求めるものではない。

誰が実行したか

どのエージェントと接続が使われたかを特定する。利用者が同じでも、別のエージェントの操作まで同じ記録として扱わない。停止と調査の単位にする。

誰のために動いたか

確認された利用者の委任か、組織が定めた定期処理かを区別する。依頼文に「管理者として」と書かれたことを、その人の権限の証明にしない。

何を対象に、何を許したか

対象の文書と、検索、取得、送信などの操作を結び付ける。正しい相手向けのトークンがあっても、今回の文書や宛先に対する許可は別に確かめる。

あとから何を説明できるか

依頼、利用者、エージェント、対象、許可または拒否の理由を追える記録にする。トークンそのものを記録する必要はない。記録の閲覧範囲と保管期間も定める。

この対応があれば、利用者の委任を取り消したのか、特定の接続だけを無効にしたのかを区別できる。 権限を増やすことだけが管理の成果ではない。 必要な仕事を残し、使わせたくない対象や操作を切り離せることも、管理できる範囲を示す。

切断した後も、発行済みの認証情報と取得済みの資料を確かめる

担当者が異動した、利用者が委任を取り消した、定期処理の目的がなくなった。 そうした変更では、どのアクセスを終えるかを決め直す必要がある。 利用者の権限を借りた検索と、組織が継続を決めた集計処理では、同じ人の異動でも扱いが違いうる。 後者を続けるなら、目的と次の管理担当を確認する。

管理画面で接続を外したことだけでは、発行済みのすべての認証情報が即座に使えなくなったとは判断できない。 OAuthの取消を定めるRFC 7009も、取消の情報が伝わる際の遅延や、アクセス用トークンの方式による違いを説明している。 更新用トークンを取り消しても、アクセス用トークンが直ちに無効にならない構成があることにも注意を向けている。

本稿が提案する確認では、新たな認証情報を取得できなくなったかと、すでに取得したものによるアクセスが拒否されるかを分ける。 停止を求めてからアクセスが拒否されるまでの時間や、どの接続に停止が反映されたかも見る。 これは各製品で取消の遅延を測った結果ではなく、実装によって確かめるべき条件である。

認証情報が無効になっても、以前に取得した文書や要約が自動で消えるとは限らない。 別の利用者の検索に、前の利用者のために保存した結果を流用しないこと、取得済み資料の保管や削除をどう扱うかも決める必要がある。 アクセスを止める処理と、すでに持つ情報を扱う処理は、それぞれ確認したい。

権限の判定と、内容を検査する仕組みは役割が違う

ここまでの権限設計を、生成内容の検査で置き換えることはできない。 要約に問題のある表現がないかと、その文書を読んでよいかでは、検査する対象が異なる。 正当な権限で取得しても、要約の正確さや共有の目的は別に確かめる必要がある。

操作の許可をモデルの返答から分ける製品例として、3月3日に一般提供されたAgentCore Policyは、エージェントのコードの外側で、Gatewayを通るツールへのアクセスや入力条件を評価すると説明する。 識別情報を持つことと、ある呼び出しを許すことを別の仕組みで扱う例になる。 ただし、そのGatewayへ結び付けた範囲の制御を、別の接続経路や取得済み資料の扱いへまで広げて解釈はできない。

企業向け製品を比較するときも、IDの発行、操作の認可、内容の検査、記録の管理を同じ機能として数えない方が判断しやすい。 本稿の文書検索なら、誰の閲覧範囲を適用し、誰が送信先を制限し、失効後のアクセスをどこで拒否するかを並べる。 機能の数より、仕事の経路に必要な判断が配置されているかを見る。

許可した仕事を続けながら、不要になった委任を止める

試行では、閲覧範囲の異なる二人が同じエージェントを使う場合を用意したい。 それぞれの検索結果と保存した要約が混ざらないか、読める文書と読めない文書を正しく分けられるかを見る。 閲覧できる文書を許可していない宛先へ送ろうとする場合も加え、どの処理が拒否したかを確認する。

その後に委任や接続を取り消し、新規取得、発行済み認証情報によるアクセス、保存済み結果の利用を別々に調べる。 同時に、停止対象ではない利用者や定期処理が必要な仕事を続けられるかを確かめる。 これは本稿の試験案であり、特定の製品について試験に合格したと述べるものではない。 運用担当者がその結果から停止の範囲と残件を説明できることまで見たい。

エージェントのID管理が役に立つのは、許可を与える時だけではない。 仕事の目的や担当者が変わっても、誰のどの権限を使い、何を続け、何を終えるかを判断できる時に意味がある。 その条件を満たす構成なら、人は一つの委任を止めるために、必要な仕事すべてを止めずに済む。