AIエージェントが社内システムに触れるための「共通の差込口」として、MCP（Model Context Protocol）はこの1年で事実上の標準になった。homula のエンタープライズ統合基盤 Agens も、この MCP を土台に「200以上のツールと構築ゼロで接続」する設計を採っている。その MCP が、2026年7月28日付でローンチ以来もっとも大きな改定を迎えた。単なるバージョンアップではない。接続のかたち・認証のかたち・拡張のかたちの3つが同時に作り直された。
重要なのは、この改定が「便利機能の追加」ではなく「エンタープライズ規模で運用するための土台の入れ替え」だという点だ。既に MCP サーバーを立てて運用している企業ほど、移行という現実に向き合うことになる。本稿では 2026-07-28 仕様で何が変わったのかを一次情報から整理し、日本企業がいま置き直すべき接続とガバナンスの論点を示す。
何が変わったのか：3つの構造転換
公式ブログは今回の狙いを「サーバーの信頼性とスケーラビリティの向上」と明言している。双方向・ステートフルなモデルから、ステートレスな要求/応答アーキテクチャへの転換がその核だ（Model Context Protocol Blog）。要点は次の3つに集約できる。
| 転換 | これまで（〜2026） | 2026-07-28 仕様 |
|---|---|---|
| プロトコルの状態 | initialize ハンドシェイクとセッション管理が前提 | ハンドシェイクを廃止。各リクエストが _meta にプロトコルバージョン・クライアント識別・能力を載せる |
| 認証 | 独自運用に寄った実装が混在 | 本番の OAuth 2.0 / OIDC に整合。DCR を非推奨化し CIMD へ |
| 機能の増やし方 | 仕様本体に機能を積み増し | 安定した中核 ＋ 独立バージョンの「拡張」に分離 |
以下、それぞれが企業の運用にどう効くかを見ていく。
ステートレス化がもたらす「運用のしやすさ」
最大の変更は、接続開始時の initialize／initialized ハンドシェイクとセッション管理を撤廃したことだ。各リクエストが自分でプロトコルバージョンやクライアントの能力を _meta に持つため、Streamable HTTP トランスポートから Mcp-Session-Id ヘッダーは姿を消した。
これは地味に見えて、運用の性質を変える。公式は、MCP サーバーを「共有ストレージを持たない素のラウンドロビン・ロードバランサの背後に配置できる」と表現している。つまりセッションの貼り付き（スティッキー）を気にせず水平スケールできる——大量のエージェントが同時に叩く本番環境で、これは効く。
ステートレス化に伴い、双方向ストリームに依存していた対話系のやり取りも作り直された。ユーザー確認や不足パラメータの入力といった「呼び出しの途中で人に聞く」処理は、サーバー起点のストリームではなく Multi Round-Trip Requests（MRTR） に置き換わり、ツールが resultType: "input_required" を返して必要な入力を要求できる。加えて、Mcp-Method／Mcp-Name の HTTP ヘッダーでゲートウェイが JSON 本体を解析せずにルーティング・計測でき、一覧系の応答は ttlMs／cacheScope でキャッシュ戦略を指定できるようになった。
ステートレス化は「軽量になった」話ではなく「スケール時の前提が変わった」話だ。セッションIDに依存した独自の負荷分散・保持ロジックを組んでいる場合、そこは作り直しの対象になる。
認証が『本番のOAuth/OIDC』に寄った
エンタープライズにとって、今回いちばん実利が大きいのは認証まわりだ。2026-07-28 では認可仕様が実運用の OAuth 2.0 / OpenID Connect に近づき、MCP サーバーを Entra ID や Okta といった企業の ID 基盤へ、独自の回避策なしに接続できる方向へ整理された。主な硬化点は次のとおり。
- RFC 9207（issuer 検証）が必須化：認可サーバーの発行元検証を強制。
- DCR（動的クライアント登録）を非推奨化し、CIMD（Client ID Metadata Documents）へ：
client_idが「クライアントのメタデータをホストする HTTPS URL」になり、サーバーは DB を引く代わりにその URL を解決する（WorkOS）。 - クライアント資格情報を発行元に束縛：別の認可サーバーへの使い回しを防ぐ。
DCR は後方互換のため当面残るが方向性は明確で、開放的なエコシステムでは CIMD が既定、統制された社内環境では DCR も併用という整理が現実的だとされる。企業 ID との接続が「独自グルーコードの塊」から「標準的な OAuth/OIDC 連携」に寄ることは、権限設計・棚卸し・監査のいずれにとっても追い風だ。裏を返せば、いまの MCP 接続がどんな認証で誰の権限で動いているかを、この機に可視化しておく必要がある。
「拡張」で仕様が割れた——Tasks / Apps / EMA
3つ目の転換は、機能の増やし方そのものだ。2026-07-28 は正式な拡張フレームワークを導入し、これまで中核にあった実験的機能を独立した拡張へ切り出した。各拡張は逆引きDNS形式の識別子（例：io.modelcontextprotocol/tasks）を持ち、独自のバージョン・リポジトリ・メンテナで、本体とは別のペースで進化する。
代表的な拡張は次の3つだ。
- Tasks：長時間の非同期処理を正式にサポート。
tools/callがタスクハンドルを返し、クライアントがtasks/get／tasks/update／tasks/cancelで駆動する。セッションなしでは安全にスコープできないためtasks/listは廃止された。エージェントが「何十分もかかる仕事」を投げっぱなしにできる、実務では重要なピースだ。 - MCP Apps：サーバーがレンダリングした対話的な HTML UI をクライアントへストリームし、同じ JSON-RPC 経路でUIがホストと通信する。
- EMA（Enterprise Managed Authorization）：企業側が認可を管理するための拡張。
// Tasks: 呼び出しがタスクハンドルを返し、以後ポーリングで駆動する
{
"taskId": "t_9f2c...",
"status": "working",
"pollIntervalMs": 1500
}
拡張が本体から分離した意味は大きい。企業は「中核仕様は追随しつつ、Tasks や Apps は自社の必要に応じて選択的に採用する」という意思決定ができる。全部入りを一括で背負う必要はない。
移行コストという現実
これだけの再設計は、当然ながら破壊的変更を伴う。公式も「とくにセッション識別子に依存していた開発者にとって移行コストがある」と認めており、その緩和として TypeScript・Python・Go・C# の SDK を同時リリース（Rust はベータ）している。さらに Roots／Sampling／Logging は非推奨化され、削除まで最低12か月の猶予が置かれた。DCR も同様に後方互換が当面維持される。予測可能なアップグレード期間が明示されたことは、計画的な移行を組む側にとって朗報だ。
採用も動き始めている。Claude はこの 2026-07-28 仕様への対応を進めており、ステートレスな中核・より強固な OAuth/OIDC 認可・Apps／Tasks の拡張対応に加え、埋め込みUI・企業管理の認証・可観測性・プライベートネットワークトンネルといったコネクタ機能を挙げている（Claude by Anthropic）。標準が動けば、その上のクライアントとサーバーが順に追随する——既存の MCP 資産を持つ企業ほど、移行の設計を「いつか」ではなく「ロードマップ」に載せる時期だ。
homulaの観点：仕様改定は『接続の作り直し』の号砲
今回の改定は、MCP を「試作の便利ツール」から「本番で統べられる接続層」へ引き上げるものだ。ステートレス化でスケールしやすくなり、認証は企業 ID 基盤に素直につながり、拡張で必要な機能だけを選べる。方向は間違いなく正しい。だが、その恩恵は既存接続をこの新しい前提へ移し替えて初めて得られる。homula がエンタープライズの現場で置き直すべきと考える論点は3つだ。
- 接続の移行設計：ステートフル前提の実装・独自セッション処理・DCR ベースの認証を、ステートレス／CIMD／企業 IdP（Entra・Okta）連携へどう移すか。12か月の非推奨窓を使い、止めずに切り替える段取りを引く。
- 認証の刷新をガバナンスに接続する：OAuth/OIDC への整合は、権限設計を作り直す好機でもある。どのエージェントが誰の権限で何に触れるか——ここに Agens Control の承認フロー・DLP・5年分の監査ログ・RBAC を重ね、「つながる」と「統べる」を同時に満たす。
- 拡張の取捨選択：Tasks（長時間処理）や Apps（UI）、EMA を、業務の必要から選んで採る。全部入りではなく、必要な拡張だけを段階導入する。
homula は戦略策定 → PoC（最短5日）→ 実装 → 運用 → 内製化を一気通貫で支援する立場から、こうした「標準が動いたときの作り直し」を、外注の依存ではなく自社で回せる形に落とすことを重視している。仕様は今後も動く。動くたびに外部へ丸投げしていては、統制も速度も手に入らない。
まとめ
- MCP 2026-07-28 は、ハンドシェイクとセッションを廃したステートレスな要求/応答へ再設計され、水平スケールが素直になった。
- 認証は本番の OAuth/OIDC に整合し、DCR 非推奨・CIMD・issuer 束縛で、企業 ID 基盤との連携が標準化に向かった。
- Tasks・Apps・EMA は独立バージョンの拡張へ分離。企業は必要な機能を選択的に採用できる。
- 恩恵を得るには既存接続の移行が要る。12か月の非推奨窓があるうちに、認証刷新をガバナンス再設計と束ねて進めるのが得策だ。
標準が「本番向け」に成熟したいまこそ、自社のエージェント接続層を、統べられる形に作り直すタイミングだ。
MCPの移行と、その上の権限・監査・承認の設計は、切り離さずに一度で組むほど後が楽になる。homula は接続の作り直しから内製化までを伴走する。