Kubernetes上でAIエージェントとMCPサーバーを動かす企業が増えている。MCPはModel Context Protocolの略で、AIエージェントが外部のツールやデータソースへ接続するための標準プロトコルである。エージェントが複数のMCPサーバーを呼び出す構成が一般化する一方、どのエージェントがどのユーザーの代理として、どのツールを呼び出せるかを制御する認可設計はまだ確立していない。プラットフォームエンジニアやAI基盤運用チームは、この空白領域への対応を独自の判断で迫られている。
2026年7月、KubeCon + CloudNativeCon Japanの併設イベントKeycloakCon Japanで、この課題に対する具体的な実装パターンが2件発表された[1]。1つはHitachiの大渕豊氏によるKeycloakのToken Exchange拡張、もう1つはTUBITAKのMustafa Dayıoğlu氏によるSPIRE JWT-SVIDとDPoPを組み合わせた鍵レス方式である。両者は前提とする既存基盤も、解決するリスクの重心も異なる。本記事では技術的な仕組みを整理し、K8s運用チームがどちらを検討すべきかの判断軸を示す。
予備知識
- MCP（Model Context Protocol）: AIエージェントが外部ツールやデータソースへ接続するための標準プロトコル。2024年11月に公開され、2025年3月の仕様改定でOAuth 2.1をリモートサーバーアクセスの必須要件に追加した[3]。
- ワークロードアイデンティティ: 人間ではなくサービスやPodそのものに割り当てる識別情報。証明書やトークンの形で払い出す。
- Token Exchange: あるトークンを別の権限範囲・別の対象者向けのトークンへ交換するOAuthの拡張仕様。委任やなりすまし防止の基盤になる。
- SPIFFE/SPIRE: ワークロードに
spiffe://形式のIDを割り当てる仕様（SPIFFE）と、その実装（SPIRE）。X.509-SVIDとJWT-SVIDの2形式でIDを発行する。 - DPoP（Demonstrating Proof-of-Possession）: トークンを盗まれても第三者が使い回せないよう、リクエストごとに秘密鍵で署名を付与するOAuth拡張仕様[5]。
ワークロードIDの前提となるコンテナ基盤のリスクを体系的に把握したい人に。
MCPサーバー認可はなぜ難しいのか
MCPサーバー認可とは、AIエージェントが呼び出す外部ツールへのアクセスを、誰の代理としてどこまで許可するかを制御する仕組みを指す。
MCPは2024年11月の公開当初、認可の仕様を定めていなかった。各MCPサーバーが独自にAPIキーやBasic認証を実装し、エージェント基盤側が個別に対応する状況が生まれた。2025年3月の仕様改定でOAuth 2.1がリモートMCPサーバーアクセスの必須要件になったが[3]、これは誰がどのトークンで呼び出すかという土台を用意したに過ぎない。
どのAIエージェントが、どのユーザーを代理して、どのツールを、どの権限範囲で呼び出せるかという認可ロジックそのものは、依然としてMCPサーバーごとにばらばらに実装されている。企業が社内外のMCPサーバーを組み合わせるほど、認可ポリシーの矛盾やトークンへの過剰な権限付与が起きやすい。KubeCon Japan 2026のセッション群は、このギャップに対する既存アイデンティティ基盤からの2つの回答だった[1]。
鍵レス方式が前提とするゼロトラストの全体設計を俯瞰したい人に。
Keycloak Token Exchange拡張とID-JAGによる委任設計
ID-JAG（Identity Assertion JWT Authorization Grant）とは、あるサービスが発行したIDトークンを、別のサービスが検証可能な短命の認可グラントに変換する仕組みを指す。
大渕豊氏（Hitachi）は、KeycloakのToken Exchange Providerを拡張してID-JAGを実装するセッションを発表した[1][2]。標準のToken Exchangeはクライアント同士でトークンを交換する仕組みを提供するが、そのリクエストが特定ユーザーの代理として本当に許可されているかまで検証する仕組みは別途必要になる[2]。ID-JAG拡張はこの検証をKeycloak側に一元化し、MCPサーバー一つひとつに認可判定ロジックを実装させない設計を狙う[1]。
エージェントがユーザーの代理としてMCPサーバーを呼び出す際、まずKeycloakからユーザーのIDトークンを受け取る。次にToken Exchangeを使い、呼び出し先のMCPサーバー向けに範囲を絞った短命トークンへ交換する。MCPサーバーはこのトークンをKeycloakの公開鍵で検証するだけでよく、認可判定そのものはKeycloakに委ねられる[1][2]。既にKeycloakを社内IDPとして運用している組織にとって、この方式は既存の認可基盤の自然な延長線上にある。
Kubernetes（K8s、コンテナオーケストレーション基盤）上でAI・ML基盤を組んでいるプラットフォームエンジニアに向けた話をする。舞台はストレージ層、それも学習（モデルを訓練する処理）と推論（学習済みモデルで予測を返す処理）それぞ[…]
SPIRE JWT-SVID + DPoPによる鍵レスワークロードID
鍵レスMCPワークロードIDとは、静的な秘密鍵やAPIキーのファイルを一切配置せずに、Kubernetes上のワークロードへ実行時に一意なIDを発行する設計を指す。
Mustafa Dayıoğlu氏（TUBITAK）は「Zero-Trust, Keyless AI Agents on Kubernetes」と題したセッションで、SPIREを使ってPodごとにJWT-SVIDを発行し、Keycloakのクライアントを人手で作らずに済むパターンを示した[1]。SPIREはPodの起動属性（サービスアカウントやネームスペースなど）を基にワークロードを検証し、spiffe://形式のIDを実行時に払い出す。静的な設定ファイルやKeycloakクライアントの手動登録が不要になる点が鍵レスと呼ばれる理由である[1]。
ただしJWT-SVIDはベアラートークンであり、盗まれれば第三者がそのまま使い回せる[4]。この方式はDPoPを組み合わせてこの弱点を補う。ワークロードはリクエストごとに自身の秘密鍵でHTTPメソッドとURIへの署名（DPoPプルーフ）を生成し、受け手はJWT-SVIDに紐づく公開鍵で検証する[5]。トークンを中間者が横取りしても、対応する秘密鍵がなければリクエストを再利用できない[5]。KubernetesとVM、マルチクラウドにまたがる環境で、証明書ベースの検証に頼らずリプレイ耐性を確保できる点が特徴である。
GPU1枚を複数のPodで共有する仕組みが、Kubernetesの標準機能として実装されようとしている。KEP-4815（Kubernetes Enhancement Proposal 4815）は、DRA（Dynamic Reso[…]
二つのアプローチをどう比較し、どちらを選ぶか
実装難易度と既存基盤との親和性を軸に整理すると、どちらの方式を優先すべきかの判断がしやすくなる。
| 観点 | Keycloak Token Exchange（ID-JAG）方式 | SPIRE鍵レス方式 |
|---|---|---|
| 前提となる基盤 | Keycloakを社内IDPとして運用済み | Kubernetes上でSPIRE運用済みか新規導入 |
| 実装難易度 | Keycloak拡張の適用が中心、比較的低い | SPIRE導入とDPoP対応クライアント実装が必要、比較的高い |
| 既存基盤との親和性 | 人間ユーザーの認可フローと統合しやすい | Pod・サービス単位の非人間アイデンティティ管理と親和性が高い |
| トークンリプレイ耐性 | 短命トークンとKeycloak側検証に依存 | DPoP署名検証によりリクエスト単位で耐性を持つ |
| 運用の重心 | ユーザー代理（委任）のガバナンス | ワークロードそのもののゼロトラスト化 |
すでにKeycloakを認可基盤として運用し、AIエージェントが特定ユーザーの代理として動く場面が中心なら、Token Exchange拡張の方が導入コストは低い[1][2]。一方、Kubernetes上で多数のワークロードが人間を介さずに常時MCPサーバーを呼び合う構成では、SPIREの鍵レス方式がAPIキー管理の負債を根本から減らせる[1]。両者は排他的ではなく、Keycloakをユーザー認可の窓口に、SPIREをワークロード間のリプレイ対策に組み合わせる設計も選択肢になる。
※本記事は2026年7月時点の情報です。料金・提供条件は変動が速いため、最新は各公式でご確認ください。一部アフィリエイトリンクを含みます。 ✅ 先に結論（Seedance 2.0の要点） 何がすごい[…]
よくある質問（FAQ）
Q1. MCPサーバーの認可とAPIキー認証はどう違うか。
A. APIキー認証は誰が呼び出しているかを示すだけで、ユーザー代理やスコープの制御を含まない。MCPサーバー認可は、どのエージェントがどのユーザーの代理として、どの権限範囲でツールを呼び出せるかまで制御する。
Q2. Token Exchange方式とSPIRE鍵レス方式は併用できるか。
A. 排他的ではない。Keycloakをユーザー代理の認可窓口に、SPIREをワークロード間のリプレイ対策に使う組み合わせは技術的に可能である[1]。
Q3. DPoPを導入すればJWT-SVIDの秘密鍵管理は不要になるか。
A. 不要にはならない。DPoPは各ワークロードが秘密鍵を保持し署名する前提の仕組みであり、鍵の発行と更新をSPIRE Agentが自動化する部分が「鍵レス」と呼ばれている[4][5]。
まとめ
KubeCon Japan 2026で示された2つのセッションは、MCPサーバー認可という未成熟な領域に対する現実的な回答だった[1]。Keycloak Token Exchange拡張はユーザー代理の委任統制を、SPIRE鍵レス方式はワークロードそのもののゼロトラスト化を狙う。どちらもMCPサーバーごとに認可ロジックを書かせないという発想は共通している。
読者がまず確認すべきは、自社の認可基盤の現状である。Keycloak等のIDPを既に運用しているなら拡張の適用を検討し、Kubernetes上でエージェント間呼び出しが増えているなら鍵レス方式の検証を優先する。両方式とも発表されたばかりで実運用事例はまだ少なく、まずは検証環境での試行から始めるのが妥当である。
出典
- KeycloakCon Japan 2026: Navigating cloud native identity and the AI frontier | CNCF
- Model Context Protocol(MCP) Authorization for Enterprise Use Case With Keycloak – Yutaka Obuchi
- Authorization – Model Context Protocol
- Extend JWT-SVID spec and Workload API profile to support OAuth DPoP · Issue #260 · spiffe/spiffe
- Demonstrating Proof-of-Possession (DPoP) – Auth0 Docs
