MT4のエラー146を解消してFX自動売買を安全に確認する手順

MT4で「trade context is busy」やエラー146が出たら、まず何の操作が失敗したかをログで確かめ、保有中の注文と決済状況を照合してください。ほかのEAやスクリプトによる取引処理と重なり、その時点で処理できなかった可能性があります。注文を連打したり、すべての建玉が閉じたと思い込んだりする前に、現在の口座状態を確認することが大切です。

FX自動売買では、新規注文、注文変更、決済のどれが失敗したかで対応が変わります。この記事では、MT4のエラー146の意味と、稼働中のEAを確認しながら状況を切り分ける順序を説明します。デモ口座で試せる確認方法と、EAを開発する人が再試行処理を設計するときの注意点も整理します。

MT4のエラー146とFX自動売買の原因

エラー146は取引処理が使用中の状態

MQL4公式リファレンスでは、146は「ERR_TRADE_CONTEXT_BUSY」、つまり取引コンテキストが使用中であることを示します。取引コンテキストはEAやスクリプトが取引処理を行うための領域です。別の処理が使用中のタイミングで新たな取引処理を始めようとすると、実行できない場合があります。

たとえば、同一のMT4端末で複数のEAがほぼ同時に注文や変更を試みる場面です。先の処理が完了していなければ、後の処理が146を返す可能性があります。複数口座の有無だけでは判断できず、どのMT4端末のどのEAが、いつ取引処理を試みたかを確認します。

146が一度記録されても、それだけでEA全体が壊れている、口座資金が不足している、業者が取引を禁止しているとは決められません。原因を取り違えてロットや戦略を変更すると、本来の問題を隠してしまいます。最初は表示番号とログの前後関係を調べましょう。

新規・変更・決済を分けて読む

同じ146でも、失敗した操作が何だったかで確認する注文は異なります。新規注文なら、意図した建玉や待機注文が既に存在しないかを見ます。注文変更なら、対象チケットの現在の価格や損切り・利確の値を確認します。決済なら、対象の数量が残っていないかを見ます。

一つのログ行が示すのは、その処理に関する結果です。別のEAや直前の操作まで含めた口座全体の結果を、その番号一つで断定することはできません。特に複数EAを使っている場合は、時刻、銘柄、注文番号、EA名など、記録されている識別情報を突き合わせます。

注文番号を記録していないEAでは、どの操作が対象だったかログだけで確定できないこともあります。その場合は推測で注文し直すのではなく、取引履歴と現在の建玉を照合し、必要に応じてEAの提供元や取引会社に確認します。口座番号や個人情報を問い合わせに含める場合は、送信先と必要範囲を先に確認してください。

たとえば、同じ通貨ペアに対する決済が失敗したという記録と、その直後の別EAによる新規注文の記録が並ぶことがあります。時刻が近くても、どちらも同じチケットを操作したと決め付けてはいけません。まずログの発信元と対象を対応付け、それぞれの注文状態を現在の一覧と照合します。

逆に、変更操作が失敗しても、その前に登録されていたストップ値が残ることがあります。新しい値へ変更できたという意味ではないため、変更予定だった値と現在の値を比較してください。画面に表示された数値が古い可能性も考え、表示更新後に確認し、不明なら業者側に照会します。

他のエラーや結果不明と混同しない

公式のエラー一覧では、4は取引サーバーが混雑している状態、128は取引タイムアウト、130はストップ値の不正、134は証拠金不足、146は取引コンテキストの使用中です。どれも注文できない場面に見えても、同じ原因や同じ対応とは限りません。

とくに、応答が確認できないタイムアウトと146をまとめて「待って再送」と決めるのは危険です。結果が不明な注文については、先に口座側の注文・取引履歴を確認し、結果が判明するまで同じ発注を自動で繰り返さない設計が必要です。注文が見当たらない場合も、表示遅延や照会条件の違いがないか確認します。

ログに複数の番号がある場合、時刻の新しい一行だけでなく、実行した関数、対象の銘柄、接続状況、前後の通知をまとめて読みます。146と別のエラーが続いた場合は、各操作が別だった可能性もあります。公式一覧は番号の意味を調べる出発点であり、実際の環境で何が起きたかの代わりにはなりません。

エラー番号は、コンパイル時のエラーなのか、EAの実行時に出た取引関連の番号なのかも確認します。MQL4では同じ数値が別のエラー分類に現れることがあり、数値だけで参照表を選ぶと意味を誤ります。エキスパートの実行ログなのか、MetaEditorのコンパイル結果なのかを先に区別しましょう。

