【MQL5】OrderCheck関数の使い方と自動売買実装コード

1. OrderCheck関数の概要と実務での活用法

MQL5で自動売買（EA）を開発する際、多くの初心者が「OrderSend関数で注文を出し、エラーが出たら対処する」という場当たり的な実装をしてしまいがちです。しかし、プロのクオンツエンジニアは、注文をサーバーに送信する前に、その注文が現在の口座状況（証拠金やロット数制限など）で実行可能かどうかを必ず検証します。そのために使用するのが OrderCheck 関数です。

OrderCheck は、いわば「注文のシミュレーター」です。実際に発注することなく、以下の項目を事前にチェックできます。

• 証拠金の不足: 注文を出した後に証拠金維持率がどれくらいになるか。
• 制限事項: 業者が設定している最小/最大ロットや、ストップレベルに抵触していないか。
• 注文パラメータの不整合: 指値の価格が現在のレートとかけ離れすぎていないか、あるいは近すぎないか。

実務においては、OrderCheck を通さずに OrderSend を乱発すると、無駄なリクエストが取引サーバーに負荷をかけ、最悪の場合は業者から接続を制限されるリスクもあります。スマートなEA開発には欠かせない「守りの関数」と言えます。

2. 構文と戻り値

OrderCheck 関数の基本的な構文は以下の通りです。

bool OrderCheck(
   const MqlTradeRequest&  request, // 注文内容（リクエスト構造体）
   MqlTradeCheckResult&    result   // チェック結果（リザルト構造体）
);

パラメーター

1. request: MqlTradeRequest 型の構造体。売買の方向、通貨ペア、ロット数、価格などを格納します。
2. result: MqlTradeCheckResult 型の構造体。この関数を実行した後、証拠金の余力やエラーの詳細がこの中に書き込まれます。

戻り値

• true: 基本的なパラメータチェックを通過し、サーバーに送信可能な状態であることを示します。
• false: チェックに失敗。この場合、第2引数の result 構造体の中身を確認して、何が原因で失敗したのか（残高不足か、パラメータミスか等）を特定します。

3. 具体的な使い方・実践サンプルコード

以下は、買い注文を出す前に OrderCheck で証拠金とパラメータの妥当性を確認する実戦的なコード例です。

void OnTick()
{
    // 1. 注文リクエストの準備
    MqlTradeRequest request = {};
    MqlTradeCheckResult result = {};

    request.action       = TRADE_ACTION_DEAL;           // 成行注文
    request.symbol       = _Symbol;                    // 現在の通貨ペア
    request.volume       = 1.0;                        // 1.0ロット
    request.type         = ORDER_TYPE_BUY;             // 買い
    request.price        = SymbolInfoDouble(_Symbol, SYMBOL_ASK); // 現在の買値
    request.deviation    = 10;                         // スリッページ許容値
    request.magic        = 123456;                     // マジックナンバー
    request.tp           = 0;                          // 利確（設定しない場合は0）
    request.sl           = 0;                          // 損切（設定しない場合は0）

    // 2. OrderCheckによる事前検証
    if(!OrderCheck(request, result))
    {
        // チェックに失敗した場合の原因特定
        PrintFormat("【チェック失敗】リターンコード: %d, 必要な証拠金: %.2f", 
                    result.retcode, result.margin);

        // 証拠金不足の場合の処理例
        if(result.retcode == TRADE_RETCODE_INSUFFICIENT_FUNDS)
        {
            Print("エラー：証拠金が足りません。");
        }
        return; // 注文へ進まずに終了
    }

    // 3. チェックを通過した場合のみOrderSendを実行
    MqlTradeResult send_result = {};
    if(OrderSend(request, send_result))
    {
        Print("注文送信に成功しました。チケット番号: ", send_result.order);
    }
    else
    {
        Print("注文送信エラー: ", GetLastError());
    }
}

4. 使用上の注意点とよくあるエラー

「Check通過 ＝ 約定確定」ではない

OrderCheck が true を返したとしても、その後の OrderSend が必ず成功するわけではありません。OrderCheck はあくまで「現時点でのクライアント端末とサーバーの制限」を照合しているに過ぎません。実際に注文がサーバーに届くまでのわずかな時間に価格が激変したり、業者のサーバー側でリクオート（再提示）が発生したりする可能性は排除できません。

ロット数のステップに注意

初心者がよく陥るのが、計算で求めたロット数が業者の定める「最小変化幅（Lot Step）」に従っていないケースです。例えば、0.01刻みの業者に対して 0.055ロットでチェックを行うと、OrderCheck はエラー（TRADE_RETCODE_INVALID_VOLUME）を返します。事前に MathFloor 等でロット数を正規化しておく必要があります。

ストップレベルの動的変化

ストップロス（SL）やテイクプロフィット（TP）を設定する場合、現在の価格に近すぎるとエラーになります。この「最低限離すべき距離（ストップレベル）」は相場急変時に業者が広げることがあるため、OrderCheck で常に確認する癖をつけておくと、EAの堅牢性が飛躍的に向上します。

5. 【重要】自動売買における約定スピードと環境の罠

どれほど完璧なロジックを組み、OrderCheck で精密なバリデーションを行ったとしても、実行環境が貧弱であればすべてが無に帰します。特に、自宅のPCから一般的なインターネット回線を通じて自動売買を行うことは、プロの視点からは極めてリスクが高い行為と言わざるを得ません。ネットワークの遅延（レイテンシ）は、数ミリ秒単位で利益を削り取り、バックテストの結果を大きく乖離させる原因となります。

FX取引サーバーは世界各地（ロンドンやニューヨークなど）のデータセンターに設置されており、そこから物理的に離れた日本の自宅PCでは、パケットの往復だけで致命的なタイムロスが発生します。急変時のスリッページを最小限に抑え、プログラムが意図した価格で即座に約定させるためには、取引サーバーの至近距離に位置する専用のVPS（仮想専用サーバー）の利用が不可欠です。24時間安定した稼働と極限の約定スピードを確保することこそが、システムトレードで長期的に生き残るための「最低条件」となります。