MT5価格アラート：価格側、再待機、JSTと欠測を確認

EUR/USDが指定条件を満たしたら通知を受けたい、という仮の作業を考えます。デスクトップMT5の価格アラートは確認を促しますが、約定価格の確保や建玉の保護をする注文ではありません。価格の側、監視する端末、配送経路を分けて検査します。

アラートと損切り注文は別

通常のデスクトップAlertsは稼働中の端末が受信データで判定します。終了、PCのスリープ、最新レートの途絶は監視を中断させます。サーバーに受け付けられた損切りや利確は役割が違い、デスクトップを閉じても動作し得ます。ただし通常のストップは約定価格や損失額を保証しません。端末終了時のSL/TPも確認してください。

業者が対応する取引サーバー通知は別機能です。PC停止中に注文・約定・残高操作の通知を受けられても、自作のデスクトップ価格条件がサーバーへ移ったとは限りません。Sound、Email、Notificationは通知アクションです。Fileは実行ファイルを起動でき、影響はそのプログラム次第です。普通の通知に必要な操作ではありません。

MT5標準の条件で指定できるもの

標準画面にはBid・Ask・Lastの比較、直近約定の数量比較、Time条件があります。選んだ銘柄の提供データと現行ヘルプを確認します。

Lastや直近約定数量は、その銘柄が適切なデータを供給する場合に意味があります。世界のFX全取引を示すものではありません。仮のEUR/USDがBid1.09990、Ask1.10002ならAskは1.10000超、Bidは未達。pip0.0001ではスプレッド0.00012/0.0001=1.2 pipです。厳密な>と≥も異なります。

アクションはSound、File、Email、Notificationから目的に合わせて選び、反復間隔・最大反復回数・有効期限を別に設定します。Timeと期限は稼働PCのローカル時計で、業者の足の時計とは限りません。標準画面は任意の指標式を入力する編集機能ではありません。

元の例を2026年7月1日に固定します。13:00 UTCの仮の予定は、Europe/WarsawのPCならUTC+2で15:00、UTC設定のVPSなら13:00です。15:00をそのまま移すと二時間遅れます。同じ瞬間は東京PCのJSTで22:00。22:00をUTCのVPSへ写すと、日本では翌7月2日07:00となり九時間遅れます。実際の設定時計と日付を確認し、外国の夏時間切替前後は再換算します。

価格アラートの設定手順

1. 表示メニューまたはCtrl+Tでツールボックスを開き、Alertsタブへ移動します。
2. 一覧を右クリックし、Createを選びます。
3. 価格・数量判定の対象銘柄を選びます。Time条件では銘柄は判定に関係しません。
4. ConditionでBid >またはBid <を選び、Valueへ例として1.0900を指定します。等号やAsk条件とは別です。
5. ActionでSound、Email、Notificationなど必要な経路を選び、その経路を試します。音の成功だけで電話への配送まで確認したとは扱いません。
6. Expirationを指定して古い水準を残し続けないようにし、OKで設定を適用します。

有効にする前に現在のBid・Askなど指定入力と比較してください。既に真なら、新しいクロスを待つとは限りません。期限・反復回数を決め、Testで経路を試したうえ、確認しやすいデモ条件の検出を別に観察します。元データ時刻と実受信時刻を記録します。一度の成功は将来すべての到達を保証しません。無効化は削除とは別です。

プッシュとメールを別々に検査

モバイルアプリのMetaQuotes IDをデスクトップの通知設定へ入力し、プッシュを有効化してTestを送ります。届かなければID、通知権限、ネットワーク、端末ログを確認します。失敗頻度や一律の到達秒数を仮定しません。

メールはTools→Options→Emailで、利用するSMTPサービスが許可するサーバー、ポート、認証方式、送受信先を設定します。Test後に受信箱と迷惑メールを確認してください。認証情報を含む画像や設定ファイルを公開しません。プッシュ成功はSMTP試験ではなく、メール成功も価格条件の検出試験ではありません。

鳴らないときの切り分け

Enable、銘柄、期限、反復上限を先に確認し、接続とレートの新鮮さ、Bid/Ask側を調べます。ログで条件未検出と、生成済み通知の配送失敗を区別します。一項目ずつ変えると、次の試験で原因を絞れます。

通常のリモートPCでMT5を稼働させれば、自宅PC停止中も監視を続けられる場合がありますが、切断や再起動は起こり得ます。MetaQuotesの仮想ホスティングは別環境で、EA・チャート・設定の移行規則があります。契約しただけで通常のAlerts一覧が移ると決めつけず、MQL通知プログラムなら移行対象と遠隔ログを確認します。

指標条件と予定時刻はどう扱うか

標準画面の価格・数量・時刻条件は、任意の指標式と同じではありません。必要な判定はインジケーターやEAで実装できますが、そのコードと実行環境を別に検査します。

予定発表のTime通知は指定時刻のリマインダーであり、実際の発表を待つ処理や値動きの予測ではありません。公表元の日付・時刻帯を確認し、実行PCのローカル時刻へ変換します。通知後に何を見るかも決めます。経済カレンダーで発表内容の確認手順を学べます。

二つの通知が届いても、二条件が同時成立した証拠にはなりません。仮に同一観測でBid>1.1000かつスプレッド<2 pipを要求します。pip0.0001のEUR/USDでt1のBid/Ask1.1002/1.1006は4 pipで価格だけ成立。t2の1.0998/1.0999は1 pipでスプレッドだけ成立。どちらの観測も全条件を満たしません。

別の観測の通知が同時に届くこともあります。配送時刻は入力の判定時刻ではありません。複合条件は同じ観測の入力とタイムスタンプを必要とし、標準画面へその任意式を入力できるとは限りません。受信後は現在価格と残り条件を確認し、古い「成立」を無期限に持ち越しません。

次に試すこと

1. 管理できる水準数を選び、各水準の理由を記録します。三つは作業例で、証拠のある最適数ではありません。
2. 一つのテスト通知とログを実際に確認します。一度の成功はその時の確認で、継続的な信頼性の証明ではありません。
3. 使うMetaQuotes IDで対象端末の受信まで確認します。権限と接続も調べ、送信表示だけで将来の全受信を確認したとは扱いません。
4. 有効期限をセットアップの寿命に合わせます。口座・銘柄・計画を変えた後も、説明が意図した条件を表すか見直します。
5. 水準、元データ時刻、通知時刻、判断を記録します。中断と有用だった通知を分け、一か月で必ず結論が出るとは仮定しません。