テクニカルEA化
時間帯フィルターをEAに入れるときの落とし穴
公開 2026.06.16最終確認 2026.06.16
「東京時間だけ」「ロンドン時間だけ」——時間帯フィルターはEA設計でよく使う手法だ。
しかし見落としやすい落とし穴があり、安易に入れると逆に性能を悪化させることがある。
結論
主な落とし穴は3つ。
- サーバー時間とローカル時間のズレ: MT5のサーバー時間はGMT+2/+3の業者が多い。日本時間のつもりで設定するとズレる。
- サマータイムの切り替え: 米・欧のサマータイム切替日に時間がズレる。年に複数回、無視できない。
- 過剰最適化: 「この時間帯だけPFが高い」は過去データに合わせた結果であり、将来も有効とは限らない。
なぜEA運用で重要か
時間帯フィルターは「不利な時間を避ける」目的では有用。早朝のスプレッド拡大や流動性の低い時間を避けるのは合理的。
しかし「特定の時間帯だけで回す」設計にすると取引回数が大きく減り、統計的信頼性が下がる。市場の時間帯特性は年単位で変わりうる。
仕組み・条件
MT5のサーバー時間
多くの業者がGMT+2（冬）/ GMT+3（夏）。日本時間（GMT+9）との換算：
- GMT+2 → JST = サーバー時間 + 7時間
- GMT+3 → JST = サーバー時間 + 6時間
MQL5での実装（GMT基準がズレに強い）
// サマータイムのズレを避けるため TimeGMT() を基準にする
datetime gmt_time = TimeGMT();
MqlDateTime g;
TimeToStruct(gmt_time, g);
int gmt_hour = g.hour;
// ロンドン時間8:00〜17:00（GMT）でフィルター
bool is_london_session = (gmt_hour >= 8 && gmt_hour < 17);サマータイム
| イベント | 時期（2026年の例） | 影響 |
|---|---|---|
| 米サマータイム開始 | 3月第2日曜 | NY時間が1時間前倒し |
| 米サマータイム終了 | 11月第1日曜 | NY時間が1時間後ろ倒し |
| 欧サマータイム開始 | 3月最終日曜 | ロンドン時間が1時間前倒し |
| 欧サマータイム終了 | 10月最終日曜 | ロンドン時間が1時間後ろ倒し |
米と欧で切替日が異なるため、その期間はオーバーラップ時間が変わる。
バックテストやリアル運用で壊れるポイント
- サーバー時間を日本時間と勘違い → 意図と違う時間にフィルターがかかる
- サマータイムを考慮しない → 年に複数回フィルターが1時間ズレる
- 「ロンドン時間だけPFが高い」を採用 → 過去データへのフィットの可能性
- フィルターで月30回以下に → 統計的に有意な判断ができない
- 業者のサーバー時間変更でフィルターが全面的にズレる
どう確認するか
- サーバー時間のGMTオフセットを確認する（
TimeCurrent()とTimeGMT()の差） - フィルターは
TimeGMT()基準にし、サーバー時間に依存させない - サマータイム切替月（3月・10月・11月）前後で結果を確認する
- フィルターあり／なしで取引回数とPFの両方を比較する
- フィルター後の取引が月50回未満なら統計的信頼性に注意する
自分の検証スタンス
時間帯フィルターは「不利な時間を避ける」目的に限定して使う。「有利な時間だけを狙う」使い方は過剰最適化のリスクが高い。
具体的には早朝のスプレッド拡大時間を避けるフィルターを基本にし、「どの時間が一番利益につながるか」の最適化はしない。
参照した公式情報
免責
本記事は個人の検証メモであり、投資助言ではありません。時間帯フィルターの効果は市場環境の変化により変動する可能性があります。サーバー時間の設定は業者によって異なるため、利用する業者の仕様を確認してください。