MT4・VPSの障害対策と安全なバックアップ・復旧

復旧するのは取引環境であり、過去の口座状態ではない

主な手順は、通常のWindows VPSでMT4を動かす場合を対象としています。MetaTrader内蔵の仮想ホスティングでは操作が異なるため、後の専用セクションで違いを説明します。計画では、ブローカーの口座、端末のローカル設定、EAの実行時の状態を分けて考えてください。

フォルダーを復元しても、ブローカーがすでに処理した取引を取り消すことはできません。また、保存済みのチャートがあるだけでは、そのEAが再起動後にバスケットの管理を安全に再開できるとはいえません。目的は同じ見た目のデスクトップではなく、各注文の管理担当が明確な、検証済みの稼働状態です。復旧は運用上の中断を減らしますが、市場リスクをなくしたり約定を保証したりするものではありません。

初動対応：障害を拡大させない

1. 障害を記録する。検知時刻とタイムゾーン、対象の口座・サーバー・端末、最後に正常動作を確認した内容、最近の変更を記録します。通知が届かないことやRDP接続が切れたことは症状であり、診断結果ではありません。
2. 口座のエクスポージャーを確認する。正当にアクセスできるブローカーの口座画面、またはEAがないか取引できない別の監視用端末を使います。現在のポジション、未決済の指値・逆指値注文、受け付け済みの保護水準を確認し、口座状態が不明ならブローカーに問い合わせます。
3. すべての取引環境を特定する。メインVPS、自宅のPC、予備端末、内蔵ホスティング、取引コピーサービスも含めます。メイン環境に接続できないという理由だけで、別の自動取引環境を起動しないでください。
4. 介入の範囲を決める。証拠を保存し、障害が起きた層を特定して、文書化された障害対応計画に従います。再起動や停止の前に、ローカルEAの管理に依存するポジションを誰が管理するか決めます。

通常のMT4でAutoTradingを無効にすると、その端末のEAによる取引操作が禁止されます。ポジションの決済、ブローカーの注文の削除、別のホストの停止は行われません。EAが管理する決済を中断する場合もあります。そのため再起動は口座に影響する運用上の判断であり、影響のない診断ボタンではありません。

再インストールの前に障害箇所を切り分ける

個別の設定や注文エラーはEAエラーのガイドを参照してください。この表は問題の層を切り分けるためのもので、各症状の原因が1つだけであることを保証しません。

チャート上のEAでも注文を管理できない場合がある

予定の銘柄と時間足、EAのバージョン、承認済みInputs、初期化の成功を確認します。口座やライセンスの要件を確認し、推測した値で置き換えないでください。プロファイルの変更、カスタムインジケーターの欠落、DLL/WebRequestの依存関係により、価格が届いていても動作が変わる場合があります。

• 端末・EAの許可に関するエラーと、ブローカー・口座の制限を区別します。コード133は取引が無効であることを示しますが、押すべきローカルのボタンは特定しません。
• コード6は取引サーバーへの接続がないこと、コード146は取引コンテキストが使用中であることを示します。再起動や要求の送信を繰り返すのではなく、実際のメッセージと前後の出来事を調べます。
• コード128や、応答が失われた・不確かな取引では、再試行の前にサーバー側の結果と照合します。ローカルの確認がないだけでは、ブローカーが要求を拒否したとはいえません。

診断用の取引を無理に発生させるために、スプレッド、セッション、ポジション、リスクのフィルターを外さないでください。EAに有効なシグナルがなければ、復旧に成功しても新規ポジションは発生しない場合があります。既存注文の管理と新しいデータの受信は、無理な新規エントリーより有用な確認材料です。

自動取引の再開前にブローカーの注文記録と照合する

接続済みの監視環境で、Tradeから保有ポジションと未決済の指値・逆指値注文を確認します。Account Historyから障害中の取引を確認し、対象期間を確実に含む日付範囲を選びます。記録が食い違う、またはアクセスが不完全な場合は、再構成が完了したと判断する前にブローカーに確認します。

