ForexBestRobots.comEAを比較 →

VPSとMT4の安定稼働 · ガイド2

VPS上のMT4を設定し、リソース使用を最適化する方法

Windows VPS上のMT4で、端末の分離、CPU・RAMの測定、チャートと履歴の調整を行い、EAの権限、再起動、通知を確認する手順を解説します。

読了目安:約17分ForexBestRobots編集チームによるレビュー
MT4設定を見直すサイクル:稼働構成を把握し、リソース負荷を測定し、設定を一つ変更した後、データ・権限・EAの動作を確認して採用を判断します。VPS上のMT4設定測定し、調整し、確認する

設定の検証手順です。処理能力や性能の測定結果ではありません。

適切なMT4の設定には、実際の負荷に対応できる余力、各稼働環境を識別できる管理方法、通常の保守後も意図した設定を維持できる仕組みが必要です。万能な「MT4高速化設定」をそのまま使うのではなく、観測したリソースの逼迫状況と、確認済みのEAの動作に基づいて環境を調整します。

本記事は「VPS・MT4の安定稼働」シリーズのガイド2です。ホスティングと継続稼働は基礎ガイドで説明しています。障害対応、バックアップ、復旧はガイド3:障害対策と安全な復旧を参照してください。 障害が起きていない間の監視は、ガイド4:気配値・ハートビート・通知で確認できます。

最適化の対象を明確にする

本ガイドは、MT4と対象のEAをすでにインストールし、デモ口座で動作確認していることを前提とします。ファイル配置とEAの適用については、EAのインストールガイドを参照してください。MetaTrader内蔵の仮想ホスティングは移行手順が異なり、Windowsデスクトップもありません。Windowsの起動設定やフォルダーに関する手順をそのまま適用しないでください。

運用面の最適化とは、承認したEAの動作を維持しながら不要な負荷を減らすことです。テスターで戦略パラメーターを最適化する作業とは別です。端末の反応をよく見せるために、ロット数、シグナルフィルター、リスク制限、約定関連の設定を変えないでください。端末が軽くなっても、収益性が証明されたり約定が保証されたりするわけではありません。

変更前に稼働構成を整理する

各端末の用途と、実際に必要な構成要素を記録します。チャート数だけでは、複数銘柄を扱うEAや内部で計算されるインジケーターを把握できません。負荷の大きいEA一つが、単純なEA複数より多くのリソースを必要とする場合があります。

記録項目含める情報
端末の識別情報インストール先、実際のデータフォルダー、Windowsユーザー、用途がわかる名前のショートカット。
取引環境ブローカーの口座とサーバー、デモ・本番・検証の用途。認証情報はこの一覧に載せず、安全な場所で管理します。
稼働中の構成必要なチャート、正確な銘柄名と時間足、適用中のEA、バージョン、承認済みのInputs。
依存関係他の銘柄や時間足、必要な過去データ量、カスタムインジケーター、ファイル、DLL、WebRequestの許可URL、ライセンス。
注文の管理範囲と運用Magic Numberの割り当て、管理すべき既存注文、起動方法、監視先、変更日。

対応している場合は承認済みの.setファイルを保存し、現在のプロファイルと設定も記録します。これは変更前の状態を把握するための資料であり、完全なバックアップや復旧計画ではありません。

観測した需要に合わせてVPSのリソースを決める

リソース確認する内容設定の判断
CPU高負荷時、各端末の使用量、特定の論理プロセッサーに集中する負荷。一時的な増加に備えて余力を残します。共有vCPUの数だけでは持続的な処理能力はわからないため、実際の負荷を比較します。
RAMWindows、全端末、チャートデータ、インジケーター、バックグラウンドアプリの使用量。メモリの余力を確保します。逼迫やページングの増加は調査が必要です。高速化の近道としてページファイルを無効にしないでください。
SSD・ストレージ空き容量、履歴とログの増加、スキャン・ダウンロード・更新中のディスク活動。MT4だけでなくOSと保守の容量も見込みます。SSDという名称だけでは、十分な空き容量やディスク性能は証明されません。
Windows現在のセキュリティサポート、ブローカー・EAとの互換性、ユーザーセッション、提供元の管理方針。保守され、適切なライセンスがある環境を使います。実際のエディションと依存関係を提供元や開発元に確認します。
ネットワーク対象のブローカーサーバーへの接続、切断、必要な取引時間中の価格更新。ブローカーへの経路を調べます。リモートデスクトップが滑らかに動くことや、一般の速度テストが速いことだけでは不十分です。

