MT5「Trade context busy」エラーの原因と即時対処法

Trade context busyとは

MT5で「Trade context busy」は、プラットフォームの取引処理部分（Trade context）が他のリクエストを処理中で、新しい取引リクエストを受け付けられない状態を示すメッセージです。「取引コンテキストがビジー状態」という意味で、MT5/MT4の内部設計に由来する制限のひとつです。

MT5では取引コンテキストは1つしかなく、同時に1つの取引操作しか処理できません。複数のEAやスクリプトが同時に取引リクエストを送ると、先に処理中のリクエストが完了するまで他のリクエストは待機状態になります。この仕組みは注文の整合性を保つために必要なものですが、複数EA運用時には「busyエラーで注文が通らない」というトラブルの原因になります。

このエラー自体はシステム障害ではなく、MT5が正常に動作している証拠でもあります。ただし頻発すると、スキャルピングEAや複数通貨ペアを同時に扱うEAでは致命的な機会損失につながるため、適切なハンドリングが必要です。

Trade context busyの主な原因

1. 複数のEAが同時に注文を出そうとしている：複数のチャートに異なるEAを設置している場合、ティック（価格更新）のタイミングが重なると同時にOrderSendが呼ばれることがあります。特に指標発表時は全EAが同時に反応しやすい。
2. 手動注文とEAの注文が競合：EAが動いている最中に手動で注文を出そうとした場合、EAのティック処理と競合してbusy状態になります。
3. スクリプトの実行中：一括決済スクリプトなどが大量の注文を処理している最中に別の注文を出そうとした場合。特に数十ポジションの一括決済は数秒間取引コンテキストを占有します。
4. EA内でのループ処理：1ティック内で複数回OrderSendを呼ぶ構造になっているEAは、自身のリクエスト処理中に次のリクエストを送ってしまいbusyを招きます。
5. サーバー応答遅延：ブローカーのサーバー応答が遅く、1件の注文処理が長引くと後続のリクエストが待機になります。

解決手順

// MT5の例
MqlTradeRequest request;
MqlTradeResult result;
// ... requestの設定 ...

int retries = 5;
for(int i = 0; i < retries; i++) {
    if(OrderSend(request, result))
        break;
    if(result.retcode == TRADE_RETCODE_ERROR)
        Sleep(500); // 500ms待ってリトライ
}

EA開発者向け：Sleep間隔の目安と指数バックオフ

リトライ時のSleep間隔は、短すぎても長すぎても問題があります。以下の目安を参考に、自分のEAの取引頻度に合わせて調整してください。相場の状況によって最適値は変わるため、バックテストで検証することが重要です。

• スキャルピングEA：100〜300ms。短時間での約定が必須。
• デイトレードEA：500〜1000ms。最も汎用的なバランス。
• スイングEA：1000〜3000ms。約定タイミングの数秒ズレは許容。
• 指数バックオフ実装：初回500ms、失敗したら1000ms、次2000ms…と倍々で延ばす。最大値は5000ms。
• 最大リトライ回数：3〜5回に制限。それを超えたら処理を中止してログ出力。

根本対策：EA運用構成の見直し

Trade context busyを根本的に減らすには、EAの運用構成そのものを見直すのが効果的です。以下のいずれかの手段を組み合わせることで、busy発生率を大幅に下げられます。

• MT5インスタンスを複数起動：重要EAと副次EAを別プロセスで動かす。それぞれ独立した取引コンテキストを持つ。
• Mutex（相互排他制御）をグローバル変数で実装：EA間で「取引中フラグ」を共有し、他のEAが取引中なら自分は待機する。
• ティック処理の軽量化：OnTick内の処理を短時間で完了させる。重い計算はOnTimerに移す。
• VPS上で運用：ping値30ms以下の環境にすることで1件あたりの処理時間が短縮。
• EA数を絞り込み：同時稼働EAを3〜5個以内に制限。

よくある質問（FAQ）

類似エラーとの違い

• Trade context busy：取引コンテキスト競合。クライアント側の問題。→ リトライ実装。
• 137（Broker busy）：ブローカー側の混雑。サーバー側の問題。→ 時間を置く。
• 141（Too frequent requests）：注文連打で制限。→ 1分以上待機。
• 10014（Invalid volume）：ロット仕様違反。→ ロット調整。
• 10018（Market closed）：市場休場。→ 取引時間外のため待機。

Trade context busyと137の違いを正しく理解することが重要です。busyは自分の環境側（クライアント）の問題なのでEA実装で解決可能。一方137はブローカー側の問題なので時間を置くしかありません。両者を混同してリトライ処理を過剰に走らせると、さらにbusyを悪化させるため注意してください。

実装前の確認ポイント

busy対策のリトライロジックを追加する前に、以下の項目を確認しておきましょう。間違った条件でリトライを入れると、本来回避すべきエラーまでリトライしてしまい、二重注文などの致命的な問題に発展します。

• retcode別のハンドリング：busy以外のエラー（10018, 10019等）でリトライしない。
• PositionsTotal()の確認：リトライ前に既に注文が通っていないか確認。
• ログ出力：全てのリトライ試行をログに記録。後で原因分析が可能になる。
• テスト環境でのバックテスト：MT5ストラテジーテスターで事前検証を必ず実施する。
• 通知設定：リトライ上限到達時にメール・プッシュ通知を送る設定にしておくと、異常検知が早期にできる。