146が消えた後に130や134が出た場合も、別々の失敗として確認します。たとえば処理の競合がなくなっても、価格やストップ位置、必要証拠金まで自動的に適正になるわけではありません。次のエラーについて、取引会社が示す現在の条件と注文内容を照合します。

EAが複数なくても断定しない

複数のEAやスクリプトが同じ端末で取引処理を行っていれば、重なりを確認する価値があります。ただし、画面上で見えるチャートの数だけで原因を確定できません。同じ端末の別チャート、手動操作、取引補助スクリプト、EA内部の連続処理など、実際に何を動かしていたかを時系列で確認します。

EAを一つだけ使っているつもりでも、複数チャートに同じEAを置いていたり、別の取引用プログラムが動いていたりすることがあります。一方、ログだけでは重なった処理を特定できないこともあります。「複数起動しているから必ず146になる」と考えず、仮説として一つずつ確かめます。

MT4を別の端末として複数起動していても、同じ口座であれば建玉や証拠金は共有されます。端末を分けることと注文管理を分けることは別です。口座全体の建玉、重複注文、停止後の管理方法を理解しないまま、エラー回避だけを目的に端末を増やさないようにしましょう。

MT4のエラー146をFX自動売買で切り分ける手順

ログと現在の注文を先に照合する

最初に、MT4のターミナルにある「エキスパート」と「操作履歴」を開き、146が出た時刻の前後を確認します。EA名や銘柄、操作の種類、注文番号が表示されていれば控え、単発なのか同じメッセージが連続しているのかを分けます。端末の表示時刻と業者のサーバー時刻の扱いも確認してください。

次に「取引」タブで保有中の建玉と待機注文を確認し、「口座履歴」でも該当時間帯の注文や決済を調べます。履歴の表示期間が限定されていると見落とす場合があるため、必要な期間が表示されているかも確認します。売買対象、数量、注文番号、現在のストップ設定を見て、意図した状態と一致するかを確かめます。

決済処理が失敗した場合、EAを止めたことと建玉が決済されたことは別です。現在の建玉が残っていれば、EAを外す前に、その後誰が監視・管理するのかを決めます。個別の取引操作はリスクを伴うため、内容が分からなければ取引会社やEA提供元へ相談します。

ログを共有するときは、口座番号、氏名、メールアドレス、認証情報など不要な情報を除きましょう。提供元が必要とする情報だけを、安全な窓口から渡します。ログの見方や保存方法が分からない場合は、MT4のログ保存と問い合わせ手順も参考になります。

問い合わせの際は「何時ごろ、どの端末で、どの銘柄に対して、新規・変更・決済のどれを行い、どの番号が表示されたか」を整理します。たとえば、決済を依頼した後に146が表示され、建玉が残っているのか、別の処理で数量が変わっているのかを区別して伝えます。約定結果が分からないときは、その不明点も明示してください。

複数端末を使っている場合は、問題が起きた端末のログだけでなく、同じ口座へ接続している端末で同時刻に何が動いていたかも確認対象です。ただし、別端末の存在だけで146の直接原因とは限りません。ログで分かる事実と推測を分けると、問い合わせ先も切り分けやすくなります。

停止の範囲を理解して影響を減らす

同じエラーが繰り返されるときは、まず新規注文が増え続けていないか、必要な決済が実施されているかを確認します。EAごとに「新規エントリーだけ停止」「EAの取引を許可しない」「EAをチャートから外す」などの意味が異なる場合があります。使っているEAの説明を確認し、設定を変える前に影響を把握しましょう。

自動売買を停止すると、EAが担当していた損切りや追従処理まで止まる設計もあります。サーバー側に登録済みの注文と、EAや端末が動いて初めて実行される処理を区別することが必要です。どの保護注文が有効か確認できない場合は、放置せず取引会社や提供元へ確認します。

画面の再起動やEAの入れ直しは、表示や状態を変えてしまうことがあります。再起動が必須だと決め付けず、その前にログ、設定値、稼働中のEA、建玉と待機注文を把握します。再起動を試す場合も、再接続後に同じ注文が追加されていないか、残っている注文が意図どおりかを照合してください。

停止後に確認しておきたいのは、EAを再開したときの挙動です。前回の注文を再送する設計か、すでに持っている建玉を引き継ぐか、起動時点から新しく判定するかはEAごとに異なります。提供元の説明がない場合は実口座で推測せず、デモで確認するか提供元に質問してください。

サーバーに登録された注文であっても、注文条件や市場状況によっては想定した価格で処理されないことがあります。また、端末で動く追従処理は停止・通信断で働かなくなる場合があります。いずれも一般的な注意であり、個別の注文方式や執行条件は利用中の取引会社の仕様で確かめます。

デモ口座で一つずつ条件を変える

