わずか1週間前、Model Context Protocolは2025-11-25仕様のリリースで最初の記念日を祝いました[1]。この発表は当然の勝利宣言でした。MCPは実験的なオープンソースプロジェクトから、GitHub、OpenAI、Microsoft、Blockに支援される基盤標準へと進化し、本番環境で稼働する何千ものアクティブなサーバーを持つに至っています[1]。
\n\nしかし、祝賀の裏にはより興味深い物語があります。この仕様リリースは単なる進化ではなく、エンタープライズ対応への戦略的な方向転換なのです。過去1年間、MCPは開発者ツールとして成功してきました。実験中にAIモデルをデータや機能に接続する便利な方法として機能してきたのです。2025-11-25仕様は異なります。組織がエージェント・ツールエコシステムをエンタープライズスケールで展開することを妨げる運用、セキュリティ、ガバナンスの課題を解決するために明示的に設計された機能を導入しています。
\n\n本稿では、新仕様から3つの主要機能を検証し、私が「本番環境への溝(production gap)」と呼ぶもの、つまり実験的なエージェントプロトタイプとエンタープライズグレードのエージェント型インフラストラクチャの間の距離を、それらがどのように埋めるかを分析します。
\n\n技術的な機能に入る前に、それらが解決している問題を理解する必要があります。組織は数か月間、MCPを活用したエージェントを実験しており、制御された環境で印象的な結果を出すことも多々あります。しかし、これらのプロジェクトのほとんどは、本番環境への展開に進むことができず、パイロットの煉獄に閉じ込められたままです。障壁は技術的な気まぐれではなく、基本的な運用要件です:
\n\n| 要件 | \n重要性 | \n欠けていたもの | \n
|---|---|---|
| 非同期操作 | \nレポート生成、データ分析、ワークフロー自動化などの実世界のタスクは、ミリ秒ではなく、数分または数時間かかることがある。 | \nMCP接続は同期的。長時間実行されるタスクは、クライアントに接続を開いたままにするか、カスタムポーリングシステムを構築することを強いる。 | \n
| エンタープライズ認証 | \n組織は、どのユーザー、エージェント、サービスが機密ツールやデータにアクセスできるかを一元的に制御する必要がある。 | \n元のOAuthフローはコンシューマーアプリモデルを前提としていた。マシン間認証のサポートがなく、エンタープライズIdentity Providerとの統合もなかった。 | \n
| 拡張性 | \n異なる業界やユースケースでは、コアプロトコルを断片化させることなくカスタム機能が必要。 | \n拡張を標準化する正式なメカニズムがなく、独自の互換性のない実装につながっていた。 | \n
これらはエッジケースではありません。本番システムの基本要件です。2025-11-25仕様は、これらすべてに直接対処しています。
\n\nおそらく最も変革的な追加は、新しいTasksプリミティブです[2]。まだ実験的とマークされていますが、長時間実行操作のためにエージェントがMCPサーバーと対話する方法を根本的に変えます。
従来のMCPは古典的なRPCパターンに従います。クライアントがリクエストを送信し、サーバーが処理し、サーバーがレスポンスを返す—すべて単一の接続内で行われます。これは、データベース行の読み取りや天気APIのチェックのような素早い操作には美しく機能します。しかし、現実的なエンタープライズワークフローでは破綻します:
\n\n組織はカスタムの回避策を構築することを余儀なくされてきました。ジョブキュー、ポーリングシステム、コールバックwebhook—すべて非標準で、すべてが複雑さを増し、相互運用性を低下させています。
\n\n新しいTasks機能は、標準的な「今すぐ呼び出し、後で取得」パターンを導入します:
taskヒント付きでMCPサーバーにリクエストを送信します。taskIdを返します。working、completed、failed)をチェックします。taskIdを使用して最終結果を取得します。これは単なる糖衣構文以上のものです。MCPエコシステム全体にわたる非同期作業の統一された抽象化を提供します。エージェントフレームワークは、データパイプライン、デプロイメントシステム、またはドキュメントプロセッサーを呼び出しているかどうかを知る必要がありません—非同期パターンは同じです。
\n\n本番環境では、これがすべてを変えます。複雑なワークフローを調整するAIアシスタントは以下が可能になります:
\n\nこれが実際の自律エージェントの動作方法です。Tasksプリミティブは、標準的で相互運用可能なプロトコル内でこれを可能にします。
元のMCP仕様にはOAuth 2.0サポートが含まれていましたが、コンシューマーアプリパターン(「GitHubでログイン」のようなもの)をモデルにしていました。そのモデルは、組織が一元的なID管理、監査証跡、ポリシーベースのアクセス制御を必要とするエンタープライズユースケースでは機能しません。2025-11-25仕様は、この溝を埋めるために2つの重要な更新を導入しています。
\n\n最初の変更は、Dynamic Client Registration (DCR)をClient ID Metadata Documents (CIMD)に置き換えることです[3]。古いモデルでは、すべてのMCPクライアントが使用したいすべての認可サーバーに登録する必要があり、連携されたエンタープライズ環境ではスケーラビリティの悪夢でした。
\n\nCIMDでは、client_idはクライアントが制御するURL(例:https://agents.mycompany.com/sales-assistant)になりました。認可サーバーがこのクライアントに関する情報を必要とする場合、そのURLからJSONメタデータドキュメントを取得します。このドキュメントには以下が含まれます:
このアプローチは、DNSとHTTPSに固定された分散信頼モデルを作成します。認可サーバーはクライアントと事前の関係を持つ必要がありません。URLで公開されたメタデータを信頼します。数十のエージェントアプリケーションと複数のMCPプロバイダーを持つ大規模組織にとって、これは運用オーバーヘッドを劇的に削減します。
\n\n2つ目の重要な追加は、M2M OAuth拡張を介したOAuth 2.0 client_credentialsフローのサポートです。これによりマシン間認証が可能になり、エージェントとサービスがループ内の人間ユーザーなしでMCPサーバーと直接認証できます。
なぜこれが重要なのでしょうか?以下のエンタープライズシナリオを考えてみてください:
\n\nこれらのいずれも対話的なユーザーを含みません。組織の代わりにツールにアクセスするために永続的で安全な認証情報を必要とする自律サービスです。client_credentialsフローは、まさにこのユースケースのための標準的なOAuthメカニズムであり、MCPへの含有により、ヘッドレスエージェントシステムが実現可能になります。
大規模エンタープライズにとって戦略的に最も重要な機能は、おそらくCross App Access (XAA)拡張です。これは、エンタープライズAIの消費者化を悩ませてきたガバナンスの問題、つまり制御されないツールの拡散を解決します。
\n\n標準的なOAuthフローでは、ユーザーはツールにアクセスするためにAIアプリケーションに直接同意を付与します。エンタープライズIdentity Provider (IdP)は、「アリスがAIアプリにログインした」ことだけを見て、「アリスのAIエージェントが給与システムにアクセスしている」ことは見ません。これがガバナンスのブラックホールを作り出します。
\n\nXAAは、エンタープライズIdPを中央のポリシー実施ポイントとして挿入するために認可フローを変更します。エージェントがMCPサーバーへのアクセスを試みると:
\n\nこれにより、エージェント・ツールエコシステム全体にわたる一元的な可視性と制御が提供されます。セキュリティチームは、どのエージェントがどのツールにアクセスしているかを監視し、組織全体のポリシーを設定し(例:「人間のレビューなしにPIIにアクセスできるエージェントはない」)、すべての委任されたアクセスを監査できます。シャドーAIを排除し、規制産業が要求するコンプライアンスストーリーを提供します。
\n\nこれらのOAuth拡張機能を合わせることで、MCPは開発者の利便性からガバナンスされた監査可能な統合レイヤーに変革されます。組織は以下が可能になります:
\n\n3つ目の主要な追加は、正式な拡張フレームワークの導入です[3]。これはプロトコル自体のガバナンスメカニズムであり、コミュニティがエコシステムを断片化させることなく新しい機能を開発できるようにします。
\n\n成功したすべてのプロトコルはこのジレンマに直面します。進化するユースケースに追いつくためにイノベーションを十分に速く可能にしつつ、相互運用性を維持するために注意深く標準化する。遅すぎると、コミュニティはエコシステムを断片化させる独自の拡張を構築します。速すぎると、コアプロトコルはほとんどの実装が必要としないニッチな機能で肥大化します。
\n\nMCPの解決策は、構造化された拡張プロセスです。新しい機能はSpecification Enhancement Proposals (SEPs)として提案され、コミュニティレビューを受け、段階的に採用できます。拡張は名前空間化され、明確にマークされているため、実装は互換性を破ることなく選択的にサポートできます。
\n\nエンタープライズにとって、これは重要です。異なる業界には独自の要件があります:
\n\n正式な拡張フレームワークにより、組織はこれらの機能を独自のフォークではなく、標準的で相互運用可能な拡張として開発できます。これにより、MCPの中核的な価値提案、つまりエージェント・ツール通信のための普遍的なプロトコルを維持しながら、本番使用に必要なカスタマイズを可能にします。
\n\nもう1つ言及に値する機能があります:Sampling with Tools[3]です。これにより、MCPサーバー自体がエージェント型システムとして機能し、マルチステップの推論とツール使用が可能になります。サーバーはクライアントに代わってLLMを呼び出すようリクエストでき、サーバーサイドエージェントを可能にします。
\n\nなぜこれが強力なのでしょうか?構成的なエージェントアーキテクチャを可能にするからです。高レベルのエージェントは特化したMCPサーバーに委任でき、それら自体がエージェント型推論を使用して複雑なリクエストを満たします。例えば:
\n\nこのネストされた階層的なアプローチは、実際の自律システムがスケールする方法です。これをカスタム実装ではなく標準的なプロトコル機能にすることで、MCPは特化した構成可能なエージェントの豊かなエコシステムの基盤を提供します。
\n\n2025-11-25 MCP仕様は急進的な再設計ではなく、エンタープライズ採用を妨げる障壁に直接対処する的を絞った拡張のセットです。以下を導入することで:
\n\n仕様は本番環境への溝、つまり実験的プロトタイプとスケーラブルで安全なエンタープライズグレードシステムの間の距離を埋めます。
\n\nこれは、MCPが有望な開発者ツールからエンタープライズインフラストラクチャの基盤的な部分へと移行する瞬間です。「本番対応」のシグナルを待っていた組織は、今それを手にしています。機能はあります。ガバナンスメカニズムはあります。セキュリティモデルはあります。
\n\nエージェント型AIの次のフェーズは、派手なデモではなく、エンタープライズワークフローに深く統合された自律システムの静かで信頼性が高く大規模な運用によって定義されるでしょう。2025-11-25 MCP仕様は、この未来を可能にする技術的基盤です。
\n\nMCPベースのインフラストラクチャへの投資を評価している技術リーダーにとって、計算は変わりました。これはもはや実験的なプロトコルではなく、本番標準です。今それを採用し、その上にエージェントエコシステムを構築し、その継続的な進化に貢献する組織が、エンタープライズAIの次の10年を定義するでしょう。
\n\n参考文献:
\n\n\n\n[2] Model Context Protocol. (2025, November 25). Tasks. Model Context Protocol Specification.
\n\n\n\n\n\n", "source_hash": "sha256:ea07631d24ec71a2eeb27320d3216318879d24370148bc466f28b99355798962", "model": "claude-sonnet-4-5-20250929", "generated_at": "2026-01-02T01:07:45.492082+00:00" }