この記事の内容
この記事を読むと…
- Close Byエラーと非同期段階の拒否を区別する。
- 五チケットを実約定と残数量へ照合する。
- 差引ゼロ・無建玉・待機注文なしを分ける。
記事内で用語を調べる
注文約定(Execution) ロット ストップロスMT5の全決済は要求の連続で、口座全体の同時決済を保証しません。拒否、処理の中断、アプリ終了で建玉が残り得ます。実際の約定と残数量を確認します。対象はMT5標準の一括操作で、追加ソフトや独自EAは異なる場合があります。
選んだコマンドは何を対象にするか
全建玉、利益のある建玉だけ、損失だけ、特定銘柄、同方向など、コマンドの完全名を確認。選択中の建玉によって候補が変わります。「全部閉じた」という記憶だけでは対象範囲が不明です。決済と反転は別で、反転は新たな逆方向の建玉を作り得ます。
MT5の一括操作は段階が違います。ヘッジ方式では最初にClose Byを試み、残りを通常決済。逐次のClose Byでエラーが出ると全処理が停止します。その後の非同期段階では拒否された建玉が残っても他の要求は続きます。FIFOの決済も逐次で、エラーで停止。段階を区別します。
一括コマンドにはOne Click Tradingの有効化が必要です。FIFO制約口座では一部の操作が非表示になります。見た目でなく口座の建玉方式とACCOUNT_FIFO_CLOSEを確認。これはその口座の性質で、世界共通または日本共通の法規則ではありません。
ヘッジ方式の別チケットとネット方式の合算建玉を区別します。Close Byはヘッジ方式で同一銘柄の反対建玉を相殺決済する操作。似た名称の別商品は反対側とは限りません。独自の全決済スクリプトは標準メニューと同じ動作とせず、その説明で評価します。 両建てとネット方式。
五つの建玉をどう照合するか
| チケット | 開始状態 | 確認 | 残存 |
|---|---|---|---|
| A | EUR/USD 買い0.10ロット | BとのClose By約定 | なし |
| B | EUR/USD 売り0.10ロット | AとのClose By約定 | なし |
| C | GBP/USD 買い0.20ロット | 0.20全量を決済 | なし |
| D | USD/JPY 売り0.10ロット | 要求拒否、決済0 | 売り0.10 |
| E | XAU/USD 買い0.05ロット | 0.05全量を決済 | なし |
A–B約定後、建玉数は5から3へ減ります。端末はC・D・Eの通常決済を、それぞれの直前の確認を待たず送信。模型ではCとEは決済、Dは拒否され、最後にUSD/JPY売り0.10ロットのDが一つ残ります。三要求の送信は三決済の完了ではありません。 ロットの契約数量。
五つのうち一つが残る
横にスクロールすると図全体を確認できます。
図の要点はメッセージ窓でなく現在の建玉と確認済み決済数量を数えること。ここでは一回のClose Byで二チケットが消え、通常決済には別々の結果があります。エラー分類と実際の口座照合を組み合わせます。未確認を拒否と同じ結果にしません。 注文エラー。
各チケットの銘柄、方向、開始数量、要求・注文識別子、応答、約定、残数量を保存。DEAL_ORDERやDEAL_POSITION_IDで対応を確認できます。一注文が複数約定になる場合、断片ごとに全量決済と数えません。時刻の時間帯と未解決の理由も記します。
エラーや中断で何が変わるか
同じ開始状態の別ケースとして、A–Bが約定前にClose Byエラーとなり、決済約定なしと仮定します。通常のC・D・Eの前に停止し、五つ全部が残ります。A–B成功後にDだけ拒否されるケースとは違います。現実の応答欠落では、何も約定していないと決めず調査します。
アプリを閉じると一括処理は停止しますが、確認済み約定は元に戻りません。A–B決済済みでC–E未送信なら、この別ケースの残りは三つ。送信済み要求はサーバー結果を確認します。再起動は全決済の証明でなく、記憶した旧数量で全バッチを自動再送しません。
途中でEA、別アプリ、他の操作者が新規建玉を作っていないか確認。新チケットは決済失敗した旧建玉とは限りません。履歴、指示元、時刻で照合。独自MQL5ではOrderSendのtrueだけで約定とせず、結果フィールドとイベントを確認します。診断のための実口座の試し注文は不要です。
建玉一覧が空なら終了か
待機注文も確認します。MT5にはそのための別の削除操作があり、建玉決済の実行だけでは取消済みといえません。架空の待機買いPは五建玉の決済後も残り、その後約定すれば新建玉を作ります。取消要求とその結果も別々に確認します。 注文種類。
同期後、銘柄や方向を隠すフィルターなしで正しい口座の建玉を読み、決済履歴と待機指示を別に照合。空の状態には観測時刻と口座範囲を付記します。一画面はEAが二度と新規建玉を作らない証明ではありません。残った建玉の保護も確認し、一括処理の失敗を現在リスク放置の理由にしません。
有用な全決済チェックは、現在何が口座に残るかを一覧にして終わります。送った要求の件数では代用できません。
次に行う三つの確認
- デモで範囲を再現:口座方式、コマンド完全名、各チケットと数量を開始状態とともに記録。拒否処理を実口座で試さず、模型や安全なデモ環境を使います。
- 建玉ごとに確認済み結果を対応:Close Byと通常決済を分け、拒否・未解決を明記し現数量を読みます。旧バッチを記憶で再送せず、ボタン消失を約定としません。
- 二つの一覧で終了確認:同期後、正しい口座の建玉と待機注文をフィルターなしで点検。残存リスクと可能な対応を評価し、最終状態と観測時刻を日誌へ保存します。
独立比較:差引ゼロでも建玉ゼロではない
別の架空JPY口座を考えます。USD/JPYのJ1買い1,000 USDとJ2売り1,000 USDが別チケットで残っていれば、差引数量は0 USDでも建玉は2、両側の数量を足した総量は2,000 USDです。金額換算や証拠金の優遇率を意味しません。損益、スワップ、保護、相殺可否は契約次第。差引の表示だけで全決済と判断できません。
別ケースでDの売りだけ1,000 USD残り、売り建値を150.00 JPY/USD、後の決済Askを150.20と置くと、費用前損益は(150.00−150.20)×1,000=−200 JPYです。元模型の0.10ロットを自動で1,000 USDへ置換したのではなく、数量を独立指定した仮例です。国内でも一ロットの通貨量は業者仕様で確認します。
差引額ではなくチケット、確認済み約定、待機注文、発注元を同じ観測時点で照合します。 小さな画面では横にスクロールするか、図を拡大できます。数値と要点は下のテキストにも記載しています。
時刻は例えば2026年10月26日21:00 JSTの同期後観測と明記します。JSTはUTC+9で国内夏時間なし。「建玉0・待機注文1」と「建玉0・待機注文0」も別の状態。後者でも自動発注元が活動中なら将来の無建玉を保証しません。
理解度を確認
練習の目安: 約2分.
答えと解説を見る
正解。四チケットが終了し、Dには確認済み決済がありません。
よくある質問
全決済で待機注文も消えますか。
端末を閉じれば一括操作は取り消されますか。
利益建玉だけを閉じるコマンドがないのはなぜですか。
エラー後に全決済をもう一度押せますか。
出典と検証
- www.metatrader5.com
内容の参考資料。記事に記載した範囲と前提を確認してください。
- www.mql5.com
内容の参考資料。記事に記載した範囲と前提を確認してください。
- www.mql5.com
内容の参考資料。記事に記載した範囲と前提を確認してください。
- www.mql5.com
内容の参考資料。記事に記載した範囲と前提を確認してください。
計算例には前提条件を明記しています。現在の市場データや提供会社の取引条件の代わりにはなりません。
