MT4/MT5アップデートで困らないために|事前準備と復旧手順

MT4 アップデートを放置する最大リスク—接続停止という実務の停止ライン

旧バージョンのMT4を使い続けることは「慣れた環境を守る」行為ではなく、接続停止というリスクを先送りしているだけだ。MetaQuotesは2025年7月1日以降、MT4 Build 1440未満・MT5 Build 4755未満の旧バージョンではブローカーサーバーへの接続を不可にすると明確に告知している。これは「非推奨」や「なるべく更新してください」という曖昧な表現ではない。ログイン自体が止まる実務上の停止ラインだ。

「何年も同じビルドで動いているから大丈夫」という感覚は、一定期間は通用するが、ある時点で突然通用しなくなる。MetaQuotesがBuild基準を設けた背景にはセキュリティ改善とプロトコル更新がある。Build 1440/1460は単なるバグ修正ではなく、セキュリティ強化・通信の安定性向上・APIの刷新を含む更新だ。古いビルドでは新しいサーバー側プロトコルに対応できなくなるため、接続切断の問題が起きる。

特に問題になりやすいのはVPS上で動かしているMT4だ。手元のPC版は意識的に更新していても、VPS側の更新を後回しにしているケースが多い。本番環境がVPSである場合、VPS上のMT4が旧ビルドのままになっていると、ある日突然EAが稼働しなくなるという事態が起きる。VPSと手元のローカル環境でビルドが揃っているかを定期的に確認することが、実務リスクの管理の基本になる。

MT5も同様だ。Build 4755を境にした告知は同時期に出ており、MT5ユーザーも例外ではない。MT4よりもMT5のほうが更新頻度が高く、各ビルドの変更範囲も広い。特にBuild 5640ではtick history同期の修正、Build 5660ではproxy通信の改善とSOCKS4非対応化、OpenBLASライブラリの別ファイル化という実務影響の大きい変更が含まれている。「更新しないほうが安定」という発想は、MT5においては特に通用しない。

要するに、旧バージョン放置は守りの姿勢ではない。安定運用を続けるためにこそ、Build基準を把握してアップデートを正しく管理することが必要だ。

Live Updateは止められない—更新回避より更新耐性を作る発想へ

MT4のLive Updateは、サーバー接続時に新しいバージョンを確認し、バックグラウンドで自動ダウンロードする仕組みだ。MetaTrader 4の公式ヘルプでは、このLive Updateは常に有効で無効化できないと明記されている。つまり「更新したくない」という選択肢は、公式的には存在しない。

これを知らずに「更新しないようにしたい」と考えているトレーダーは多い。特にEAやカスタムインジケーターが安定動作しているときほど、「今の状態を維持したい」という心理が働く。しかし実際には、次にMT4をサーバーに接続した瞬間から更新プロセスが走る可能性がある。更新を物理的に完全に止める方法は基本的に存在しない、というのが公式の立場だ。

だとすれば、考え方を変える必要がある。「更新を避ける運用」から「更新があっても壊れない運用」へのシフトだ。更新耐性を作るとは、具体的には以下のような意味を持つ。

まず、EAやインジケーターのファイルを常に最新の状態でバックアップしておくこと。更新によってコンパイルエラーが出ても、元ファイルがあれば対処できる。次に、動作確認の手順を定型化しておくこと。更新後に何を確認すればいいかがリスト化されていれば、問題の発見と対処が早くなる。そして、本番環境と検証環境を分けておくこと。本番機と検証機が同じでは、更新の影響を本番に直撃させることになる。これについては後のセクションで詳しく説明する。

Live Updateを止めようとする努力より、更新が来ても実務が止まらない仕組みを作る努力のほうが、時間対効果が高い。更新が来ることを前提にした運用設計が、現実的な実務管理の出発点だ。

また、MT5のLive Updateも同様の仕組みで動いている。MT5はMT4より更新頻度が高く、各更新で変更される範囲が広い傾向がある。MT5ユーザーはより頻繁に更新耐性を意識した運用が必要になる。

更新前にやるべき事前準備—「戻れる状態」を作ること

MT4 アップデートで事故が起きる大半のケースは、更新自体の問題ではなく「準備なし更新」が原因だ。更新前に正しい準備ができていれば、更新後に何か問題が起きても短時間で対処できる。逆に、何も準備せずに更新を迎えると、問題の原因特定から始まることになり時間を大きく失う。

更新前に行うべき準備は以下の順序で実施するとよい。

1. 現在のBuild番号の確認
MT4のヘルプメニュー→「MetaTrader 4 について」でBuild番号が確認できる。MT5も同様だ。現在のビルドを把握しておくことで、更新後に何が変わったかを追跡できる。MetaQuotesのリリースノートと照合することで、今回の更新でどの機能に変更が入ったかを事前に把握できる。

2. EAおよびカスタムインジケーターのバックアップ
MT4のデータフォルダ（ファイルメニュー→「データフォルダを開く」）にある MQL4/Experts/ および MQL4/Indicators/ の内容をそのままコピーしておく。MT5の場合は MQL5/Experts/ と MQL5/Indicators/ が対象だ。ソースコード（.mq4/.mq5）と、コンパイル済みファイル（.ex4/.ex5）の両方をバックアップすること。ソースがない場合は.ex4/.ex5だけでも保存しておく。

