【2026年7月版】

MCPプロトコルが分離した責務（後編）— 主体の確認とデータへの権限を分ける

公開日: 2026/07/30
読了時間: 約 10分

前編「セッションに閉じた状態を解く」では、MCP仕様 v2026-07-28 がプロトコル状態を接続から切り離し、業務状態を明示的なハンドルで扱えるようにしたことを見ました。

しかし、Instance Aが処理した次の要求をInstance Bへ送れるようになっただけでは、Bがその要求者に業務データを渡してよいとは判断できません。任意のInstanceへ届く要求について、誰から来たものかを確認し、その主体にデータ操作を許すかを判定する責務が必要です。

MCPはOAuthを認証・認可の基盤として使う

この責務を、以前のようにMCPのセッションへ持ち込むことはできません。要求は任意のInstanceへ届くためです。MCP仕様 v2026-07-28 のAuthorizationは、主体の確認とアクセストークンの発行・検証にOAuthを使います。MCPが独自のログイン方式やトークン形式を決めるのではなく、OAuthの役割をMCPの通信へ当てはめます。

エージェントはOAuth Clientとして、アクセストークンを取得してMCPサーバーへ提示します。
保護されたMCPサーバーはOAuth Resource Serverとして、トークンを受け取り、有効性と対象を検証します。
Authorization Serverは、エージェントにアクセストークンを発行します。

エージェントは、保護されたMCPサーバーに必要な認可情報を確認し、Authorization Serverからアクセストークンを取得します。その後、各MCPリクエストにトークンを添えます。Gatewayがトークンを検証して要求者を確認し、到達したInstanceが、その主体に対象データの操作を許可するかを照合します。ここで、認証と認可は別のレイヤーになります。

認証レイヤーは、要求を出した主体を確認します。提示された資格情報を検証し、確認できない要求をルーターで止めます。
認可レイヤーは、確認された主体が、要求された業務データを操作できるかを判定します。対象のレコード、テナント、操作内容を照合し、許可された要求だけをDBへ到達させます。

HTTPで保護されたMCPサーバーでは、クライアントは各リクエストに次のようなアクセストークンを添えます。

POST /mcp HTTP/1.1
Authorization: Bearer <access-token>
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: customer.search
Content-Type: application/json

Authorization: Bearer <access-token> は、OAuthで取得したアクセストークンをHTTPで提示する形式です。OAuth 2.0 Bearer Token Usage (RFC 6750) ルーターまたはGatewayは、届いたトークンの有効性と、このMCPサーバー向けに発行されたトークンであることを確認します。無効または期限切れなら 401 を返し、通過させません。MCP Authorization仕様

ここで確認するのは認証です。黄色い枠で表したGatewayは「この要求を出した主体を確認できるか」を扱います。通過後は、トークンから得た主体、テナント、scopeなどの認可情報が、実際にデータへ到達するInstanceまで伝わります。

Mcp-Session-Id は以前のMCPで「どの接続の続きか」を示すプロトコル上の手がかりであり、ユーザー、テナント、権限を証明する資格情報ではありません。Mcp-Method や _meta も認証情報ではありません。とくに _meta.io.modelcontextprotocol/clientInfo はクライアントソフトウェアの名前と版を伝える自己申告です。

トークンの検証方式を全Instanceでそろえる

Bearerアクセストークンは、所持者が提示する資格情報です。OAuthはアクセストークンの形式を固定していないため、Gatewayまたは各Instanceは、採用した方式に従ってトークンを検証します。

代表的な検証方式は二つです。

JWT access token：トークンに署名済みの iss、aud、exp、sub、scopeなどを載せる。各InstanceはAuthorization Serverの公開鍵を使って、ネットワーク照会なしに検証できる。
opaque token：クライアントにもInstanceにも意味を見せないランダムな値にする。InstanceまたはGatewayがAuthorization Serverのintrospectionで、有効性・主体・scopeを確認する。

JWTは分散したInstanceで検証しやすく、opaque tokenは失効や権限変更を中央で反映しやすい、という違いがあります。いずれもクライアントが中身を読んで判断するのではなく、Resource Serverが設定された方式で検証します。JWT Access Token Profile (RFC 9068) / OAuth Token Introspection (RFC 7662)

JWTを使う場合は、発行者（iss）、対象リソース（aud）、有効期限（exp）、署名、操作に必要なscopeを検証します。ID TokenをAccess Tokenの代わりに受け入れません。

業務データへ到達する前に、操作権限を照合する

前編で扱った basket_id、task_id、会話IDのようなハンドルは、DBやキャッシュにある業務状態を参照するための鍵です。Instanceはデータを読む・書く直前に、トークンから得た主体・テナント・scopeと、対象レコードの所有者・テナント・操作ポリシーを照合します。

たとえばInstance Aが basket_id: "bsk_42" を返した後、Instance Bに次の要求が来たとします。Bは bsk_42 の所有者・テナント・操作ポリシーを照合し、成功したときだけ状態を読み書きします。必要なscopeが足りない場合や、対象が別テナントのものであれば、ここで 403 を返します。

request:  basket_id = bsk_42
token:    subject = user_123, tenant = acme, scope = basket:write
record:   owner = user_123, tenant = acme
result:   allow

この照合が、図の青・紫の認可情報がDBまで届く部分です。認証Gatewayは要求者の確認を担い、業務サービスは対象データへの操作を許可するかを担います。ハンドルだけでデータを返す実装にすると、ログ、URL、エラーなどから漏れたIDが認可の抜け道になります。

OAuthとMCPのサーバー構成

組織のIdPやOAuth基盤であるAuthorization Serverは、MCPの外部で動きます。エージェントの認証、同意、アクセストークンの発行、失効を担い、エージェントはそこで得たトークンをMCPサーバーへ提示します。ロードバランサーの後ろにA/B/Cを増やしても、エージェントが提示するのは、この共通の認証基盤が発行したトークンです。

各MCP InstanceはOAuth Resource Serverとして、その発行済みトークンを検証します。JWTならAuthorization Serverが公開する鍵を取得して iss、aud、exp、署名、scopeを確認します。opaque tokenなら、Authorization Serverのintrospectionへ問い合わせて有効性・主体・scopeを確認します。これはOAuthサーバーをMCP Instanceへ組み込むのではなく、外部の認証基盤を利用する処理です。

Gatewayでトークンを一次検証してからMCP Instanceへ渡す構成もあります。その後、MCP Instanceまたは業務サービスが、basket_id や task_id と、トークンから得た主体・テナント・scopeを照合し、対象データへの操作を許可します。

Bearer tokenは所持者を認める方式です。したがってHTTPS、トークンをURLへ置かないこと、ログへ生のトークンを出さないこと、短い有効期限と安全な更新も前提になります。MCP仕様もアクセストークンをURIのクエリ文字列へ含めることを禁止しています。

分離するのは、接続ではなく責務

MCP仕様 v2026-07-28 は、状態を消したのではありません。プロトコル状態を各リクエストへ、業務状態を明示的な永続データへ、認証・認可をアクセストークンとサーバー側ポリシーへ分けました。

この境界があるから、ルーターは接続履歴ではなく到着した一要求を任意のInstanceへ渡せます。そしてInstanceは、状態を参照しながらも、その要求者に操作を許すかを独立して判断できます。セッションをなくしたこと自体ではなく、状態と権限を別の責務として扱えるようにしたことが、クラウドでMCPを運用するための変更です。