• チケット、正確な銘柄、売買方向、数量、エントリー時刻、受け付け済みStop Loss/Take Profitを障害記録と照合します。端末を停止してもブローカーが保持する注文は消えません。指値・逆指値注文は障害中にも発動する場合があります。
• EAの文書にある銘柄・Magic Numberのルールに従って、管理担当を特定します。古い注文をEAから見えなくするために識別子を変更しないでください。
• 端末が使えない間に注文が決済・変更されたかを確認します。バックアップやログに残っているという理由だけで、過去のポジションを再作成しないでください。
• そのEAがバスケット、トレーリングのロジック、仮想決済などの状態をどう再構成するか確認します。非対応または不明な場合は、有効にする前に開発元の復旧手順に従います。

ブローカーが受け付けたStop Loss/Take Profitの水準はサーバー側に残ります。MT4のTrailing Stopの更新やEAの仮想決済には、管理する端末・EAの稼働が必要です。最後にサーバーが受け付けたストップと、その後のローカルでの継続的な更新は別物です。保護水準は約定価格を保証せず、特に価格のギャップやブローカーの障害時には注意が必要です。

障害を説明するための証拠を保存する

表示の消去、スナップショットの復元、再インストールの前に、関係するExpertsとJournalの記録を保存します。端末が応答する場合は、各タブのOpenでログの場所を開き、バッファーをディスクに書き出します。EAログは通常、実際のデータフォルダー内のMQL4/Logs、端末ログはlogsにあります。

端末の識別情報、エラーの本文・コード、対象注文のチケット、最後に成功した初期化、接続の変化、最近のWindowsやEAの変更を記録します。各情報源の時計とタイムゾーンを記録し、出来事の順序を判断する前にWindows、端末、ブローカーの時刻をそろえます。ExpertsとJournalのガイドも参照してください。

サポートには調査に必要な部分のログと設定だけを送り、認証情報や無関係な口座情報を除いてください。VPS提供元にはVMのイベント、ブローカーには注文・サーバーの詳細、EA開発者には初期化や状態のエラーが必要になる場合があります。先に再起動を繰り返すと、元の障害と復旧による副作用を区別しにくくなります。

依存関係を含む復旧パッケージを用意する

使用予定の各端末について、インストール先とWindowsユーザーを記録し、File → Open Data Folderで実際のデータの場所を確認します。バックアップと一緒に一覧を保存してください。ショートカットやブローカー名の付いたフォルダーだけでは正確な対応表になりません。

ブローカーの実際の注文記録は再接続後に照合するもので、このパッケージから復元するものではありません。設定と証拠を安全に保管し、復旧用の認証情報を公開チェックリストやサポートへの添付に含めないでください。

プリセット・テンプレート・プロファイルの役割を理解する

EAのInputsタブでは、Saveで対応する外部パラメーターを保存し、Loadで保存済みプリセットを適用します。対応するEAのバージョンも記録してください。別バージョンで入力名や既定値が変わると、結果が変わる場合があります。見覚えのあるファイル名だけを信頼せず、読み込んだ値を確認します。

.tplテンプレートはチャート設定を保存し、EAとそのパラメーターを含む場合があります。プロファイルはチャートのグループを表します。どちらも、対応する実行ファイル、依存関係、開発元固有の状態の代わりにはなりません。作業環境の変更に応じてプロファイルも保存されるため、誤操作による変更が現在のプロファイルになる場合もあります。

• 確認済みのプリセット、テンプレート、プロファイル記録には、日付・バージョン付きの名前を付けます。
• 正確な銘柄、時間足、予定の注文管理ルールを別に記録します。
• 復元したチャートは、検証前に自動取引が始まらない管理された環境でのみ適用します。復元した設定に、意図せず有効になる許可が含まれる場合があります。

再起動で残る状態と再構成が必要な状態を確認する

EAはブローカーの注文から状態を求めたり、ローカル・共有ファイルを書いたり、端末のグローバル変数を使ったり、メモリーだけに情報を保持したりします。必須の状態、その保存方法、バックアップ後に開かれた注文を復旧時にどう扱うかを開発者に確認してください。すべてのEAが同じように動くと考えないでください。

端末のグローバル変数はEAコード内の変数とは異なります。永続的な端末グローバル変数は再起動後も残る場合がありますが、アクセスがなければ4週間で期限切れになります。一時的なグローバル変数は現在の端末セッションでのみ存在します。グローバル変数の一覧やプリセットのコピーだけでは、汎用的なEAバックアップにはなりません。文書化された方法で保存し、現在の注文に対して状態が新しいか確認します。

