MQL5注文・ポジション・履歴管理完全ガイド｜OrderSend・Position・Deal・Historyの基本

MQL5でEAを作成・改修する時に混乱しやすいのが、「注文」「ポジション」「約定」「履歴」の違いです。

MT4ではOrderSelectを中心に考える場面が多かったため、MT5へ移行すると「OrderSendは成功したのにポジションが見つからない」「履歴にはDealがあるのにOrderの見方が分からない」「PositionSelectで取得した値が想定と違う」といった確認ミスが起きやすくなります。

この記事では、MQL5のOrderSend、MqlTradeRequest、MqlTradeResult、TRADE_RETCODE、Position、Deal、Historyの基本を、EA利用者・MQL5開発者・検証担当者の視点で整理します。

公式リファレンスの代替ではなく、公式仕様を読む前に全体像を理解し、EAの動作確認や開発依頼前の資料整理に使える実務ガイドとして確認してください。

MQL5で注文・ポジション・履歴を分けて考える理由

MQL5では、取引処理を1つの「注文」だけで追いかけるのではなく、複数の概念に分けて確認します。

大きく分けると、注文リクエスト、注文結果、現在ポジション、約定履歴、注文履歴の5つです。EAが発注処理を行う時は、まずMqlTradeRequestで取引サーバーへ依頼内容を渡し、その結果をMqlTradeResultで受け取ります。その後、現在保有中の状態はPosition系関数で確認し、過去の約定や注文履歴はHistory系関数で確認します。

EAの不具合調査では、「どの段階で止まっているのか」を切り分けることが重要です。発注前の条件判定で止まっているのか、OrderSendで拒否されているのか、サーバーに受理されたが約定していないのか、約定後のPosition確認で失敗しているのかを分けて確認します。

MT4のOrder中心の考え方とMQL5の違い

MT4では、OrderSelectを使って現在注文や履歴注文を扱う設計に慣れている方が多いです。一方、MQL5では注文、約定、ポジション、履歴を分けて扱うため、MT4と同じ感覚で移植すると確認漏れが起きやすくなります。

特に、MT4からMT5へEAを移行する場合は、「注文を出す処理」と「現在ポジションを集計する処理」と「履歴から決済結果を確認する処理」を別々の関数に分けて設計すると、後から検証しやすくなります。

注文処理の全体像｜Request・Result・Retcode

MQL5の注文処理は、次の流れで考えると整理しやすくなります。

ここで重要なのは、OrderSendを呼び出した時点でEA側の処理が終わるわけではないという点です。注文を送信した後も、retcode、ポジション状態、履歴を確認して、実際に何が起きたかを追跡する必要があります。

MqlTradeRequestで指定する主な項目

MqlTradeRequestは、取引サーバーへ送る注文依頼の内容をまとめる構造体です。発注種別、銘柄、ロット、注文タイプ、価格、SL/TPなどをここに設定します。

実務では、MqlTradeRequestを作る関数を1か所にまとめると、発注ログとエラー確認がしやすくなります。EA内で複数箇所から直接OrderSendを呼ぶと、どの処理がどの条件で注文を出したのか追いにくくなるためです。

MqlTradeResultで確認する主な項目

MqlTradeResultは、OrderSend後に取引サーバーから返ってくる処理結果を受け取る構造体です。特に重要なのはretcodeです。

注文処理のログでは、少なくともretcode、order、deal、volume、price、commentを出しておくと、後から「注文が拒否されたのか」「注文は置かれたが約定していないのか」「約定したがPosition確認で失敗しているのか」を切り分けやすくなります。

OrderSendの基本と確認ポイント

OrderSendは、MqlTradeRequestを取引サーバーへ送り、MqlTradeResultへ処理結果を受け取る関数です。

重要なのは、OrderSendがtrueを返したからといって、必ずポジションが建っているとは限らないことです。OrderSendのtrueは、リクエストが取引サーバーに受理されたことを示す場面があり、実際の約定完了はretcode、deal、order、Position、Historyをあわせて確認します。

