Model Context Protocol (MCP) がステートレス化されました。これにより、各リクエストがプラットフォームの 10ms CPU 制限内に収まる限り、開発者は Cloudflare Workers の無料枠で極小の MCP サーバーを立ち上げることが可能になります。

なぜこの変化が重要なのか

2つの最近の動きがその道を開きました。第一に、MCP コアがセッションベースの設計を脱却し、ハンドシェイクなしで動作するようになりました。これにより、どのリクエストもコードのどのインスタンスでも処理できるようになります。第二に、Cloudflare が McpAgent クラスを廃止し、新しいサーバーにはプレーンなリクエストハンドラーを推奨するようになりました。これらが組み合わさることで、無料プランでの MCP 実行の主な障壁であった Durable Objects やその他のステートフルなストレージの必要性がなくなりました。

無料枠で実際にできること

私たちは、静的サイトから Markdown ファイルを提供する読み取り専用の MCP サーバーを構築しました。このサーバーは、単純な switch 文を使用してメソッドをルーティングする 2 つのツール、list_articles と get_article を実装しています。重い計算は行わず、単に静的アセットを取得するだけです。

Cloudflare の CPU 計測は、総レスポンス時間とは異なります。CPU 時間には、JavaScript の実行に費やされたサイクルのみがカウントされ、ネットワークコールやディスク読み取りの待機時間は含まれません。この違いは重要です。なぜなら、無料枠では CPU 時間がリクエストあたり 10ms に制限されている一方で、総レイテンシはそれよりも高くなる可能性があるからです。

無料枠での測定結果は以下の通りです：

  • server/discover: 0-1 ms CPU
  • tools/list: 0 ms CPU
  • get_article (最大ファイル): 1-2 ms CPU

最大の記事でさえ、10ms の予算のほんの一部しか使用しませんでした。クライアント側で見られた遅延は、コードの実行ではなく、ファイルの読み取り待ちによるものでした。

制限が厳しくなる場面

データは明確なパターンを示しています：

  • データ提供ツール（単純な読み取り、リスト表示）は、余裕を持って制限内に収まります。
  • 計算負荷の高いツール（パース、レンダリング、ハッシュ化、またはその他のアルゴリズム処理）は、すぐに 10ms の予算を使い果たしてしまう可能性があります。

ツールに些細な処理以上のものが必要な場合、開発者は有料の Workers プランに移行する必要があります。5ドルのプランでは、制限がリクエストあたり 30秒に引き上げられます。

誰が得をし、誰が時間を気にするのか

Markdown ファイルや RSS フィードをすでにホストしている小規模なサイトは、新しいルートを 1 つ追加するだけで MCP エンドポイントを公開でき、無料プランを維持できます。これは、ホビーユーザー、ドキュメントサイト、または低トラフィックのブログにとって、運用コストの低減と構成要素の削減を意味します。

ツールに些細な処理以上のものが必要な場合、開発者は有料の Workers プランに移行する必要があります。

リリース前にテストすべきこと

  • ツールのプロファイリング: 代表的なリクエストをいくつか実行し、Cloudflare のダッシュボードで CPU メーターを確認してください。
  • 静的パスと動的パスの分離: 静的ファイルの提供は無料枠で行い、計算負荷の高い呼び出しは有料の Worker または別のバックエンドにルーティングしてください。
  • 隠れたレイテンシに注意: ネットワークの待機時間は CPU 時間にはカウントされませんが、ユーザーエクスペリエンスには影響します。提供するファイルにはエッジキャッシュの利用を検討してください。

反論：無料プランは無制限ではない

ステートレスなコアによって Durable Objects の必要性はなくなりましたが、10ms の上限は依然として厳格な天井です。たとえ控えめなパース（例：Markdown から HTML への変換）であっても、そのコストを過小評価している開発者は、予期せず制限に達してしまう可能性があります。無料枠は「そのまま提供する」シナリオに適しており、オンザフライでのコンテンツ生成には向いていません。

Cloudflare 上の MCP の今後

サイトのコンテンツがすでに静的バケットにある場合、MCP エンドポイントの追加は、数行のコードと 1 つのルートを追加するだけで済むほど簡単かもしれません。プロトコルは現在、小規模なサーバーのニーズ、つまり 10ms の CPU 上限を守る限り無料でホストできるプレーンな HTTP エンドポイントのニーズと一致しています。