古いローカル状態がブローカーの新しい記録と食い違う場合があります。実口座のバスケット状態ファイルをデモ口座に移したり、既存取引を「リセット」するために状態を削除したり、開発元の対応表なしにMagic Numberを変更したりしないでください。EAが安全に管理を再構成できなければ、自動取引を無効のままにして不整合を解決します。

障害が起きたVPSの外に復元可能な世代を保存する

承認済み設定を日付付きの世代で保存し、保護したコピーをメインVPSの外に置きます。同じVM上のZIPはVMと一緒に失われる場合があります。提供元のスナップショットも復旧手段の1つですが、保持期間、対象範囲、整合性、利用可能性を確認する必要があります。ブローカー口座の独立したバックアップではありません。

• 承認済みの設定・バージョン・依存関係の変更後にバックアップし、EAが許容できる復元不能な状態変化の量に応じて状態のバックアップを計画します。
• 整合性を保てる、検証済みの取得方法を使います。EAが書き込んでいる間にファイルをコピーすると、異なる時点の版が混在する場合があります。必要な一時停止や正常終了はポジション管理と調整し、コピーを簡単にするだけの理由で稼働中の管理を止めないでください。
• アーカイブが開くこと、必要なファイルがあること、復元の練習が成功することを確認します。アクセスを保護し、以前の利用可能な世代を残して、破損や誤変更がすべてのコピーを上書きしないようにします。

チェックサムは信頼できる基準に対する予期しないバイトの変更を検出できますが、EAの状態が最新で論理的に整合していることは証明しません。バックアップの成功とは復元できることであり、定期処理が完了と表示しただけではありません。

停止時間と状態の損失に別々の目標を設定する

目標復旧時間（RTO）は、予定のサービスを復旧するまでに許容しようとする停止時間です。目標復旧時点（RPO）は、失っても許容しようとする過去の状態変化の範囲です。EAの実際の管理要件に応じて設定し、手順とバックアップ頻度で達成できるか検証します。

これらは仮の時刻であり、実測した復旧結果やRTOの保証ではありません。20分は失われた可能性のあるローカル状態の変化に関する時間です。ブローカーが受け付けた注文は、引き続き現在の記録で確認します。12分は停止時間です。バックアップ間隔を守っていても、EAがその状態と口座を照合できなければ復旧は失敗する場合があります。

管理された環境で復元する

1. 元の環境が取引できないことを確認する。確認済みの操作で停止または隔離し、自動再有効化を防ぎます。単に接続できないだけなら、代替環境の自動取引を開始する前にその不確実性を解消します。
2. クリーンな監視・準備用端末を用意する。ブローカーが指定するMT4と正しいWindowsユーザーを使います。復元したEAのプロファイルや設定を入れる前に、自動取引を無効にします。初期確認では実口座の認証情報を入れないか、対応する読み取り専用の監視ログインを使い、実際のアクセス制限を確認します。
3. 新しいデータフォルダーを特定する。File → Open Data Folderを使います。元のバックアップを変更せず、選定した文書化済みファイルを復元してください。新しい設定全体を無条件に上書きしないでください。
4. 承認済みプログラムと入力値を復元する。バージョン、正確な銘柄・時間足、依存関係、ライセンスを確認します。自動取引を無効のままにし、古い設定ファイルで確認済みの許可設定が知らないうちに置き換わらないようにします。
5. 状態と注文を検証する。文書化された手順で、永続状態をブローカーの現在のポジション、未決済の指値・逆指値注文、障害中の履歴と比較します。管理を再開する前に不一致を解決します。
6. 受け入れ確認を完了する。必要なデータ、初期化、許可、管理担当、ログ、通知、起動条件を確認します。手順は事前にデモで検証し、実口座の状態を練習用口座へコピーしないでください。
7. 予定の取引環境を1つだけ承認する。文書化された引き継ぎに従い、旧環境が引き続き取引できないことを確認します。予定の正当な取引用ログインを設定し、口座変更時の保護と最終的な許可を再確認して、検証済みの代替環境だけを有効にします。既存注文の管理を監視し、時刻と結果を記録します。

重要な状態、注文の管理担当、ブローカーへのアクセス、元の環境の停止を確認できない場合、手順は未完了です。代替環境の自動取引を無効のままにし、未解決の問題を具体的に担当先へ連絡します。terminal.exeが動いていることや、復元したチャートの見た目だけでは不十分です。

2つ目の管理担当を稼働させずに予備環境を準備する

