MT4のForex EAを監視する：気配値・ハートビート・通知

異常を判断する前に、通常の動作を定義する

新規取引がなくても、EAは正常に動作している場合があります。取引時間の制限、スプレッドの上限、既存のポジション群、リスク管理のルール、有効なシグナルがないことなどが理由になり得ます。監視では、既存注文の管理も含め、想定した環境が仕様どおりの役割を果たせるかを確認します。最低取引回数を要求するものではありません。

端末の識別情報、使用する口座とサーバー、正確な銘柄名と時間足、EAのバージョン、承認済み設定、注文の管理範囲、想定稼働時間を記録します。EAが参照する他の銘柄も含めてください。開発者には、確認できる状態表示やログ、再起動後の動作を問い合わせます。EX4ファイルだからといって、定期的な稼働報告や全判断の説明が自動的に得られるわけではありません。

「正常」「問題を確認済み」「不明」を区別します。ダッシュボードの更新が止まったら、最終確認時刻を表示し、現在の状態を不明とします。古い緑色の表示を、現在も正常である証拠として扱わないでください。

四つの層を分けて確認する

これらは別々の確認項目です。手動で確認するか、目的に合わせて構成した監視システムで集めます。ここで説明するダッシュボードをMT4が自動的に構築するわけではありません。

戦略を変えずに行う五分間の確認

1. EAが実際に動く場所を確認します。 移行後に残ったローカルチャートではなく、対象の端末と口座を見ます。
2. 取引時間と必要な気配値を確認します。 今は更新が期待される時間か、ブローカーの正確な銘柄名に利用可能なデータがあるかを調べます。
3. 初期化と権限を確認します。 ExpertsとJournalの最近のメッセージ、およびEAの仕様上の状態を読みます。
4. 現在の注文を確認します。 誰が管理し、どの保護水準がブローカー側に存在するかを確かめます。
5. 監視経路を確認します。 最終報告時刻と、対象端末へのテスト通知の到着を確認します。

五分間は確認の形式であり、診断の完了や、どのEAにも適切な対応時間を保証するものではありません。不明点があれば証拠を保存し、EAエラーのガイドを使います。表示を緑色にするために、スプレッドやリスクの制限を緩めたり、Magic Numberを変えたり、無理に注文を出したりしないでください。

接続中であることと、新しい気配値の受信は別

IsConnected()は端末とサーバーの接続状態を示します。全銘柄の最新データ、取引権限、戦略の正常動作を保証するものではありません。ブローカーの接尾辞を含む正確な銘柄名と、EAのチャート以外に必要なデータも確認します。

MarketInfo(symbol, MODE_TIME)は、その銘柄で最後に受信したティックの時刻をブローカーのサーバー時間基準で返します。最終気配値は過去の観察であり、新しいティックなしでも進む時計ではありません。週末、銘柄の取引休止時間、流動性が低い時間には古い気配値が通常の状態であることもあります。データ配信障害と判断する前に、ブローカーの実際の取引時間を確認してください。

通常の動作を観察したうえで、銘柄と時間帯ごとに気配値の鮮度判定を定めます。すべてのFX通貨ペアやEAに共通する安全な待ち時間はありません。Bidが変わらないだけでも判断できません。同じ価格を含むティックが続くこともあります。可能なら、価格変化だけでなくデータイベントの受信を記録します。

確認する内容に合った時計を使う

共通の時間基準を確認せずに、Windowsの時計からブローカーの気配値時刻を直接引いて「経過時間」としないでください。開発者は適切なカウンターで時間間隔を測れますが、リセットや桁あふれへの対応が必要です。外部の収集システムは、市場時刻とは別に、検証済みの独自の経過時間計測で報告の欠落を判定します。

ログには情報源、日付、タイムゾーンを添えます。障害の経緯を調べる前に時間基準をそろえてください。似た時刻が画面に並んでいるだけでは、出来事の順序は分かりません。ExpertsとJournalのガイドも参照してください。

ハートビートが何を確認するのか明確にする

ハートビートとは、特定の構成要素から送る定期報告です。VPSの報告はホスト側、監視用EAの報告はそのEA自身のイベント処理に関するものです。別の取引用EAがシグナルを評価したり、ポジション群を管理したりした証拠には自動的になりません。

OnTick()はEAを取り付けたチャート銘柄の新しいティックで実行されます。その中だけで送る報告は、ティックがないと止まり得ます。開発者が実装していれば、EventSetTimer()とOnTimer()で定期イベントを要求できます。イベントはキューに入り、Timerイベントがすでに待機中または処理中なら新しいTimerイベントは追加されません。正確な外部時計ではなく、処理が詰まったプログラムが報告し続ける保証もありません。

