「PoCでは動いた」MCPを、本番のスケールに乗せる年
homulaは、エンタープライズ企業向けにAIエージェントの戦略策定・PoC・実装・運用・内製化までを一気通貫で支援するAIインテグレーターです。日々のMCP（Model Context Protocol）導入支援で痛感するのは、「ツールをつなぐ」ところまでは誰でも到達できるが、その先の本番運用——認証・監査・スケール——で多くのプロジェクトが止まるという現実です。
2026年のMCPは、まさにここに切り込みます。2026年3月に公開された2026年版ロードマップは、優先領域を「トランスポートのスケーラビリティ」「エージェント間通信」「ガバナンスの成熟」「エンタープライズ対応」の4つに整理しました。そして5月21日にロックされた次期仕様のリリース候補（RC）では、その中核としてプロトコルのステートレス化が具体化されています。最終仕様は2026年7月28日に公開予定で、本記事執筆時点（5月末）ではまだ確定前です。
本記事は、MCPの基礎解説の焼き直しではありません。「2026年に何が変わるのか」、とりわけ企業が本番でぶつかる4つの壁——認証・監査・ゲートウェイ・設定の持ち運び——を、ステートレス化＋エンタープライズ対応がどう解こうとしているのかに絞って整理します。
前提整理：MCPはAIエージェントと外部ツール／データを標準化された方法でつなぐオープンプロトコルです。基礎から押さえたい方は「MCPとは」を先にどうぞ。本記事は「2026年の進化」に焦点を当てます。
見出しの変化：プロトコル層が「ステートレス」になる
2026年の最大の構造変化は、プロトコルの中核からセッション（状態）が外れることです。
これまでのMCP（Streamable HTTPトランスポート）は、クライアントとサーバーが最初にハンドシェイクを交わし、以後はセッションを保持してやり取りしていました。1対1なら問題ありませんが、本番で台数を増やそうとすると壁にぶつかります。ロードマップ自身が「ステートフルなセッションはロードバランサーと衝突し、水平スケールには回避策が必要だった」と認めています（MCP公式ブログ）。同じクライアントを常に同じサーバーへ送るスティッキールーティングや、状態を共有するセッションストアが要り、運用が重くなっていたのです。
RCではこのハンドシェイクとセッションの仕組みが取り除かれ、サーバーは「素のラウンドロビンのロードバランサーの背後で動かせる」ようになります（MCP仕様RC）。状態をサーバー側に持たないため、リクエストをどのインスタンスに振っても結果が変わりません。これは普通のWebサービスと同じ運用モデルであり、エンタープライズにとっては**「特別扱いしなくてよいインフラ」**になることを意味します。
企業が本番でぶつかる「4つの壁」
ロードマップの「エンタープライズ対応」が示すのは、本番MCP運用で各社が同じ壁にぶつかっている、という観察です。WorkOSの解説も「本番デプロイは同じ一連の壁に突き当たる——標準化された監査証跡がない、認証が静的シークレットに紐づく、ゲートウェイの挙動が未定義、設定がクライアント間を移動しない」と整理しています（WorkOS）。順に見ていきます。
| 壁 | 現状の痛み | 2026年の方向性 |
|---|---|---|
| 認証 | クライアントごとに静的シークレットを抱える。IT部門が一元管理できない | SSO統合フローへの「舗装された道」。SSOで入り、スコープ付きトークンを発行（Cross-App Access） |
| 監査 | 標準の監査証跡がなく、各社が独自にログ・トレースを発明 | 既存のSIEM／APMに流し込める構造化された監査証跡・観測性 |
| ゲートウェイ | プロキシ／ゲートウェイ越しの挙動が未定義（権限の伝播・セッション・可視範囲） | 仲介経由でも「明確に定義された挙動」 |
| 設定の持ち運び | あるクライアントで組んだ設定が別クライアントでゼロから | クライアント横断の設定ポータビリティ |
認証：静的シークレットからSSO統合へ
最も切実なのが認証です。現状の多くのMCP運用は、クライアントが固有の認証情報を抱える形になっており、IT部門が「他のSaaSと同じように」アクセスを管理できません。ロードマップはここに「静的シークレットから離れ、SSO統合フローへ向かう舗装された道」を敷くと宣言しています。鍵になる概念が**Cross-App Access（XAA）**で、各クライアントが個別に認証情報を握るのではなく、組織の既存IdP（Okta、Google Workspace等）を通じてアクセスを仲介します——SSOで入り、スコープを絞ったトークンが出て、ITは常に管理ループの中にいる、という発想です（The New Stack）。
加えてRCには認可（authorization）のハードニングとして6本のSEPが含まれ、OAuth 2.0／OpenID Connectのプラクティスへの整合——たとえばissuer（発行者）の検証の義務化——が強化されます。MCPの認可が、エンタープライズの標準的なIDレイヤーに素直に乗る方向です。
従来: 各クライアント → 静的クライアントシークレット → MCPサーバー
2026: ユーザー → 企業SSO(IdP) → スコープ付きトークン → MCPサーバー
└ ITが付与・失効を一元管理 / 監査可能 / issuer検証あり
ただし注意点があります。WorkOSは、認証まわりの作業は2026年初頭時点でまだ「pre-RFC（仕様化前）」の段階で、エンタープライズ向けの多くはコア仕様の変更ではなく「拡張（Extensions）」として提供される見込みだと指摘しています。つまり「7月28日に全部そろう」わけではありません。方向性は明確でも、足回りは段階的に整います。本番設計では、標準を待つ部分と自社で先に固める部分の切り分けが要ります。
監査・ゲートウェイ：本番運用の土台
監査については、「標準化された監査証跡が存在しない」ため、各社が独自のロギング・トレース・コンプライアンス基盤を作っているのが現状です。2026年の方向性は、MCPが既存のSIEM（Splunk、Elastic等）やAPMに差し込める構造化された監査証跡・観測性を出すこと。「組織が既に動かしている仕組みに信号を流す」という考え方です。
ゲートウェイ／プロキシも、これまで挙動が曖昧でした。クライアントがサーバーに直接つながず仲介を経由するとき、**認可の伝播・セッションのセマンティクス・ゲートウェイが見てよい範囲（inspection boundary）**が未定義だったのです。2026年はここに「明確に定義された挙動」を与えます。エンタープライズではセキュリティ機器の背後でMCPを動かすのが当たり前なので、これは実務直結の論点です。
RCに入る中身——拡張・Tasks・MCP Apps・廃止ポリシー
ステートレス化と認可ハードニング以外にも、RCには本番運用の土台になる要素が並びます（MCP仕様RC）。
- Extensions（拡張）フレームワーク：reverse-DNS形式の識別子を持つ「オプトインの拡張」。独立してバージョン管理され、専用リポジトリと担当メンテナを持ちます。エンタープライズ機能の多くはここに乗ります。
- Tasks：失敗時のリトライや結果保持期限など、長時間処理のライフサイクルをステートレス前提で再設計。コア機能から拡張へ移行します。
- MCP Apps：サンドボックス化されたiframe内で動く「サーバー側でレンダリングするUI」。対話的なHTMLテンプレートとして提供されます。
- 正式な廃止（deprecation）ポリシー：機能に「Active／Deprecated／Removed」のライフサイクルを定義し、廃止予告から最短でも12か月は削除しないと約束します。
最後の廃止ポリシーは地味ですが、エンタープライズにとっては重要です。**「ある日突然、依存していた機能が消えない」**という予見可能性は、本番システムを長期運用する上での前提条件だからです。
ロードマップは「公式のリリースは2025年11月が最後」で、以後は日付主導からワーキンググループ主導の開発へ移ったと述べています。つまり今後は「年に一度の大型リリース」より、領域ごとに拡張が継続的に出る形に。設計時は「コア仕様」と「拡張」を分けて追うのが実務的です。
homulaの視点：ステートレス化が効くのは「土台がある企業」
ここまでの変化は、homulaの支援領域そのものです。整理すると、2026年のMCPは**「つなぐ」を簡単にしつつ、「安全に運用する」責任を企業側のIDレイヤーとガバナンス基盤に寄せていく**方向にあります。逆に言えば、IdP・監査・権限の土台がない企業は、ステートレス化の恩恵（水平スケール）を活かす前段で止まります。
homulaのAgensは、MCPを活用したエンタープライズ向け統合プラットフォームとして、200以上のツールと構築ゼロで接続します。ステートレス化で「サーバーを増やすだけでスケールする」世界になるほど、エージェント側から見た接続点を共通化しておく価値は上がります。クライアントごとに連携を積み増す保守負債を避け、設定の持ち運びにも備えられます。
そして本記事で見た「認証・監査・ゲートウェイ」の壁に直接効くのがAgens Controlです。承認フロー・DLP・5年分の監査ログ・RBACをセットで提供し、「誰が・何に・どの権限でアクセスしたか」を横断的に追える状態をつくります。MCP標準が認可ハードニングやSSO統合へ向かう方向と、企業が今すぐ必要とするガバナンスの“現実解”を橋渡しする位置づけです。
導入の順序としては、いきなり全社展開ではなく、(1) 1業務でMCP接続をPoC → (2) 認可・監査の境界をAgens Controlで設計 → (3) ステートレスなサーバーで横展開、が現実的です。homulaのAIエージェント・ブートキャンプでは、業務棚卸し・プロトタイプ構築・ROI試算を3〜5日で行い、この最初の一歩を素早く形にします。
まとめ
2026年のMCPは、「つなぐための標準」から「本番で運用する接続レイヤー」へと性格を変えます。中核にあるのがプロトコルのステートレス化で、これによりMCPサーバーは普通のWebサービスのように水平スケールできるようになります。
そしてその上で、企業が本番でぶつかる認証（静的シークレットからSSO統合・Cross-App Accessへ）・監査（SIEM/APMに流せる証跡）・ゲートウェイ（仲介経由の明確な挙動）・設定の持ち運びという4つの壁に、ロードマップと7月28日予定の最終仕様が取り組みます。ただし、エンタープライズ向けの多くは拡張として段階的に提供される見込みで、「7月28日に全部そろう」と捉えるのは禁物です。
要点は、標準の進化を待つ部分と、自社で先に固めるべきガバナンスを切り分けること。ステートレス化という追い風を活かせるのは、認証・監査・権限の土台を持つ企業です。
MCPの2026年の進化は、「ツールをつなげるか」より「本番で安全に・大規模に運用できるか」を問うています。自社のどの業務からMCPを本番に乗せ、どこで認証・監査・承認の境界を引くか——標準の進化に振り回されない設計を、早めに整理することが導入の成否を分けます。