EAの注文処理では、OrderSendの直後に「送信結果ログ」を出し、その後に「現在ポジション確認ログ」を分けて出すと、確認しやすくなります。

OrderSendログの最小例

ORDER_SEND:
action=DEAL symbol=SYMBOL type=BUY volume=LOT price=ASK sl=... tp=... deviation=...
result_bool=true retcode=10009 order=123456 deal=123457 comment=Done

このように、送信前のRequest内容と、送信後のResult内容を同じログ行または連続ログで確認できるようにすると、問い合わせ時にも原因を整理しやすくなります。実運用の口座番号、認証情報、APIキー、Webhook URLなどの機密値はログ例や問い合わせ文に含めないでください。

注文成功と約定完了は同じではない

MQL5で最も重要な注意点の1つが、「注文成功」と「約定完了」を分けて考えることです。

たとえば、Pending注文がサーバーへ正常に置かれた場合、注文としては成功していても、その時点ではポジションは建っていません。成行注文でも、サーバー応答のタイミングや約定方式によっては、OrderSend直後の情報だけでは最終状態を判断しにくい場合があります。

注文処理の不具合を調べる時は、「送信できたか」「サーバーが受理したか」「注文が登録されたか」「約定したか」「ポジションとして反映されたか」を順番に確認してください。

TRADE_RETCODEを読む時の基本

TRADE_RETCODEは、取引サーバーが注文リクエストをどのように処理したかを示す戻りコードです。EAの注文エラー調査では、retcodeを読めるかどうかが重要です。

retcodeをログへ残さないEAでは、注文が失敗した時に原因を追跡しにくくなります。EA改修時は、ORDER_FAIL、ORDER_RETRY、ORDER_SENT、EXEC_BLOCKのように、処理結果を分けて記録できる構造にすると検証しやすくなります。

Positionとは何か

Positionは、現在保有しているポジションの状態です。MQL5では、注文や約定そのものではなく、現在の保有状態を確認する時にPosition系関数を使います。

ポジションには、銘柄、方向、ロット、建値、現在価格、損益、Swap、Magic、コメント、ポジションIDなどの情報があります。EAでナンピン、トレーリング、建値移動、決済判定を行う場合は、Position情報の取得が基本になります。

複数EAや複数ロジックを同じ口座で動かす場合は、銘柄だけでなくMagic Numberも確認してください。銘柄だけで決済対象を判定すると、他EAや手動ポジションを巻き込む可能性があります。

PositionSelectとPositionGet系の使い方の考え方

PositionSelectは、指定した銘柄のポジション情報を選択し、その後にPositionGetDouble、PositionGetInteger、PositionGetStringで詳細を取得するために使います。

注意点として、PositionSelectで選択した情報は、その時点の情報です。ポジション状態が変わった可能性がある場面では、取得直前にPositionSelectを呼び直す設計にしておくと、安全に確認できます。

EAでポジションを走査する場合は、PositionsTotal、PositionGetTicket、PositionSelectByTicketを使って、対象銘柄・対象Magic・対象方向を絞り込む構造にすると、誤決済や誤集計を避けやすくなります。

Orderとは何か

MQL5のOrderは、取引サーバーへ出された注文を表します。成行注文、指値注文、逆指値注文、注文変更、注文削除など、サーバーへ依頼された処理を追跡する時に使います。

Orderは「注文として出されたもの」であり、必ずしも「約定済みの取引」と同じではありません。Pending注文のように、注文は存在していてもまだDealが発生していない状態があります。

MT4から移行する時は、Orderという言葉だけで現在保有中の取引まで扱おうとせず、現在状態はPosition、約定結果はDeal、過去の注文はHistoryOrderとして分けると整理しやすくなります。

Dealとは何か

Dealは、実際に成立した取引や、口座に反映された取引イベントを表します。注文が出された事実ではなく、約定や入出金など、実際に履歴として残るイベントを確認する時にDealを見ます。

EAで「いつ決済されたか」「どの注文がどの価格で約定したか」「最終的な損益がどうなったか」を確認する場合は、Deal履歴の確認が重要です。

