役に立つフィルターは、「今ある情報で、このEAは新しいポジションを検討してよいか」という実務的な問いに答えます。セッション名や空のカレンダーだけでは判断できません。確認済みの時刻、明確なイベント収録範囲、取引する銘柄の現在のレートが必要です。
まず単純に分けて考えましょう。既存のポジションは固有のルールで管理し、新規エントリーは必須の確認を通過してから検討します。 このガイドでは、その区別を具体化し、短い判断記録と検証方法を示します。完成したEAや収益性の証拠を提供するものではありません。
1. フィルターが制御する対象を決める
取引時間のルール、予定されたニュースによる制限、戦略のエントリー条件を区別します。時間ルールは許可する時間、ニュースルールは除外する時間帯、戦略の条件は売買機会を定めます。最初の二つを通過しても売買機会が生まれるわけではなく、約定や口座リスクの制限も残ります。
結果は明示的に PASS、BLOCK、UNKNOWN の三つに分けます。これは筆者が定めたデータ状態のラベルで、MT4のエラーコードではありません。禁止時間内と分かれば禁止できますが、情報の欠落を通過の根拠にはできません。この例の方針では、禁止でも必須入力が不明でも、新規エントリーの検討を保留します。ポジション管理には、管理用のデータと権限の確認を別に設けます。
2. 検証前に時刻と収録範囲のルールを書く
取引時間帯のガイドの日付ごとの時刻対応と、経済指標カレンダーのガイドのイベント定義を使います。同じ入力を使えば別の人も適用できる、バージョン管理された仕様にまとめましょう。
- 銘柄と対象範囲：ブローカー、口座、銘柄、関連通貨、対象とするイベント群とその後続段階。
- 取引時間：完全な日付、タイムゾーン、曜日のルール、開始・終了時刻を含むかどうか。
- 時刻対応：UTC、必要な現地時間のルール、各日付のブローカーサーバー時刻の検証済みの関係。
- ニュース除外：イベント時刻の出典、前後の時間幅、重複、時刻未確定・延期・変更の扱い。
- データ要件：必要な日付・通貨の収録範囲、データ構造、出典のバージョン、更新状況、経過時間の上限。
- 障害時の対応：新規エントリーの保留条件、監視・管理の継続方法、再開前に照合すべき状態。
現地時間のセッションが深夜をまたぐ場合は、どの取引日に属するかを定め、日付の変更を明示的に処理します。隣接する日付のイベントでも、除外時間帯が判断時刻に重なるものは含めます。夏時間の切り替えでは、重複する時刻や存在しない現地時刻をどう変換するか確認します。時刻対応がないからといって、黙ってパソコンの表示タイムゾーンに置き換えてはいけません。
3. ダウンロードだけでなくカレンダーの保存版を検証する
スナップショットとは、判断に使うため保存したカレンダーの特定バージョンです。ダウンロード成功や空のイベント配列は、完全性の証明になりません。提供元が必要な通貨・日付・イベント種別を扱っているか、必要な全レコードを取得したか、時刻・単位・バージョンを正しく読み取ったかを確認します。
提供元の更新情報と自分の受信時刻は分けて保存します。受信したばかりの応答にも、古いデータが入っている場合があります。新しい版全体の検証が終わってから有効なスナップショットを置き換えます。一部だけのファイルや更新途中の一覧を有効にしてはいけません。更新失敗やキャッシュの再読込で、最後に確認した版の経過時間をリセットしないようにします。
検証済みで十分に新しいスナップショットなら、明示された収録範囲内で対象の除外時間帯が有効ではないことを確認できます。収録範囲の欠落、未解決の予定変更、重要イベントの時刻不明、期限切れは不明のままです。予定どおり、その情報に依存する新規エントリーを保留し、所定の障害処理と管理を継続します。予定外のニュースは、予定表だけでは防げません。
4. 取引する銘柄のレートを別に確認する
対象銘柄のBid/Askの受信と有効性を記録し、再起動や時計変更を扱える方法で経過時間を測ります。受信が新しくても、上流データが最新であることや約定できることの証明にはなりません。配信元と時刻の状況、スプレッド、取引権限は別条件として検証します。EAの監視ガイドも参照してください。
MT4の TimeCurrent() は、OnTick() 内では処理中のティックの時刻を示しますが、ほかのハンドラーでは気配値表示内の別銘柄の最新レートを反映することがあります。自分の銘柄のレートが新しい証拠にはなりません。実運用の TimeGMT() はパソコンの時刻設定に依存し、MT4テスター内ではシミュレーションされた TimeCurrent() と等しくなります。テスター内の差からブローカーの過去の時差は復元できません。
5. 架空の判断記録を追う
この例だけでは、2026-03-16 のUTCセッション [08:00, 17:00) を使います。前のガイドの架空のA/Bニュース除外区間の和集合 [12:15, 13:05) を引き継ぎます。必要な収録範囲とメタデータはすべて検証済みと仮定します。イベントはUTCの一日全体を収録し、この日中の確認と前後の余裕時間には十分です。実在の提供元や発表を示してはいません。
計算説明用に、スナップショットの経過時間を最大 30分、対象銘柄のレートを最大 5秒 とします。筆者が設定した入力値であり、推奨更新設定や安全の保証ではありません。最初のスナップショットは12:00:00に検証され、完全で最新の置き換え版を13:06:00に検証します。17:00:00には別の有効なスナップショットがあります。経過時間は、検証済みで比較可能な時間測定を前提とします。
| 判断時刻 · UTC | 保存版の経過時間 | 対象レートの経過時間 | 時刻・データ確認だけの結果 |
|---|---|---|---|
12:10:00 | 10 min | 1 s | この確認は通過。ほかの確認へ |
12:20:00 | 20 min | 1 s | 禁止：ニュース除外時間内 |
13:05:00 | 65 min | 1 s | 保留：カレンダーが古い |
13:06:06 | 6 s | 12 s | 保留：対象銘柄のレートが古い |
13:06:07 | 7 s | 1 s | この確認は通過。ほかの確認へ |
17:00:00 | 0 s | 1 s | 禁止：取引時間外 |
13:05:00にはニュース除外区間が終わりますが、古いスナップショットは65分前のものです。13:06:06には新しい版は6秒前のものでも、対象銘柄の最終受信は13:05:54で、12秒が経過しています。13:06:06の受信なら、13:06:07時点で経過は1秒です。その行は例示した時刻・データ確認を通過しますが、戦略・約定・リスクの確認を通過したわけではありません。17:00の境界は含みません。注文、決済、収益のシミュレーションはしていません。
6. 管理を維持し、ブローカー側の注文を照合する
新規エントリーの禁止によって、既存ポジションの所定の監視・管理を飛ばしてはいけません。管理操作にも、それぞれ有効なデータと権限が必要です。価格がないからといって、ストップを無条件に変更することはできません。待機注文を維持するか取り消すかを別に定め、取消要求の成功を決めつけず、ブローカーが受け付けた状態を確認します。
MT4のAutoTradingボタンは自動取引リクエストを禁止しますが、EAや OnTick() の実行は続く場合があります。新規エントリー専用の一時停止ではなく、取引リクエストが必要な管理も影響を受けます。EAの削除やターミナルの切断とも区別してください。ブローカー側にある保護とクライアント側の管理は別の仕組みです。リスク管理も参照してください。
7. データ取得で判断処理を止めない
判断には完全な検証済みキャッシュを使い、更新は制御された手順で行います。タイムアウト、失敗の通知、新しい版を有効にする方法を定めます。遅いリクエストの前に管理処理を一度呼んでも、そのリクエストが同じEAを停止させている間、管理が動き続けるわけではありません。
補足：MT4の通信とイベントの制約
MQL4の WebRequest() は同期処理です。同じEAで OnTick() から OnTimer() に移しても非同期にはならず、応答待ちがそのプログラムを遅らせる可能性は残ります。別の取得コンポーネントから検証済みスナップショットを渡す設計も可能ですが、受け渡しと障害時の動作も検証が必要です。タイマーは実行予定を組む仕組みで、管理の無停止を保証しません。
論理的な順序は、所定の管理・監視処理を実行し、新規エントリーの必須確認を評価し、通過した場合だけ現在の売買条件を約定・リスク管理とともに検討する、というものです。これは判断の役割分担であり、実行可能なMQL4コードや処理時間の保証ではありません。依存する前に、実際の統合、権限、障害時の動作を検証してください。
8. 再起動後も残る判断記録を保存する
UTCの判断時刻、サーバー時刻と検証済み対応、ルールの版、スナップショット識別子、出典と受信の時刻、収録範囲、レートの受信時刻と経過時間、有効な除外区間、結果の理由を記録します。通過した確認だけでなく、拒否した候補も残します。後日修正されたカレンダーから再構築しなくても、保留の理由を説明できる記録にしましょう。
再起動・再接続後は、既存ポジション、待機注文、未解決のリクエストをブローカーと照合します。復元するのは確認できる状態だけです。再起動したからといって、ポジションがないともキャッシュが新しいとも限りません。同じ候補の重複処理を防ぎます。必要な状態が不明なら照合まで新規エントリーを保留し、所定の障害対応と管理を続けます。
9. バックテストを解釈する前に正しい動作を確認する
市場での成績を調べる前に、期待結果が決まった小さな固定ケースを作ります。次を含めてください。
- セッション開始を含み、終了を含まない境界、および深夜をまたぐ区間。
- ニュース除外の開始・終了、イベントの重複、延期・変更された予定。
- 欠落、一部のみ、不正な形式、収録範囲外のカレンダーデータと、未検証の空の応答。
- 選んだ経過時間の上限ちょうどと直後、および別銘柄の新しいティックが来ても対象銘柄のレートは古い場合。
- 再起動、時計の飛び、更新失敗、スナップショット置き換え中断で経過時間をリセットしないこと。
- 新規エントリー禁止中のブローカー側注文と管理処理。取消拒否や取引権限がない場合も含める。
MT4のストラテジーテスターは WebRequest() を実行せず、Timer イベントも処理しません。共通の判断ロジックは、固定したデータと検証済みの過去の時刻対応を用い、対応するテスト経路で動かします。各スナップショットは、当時利用できた時点以降にだけ再生します。過去のイベント表だけでは、実際の取得やタイマー実行は再現できません。全般的な制約は MT4バックテストガイドを参照してください。
10. 正常動作と効果を別々に検証する
正しく実装されたフィルターでも、負け取引だけでなく勝ち取引を除外します。同じ戦略・データ・コスト前提で、提案するルールと事前に定めた基準を比較します。全候補と拒否理由を残し、後の期間のデータを検証用に分け、現実的な 約定コストを含めます。多数の時間帯を探索して最良のものだけ報告すると、標本への過剰適合が起き得ます。
次にデモ環境で、正常時とデータ障害時の実際の統合動作を継続観測します。更新失敗、古いデータによる保留、レートの空白、管理の遅延、ブローカーの注文応答を測ります。整理されたログは動作を示しますが、将来の収益性は証明しません。利用を広げる前に、次を確認します。
- バージョン付き仕様、時刻対応、イベント選定方針が文書化されている。
- 収録範囲とデータ経過時間の確認で、制限なし・禁止・不明を区別できる。
- 境界と障害のケースが期待結果に一致する。
- 過去検証が情報の利用可能時点を守り、欠けている履歴を明示する。
- デモで取得、再起動、管理の継続、ブローカー側の注文状態を確認する。
- 効果を述べる場合は別に評価し、コストと後のデータを使い、架空の成績数値を使わない。
11. EAフィルターのよくある質問
カレンダーに制限がなければ、EAはエントリーすべきですか？
いいえ。検証済みカレンダーに制限がないことは、判断の一部分を通過するだけです。取引時間、レート品質、約定、口座リスク、現在の戦略条件の確認が残ります。予定外のニュースも発生します。
取得したばかりでも不明になるのはなぜですか？
応答が古い、不完全、必要な収録範囲外、または読み取りが誤っている可能性があります。受信時刻だけでは提供元のデータを検証できません。必要な確認を通過するまで、その入力に依存する新規エントリーを保留します。
MT4テスターで実際のニュース取得をテストできますか？
文書化されたテスターはWebRequestを実行せず、Timerイベントも扱いません。固定し版管理した入力と対応する実行経路で共通判断ロジックを検証し、実際の取得と実行予定は別途デモで確認します。
ニュース時の停止にAutoTradingを使うべきですか？
対象は新規エントリーだけではなく、管理が使う自動取引リクエストも禁止される場合があります。ここで扱うのは、管理の責任を別に検証した内部のエントリー制御です。保有リスクを一括でなくす万能スイッチではありません。
12. 参考資料と適用範囲
公式の MQL4 WebRequestリファレンスは同期リクエストと制約を説明しています。MT4ストラテジーテスターの制限には、時刻シミュレーションと未対応の外部関数・イベントが記載されています。他のプラットフォームの例が使えると決めつけず、自分のプラットフォームと統合構成で利用可能な機能を確かめてください。資料確認日：2026-10-17。
このガイドは、取引時間帯・ニュースのガイド群を、ルールと検証の枠組みで締めくくります。予定、スナップショット、経過時間、結果は説明用の架空例です。上限値は推奨設定ではなく、EAの実行や取引成績も主張していません。フィルターは市場・約定・口座のリスクをなくすものではありません。