3. プロファイル・テンプレート・プリセットの保存
データフォルダ内の profiles/、templates/、presets/ フォルダもバックアップ対象だ。チャート設定やインジケーターのパラメーター設定が入っているため、これがないと更新後に設定を一から入れ直すことになる。

4. 特殊なネットワーク設定の確認
プロキシ経由でMT4を使っている場合や、VPN・特定のポート設定を使っている場合は、現在の設定を記録しておく。更新後にネットワーク設定が初期化されるケースがあるため、再入力できるよう手元に控えを残す。特にMT5 Build 5660でSOCKS4プロキシが非対応になったように、プロキシ仕様が更新で変わることがある。

5. VPSと複数端末の更新タイミング統一
ローカルPCとVPSのMT4が異なるビルドで動くと、動作に差異が生じるケースがある。更新を行う際は複数の稼働環境を同じタイミングで揃えることが望ましい。本番運用中のVPSを更新する前に、手元の環境で動作確認を先に済ませておくと安全性が高い。

更新後の確認チェックリスト—困る場所は通信・履歴・テスター

MT4 アップデート後に問題が出やすい場所は限られている。更新後にどこを確認すればいいかを事前に把握しておけば、確認作業の時間は大幅に短縮できる。以下の順序で確認するのが実務的に効率が良い。

確認1：ブローカーサーバーへの接続
まず最初に確認すべきはサーバーへの接続状態だ。画面右下の接続バーが緑になっているか、気配値が更新されているかを確認する。接続できない場合は、サーバーアドレスの設定が変わっていないかを確認し、必要であれば再設定する。プロキシ設定を使っている場合は、更新で設定がリセットされていないかも確認する。

確認2：気配値・チャートのリアルタイム更新
接続は通っていても、チャートのティックが止まっていることがある。複数の通貨ペアのチャートが実際に更新されているかを確認する。MT5でBuild 5640のtick history修正が入った背景があるように、tick同期に問題が出るケースもある。

確認3：EAおよびインジケーターの動作
稼働中のEAについて、アドバイザータブのログにエラーが出ていないかを確認する。コンパイルエラーが発生している場合は、ソースコードを再コンパイルすることで解決するケースが多い。DLL（外部ライブラリ）を使っているEAについては、DLLの互換性も確認が必要だ。MT5でOpenBLASが別ファイル化されたように、ライブラリの配置が変わることがある。

確認4：アラートと通知機能
メール通知・プッシュ通知・アラートが正常に動作しているかを確認する。通知設定が更新でリセットされることがあるため、ツールメニューの設定から通知先を再確認する。特にVPS上で動かしているEAの通知機能は、更新後に設定が変わっていないかの確認を忘れがちだ。

確認5：ストラテジーテスターの結果
EAのバックテストを定期的に行っている場合は、更新後に同じ設定でテストを走らせて結果に異常がないかを確認する。MT5 Build 4755ではテスターのトリプルスワップ計算エラーが修正されており、このような更新後はテスター結果が変わることがある。「更新前と結果が違う」という場合は、バグ修正による正常化の可能性がある。

確認6：プロキシおよびネットワーク設定
プロキシ経由の接続を使っている場合は、更新後に設定が初期化されていないかを必ず確認する。特にMT5 Build 5660以降はSOCKS4が非対応になっているため、SOCKS4を使っていた場合は別の方式への切り替えが必要になる。

MT4 アップデートで困らない運用—本番と検証環境を分ける考え方

MT4 アップデートへの対応を仕組みとして固めるには、本番環境と検証環境を分けて運用することが最も実効性の高いアプローチだ。更新の影響を本番トレードに直撃させない構造を作れば、更新を怖がる必要がなくなる。

環境分離の基本的な考え方は以下の通りだ。

本番機（VPS）：最新ビルドへ追随
本番EAを動かすVPSは、MetaQuotesのBuild基準を満たした最新ビルドを維持する。旧ビルドで放置するリスクを避けるため、更新が来たら確認手順を踏んだうえで反映する。確認手順が定型化されていれば、本番機の更新作業は30分程度で完了する。

検証機（ローカルPC）：更新後の確認用
手元のPCをVPS本番機の更新前確認環境として使う。VPSを更新する前に、ローカルPCで更新後の動作を先に確認することで、本番環境での問題発生を事前に検知できる。同じEAを同じ設定で検証機に入れておけば、更新後に何が変わったかを本番前に把握できる。

MT5口座の並行開設：検証環境の拡充
MT5口座を並行開設しておくと、更新後の検証環境として機能する。特にMT5はMT4より更新頻度が高く、各更新での変更範囲も広いため、MT5の更新確認には独立した環境があると対処が速くなる。また、将来的なMT4からMT5への移行を考えている場合、並行運用によって移行コストを段階的に吸収できる。

更新管理の定型化
どのブローカーのどの口座でMT4/MT5を使っているか、現在のBuild番号、最終確認日時をスプレッドシートなどで一元管理する習慣をつけると、複数環境の管理が格段に楽になる。特にVPSを複数台使っているトレーダーや、ブローカーを複数持っているトレーダーには、この管理表が実務上の必需品になる。

運用をシステム化することで、「アップデートが怖い」という心理的ハードルは消える。更新が来たら決まった手順で確認して反映する、というサイクルが回れば、旧バージョン放置という最大のリスクを取り除ける。更新管理は面倒な作業ではなく、安定運用を続けるための投資だ。

よくある質問