「GBあたりのEA数」「vCPUあたりの端末数」といった信頼できる万能ルールはありません。起動、履歴読み込み、保守を含む予定の構成全体を観測してから容量を判断します。リソースの余力は運用上の余裕であり、取引結果の約束ではありません。

通常時と重要なピーク時を測定する

  1. 基準となる状態を記録します。 WindowsのタスクマネージャーをCtrl+Shift+Escで開きます。「プロセス」または「詳細」で各terminal.exeを、「パフォーマンス」でCPU、メモリ、ディスク、ネットワーク全体を確認します。プロセスを記録済みのインストール先と対応させます。
  2. 複数の運用条件を観測します。 通常の取引時間、価格更新が多い時間、起動、データ読み込みを含めます。時刻、稼働構成、リソースの逼迫状況、MT4の応答を記録します。アイドル時のスクリーンショット一枚は処理能力の検証にはなりません。
  3. 負荷の原因を絞ります。 端末の使用量と、他のアプリ、更新、セキュリティスキャンを比較します。CPU全体の使用率では、特定の論理プロセッサーの高負荷やプログラムのボトルネックが隠れる場合があります。全体の使用率が低くても、すべてのEAが迅速に処理しているとは限りません。
  4. 検証作業の負荷を分離します。 可能なら長いバックテストやパラメーター探索を取引用の環境外で行います。同じVPSにテスターを別途インストールしても、設定が分かれるだけで、同じマシンのリソースを使います。

MQL4のEAは別々のスレッドで動作しますが、チャート上のインジケーターはインターフェースのスレッドを共有します。iCustom()で呼び出したインジケーターは、呼び出し元のスレッドで動作します。EA内部のイベントは順番に処理され、OnTick()の処理中に届く新しいティックがすべてキューに入るわけではありません。コアを増やしても、重い処理や停止したインジケーターが自動的に解決するとは限りません。プログラムの負荷が続く場合は開発元に相談してください。

複数のMT4インストールを識別できるようにする

複数口座を同時に使う場合は、ブローカー指定のMT4を別々のインストール先に導入します。ショートカットには用途を区別できる名前を付けます。同じ実行ファイルへのショートカットを二つ作っても、独立した二つのインストールにはなりません。

各稼働コピーでFile → Open Data Folderを開き、実際の場所を記録します。通常のデータフォルダーはインストール先とWindowsユーザーに依存し、origin.txtで対応するインストール先を確認できます。ブローカー名だけで正しいフォルダーを推測したり、別のWindowsユーザーにも同じEAのファイルと設定が見えると思い込んだりしないでください。

各コピーの依存ファイルを、それぞれの実際のデータフォルダーに配置して確認します。フォルダー分離は設定の取り違えを減らしますが、同じブローカー口座のリスクは分離しません。EAがFILE_COMMONの共有ファイルや外部ライセンスサービスを使う場合もあるため、複数起動に関する仕様に従います。

ポータブルモードは高速化設定ではありません。 /portableはMT4がデータを保存しようとする場所を変えます。既存のデータフォルダーを自動で移す機能はなく、書き込み権限も必要です。検証済みの理由がなければ通常モードを維持し、便宜のためにUACを無効化したり権限を広く引き上げたりしないでください。

注文の管理範囲と端末の処理能力を分けて考える

