MetaTraderのよくあるエラー：MT4とMT5のコード、原因、サーバー側の対処法

MetaTrader のエラー報告の仕組み

MetaTrader は、MetaQuotes が文書化している固定の名前を持つ番号付きコードでエラーを報告し、その番号からリクエストが処理の流れのどこで失敗したかが分かります。MT4 と MT5 では番号体系が異なるため、同じ問題でもプラットフォームによって2つの異なるコードになります。

MetaTrader 5 では、すべての取引リクエストに対してトレードサーバーから応答が返されます。MetaQuotes はその仕組みを次のように説明しています。

"All requests to execute trade operations are sent as a structure of a trade request MqlTradeRequest using function OrderSend(). The function execution result is placed to structure MqlTradeResult, whose retcode field contains the trade server return code."
（訳：取引操作を実行するすべてのリクエストは、OrderSend() 関数を使用して取引リクエストの構造体 MqlTradeRequest として送信されます。関数の実行結果は構造体 MqlTradeResult に格納され、その retcode フィールドにトレードサーバーのリターンコードが含まれます。）— MQL5 Reference, Trade Server Return Codes, MetaQuotes（2026年10月閲覧）

MT5 のトレードサーバーリターンコードは 10004（TRADE_RETCODE_REQUOTE）から 10046（TRADE_RETCODE_HEDGE_PROHIBITED）までです。MetaTrader 4 では、同種の情報は GetLastError() から得られます。取引関連のコードは低い範囲（0～150、たとえば 130 ERR_INVALID_STOPS）にあります。プログラムの実行時エラーは 4000 から始まります（たとえば 4109 ERR_TRADE_NOT_ALLOWED）。

成功コードは、注文が約定したことと同じではありません。OrderSend() に関する MQL5 リファレンスは、「OrderSend() 関数の結果が成功であっても、注文が執行されたことを意味しない」と注意を促しています。これはリクエストが以降の処理のために受け付けられたことを意味するだけです。顧客から「OK と表示されたのに何も起きない」と言われた場合は、サーバージャーナルを確認してください。

実際のコードを確認できる場所は3つあります。

• 「操作履歴」（Journal）タブ（プラットフォームのイベント：接続、ログイン、注文リクエスト）。
• 「エキスパート」（Experts）タブ（エキスパートアドバイザーやスクリプトが出力したメッセージ。GetLastError() の結果を含む）。
• ディスク上のログファイル。MetaQuotes の MT5 ヘルプには、「プラットフォームのログファイルは Logs ディレクトリに保存され、エキスパートのログファイルは MQL5\Logs に保存されます。ファイル名はジャーナルが生成された日付（YYYYMMDD.LOG）に対応します」と記載されています。

内蔵のログビューアーでは、「Full, No connection, Errors only」（すべて、接続なし、エラーのみ）でエントリーを絞り込むことができます。

接続エラー："No connection" と "Invalid account"

"No connection" は、ターミナルが指定されたトレードサーバーのアドレスに到達できないことを意味し、"Invalid account" は、サーバーには到達したもののログインが拒否されたことを意味します。それぞれ必要な確認事項が異なり、ブローカーにはトレーダーには見えないものが見えます。

トレーダーが確認できること

1. ブラウザでインターネット接続が機能していることを確認します。
2. ログイン、パスワード、正確なサーバー名を入力し直します。MT5 ヘルプには、アドレスを「[サーバー番号]:[ポート番号]、たとえば 192.168.0.1:443」の形式で手動入力することもできると記載されています。
3. パスワードがマスターパスワードであることを確認します。MetaQuotes は、「投資家パスワードでの認証では、口座の状態の確認、価格の分析、自身のエキスパートアドバイザーの操作はできますが、取引はできません」と説明しています。
4. プロキシとファイアウォールを確認します。MT5 では、「ツール」>「オプション」の サーバータブに「サーバー接続の設定、プロキシサーバーの設定」があります。
5. ログビューアーを開き、"No connection" で絞り込み、YYYYMMDD.LOG ファイルをブローカーに送ります。

ブローカーがサーバー側で確認すべきこと

