社内でAIエージェントにMCP（Model Context Protocol、AIモデルと外部ツール・データソースを接続する標準規格）サーバーを接続し始めた企業のIT基盤・セキュリティ担当が、2026年7月28日にリリースされた仕様2026-07-28で押さえておくべき変更がある[1]。今回の改訂は、プロトコルコアのステートレス化、認可（アクセス権限の付与）まわりをOAuth 2.0・OpenID Connect（OIDC）の実運用に整合させる複数の変更、拡張フレームワークの正式化、そして最低12か月の廃止告知期間を定めたガバナンス方針で構成されている。
MCPは登場以降、AIエージェントがSlackやデータベース、社内システムに接続する際の事実上の標準として急速に採用が広がった。Tier 1 SDKの月間ダウンロードは合計で5億に迫り、TypeScript・Python SDKはいずれも累計10億ダウンロードを超えたと公式は述べている[1]。一方で企業導入に必要な監査証跡・SSO統合・ゲートウェイ制御といった要素の不足が課題として指摘されてきた。
本記事では今回の仕様の主要な変更点を整理し、企業がMCP導入時にどのような認可設計・運用ルールを組み込むべきかを検討する。
予備知識
- MCP（Model Context Protocol）: AIモデルが外部のツールやデータソースに接続するための標準プロトコル。
- OAuth 2.1 / OIDC: アクセストークンを用いた認可の標準規格と、それを拡張して本人確認機能を加えた規格。
- DCR（Dynamic Client Registration）: クライアントが認可サーバーへ動的に自身を登録する仕組み。
- CIMD（Client ID Metadata Documents）: クライアント識別子をURLとして扱い、その先のメタデータ文書で自身を記述する方式。今回DCRの後継として位置づけられた。
- ステートレス運用: サーバー側がリクエスト間の状態（セッション情報）を保持しない構成。ロードバランサ配下での水平スケールがしやすくなる。
MCPの認可仕様が準拠するOAuth 2.1の設計思想を基礎から理解しておきたい情報システム・セキュリティ担当向けの定番書。
ステートレス化——ロードバランサ配下での運用が前提に
今回の目玉は、プロトコルコアのステートレス化だ。接続確立時のinitialize/initializedのやり取りと、セッションを識別するMcp-Session-Idヘッダーが正式に廃止された（SEP-2575、SEP-2567）[1]。各リクエストがプロトコルバージョン・クライアント識別情報・ケイパビリティを_metaに自ら載せて単独で完結するため、共有ストレージなしに、素のラウンドロビン構成のロードバランサ配下でどのインスタンスにリクエストが着いても処理できる[1]。
事前にサーバーのケイパビリティを知りたいクライアント向けにはserver/discoverというRPCが新設されたが、これは必須ではない[1]。
なお、プロトコルからセッションが消えたことはアプリケーションがステートレスでなければならないという意味ではない。公式は、状態を持ち越したい場合はツール側から明示的なハンドルを発行し、モデルにそれを引数として渡し戻させる方式を推奨している。トランスポートに隠れたセッション状態より、モデルから見える形のほうがうまく機能したという説明だ[1]。
MCPサーバーを含むAIエージェント基盤を実際に社内導入する際の実務的な勘所を押さえたい担当者向け。
認可面の強化——OAuth整合の6件の変更と、DCRの非推奨化
認可はMCPの実装者が統合作業でもっとも時間を費やしてきた領域だと公式は述べている[1]。今回、認可仕様を実運用のOAuth 2.0／OIDCに寄せる6件のSEPが入った[2]。
中核はRFC 9207準拠のiss（issuer、トークン発行者）検証の必須化だ（SEP-2468）。認可サーバーはissパラメータを返し、クライアントは認可コードを引き換える前にこれを検証しなければならない。これは認可サーバー混同（authorization-server mix-up）攻撃の穴を塞ぐ変更である[1]。あわせて、クライアント資格情報はそれを発行した issuer に紐付けられ、別の認可サーバーへの使い回しができなくなった（SEP-2352）[1]。
ここが企業の設計判断に直結する。DCR時にapplication_typeを宣言する変更（SEP-837）は、デスクトップ・CLIクライアントのlocalhostリダイレクトが認可サーバーに拒否される問題への対処として入った。ただし公式は同時に、「DCR自体がCIMDを優先して正式に非推奨となった。DCRは後方互換のため動作し続けるが、将来のバージョンで削除される」と明記している[1]。つまりDCRまわりの改善は移行期の緩和策であって、新規に設計するなら向かうべき先はCIMDである。今からMCPの認可基盤を組む企業が、DCR前提で作り込むのは避けたい。
企業向けにはもう一点重要な動きがある。今回、拡張フレームワークが正式に固められ、Enterprise Managed Authorization（EMA） がMCP AppsやTasksと並ぶ公式拡張として位置づけられた[1]。企業の管理下で認可を統制する枠組みが、仕様本体ではなく拡張として整理された形になる。認可設計を検討する際は、コア仕様だけでなくこの拡張の動向を追う必要がある。
Kubernetes上でAIエージェントとMCPサーバーを動かす企業が増えている。MCPはModel Context Protocolの略で、AIエージェントが外部のツールやデータソースへ接続するための標準プロトコルである。エージェントが[…]
ライフサイクルガバナンス方針——最低12か月の廃止告知
今回のリリースでは、機能の非推奨化から削除までに最低12か月の期間を置く正式な廃止ポリシーが定められた[1]。破壊的変更を含むリリースであることを踏まえ、将来の改訂がコア機能を壊さずに進化できるようガバナンス面のSEPが3件入っている[2]。
このポリシーの下で、今回すでに非推奨化されたものがある。Roots・Sampling・Logging（SEP-2577）と、レガシーのHTTP+SSEトランスポートだ。いずれも当面は動作し、少なくとも12か月は使えるが、新規実装で採用すべきではないと公式は述べている[1]。既存のMCPサーバーがこれらに依存していないかは、棚卸しの対象になる。
| 変更カテゴリ | 主な内容 | 企業への影響 |
|---|---|---|
| 通信のステートレス化 | initializeハンドシェイク・Mcp-Session-Idの廃止 | 共有ストレージ不要で水平スケールが容易に |
| 認可整合強化（6件） | iss検証必須化、資格情報のissuer紐付け等 | 既存ID基盤との統合パターンを流用しやすく |
| DCRの非推奨化 | CIMDへ移行。DCRは後方互換で存続、将来削除 | 新規設計はCIMD前提にする必要がある |
| 拡張の正式化 | Tasks・MCP Apps・EMAを公式拡張として整理 | 企業向け認可統制はEMA側の動向を追う |
| 機能の非推奨化 | Roots・Sampling・Logging、HTTP+SSEトランスポート | 依存している実装は12か月以内に移行 |
| ライフサイクルポリシー | 非推奨から削除まで最低12か月 | 機能利用の予見可能性が向上 |
複数の部門やチームでTerraform運用基盤を共有し、AIエージェントによるインフラ操作の実証を始めた数百〜数千人規模の企業では、インフラ担当とセキュリティ担当がこの脆弱性に直接向き合うことになる。個々の端末ではなく組織の共有ホスト単位[…]
企業導入時に検討すべき認可設計
MCPサーバーを社内のAIエージェント基盤に接続する企業は、今回の仕様変更を踏まえていくつかの設計判断を迫られる。第一に、MCPサーバーへの認可を既存のOAuth 2.1/OIDC基盤（Entra ID、Okta等）に統合するか、MCP専用の認可サーバーを別途構築するかという判断。前者は既存の運用体制を流用できる一方、後者は柔軟な権限設計がしやすいというトレードオフがある。
第二に、MCPゲートウェイ（複数のMCPサーバーへのアクセスを一元的に制御する中継層）を導入するかどうか。ここで今回の変更が効いてくる。Streamable HTTPリクエストにはMcp-MethodとMcp-Nameヘッダーの付与が必須になった（SEP-2243）。ゲートウェイ・レートリミッタ・WAFは、JSONボディをパースせずにこれらのヘッダーだけでルーティングと認可・計測ができる[1]。中継層で統制をかける設計のコストが、この変更で明確に下がった。
社内で複数のMCPサーバーを並行運用する企業ほど、認可・監査ログ・レート制御をゲートウェイに集約するメリットが大きい。
Entra ID（旧Azure AD）とオンプレのAD FS（オンプレADのフェデレーション認証基盤）を併用し、子会社・関連会社を含む複数ドメインでフェデレーション認証を組んでいる数千人規模の企業の情シスが、今まさに確認を急ぐべき変更があ[…]
日本企業のMCP導入、認可設計の見落としやすい点
日本企業のAIエージェント導入は、まず特定部門での実証実験（PoC）から始まり、その後全社展開に進む流れが一般的だ。PoC段階では、MCPサーバーへの接続を個別のAPIキーや簡易な認証で済ませてしまうことが多く、全社展開の段階になって初めて、OAuth 2.1/OIDCベースの正式な認可設計への作り直しが必要になるケースが少なくない。
内部統制・監査の観点では、AIエージェントがどのMCPサーバー経由でどの社内データにアクセスしたかという監査証跡が、生成AI利用ガイドラインの整備が先行する企業ほど後回しにされがちだ。利用ガイドラインは「何を使ってよいか」を定めるが、「誰が・いつ・何にアクセスしたか」を記録する仕組みの整備は、MCPゲートウェイのような技術的な裏付けがなければ実現しない。
今回のタイミングで特に注意したいのは、PoCで作り込んだ認可まわりがすでに非推奨側に乗っている可能性だ。DCRで動的登録する実装も、レガシーHTTP+SSEトランスポートを前提にした実装も、動きはするが向かう先ではない。作り直しの範囲を見積もる際は、単に「APIキーからOAuthへ」ではなく、どの方式に向かうかまで決めておく必要がある。
| 観点 | PoC段階 | 全社展開段階で必要になること |
|---|---|---|
| 認可方式 | 簡易なAPIキー等で代替されがち | OAuth 2.1/OIDCベースの正式な認可設計 |
| クライアント登録 | DCRで動的登録しがち | CIMDへの移行を前提に設計 |
| 監査証跡 | 記録されないことが多い | MCPゲートウェイ等による一元的なログ収集 |
| 既存ID基盤との統合 | 個別対応で済ませがち | Entra ID等の全社ID基盤への統合が前提に |
情シス担当の次の一手は、PoC段階で使っている簡易な認可方式と、DCR・HTTP+SSEといった非推奨側の依存を棚卸しし、全社展開前にOAuth 2.1/OIDC＋CIMDベースの設計へ移行する計画を立てること。決裁側の判断材料は、MCPゲートウェイの導入予算と、それによって得られる監査証跡・統制の強化を、内部統制対応のコストとして評価することになる。
まとめ
MCP仕様2026-07-28は、ステートレス化・認可整合強化・拡張フレームワークの正式化・12か月の廃止ポリシーという形で、企業導入の障壁になっていた要素に応えている。認可設計で見落としやすいのは、DCRが正式に非推奨となりCIMDが標準になったこと、そして企業向けの認可統制がEMAという拡張側に整理されたことだ。情シス担当はPoC段階の認可方式と非推奨機能への依存を棚卸しし、決裁側はMCPゲートウェイ導入による統制強化を予算判断に組み込む必要がある。
よくある質問（FAQ）
Q. 既存のMCPサーバー実装は今回の仕様変更で動かなくなりますか？
A. 今回は破壊的変更を含むリリースで、initializeハンドシェイクやMcp-Session-Idに強く依存した実装は影響を受ける[1]。一方、非推奨化された機能（DCR、Roots・Sampling・Logging、HTTP+SSEトランスポート）は最低12か月は動作するため、計画的な移行が可能になっている。
Q. MCPゲートウェイは自社で構築する必要がありますか？
A. OSS・商用の両方でMCPゲートウェイ製品が提供され始めており、自社構築以外の選択肢も増えている。今回Mcp-Method・Mcp-Nameヘッダーが必須化されたことで、既存のAPIゲートウェイやWAFでもヘッダーベースの制御がしやすくなった[1]。
Q. MCPを使わずに独自のAPI連携でAIエージェントを構築する場合も関係ありますか？
A. 直接は関係しないが、今回の仕様が示す「認可の標準化」「監査証跡の確保」という設計思想は、独自実装でも参考になる考え方である。