複数EAや端末を同じ口座で運用するには、注文管理のルールが互いに両立している必要があります。各予定インスタンスのMagic Number、銘柄、その他の識別条件を仕様に基づいて記録します。EAが自分の注文だけを管理するとは限りません。

Magic Numberは注文の識別子であり、他端末を排除するロックではありません。二つのコピーは、識別子が違っても重複注文を送れます。識別子の変更やEAの移動前に、既存の保有ポジションや未約定注文を引き続き管理する必要があるか確認します。管理を再開するために必要な識別条件を維持してください。詳しくはMagic Numberガイドを参照してください。

リソースを分けても口座のリスクは共有されます。EA全体で証拠金の使用や相関のあるポジションが積み重なる場合があります。リスク管理ガイドでそのリスクを確認してください。CPUに余裕があることは、ポートフォリオ全体の安全性を意味しません。

必要なデータを残してチャートと履歴を調整する

まず、不要と確認できた分析用チャートと装飾的なインジケーターを外します。EAのチャートを閉じるとそのEAはアンロードされます。ウィンドウの最小化とは異なります。閉じる前に稼働内容を確認し、仕様上必要なチャートは残してください。

Tools → Options → Chartsでは、Max bars in historyとMax bars in chartを区別します。前者は保存する履歴、後者はインジケーター計算に使うチャートデータを制御します。不要なチャート履歴を減らすと負荷を軽減できる場合がありますが、根拠なく小さい値にするとEAやインジケーターに必要な過去データが足りなくなります。

  1. 内部計算されるインジケーターも含め、必要なすべての銘柄と時間足について最低限のデータ量を確認します。
  2. その条件と予定する検証に十分な履歴を維持します。表示中のチャート一つで複数時間足のEAに対応できるとは限りません。
  3. デモで一つの上限を変更し、必要に応じて再読み込みや再起動を行います。初期化、データの利用可否、想定した計算を確認してから採用します。

これらの上限は厳密なメモリ割り当てではありません。新しい価格が届くとチャートのバー数が増える場合があります。「MT4高速化」のために履歴フォルダーを空にしないでください。再読み込みにリソースが必要になり、テストで使えるデータも変わり得ます。比較用の元データを保存します。

必要な銘柄とインジケーターの依存関係を維持する

Market Watchでは、構成全体で不要と確認できた銘柄だけを非表示にします。MT4の説明では、これは価格データの通信量を減らす方法です。表示チャートがなくても、取引、銘柄間のシグナル、通貨換算に必要な銘柄は残します。MT4は開いているチャートや注文がある一部の銘柄を非表示にできないようにしていますが、この一覧だけでは依存関係を網羅できません。

表示中のインジケーターを外しても、計算が止まった証拠にはなりません。EAが内部で値を取得する場合があります。任意のダッシュボードや不要な表示要素は別々に検証し、開発元が必要とするインジケーターとファイルを維持します。CPUやメモリの使用が増え続ける場合は、確認のない頻繁な再起動で隠すのではなく、時刻とログを収集して開発元に伝えます。

実際に取引するコピーの権限を確認する

通常のWindows版MT4では、端末のAutoTradingと、適用中のEAのAllow live tradingの両方を確認します。EAのアイコン、届く価格、動いているプロセスだけでは、取引権限は確認できません。意図した口座、サーバー、取引可能なログインも確認します。

口座、プロファイル、銘柄、時間足の変更後に自動売買を無効にする設定を確認します。これらは保護機能であり、機械的に外すものではありません。作動した場合は、新しい環境を確認してから対象EAの取引を再び許可します。

DLLの使用は信頼できる必要なライブラリーだけ、WebRequestは仕様にある信頼できるURLだけに許可します。すでに適用されているEA自身の設定を確認してください。既定値の変更は、稼働中のインスタンスの確認には代わりません。プロファイル、テンプレート、EAを更新した後も再確認します。AutoTradingをオフにするとその端末のEAの取引操作が禁止されますが、注文を閉じたり別途ホストされたコピーを止めたりはしません。

診断資料を残しながらログの増加を管理する