設定、依存関係、アクセスを事前に検証した予備VPSは、準備作業を減らせます。引き継ぎ条件が満たされるまでは取引できない状態に保ってください。同じブローカー口座の2つ目のVPSには、重複注文を防ぐロック機能はありません。

• メイン、予備、その他すべてのホストと、それぞれの停止方法・自動再起動の防止方法を記録します。
• メインが停止しているか、取引から実効的に隔離されていることを確認します。提供元が確認した電源操作や検証済みの停止は、RDPの失敗やハートビートの欠落だけより強い証拠です。
• ブローカーの注文とEAの状態を照合し、代替環境の確認を完了してから有効にします。メインが戻ったときも稼働する管理担当は1つに保ち、両方の起動手順が取引を再有効化しないようにします。

VPSを変えてもブローカーのサーバー障害は修復できず、広域障害中のアクセスも保証できません。メインの取引状態が不明なら、未検証の切り替えを安全だと判断しないでください。その状態を確認する間も、口座の障害管理計画に従います。

MetaTraderの仮想ホスティングに合った操作を使う

MetaTrader内蔵のホスティングはWindows VPSのデスクトップではありません。リモートの状態と、取得を要求した端末・Expertsのログを使って調査します。Stop Serverは仮想端末を停止します。別の場所で代替環境を有効にする前に、停止状態が報告されていることを確認してください。ローカルのAutoTrading切り替えでは、ホスティング先のEAは停止しません。

移行はローカル環境から仮想端末への方向のみで、復旧用のエクスポートとして逆方向に戻すものではありません。ホスティング先では、ローカルの取引許可を無効にしていても自動取引が許可されます。準備済みで無効化した実口座の復旧環境を、リモートでも無効のままだと考えて移行しないでください。同期前に予定の環境と口座の状況を検証します。そこではDLL呼び出しはサポートされません。

手順を練習し、受け入れ確認を記録する

正当に使用できる別のデモ環境で、端末の終了、OSの再起動、依存ファイルの欠落、保存済みパッケージからの復元、メインから予備への管理された引き継ぎを練習します。デモと実口座の口座情報、ライセンス、状態ファイルは分けてください。実際に試した内容、限界、結果を記録します。デスクトップ上の練習は、将来の実口座での約定を証明しません。

障害後は、原因、復旧作業、解決した不一致、次の練習に向けた改善を文書化します。技術的な問題を隠すために戦略のリスク規則を変えるのではなく、ガイド2を使ってリソースや起動の弱点を修正してください。

バックアップと復旧のよくある質問

VPSのスナップショットを復元すると取引口座も元に戻りますか？

いいえ。提供元が文書で定めた範囲のローカル環境が復元されます。ブローカーの取引は引き続き現在の記録に基づいて確認します。EAの古いローカル状態は、その記録と照合する必要があります。

.setファイルだけでEAをバックアップできますか？

いいえ。保存されるのは対応する外部入力値です。対応するプログラムのバージョン、必要なインジケーター・ファイル、ライセンス情報、EAの文書化された状態復旧手順も保存してください。

リモートデスクトップが使えないとき、予備VPSを起動してもよいですか？

自動取引ができない状態で調査・準備することはできます。メインの取引能力と既存注文の管理担当を確認するまで、代替環境を有効にしないでください。リモートアクセスの喪失だけでは、メインが停止したことを証明できません。

タイムアウト後に取引要求を再送すべきですか？

サーバー側の結果を確認する前には再送しないでください。保有ポジション、未決済の指値・逆指値注文、関係する履歴、ログを照合し、結果がまだ不明ならブローカーに確認します。無条件の再送は、すでに受け付けた要求を重複させるおそれがあります。

公式資料と実務上の適用範囲

プラットフォームの動作はMetaQuotesの公式文書で確認しました。障害対応の流れ、バックアップ方針、予備環境の制御、受け入れ確認は実務上の推奨事項であり、あらゆるMT4環境で検証済みの復旧ツールではありません。画面の名称は端末の言語や版で異なる場合があります。実際の表示とEA開発元の手順を確認してください。

• MetaTrader 4：データフォルダー、テンプレートとプロファイル、EAの入力値と許可。
• MetaTrader 4：ブローカーが保持する注文と端末のTrailing Stop。
• MQL4リファレンス：取引の戻りコードと端末のグローバル変数。
• MetaTrader 4：リモートホスティングの制御と移行ルール。