エッジにおける MCP：あらゆる配信拠点で MCP を安全に実行することにより何が変わるのか

Model Context Protocol (MCP) サーバーは、AI エージェントがツールを呼び出し、リソースを読み取り、プロンプトを一括で取り込むための標準的な方法を提供します。 

ほとんどの MCP サーバーは、単一リージョン、ロードバランサーの配下、クライアントごとのセッション維持といった、従来型のクラウドアーキテクチャで稼働しています。それは、地球の反対側にいるエージェントが1つのタスクを完了するために40回ものツール呼び出しを行い、その推論ループ内で呼び出しのたびに大陸間通信によるラウンドトリップが発生するようにならない限り、合理的な選択です。こうした長距離通信によるラウンドトリップは瞬く間に積み重なっていき、アプリケーションのパフォーマンスを著しく低下させます。

すべてのデータセンターにわたって Fastly Compute 上で MCP サーバーを WebAssembly バイナリとして実行し、620+ Tbps のグローバルプラットフォームによって強化および保護することで、エージェントとそれを管理する人々にとって、MCPでできることの可能性を大きく広げます。当社では、これをまさに実現するサンプルプロジェクトを先日公開しました。独自の MCP スタックをモダナイズする際に、コーディングエージェントはこのプロジェクトを参照できます。 

特殊なホスティングサービスに費用をかけたり、サーバーを特定の地域に限定して配置したりする必要はもうありません。また、ネットワークにデプロイする前に、Fastly のローカル Compute ランタイムである Viceroy を使用して、プロジェクト全体をローカルでテストすることもできます。以下では、エッジでステートレスな MCP を実行する仕組みについて詳しく解説します。

重要なポイントでレイテンシを解消：エージェントループの内部

エージェントは、1回の呼び出しだけで処理を終えるわけではありません。ツールを見つけ出し、1つを呼び出して結果を読み取り、別のツールを呼び出し、応答するまでに十数回ループすることもあります。これらのホップの1つひとつが、エージェントのワークフローにおけるクリティカルパス上に存在します。従来のアーキテクチャで MCP サーバーをホストしている場合、世界各地でその MCP サーバーを利用するエンドユーザーである開発者は、呼び出しごとに合計で最大 500ms の遅延を経験する可能性があり、エージェントは1つのアクションにつき何十回も呼び出しを行うことがあります。こうした遅延は瞬く間に積み重なり、エンドユーザーの体験を大きく損ないます。 

エッジでは、リクエストの送信元からわずか数ミリ秒の場所にサーバーが存在します。単一のオリジンリージョンによる制限はなく、ホームデータセンターへのバックホールも発生しません。ツールカタログ、呼び出しのディスパッチ、認証チェックなどは、すべて最寄りの配信拠点で処理されます。通信頻度の高いエージェントのワークロードでは、各呼び出しから数百ミリ秒を削減することで、エージェントループが目に見えて高速化されます。

ステートレス設計で、どの配信拠点からでも応答可能

最新の MCP リビジョン (2026-07-28) は、ステートレスになるよう構築されています。これは HTTP のベストプラクティスにより即したアプローチであり、この分野における Agentic AI Foundation の研究や今後の技術革新を支援できることを当社は光栄に思います。

このリビジョンにおける注目すべき相違点は、初期化ハンドシェイクが存在しないことです。各リクエストは _meta ブロック内に独自の ID とネゴシエートされた機能を保持しており、呼び出し間で維持する必要があるステートは、サーバー側に保持されるのではなく、リクエストとともに渡されます。

セッションが特定のマシンに固定されないため、ステートレスなエッジデプロイは、従来の仕様よりもはるかに魅力的な選択肢となります。Fastly のような最新のプラットフォームでこのような実装することにより、いかが可能になります。 

• MCP サーバーは瞬時にあらゆる場所にデプロイされます。リクエストは、世界中のどの Fastly データセンターに到達しても正しく処理されます。

• スケーリングは水平かつ自動で行われ、コールドスタートによる遅延はありません。Fastly は、MCP サーバーを50マイクロ秒未満で起動します。