設定変更のたびに、EAのメッセージはExperts、端末と接続のイベントはJournalで確認します。各タブの右クリックメニューのOpenは、対応するログフォルダーを開き、現在の記録をディスクに書き出します。実際のデータフォルダーでは、EAのログは通常MQL4/Logs、端末のログはlogsにあり、日付を表すYYYYMMDD.LOGというファイル名です。

タブには最近の記録が表示され、Clearは表示を消すだけで実ファイルを削除しません。ストレージ保守では、まず増加しているフォルダーを測定し、障害や比較に必要なログを残してから、定めた保存方針に従って古いファイルをアーカイブします。稼働中のファイル削除や、データフォルダー全体の一括削除は避けます。

繰り返すエラーやティックごとの過剰な記録は、原因を直す必要があります。昨日のログを削除しても翌日の増加は止まりません。プロファイル、テンプレート、プリセット、EAの状態ファイルを維持します。診断にはExpertsとJournalのガイドを使ってください。詳しいバックアップ設計はガイド3で扱います。

Windows更新を計画し、起動をテストする

Windowsのセキュリティ保守を有効に保ち、管理できる再起動時間を設けます。実際のWindowsエディションと提供元の再起動設定、セッション方針を確認します。利用できる場合、アクティブ時間は実施時間の調整に役立ちますが、無停止の取引を保証しません。測定値を改善するためにセキュリティソフトや更新を無効にしないでください。

サインイン後に起動する方式なら、対象ユーザーのスタートアップフォルダー(shell:startup)に、正しい実行ファイルへのわかりやすい名前のショートカットを作ります。そのユーザーのサインイン後に実行されるもので、Windowsが起動しただけでは動きません。別の起動機構を重ねると競合する場合があるため、各コピーの検証済みの方法を一つ記録します。

無人での再起動が必要なら、提供元や管理者に、対応するユーザーセッションと起動方式を確認してもらいます。スケジュールタスクや稼働中のterminal.exeだけでは、正しいデータフォルダー、口座、ライセンス、EAの状態が利用可能とは言えません。安易な解決策として認証情報が露出する自動サインインを設定しないでください。

デモで端末の再起動とOSの再起動を別々にテストします。各テスト後に口座・サーバー、プロファイル、チャート、EAのバージョンとInputs、権限、価格、ログ、既存注文の管理を確認します。リモートデスクトップの切断と再接続も確認します。サインアウトやセッションの時間制限はアプリを終了させる場合があります。「毎時間再起動する」タスクや、これらの確認を飛ばす監視プログラムの無条件な再起動は避けてください。

役立つ通知を設定し、限界を確認する

リソースの逼迫と、端末やEAの動作停止を区別できる監視を選びます。通知を受け取る担当者と、次に確認する内容を決めます。通常時の負荷、観測したピーク、対応できる時間からしきい値を設定します。万能な使用率や、価格データの古さの基準はありません。

兆候確認する内容限界
CPU・メモリの持続的な逼迫、または空き容量不足対象端末、バックグラウンド処理、最近の変更を基準状態と比較します。短いピークと継続的な逼迫は異なります。使用量だけでは取引の正常性はわかりません。
端末プロセスや予定された定期通知がない再起動前に、対象インスタンスと稼働環境を確認します。OnTickだけで送る通知は、静かな市場や休場中に止まる場合があります。仕様上の動作を確認します。
接続、価格、EAのエラー必要な銘柄の取引時間と最新データを調べ、ExpertsとJournalを確認します。端末が接続中でも、必要なデータが古かったりEAのロジックが失敗していたりする場合があります。

プッシュ通知にはTools → Options → Notificationsを設定し、通知先のMetaQuotes IDを入力してTestを使います。実際の端末で受信を確認してください。標準の取引通知は拒否されたリクエストを通知しません。EA独自のエラー通知に対応している場合は、それもデモでテストします。