報告を作る地点を確認してください。ハンドラに入った時点、データ確認が完了した時点、管理サイクルの完了時点、送信成功時点などで意味が違います。実行環境の識別情報、バージョン、連番、動作モード、データ状態、生成・受信時刻が役立ちます。増加する連番は新しい報告と再送を区別できますが、約定を証明するものではありません。

ソースコード非公開のEAでは、提供者が用意した状態表示と外部観察を利用します。監視プログラムを追加しても、戦略内部の正常性が分かるようになるわけではありません。別の監視用EAには専用チャートが必要です。戦略のチャートに取り付けると、既存のEAを置き換えてしまいます。監視用EAは取引要求を送ったり戦略の注文を管理したりせず、観察に徹する設計にします。

端末の外から、報告が来ないことを検知する

停止した端末は、自身の停止を知らせる最後の通知を確実に送れません。独立した監視側は、自身と通信・通知経路が動いていれば、期待する報告の停止を検知できます。唯一の監視プログラムを同じVPSに置くと、同じホスト障害に巻き込まれます。

観察と介入を分けます。報告欠落の警告は、送信元、ネットワーク、収集側、通知経路のどこかで観察が失敗したという意味です。主系EAの取引停止を証明せず、予備の取引用コピーを自動的に有効化する根拠にもなりません。ガイド3の切り替え手順に進む前に、ホストと現在のブローカー注文を調べます。

各実行環境に固有の監視IDを割り当て、不明または重複した送信元を検知します。収集側そのものも監視し、代替連絡経路を試します。送信するのは必要な状態情報だけです。パスワード、ライセンス認証の秘密情報、無制限の口座アクセスはハートビートの項目に含めません。

権限を監視し、むやみに有効化しない

通常のデスクトップMT4では、AutoTrading、EA自身の取引許可、対象口座の取引アクセス、提供者のライセンスを確認します。読み取り専用ログインは口座情報を表示できても取引できません。権限が変わると、計算は続いていても必要な注文変更ができない場合があります。

引数なしのIsTradeAllowed()は、呼び出したEAの許可と、取引コンテキストが使用中でないことを確認します。falseだけでは原因を特定できず、trueでも次の要求がブローカーに受理される保証はありません。別の監視用EAで得た結果は、他のEAの個別権限を証明しません。

承認済み動作モードからの予期しない変化を通知します。意図的に停止した端末は「一時停止」と記録し、監視側が勝手に「修復」しないようにします。自動取引を止めてもポジションは閉じません。ローカル側の決済処理を妨げることもあるため、一時停止には明確な管理計画が必要です。

失敗した要求と既存ポジションを監視する

仕様に基づく取引要求について、意図した操作、試行、返された結果、ブローカー記録との照合を追います。新規ポジションがなくても、拒否や変更の失敗は重要です。提供者が試行やシグナルを見送った理由を記録しない場合、取引一覧だけからそれらを確実に復元することはできません。

エラー128は取引要求のタイムアウトです。応答を失った、または結果が不明なときは、保有ポジション、待機注文、該当期間の履歴を確認してから再試行を判断します。ローカル側に確認がないことは拒否の証拠ではありません。正確な銘柄、売買方向、数量、分かる場合はチケット番号、要求時刻を調査に含め、対応する注文を推測しないでください。

現在のエクスポージャー、含み損益、equity（有効証拠金）、受理済みStop Loss/Take Profitを、EAの管理範囲の仕様と合わせて確認します。ブローカー側の保護と、予定された仮想ストップや今後のトレーリング更新は別です。EA停止後もポジションは残り得て、ローカル監視がない間に待機注文が発動する場合もあります。このガイドは、新たなドローダウン基準や自動清算方針を定めるものではありません。

受信者まで届くことを確認する

1. 対象の端末でTools → Options → Notificationsを開き、プッシュ通知を有効にして、使用するモバイル端末のMetaQuotes IDを入力します。
2. Testを実行し、端末側の結果と実際のデバイスでの受信を確認します。デバイスの通知許可と、受信後の連絡・対応経路も調べます。
3. EAまたは監視側の実際の警告条件は別に試します。設定のテストだけでは、報告欠落や注文拒否を検知するルールの存在は証明できません。
4. 試験時刻、送信元、宛先、結果を記録します。VPS移行、デバイス変更、通知設定変更後には再試験します。

Notify of trade operationsは成功した取引操作と仕様に記載された口座イベントを対象とし、失敗した取引操作は通知しません。注文拒否、古いデータ、端末停止をすべて検知する仕組みではありません。

SendNotification()について、MetaQuotesは255文字以内、呼び出しは毎秒最大2回かつ毎分最大10回と定めています。頻度制限を超えると機能が無効化される場合があります。Strategy Testerでは動作しないため、適切な稼働中のデモ環境で配信を確認します。送信成功は、人が読んだり確認したりした証拠ではありません。同じ障害をまとめ、毎ティックの通知ではなく意味のある状態変化を通知してください。

警告ルールには背景と次の行動を含める

