MCPホスティングの選び方｜リモートMCPサーバーの置き場所6択をコスト・コールドスタート・stdio対応で比較【2026年版】
MCPサーバーをどこで動かすか。VPS、Cloud Run、Cloudflare Workers、Lambda/Vercel、AgentCore Runtime、MCP専用ホストの6択を、stdio対応・タイムアウト・コールドスタート・GB時間のコストで比較し、Claude・Cursor・自作エージェントへの接続手順までまとめました。
最終更新：2026年10月13日 ／ 対象：MCP仕様 2026-07-28版、各プラットフォームの2026年10月時点の公開料金
結論（30秒で読める要約）
MCPホスティングとは、MCP（Model Context Protocol）サーバーを利用者のPCではなくネットワーク上で動かし、Claude・Cursor・自作エージェントから呼べるStreamable HTTPのURLとして公開することです。2026年時点の現実的な置き場所は、自前のVPS、コンテナ型サーバーレス（Google Cloud Run）、エッジ関数（Cloudflare Workers）、関数基盤（AWS Lambda・Vercel）、エージェント実行基盤（Amazon Bedrock AgentCore Runtime）、MCP専用のマネージドホストの6つです。
選ぶときは次の3点だけ確認すれば足ります。
- そのサーバーはstdio専用か。汎用のプラットフォームの多くはstdioサーバーをそのまま動かせないので、変換役（ブリッジ）を自分で入れるか、それを内蔵したホストを使います。
- ツール呼び出しは何分かかるか。各基盤の上限は「CPU時間10ミリ秒」から「60分」まで大きく違います。
- 月に何時間ちゃんと動いているか。MCPサーバーはほとんどの時間エージェントを待っているだけなので、使った分だけ課金される方式（scale-to-zero）が常時起動より1桁安くなるのが普通です。
2026-07-28版の仕様でStreamable HTTPがステートレスになったため、いまはほぼどのHTTP基盤でもMCPを配信できます。差が出るのは、stdio対応、タイムアウト、コールドスタート、課金方式の4点です。
目次
- MCPホスティングとは
- そもそもリモートに置く必要はあるか
- MCPホスティング6択の比較
- stdioをリモート化するブリッジはどこで動くか（mcp-remoteとの違い）
- コストの実際：GB時間で計算する
- コールドスタートとレイテンシ
- 5つの質問で選ぶ
- Claude・Cursor・自作エージェントへの接続
- 公開前チェックリスト
- よくあるハマりどころ
- NodeFlareならこう解決できる
- よくある質問（FAQ）
MCPホスティングとは
MCPホスティングとは、MCPサーバーを「クライアントが手元で起動する子プロセス」ではなく、HTTPSで到達できるネットワークサービスとして動かすことです。MCP仕様が定める標準トランスポートは2つあり、stdioは「クライアントが起動したサブプロセスの標準入出力で改行区切りのメッセージをやり取りする」方式、Streamable HTTPは「各メッセージを単一のMCPエンドポイントへHTTP POSTする」方式です。ホスティングは前者を後者に変える作業だと言えます。
必要になるのは、たとえば次のような場面です。ブラウザ版のClaudeのようにローカルのプロセスを起動できないクライアントから使いたいとき。チームや複数のエージェントで1つのサーバーを共有したいとき。PCを閉じている間もスケジュール実行のエージェントに使わせたいとき。そして、利用者全員にNode.jsやPython、Dockerを入れてもらうのが現実的でないときです。
そもそもリモートに置く必要はあるか
必ずしも必要ではありません。ローカルのstdioのほうが構成は単純で、ホスティング費用もかかりません。
| 状況 | ローカルのstdioで十分 | リモートに置く |
|---|---|---|
| 1人・1台でCursorやClaude Desktopから使う | ✅ | |
| サーバーが手元のファイルやローカルDBを読む | ✅ | |
| Web版・モバイル版のClaudeから使う | ✅ | |
| チームで1つのサーバーを共有する | ✅ | |
| スケジュール実行・バックグラウンドのエージェント | ✅ | |
| クラウド上で動く自作エージェント | ✅ | |
| ランタイムを入れられない利用者がいる | ✅ |
MCPホスティング6択の比較
主なトレードオフを表にまとめました。上限と料金は2026年10月時点の各社ドキュメントに基づきます。契約前に参考資料のリンク先で最新値を確認してください。
| 選択肢 | stdioサーバーをそのまま動かせるか | 1リクエストの上限 | アイドル中の費用 | 課金方式 | 向いているケース |
|---|---|---|---|---|---|
| VPS＋Docker（自前運用） | ブリッジを自分で入れれば可 | なし（自分で決める） | 24時間ずっと満額 | 月額固定 | 完全に制御したい、トラフィックが常にある |
| Google Cloud Run | 不可（Streamable HTTPのみ） | 既定5分、最大60分 | ゼロまで縮小すれば0 | インスタンス稼働時間 | 依存の重いコンテナ |
| Cloudflare Workers | 不可（Workers上のJS/TS） | CPU時間：Free 10ミリ秒、Paid最大5分 | 0 | リクエスト数＋CPUミリ秒 | エッジ向けに書いたTypeScriptのサーバー |
| AWS Lambda／Vercel Functions | 不可（HTTPアダプタが必要） | Lambdaは15分、Vercelはプランによる | 0 | リクエスト数＋GB秒 | すでにそこで運用しているチーム |
| Amazon Bedrock AgentCore Runtime | 不可（HTTPサーバーをコンテナで渡す） | AWSのドキュメントを参照 | メモリは回収されるまで課金 | vCPUとGBの秒課金 | AWSでエージェント基盤をそろえている |
| MCP専用のマネージドホスト | 多くは可（stdioを包んでくれる） | サービスによる | サービスによる | サービスによる | GitHubのstdioサーバーを最短で使いたい |
VPS＋Docker
サーバーを借りて、MCPサーバーをコンテナで動かし、TLS付きのリバースプロキシの後ろに置く方法です。自由度は一番高く、常にトラフィックがあるなら時間あたりの単価も安くなりがちです。その代わり、OSの更新、証明書の更新、プロセスの再起動、ログ、スケールはすべて自分の仕事になり、ツールが呼ばれていない時間もマシン代を払い続けます。
Google Cloud Run
任意のコンテナを動かせて、使っていないときはゼロまで縮小します。Googleのドキュメントには「Cloud RunはStreamable HTTPトランスポートのMCPサーバーはホストできるが、stdioトランスポートのMCPサーバーはホストできない」と明記されています。既定ではCloud RunのURLにCloud Run起動元（roles/run.invoker）のIAMロールが必要で、安全ではあるものの、Google以外のクライアントから使うには別の認証層が要ります。リクエストのタイムアウトは既定5分で、最大60分まで延ばせます。
Cloudflare Workers
TypeScriptで書いたサーバーを安く動かすならエッジのWorkersが有力です。CloudflareのAgents SDKは、新しいステートレスなサーバーには createMcpHandler() を推奨しています。Durable Objectsベースの McpAgent は非推奨扱いになっていて、ガイドでは「ワンクリックのテンプレートはまだ旧方式を使っているので新規には使わない」と注意しています。Freeプランは1日10万リクエスト、1回あたりCPU時間10ミリ秒まで。Paidプランは月5ドルからで、月1,000万リクエストと3,000万CPUミリ秒が含まれます。PythonやGoのstdioバイナリをそのまま載せることはできません。
AWS Lambda／Vercel Functions
どちらも呼び出し単位の課金でゼロまで縮小するので、ツール呼び出しが断続的に来る使い方に合います。Lambdaのタイムアウト上限は15分、Vercelの実行時間上限はプランによって変わります。いずれもデプロイするのはHTTPのMCPハンドラーで、stdioのプロセスではありません。GitHubで見つけたstdioサーバーは、先にHTTP化する必要があります。
Amazon Bedrock AgentCore Runtime
エージェントやツール（MCPサーバーを含む）をmicroVMで動かすAWSの実行基盤です。課金がエージェント向きなのが特徴で、秒単位課金に加え、LLMや外部APIの応答待ちといったI/O待ちの間はCPUが課金されません。v1の単価は1 vCPU時間あたり0.0895ドル、1 GB時間あたり0.00945ドルで、メモリは回収されるまで課金されます。AWSに統一しているチームに向いています。
MCP専用のマネージドホスト
MCP専用のホストは、GitHubリポジトリやパッケージを指定するとstdioサーバーを自動で包んでHTTPSのURLを返す、という形が一般的です。たとえばSmitheryは「STDIOサーバーをデプロイすると、こちらでラップしてHTTP経由でプロキシする」と説明しており、ステートフルなサーバーへの接続は2分間操作がないとタイムアウトするとしています。比べるときは、対応ランタイム、コールドスタートの挙動、ログ、課金方式を見てください。
stdioをリモート化するブリッジはどこで動くか（mcp-remoteとの違い）
stdioのサーバーは標準入出力でJSON-RPCを話し、リモートのクライアントはHTTPを話します。間で誰かが翻訳しなければなりません。押さえるべきは、その翻訳役がどちら側で動くかです。
| ツール・方式 | 変換の向き | 動く場所 | 使う場面 |
|---|---|---|---|
mcp-remote |
ローカルのstdioクライアント → リモートのHTTPサーバー | 利用者のPC | クライアントがローカルサーバーしか扱えないが、サーバーはすでにリモートにある |
supergateway |
stdioサーバー → SSE／Streamable HTTP／WebSocket | 自分のサーバーやコンテナ | stdioサーバーを自前でホストする |
| SDKのHTTPトランスポート | サーバー自体をHTTP対応に書き換える | デプロイ先 | コードに手を入れられ、アダプタを挟みたくない |
| ホスト内蔵のアダプタ | stdioサーバー → Streamable HTTP | ホスティング基盤 | コードを触らずにURLだけ欲しい |
mcp-remote はホスティングの道具だと誤解されがちですが、向きが逆です。stdioしか扱えないクライアント（古いClaude Desktopの設定など）から、すでにホストされているサーバーへつなぐためのものです。READMEでも「動作する概念実証」で「実験的なものとして扱うべき」とし、クライアントがリモートサーバーにネイティブ対応したら外してよいと書いています。
stdioサーバーを自前でホストするなら、ブリッジをイメージに入れ、依存はすべてビルド時にインストールします。
FROM node:22-slim
# stdioサーバーとブリッジはビルド時に入れる（起動時には入れない）
RUN npm install -g supergateway your-stdio-mcp-server
EXPOSE 8000
CMD ["supergateway", "--stdio", "your-stdio-mcp-server", "--outputTransport", "streamableHttp", "--port", "8000"]
supergateway はStreamable HTTP出力では既定でステートレスです（セッションが必要なサーバーだけ --stateful を付けます）。エンドポイントのパスはREADMEで確認し、インターネットに出す前にTLSと認証を前段に置いてください。トランスポートそのものの仕様（ヘッダー、SSEストリーム、2026-07-28版での変更点）は、MCP Streamable HTTPの解説記事にまとめています。
コストの実際：GB時間で計算する
多くの基盤は「メモリ×時間」で課金します。単位はGB時間で、1 GBのメモリを1時間動かすと1 GB時間です。1か月はおよそ730時間です。
| メモリ | 常時起動（約730時間） | 1日2時間稼働（約60時間） | 1日30分稼働（約15時間） |
|---|---|---|---|
| 256 MB | 182.5 GB時間 | 15 GB時間 | 3.75 GB時間 |
| 512 MB | 365 GB時間 | 30 GB時間 | 7.5 GB時間 |
| 1 GB | 730 GB時間 | 60 GB時間 | 15 GB時間 |
| 2 GB | 1,460 GB時間 | 120 GB時間 | 30 GB時間 |
この表から言えることは3つです。
- 1日2時間しか動かないサーバーなら、scale-to-zeroは常時起動のおよそ12分の1で済みます。MCPサーバーの多くはこの形で、エージェントを待ち、まとまったツール呼び出しに答え、また静かになります。
- 稼働時間と同じくらいメモリサイズが効きます。メモリを倍にすれば請求も倍です。Node.jsやPythonのMCPサーバーの多くは256〜512 MBで十分動くので、1 GBを選ぶ前に実測しましょう。
- 常時起動が必要なサーバーもあります。システム時刻で署名するAPI（OAuth 1.0aなど）を使うもの、上流と長時間の接続を保つもの、メモリ上にキャッシュを持つものは、一時停止からの復帰後に不具合が出ることがあります。その場合は常時起動の費用を払い、最適化はあきらめるのが正解です。
コールドスタートとレイテンシ
コールドスタートとは、最初のリクエストが来てからサーバーが応答できる状態になるまでの遅れです。MCPでは、クライアントが接続したときの tools/list が遅い、あるいは最初のツール呼び出しだけ遅い、という形で現れます。
| 遅れの内訳 | よくある原因 | 対処 |
|---|---|---|
| マシンの起動 | 新しいVMやコンテナの立ち上げ | スナップショットからの復元、または1台を温めておく |
| ランタイムの起動 | Node.js、Python、JVMの起動 | イメージを小さくする、小さなツールにJVMを使わない |
| 依存のインストール | 起動時の npx -y や uvx が毎回パッケージを取得する |
ビルド時に入れる（減らせる遅れの中で最大） |
| サーバーの初期化 | 大きなカタログの読み込み、DB接続 | 遅延読み込みにし、最初のツール呼び出し時に接続する |
最初のリクエストが済んだあとのレイテンシは、たいていMCPそのものではなく、ツールが呼ぶ上流のAPIで決まります。ツールが特定リージョンのDBやSaaSを叩くなら、サーバーもその近くに置きましょう。
5つの質問で選ぶ
- コードに手を入れられるか。入れられず、しかもstdio専用なら、MCP専用ホストか、VPS＋
supergateway。入れられるなら、どのHTTP基盤でも構いません。 - ネイティブ依存のないTypeScriptか。そうならアイドル時の費用ではCloudflare Workersが強力です。
- 1回のツール呼び出しが数分を超えるか。超えるならCloud Run（最大60分）、VPS、または上限の短くないホスト。
- 稼働しているのは1日数時間未満か。そうならscale-to-zeroのある基盤。常に一定の負荷があるなら常時起動かVPS。
- すでに特定のクラウドに寄せているか。寄せているならそのクラウドの選択肢（Cloud Run、Lambda、AgentCore）を使うと、IAM・ログ・請求が1か所にまとまります。
Claude・Cursor・自作エージェントへの接続
Claude
ProとMaxでは、設定の「コネクタ」から「カスタムコネクタを追加」を開き、サーバーのURL（多くは末尾が /mcp）を貼って「追加」を押します。TeamとEnterpriseでは、オーナーが管理者設定の「コネクタ」で追加し、メンバーは「接続」を押して使います。カスタムコネクタはベータ版で、認証は主にOAuthです。詳細設定でOAuthのクライアントIDとシークレットも指定できます。URLはインターネットから到達できる必要があり、localhost では使えません。
Cursor
プロジェクト単位なら .cursor/mcp.json、全体なら ~/.cursor/mcp.json に追加します。ヘッダーでは ${env:NAME} が展開されるので、キーをファイルに直接書かずに済みます。
{
"mcpServers": {
"my-hosted-server": {
"url": "https://example.com/mcp",
"headers": {
"Authorization": "Bearer ${env:MCP_API_KEY}"
}
}
}
}
自作エージェント
公式のTypeScript SDKを使う例です。
import { Client } from "@modelcontextprotocol/sdk/client/index.js";
import { StreamableHTTPClientTransport } from "@modelcontextprotocol/sdk/client/streamableHttp.js";
const transport = new StreamableHTTPClientTransport(new URL("https://example.com/mcp"), {
requestInit: { headers: { Authorization: `Bearer ${process.env.MCP_API_KEY}` } },
});
const client = new Client({ name: "my-agent", version: "1.0.0" });
await client.connect(transport);
console.log(await client.listTools());
公開前チェックリスト
- [ ] HTTPSの単一エンドポイント（例：
/mcp）でStreamable HTTPに応答する - [ ] 依存はビルド時に入れており、起動時の
npx -yやuvxに頼っていない - [ ] シークレットは環境変数で渡し、ビルド引数やイメージのレイヤーに入れていない
- [ ] ツールに届く前に呼び出し元を認証している
- [ ] 一番長いツール呼び出しが基盤のタイムアウト内に収まる
- [ ] 状態をプロセスのメモリだけに持っていない（持つなら1台に固定している）
- [ ] メモリサイズを推測ではなく実測で決めた
- [ ] どのツールがなぜ失敗したか分かるリクエストログがある
- [ ] 月の支出上限かアラートを設定した
- [ ] curlだけでなく、実際のクライアント（Claude、Cursor、自作エージェント）からURLを試した
よくあるハマりどころ
| 症状 | 考えられる原因 | 対処 |
|---|---|---|
| Claudeが「接続できない」と言う | URLが localhost やプライベートネットワーク内 |
公開されたHTTPSのURLにデプロイする |
| 毎回、最初の呼び出しだけ数秒以上かかる | 起動時にパッケージをダウンロードしている | 依存をイメージに焼き込む |
接続時に 404 が返る |
クライアントは /、サーバーは /mcp で待っている（またはその逆） |
エンドポイントのパスを完全に一致させる |
| 1台では動くが、台数を増やすと壊れる | セッションの状態をメモリに持っている | ツールをステートレスにするか、状態を外部に置く |
| 長いツール呼び出しが途中で切れる | 基盤のタイムアウトやCPU上限 | 上限の長い基盤へ移すか、処理を分割する |
| 進捗がまとめて最後に届く | リバースプロキシがSSEをバッファしている | MCPのルートだけレスポンスのバッファリングを切る |
| 1日は動くが、その後に認証エラーになる | 一時停止・復帰で時刻に依存する署名がずれる | そのサーバーだけ常時起動にする |
NodeFlareならこう解決できる
NodeFlareは、stdioベースのMCPサーバーをコードを変えずに認証付きのクラウドURLへ変えるMCPホスティングサービスです。この記事で挙げた課題ごとに、対応する機能を並べます。
| この記事で挙げた課題 | NodeFlareでの解決策 |
|---|---|
| サーバーがstdio専用 | GitHubリポジトリを選ぶだけ（モノレポのサブディレクトリも可）。Dockerfileは不要。内蔵のstdioアダプタがStreamable HTTPと旧来のHTTP+SSEで公開する |
| 本当にデプロイできたのか分からない | ビルダーがFirecrackerのmicro-VMでサーバーを起動し、MCPの initialize ハンドシェイクを確認してから「Succeeded」にする |
| 対応ランタイム | Node.js、Python、Go、Rust、Java（Maven／Gradle、Kotlin）、C#／.NET、Docker。BunとDenoも認識する |
| アイドル時間にお金を払っている | scale-to-zero。アイドル中のサーバーはスナップショットを取って停止し、その間は0円。復帰は1秒未満 |
| 温めておく必要があるサーバー | 常時起動（Always-on、Pro以上）でウォームなレプリカを1つ保つ |
| GB時間のコスト | コンピュートは稼働中だけ1 GB時間あたり5円。メモリは256 MB／512 MB／1 GB／2 GBから選べ、約1か月の使用量を見て小さいサイズを提案するライトサイジング機能もある（メモリ不足が出たら自動で元に戻る） |
| 想定外の請求 | 月の支出上限に達するとHTTP 402 を返して止める |
| 再起動で消えては困る状態 | オプションの永続ディスク（1 GB月あたり15円）。scale-to-zeroや再デプロイ後も残る |
| スケール | 同時実行数に応じた水平オートスケール。セッションアフィニティ付き |
| どのツールが失敗したか | リクエストごとに mcp_method、tool_name、http_status、duration_ms などを記録。保持期間はFreeが7日、Pro／Teamが30日 |
| クライアントとの接続 | 末尾が /mcp のHTTPS URLに、mcp_ で始まるAPIキーをBearerで付けて接続。OAuthのディスカバリー（RFC 8414／RFC 9728）にも対応 |
料金はシンプルです。Freeは0円で、MCPサーバー1つと月30 GB時間のコンピュートが付きます。Proは月2,980円で、サーバー数無制限、コンピュート300 GB時間とストレージ10 GBが込みになり、カスタムドメインやマネージドブラウザも使えます。256 MBで1日2時間動くサーバー（月約15 GB時間）なら、無料枠に収まります。
始め方は3ステップです。
- nodeflare.techにログインし、GitHubリポジトリ（またはExploreのテンプレート）を選ぶ。
- 環境変数を入れてデプロイし、「Succeeded」になるのを待つ。
- 表示された
/mcpのURLを、Claude・Cursor・自作エージェントに貼る。
1サーバーまで無料で試せます → nodeflare.tech
よくある質問（FAQ）
MCPホスティングとは何ですか？
MCPサーバーを手元の子プロセスとしてではなく、リモートのHTTPSサービスとして動かすことです。Claude、Cursor、自作エージェントなどのクライアントは、そのURLにStreamable HTTPで接続します。
MCPサーバーはホスティングすべき？ローカルで十分？
1人でデスクトップのクライアントから使うだけなら、ローカルのstdioで十分です。Web版やモバイル版のクライアント、チームでの共有、スケジュール実行やクラウド上のエージェントから使うなら、ホスティングが必要です。
stdioのMCPサーバーをリモートで使えますか？
使えますが、stdioをStreamable HTTPに変換するブリッジが必要です。supergateway などを自分で動かすか、stdioサーバーを自動で包んでくれるMCPホストを使います。Cloud Run、Workers、Lambdaはstdioサーバーを直接は動かせません。
mcp-remoteでMCPサーバーをホスティングできますか？
できません。mcp-remote は利用者のPC上で動き、stdioしか扱えないクライアントを、すでにリモートにあるサーバーへつなぐための道具です。ローカルのサーバーを他人から使えるようにするものではありません。
MCPサーバーを一番安くホストする方法は？
1日の大半がアイドルなら、無料枠のあるscale-to-zeroの基盤がたいてい最安です。費用は「メモリ×稼働時間」で決まるので、メモリを小さく保ち、必要がなければ常時起動にしないことが効きます。
MCPサーバーは無料でホストできますか？
条件付きでできます。Cloudflare WorkersのFreeプランは1日10万リクエストまで使え、MCP専用ホストにも1サーバー分の無料枠を用意しているところがあります。CPU時間、実行時間、月のコンピュート上限が自分のツールに足りるかを確認してください。
MCPにはCloudflare WorkersとCloud Runのどちらがいい？
軽量なTypeScriptのサーバーで、アイドル時の費用や世界中からの近さを重視するならWorkersです。ネイティブ依存のあるコンテナ、TypeScript以外の言語、ミリ秒ではなく分単位のCPUが要るツールならCloud Runが向いています。
ホストしたMCPサーバーをClaudeにつなぐには？
設定の「コネクタ」から「カスタムコネクタを追加」を開き、サーバーのURLを貼ります。カスタムコネクタはPro、Max、Team、Enterpriseプランで使え、URLはインターネットから到達できる必要があります。
ホストしたMCPサーバーをCursorにつなぐには？
.cursor/mcp.json または ~/.cursor/mcp.json に、url と必要に応じて headers を書いたエントリを追加します。ヘッダーでは ${env:NAME} を使えば、APIキーをファイルに残さずに済みます。
MCPサーバーのコールドスタートを避けるには？
依存は起動時ではなくビルド時に入れ、初期化は遅延させ、スナップショット復元の速い基盤を選びます。最初の呼び出しを必ず即答させたいなら、1台を温めておき、常時起動の費用を受け入れます。
まとめ
2026年のMCPホスティングは、プロトコルに対応しているかどうかより、相性で選ぶ時代になりました。ステートレスなStreamable HTTPはどのHTTP基盤でも配信できるからです。stdio専用のサーバーならブリッジか、それを内蔵したホストが要ります。ツール呼び出しが長いならタイムアウトに注意し、ほとんどアイドルならscale-to-zeroと小さめのメモリで費用を1桁下げられます。GB時間の表で費用を見積もり、公開前にチェックリストを確認してから、URLをClaude・Cursor・自作エージェントにつなぎましょう。
