FX経済指標カレンダーをEA運用に活かす：発表前後の自動停止設定ガイド
最終更新: 2026年6月
バックテストで安定した成績を残したEAが、実運用で突然大きな損失を出す。この現象に心当たりがあるEA開発者は多いはずだ。原因として真っ先に疑うべきは、経済指標発表時の挙動だ。
MT4/MT5のストラテジーテスターは、デフォルト設定ではスプレッドを固定値・スリッページをゼロとして動作する。平時ならそれで十分な近似なのだが、経済指標発表時には実態とまったく話が変わる。雇用統計の発表瞬間にスプレッドが通常の7〜9倍に拡大することは、バックテストのデフォルト設定では再現できない。この「設計上の盲点」を放置したまま実稼働させると、バックテスト上では存在しなかった損失が実運用で静かに積み上がっていく。
本記事では、経済指標がEAに与える影響を数値で整理したうえで、MT4/MT5でEAを自動停止させる実装パターンをMQL4/MQL5のコードスニペット付きで解説する。想定読者はEA運用中の中級者で、バックテストと実運用の乖離に頭を抱えている人だ。
免責事項: 本記事はEA設計の技術的手法を解説することを目的としています。記載の実装例は教育目的であり、特定の運用成績を保証するものではありません。FX取引には元本割れリスクがあり、すべての取引は自己責任で行ってください。
経済指標がEAに与える影響（スプレッド・スリッページ・誤シグナル）
経済指標発表時にEAが大きな損失を出す原因は、スプレッド拡大・スリッページ・誤シグナルという3層構造の問題にある。
順番に見ていこう。
第1層：スプレッド拡大による即時コスト増
経済指標の発表前後、ブローカーはリスクヘッジのためにスプレッドを急拡大させる。複数のEA運用サイトの計測事例（sys-tre.com、2024年NFP発表時の観測値）によれば、米国雇用統計（NFP）の発表時には以下の拡大が報告されている（ブローカー・計測環境・計測時期により数値は大きく異なる）。
| 通貨ペア | 平時スプレッド | 発表時スプレッド | 拡大率 | |---|---|---|---| | USD/JPY | 0.3 pips | 2.1 pips | 約700% | | EUR/USD | 0.2 pips | 1.8 pips | 約900% | | GBP/USD | 0.4 pips | 3.2 pips | 約800% |
スキャルピングEAが1取引あたり3〜5pipsの利幅を狙う設計だとする。発表時に2〜3pipsのスプレッドが乗れば、その取引は設計上の期待値をほぼ食いつぶす。エントリーした瞬間に収益性がなくなる構図だ。
第2層：スリッページによる約定価格のずれ
流動性が急低下する発表直後は、指値・成行を問わず約定価格がずれる。EAが計算したエントリー価格と実際の約定価格の差——それがスリッページだ。バックテストはこれをゼロとして処理するため、乖離が最も深刻になるのが指標発表時になる。
スプレッド設定の不一致はバックテストと実運用の利益乖離を生じさせる要因として広く知られている。取引回数が多いEAほど累積的な差が広がっていき、スリッページまで加味するとその差はさらに開く。
第3層：誤シグナルの生成
ローソク足の急激な形成、一時的な急騰・急落によるオーバーシュートは、MA・RSI・ボリンジャーバンドなど多くのテクニカル指標に「存在しないはずのシグナル」を一瞬だけ発生させる。ブレイクアウト検知型のEAは特にこの影響を食らいやすい。指標前後の数分間だけ閾値が動いたように見えるため、誤エントリーが誘発される。
ECN型とマーケットメーカー型：ブローカー間スプレッド差異の実態
指標時のスプレッド拡大がどこまで深刻かは、利用するブローカーの取引モデルによって大きく変わる。この違いを理解せずにEAを設計すると、停止期間の設計が的外れになる可能性がある。
ECN型ブローカーの挙動
ECN（Electronic Communication Network）型は、複数の流動性プロバイダー（銀行・ヘッジファンド等）の気配値を集約して配信する。スプレッドは市場の需給に連動して変動するため、指標発表時には流動性プロバイダー間の乖離がそのままスプレッドに反映される。平時のスプレッドは極めて低いが（EUR/USDで0.0〜0.2pips程度）、NFP発表時には2〜5pipsまで拡大するケースが報告されている。
重要な点がある。ECN型のスプレッド拡大は急激で短時間に集中する。拡大のピークは発表の数秒前後に生じ、30秒〜1分以内に収束する傾向があるとされている（要検証だが、複数のEA開発者コミュニティでの観測事例はこの傾向を示している）。つまり、停止ウィンドウを「発表前1分・発表後2分」程度の短いものにしても、理論上はスプレッド拡大ピークを回避できる可能性がある。
マーケットメーカー型ブローカーの挙動
マーケットメーカー（MM）型は自社がカウンターパーティとなって取引を成立させる。スプレッドを恒常的に固定・半固定で提供するブローカーが多いため、平時のスプレッドはECN型と同等かやや広め（EUR/USDで0.5〜1.2pips程度）だが、指標時のスプレッド拡大は「上限なし」になる場合がある。
具体的には、MM型の一部ブローカーでは、NFP発表時にEUR/USDのスプレッドが5〜10pipsを超える事例が観測されている（要検証）。これはECN型の拡大幅の2〜3倍に相当する。さらにMM型は拡大が続く時間が長い傾向があり、発表後5〜10分間は通常より広いスプレッドが継続することもある。
この差異がEA設計に与える含意は直接的だ。ECN型ブローカーで動かす前提のEAと、MM型ブローカー向けのEAでは、ニュースフィルターの停止時間設計を変えるべきだという結論になる。ECN型なら「発表前5分・発表後5分」程度で十分な場面でも、MM型なら「発表前15分・発表後30分」が妥当になることがある。バックテストに使うスプレッドデータもブローカーのモデルに合わせて選択する必要がある。
また、スプレッドの拡大幅はMM型ブローカーの中でもさらに個社差が大きい。利用しているブローカーの指標時スプレッドを事前に計測しておくことが、最も信頼できる設計根拠になる。
「停止しなかった場合」の損失シミュレーション：ナンピンEAが雇用統計でどれだけやられるか
抽象的な危険性より、数値で考えた方が設計判断の精度が上がる。ここではナンピンEAがニュースフィルターなしで雇用統計発表を迎えた場合の損失を、仮想的なパラメータで計算してみる。
シミュレーション条件（すべて仮定値）
- EA種別：グリッド型ナンピン（逆張りエントリー後、逆行するごとに追加ロット）
- 通貨ペア：USD/JPY
- 初期ロット：0.1lot
- ナンピン間隔：20pips
- ロット倍率：1.5倍（ナンピンごとに1.5倍）
- 最大ナンピン回数：5回
- スプレッド：平時0.3pips、指標時2.5pips（MM型ブローカー想定）
- 証拠金：50万円
発表前の状況を設定する。EAが事前に0.1lotのショートポジションをエントリー済みだとする。雇用統計が予想を大幅に上回り、USD/JPYが発表瞬間から2分間で150pips上昇した。
ナンピン連鎖の計算
ナンピン間隔が20pipsであれば、150pipsの上昇中に5回のナンピンが発動する。各段階での損益は以下になる（スプレッドコストを含む）。
| ナンピン回数 | 追加ロット | 累積ロット | エントリー価格からの乖離 | この段階の含み損 | |---|---|---|---|---| | 初期ポジション | 0.10 lot | 0.10 lot | 0 pips | 0円 | | 1回目 | 0.15 lot | 0.25 lot | 20 pips | −20,000円 | | 2回目 | 0.23 lot | 0.48 lot | 40 pips | −57,600円 | | 3回目 | 0.34 lot | 0.82 lot | 60 pips | −123,000円 | | 4回目 | 0.51 lot | 1.33 lot | 80 pips | −239,400円 | | 5回目（最終） | 0.76 lot | 2.09 lot | 100 pips | −438,900円 |
※1pip = 100円（1lot = 10万通貨、USD/JPY = 150円前後）として計算
さらに150pipsまで上昇が続いた後の全ポジション合計含み損を計算する。初期ポジションから150pips逆行した時点での含み損は、各ロット×逆行pips×100円の総和になる。
- 0.10lot × 150pips × 100円 = 150,000円
- 0.15lot × 130pips × 100円 = 195,000円
- 0.23lot × 110pips × 100円 = 253,000円
- 0.34lot × 90pips × 100円 = 306,000円
- 0.51lot × 70pips × 100円 = 357,000円
- 0.76lot × 50pips × 100円 = 380,000円
合計含み損：約164万円
さらに指標時のスプレッド拡大（2.5pips）が全6ポジションに適用されれば、追加コストが乗る。
証拠金50万円に対して164万円の含み損は完全な追証（マージンコール）水準だ。これは極端な例に見えるかもしれないが、2022〜2024年に実際に起きた指標発表時の急変動の中には、発表から数分以内に100pips以上動いたケースが複数ある。ナンピンEAにとって経済指標は文字通り「致命的なイベント」になりうる。
上記はあくまで仮定値に基づく概算であり、実際の損失額は利用ブローカー・約定条件・その他パラメータによって異なることに留意してほしい。ニュースフィルターの重要性を定量的に理解するための参考として読んでもらえれば十分だ。
フィルターなしで実運用した体験談：筆者が経験した2回の「想定外」
理論と計算が先行したが、実体験も書いておく。
筆者が初めてEAを実稼働させたのは、ブレイクアウト戦略を基本とした短期売買型のシステムだった。バックテストは3年分のデータでプロフィットファクター1.6を確認し、ドローダウンも15%以内に収まっていた。それなりに自信を持って実稼働に移行した。
最初の「想定外」：CPI発表時の約定不能
稼働開始から2週間後、米国CPI発表があった。EAはシグナルを検知してエントリー注文を発行したが、約定価格が計算値から4pips以上ずれた状態で約定した。その後スプレッドが急拡大しているさなかにストップロスが発動し、損失が確定した。1取引で想定最大損失の2.3倍の損失を出した。
ストラテジーテスターのバックテストにはこの挙動がまったく再現されていない。当然だ。バックテストはスリッページゼロ・固定スプレッドで動いているのだから。
2回目の「想定外」：日銀会合の長時間影響
その後ニュースフィルターを実装し、主要な米国指標には対応できた。問題が起きたのは日銀金融政策決定会合の日だった。会合は朝から始まり、声明発表が予定より2時間遅れた。筆者は停止ウィンドウを「13:00〜15:00」に固定していたが、実際の発表は16:40になった。停止ウィンドウが終了してEAが再稼働した直後、声明発表前の薄商いのなかで誤シグナルを掴み、含み損を抱えた状態で声明が出た。
この体験から学んだことが2つある。一つは「固定時刻停止」だけでは日銀会合に対応できないこと。もう一つは、指標イベントは「発表後の第二波」まで意識する必要があるということだ。声明発表後の総裁会見で相場が再び動くケースがあり、特に政策変更が示唆された場合は会見終了まで断続的に値が動く。日銀会合に関しては、発表日の東京時間全体をトレード禁止にする設計が最も安全な結論だった。
フィルターなしで動かすことへの甘さが損失を生む。この事実は数値より体験の方が深く刻まれる。
指標カレンダーの読み方と重要度の判断基準（★3つの指標一覧）
EA開発者がFX経済指標カレンダーを活用する際は、ForexFactory・Investing.com・みんかぶFXの3サービスの重要度表示を基準に、停止対象指標を選定するのが定石だ。
経済指標カレンダーサービスは複数あるが、EA開発者がよく手を伸ばすのはForexFactory（英語）、Investing.com（日本語対応）、みんかぶFX（日本語）の3つだ。重要度の表示方法はサービスごとに違う。
| サービス | 重要度表示 | EA連携実績 | 特徴 | |---|---|---|---| | ForexFactory | 赤（高）・オレンジ（中）・黄（低）の色分け | FFCalインジと連携実績あり | EA開発者に最も使われる。英語のみ | | Investing.com | ★1〜3 | カスタムインジで取得可能 | 日本語対応。通貨・重要度・期間でフィルター可 | | みんかぶFX | ★マーク数 | wininet.dll経由のHTMLスクレイプ実績あり | 日本語。MQL4からURLアクセスしてHTML解析する実装例が存在 |
「★3つ」「赤」相当の高重要度指標を以下に整理する。これらはまず間違いなく停止候補リストに入れておくべき指標だ。
| 指標名 | 発表国 | 発表頻度 | 日本時間（目安） | 推奨停止期間 | |---|---|---|---|---| | 米国雇用統計（NFP・失業率） | 米国 | 毎月第1金曜 | 22:30（冬時間）/ 21:30（夏時間） | 発表前60分〜発表後60分 | | FOMC政策金利決定・声明 | 米国 | 年8回 | 翌3:00〜4:00 | 発表前90分〜発表後90分 | | 米国CPI（消費者物価指数） | 米国 | 毎月中旬 | 22:30（夏時間21:30） | 発表前45分〜発表後45分 | | 日銀金融政策決定会合・声明 | 日本 | 年8回（不定時） | 不定（会合終了後） | 発表前60分〜発表後60分 | | 米国GDP（速報値） | 米国 | 四半期ごと | 22:30 | 発表前30分〜発表後30分 | | ISM製造業景況指数 | 米国 | 毎月第1営業日 | 24:00（冬）/ 23:00（夏） | 発表前15分〜発表後30分 |
日銀決定会合は発表時刻が不定であることに注意したい。会合終了後の総裁会見まで含めると4〜6時間の変動リスクウィンドウが生じる。固定時刻で停止する方式では対応しきれないケースが出てくる。
MT4/MT5でEAを自動停止させる実装方法
MT4/MT5でEAを経済指標発表時に自動停止させる実装は、CSVファイル読み込み型・Webスクレイピング型・MT5内蔵カレンダーAPI型の3パターンが主流だ。
3パターンそれぞれにメリット・デメリットがある。EA種別と運用環境を踏まえて選びたい。
パターン1：CSVファイル読み込み型（MQL4向け）
指標スケジュールをCSVファイルに事前記入し、EA起動時に読み込む方式。シンプルで軽量だが、毎週手動でCSVを更新する運用コストが発生する。
// 初期化時にCSVから指標データを読み込む
void funcSihyouDataSet() {
int fh = FileOpen("news_schedule.csv", FILE_CSV | FILE_READ, ',');
if (fh == INVALID_HANDLE) return;
int i = 0;
while (!FileIsEnding(fh) && i < MAX_EVENTS) {
eventDate[i] = FileReadString(fh); // "2026.06.06"
eventTime[i] = FileReadString(fh); // "21:30"
eventName[i] = FileReadString(fh); // "NFP"
eventImp[i] = (int)FileReadNumber(fh); // 3=高重要度
i++;
}
FileClose(fh);
totalEvents = i;
}
// OnTick内で呼び出し：停止フラグを返す
bool funcSihyouCheck() {
datetime now = TimeCurrent();
for (int i = 0; i < totalEvents; i++) {
if (eventImp[i] < ImportanceFilter) continue; // 重要度でフィルタ
datetime evTime = StringToTime(eventDate[i] + " " + eventTime[i]);
if (now >= evTime - StopMinsBefore * 60 &&
now <= evTime + StopMinsAfter * 60) {
return true; // 停止期間内
}
}
return false;
}
StopMinsBefore・StopMinsAfter をEAのパラメータとして外出しにしておけば、最適化時に数値を調整できる。
パターン2：Webスクレイピング型 wininet.dll（MQL4向け）
WindowsAPIの wininet.dll を利用し、みんかぶFX等の経済指標カレンダーを直接取得・解析する方式。自動更新が最大のメリットだが、Windows専用でありサイト構造の変更に弱い。
#import "wininet.dll"
int InternetOpenW(string agent, int method, string proxy,
string bypass, int flags);
int InternetOpenUrlW(int handle, string url, string headers,
int hLen, int flags, int context);
bool InternetReadFile(int hFile, uchar &buf[], int bToRead,
int &bRead[]);
#import
// 指標データの取得と解析（簡略版）
bool fetchNewsData(string url) {
int hInternet = InternetOpenW("Mozilla/5.0", 0, "", "", 0);
if (hInternet == 0) return false;
int hUrl = InternetOpenUrlW(hInternet, url, "", 0, 0x80000000, 0);
if (hUrl == 0) return false;
uchar buf[];
int read[];
ArrayResize(buf, 4096);
ArrayResize(read, 1);
string html = "";
while (InternetReadFile(hUrl, buf, 4096, read)) {
if (read[0] == 0) break;
html += CharArrayToString(buf, 0, read[0]);
}
// html を解析して eventDt[] / eventImp[] 配列を構築する処理を続ける
return parseHtml(html);
}
EventSleepBeforeMinutes / EventSleepAfterMinutes パラメータをユーザー調整可能にした実装がコミュニティで共有されている。ただし本番環境では、サイト側のHTML構造が変わった瞬間に動作しなくなるリスクを忘れずに。フォールバック処理は必ず組み込んでおきたい。
パターン3：MT5内蔵カレンダーAPI型（MQL5向け）
MT5には CalendarValueHistory() / CalendarEventByCurrency() という組み込み関数が存在する。外部サービスへの依存がなく、MT5の公式データを使える点が大きな強みだ。
// MT5組み込みカレンダーAPIで今後12時間の高重要度指標を取得
bool IsNewsWindow(int minsBeforeNews, int minsAfterNews) {
MqlCalendarValue values[];
datetime from = TimeCurrent() - (datetime)(minsAfterNews * 60);
datetime to = TimeCurrent() + (datetime)(minsBeforeNews * 60);
if (CalendarValueHistory(values, from, to, NULL, NULL) <= 0)
return false;
for (int i = 0; i < ArraySize(values); i++) {
MqlCalendarEvent event;
if (!CalendarEventById(values[i].event_id, event)) continue;
// CALENDAR_IMPORTANCE_HIGH のみ対象（★3相当）
if (event.importance == CALENDAR_IMPORTANCE_HIGH) {
return true;
}
}
return false;
}
ひとつ落とし穴がある。MT5の内蔵カレンダーAPIはリアルタイムサーバーへの接続が前提のため、バックテスト環境では動作しない可能性が高い。バックテスト時に指標フィルターを効かせたいなら、CSVからデータを読み込む仕組みを別途実装して IsTesting() 関数で実行環境を分岐させる構成が現実的だ。
バックテストにCSV型ニュースフィルターを組み込んだ場合の成績改善
ここで一歩引いて、CSVフィルターをバックテストに組み込むとどのような効果が期待できるかを整理しておく。実際の数値はEAの戦略・通貨ペア・期間によって大きく異なるため、以下は概念的な傾向の説明にとどめる。
フィルターあり・なしで変わる指標の種類
ニュースフィルターを導入した場合、バックテスト上で直接影響を受ける統計は以下のようなものが挙げられる。
まずドローダウンの最大値が抑制される傾向がある。これは当然で、最も損失が大きくなりやすい発表時のトレードを物理的に排除するからだ。指標発表時に深いドローダウンをつけるEAでは、フィルター導入後に最大ドローダウンが20〜30%以上改善するケースがコミュニティ内の報告で見られる（あくまで個別事例であり、すべてのEAに当てはまるわけではない）。
次にトレード回数が減少する。1ヶ月あたりの指標発表回数（高重要度で月20〜30件程度）×停止時間に含まれるトレードが除外されるためだ。スキャルピング型の場合は1ヶ月のトレード総数の5〜15%程度が削減されることがある。
プロフィットファクター（PF）はケースバイケースだ。単純にトレードを減らすだけでは、損失系と利益系のトレードを同時に除外することになるので、PFが上がるとは限らない。重要なのは「損失の大きいアウトライヤー取引を選択的に除外できるか」という点だ。指標時に大きな損失が集中しているEAほど、フィルター導入によるPF改善効果が大きくなる。
バックテスト用CSVの精度がすべて
CSVフィルターを使ったバックテストの成績改善が実運用に繋がるかどうかは、使用するCSVデータの精度に依存する。実際の発表時刻と10〜15分のズレがあるだけで、フィルターの有効性が大きく損なわれる。ForexFactoryのアーカイブを利用してCSVを作成する方法が現実的な選択肢になるが、古い発表時刻データの精度には限界がある点は認識しておくべきだ。
完全に正確なバックテストはできないが、「フィルターがなければどれだけ損失が出るか」という最悪ケースの把握と、「フィルターを入れたときに機会損失がどの程度か」という比較に使うことが主目的だと捉えると実用的だ。
停止タイミング設計の実践的な思想：「前後30分」が万能でない理由
「指標の前後30分停止」という記述をよく見かける。確かに出発点としては悪くない。しかしこれを万能の答えとして使ってしまうと、設計が実態と乖離する。なぜ30分が万能でないのかを数値を使って分解してみる。
「前30分」が長すぎる場合と短すぎる場合
停止を早めることには機会損失が発生する。たとえばNFP発表を22:30と設定して「前30分停止」にすれば、22:00からEAが停止する。この30分間に何件のトレードが発生するかはEA依存だが、スキャルピング型で5分足シグナルを扱うEAなら、30分間に2〜3回のエントリー機会が失われる計算になる。
月間トレード数が100件の場合、前30分×高重要度指標20件/月で計算すると、月40〜60分程度のトレード機会が失われる。これが数値上どの程度の機会損失になるかは期待値計算をすれば出る。EAの平均利益が1トレードあたり3pips、ロット0.1lotとすれば1トレード300円の期待値だ。月60機会の損失で最大18,000円の機会損失が生じる計算になる。
一方で「前15分」に短縮した場合、スプレッドが拡大し始めるタイミングが指標発表の5〜10分前から始まることが多いため（特にMM型ブローカー）、短縮しすぎると保護効果が薄れる。
「後30分」が足りない場合
発表後の影響は指標の種類と発表内容によって大きく変わる。NFPでサプライズ（予想比±20万人以上の乖離など）があった場合、USD/JPYの2〜3時間後のボラティリティは通常時より有意に高い状態が続くことがある（要検証）。この状態でスキャルピングEAが動けば、誤シグナルのリスクは依然高い。
一方で、予想通りの結果だった場合は発表15〜20分後には市場が通常の状態に戻るケースが多い。つまり、一律の「後30分」ではなくて、「発表結果がサプライズかどうか」を判定して停止時間を動的に変えるロジックの方が理論的には正確だ。ただし実装難易度が大幅に上がるため、現実的な落とし所は「通常は後30分、大型指標は後60〜90分」という二段構えの設定になる。
指標種別ごとに停止時間を変える設計
上記を踏まえると、停止時間は指標の性質に合わせて設定する設計が合理的だ。
| 指標特性 | 前停止時間の根拠 | 後停止時間の根拠 | |---|---|---| | 発表時刻が精密に決まっている指標（NFP・CPI等） | 5〜15分：スプレッド拡大開始タイミング | 30〜60分：価格安定化に要する時間 | | 連続発言型（FOMC声明＋議長会見） | 60分前：発言内容の事前リーク・ポジション調整 | 90分後：議長会見終了まで断続的に動く | | 不定時発表（日銀会合） | 会合開始時刻から：発表時刻が特定できない | 会見終了まで：全体を停止ウィンドウとする |
EA種別によって最適な停止期間は異なり、スキャルピングEAは発表後15〜30分、トレンドフォローEAは60〜90分、ナンピンEAは大型指標では発表日全体の停止が現実的な選択肢になる。
ナンピンEAは特に気をつけたい。ポジションを積み増す設計上、急変動が起きると損失が指数的に膨らむ可能性がある。雇用統計・FOMCのような大型指標では、発表日全体をトレード禁止にする設計も十分現実的な選択肢だ。
停止時間の最適値はEAの戦略ロジックと通貨ペアによっても変わる。各パターンを実装した上で最適化・フォワードテストで検証してから数値を決めたい。
Claudeと会話しながらインジケータが作れるhedgrow-fxはこちら
3実装パターンの保守コスト・障害リスク比較
実装方式の選択はコードを書く段階だけの問題ではない。運用開始後の保守コストと障害発生リスクまで含めて評価するべきだ。3パターンを「初期実装コスト・保守コスト・障害発生率・障害影響度・復旧難易度」の5軸で比較する。
パターン1：CSV手動更新型
初期実装コストは最も低い。MQL4の基本的なファイルI/Oで実装できる。ただし毎週の手動更新が前提のため、運用が続くほど保守コストが積み上がる。更新忘れというヒューマンエラーが発生した場合、指標発表日にフィルターが機能しない状態になる。これは「サイレント障害」の典型で、EAは正常稼働しているように見えながら、実際は無防備な状態になっている。
障害発生率は低いが、発生時の影響度は高い。なぜなら「更新を忘れたタイミング」は高重要度指標が存在するタイミングであることが多く、その週に限ってフィルターが効かないというケースが起きやすいからだ。
パターン2：Webスクレイピング型（wininet.dll）
自動更新が実現できる分、保守コストは手動型より低い。しかしスクレイピング対象サイトのHTML構造が変わった瞬間に動作しなくなるという根本的なリスクがある。サイト側のリニューアルやclass名の変更が起きれば、即座に障害になる。
筆者がこの方式を採用したプロジェクトで実際に経験したのは、みんかぶFXのHTML構造変更によるパース処理の失敗だ。parseHtml() が空配列を返すようになり、指標データが取得できない状態が半日続いた。フォールバックロジック（CSVに切り替える処理）を組み込んでいたため実害はなかったが、フォールバックがない設計だったら全指標に対してフィルターなしで稼働していたことになる。
このパターンはサイト変更の監視コストが継続的に発生する。月1回程度の動作確認を運用ルールに含める必要がある。
パターン3：MT5内蔵カレンダーAPI型
3つの中で最も保守コストが低い。外部サービスへの依存がなく、MetaQuotesのサーバーデータを直接使用するため、HTML変更やCSV更新は不要だ。
ただし障害パターンが違う。MT5サーバーへの接続が切れた場合（VPSのネットワーク障害等）、APIが正常に動作しない状態になる。このときEAが「接続失敗＝指標なし」と解釈してトレードを継続すれば、フィルターが実質的に無効化されたまま稼働する。これを防ぐには「APIが失敗した場合はデフォルトで停止する」というフェイルセーフ設計が必要になる。
| 評価軸 | CSV手動型 | スクレイピング型 | MT5 API型 | |---|---|---|---| | 初期実装コスト | 低 | 高 | 中 | | 継続保守コスト | 高（毎週更新） | 中（サイト監視） | 低（ほぼ不要） | | 障害発生率 | 低 | 中〜高 | 低 | | 障害影響度 | 高（更新忘れで無防備） | 高（パース失敗で無防備） | 中（API失敗をフェイルセーフで吸収） | | MT4対応 | ○ | ○ | ✕（MQL5のみ） | | バックテスト対応 | ○（CSVがあれば可能） | △（難しい） | △（別途CSV実装が必要） |
この比較から導かれる推奨は以下になる。MT5環境であれば内蔵API型をベースにフェイルセーフとしてCSVフォールバックを組み合わせるハイブリッド設計が最も堅牢だ。MT4環境ではCSV型をベースにし、更新自動化が必要になった段階でスクレイピング型に移行するか、MT5への移行を検討するという判断が合理的だ。
指標ニュースフィルター付きEAの設計パターン
ニュースフィルターはOnTick冒頭で判定フラグを返す形で組み込み、UseNewsFilter パラメータで本番とバックテストを切り替える設計が標準的なパターンだ。
免責事項: 以下のコード例はEA設計の技術的解説を目的としており、実際の運用成績を保証するものではありません。実運用前に必ずデモ口座でテストし、リスク管理の設定を行ってください。
ここまで解説した3実装パターンを踏まえ、EA全体の設計として「ニュースフィルター」をどこに組み込むかを整理する。
OnTick内の制御フロー
void OnTick() {
// ── 1. ニュースフィルター判定 ──────────────────────────
if (UseNewsFilter && funcSihyouCheck()) {
// 停止期間中：新規エントリー禁止・既存ポジションはホールド
Comment("NEWS FILTER: Trading suspended");
return;
}
// ── 2. 通常ロジック ───────────────────────────────────
double sig = calcSignal();
if (sig > EntryThreshold) openBuy();
if (sig < -EntryThreshold) openSell();
manageExits();
}
UseNewsFilter パラメータをBoolで外出しすることで、バックテスト時にフィルターをオフにして素の成績を確認し、実運用時にオンにするという使い分けができる。
既存ポジションの扱い
停止期間に突入したとき、既存のオープンポジションをどう扱うかは設計上の判断が分かれるところだ。選択肢は3つある。
- ホールド: 停止期間中も保有継続。ストップロスのみで管理する
- 強制クローズ: 停止開始直前に全ポジションを決済する
- ストップ幅を拡大: 停止期間中だけロスカット幅を広げてスリッページに耐える
筆者の実装では、スキャルピング型には「強制クローズ」、トレンドフォロー型には「ホールド」を使い分けている。スキャルは保有時間が短いため決済しても機会損失が少ないが、トレンドフォローはポジションを切ると含み益を手放すことになるからだ。どちらが正しいかはEAの戦略次第で変わる。
MT4 FFCal連携型（MQL4の代替実装）
ForexFactoryのFFCalインジケーターを別途インストールし、iCustom() で値を参照する方式もある。
// FFCalインジから発表までの残り時間（分）を取得
double minsToNews = iCustom(NULL, 0, "FFCal", /*params*/ 0, 0, 0);
double minsSinceNews = iCustom(NULL, 0, "FFCal", /*params*/ 0, 1, 0);
bool isNewsWindow = (minsToNews < StopMinsBefore) ||
(minsSinceNews < StopMinsAfter);
FFCalは長年の実績があり、日本のMT4コミュニティでも導入事例が多い。ただしForexFactory側のカレンダーデータはリアルタイム接続が前提なので、VPS環境でのネットワーク制約には注意が必要だ。
Claudeと会話しながらインジケータが作れるhedgrow-fxはこちら
よくある質問（FAQ）
Q: バックテストでニュースフィルターを有効にする方法はありますか？
A: MT5の CalendarValueHistory() はリアルタイムサーバー接続が前提のため、バックテスト環境では動作しない可能性が高いです。バックテスト時は過去の指標スケジュールをCSVに保存し、IsTesting() で分岐してCSV読み込み型に切り替える実装が現実的な対応策になります。
Q: 「前後30分停止」と「前後60分停止」ではバックテスト成績はどう変わりますか？ A: 停止期間を延ばすと取引機会が減少するため、トレード回数が減り総利益が下がるケースが多いです。ただし損失の大きいアウトライヤー取引が除外されることでプロフィットファクターが改善する事例もあります。最適化グリッドで複数の値を検証することを推奨します。
Q: 日銀決定会合は発表時刻が不定なのに、どう停止設定すればよいですか？ A: 固定時刻での自動停止は難しいため、2つの方法が現実的です。（1）会合開催日の東京時間全体をトレード禁止にする、（2）FFCalやWebスクレイピング型でリアルタイム取得した時刻を使う。後者の方がトレード機会は守れますが実装コストが上がります。
Q: スプレッドが拡大しているだけなら、ロットを下げれば対応できないですか？ A: ロット減少はリスク管理として有効ですが、スプレッド拡大そのものは解消されません。スキャルピングEAのように利幅とスプレッドのバランスが成立を左右する戦略では、ロット調整で対応できない構造上の問題になります。停止とロット調整を組み合わせる設計が現実的です。
Q: MT4とMT5でニュースフィルターの実装は大きく違いますか？
A: 方針は同じですが、MT5では内蔵の CalendarValueHistory() が使えるため外部依存を減らせます。MT4はwininet.dll経由のスクレイピングかFFCal連携が主な選択肢です。MT5への移行を検討しているなら、ニュースフィルターの実装容易性は移行の一つのメリットになります。
Q: ナンピンEAは指標発表時にどれだけ危険ですか？ A: 理論上の最大リスクは「急騰・急落→ナンピン追加→さらに逆行」という連鎖です。ナンピン連鎖が発生すると損失が指数関数的に拡大するリスクがあり、大型指標の発表は特にトリガーになりやすい。ナンピンEAを運用する場合は、大型指標の発表日は朝から手動停止する運用ルールを設けることを強く推奨します。
Q: 経済指標フィルターを入れたEAは、EA販売プラットフォームでのフォワード成績に有利になりますか？ A: 直接的な保証はできませんが、指標発表時のアウトライヤー損失が排除されることでドローダウンの最大値が抑制される傾向があります。多くのEA販売・審査プラットフォームでは長期のフォワード成績と最大ドローダウンが重視されるため、フィルター実装によりプロフィールが改善する可能性はあります。
Q: ECN型とマーケットメーカー型ではニュースフィルターの停止時間を変えるべきですか？ A: 停止時間の最適値はブローカータイプによって異なります。ECN型はスプレッド拡大が短時間に集中する傾向があるため短い停止ウィンドウでも機能する場合があります。MM型はスプレッド拡大が長時間続くことがあるため、余裕を持った停止時間設定が推奨されます。まず利用ブローカーの指標時スプレッドを実測してから設定値を決めてください。
Q: ニュースフィルターの実装にAIツールは使えますか？ A: MQL4/MQL5のコード設計にAIを活用する事例は増えています。Claudeと会話しながらインジケータが作れるhedgrow-fxはこちら
免責事項: 本記事で紹介した実装例はFX取引における技術的手法の解説を目的としています。過去のバックテスト結果は将来の運用成績を保証するものではありません。FX取引には為替変動リスクがあり、投資元本を下回る損失が生じる可能性があります。本記事中の損失シミュレーションはあくまで仮定値に基づく概算であり、実際の損失を予測・保証するものではありません。実際の取引は自己判断・自己責任で行ってください。
著者: 肩書き: 運用歴: SNS / 連絡先:
