MCPサーバーのレイテンシを実測：往復回数・リージョン・プロトコル版で呼び出しはどれだけ変わるか【MCP Hosting・2026年】
起動済みのMCPサーバーで1回の呼び出しはどこに時間を使うのか。MCP Python SDK 2.3.0で実測した往復回数（旧ハンドシェイク4回・server/discover 3回・2026-07-28固定2回）、ttlMsのキャッシュ効果、Azureのリージョン間RTT、Claudeコネクタの発信元、利用者と接続先APIのどちらの近くに置くかの判断基準を解説。
最終更新：2026年10月20日 ／ 対象：MCP仕様 2026-07-28 と2025年版（セッションあり）のサーバー。計測は2026年10月20日、MCP Python SDK 2.3.0（クライアントと
MCPServer）、Node.js 22.22.0、往復80msを再現する遅延プロキシで実施。リージョン間の数値はMicrosoftが公開しているAzureのP50実測値（2026年7月30日までの30日間）
結論（30秒で読める要約）
MCPサーバーのレイテンシとは、クライアントが1回のMCPリクエストの結果を受け取るまでの待ち時間です。起動済み（ウォーム）のサーバーでは、その大半はネットワークで決まります。「往復回数 × 往復時間（RTT）」に、ツールが外部APIやDBを呼ぶ時間を足したものです。MCP Hostingで自分で動かせるのは、1回の呼び出しに必要な往復回数と、1往復の距離の2つです。
- プロトコルのバージョンで往復回数が変わります。今回の計測では、新しく接続したクライアントが最初のツール結果を得るまでの直列のHTTP往復は、旧来のハンドシェイクで4回、2026-07-28の
server/discover確認ありで3回、2026-07-28を固定指定すると2回でした。RTT 80msでは、それぞれ489ms、394ms、307msです。 - 接続後は、どの方式でも1呼び出し＝1往復です。ウォーム状態の
tools/callはRTT 80msで87〜88msでした。あとは距離だけで決まります。AzureではEast US→Japan Eastが162ms、West Europe→Japan Eastが233msです。 ttlMsで一覧の再取得を省けます。tools/listにttlMs: 300000を付けると、2026-07-28のクライアントは2回目の一覧をキャッシュから0msで返しました。既定値の0のままだと毎回サーバーに問い合わせます（88ms）。- サーバーは「直列の往復が多い側」の近くに置きます。DBに5回続けてクエリを投げるツールなら、利用者ではなくDBの隣に置く方が速くなります。6章の例では約202ms対約810msでした。
- リクエストの発信元を把握します。Claude CodeやCursorは利用者のPCから接続します。Claudeのカスタムコネクタと Claude API の MCP connector はAnthropicのクラウド（送信元
160.79.104.0/21）から接続し、そのリージョンは公開されていません。
往復回数の表は3章、リージョン間の表は4章、配置の考え方は6章にあります。
目次
- MCPサーバーのレイテンシとは
- レイテンシの計算式
- 実測：プロトコルのモード別の往復回数
- 距離：リージョン間の往復時間
- MCPのリクエストはどこから来るか
- MCP Hostingの配置：利用者の近くか、接続先APIの近くか
- MCPのレイテンシを減らす9つの方法
- 自分の経路を計測する
- チェックリスト
- よくあるハマりどころ（症状→原因→対処）
- NodeFlareならこう解決できる
- FAQ
1. MCPサーバーのレイテンシとは
MCPサーバーのレイテンシとは、クライアントが tools/call などのMCPリクエストを送ってから、結果をすべて受け取るまでの時間です。クライアントとサーバーの間の往復、接続の確立、サーバー自身の処理、ツールが呼ぶ外部サービスとのやり取りがすべて含まれます。
この記事で扱うのは、サーバーが起動済みで、ツールが数秒以内に終わる場合です。しばらく使っていないサーバーの初回が遅い問題は MCPサーバーの初回呼び出しはなぜ遅い？ で、数分かかるツールの問題はタイムアウトの記事で扱っています。
モデルの応答に数秒かかるのに、数十ミリ秒を気にする理由は、エージェントがツールを続けて呼ぶからです。ツール呼び出し1回ごとに、モデルの1ターンとMCPの往復が発生します。20回呼ぶエージェントは、そのオーバーヘッドを20回払います。1呼び出しあたり4往復、RTT 83ms（East US↔West Europe）なら、20 × 4 × 83 ≈ 6.6秒がネットワークだけで消えます。1往復なら約1.7秒です。
2. レイテンシの計算式
ツール呼び出し1回のレイテンシは、おおよそ次の式で表せます。
latency ≈ setup_RTTs × RTT(client↔server)
+ mcp_RTTs × RTT(client↔server)
+ server_time
+ upstream_RTTs × RTT(server↔upstream) + upstream_time
| 項目 | 内容 | 目安 |
|---|---|---|
setup_RTTs |
新しいTCP接続（1往復）とTLS 1.3のハンドシェイク（1往復、RFC 8446） | 新規接続で2、接続を使い回せば0 |
mcp_RTTs |
結果が返るまでの直列のMCPのHTTP往復 | 1〜4（3章） |
server_time |
サーバーの処理時間とブリッジのオーバーヘッド | 単純なツールなら数ms。POSTごとにプロセスを起動するstatelessブリッジは、コールドスタートの記事の計測で1リクエストあたり約194ms |
upstream_RTTs |
ツールが外部APIやDBに順番に投げる呼び出しの数 | 0〜数十 |
この式から2つのことが分かります。1つ目は、RTTが掛け算で効くので、往復回数を半分にする方がサーバーのコードを速くするより効く場合があることです。2つ目は、RTTが「クライアント↔サーバー」と「サーバー↔接続先」の2種類あり、サーバーの置き場所で短くできるのはどちらか一方だけだということです。
3. 実測：プロトコルのモード別の往復回数
2026-07-28の仕様では initialize と notifications/initialized のハンドシェイク、およびプロトコルレベルのセッションが廃止されました。最初のリクエストでいきなりツールを呼べます。changelogには、各リクエストが「プロトコルのバージョンとクライアントの機能を _meta に含める」と書かれています。ただし、実際にハンドシェイクを省くかどうかはクライアントのモードしだいです。
MCP Python SDK 2.3.0 をクライアントとサーバーの両方に使って計測しました。クライアントの mode は、"legacy"（initializeハンドシェイク）、"auto"（既定。server/discover を確認し、古いサーバーならハンドシェイクに戻る）、"2026-07-28" のようなバージョン固定の3種類です。間にNode.jsのプロキシを置き、HTTPのやり取りごとに片道40ms（往復80ms）の遅延を入れて、リクエストを記録しました。手順は「接続→ツール一覧→ツール呼び出し→もう一度一覧と呼び出し」で、値は3回の中央値です。TCPとTLSの確立は再現していない（ローカルのHTTP）ので、実際の新規接続ではさらに約2往復かかります。
| クライアントのモード | 送られたHTTPリクエスト（順番） | 最初の結果までの直列の往復 | RTT 80msで最初の結果まで | 遅延0msの場合 | ウォームの tools/call |
|---|---|---|---|---|---|
legacy（セッションあり） |
initialize、notifications/initialized、GETストリーム、tools/list、tools/call、終了時に DELETE |
4 | 489ms | 164ms | 87ms |
auto（既定） |
server/discover、tools/list、tools/call |
3 | 394ms | 162ms | 88ms |
2026-07-28 を固定 |
tools/list、tools/call |
2 | 307ms | 147ms | 88ms |
遅延0msの列を引くと、ネットワーク分は325ms、232ms、160msです。ちょうど80msの往復が4回、3回、2回分です。legacy ではセッションを閉じるときの DELETE にもさらに87msかかりました。
次に、サーバー側にキャッシュのヒント（cache_hints={"tools/list": CacheHint(ttl_ms=300_000)}）を付け、tools/list が ttlMs: 300000 を返すようにしました。
| クライアントのモード | 2回目の tools/list（既定の ttlMs: 0） |
2回目の tools/list（ttlMs: 300000） |
|---|---|---|
legacy |
88ms（リクエスト送信） | 88ms（リクエスト送信。旧方式ではキャッシュされない） |
auto |
86ms（リクエスト送信） | 0ms（クライアントのキャッシュから返り、送信なし） |
2026-07-28 を固定 |
89ms（リクエスト送信） | 0ms（クライアントのキャッシュから返り、送信なし） |
数字から言えること：
- サーバーが2026-07-28に対応していれば、クライアントは新規接続ごとに1〜2往復を省けます。最初に確認する
autoなら1往復、バージョンが分かっているクライアントなら2往復です。 ttlMsはキャッシュのヒントであると同時に、レイテンシの設定でもあります。Python SDKのクライアントは既定でこれに従います。一方、SDKのサーバー側の既定値はttl_ms = 0（すぐに古くなる扱い）なので、自分で設定する必要があります。- 接続した後は、どのモードも1呼び出し＝1往復で同じです。差が出るのは接続のときで、エージェントやクラウドのコネクタが一番よく繰り返すのがまさにこの部分です。
計測に使ったスクリプトは短いので、そのまま使えます。
# client.py - time connect, list and call through any MCP URL
import asyncio, sys, time
from mcp import Client
async def main(url: str, mode: str) -> None:
t0 = time.perf_counter()
async with Client(url, mode=mode) as c: # "legacy", "auto" or "2026-07-28"
t1 = time.perf_counter(); await c.list_tools()
t2 = time.perf_counter(); await c.call_tool("echo", {"text": "hi"})
t3 = time.perf_counter(); await c.call_tool("echo", {"text": "hi"})
t4 = time.perf_counter()
ms = lambda a, b: round((b - a) * 1000)
print(f"{mode}: connect={ms(t0,t1)} list={ms(t1,t2)} first_call={ms(t2,t3)} warm_call={ms(t3,t4)} ms")
asyncio.run(main(sys.argv[1], sys.argv[2]))
なお、Pythonクライアントの最初の call_tool は、手元の処理だけで約50msかかりました（遅延0msでも53〜55ms）。すべてをネットワークのせいにする前に、自分のクライアントも測ってください。
4. 距離：リージョン間の往復時間
1往復のコストは2台のマシン間のRTTで、RTTはほぼ物理的な距離で決まります。MicrosoftはAzureのリージョン間の往復時間の実測値（30日間のP50、2026年7月30日まで）を公開しています。設計の目安として使えます。実際の値は利用するクラウドによって多少異なります。
| 区間 | P50のRTT | ウォームの1呼び出し（1往復） | 旧方式で新規接続＋呼び出し（接続2＋MCP 4往復） | 2026-07-28固定で新規接続＋呼び出し（2＋2往復） |
|---|---|---|---|---|
| East US → East US 2 | 8ms | 8ms | 48ms | 32ms |
| West Europe → UK South | 11ms | 11ms | 66ms | 44ms |
| Japan East → Korea Central | 29ms | 29ms | 174ms | 116ms |
| East US → West US | 69ms | 69ms | 414ms | 276ms |
| Japan East → Southeast Asia | 72ms | 72ms | 432ms | 288ms |
| East US → West Europe | 83ms | 83ms | 498ms | 332ms |
| West US → Japan East | 108ms | 108ms | 648ms | 432ms |
| East US → Japan East | 162ms | 162ms | 972ms | 648ms |
| East US → Australia East | 201ms | 201ms | 1,206ms | 804ms |
| East US → Southeast Asia | 224ms | 224ms | 1,344ms | 896ms |
| West Europe → Japan East | 233ms | 233ms | 1,398ms | 932ms |
右の2列はネットワークの時間だけです。同じサーバーが、ある場所からは一瞬で、別の場所からは重く感じる理由がここにあります。東京からバージニアのサーバーへ旧方式で新規接続すると、ツールが動く前にネットワークだけで約1秒かかります。日本の利用者が多いのに、何も考えずに米国東部へデプロイしているなら、まず確認したいポイントです。
5. MCPのリクエストはどこから来るか
配置で考えるべき「クライアント」は、HTTP接続を開くマシンです。それは必ずしも利用者のPCではありません。デスクトップやCLIのクライアントは利用者の手元から、クラウドのコネクタは提供元のインフラから接続します。
| 呼び出し元 | 発信元 | 場所について分かること | 配置の目安 |
|---|---|---|---|
| Claude Code、Cursor、VS Code、Codex CLI、Gemini CLI | 利用者のPC | 利用者のいる場所 | 利用者の近く、または接続先APIの近く（6章） |
| Claudeのカスタムコネクタ（Web・デスクトップ・モバイル） | Anthropicのクラウド | 送信元IPv4 160.79.104.0/21 は「外部サーバーへのMCPツール呼び出し」に使うと公開されているが、リージョンは非公開 |
不明。サーバーのログで測る（8章） |
| Claude API の MCP connector | Anthropicのクラウド | 同上 | 同上 |
| ChatGPTのアプリ・コネクタ | OpenAIのクラウド | リージョンは非公開 | 測る |
| 自作のエージェント | エージェントを動かす場所 | 自分で決められる | エージェント、MCPサーバー、接続先を同じリージョンに置く |
MCP Hostingで押さえたいこと：
- 自作のエージェントなら、すべてを同じ場所に置きます。エージェントがフランクフルト、サーバーがバージニアなら、ツール呼び出しのたびに83msの往復を無駄に払うことになります。
- ベンダーのコネクタは推測しないでください。リクエストごとに送信元IPとサーバー側の処理時間を記録し、利用者の体感と比べます。クライアントごとの接続方法は リモートMCPクライアント設定チートシート にまとめています。
6. MCP Hostingの配置：利用者の近くか、接続先APIの近くか
MCPサーバーは、直列の往復が多い側の近くに置きます。クライアントとの往復は通常1呼び出しにつき1回です。一方、依存関係のあるクエリやAPI呼び出しを続けて行うツールは、接続先と何度も往復します。こちらの方が大きくなるのが普通です。
Azureの数値で計算してみます。東京の利用者が、East USのDBに5回続けてクエリを投げるツールを呼ぶ場合です。
| サーバーの場所 | クライアント↔サーバー（1往復） | サーバー↔DB（直列で5往復） | 1呼び出しのネットワーク合計 |
|---|---|---|---|
| Japan East（利用者の近く） | 数ms | 5 × 162 = 810ms | 約810ms＋数ms |
| East US 2（DBの近く） | 約162ms | 5 × 8 = 40ms | 約202ms |
利用者から遠ざけた方が4倍速くなりました。判断の目安は次のとおりです。
| 状況 | サーバーを置く場所 |
|---|---|
| ツールが1つの接続先に2回以上続けて呼び出す | その接続先の近く |
| ツールが計算だけ、または接続先を1回呼ぶだけ | 呼び出し元の近く（接続先の近くでもほぼ同じ） |
| 複数リージョンの接続先を呼ぶ | 直列の呼び出しが一番多い接続先の近く。残りは並列化する |
| 呼び出し元が世界中にいて、ツールに接続先がない | 利用者が一番多い地域の近く。そのうえで往復を減らす（7章） |
| 呼び出し元がベンダーのクラウドコネクタ | 接続先の近く（呼び出し元のリージョンは不明なので） |
| 頻繁に再接続する旧方式のクライアント | 先に往復を減らす（7章）。距離はその回数分だけ効く |
サーバーの前にゲートウェイやプロキシを置く場合、それも1つの中継点です。ゲートウェイはサーバーと同じリージョンに置かないと、毎回その距離を往復分余計に通ることになります。
7. MCPのレイテンシを減らす9つの方法
MCPのレイテンシ対策は、ほとんどが「往復を1つ減らす」か「1往復を短くする」かのどちらかです。効く場面が多い順に並べます。
| # | 対策 | 減らせるもの | 誰がやるか |
|---|---|---|---|
| 1 | サーバーをMCP 2026-07-28に対応させ、クライアントがハンドシェイクを省けるようにする | 新規接続ごとに1〜2往復（3章） | サーバー |
| 2 | tools/list に実際の ttlMs を返す（ツール構成が安定しているなら300,000msなど） |
一覧の再取得1回につき1往復 | サーバー |
| 3 | MCPクライアントとHTTP接続をツール呼び出しの間で使い回す | 1呼び出しごとの2往復（TCP＋TLS）とプロトコルの準備 | クライアント・エージェント |
| 4 | 両端を自分で管理しているなら、自作エージェントでバージョンを固定する | auto と比べて接続ごとに1往復 |
クライアント・エージェント |
| 5 | Claude APIでは mcp-client-2026-09-15 を送り、mcp_tool_listing ブロックをそのまま返す。公式ドキュメントによれば、以降のリクエストは記録済みの一覧を使い、サーバーに再度問い合わせない |
APIリクエストのたびの一覧取得 | エージェント |
| 6 | ツールが接続先を続けて呼ぶなら、接続先の近くに置く（6章） | （接続先との往復数 − 1）× RTT | 配置 |
| 7 | ツール内で依存関係のない外部呼び出しを並列に実行する | （n − 1）回分の接続先との往復 | サーバーのコード |
| 8 | リクエストごとにプロセスを起動するstatelessブリッジを避け、statefulブリッジかネイティブHTTPを使う | 毎回のランタイム起動（コールドスタートの計測で194ms） | サーバー |
| 9 | 細かすぎるツールをまとめる。get_order と get_item × 5ではなく get_order_with_items を1つ用意する |
モデルのターンとその往復を丸ごと | ツール設計 |
9番はネットワークの設定ではないので見落とされがちですが、たいてい一番効きます。ツール呼び出しが1回増えるごとに、往復（ミリ秒）だけでなくモデルの1ターン（秒）が増えるからです。
主なstdioブリッジ（supergateway、mcp-proxy）のプロセスの扱いの違いは、stdioのMCPサーバーをリモートで動かす手順の記事で比べています。
8. 自分の経路を計測する
呼び出し元の場所から段階ごとに測り、サーバー側の処理時間と比べます。curlを使えば、新規接続での1リクエストを段階ごとに分けて表示できます。
# probe.sh - one 2026-07-28 tools/call on a new connection, phase by phase
curl -s -o /dev/null -X POST "$MCP_URL" \
-w 'dns=%{time_namelookup}s tcp=%{time_connect}s tls=%{time_appconnect}s first_byte=%{time_starttransfer}s total=%{time_total}s status=%{http_code}\n' \
-H "Authorization: Bearer $MCP_API_KEY" \
-H 'Content-Type: application/json' \
-H 'Accept: application/json, text/event-stream' \
-H 'MCP-Protocol-Version: 2026-07-28' \
-H 'Mcp-Method: tools/call' -H 'Mcp-Name: echo' \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"echo","arguments":{"text":"hi"},
"_meta":{"io.modelcontextprotocol/protocolVersion":"2026-07-28",
"io.modelcontextprotocol/clientInfo":{"name":"probe","version":"1"},
"io.modelcontextprotocol/clientCapabilities":{}}}}'
このリクエストをPython SDK 2.3.0のサーバーに送ると200が返りました。MCP-Protocol-Version ヘッダーを外すと、同じサーバーは旧方式のリクエストとして扱い、400「Missing session ID」を返しました。echo は、自分のサーバーにある軽い読み取り専用ツールに置き換えてください。
結果の読み方：
| 結果 | 意味 |
|---|---|
tcp が約1往復、tls が約2往復 |
通常の新規接続。接続を使い回せば毎回は払わない |
first_byte − tls が約1往復 |
サーバーはほぼ即答している。遅さの原因は距離 |
first_byte − tls が1往復よりずっと大きい |
サーバーの処理か接続先の呼び出しが原因。サーバー側の処理時間を確認する |
dns が大きい |
呼び出し元のDNSの問題で、サーバーの問題ではない |
次に、サーバー側の取り分を切り分けます。サーバーでリクエストごとの処理時間（受信から最後のバイトの送信まで）を記録します。クライアントで測った時間からサーバーの記録を引いた分が、おおよそのネットワークの時間です。ベンダーのコネクタのように呼び出し元でcurlを実行できない場合は、サーバーのログが唯一の手がかりです。送信元IPと処理時間を記録し、リージョンを変えたときの変化を見てください。
旧方式のハンドシェイクのコストを知りたい場合は、3章のPythonスクリプトを自分のURLに対して mode="legacy" と mode="2026-07-28" で実行します。その差が、新規接続のたびにクライアントが払っている時間です。
9. チェックリスト
- [ ] 主な呼び出し元がどこから接続するか（利用者のPC、Anthropicのクラウド、OpenAIのクラウド、自作エージェントのリージョン）を把握している
- [ ] 遅いツールの直列の外部呼び出しを数え、一番多い接続先の近くにサーバーを置いた
- [ ] サーバーがMCP 2026-07-28に対応しており、新しいクライアントはハンドシェイクを省ける
- [ ]
tools/listが、ツール構成の変更頻度に合った0以外のttlMsを返す - [ ] 自作エージェントはタスクごとにMCPクライアントを1つ使い回し、HTTP接続を維持している
- [ ] 2026-07-28対応と分かっているサーバーには、自作エージェントでバージョンを固定している
- [ ] Claude APIのエージェントは
mcp-client-2026-09-15を送り、mcp_tool_listingブロックをそのまま返している - [ ] ツール内の依存関係のない外部呼び出しは並列に実行している
- [ ] 起動の遅いサーバーの前で、リクエストごとにプロセスを起動するstatelessブリッジを使っていない
- [ ] サーバーの前のゲートウェイは同じリージョンにある
- [ ] 呼び出し元のリージョンからcurlで計測し、サーバー側でリクエストごとの処理時間を記録している
10. よくあるハマりどころ（症状→原因→対処）
| 症状 | 原因 | 対処 |
|---|---|---|
| どのツールでも同じくらい遅い | 距離。遠いリージョンへ1呼び出しごとに1往復している | サーバーを呼び出し元に近づけるか、エージェントを同じ場所に置く |
| 会話の最初の呼び出しだけ遅く、後は速い | 接続の確立とハンドシェイク（旧方式の新規接続で最大6往復） | 2026-07-28に対応する。自作エージェントでバージョンを固定し、接続を使い回す |
ログで毎回の呼び出しの前に tools/list がある |
クライアントが毎回一覧を取りに来ている。ttlMs が0か、旧方式のクライアント |
実際の ttlMs を返す。Claude APIでは記録済みの mcp_tool_listing を返す |
| 特定のツールだけ遅い | リージョンをまたいだ直列の外部呼び出し | その接続先の近くに置くか、呼び出しを並列化する |
| 自分のPCからは速いが、Claudeのカスタムコネクタからは遅い | リクエストはPCではなくAnthropicのクラウドから来ている | サーバー側で測る。サーバーは接続先の近くに置く |
| 同じリージョン内でも毎回200msほど余計にかかる | statelessブリッジがリクエストごとにプロセスを起動している | statefulブリッジかネイティブのStreamable HTTPを使う |
| ゲートウェイを入れたらレイテンシが倍になった | ゲートウェイがサーバーと別のリージョンにある | ゲートウェイをサーバーと同じリージョンに置く |
| curlの計測が400「Missing session ID」になる | 旧方式にも対応したサーバーに、MCP-Protocol-Version: 2026-07-28 なしで送った |
ヘッダーと _meta を付けるか、旧方式のハンドシェイクを行う |
| ウォーム時は速いが、しばらく空いた後の1回目が数秒かかる | レイテンシではなくコールドスタート | MCPサーバーの初回呼び出しはなぜ遅い？ を参照 |
11. NodeFlareならこう解決できる
NodeFlareは、GitHubリポジトリのMCPサーバーを、stdio専用のものも含めて https://<your-server>.nodeflare.tech/mcp のHTTPSエンドポイントとしてデプロイするMCP Hostingサービスです。この記事で挙げた課題には、次のように対応しています。
| この記事の課題 | NodeFlareでの対応 |
|---|---|
サーバーへの tools/list の往復が繰り返される |
読み取り専用の一覧メソッド（tools/list、resources/list、prompts/list）をプロキシでキャッシュし、重複をまとめる。tools/list は最大24時間キャッシュされ、キャッシュキーには呼び出し元のIDが含まれる |
| 認証の確認が毎回のリクエストの負担になる | mcp_* のAPIキーはハッシュ化され、Redisに5分間キャッシュされる。有効なキーを毎回一から照会しない |
| 旧方式のクライアントで、セッションが同じプロセスに届く必要がある | 各サーバーへのリクエストは専用のVMに送られ、initialize で発行された Mcp-Session-Id もそのまま渡される |
| 新旧のクライアントが同じエンドポイントを使う | Streamable HTTPと旧来のHTTP+SSE（2024-11-05）の両方に対応 |
| stdioのサーバーにはブリッジが必要 | 同梱のアダプター（stdio-adapter.cjs）がサーバーを子プロセスとして起動し、HTTPで公開する。言語を問わず使え、クラッシュ時は1秒から30秒の間隔を空けて再起動する |
| ネットワークの時間とサーバーの時間を切り分けたい | すべてのリクエストを duration_ms、client_ip、user_agent、mcp_method、tool_name、req_bytes、res_bytes 付きで記録。1時間・24時間・7日・30日の範囲で検索できる（Freeは1時間固定）。保存期間はFreeで7日、ProとTeamで30日 |
| アイドル後の起動がレイテンシに上乗せされる | アイドル状態のサーバーはスナップショットから1秒未満で復元される。Always-On（Pro以上）なら1台を常に起動しておける |
| メモリ不足でツールが遅い | メモリは256MB、512MB、1GB、2GBから選べ、約1か月の使用量からサイズの推奨が出る |
ドキュメントに書かれていないこと：NodeFlareのドキュメントには、デプロイ先のリージョンは記載されていません。8章のcurlの計測を、呼び出し元の場所からNodeFlareのURLに対して実行し、リクエストログの duration_ms と比べれば、レイテンシのうちどれだけが距離によるものかが分かります。
料金：Freeプランは¥0で、MCPサーバー1台、月30 GB時間のコンピュートが使えます。Proは月額¥2,980で、サーバー数無制限、300 GB時間のコンピュートと10GBのストレージを含みます。超過分のコンピュートは1 GB時間あたり¥5で、外向き通信（egress）は課金されません。
最小の始め方：
- nodeflare.tech にGitHubでサインインし、MCPサーバーのリポジトリを選ぶ。
- デプロイする。NodeFlareは実際のMCPの
initializeが通ることを確認してから公開する。 /mcpのURLに8章の計測を実行し、ログのduration_msと比べる。
1サーバーまで無料で試せます → nodeflare.tech
12. FAQ
MCPサーバーのレイテンシとは？
MCPクライアントが tools/call などのリクエストを送ってから、結果をすべて受け取るまでの時間です。起動済みのサーバーでは、大半が「往復回数 × 往復時間」と、ツールが行う外部呼び出しの時間で決まります。サーバー自身の処理は数ミリ秒であることも多いです。
MCPのツール呼び出しは何往復かかる？
接続した後は、1呼び出しにつきHTTPの1往復です。新規接続では、TCPとTLSの確立（約2往復）に加え、プロトコルのモードによって最大3回のMCPのやり取りが増えます。今回の計測では、旧方式の新しいクライアントは最初の結果までに直列で4往復、2026-07-28を固定したクライアントは2往復でした。
MCP 2026-07-28でMCPは速くなる？
接続時の往復が減ります。initialize のハンドシェイクとセッションが廃止されたので、バージョンが分かっているクライアントは最初のリクエストでツールを呼べます。今回のRTT 80msの計測では、最初の結果までが489msから307msに縮みました。接続後の呼び出しの速さはどのバージョンでも同じです。
MCPサーバーはどこにホスティングすべき？
直列の往復を一番多く交わす相手の近くです。多くの場合、それは利用者ではなく、ツールが呼ぶDBやAPIです。ツールに接続先がなければ、呼び出し元が一番多い地域の近くに置きます。クラウドのコネクタは提供元のインフラから接続する点にも注意してください。
Claudeのコネクタからのリクエストはどこから来る？
Claudeのカスタムコネクタと Claude API の MCP connector は、Anthropicのクラウドからサーバーに接続します。送信元のIPv4アドレス範囲は 160.79.104.0/21 です。これらのリクエストのリージョンは公開されていません。Claude Codeは違い、利用者のPCから接続します。
Claude CodeやCursorでもサーバーのリージョンは関係ある？
関係あります。どちらも利用者のPCから直接接続するため、ツール呼び出しのたびに利用者とサーバーの間のRTTがかかります。東京の利用者なら、East USのサーバーは1呼び出しあたり約162ms、日本のサーバーなら数ミリ秒です。
ttlMsはレイテンシにどう効く？
tools/list の結果に付く ttlMs は、2026-07-28のクライアントにその一覧をどれだけ使い回してよいかを伝えます。今回の計測では、ttlMs: 300000 を受け取ったクライアントは、次の一覧をリクエストを送らずにキャッシュから0msで返しました。MCP Python SDKのサーバーは既定で0なので、明示的に設定してください。
stdioからHTTPへのブリッジはレイテンシを増やす？
statefulなブリッジは、プロセスが起動していればほとんど増やしません。POSTごとに新しいプロセスを起動するstatelessなブリッジは、毎回ランタイムの起動分がかかります。コールドスタートの記事の計測では、小さなNode.jsサーバーで1リクエストあたり約194msでした。レイテンシが重要なツールにはstatefulモードかネイティブのStreamable HTTPを使ってください。
MCPのレイテンシはどう測る？
呼び出し元の場所から curl -w で tools/call を実行し、DNS・TCP・TLS・最初のバイトまでの時間を見ます。同時にサーバー側でリクエストの処理時間を記録し、その差をネットワークの時間とみなします。旧方式のオーバーヘッドは、同じURLに対して旧方式と2026-07-28固定のクライアントを比べると分かります。
MCPゲートウェイを入れるとレイテンシは増える？
中継点が1つ増えます。同じリージョンなら、通常は数ミリ秒です。別のリージョンに置くと、毎回の呼び出しに1往復分が丸ごと加わるので、ゲートウェイはサーバーの隣に置いてください。
まとめ
起動済みのサーバーでは、MCPのレイテンシはほぼ計算で説明できます。往復回数 × 距離に、ツール自身の外部呼び出しを足したものです。まず往復を減らします。サーバーを2026-07-28に対応させてハンドシェイクを省けるようにし、実際の ttlMs を返し、自作エージェントでは接続とクライアントを使い回し、細かすぎるツールはまとめます。そのうえで、直列の往復が多い側（多くは接続先のDBやAPI）に合わせてリージョンを選びます。計測は、呼び出し元からの curl -w と、サーバー側のリクエストごとの処理時間の両方で行います。リージョンが分からないクラウドのコネクタでは特に重要です。ホスティング先の比較は MCPサーバーホスティングのおすすめランキング を参考にしてください。
