FXあなたの「ポチッ」が約定するまで。MT5 Trade Server内部の知られざる旅｜MT5の向こう側

裁量で何気なくBUY/SELLする。
EAがいつものように自動でBUY/SELLする。

この「当り前」の裏では何が起こっているのでしょう？
今回はFXにおける注文の流れを細かく見ていきます。

顧客 → MT5 Trade Server → 約定エンジン → LP/銀行/取引所

MetaQuotesの公式資料を見ると、MT5にはTrade Serverそのものに取引処理機能があり、さらに Gateway を介してLP、銀行、ECN、取引所などへ接続できます。MT5には独自のECN/マッチング機能を構築することもできます。

詳細な流れは以下になります。

１．顧客が「Buy」を押した瞬間

顧客が

を押したとします。
MT5端末は注文をブローカー側へ送ります。
この段階では、まだ「銀行でEURUSDを買った」とは限りません。

MetaTrader公式の説明でも、注文はまずブローカーへ送られ、サーバー側で価格・資金などのチェックを受け、その後Trade Serverで処理される、とされています。

つまり、

２．MT5 Trade Serverで何が起きるのか

ここが非常に重要です。
Trade Serverは単なる「注文を転送する中継サーバー」ではありません。

などを確認します。
そして注文を

• 約定

• 拒否

• キャンセル

• Dealer処理

• 外部市場へ送る

などに振り分けることができます。公式ドキュメントにも、注文はTrade Serverで処理され、自動執行またはDealerによる執行、拒否、取消などがあり得ると説明されています。

３．ここで「A-book」と「B-book」の違いが出る

例えば顧客がEURUSDを1 lot Buyした場合。

という処理も可能です。
この場合、顧客の注文がそのまま銀行に送られるとは限りません。

例えば、

なら、ブローカー内部で

と相殺することができます。
この場合、外部LPに1 lotを送る必要はありません。

４．では「約定エンジン」とは何なのか？

今回の記事ではここが今回一番重要です。
「約定エンジン」という言葉は、実は2種類の意味で使われることがあります。

① MT5内部の取引処理
MT5 Trade Server自身が注文を処理します。

MT5の公式ドキュメントでも、注文を処理して約定（Deal）を生成し、ポジション（Position）を更新するという取引モデルが説明されています。

② 外部のMatching Engine
一方、ECNなどを構築している場合は、

のような別のマッチングエンジンが存在する場合があります。
MetaQuotes自身もMT5について、独自の流動性プールを作り、完全なマッチングエンジン管理を実行できると説明しています。

したがって、
「MT5 Trade Serverの後ろには必ず別の約定エンジンがある」
ではありません。

ブローカーの構成次第です。

５．LPとは何なのか？

LP = Liquidity Provider（流動性提供者） です。

MT5はこうしたLPへ接続できます。
現在のMetaQuotesの説明では、MT5にはLPへの接続機能があり、複数LPを同時接続して価格集約や注文執行を管理できます。

という価格が来ていたとします。
するとブローカー側では、

のように最良価格を組み合わせて顧客向け価格を作ることができます。

６．さらに重要なのが「Gateway」

ここはMT5を理解するうえで非常に重要です。
Gatewayは簡単に言えば、

💡MT5と外部取引システムを接続するためのアダプター

外部システムはMT5と同じ通信方式ではありません。
そこでGatewayが、

に変換します。逆方向では、

となります。
MetaQuotesもGateway APIを、MT5と他の取引システムとの統合に使うものとして説明しています。

７．実際の「Buy 1 lot」を追ってみる

顧客が以下の発注を行ったとします。

STEP 1

STEP 2

STEP 3
Trade Serverで以下を確認。

STEP 4
ここから分岐します。

• Dealer：内部処理（ディーラー）

• Internal Matching：内部処理（マリー）

• Gateway：外部処理

💡全顧客注文が必ずLPへ行くわけではありません

８．LPへ送った場合

Gatewayを通してLPに送った場合

LP側から、

という結果が返ってきます。
それを、

と戻します。
顧客のMT5には、

として約定が表示されます。
外部システムでの約定には、MT5側のDeal IDとは別に外部システム側のIDが付く場合もあり、MetaTraderの公式ドキュメントでもその対応関係を追跡できるとされています。

９．この場合はどうなる？

顧客が以下の注文を出したとします。

LP A　：　Ask 1.10000　10 lot
LP B　：　Ask 1.10001　30 lot
LP C　：　Ask 1.10002　60 lot

しか持っていなかったとします。
すると100 lotを一発で同じ価格で約定できない可能性があります。

という 複数LPへの分割執行 が起こり得ます。
このような価格集約・注文執行を行う仕組みがLiquidity Aggregatorです。
実際、MT5向けの流動性アグリゲータでは、複数LPの価格を集約し、BBO（Best Bid and Offer）に基づいて注文をルーティングする仕組みが提供されています。

10．そして「約定拒否」「スリッページ」が発生する

顧客から以下の注文が来たとします。

しかしLP側では、その瞬間には

となっていたとすると

となることがあります。
これがスリッページです。
あるいは

などで注文が拒否されることもあります。

11．ここで「MT5が価格を作っているのか？」という疑問が出る

これも非常に重要です。
MT5そのものが世界のFX市場からEURUSD価格を取得しているわけではありません。

ブローカーが以下の構造をつくります。

だから、

💡同じMT5でもブローカーによってEURUSDの価格・スプレッド・約定品質が違う

MT5はブローカー向けにLP、取引所、ECN、銀行などへの接続機能を提供しています。

12．さらに重要：「MT5＝市場」ではない

ここを理解するとMT5の全体像がかなりクリアになります。
MT5は、市場そのものではありません。
むしろ、

という ブローカーの取引インフラの中心部分 と考えた方が近いです。
MetaQuotes自身もMT5をブローカー向けのフルサイクルプラットフォームと位置付け、取引所・LP・ECN・銀行などへの接続機能を提供しています。

13．FXの注文は分散システム

FXの注文は上記の分散システム全体で処理されます。

MetaQuotesもMT5について「様々な機能が個々のサーバーに分散された分配型アーキテクチャ」と説明しています。

そしてサーバーを置く場所についても、MetaQuotesはAWS、Azure、Equinixなどのホスティング環境を例として挙げています。つまり物理専用機の場合もあれば、クラウド/仮想化環境の場合もあり得ます。