MetaTraderサーバーのトラブルシューティング：MT4/MT5ブローカー向けインシデント手順書

MT5 サーバーがダウンしているのか、それとも1人の顧客の問題か

「MT5 サーバーがダウンしている」という報告の多くは、全面的な障害ではありません。1人の顧客、1つのネットワーク、1つのシンボルに限られた問題です。誤った再起動によって部分的な問題が全面的な障害に変わることがあるため、誰かがサービスを再起動する前に、問題の範囲を確認してください。

各ブローカー（またはそのホワイトラベル／グレーラベルのプロバイダー）が自社のサーバーを運用しており、MetaQuotes はソフトウェアを提供しています。

You independently deploy our software on your own hardware, as well as maintain your server infrastructure and fully control support and administration.
（訳：お客様は、当社のソフトウェアをご自身のハードウェアに独自に導入し、サーバーインフラを保守し、サポートと管理を完全にコントロールします。）— MetaQuotes, MetaTrader 5 for Brokers（2026年10月閲覧）

MetaQuotes はライセンスページで、「お客様のサーバー、口座、顧客の取引履歴にはアクセスできない」と付け加えています（metatrader5.com）。トレーダーの方はご利用のブローカーにお問い合わせください。ブローカーを運営している場合は、本ページの以下の内容が手順書となります。

範囲を確認するための4つの簡単な質問：

• 誰が？1つの口座、1つのグループ、1つの IB の顧客、1つの国、それとも全員か。
• どこで？デスクトップ、モバイル、WebTrader、またはその3つすべてか。マネージャー端末や管理者端末も影響を受けているか。
• 何が？ログインできない、クオートがない、クオートが止まっている、注文が拒否される、執行が遅い、スワップやセッション時間が誤っている、のどれか。
• いつから？過去24時間で何が変わったか。

すべてのデバイスで全員が影響を受けている場合はトレードサーバーまたはその手前のネットワーク、1つの地域ならアクセスサーバー、1つのシンボルならデータフィード、クオートは流れているのに注文が失敗する場合はブリッジ、リクイディティプロバイダー、またはプラグインが疑われます。

最初の15分：トリアージの手順

毎回同じ順序で進めます。範囲、重大度、ログ、最近の変更、そして判断です。インシデント後のレビューのために、各ステップにタイムスタンプを残してください。

1. インシデント記録を作成する。最初の報告時刻と正確なエラーを記録します。
2. 範囲を確認する。社内のテスト口座を使い、デスクトップ、モバイル、ウェブで確認します。
3. 重大度を設定する。下の表を用い、再起動と顧客へのメッセージを判断するインシデントリーダーを1人指名します。
4. ログを読む。トレードサーバー、アクセスサーバー、フィード、ブリッジの直近30～60分のログを確認します。
5. 最近の変更を洗い出す：プラグイン、設定、サーバービルド、証明書、ファイアウォール、DNS、ホスティング。
6. 判断する：直近の変更をロールバックする、フェイルオーバーする、コンポーネントを切り離す（シンボル、経路、プラグインを無効化する）、またはベンダーにエスカレーションする。
7. 連絡する。何が影響を受けているか、次回の更新はいつかを伝えます。

まずログとリターンコードを読む

ログを見れば、「サーバーがダウンしている」という報告を特定のコンポーネントと時刻に絞り込めます。同じ時間帯のトレードサーバー、アクセスサーバー、フィード、ブリッジのログを取得し、タイムゾーンを揃え、最も目立つエラーではなく最初のエラーを探します。

クライアントターミナルにも証拠が残ります。MetaTrader 5 はプラットフォームのイベントを「操作履歴」（Journal）タブに書き込み、そこには「ソース」列（たとえば「Network」）と、ログファイルのフォルダを開くコンテキストメニューのコマンドがあります。エキスパートアドバイザーのイベントは「エキスパート」（Experts）タブに記録されます（MetaTrader 5 Help: Platform Logs）。

顧客やエキスパートアドバイザーが報告するコードから、障害箇所をすばやく特定できます（MQL4 および MQL5 の公式リファレンス）。

多数の異なる顧客が同じ分に同じコードを報告している場合、原因はほぼ必ずサーバー側にあります。より詳しい一覧は MetaTrader のよくあるエラーのガイドを、体系的なログ分析については MetaTrader のログ分析をご覧ください。

データフィードの問題

クオートが止まれば、取引も止まります。MetaQuotes 自身の MT4 ヘルプは、次のように端的に述べています。

