プラットフォームとツール

MT5の全決済後に建玉が残る理由:五チケットで結果を照合

Close Byの逐次処理、通常決済の非同期要求、FIFOと中断を区別。五建玉の元SVGと日本語照合表、差引ゼロでも二建玉が残る独立JPY例で確認します。

五建玉の決済結果を照合する編集用イメージ。実取引画面や業者記録ではありません。
送信した要求数と、口座に残る建玉数を分けて記録します。

レバレッジを使うFXやCFDでは、短時間で大きな損失が生じることがあります。内容は学習用であり、個別の投資助言ではありません。

この記事の内容

この記事を読むと…

  • Close Byエラーと非同期段階の拒否を区別する。
  • 五チケットを実約定と残数量へ照合する。
  • 差引ゼロ・無建玉・待機注文なしを分ける。

記事内で用語を調べる

注文約定(Execution) ロット ストップロス

MT5の全決済は要求の連続で、口座全体の同時決済を保証しません。拒否、処理の中断、アプリ終了で建玉が残り得ます。実際の約定と残数量を確認します。対象はMT5標準の一括操作で、追加ソフトや独自EAは異なる場合があります。

選んだコマンドは何を対象にするか

全建玉、利益のある建玉だけ、損失だけ、特定銘柄、同方向など、コマンドの完全名を確認。選択中の建玉によって候補が変わります。「全部閉じた」という記憶だけでは対象範囲が不明です。決済と反転は別で、反転は新たな逆方向の建玉を作り得ます。

MT5の一括操作は段階が違います。ヘッジ方式では最初にClose Byを試み、残りを通常決済。逐次のClose Byでエラーが出ると全処理が停止します。その後の非同期段階では拒否された建玉が残っても他の要求は続きます。FIFOの決済も逐次で、エラーで停止。段階を区別します。

一括コマンドにはOne Click Tradingの有効化が必要です。FIFO制約口座では一部の操作が非表示になります。見た目でなく口座の建玉方式とACCOUNT_FIFO_CLOSEを確認。これはその口座の性質で、世界共通または日本共通の法規則ではありません。

ヘッジ方式の別チケットとネット方式の合算建玉を区別します。Close Byはヘッジ方式で同一銘柄の反対建玉を相殺決済する操作。似た名称の別商品は反対側とは限りません。独自の全決済スクリプトは標準メニューと同じ動作とせず、その説明で評価します。 両建てとネット方式。

五つの建玉をどう照合するか

作成した診断模型:FIFO制約のない架空ヘッジ口座の五建玉で、EUR/USDはClose By可。部分約定、新規参入、その他変動はありません。順序の依存を示すもので、サーバー速度や現金損益を計算せず、異なる契約のロットは足しません。
開始状態と確認済み結果
チケット開始状態確認残存
AEUR/USD 買い0.10ロットBとのClose By約定なし
BEUR/USD 売り0.10ロットAとのClose By約定なし
CGBP/USD 買い0.20ロット0.20全量を決済なし
DUSD/JPY 売り0.10ロット要求拒否、決済0売り0.10
EXAU/USD 買い0.05ロット0.05全量を決済なし

A–B約定後、建玉数は5から3へ減ります。端末はC・D・Eの通常決済を、それぞれの直前の確認を待たず送信。模型ではCとEは決済、Dは拒否され、最後にUSD/JPY売り0.10ロットのDが一つ残ります。三要求の送信は三決済の完了ではありません。 ロットの契約数量。

五つのうち一つが残る

横にスクロールすると図全体を確認できます。

五つのうち一つが残る作成模型:Close ByでAとB、通常決済でCとEが終了。Dは拒否されUSD/JPY売り0.10ロットが残ります。要求の送信と約定は別です。A + B:EUR/USDClose By完了2建玉を決済C:GBP/USD決済約定を確認1建玉を決済D:USD/JPY要求が拒否売り0.10が残存E:XAU/USD決済約定を確認1建玉を決済
A–Bの相殺とC・Eの決済が成功しても、Dの売り0.10ロットは残ります。実口座ではなく作成模型です。

図の要点はメッセージ窓でなく現在の建玉と確認済み決済数量を数えること。ここでは一回の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が二度と新規建玉を作らない証明ではありません。残った建玉の保護も確認し、一括処理の失敗を現在リスク放置の理由にしません。

有用な全決済チェックは、現在何が口座に残るかを一覧にして終わります。送った要求の件数では代用できません。