実口座で繰り返し注文を試す代わりに、EA提供元の案内に従ってデモ口座で再現を調べます。まず一つのEAだけを使い、処理の重複が起きる条件を観察します。次に、ほかのEAや補助スクリプトを一つだけ追加し、エラー時刻と前後の処理が変わるかを比べます。

比較では、EAの版、入力値、銘柄、時間足、対象口座、MT4端末、稼働させたチャートをそろえます。一度にロットや売買条件まで変更すると、何が原因で結果が変わったのか分かりにくくなります。デモで再現しない場合も、本番では処理のタイミングや通信状況が違う可能性があるため、解決を保証するものではありません。

複数EAが異なる注文を管理しているときは、それぞれの対象銘柄やマジックナンバーなど、EAが実際に使う識別条件を確認します。番号を変えるだけで競合が必ず解消するわけではありません。注文の識別と、同じ端末で取引処理が重なる問題は別の論点だからです。

確認用の比較は「EAを一つ動かした期間」「二つ目を加えた期間」の順に行い、対象とする動作を新規、変更、決済のいずれかに絞ると整理しやすくなります。二つ目を加えた直後に146が出たとしても、それだけで特定のEAの欠陥とは断定できません。ほかの実行中プログラムや、その時点のログも合わせて見ます。

デモ検証では、新規注文の成功だけではなく、エラー後に注文が二重にならないか、変更が一度だけ反映されたか、決済後の残数量が合っているかを確認します。試験終了時に未約定の注文が残っていないかも見て、次回のテストへ影響しないよう管理します。消去や決済を行うときは対象の口座を間違えないことが前提です。

再試行は上限と再確認を設ける

EAを自作する場合、MQL4のIsTradeContextBusyは、別のEAが取引処理を使用中かどうかを確認する関数です。IsTradeAllowedは取引許可と取引処理の状態を調べるために使えます。ただし、事前確認で使用中でなかったとしても、実際の発注までに別の処理が始まる可能性があります。確認結果を予約や成功の保証として扱わないでください。

注文関数の戻り値を確認し、失敗したときにGetLastErrorでエラー番号を取得する構成にします。公式資料によるとGetLastErrorの呼び出し後、保持されていたエラー値はリセットされます。調査用に必要な番号は一度変数へ取り、ログにも操作と一緒に記録すると、後の照合がしやすくなります。

再試行を実装する場合は、エラーの種類を区別し、待機間隔、回数や期限、途中停止の条件を事前に決めます。無制限のループや連続発注は避け、時間の経過で元の売買条件が変わっていれば見送る判断も必要です。待機後は価格、注文対象、取引許可、残高や証拠金など、対象操作に必要な条件を改めて確認します。

新規・変更・決済で同じ再試行処理を使い回す場合も、現在の注文状態を照合してください。たとえば決済対象が既に別処理で変わっていれば、古い数量やチケットを前提に次の操作へ進むことはできません。結果不明を146と同列に扱わず、照合できるまで待つ状態を設けることが重要です。

EAの内部を変更できない場合は、待機回数を推測して設定ファイルを書き換えるのではなく、提供元に146発生時の動作、再試行の上限、重複注文の防止方法を尋ねます。改善後もデモでログと注文履歴を照合し、想定どおりに動くかを確認します。実口座とデモ口座では約定や通信条件が異なるため、デモの結果だけで本番の安全性を保証することはできません。

設計上は「待機中」「送信した」「結果を照合中」「中止した」を区別すると、原因を追いやすくなります。待機回数が上限に達したら次のティックで延々と同じ注文を作るのではなく、利用者が状況を確認できるよう通知し、そのシグナルをどう扱うかを決めます。具体的な状態管理はEAの設計と利用条件に合わせて検証してください。

また、このエラー番号と関数はMT4・MQL4を前提に説明しています。MT5では注文、約定、ポジションの扱いや戻り値の確認方法が異なるため、番号だけを対応させてコードを移植しません。MT5で同じような症状が出たときは、MQL5の公式リファレンスと使っている注文クラスの戻り値を確認します。

MT4のエラー146を確認した後のまとめ

MT4のエラー146は、取引コンテキストが使用中であることを示します。最初に、失敗したのが新規注文・変更・決済のどれかを確認し、ログと現在の建玉、待機注文、履歴を照合してください。その後、同じ端末のEAや補助スクリプトを確認し、デモ口座で条件を一つずつ変えて切り分けます。

自動再試行を設ける場合は、待機の上限、停止条件、現在の注文状態の再確認が欠かせません。結果が不明なときや原因を特定できないときは、重複送信を止め、取引会社またはEA提供元へ確認してから次の判断を行いましょう。