条件の継続時間、再通知間隔、確認応答、復旧判定を定めます。復旧通知には、どの観察が再開したかを示してください。一つの報告が来ても、全層の復旧を意味しません。頻繁な警告を永久に消すのではなく、担当者と終了時刻を明記した保守時間を設定します。

重要度は実際の口座状況に合わせます。同じデータ障害でも、ポジションがない場合と、ローカル決済に依存するポジションがある場合では影響が違います。監視はその状況を明らかにしますが、すべてに共通する安全な待ち時間を提示するものではありません。

一つの時計で見る、ハートビート欠落の例

仮の例です。収集側が60秒ごとに識別可能な報告を期待し、新しい報告が180秒来なければ警告します。学習用の設定であり、共通の推奨閾値ではありません。以下の時刻はすべて収集側が観察したUTC時刻です。ブローカーの気配値時刻を差し引いていません。

180 ÷ 60 = 3回分の報告間隔が、新しい受信なしで経過しています。これは、10:00:00に取引が停止したこと、サーバーが要求を拒否したこと、注文が管理されていないことの証明ではありません。介入前にEA、ログ、現在の注文状態を確認します。収集側自体が停止していたなら、全期間を連続観察したと主張することはできません。

簡潔な運用記録を残す

最後に確認できた時刻、必要銘柄のデータ状態、EAと端末の識別情報、保有ポジションの管理担当、未解決メッセージ、通知試験結果、予定変更を記録します。導入、再起動、移行、承認済み設定変更、ブローカー保守後に確認し、その後もEAの実際の管理要件に合った頻度で見直します。

公開モニタリングは成績を調べるのに役立ちますが、最終更新時刻と公開の遅れを先に確認します。見栄えのよい残高曲線は、リアルタイムの動作確認ではありません。更新の少ないレポートや横ばいの残高だけでは、シグナル待ちと端末停止を区別できません。成績評価と即時の運用監視は別の仕事として扱います。

実際に取引する環境を監視する

Windows VPSでは、ホストとプロセスの確認、端末の観察、独立した収集側がそれぞれ異なる障害経路を確認できます。リソース不足と起動動作はガイド2で見直します。Windowsへのログイン成功だけではEAの正常動作を確認できません。

MetaTraderの統合型仮想ホスティングでは、ホスティング管理機能から、リモートの稼働状態、同期、取得した端末・Expertsログを調べます。ローカルのチャートや報告は、リモートEAの動作を示しません。リモート側のハートビートは、対応した仕組みを意図的に配置し、その環境で試験する必要があります。Windowsサービスや未対応のDLLツールをそのまま移すことはできません。

ローカルのAutoTradingはホスティング側のコピーを停止しません。介入時はホスティングの管理機能を使い、実際のリモート状態を確認します。監視対象が主系の取引ホスト、ローカルの準備端末、予備のどれなのかを識別してください。

監視の弱点をデモ環境で試す

許可されたデモ環境と、その環境専用の状態ファイルを使います。計画した端末終了、報告経路の遮断、予定された取引休止、意図的な一時停止、通常状態への復帰を試します。実際の警告と、単なる配信試験の成功を区別してください。監視試験のために、実口座のポジションを管理なしの状態にしないでください。

試験した構成、観察結果、残る死角を記録します。監視は不確実性を減らしますが、稼働継続、約定、戦略の成果を保証しません。

EA監視についてよくある質問

新しい取引がないと、EAは故障していますか？

いいえ。取引時間、シグナル条件、データ、権限、既存注文の管理を確認してください。正常な戦略でも、適切に待機することがあります。

ハートビートで全機能の正常性が分かりますか？

いいえ。仕様上の報告が生成された、または受信されたことだけを示します。どの地点で作られ、どの項目が新しいかで意味が変わります。

標準のプッシュ通知はすべての障害を検知しますか？

いいえ。成功した取引の通知に失敗操作は含まれません。停止した端末が自身の完全停止を確実に通知することもできません。独自の警告条件と独立した報告欠落検知を別々に試してください。

報告が来なければ予備VPSを自動起動すべきですか？

いいえ。まず主系の取引状態、現在のブローカー注文、管理の責任を確認します。報告欠落だけでは重複した自動取引を許可できません。

公式資料と実務上の範囲

プラットフォームの詳細はMetaQuotesの公式資料で確認しました。確認の形式、例の閾値、障害対応のルールは運用を学ぶための説明であり、提供する監視製品や測定済み信頼性の結果ではありません。画面の名称は端末の言語で異なるため、自分の環境の表示を確認してください。

• MQL4：接続状態とEAの取引許可。
• MQL4：銘柄の気配値時刻、サーバー時刻の動作、Timerイベントの制約。
• MetaTrader 4：通知設定。MQL4：独自プッシュ通知の制限。
• MetaTrader 4：リモートホスティングの状態とログ。