If a client terminal does not receive quotes, it is impossible to trade with it.
（訳：クライアントターミナルがクオートを受信していない場合、そのターミナルで取引することはできません。）— MetaQuotes, MetaTrader 4 Help: Settings, Server（2026年10月閲覧）

フィードは、フィーダーとゲートウェイを通じて MetaTrader に届きます。MetaQuotes は MT4 DataFeed API を「あらゆるニュースおよびクオートのデータフィードの開発向けに設計された」ものと説明し（MetaTrader 4 API）、MT5 Gateway API を「他の取引システムとの連携やカスタムデータフィードの作成」に使用するものと説明しています（MetaTrader 5 for Brokers）。確認は次の順序で行います。

1. どのシンボルが止まっているか。すべてか、1つのアセットクラスか、1つのフィードソースか。
2. 最後のティックはいつ届いたか。フィードのログに切断やログインエラーはあるか。
3. 上流のソースは他の場所には価格を配信しているか。
4. どちらか一方での最近の変更の後も、シンボル名とマッピングは一致しているか。
5. シンボルのセッションは開いているか。「止まっている」シンボルが、単にセッションのクローズ中であることもあります。

対処法は、フィーダーの再起動からバックアップソースへの切り替えまでさまざまです。価格が古くなっている間は、影響を受けたシンボルでの取引の無効化を検討してください。詳しくは MetaTrader データフィードのセットアップをご覧ください。

プラグインの競合とアップデートの問題

サーバープラグインは取引処理の経路内で動作するため、不具合のあるプラグインはログインをブロックしたり、執行を遅くしたり、サーバーをクラッシュさせたりすることがあります。MetaQuotes は、MT4 Server API で「サーバーパラメーター、注文と顧客ベースの管理、取引リクエストの処理など」を扱うプラグインを作成できると述べています（MetaTrader 4 API）。

1. インシデントの開始時刻を、プラグインの変更履歴やサーバーの再起動と比較します。
2. サーバーログで、プラグインの読み込みエラーや処理の遅延を確認します。
3. 2つのプラグインが同じイベントに対して動作していないか確認します。
4. 疑わしいプラグインの無効化は、まずステージングでテストします。本番環境では、インシデントリーダーの承認がある場合に限り行います。
5. サーバービルドの更新後は、取引を再開する前にすべてのプラグインの互換性を確認します。

長期的な対策は変更管理です。ステージングサーバー、文書化されたロールバック計画、プラグインごとに1人の担当者を置くことです。当社はプラグインを開発・保守しています。MetaTrader プラグイン開発をご覧ください。

サーバーリソース、データベース、バックアップ

執行時間が毎週長くなるといった緩やかな劣化は、通常リソースの限界を意味します。すべてのサーバーで CPU、メモリ、ディスク容量、I/O を監視し、しきい値に達する前にアラートを出してください。

• ディスク：ログと履歴は継続的に増加します。ディスクがいっぱいになると、ロギング、レポート、バックアップが同時に止まることがあります。
• バックアップ：バックアップが完了していること、そして復元をテスト済みであることを確認します。MetaQuotes は、MT5 のシステムデータベースには「バックアップと復旧のオプション」が備わっていると述べています（MetaTrader 5 for Brokers）。一度も復元したことのないバックアップは、まだ仮定にすぎません。

当社は、MetaTrader で一般的な Windows Server 環境と、ウェブ、データベース、関連システムに使用される Linux 環境の両方をサポートしています。サーバー監視、バックアップと復旧、パフォーマンスチューニングをご覧ください。

インシデントの後：レビューと規制当局

インシデントは、サーバーが復旧した時点ではなく、根本原因が判明し、再発防止策が合意された時点で終了となります。タイムライン、影響、根本原因、担当者付きの再発防止策をまとめた簡潔な報告書を作成してください。

FCA は、オペレーショナル・レジリエンス規則の対象となる企業は「2025年3月31日までに、重要な業務サービスを影響許容度の範囲内で運営できるようにする必要があった」と述べています（FCA）。EU では、ESMA が、デジタル・オペレーショナル・レジリエンス法（DORA）は「2023年1月16日に発効し、2025年1月17日から適用される」と述べています（ESMA）。特定のインシデントを報告する必要があるかどうか、またその方法は、貴社のライセンスと法域によって異なります。コンプライアンス担当者にご確認ください。本内容は一般的な情報であり、法的助言ではありません。

よくある質問