EAの履歴集計では、Orderだけを見ても実際の約定単位を取りこぼすことがあります。決済結果、部分決済、ナンピンの追加約定、Close Byなどを確認する場合は、Deal履歴の確認を前提にしてください。

Historyとは何か

Historyは、過去の注文や約定を確認するための履歴領域です。現在保有しているポジションではなく、過去に処理された注文、約定、決済結果などを確認する時に使います。

履歴を確認する前には、HistorySelectで対象期間を選択します。対象期間がずれていると、履歴が0件に見えたり、必要なDealが取得できなかったりします。

日次損益、EA別損益、Magic別集計、決済理由の調査では、HistorySelectの期間とDeal履歴の集計条件を必ず確認してください。

HistorySelectとHistoryDealGet系の考え方

HistorySelectは、履歴確認の入口です。先に対象期間を選択し、その後でHistoryDealGetTicketやHistoryDealGetInteger、HistoryDealGetDouble、HistoryDealGetStringを使って、個別の履歴情報を取得します。

履歴確認では、「履歴がない」のか、「期間が違う」のか、「フィルター条件で除外された」のかを分けて確認します。履歴集計のログでは、HistorySelectの成否、対象期間、Deal件数、絞り込み後件数を出しておくと確認しやすくなります。

注文・決済・履歴確認でよくある失敗

注文処理や履歴確認で起きやすい失敗を整理します。原因を決めつけず、どの段階で問題が出ているかを順番に確認してください。

注文処理の失敗は、ロジック条件の問題、EA実装の問題、端末設定の問題、口座・銘柄仕様の問題、取引サーバー側の拒否など、複数の原因に分かれます。1つのログだけで断定せず、段階ごとに確認してください。

EA利用者向けの確認ポイント

EAを利用していて注文が入らない、決済されない、履歴が合わないと感じた場合は、まず次の情報を整理してください。

注文処理に関する相談では、「エントリーしません」だけでは原因を切り分けにくいため、注文前の条件、OrderSend結果、retcode、Position確認、履歴確認のどこで止まっているかを整理することが重要です。

MQL5開発者向けの実装ポイント

MQL5開発者は、注文処理をsignal、execution、risk、exit、position、historyに分けて実装すると、保守しやすくなります。

注文処理を1つの巨大関数にまとめると、retcode、Position、Historyの確認が混ざり、後から修正しにくくなります。EAの規模が大きくなるほど、発注リクエスト作成、送信、結果判定、ポジション再確認、履歴反映を別関数へ分けることが重要です。

検証担当者向けのログ確認ポイント

検証担当者は、チャート上の見た目だけでなく、Expertsログ、Journalログ、取引履歴を照合します。特に注文・決済・履歴に関する検証では、時刻とチケット番号の整合が重要です。

検証では、注文が出たかどうかだけではなく、注文前に止めたのか、OrderSendで失敗したのか、サーバーが拒否したのか、約定後にポジション確認で失敗したのかを分けて記録してください。

EA改修・開発依頼前に整理する情報

EAの注文処理や履歴管理の改修を依頼する場合は、現象だけでなく、再現条件と確認ログを整理しておくと、原因調査が進めやすくなります。

送ってはいけない情報もあります。口座番号、認証トークン、APIキー、Webhook URL、GAS URL、個人情報が写った画像は、そのまま送らないでください。必要な箇所だけを伏せて、EA名、バージョン、ログ、setファイル、再現条件を中心に整理してください。

関連する確認ページ

注文・ポジション・履歴管理を確認する時は、関数、エラー、検証環境、依頼前資料をあわせて整理すると、原因を切り分けやすくなります。

公式リファレンスで確認したい項目

実装時は、この記事だけで完結させず、公式リファレンスで関数仕様や構造体の項目を確認してください。特に、retcode、Position系、History系は、細かいプロパティの型を間違えると取得結果がずれることがあります。

次に読む技術講座

この講座とあわせて確認すると、MQL5の注文・決済・履歴管理をより実務に近い形で整理できます。

次に確認するページ

技術講座を確認した後、導入・商品確認・開発相談・不具合報告へ進む場合は、以下のページも確認してください。