• 各リクエストは当社の WebAssembly ベースのランタイム内で安全に分離されるため、ノイジーネイバーによるセキュリティリスクを排除できます。

1回のデプロイだけで、世界中に分散したプラットフォームをシンプルに運用できます。

接続を維持せずに長時間・複数ステップの処理を実行

「ステートレス」は通常、「長時間実行」とは両立しないように思われます。この仕様で定められた2つの継続処理の仕組みによってこれが可能になっており、当社の実装ではその両方を活用しています。

• マルチラウンドトリップリクエスト (MRTR)：ツールは呼び出しの途中で一時停止してクライアントに入力を求め、その後処理を再開できます。処理中の状態は不透明なトークンに封入され、クライアントは次回の呼び出し時にそれを返送します。接続を維持する必要はなく、どのインスタンスでも処理を引き継いで再開できます。

• Tasks 拡張機能：長時間実行される処理をトリガーし、タスクハンドルを返すツールです。クライアントは処理中ずっとソケット接続を維持するのではなく、ポーリングによって処理の完了を確認します。これは Fastly のリクエストモデルによく適合します。

どちらの継続トークンも、認証付き暗号化によって暗号学的に保護され、呼び出し元の ID に紐付けられるため、「状態がリクエストと共に移動する」モデルが処理の偽造やハイジャックの手段になることはありません。

キャッシュから配信されるツールカタログ

ディスカバリーおよびリスティングの呼び出し — server/discover、tools/list、prompts/list、resources/list — は、すべての呼び出し元に同じ応答を返し、めったに変更されることはありません。これらは、Fastly のネイティブキャッシュ機能を利用してエッジでキャッシュするのに最適です。

サーバーは、これらのレスポンスに鮮度とキャッシュ範囲を示すヒントを付与するため、キャッシュは毎回ハンドラーを再実行することなく、世界中のエージェントにツールカタログを配信できます。誰が問い合わせているかに依存するものはすべて自動的にキャッシュから除外されるため、リクエスト間で漏洩することはありません。

オリジンに到達する前にセキュリティを適用

Fastly は、ツールが実際に通信するサービスの手前に配置されるため、アクセス制御を適用するのに最適な場所です。このプロトタイプには、以下の機能を組み込みました。

• 認証はデフォルトでフェイルクローズ方式を採用：設定ミスが発生しても、エンドポイントがロックダウンされるか利用不可になるだけで、気付かないうちにオープンな状態になることは決してありません。

• エッジでベアラートークンを検証：  キャッシュされた JWKS に対して ES256 JWT を検証するため、未認証のリクエストや不正な形式のリクエストは、ダウンストリームでコストが発生する前に拒否されます。

• 認可はデフォルトで拒否され、適用範囲が限定される：呼び出し元はツールが宣言する特定のスコープを保持している必要があります。何も宣言していないツールは、認可のもとでは呼び出すことができません。

• リクエストボディは解析前に上限が設定される：JWKS の取得は SSRF から保護され、内部エラーはデバッグ用の相関 ID でマスキングされます。

不正または悪意のあるリクエストは Fastly 内で阻止されるため、バックエンドに到達することはありません。

Fastly プラットフォームのあらゆる機能を最大限に活用

MCP プロトタイプは Fastly Compute 上で動作します。つまり、以下をはじめとするプラットフォームの高い耐障害性や豊富な機能を活用できます。

• 50マイクロ秒未満のコールドスタート

• 当社の WebAssembly ランタイムによるセキュアな分離

• ワンクリックでの DDoS Protection を有効化

• 必要に応じて利用できる 620+ Tbps の容量

• リクエスト共有により、製品へのアクセスが急増した際のサンダリングハード問題を防止

ステートレスな MCP 仕様と Fastly のランタイムは互いを補強し合っています。このプロトコルは、リクエストとともにステートを引き継げるよう設計されており、そのメリットを最大限に活かせるのがエッジ環境です。これまで単一リージョンでセッションに紐付けられていたサービスを、あらゆる場所に展開し、呼び出し元のすべてのエージェントの近くで利用できるサービスへと変えることができます。

実際に試すには、GitHub のプロジェクトをご覧ください。