MCPがAPIキー依存を脱する｜発注前に効く4つの問い

AIと社内システムをつなぐ標準として使われているMCP（Model Context Protocol、AIに社内のツールやデータを接続するための共通仕様）の公式ロードマップが、2026年8月22日に更新されました。優先領域の1つに挙がったのが「エージェント固有のIDと権限委任」です。ロードマップは現状を「貼り付けたAPIキーと長期有効なリフレッシュトークンに依存している」と明記しています。確定した仕様ではありませんが、いま社内で動いているMCP接続の作り方を決め直す材料になります。確定事項と検討段階を切り分けたうえで、発注側がいま決められる判断を整理します。

何が起きたのか：MCP公式ロードマップが「エージェントのID」を優先領域に置いた

Model Context Protocolの公式ロードマップが2026年8月22日に更新され、今後6〜12か月の優先領域5つのうち3番目に「Agent Identity and Enterprise-Ready Security（エージェントIDとエンタープライズ対応のセキュリティ）」が置かれました。同日、Lead Maintainersの David Soria Parra 氏と Den Delimarsky 氏による解説記事も公開されています。

ロードマップが挙げている現状認識は明快です。MCPの認可は「同意の瞬間にブラウザの前に人がいる」ことを前提に設計されている一方、実際の呼び出し元はクラウド上で自分のIDを持って動くエージェントであり、人が不在の状態で動いたり、親より狭い権限を持つべき子エージェントを生成したりします。そのうえで、既存のMCPサーバーは「貼り付けたAPIキーと長期有効なリフレッシュトークン」に頼っている、と記載されています。

このロードマップ期間の成果物として挙がっているのは2つです。

1. DPoP（Demonstrating Proof of Possession）の仕様確定と普及。トークンを送信者に暗号的に結び付ける仕組みで、IETFの標準（RFC 9449）に基づきます。担当はAgent Identity WG（ワーキンググループ）です。
2. エージェントIDと権限委任。Workload Identity Federation（SEP-1933）、Enterprise-Managed Authorizationが使う ID-JAG（Identity Assertion JWT Authorization Grant）、RFC 8693のトークン交換を軸に、IETFのOAuth WG・WIMSE WGと協調して進めるとされています。

加えて検討段階の論点として、対話型のクライアントとヘッドレス（人が画面の前にいない）なエージェントを区別する「human-presence attestation」も挙げられています。

何が変わる方向なのか：業務の言葉に置き換えると4点

技術用語のままでは判断材料になりません。いまの実務と、ロードマップが向かう先、そして業務上の意味を並べると次のようになります。

いまの実務	ロードマップが向かう先	業務・統制上の意味
APIキーを貼り付けて接続する	エージェント自身のIDで接続する（Workload Identity Federation、RFC 8693のトークン交換）	「どのエージェントが何にアクセスしたか」が記録として残り、台帳で管理できる
長期有効なトークンを保持する	送信者に暗号的に紐づくトークン（DPoP）	トークンが漏れても、それ単体では使えなくなる方向
利用者が1サービスずつ承認する	会社のIdPが可否を一元的に判断する（ID-JAG）	入社時の権限付与と退職時の失効が1か所で済む
人が画面で同意する前提	人が不在の実行を区別する議論（human-presence attestation）	無人実行を許すかどうかを、仕組みとして線引きできる

このうち3行目は、拡張仕様として既にドキュメントが公開されています。Enterprise-Managed Authorizationは、企業のIdP（Okta、Azure AD、社内SSOなど）がどのMCPサーバーへのアクセスを許すかを一元的に決める仕組みです。公式ドキュメントは、利用者ごとの個別承認では一貫したアクセスポリシーを強制できないこと、入社時に数十のサービスを手作業で承認する必要があること、退職時にはサービスごとに個別の失効作業が要ることを課題として挙げています。

ただし「決まった」わけではない：効力の限界を先に押さえる

ロードマップは確約ではありません。この前提を外すと、まだ存在しない仕組みを当てにした計画を立てることになります。限界は4点あります。

• ロードマップ自体が確約ではない。ページには「This roadmap reflects current thinking rather than firm commitments（現時点の考えを反映したものであり、確約ではない）」と明記され、優先順位の変更・内容の変更・先送りがあり得るとされています。
• 担当するAgent Identity WGは、このロードマップ期間に発足する段階です。議論の母体そのものが形成中です。
• 拡張はオプトインで、既定では有効になりません。Enterprise-Managed Authorizationの公式ドキュメントも「Extensions are opt-in and never active by default」と記載し、対応状況はMCPクライアントによって異なるとしています。
• ローカル接続（STDIOトランスポート）はそもそも認可仕様の対象外です。現行の仕様（2026-07-28版）は、STDIOトランスポートはこの認可仕様に従うべきではなく、環境から資格情報を取得すると規定しています。手元のPCで動かすMCPサーバーは、当面は環境変数のキー運用が前提になります。

一方で、現行仕様にも今日から効く規定はあります。MCPサーバーは自分宛てに発行されたトークンであることを検証しなければならず（RFC 8707）、それ以外のトークンを受け入れることも中継することも禁じられています。ベンダー選定の確認項目として、今日の時点で使える基準です。

