レイテンシの地理学 — 「ブローカーに近いサーバ」が半分間違いである理由

Ember 編集部 ・ 2026-07-16 ・ 約6分 ・ market-microstructure

本記事は情報提供・教育を目的としたものであり、特定の金融商品の取得・売買を推奨する投資助言ではありません。投資判断はご自身の責任で行ってください。

自動売買ボットをどこにデプロイするか。よくある答えは「ブローカーのサーバに近いリージョン」で、よくある実践は「API エンドポイントに ping して一番速い場所を選ぶ」です。 この方法は 半分の確率で間違った答えを返します 。理由は単純で、あなたが ping している「APIエンドポイント」はたいていただの入口(プロキシ・アクセスゲートウェイ)であり、 価格が生まれる場所(マッチングエンジン・価格配信の源流)は別の大陸にある ことが珍しくないからです。API の受付が東京、価格の源流がロンドン — この構成のブローカーに対して「東京が最速」という ping の答えは、フィードの鮮度では最悪の選択になり得ます。 この記事は連載の最終回として、検証(第1〜3回)の外側にある 実行インフラの選定 を扱います。 レイテンシがリテールの時間スケールでも損益に効く場面の整理 金融のネットワーク地理の基礎(Equinix NY4 / LD4 / TY3 と FX の地勢) RTT とフィード鮮度が別の場所を指す というプロキシ構成の罠 全リージョンに計測プローブを撒いて エンドツーエンドで測る 方法論(1日で終わります) 測定結果の読み方 — 戦略の型によって「正解の場所」が変わる理由

レイテンシはいつ損益になるか 正直な前提から始めます。 保有が数時間〜数日の戦略なら、リージョン選定はほぼ誤差 です。50ms と 250ms の差が日足の判断を変えることはありません。 効いてくるのは次の場面です。 イベント駆動 : 指標発表・要人発言に反応する戦略は、反応が 100ms 遅いだけで「動いた後の価格」を掴む ストップ執行の質 : 急変時、ストップ注文の滑りはレイテンシにほぼ比例して悪化する クオート駆動のシグナル : 気配の変化そのものを特徴量にする戦略(マイクロプライス、板の傾き)は、フィードが古いとシグナル自体が古い 複数会場の裁定・ヘッジ : 会場間の伝播より遅い裁定は、単に逆選択される側に回る つまり「速くなるほど儲かる」のではなく、 遅いと構造的に不利になる戦略の型がある 、が正確な理解です。自分の戦略がその型でないなら、この記事の結論は「好きな場所に置け」で終わりです(それも立派な測定結果です)。 金融のネットワーク地理 — 価格には産地がある FX の機関間流動性は、物理的にはごく少数のデータセンターに集中しています。 NY4/NY5(ニュージャージー) : EBS・主要 ECN・大手 LP。事実上の USD 集積地 LD4/LD5(ロンドン郊外) : Refinitiv Matching・欧州系 LP。EUR/GBP の重心 TY3(東京) : 円絡みの一部と国内業者 リテールブローカーはこの「源流」から価格を仕入れ、自社のブリッジやアグリゲータを経由してあなたに配信します。ここで重要なのは、 ブローカーの会社所在地・APIの入口・価格の源流は、3つとも別の場所であり得る ということです。オーストラリアのブローカーが、ロンドンの LP から価格を仕入れ、シンガポールでAPIを受け付ける — ごく普通にあります。 罠: ping が最小の場所 ≠ 価格が最初に届く場所 問題を式にすると、あなたが最適化したい遅延は2種類あります。 1. フィード鮮度 : 源流で価格が変わってから、あなたのプロセスがそれを知るまでの時間 2. 発注 RTT : あなたが注文を出してから、約定が確定するまでの時間 プロキシ構成のブローカーでは、この2つが 別々のリージョンで最小化される ことがあります。API 入口(プロキシ)が東京にあれば発注 RTT は東京が最小に見える。しかし価格が LD4 産なら、フィードは「ロンドン → 東京のプロキシ → あなた」と旅してくるので、フィード鮮度はロンドン近傍のリージョンが最良になる。 ping(TCP RTT)はプロキシまでの距離しか測っていない ので、この構造を原理的に検出できません。 さらに悪い形もあります。入口すら anycast や CDN 的な構成で「どこから見ても近い」場合、ping はほぼ横並びになり、何の情報も持ちません。 方法論: 全リージョンにプローブを撒いて、エンドツーエンドで測る 答えは推測ではなく測定で出します。手順は素朴です。 1. 同一のプローブを全リージョンにデプロイする 。クラウドの従量課金(コンテナ実行や関数)なら、全リージョン×数時間の測定でも数百円で済む 2. 各プローブが 同じ口座・同じフィードに接続 し、受信した各ティックに「受信時刻」を打つ 3. あわせて 発注経路の RTT (またはその代理として order API エンドポイントへの TCP 接続時間)を測る 4. 中央に集めて比較する フィード鮮度の比較には時計合わせの問題があります。リージョン間で数 ms 精度の絶対時刻を保証するのは面倒ですが、実務には 相対比較で十分 です: 全プローブが同じクオート列(bid/ask の値の系列)を受け取ることを利用して、同一クオートの受信時刻差の分布を取れば、NTP レベルの時計精度でもリージョン間の優劣は安定して出ます。 測定でよく出る(そして ping では絶対に見えない)パターンが2つあります。 RTT 最小とフィード最速が別リージョン : 上で説明したプロキシ構成の証拠。ブローカーの内部トポロジーが、測定結果として外から観測できる 中央値は同じでも裾(p90/p99)が違う : 平常時は横並びなのに、値動きが激しい瞬間だけ特定リージョンの配信が遅れる。イベント駆動戦略にとってはこの裾こそが本体 結果の読み方 — 「正解の場所」は戦略の型で決まる 測定が終わったら、置き場所は次の整理で決まります。 戦略の型 優先すべき指標 クオート駆動(気配変化がシグナル) フィード鮮度(特に p90 以奥の裾) イベント駆動(発表に反応) フィード鮮度 + 発注 RTT の和 ストップ・決済の執行品質を守りたい 発注 RTT 日足・スイング どうでもよい(運用しやすい場所へ) フィードと RTT が別の場所を指した場合、シグナル計算と発注執行を 別リージョンに分離する 構成も選択肢に入ります(フィードの速い場所で判断し、入口の近くから撃つ)。ただしその内部通信の遅延が加算されるので、これも推測ではなく測ってから決めます。 まとめ — 連載を閉じる 「アルファ以前」の4回で扱ったのは、すべて 戦略のアイデアより先に固定すべき足場 でした。 1. 検証コードは正直か(ルックアヘッド・多重検定・コスト) 2. データは現実を写しているか(bid/ask・スプレッドの時間構造・約定モデル) 3. 数字は偶然と区別できるか(SE・PSR・DSR) 4. 実行環境は測定して選んだか(この記事) 足場のない状態で見つけた「勝てる戦略」は、足場を組んだ瞬間にほとんど消えます。それはあなたが下手になったのではなく、 幻が見えなくなっただけ です。そして足場の上に残ったわずかなものだけが、本番の損益と同じ形をしています。 質問・追試の報告は、この記事のレビュータスクや Q&A へどうぞ。追試されること自体がこのサイトの設計思想です。