EAの発注失敗は、シグナルではなく注文条件の不整合から起きることがあります。MQL5のOrderCheckを使い、証拠金、注文パラメータ、サーバー応答を送信前に検証し、失敗原因を記録・分類する実装方法を解説します。
売買ロジックが正しくても注文は失敗する
EAでは、エントリー条件が成立した後にOrderSendを呼べば注文処理が完了すると考えがちである。しかし実際には、ロット、価格、証拠金、取引権限など複数の条件が注文受付に関係する。
そのため「シグナルは発生しているのに注文されない」という現象を、売買ロジックの問題だけとして調査すると原因特定に時間がかかる。
MQL5には、取引リクエストを送信する前に検査するOrderCheck関数が用意されている。発注処理を「シグナル生成」「注文生成」「事前検証」「送信」「結果確認」に分離すれば、どの段階で問題が起きたかを数値とコードで追いやすくなる。
OrderCheckは何を確認するのか
OrderCheckはMqlTradeRequest型の取引リクエストを受け取り、MqlTradeCheckResultへ検査結果を返す関数である。
主な確認対象には、リクエスト内容の妥当性と必要証拠金に対する資金状況がある。検査結果からはretcodeやcommentに加え、注文が実行されたと仮定した場合のbalance、equity、margin、margin_free、margin_levelなどを取得できる。
つまり「現在の余剰証拠金がいくらか」だけではなく、「この注文を追加した後に口座状態がどう変化するか」を発注前に確認できる。
ただし、OrderCheckが正常でも、その後の注文成立が保証されるわけではない。価格やサーバー状態は検査後にも変化するため、事前検証と実際の執行結果は別の工程として扱う必要がある。
EAでは三段階に処理を分ける
実装では、注文を直接OrderSendへ渡すより、処理を三段階に分離すると管理しやすい。
第一段階はMqlTradeRequestの生成である。注文種別、数量、価格、Stop Loss、Take Profit、Magic Numberなど、戦略が必要とする値を構築する。
第二段階でOrderCheckを実行する。ここでfalseが返った場合や、check結果のretcodeが許容状態でない場合はOrderSendへ進めない。
第三段階で初めてOrderSendを呼び、MqlTradeResultのretcodeを確認する。
この構造にすると、「シグナルが出なかった」「注文値が不正だった」「事前検査で拒否された」「送信後にサーバー側で成立しなかった」を別々に記録できる。
trueだけを見てはいけない
OrderCheckでもOrderSendでも、戻り値のboolだけで成功を判断しないことが重要である。
OrderCheckがtrueを返しても、それは要求した取引が将来確実に成立するという意味ではない。結果構造体のretcodeとcommentを確認する必要がある。
OrderSendについても同様で、trueは基本的なリクエスト処理が通ったことを示すが、実際の約定完了そのものを意味しない。取引サーバーの応答コードを別途確認する。
したがってEAのログには、bool値だけではなく、OrderCheckのretcodeとcomment、OrderSendのretcode、order番号、deal番号をセットで保存した方がよい。
ロット計算後に検証層を置く
特に有効なのが、ポジションサイジングと発注処理の間にOrderCheckを置く設計である。
例えば残高やATRからロットを計算しても、銘柄ごとの最小数量や数量ステップ、証拠金条件などによって、その値をそのまま発注できるとは限らない。
「ロット計算関数が返したから正しい」と仮定せず、最終的なMqlTradeRequestを完成させた後に検査する。こうすることで、戦略側の理論数量と、実際の取引環境で受け付けられる注文を切り分けられる。
また、検査後のmarginやmargin_freeをログへ保存しておけば、注文が増えたときに証拠金余力がどう変化していたかを後から分析できる。
静的チェックも組み合わせる
OrderCheckにすべてを任せるのではなく、EA側でSymbolInfo系の情報を取得し、注文前の静的チェックを行う方法もある。
数量の最小値・最大値・ステップ、価格のtick size、Stops Level、取引モードなどを事前に確認すれば、明らかな入力不整合をサーバーへ送る前に分類できる。
最近公開されたMT5向けの注文検査ツールでも、数量ステップ、価格グリッド、Stops Level、注文方向、取引権限などを個別に表示する考え方が採用されている。
EAでも同様に、「volume_error」「price_grid_error」「margin_error」のように理由を分類すると、単純なfailedというログより検証価値が高くなる。
発注失敗率そのものを指標にする
注文処理の品質を測るなら、損益とは別に発注失敗率を記録するとよい。
例えば、シグナル発生数、OrderCheck通過数、OrderSend実行数、サーバー受付数、約定数をそれぞれカウントする。1000回のシグナルに対して事前検査で何件止まり、送信後に何件失敗したかを集計すれば、EAの実装品質を定量化できる。
さらにエラー理由、時間帯、銘柄、ボラティリティ、スプレッドと組み合わせれば、特定条件で注文失敗が増える構造も確認できる。
これはバックテストの純利益とは異なる、執行レイヤーの評価指標である。
まとめ
EAの注文処理では、シグナル生成とOrderSendの間に検証層を設けることが重要である。OrderCheckを使えば、リクエスト内容や証拠金への影響を送信前に確認できる。
ただし事前検査の成功は約定保証ではないため、OrderCheck、OrderSend、最終的な取引結果を別々に記録する。さらに静的条件や失敗理由を分類し、発注失敗率まで測ることで、EAの性能を売買ロジックだけでなく注文処理の品質から評価できる。