FAQ

OrderとPositionは何が違いますか？

Orderは取引サーバーへ出された注文、Positionは現在保有しているポジション状態です。注文が出ても、まだ約定していなければPositionとして確認できない場合があります。

OrderSendがtrueなら注文は必ず成功していますか？

いいえ。OrderSendのtrueだけで最終成功とは判断しません。MqlTradeResultのretcode、order、deal、Position、Historyをあわせて確認します。

TRADE_RETCODE_DONEは何を意味しますか？

取引サーバー側でリクエストが完了したことを示す成功系の戻りコードです。ただし、実務ではdeal、price、Position状態、履歴も確認して、EA側の処理と一致しているかを見ます。

MT4のOrderSelectとMQL5のPositionSelectは同じですか？

同じではありません。MT4ではOrderSelect中心で現在注文や履歴を扱う場面が多いですが、MQL5では現在保有状態はPosition、注文履歴はOrder、約定履歴はDealとして分けて確認します。

約定履歴を確認するには何を見ればよいですか？

まずHistorySelectで対象期間を選択し、HistoryDealsTotal、HistoryDealGetTicket、HistoryDealGetInteger、HistoryDealGetDouble、HistoryDealGetStringなどでDeal履歴を確認します。

注文エラーが出た時はどのログを送ればよいですか？

注文前後のExpertsログ、Journalログ、使用したsetファイル、対象銘柄、時間足、EA名とバージョン、該当時刻の取引履歴、スクリーンショットを整理してください。口座番号や認証情報は伏せてください。

EA改修依頼前に注文処理の何を整理すればよいですか？

どの条件で注文を出したいのか、注文前に止めたい条件は何か、OrderSend後に何を成功扱いにするか、PositionやHistoryで何を確認するかを整理してください。特にretcodeと履歴確認の扱いは事前に明確にしておくと改修しやすくなります。

Positionが見つからない時は注文失敗ですか？

必ずしも注文失敗とは限りません。Pending注文として登録されただけでまだ約定していない場合や、対象銘柄・Magic Number・ポジションチケットの絞り込みが違う場合があります。

履歴の損益が想定と合わない時は何を確認しますか？

Deal履歴のDEAL_PROFITだけでなく、手数料、Swap、部分決済、Close By、複数Dealの合算を確認します。Order履歴だけでは実際の約定単位を確認できない場合があります。

複数EAを同じ口座で使う時に注意することはありますか？

あります。銘柄だけでなくMagic Number、方向、ポジションチケットを使って対象を分けてください。銘柄だけで決済対象を選ぶと、他EAや手動ポジションを巻き込む可能性があります。

Order、Deal、Positionのどれをログに出すべきですか？

注文処理ではRequestとResult、保有確認ではPosition、履歴確認ではDealをログに出すと切り分けやすくなります。1つのログに詰め込みすぎず、ORDER_SEND、ORDER_RESULT、POSITION_SNAPSHOT、HISTORY_SUMMARYのように分けると確認しやすくなります。

公式リファレンスだけでなく、このような整理記事を見る意味はありますか？

あります。公式リファレンスは仕様確認に有効ですが、EAの不具合調査や開発依頼では、注文、ポジション、約定、履歴をどういう順番で確認するかが重要です。この記事では、その実務上の確認順を整理しています。

まとめ

MQL5の注文処理では、OrderSend、MqlTradeRequest、MqlTradeResult、Position、Deal、Historyを分けて理解することが重要です。

OrderSendの戻り値だけで判断せず、retcode、order、deal、Position、Historyを順番に確認することで、注文がどの段階で止まっているのかを切り分けやすくなります。

EAを利用する側は、EA名、バージョン、銘柄、時間足、setファイル、Expertsログ、Journalログ、取引履歴、スクリーンショットを整理してください。開発する側は、signal、execution、risk、position、exit、historyを責務分離し、ログで追跡できる構造にしておくことが重要です。

関数やエラーコードを確認したい場合は、上記の関連ページと技術講座を参照し、注文処理、現在ポジション、履歴確認を分けて整理してください。