MCPの次の宿題は『エージェントの身元』——2026ロードマップが示す、人の承認からワークロード認証への移行

AIエージェントを社内システムにつなぐ「共通の差込口」として、MCP（Model Context Protocol）はこの1年で事実上の標準になった。homula のエンタープライズ統合基盤 Agens も、MCP を土台に「200以上のツールと構築ゼロで接続」する設計を採っている。その MCP のメンテナ陣が、2026年8月22日に新しいロードマップを公開した（Model Context Protocol Blog）。7月28日の大改定で「ステートレスな中核」がひとまず固まったのを受け、次に何へ力を注ぐかを示す文書だ。

読むと、次の半年の重心がどこにあるかがはっきり見える。エージェント自身の「身元」だ。 これまでの MCP 認可は「人がブラウザで承認する」ことを前提にしていた。だが実際に MCP サーバーを叩く主体は、いまや自分の資格情報でクラウド上を走るエージェント（ワークロード）へと移りつつある。ロードマップはこのズレを正面から扱う。本稿では公開されたロードマップを一次情報から整理し、日本企業がいま接続層に仕込んでおくべき論点を示す。

ロードマップの全体像：5つの優先領域

ロードマップは、リード・メンテナの David Soria Parra 氏と Den Delimarsky 氏の署名で公開された。掲げられた優先領域は次の5つだ。

7月28日の改定が「接続と認証と拡張の作り直し」だったのに対し、今回のロードマップはその先の運用課題——大量のエージェントを、身元をもって安全に走らせること——に照準を合わせている。以下、企業の運用に効く順に見ていく。

本題：認可の主語が『人』から『エージェント』へ移る

いちばん重いのが3番目、エージェント認証だ。ロードマップは明確に、MCP の認可が今日「人がブラウザで承認する」設計を中心に組まれていることを認める。対話的なクライアントには向くが、呼び出し側の多くが自分の身元を持つクラウドワークロードになっていく現実には合わない。そこで、貼り付けた API キーや長寿命トークンではなく、既存標準の上にエージェントの身元を載せる方向が示された。

具体的に挙がっている要素は次のとおり（Model Context Protocol Blog）。

• DPoP（Demonstrating Proof of Possession, RFC 9449）：トークンを要求元クライアントに束縛し、盗まれたベアラートークンの使い回し（リプレイ）を防ぐ。仕様の確定と普及のために Agent Identity ワーキンググループを新設する。
• Workload Identity Federation（SEP-1933）：AWS IAM・GCP・Azure などのワークロード ID と連合し、静的な鍵を配らずにエージェントを認証する。
• ID-JAG（Identity Assertion JWT Authorization Grant）：Enterprise-Managed Authorization（企業管理認可）の裏で使われる委任の仕組み。エージェントが「自分の身元」または「ユーザーに委任された身元」でサーバーに到達できる道筋を、標準化して用意する。
• RFC 8693 トークン交換：上記を束ねる土台。IETF の OAuth・WIMSE ワーキンググループと協調して進める。

これは7月28日の改定（過去記事）で認可が本番の OAuth/OIDC に寄った流れの、当然の続きだ。あのとき企業 ID 基盤（Entra ID・Okta）に「人として」つなげるようになった。次は、その基盤にエージェントを一級の主体として登録し、監査可能な形で権限を渡す段階に入る。

エージェント間メッセージング：ポーリングからイベント駆動へ

もう一つの重心が、要求/応答の枠を越えたやり取りだ。ステートレス化の副作用として、これまで双方向ストリームでやっていた「途中経過の通知」や「完了の待ち受け」は素直に書けなくなった。ロードマップは、ここを次のプリミティブで埋めにいく。

• Tasks（SEP-2663）：長時間の非同期処理を正式なタスクとして扱う。
• 購読（subscriptions / listen）と進捗通知：処理の途中経過を受け取る。
• サーバー起点イベント（webhook・チャネル）：クライアントがポーリングし続けなくても、サーバー側から変化を通知できるようにし、ポーリングの撤廃を狙う。

