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

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

MQL5で自動売買プログラム（EA）を開発する際、避けて通れないのが「予期せぬエラー」の処理です。GetLastError関数は、直近で実行された処理において「何が原因で失敗したのか」を特定するためのエラーコード（整数値）を取得する関数です。

実務においては、単に「売買注文が通らなかった」という事実を知るだけでは不十分です。
* 証拠金が不足しているのか？
* 指値・逆指値の価格がサーバー側の制限に抵触しているのか？
* ネットワークの瞬断によってサーバーに届かなかったのか？

これらを正しく判別できなければ、適切なリトライ（再試行）処理やエラー通知の実装ができません。GetLastErrorを使いこなすことで、EAの堅牢性を高め、想定外の挙動による資金消失を防ぐ「守りのプログラミング」が可能になります。

2. 構文と戻り値

GetLastError関数は非常にシンプルで、引数は持ちません。

int  GetLastError();

• 戻り値: 最後に発生したエラーのコード（int型）を返します。
• 仕様: この関数を呼び出すと、内部で保持されているエラーコードの変数がリセットされるわけではありません。最新の状態を取得し直すには、あらかじめ ResetLastError() を呼んでエラーコードを「0（エラーなし）」にクリアしておくのが実務上の定石です。

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

以下は、成行注文を出す際に GetLastError を利用してエラー原因を特定し、ログに出力する実践的なコード例です。

#include <Trade\Trade.mqh>

void OnTick()
{
    // 例として買い注文を出す処理
    CTrade trade;
    double price = SymbolInfoDouble(_Symbol, SYMBOL_ASK);

    // 1. 処理の前にエラーコードをリセット（重要！）
    ResetLastError();

    // 2. 注文実行
    if(!trade.Buy(0.1, _Symbol, price, 0, 0, "Error Check Test"))
    {
        // 3. 戻り値がfalseの場合、GetLastErrorで原因を確認
        int errorCode = GetLastError();

        Print("【エラー発生】注文に失敗しました。");

        // エラーコードに応じた処理の分岐
        switch(errorCode)
        {
            case 10018: // ERR_MARKET_CLOSED
                Print("エラー理由: 取引時間外です。コード:", errorCode);
                break;

            case 10019: // ERR_NOT_ENOUGH_MONEY
                Print("エラー理由: 証拠金不足です。コード:", errorCode);
                break;

            case 10016: // ERR_INVALID_STOPS
                Print("エラー理由: ストップレベルが不適切です。コード:", errorCode);
                break;

            default:
                Print("エラー理由: その他のエラーが発生しました。コード:", errorCode);
                break;
        }
    }
    else
    {
        Print("注文は正常に送信されました。");
    }
}

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

必ず ResetLastError() とセットで使う

GetLastErrorは、新しいエラーが発生しない限り、前回の古いエラーコードを保持し続けます。例えば、10分前に発生したエラーを「今のエラー」と勘違いして処理してしまうのを防ぐため、クリティカルな処理の直前には必ず ResetLastError() を実行してください。

エラーコードの意味をリファレンスで確認する

MQL5には数百種類のエラーコードが存在します。主要なものは以下の通りです。
– 10004 (REQUOTES): リクオート（価格再提示）。スリッページ許容幅を広げる検討が必要。
– 10006 (REJECTED): 注文拒否。ブローカー側で何らかの制限がかかっている可能性。
– 4756 (TRADE_ERROR_SEND): 送信エラー。通信環境を疑うべきサイン。

実行順序に注意

エラーが発生した直後に他の組み込み関数を呼ぶと、その関数が成功したことでエラーコードが上書きされたり、予期せぬ値に変わる場合があります。エラーが疑われる時は、真っ先に GetLastError の値をローカル変数に退避させることが重要です。

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

どれほど完璧なエラー処理コードを記述しても、物理的な環境が劣悪であれば「注文遅延」という見えないエラーに資金を削られ続けます。日本の自宅PCから海外の取引サーバーへ注文を出す場合、ネットワークパケットは数千キロの物理的な距離を超えて往復しなければならず、この通信遅延（レイテンシ）はミリ秒単位で利益を奪い取ります。特にスキャルピングや指標発表時のトレードにおいて、自宅回線の不安定なPing値は致命傷となります。

プロのクオンツエンジニアが「VPS（仮想専用サーバー）」を必須とするのは、単にEAを24時間稼働させるためだけではありません。取引サーバーに物理的に近いデータセンターのVPSを利用することで、ネットワーク遅延を極限まで排除し、滑り（スリッページ）を最小化してバックテストに近い再現性を確保するためです。たとえ GetLastError がエラーを吐かなくても、約定価格が数ピップス不利になるだけで、期待値は容易にマイナスへ転じます。本気でシストレで利益を追うのであれば、まずはインフラという土台をプロ仕様に整えることが、勝利への最短ルートです。