経営・DX担当者がいま決められる4つのこと

仕様の確定を待たずに決められることがあります。いずれも後から標準に乗り換えるときのコストを下げる判断です。

1. MCP接続の資格情報を一覧にする。どのシステムに、誰の名前で発行されたキーが、どこに保管されて使われているかを書き出します。「個人のアカウントで発行したキーを共用している」状態は、エージェントIDの仕組みが整っても自動では解消されません。

2. 接続単位ではなく業務単位で権限を切る。システム全体への権限を1本のキーで渡していると、将来の細分化がそのまま作り直しになります。読み取りだけで足りる処理に書き込み権限を渡さない設計は、今日から実装できます。権限の切り方は「AIエージェントの権限管理｜野良化を防ぐ3つの設計変数」で整理しています。

3. 失効の手順を先に決める。退職・委託終了・インシデント時に、どのキーを誰が止めるのかを文書化します。IdP一元管理に移れば1か所で済みますが、移るまでの期間こそ手順が要ります。

4. 社内のIdPを接続の起点にできるか確認する。将来Enterprise-Managed Authorizationに乗るなら、入口は会社のIdPです。社員が業務ツールで使っている認証基盤と、AI関連ツールの認証がつながっていないなら、先に揃えておくほど移行が軽くなります。端末や場所による利用制限の考え方は「Gemini Enterpriseの利用を端末と場所で絞る」も参考になります。

発注・契約の前に聞く4つの問い

ベンダーにMCP接続を依頼する場合、確定仕様を待たずに確認できる項目があります。

問い	何を見分けられるか
接続に使う資格情報は、誰の名義でどこに保存されますか	個人アカウントの流用と、サービス用IDの使い分けができているか
アクセストークンの有効期限と、失効の手順を教えてください	長期有効なトークンを配りっぱなしにしていないか
将来、当社のIdPを認証の起点にする構成へ移行できますか	Enterprise-Managed Authorizationのような一元管理に乗れる設計か
対象システムごとに権限を分けられますか。最小の単位は何ですか	権限が「システム全体」でしか切れない作りになっていないか

AI導入の進め方全体は「AI導入支援｜中小企業の進め方と支援会社の選び方」、発注前に確認する具体的な基準は「AI導入支援会社の選び方｜発注前に確認する7つの基準」で解説しています。エージェント導入そのものの支援先を選ぶ観点は「AIエージェント導入支援の選び方｜5つの確認点」にまとめています。

よくある質問

MCPのエージェントID対応はいつ使えるようになりますか。

2026年10月9日時点で時期は公表されていません。公式ロードマップは今後6〜12か月の優先領域を示すもので、内容の変更や先送りがあり得ると明記されています。時期を前提にした計画は立てないのが安全です。

いまAPIキーでMCP接続している構成は、作り直しが必要になりますか。

必須とは言えません。ただし資格情報の名義・保管場所・権限の単位を整理しておくと、将来の移行が軽くなります。個人名義のキーを共用している状態は、仕組みが変わっても自動では解消されません。

DPoPとは何ですか。導入すると何が防げますか。

DPoPはトークンを送信者に暗号的に結び付けるIETFの標準（RFC 9449）です。トークンが漏れても、その鍵を持たない第三者が単独で使うことを難しくします。MCPでは仕様確定と普及が今期の目標に挙がっています。

手元のPCで動かすMCPサーバーにも同じ話が当てはまりますか。

当てはまりません。現行仕様（2026-07-28版）は、STDIOトランスポートは認可仕様に従わず環境から資格情報を取得すると規定しています。ローカル接続は当面、環境変数でのキー管理が前提になります。

まとめ

経営・DX目線での要点は3つです。第一に、MCPの公式ロードマップは現状を「貼り付けたAPIキーと長期有効なトークンへの依存」と認めたうえで、エージェント自身のIDと権限委任に向かうと示しました。第二に、これは確約ではありません。担当ワーキンググループは形成中で、関連する拡張はオプトイン、ローカル接続はそもそも対象外です。第三に、それでも今日決められることがあります。資格情報の一覧化、業務単位の権限設計、失効手順、IdPとの接続です。

Auto-IDフロンティアとしては、標準が固まるのを待つより、「移行できる形で始める」判断のほうが費用対効果が高いと考えています。資格情報の名義と権限の単位は、仕様が変わっても引き継がれる情報だからです。次に取るべきアクションは、現在動いているAI連携（検証中のものを含む）について、接続に使っている資格情報の名義・保管場所・権限範囲・失効手順の4項目を一覧にすることです。空欄になった箇所が、そのまま次に決めるべき論点になります。

社内システムとAIの接続を、後で作り直さずに済む形で始めたいという方は、AI導入相談フォームからお気軽にご相談ください。

出典・参考資料

• Model Context Protocol： Roadmap （2026年8月22日）
• Model Context Protocol Blog： The New MCP Roadmap （2026年8月22日）
• Model Context Protocol： Enterprise-Managed Authorization
• Model Context Protocol： Specification 2026-07-28 — Authorization （2026年7月28日）
• IETF： RFC 9449: OAuth 2.0 Demonstrating Proof of Possession (DPoP)
• IETF： RFC 8693: OAuth 2.0 Token Exchange