• すべてのアクセスポイントへの到達性。サーバーリストで公開しているアドレスとポートを、自社ネットワークの外から1つずつテストし、複数の地域からテストします。
• 最近のインフラ変更。新しい IP、DNS レコード、データセンターの移転、DDoS 対策のルールは、"No connection" が一斉に発生する原因になりがちです。
• サーバーの健全性。トレードサーバーとアクセスサーバーの CPU、メモリ、ディスク。過負荷は、完全な切断に至る前にタイムアウト（128 ERR_TRADE_TIMEOUT、10012 TRADE_RETCODE_TIMEOUT）として現れます。
• 口座の状態。口座は有効か。正しいグループに属しているか。移行中に移動されていないか。パスワードの強制変更がオンになっていないか。MT5 ヘルプでは、「パスワードの強制変更はトレードサーバーの管理者が有効にできます」と明記されています。
• 古いクライアントのビルド。5 ERR_OLD_VERSION（"Old version of the client terminal"、クライアントターミナルのバージョンが古い）は、ターミナルの更新が必要であることを意味します。

ネットワークやホストのより深い問題については、FX サーバーのトラブルシューティングおよび MetaTrader サーバーホスティングをご覧ください。

MT4 のエラーコードと対応する MT5 のコード

MT4 の取引エラーは、MetaQuotes が MQL4 リファレンスに掲載している小さな番号を使用しており、そのほとんどに直接対応する MT5 のコードがあります。顧客がプラットフォーム間を移る場合や、MT4 から MT5 への移行中に両方のサーバーを運用する場合は、以下の対応表をご利用ください。

この対応表は当社の実務上の目安であり、MetaQuotes の公式な表ではありません。説明文そのものは MQL4 の Trade Server Return Codes ページから引用しています。

トレードコンテキストのビジー（146）は MT4 特有のエラーです。MQL4 の関数 IsTradeContextBusy() は、「取引用のスレッドが別のエキスパートアドバイザーによって使用されている場合に true を返します」。これはクライアント側の問題です。1つのターミナル内で複数の EA が取引スレッドを奪い合っている状態であり、対処法はリトライ処理を入れるか、ターミナルあたりの EA を減らすことです。ブローカーがサーバー上で解決することはできません。

自動売買と権限に関するエラー

自動売買のエラーは名前ではっきり区別できます。10026 はサーバーが無効化したことを、10027 はクライアントターミナルが無効化したことを示します。MT4 では、クライアント側の同等のエラーは実行時エラー 4109 です。

プラグインもリクエストをブロックしたり書き換えたりすることがあります。注文を拒否するリスクプラグインやルーティングプラグインは、顧客には一般的な拒否（10006）または一般的なエラー（2）として表示されます。プラグインの更新後に拒否が始まった場合は、まずそのプラグインを確認してください。当社はこれらを MetaTrader プラグイン開発の一環として開発・保守しています。

場当たり的な対応から監視へ

繰り返し発生する MetaTrader のエラーの多くは、顧客から苦情が来る前にサーバーログで検知できます。そのためには、個別のチケットではなくエラー発生率を監視します。1つのシンボルでの 10021 の増加、特定のセッション中のタイムアウト、ブリッジ再起動後の拒否は、いずれも発生から数分でログに現れます。

FXSUPPORT は、ブローカーとプロップファーム向けに MT4/MT5 のプラットフォームサポートを提供しています。セットアップ、アップデート、バックアップ、設定、ログ監視、ブリッジの設定が対象です。また、英国とオランダのサーバーインフラも、監視と稼働率目標99.9%のもとでカバーしています。実際には、当社は次のことを行います。

• 障害だけでなく、エラーのパターンについてもプラットフォームとブリッジのログを監視する。
• 変更のたびに、また DST の切り替え前に、シンボル、セッション、グループの設定を見直す。
• プラットフォームの更新後にプラグインの動作を確認する。
• サーバーを DDoS に対して強化し、バックアップを復元可能な状態に保つ。

ブローカーを運営していて、サポートチームが同じエラーのチケット対応に追われているなら、それは原因がサーバー側にある兆候です。対応範囲については MT5 サポートおよび MT4 サポートをご覧いただくか、無料技術レビューのためにお問い合わせください。