はじめに：VPSが止まればEAは止まる（だから“監視”が必要）
VPSが止まれば、MT5もEAも止まります。
特に成行注文中心のEAは、VPSが落ちた瞬間に発注・決済が止まり、相場急変時に想定外の損失につながるリスクがあります。
この記事では、ノーコードで現実的に運用できる「VPS監視」の作り方をまとめます。
- UptimeRobotで「VPSが落ちていないか」をチェック（まずは無料でOK）
- さらに“VPSは生きているのにMT5やEAだけ止まる”ケースにも備える
- ポイントはEAのタイプ（非スキャル / スキャル、ストップロスあり/なし）で“監視の敏感さ”を変えること
結論：監視の強さは「スキャルか」「SLをサーバーに置くか」で決める
どの程度監視すべきかは、EAのタイプと注文設計で変わります。監視を複雑にしすぎると、運用が続かなかったり、コストだけ増えたりします。
関連記事：
» スキャルピングEAは勝てる？おすすめしない理由（再現性の低さに注意）
» EA注文タイプとリスク比較｜成行・ストップ・SL/TPとVPS停止時の安全性
スキャルピング（秒〜数分）× ストップロスなし（または端末依存）
- MT5/EAが停止中に相場が急変すると、想定外リスクが大きい。
- 高感度監視を推奨：VPSの稼働だけでなく、MT5/EAが動いている“目印”も持つ。
- ノーコードで現実的にやるなら、UptimeRobot（短め間隔）＋MT5の通知。
- さらに精度を上げるなら、定期通知を出せる既製のインジ/EAで「一定時間ごとに通知が来る状態」を作る。
スキャルピング（秒〜数分）× ストップロスあり（サーバー登録のSL/TP）
- スキャルはそもそも反応速度が重要なため、停止の影響が出やすい。
- ただしSL/TPをサーバーに置けている場合は、最悪の事故（無防備状態）を避けやすい。
- 監視は中〜高感度：Pingに加え、MT5の通知（取引通知/定期通知）を推奨。
非スキャル（数時間〜数日）× ストップロスなし（または端末依存）
- 取引頻度が低くても、SLが置けない設計は放置リスクが残る。
- 監視は中感度：Ping監視＋「MT5が動いている目印」を用意すると安心。
- ノーコードなら、MT5の取引通知に加え、必要なら定期通知インジ/EAの導入を検討。
非スキャル（数時間〜数日）× ストップロスあり（サーバー登録のSL/TP）
- リスクは相対的に低め。 指値・逆指値（Stop）やストップロス（SL）は、ブローカー側サーバーに保持・執行されるケースが多い。
- ただしTrailing Stop（トレーリングストップ）は、発動・位置調整が端末側（MT5）依存になりやすい点に注意。
- 監視は過敏にしすぎない方が運用が安定しやすい。
- UptimeRobot：Ping（5分）＋必要ならRDPポート監視で十分。
UptimeRobotとは：VPSの稼働を自動チェックできる監視サービス
UptimeRobotは、サーバーやWebサービスの稼働状況を自動チェックし、ダウン時に通知してくれる監視サービスです。無料プラン（5分間隔・最大50監視）があるため、まずは費用ゼロで運用を始められます。
EA/MT5のVPS運用と相性が良いのは、まずPing監視（Ping Monitor）と、必要に応じたポート監視（Port Monitor）です。通知先はメールのほか、Telegram / Slack / Discord / Webhookなどにも対応しています。
まずはメール通知でシンプルに始め、運用に慣れたら通知先を増やすのがおすすめです。
UptimeRobotでやること：ノーコードで最低限の監視を作る
1) Ping監視（必須）：VPSが“生きているか”を確認する
- 監視対象：VPSのグローバルIP
- 監視間隔：5分（無料プラン標準）
- 通知：2～3回連続失敗で通知（誤報を減らす）
Ping監視を入れるだけで、VPSや回線のダウンはかなり高確度で検知できます。
2) ポート監視（任意）：RDP接続の可否をチェックする
- 監視対象：RDP（Remote Desktop Protocol） 3389/TCP
- 目的：「外部から接続できない」状態を早めに見つける
- 注意：セキュリティ上、RDPを外部に開けていない運用なら無理に入れなくてOK
3) 通知の受け取り先：見落としにくい経路を選ぶ
- メール：まずはこれで十分（普段必ず見るアドレスを指定）
- Telegram/Slack：慣れたら追加して即時性を上げる
- メンテナンス時間：VPS事業者のメンテ中は通知しない設定（Maintenance Window）を活用
ここまでで「VPSが落ちた」は確実に拾えます。問題は、次の“VPSは動いているのにMT5やEAだけ止まる”ケースです。
なぜ「VPSは動いているのにMT5/EAが止まる」のか：よくある原因
- Windowsの更新／自動再起動後にMT5が起動していない
- 回線の一時不調でMT5が未接続になり、EAが売買しない
- ログイン情報・証明書の期限、取引サーバー変更などで未接続
- ディスク容量不足／ログ肥大でMT5が不安定
- シンボル名変更・仕様変更でEAが待機状態になる
- メモリ不足・クラッシュなどアプリ側の不具合
対策のカギは、「VPSの稼働（Ping）」と「MT5/EAの稼働（動いている目印）」を別レイヤーで見ることです。
関連記事：EAが止まる・重い原因と対策｜VPS最適化とMT5軽量化の基本設定
「MT5/EAが動いている目印」をノーコードで作る方法
VPSが動いていても、MT5が落ちている／固まっている可能性はあります。ここでは、MT5/EAが動いているかを確認する“目印”を整理します。
A. MT5のプッシュ通知（Push Notification）：まず入れるべき基本設定
- MT5のTools（ツール）→ Options（オプション）→ Notifications（通知）でプッシュ通知をON
- スマホアプリのMetaQuotes IDを入力し、テスト送信
- 取引通知（発注・約定など）をONにする
普段どおり約定通知が来ていれば、“とりあえず動いている”目安になります。逆に、いつも動くEAなのに長時間（例：丸1日）通知がゼロなら要確認です。
B. 既製の「定期通知インジ/EA」を使う：取引が少ないEAでも確認しやすくする
- MQL5マーケット等で「定期通知」「稼働監視」系を検索
- 出所の信頼性（レビュー、更新頻度、サポート状況）を確認
- 外部連携（Telegram等）を使う場合は、必要権限と設定内容を必ず確認
- 導入後は通知をメール／Telegramなどに集約し、見落としを減らす
コーディングなしでも、取引通知＋定期通知を組み合わせれば、停止の見落としを大きく減らせます。
EAタイプ別：監視の“敏感さ”おすすめ設定（まとめ）
非スキャル × SLあり（サーバー登録のSL/TP）
- UptimeRobot：Ping（5分）＋（必要に応じて）RDPポート
- 通知閾値：2～3回連続失敗で通知（過敏にしない）
- MT5側：（任意）取引通知ON（緩い目印）
- 注意：Trailing Stopは端末依存になりやすい
非スキャル × SLなし（または端末依存）
- UptimeRobot：Ping（5分）＋必要ならRDPポート
- MT5側：取引通知ON＋（必要に応じて）定期通知インジ/EA
- 通知閾値：2回前後の失敗で通知（中感度）
スキャル × SLあり（サーバー登録のSL/TP）
- UptimeRobot：Ping（可能なら短め間隔）＋RDPポート
- MT5側：取引通知ON（停止を早めに気づく）
- 通知閾値：1～2回失敗で通知（中〜高感度）
スキャル × SLなし（または端末依存）
- UptimeRobot：Ping（短め間隔を検討）＋RDPポート
- MT5側：取引通知ON＋定期通知インジ/EA（停止の見落としを減らす）
- 通知閾値：1回失敗でも通知（高感度）
- 運用：再起動手順・夜間対応などの“対応フロー”を用意
アラートが鳴ったら：切り分け手順（最短で復旧する）
- PingもNG：VPS／回線障害の可能性 → VPS事業者のステータス確認／サポート連絡
- PingはOKだが、通知（取引・定期通知）が長時間ゼロ：RDPでVPSへ接続 → MT5の接続状態（右下の回線表示）、口座ログイン、証拠金、休場、銘柄仕様変更を確認
- ログ確認：MT5で View（表示）→ Terminal（ターミナル）→ Journal / Experts を見て、エラー・停止理由をチェック
- 復旧後：再発防止の1アクションだけ入れる（例：Windows更新の曜日固定、不要ログ削除、時刻同期の定期化）
まとめ：PingでVPS、通知でMT5/EAの停止を見落としにくくする
- UptimeRobotでVPSの稼働を監視し、MT5/EAが動いている目印は取引通知＋（必要に応じて）定期通知で補う。
- 監視の敏感さは、スキャルかどうかとSLをサーバーに置けているかで決める。
- スキャル×SLなしは最も事故が起きやすいので、高感度＋目印の多重化で早期検知を優先する。
MQL5
Myfxbook
YouTube
X
GOGOJUN