さらに、Agents・Transports・Triggers & Events の各ワーキンググループを横断して「プリミティブ同士がちゃんと噛み合うか」を審査する、とされている。個々の機能を足すだけでなく、組み合わせの整合を取りにいく姿勢だ。

トランスポートとプリミティブ：一本化と「百個のツール」問題

残る3領域も、大規模運用の悩みに直結する。

HTTPネイティブ・トランスポートの統一では、リモート MCP サーバーが既に「ただの HTTP ワークロード」になったことを踏まえ、ローカルサーバーも標準入出力の上で Streamable HTTP を話す形へ寄せる。トランスポートを一本の束縛に統一し、開発とゲートウェイでの扱いを単純化する狙いだ。

プリミティブの改善では、ツール結果の扱い方（契約）を標準化するほか、大規模なツールカタログの段階的発見に取り組む。ロードマップは「百個のツール」を例に挙げ、全部を一度に読み込ませるのではなく、必要なものを段階的に見つけさせる仕組みを検討する。エージェントに接続するツールが増えるほど、これは実務で効いてくる。

homulaの観点：ロードマップは『接続層に何を仕込むか』の指針

ロードマップは確定仕様ではない。だからこそ、企業にとっての価値は「次に何が来るかを知り、いま作る接続層をそこへ地続きにしておく」ことにある。homula がエンタープライズの現場で置くべきと考える論点は3つだ。

1. エージェントの身元を、いまから設計に織り込む：貼り付け API キーや長寿命トークンで動いている MCP 接続は、DPoP・Workload Identity Federation・ID-JAG が普及した世界では作り直しの対象になる。どのエージェントが誰の権限で何に触れているかを可視化し、企業 ID 基盤に「エージェントを主体として」寄せていく前提で組む。
2. 認可の刷新をガバナンスに束ねる：エージェントが自分の身元で走るということは、その一挙手一投足を誰が承認し、どう記録するかが問われるということだ。ここに Agens Control の承認フロー・DLP・5年分の監査ログ・RBAC を重ね、「つながる」と「統べる」を同時に満たす。ワークロード認証は、統制の敵ではなく前提装置になる。
3. 拡張の取捨と段階導入：Tasks やサーバー起点イベント、段階的ツール発見は、全部を一括で背負う必要はない。業務の必要から選び、段階的に採る。Agens の「構築ゼロ接続」は、こうした選択的採用を現場の速度で回すための土台になる。

homula は戦略策定 → PoC（最短5日）→ 実装 → 運用 → 内製化を一気通貫で支援する立場から、こうした「標準がまだ動いている領域」への向き合い方を重視している。仕様は固まっていない。だが方向は見えている。動くたびに外部へ丸投げしていては、統制も速度も手に入らない——動く標準を自社で追える形に落とすことが、エージェント時代の接続層の要件だ。

まとめ

• MCP は2026年8月22日、新ロードマップを公開。次の重心はエージェント自身の身元だ。
• 認可の主語が「人のブラウザ承認」からワークロードの身元へ移る。DPoP（RFC 9449）・Workload Identity Federation・ID-JAG・RFC 8693 が軸で、専用のワーキンググループが新設される。
• エージェント間メッセージング（Tasks・購読・サーバー起点イベント）でポーリングを撤廃し、トランスポートを HTTP ネイティブに一本化、大規模ツール群の段階的発見にも取り組む。
• 確定仕様ではないからこそ、企業はいまの接続層をこの方向に地続きで作り、認可刷新をガバナンス再設計と束ねておくのが得策だ。

「人が承認する」から「エージェントの身元で走る」へ。MCP が引く次の線は、企業の接続層の作り方そのものを問い直す。

---

エージェント認証の刷新と、その上の承認・監査・権限の設計は、切り離さずに一度で組むほど後が楽になる。homula は接続の作り直しから内製化までを伴走する。

MCP活用支援の詳細を見る

Agens Controlで承認・監査・ガバナンス設計を見る

無料相談を予約する