停止したMT4は、自身の停止を確実に通知できません。独立したプロセス・ホスト監視や、定期通知の未着を外部で確認する仕組みで補います。取引用端末を繰り返し終了・再起動する監視処理より、範囲を限定し手順を明確にした対応を優先します。

変更と採用判断を段階的に行う

  1. 変更前を記録します。 設定、観測条件、リソースの逼迫、関連ログの時刻を保存します。
  2. 根拠のある変更をデモで一つ行います。 不要な表示要素を外す、仕様に沿って履歴の上限を変える、テスターの負荷を分離するなどです。戦略とリスクの設定は固定します。
  3. 同じような条件で比較します。 通常時、多い価格更新、起動を再度観測します。条件が異なる場合は限界を記録し、測定済みの改善だと主張しません。
  4. 採用するか戻します。 必要なデータ、EAの計算、権限、注文管理が正しく、十分な余力がある場合だけ採用します。そうでなければ以前の設定に戻します。
判断の例であり、ベンチマークではありません。 複数銘柄のEAが、テスターと任意のダッシュボードと同じVPSを使っているとします。まずテスターの処理を別環境に移すか、取引の観測時間外に予定し、次に任意のダッシュボードを個別に評価します。EAに必要な銘柄と過去データは残します。逼迫が続けば開発元と調査するか、測定後に適切な容量を増やします。追加できるEA数を固定して約束しません。

端末の追加、EAのバージョン、プロファイル、依存関係の変更、保守後に採用条件を再確認します。デモでの再起動テストは運用手順の確認であり、本番で同じ約定が得られることや将来の利益の証明ではありません。

MT4設定を見直すサイクル:稼働構成を把握し、リソース負荷を測定し、設定を一つ変更した後、データ・権限・EAの動作を確認して採用を判断します。
リソース設定の変更は、EAに必要なデータ、権限、注文管理の範囲が維持されていることを確認してから採用します。稼働構成が変わったら再確認します。

設定完了の確認リスト

各端末のインストール先、データフォルダー、Windowsユーザー、用途を記録
ブローカー口座、サーバー、予定した取引権限を確認
必要なチャート、銘柄、時間足、履歴、依存ファイルを維持
EAのバージョン、承認済みInputs、既存注文の管理範囲を記録
通常時、高負荷時、起動時を観測し、処理能力の余力を確保
AutoTrading、EAの権限、信頼できる依存先へのアクセスを確認
ログの保存方針、空き容量、Windowsの保守を整備
端末再起動、OS再起動、リモート切断、通知をデモで検証

確認した日付と結果を保存します。重要な変更後と、運用に必要な監視頻度に応じて見直します。設定済みのVPSにも継続的な運用管理が必要です。

MT4設定についてよくある質問

一台のVPSでMT4を何台動かせますか?

共通の台数はありません。予定する端末、EA、依存関係を重要なピーク時に測定し、OSと保守の余力を残します。同じVPSにもう一つインストールしても、物理的なリソースは増えません。

バー数の上限はできるだけ小さくすべきですか?

いいえ。必要な銘柄、時間足、インジケーターのデータを維持します。不要と確認した分だけを減らし、デモで検証し、比較用データを保存します。

AutoTradingボタンが緑ならEAは動作していますか?

それだけでは判断できません。適用中EAの権限、口座へのアクセス、データ、初期化、ログ、予定した注文管理を確認します。戦略のシグナルがなければ、新規取引がないのは正常な場合があります。

MT4を一定間隔で自動再起動すべきですか?

継続的な負荷の原因調査や起動確認の代わりにはしないでください。必要な保守を計画し、再起動手順を検証し、対応方法を定めた監視を使います。確認のない再起動は管理を中断したり、誤った設定を読み込んだりするおそれがあります。

公式資料と本ガイドの範囲

プラットフォームの詳細は公式資料で確認しました。構成の整理、測定、採用判断の手順は実務上の運用指針であり、VPSの実測結果ではありません。表示名は端末の言語やWindowsのエディションで異なる場合があります。本記事の英語UI名は確認対象の設定を示しています。