次に行う三つの確認

  1. デモで範囲を再現:口座方式、コマンド完全名、各チケットと数量を開始状態とともに記録。拒否処理を実口座で試さず、模型や安全なデモ環境を使います。
  2. 建玉ごとに確認済み結果を対応:Close Byと通常決済を分け、拒否・未解決を明記し現数量を読みます。旧バッチを記憶で再送せず、ボタン消失を約定としません。
  3. 二つの一覧で終了確認:同期後、正しい口座の建玉と待機注文をフィルターなしで点検。残存リスクと可能な対応を評価し、最終状態と観測時刻を日誌へ保存します。

独立比較:差引ゼロでも建玉ゼロではない

別の架空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へ置換したのではなく、数量を独立指定した仮例です。国内でも一ロットの通貨量は業者仕様で確認します。

独立比較:ゼロの表示を三種類に分ける架空JPY口座の例。建玉数量はUSD単位で独立指定し、元模型のロットを換算したものではありません。仮定に基づく計算買い1,000・売り1,000 USD差引0でも2建玉建玉0・待機注文1将来の新規約定があり得る建玉0・待機注文0観測時点の状態
独立比較:ゼロの表示を三種類に分ける. 架空JPY口座の例。建玉数量はUSD単位で独立指定し、元模型のロットを換算したものではありません。

差引額ではなくチケット、確認済み約定、待機注文、発注元を同じ観測時点で照合します。

小さな画面では横にスクロールするか、図を拡大できます。数値と要点は下のテキストにも記載しています。

買い1,000・売り1,000 USD
差引0でも2建玉 – 総数量2,000 USD。証拠金の計算とは別。
建玉0・待機注文1
将来の新規約定があり得る – 建玉決済と待機指示の削除は別操作。
建玉0・待機注文0
観測時点の状態 – 活動中EAが将来新規発注しない保証ではありません。

時刻は例えば2026年10月26日21:00 JSTの同期後観測と明記します。JSTはUTC+9で国内夏時間なし。「建玉0・待機注文1」と「建玉0・待機注文0」も別の状態。後者でも自動発注元が活動中なら将来の無建玉を保証しません。

理解度を確認

練習の目安: 約2分.

Close ByでAとB、通常決済でCとEが終了。Dは拒否されました。元の建玉はいくつ残りますか。

答えと解説を見る

正解。四チケットが終了し、Dには確認済み決済がありません。

よくある質問

全決済で待機注文も消えますか。
建玉の決済を待機注文の取消確認とは扱いません。MT5には別の削除操作があります。正しい口座で両一覧と履歴を確認し、選択コマンドと観測時刻を記録します。取消が未解決なら建玉一覧が空でも結果不明です。待機注文の約定と削除は別イベントで、後の約定が新建玉を作る場合があります。
端末を閉じれば一括操作は取り消されますか。
確認済み約定は戻りません。残りの処理が止まり、未決済建玉が残る場合があります。終了前に送信した要求のサーバー結果を確認。アプリ中断を全要求の取消や全決済完了とせず、ログを保存し同期後の数量を履歴に照合します。再起動だけでは口座リスクが消えたといえません。
利益建玉だけを閉じるコマンドがないのはなぜですか。
口座種類、選択建玉、設定で一覧が変わります。FIFO制約と両立しない一括操作は非表示とMT5資料にあります。One Click Tradingと完全な機能名も確認。これだけで業者の故障とはせず、追加ソフトなら標準と同じ機能名でも独自の可用性と仕様を調べます。
エラー後に全決済をもう一度押せますか。
旧数量を記憶で再送する前に現状を確定します。決済・部分減少・EAの新規建玉が混在し得ます。拒否と確認欠落を分け、残チケットと数量、過去要求の解決を照合して現在のリスクへの対応を検討。次の一括操作も新たな対象範囲と約定条件を持ち、旧一覧を自動で完了するものではありません。

出典と検証

  1. www.metatrader5.com

    内容の参考資料。記事に記載した範囲と前提を確認してください。

  2. www.mql5.com

    内容の参考資料。記事に記載した範囲と前提を確認してください。

  3. www.mql5.com

    内容の参考資料。記事に記載した範囲と前提を確認してください。

  4. www.mql5.com

    内容の参考資料。記事に記載した範囲と前提を確認してください。

計算例には前提条件を明記しています。現在の市場データや提供会社の取引条件の代わりにはなりません。

著者について

Jarosław Wasińskiはポーランドの編集者・市場アナリストです。2004年にMyBank.plを設立し、2007年から外国為替市場の分析に携わっています。