MQL5のsymbol-trading-hoursとは何ですか？

MQL5のsymbol-trading-hoursとは、銘柄ごとの取引可能時間を取得・判定するための仕組みです。主にSymbolInfoSessionTrade()を使って、ブローカーが定義した取引セッションを参照します。

MQL5でsymbol-trading-hoursはどうやって取得しますか？

MQL5ではSymbolInfoSessionTrade()を使って取得します。現在のサーバー時間をTimeCurrent()で取得し、曜日とセッション番号を指定して取引可能時間を判定するのが基本手順です。

MQL5でsymbol-trading-hoursを使う理由は何ですか？

理由は、市場クローズ時の注文エラーやスプレッド異常を避けるためです。取引時間を考慮しないEAは、executionの悪化やslippage拡大で成績が不安定になりやすくなります。

SymbolInfoSessionTrade()がfalseになる原因は何ですか？

主な原因は、その曜日に該当セッションが存在しないことです。土日や祝日、または指定したセッション番号が実際の数を超えている場合もfalseになります。

symbol-trading-hoursの判定でTimeLocal()ではなくTimeCurrent()を使うのはなぜですか？

取引時間の基準はローカル時間ではなくサーバー時間だからです。TimeLocal()を使うとブローカーの実際の取引時間とズレるため、TimeCurrent()を使う必要があります。

MQL5のsymbol-trading-hoursは固定時間フィルターと何が違いますか？

symbol-trading-hoursはブローカーが定義した実際の取引可能時間を使う点が違います。固定時間フィルターは実装が簡単ですが、銘柄差異やサマータイムには正確に対応できません。

MQL5でsymbol-trading-hoursを実装してもスプレッド異常は防げますか？

防げません。symbol-trading-hoursは取引可能かどうかを判定する仕組みであり、スプレッドやslippageの異常までは判定しないため、spreadフィルターとの併用が必要です。

MQL5のsymbol-trading-hoursはFX以外のCFDや指数でも使えますか？

使えます。むしろCFDや指数は取引時間が限定されることが多いため、symbol-trading-hoursの重要性はFXより高い場合があります。

MQL5 symbol-trading-hoursの使い方と取引時間判定の実装

1 1. MQL5 symbol-trading-hoursとは何か
2 2. MQL5でsymbol-trading-hoursを取得する方法（実装手順）
3 3. symbol-trading-hoursの仕組みと内部構造（Why）
4 4. symbol-trading-hoursと他手法の比較（vs 時間フィルター・ニュース制御）
5 5. よくある失敗・注意点（実務でハマるポイント）
6 6. 実務での使いどころ（戦略別の活用パターン）
7 7. FAQ（よくある質問）
8 8. まとめ（実務実装の最適解）

1. MQL5 symbol-trading-hoursとは何か

【結論】
MQL5のsymbol-trading-hoursとは、銘柄ごとの「実際に取引可能な時間帯」をプログラムから取得・判定するための仕組みです。EAの誤発注や市場クローズ時のエラー回避に必須です。

【定義】
symbol-trading-hoursとは、MQL5において銘柄（Symbol）の取引セッション（売買可能時間）を取得する機能であり、主にSymbolInfoSessionTrade()関数で取得します。

1.1 なぜ取引時間の取得が必要なのか

【結論】
取引時間を考慮しないEAは、市場クローズ時に注文エラー・スリッページ拡大・スプレッド異常を引き起こします。

【定義】
取引時間とは、ブローカーが定義する「注文が成立する時間帯（executionが有効な時間）」のことです。

MQL5で自動売買（EA）を開発する場合、「いつトレードするか」だけでなく、「いつトレードしないか」の制御が極めて重要です。

特に以下のような状況で問題が発生します：

市場クローズ中（週末・祝日）
セッション切り替え直後（流動性が低い）
ロールオーバー時間（スプレッド急拡大）
CFD・指数などの時間制限銘柄

これらを無視すると、以下のリスクが顕在化します：

TRADE_RETCODE_MARKET_CLOSED エラー
異常スプレッドによる不利なexecution
slippage（約定ずれ）の拡大
注文拒否や再試行ループ

1.2 symbol-trading-hoursの基本構造

【結論】
MQL5では、銘柄ごとの取引時間は「曜日 × セッション単位」で管理されています。

【定義】
セッションとは、1日の中で分割された取引可能時間帯（例：東京時間・ロンドン時間など）を指します。

MQL5の取引時間は以下の構造で管理されています：

曜日（0〜6：日曜〜土曜）
セッション番号（0〜複数）
開始時刻（from）
終了時刻（to）

つまり、単純な「1日＝1つの時間帯」ではなく、
1日に複数の取引セッションが存在する可能性があります。

例：

曜日	セッション	開始	終了
月曜	0	09:00	11:30
月曜	1	13:00	17:00

このような構造のため、単純な時間比較ではなく、
セッション単位での判定が必要になります。

1.3 使用する主要関数（概要）

【結論】
symbol-trading-hoursの取得には、SymbolInfoSessionTrade()を使用します。

【定義】
SymbolInfoSessionTrade()は、指定した銘柄・曜日・セッションの取引時間を取得する関数です。

基本的な関数シグネチャ：

bool SymbolInfoSessionTrade(
   string           symbol,       // 銘柄
   ENUM_DAY_OF_WEEK day_of_week,  // 曜日
   uint             session_index,// セッション番号
   datetime&        from,         // 開始時間
   datetime&        to            // 終了時間
);

この関数のポイント：

true：取得成功
false：セッションが存在しない
from / to：その日の取引可能時間

1.4 よくある誤解と失敗

【結論】
最も多い失敗は「時間固定で判定してしまうこと」です。銘柄ごとの取引時間は異なります。

初心者が陥りやすいミス：

固定時間（例：9:00〜17:00）で制御してしまう
サーバー時間とローカル時間を混同する
曜日ごとの違いを考慮しない
セッションが複数あることを無視する

特に重要なのは以下です：

FXとCFDで取引時間は異なる
ブローカーごとに仕様が異なる
祝日・例外時間は別管理されることがある

1.5 実務での使いどころ

【結論】
symbol-trading-hoursは「エントリー制御」と「リスク回避ロジック」に組み込みます。

主な活用例：

エントリー前チェック（市場オープン確認）
スプレッド異常回避（流動性低下時間の除外）
指標前後のトレード停止
ロールオーバー回避（スワップ時間帯）
execution品質の安定化

特に重要なのは：

OrderSend前に必ずチェックする
OnTickではなく関数化して再利用する
スプレッド・ボラティリティと組み合わせる

2. MQL5でsymbol-trading-hoursを取得する方法（実装手順）

【結論】
SymbolInfoSessionTrade()をループ処理で呼び出し、現在時刻が取引セッション内かを判定するのが基本実装です。

【定義】
取引時間判定とは、「現在のサーバー時間が、銘柄の取引可能セッション内に含まれるか」をチェックする処理です。

2.1 実装の全体手順（最短フロー）

【結論】
以下の4ステップで実装できます。これを関数化すればEA全体で再利用可能です。

手順

現在のサーバー時間を取得（TimeCurrent()）
曜日を取得（TimeDayOfWeek()）
セッションをループ取得（SymbolInfoSessionTrade()）
現在時刻が範囲内か判定

2.2 最小構成コード（コピペ可）

【結論】
以下の関数で「現在が取引時間内か」を判定できます。

bool IsTradingTime(string symbol)
{
   datetime now = TimeCurrent();
   int day = TimeDayOfWeek(now);

   datetime from, to;

   // セッション最大数は通常少数（0〜数個）
   for(int i = 0; i < 10; i++)
   {
      if(!SymbolInfoSessionTrade(symbol, (ENUM_DAY_OF_WEEK)day, i, from, to))
         break;

      // 時刻部分のみ比較
      datetime now_time = now % 86400;
      datetime from_time = from % 86400;
      datetime to_time = to % 86400;

      if(now_time >= from_time && now_time <= to_time)
         return true;
   }

   return false;
}

2.3 実装のポイント（重要）

【結論】
「日付ではなく時刻のみ比較する」ことが最重要ポイントです。

理由

SymbolInfoSessionTrade()で取得されるfromとtoは
日付を含まない時間ベースの値です。

そのため：

now % 86400

で「秒単位の時刻」に変換して比較する必要があります。

補足（86400とは）

1日 = 86400秒
% は剰余（余り）演算
→ 日付を除いた「時刻部分のみ取得」

2.4 EAへの組み込み例（OrderSend前チェック）

【結論】
注文前に必ずチェックすることで、エラーと損失を防げます。

if(!IsTradingTime(_Symbol))
{
   Print("市場クローズ中のためトレード停止");
   return;
}

// 通常のエントリー処理
OrderSend(request, result);

2.5 よくある失敗と対策

【結論】
時間判定のバグは「見えにくく、長期損失につながる」ため要注意です。

失敗①：ローカル時間を使う

TimeLocal(); // NG

→ サーバー時間とズレる
→ executionタイミングが狂う

対策

TimeCurrent(); // 必須

失敗②：セッションを1つしか見ない

SymbolInfoSessionTrade(..., 0, ...)

→ 複数セッションを見逃す

対策

for(int i=0; i<10; i++)

失敗③：日付込みで比較する

if(now >= from && now <= to) // NG

→ 判定が常にズレる

対策

now % 86400

失敗④：週末・祝日を考慮しない

土日はセッションなし
CFDは休場日あり

対策

セッションが1つも取得できなければfalse

2.6 実務向け拡張（精度を上げる）

【結論】
取引時間判定だけでなく、市場状態フィルターと組み合わせるのが実務レベルです。

推奨組み合わせ

スプレッド制限（SymbolInfoDouble(..., SYMBOL_SPREAD)）
ボラティリティフィルター（ATRなど）
スリッページ許容制御
execution条件チェック

例（簡易フィルター）

double spread = SymbolInfoInteger(_Symbol, SYMBOL_SPREAD);

if(spread > 30)
{
   Print("スプレッド異常のため停止");
   return;
}

2.7 補足：代替手段との違い（軽く比較）

【結論】
時間ベースの固定フィルターよりも、symbol-trading-hoursの方が正確です。

固定時間フィルター

メリット：実装が簡単
デメリット：ブローカー差異に対応不可

symbol-trading-hours

メリット：銘柄・ブローカー依存に対応
デメリット：実装がやや複雑

3. symbol-trading-hoursの仕組みと内部構造（Why）

【結論】
symbol-trading-hoursは「ブローカー側の取引セッション定義」を参照しており、EA側で時間を決めているのではなく、サーバー仕様に依存する設計です。

【定義】
取引セッションとは、ブローカーが銘柄ごとに設定している「注文受付・executionが有効な時間帯」のことです。

3.1 なぜ銘柄ごとに取引時間が異なるのか

【結論】
市場の性質（FX・株式・指数・CFD）によって、流動性・取引所・清算時間が異なるためです。

主な理由は以下です：

FX：基本24時間（ただしロールオーバーあり）
株式CFD：取引所時間に依存（例：NYSE、NASDAQ）
指数CFD：メンテナンス時間あり
コモディティ：特定時間帯のみ

つまり、「市場そのものの仕様」がそのまま反映されているため、
EA側で固定時間を設定するとズレが発生します。

実務的な重要ポイント

同じEURUSDでもブローカーごとに微妙に違う
XM / ICMarkets / Exness などで差異あり
サマータイム（DST）で時間がズレる

3.2 MQL5における時間の基準（重要）

【結論】
MQL5の時間は「サーバー時間」が基準であり、ローカル時間とは無関係です。

【定義】
サーバー時間とは、ブローカーのMT5サーバーが基準とする時間（通常はGMT+2や+3など）です。

主な時間関数の違い

TimeCurrent()：サーバー時間（最重要）
TimeLocal()：PCのローカル時間（使わない）
TimeTradeServer()：サーバー時間（ほぼ同義）

なぜサーバー時間を使うのか

execution（約定）はサーバー基準
スプレッド・価格更新もサーバー基準
ローカル時間はズレる可能性あり

よくある誤解

日本時間で判断してしまう
VPSのタイムゾーンに依存すると思っている

→ どちらも誤り

3.3 セッション構造の本質

【結論】
取引時間は「1つの連続時間」ではなく、「複数の分割セッション」で構成されます。

なぜ分割されるのか

メンテナンス時間（サーバー停止）
清算処理（ロールオーバー）
取引所の昼休み（株式系）

具体例

00:00〜23:55（FX）
23:55〜00:05（メンテナンス）

この場合：

セッション1：00:00〜23:55
セッション2：なし（空白時間あり）

実装への影響

「1日1セッション前提」は危険
必ずループで判定する必要あり

3.4 execution・spread・slippageとの関係

【結論】
取引時間外ではexecution品質が低下または停止し、スプレッドやスリッページが異常化します。

相関関係

取引時間外 → execution不可 or 拒否
セッション境界 → スプレッド拡大
流動性低下 → slippage増加

実務上の重要性

symbol-trading-hoursは単なる時間取得ではなく、
トレード品質のフィルターとして機能します。

3.5 なぜ固定時間フィルターではダメなのか

【結論】
固定時間では「ブローカー差異・銘柄差異・DST」に対応できないためです。

固定時間の問題点

夏時間でズレる
銘柄ごとの差異を無視
CFD・指数に対応不可

symbol-trading-hoursの優位性

ブローカー定義をそのまま使用
自動で時間調整（DST対応）
銘柄ごとの正確な制御が可能

3.6 よくある設計ミス（構造理解不足）

【結論】
構造を理解せずに実装すると、「動いているのに負けるEA」になります。

典型パターン

夜間に無駄なトレードをする
ロールオーバーで損失増加
スプレッド拡大時にエントリー

本質的な問題

時間ではなく「市場状態」を見ていない
execution条件を軽視している

3.7 実務での設計思想

【結論】
symbol-trading-hoursは「最低限のフィルター」であり、単体では不十分です。

実務設計の基本

① 取引時間チェック（必須）
② スプレッド制御
③ ボラティリティ制御
④ 戦略ロジック

優先順位

execution可能か
不利条件ではないか
エントリー条件成立

この順序を守らないと、
「正しいロジックでも負ける」状態になります。

4. symbol-trading-hoursと他手法の比較（vs 時間フィルター・ニュース制御）

【結論】
symbol-trading-hoursは「ブローカー定義ベースの正確な取引時間判定」であり、固定時間フィルターやニュースフィルターとは役割が異なります。単体ではなく併用が前提です。

【定義】
比較対象となる主な手法：

固定時間フィルター：指定した時刻で取引をON/OFF
ニュースフィルター：経済指標カレンダーに基づき停止
symbol-trading-hours：銘柄ごとの実取引可能時間を取得

4.1 手法比較（一覧）

【結論】
「精度」はsymbol-trading-hours、「柔軟性」は固定時間、「リスク回避」はニュースフィルターが強みです。

手法	精度	柔軟性	実装難易度	主な用途
symbol-trading-hours	◎	△	中	市場オープン判定
固定時間フィルター	△	◎	低	戦略時間制御
ニュースフィルター	○	○	高	指標リスク回避

4.2 symbol-trading-hoursの強みと弱み

【結論】
symbol-trading-hoursは「正確だが、それだけでは不十分」です。

強み

ブローカー仕様に完全準拠
銘柄ごとの差異に対応
DST（サマータイム）自動対応
execution可能状態を保証

弱み

指標（ニュース）までは考慮しない
スプレッド異常は検知しない
ロジックの優位性は保証しない

4.3 固定時間フィルターとの違い

【結論】
固定時間は「戦略都合」、symbol-trading-hoursは「市場都合」です。

固定時間の特徴

if(hour >= 9 && hour <= 17)

メリット：簡単・高速
デメリット：ズレる（ブローカー依存）

違いの本質

固定時間：EA側が時間を決める
symbol-trading-hours：市場が時間を決める

実務判断

短期戦略 → 固定時間も有効
安定重視 → symbol-trading-hours必須

4.4 ニュースフィルターとの違い

【結論】
ニュースフィルターは「価格変動リスク回避」、symbol-trading-hoursは「取引可能性の判定」です。

ニュースフィルターの役割

雇用統計・CPIなどの回避
ボラティリティ急変対策
スプレッド急拡大回避

限界

取引可能かは保証しない
ブローカーの仕様は考慮しない

4.5 実務での最適構成（重要）

【結論】
3つを組み合わせることで、リスクと機会のバランスが最適化されます。

推奨構成

if(!IsTradingTime(_Symbol)) return;

if(IsHighImpactNews()) return;

if(IsSpreadTooWide()) return;

// エントリー条件

この構成の意味

① execution可能か
② 異常環境でないか
③ 戦略成立

4.6 よくある誤った選択

【結論】
「どれか1つで十分」と考えるのは危険です。

NGパターン

固定時間のみ → 祝日・DSTで崩壊
ニュースのみ → 市場クローズ無視
symbol-trading-hoursのみ → スプレッド異常を拾う

4.7 判断基準（設計指針）

【結論】
目的に応じて役割分担するのが正解です。

判断フレーム

市場が開いているか → symbol-trading-hours
危険時間か → ニュース
戦略に合う時間か → 固定時間

優先順位

市場状態（必須）
リスク回避（重要）
戦略最適化（任意）

5. よくある失敗・注意点（実務でハマるポイント）

【結論】
symbol-trading-hoursの実装ミスは「エラーにならずに損失だけ増える」タイプが多く、見えない不具合として長期的にパフォーマンスを悪化させます。

【定義】
ここでの失敗とは、「コードは動くが、execution品質・収益性が悪化する設計ミス」を指します。

5.1 サーバー時間とローカル時間の混同

【結論】
TimeLocal()を使うと、実際の取引時間とズレて誤判定が発生します。

NG例

datetime now = TimeLocal(); // 誤り

正しい実装

datetime now = TimeCurrent(); // 正解

なぜ問題か

executionはサーバー基準
VPSのタイムゾーンは関係ない
数時間ズレるだけで「常に取引外判定」になる可能性あり

5.2 セッションを1つしか見ていない

【結論】
セッションは複数存在するため、1回の取得では不完全です。

NG例

SymbolInfoSessionTrade(symbol, day, 0, from, to);

正しい実装

for(int i=0; i<10; i++)

なぜ重要か

CFD・指数は分割セッションが多い
昼休み・メンテナンスで分断される
一部時間だけトレードできないケースあり

5.3 日付込みで比較してしまう

【結論】
そのまま比較すると、常に判定がズレます。

NG例

if(now >= from && now <= to)

正しい方法

now % 86400

理由

from/toは「時刻のみ」
nowは「日付＋時刻」
→ そのままでは一致しない

5.4 週末・祝日を考慮していない

【結論】
セッションが存在しない日は「必ずfalse」になります。

よくある現象

土日 → 全セッションなし
祝日 → 一部銘柄停止
CFD → 不定期休場あり

対策

if(!SymbolInfoSessionTrade(...))
   break;

→ セッション0すら取れない = 取引不可

5.5 スプレッド・流動性を無視している

【結論】
「取引可能＝安全」ではありません。スプレッドやslippageも同時に見る必要があります。

問題例

ロールオーバー直後にエントリー
スプレッド50ポイント以上
execution遅延

対策

double spread = SymbolInfoInteger(_Symbol, SYMBOL_SPREAD);

if(spread > 30)
   return;

なぜ重要か

取引時間内でも市場は不安定
流動性が低いと不利約定が発生

5.6 OrderSend直前にチェックしていない

【結論】
OnTickの最初ではなく、注文直前にチェックする必要があります。

NG設計

OnTick冒頭だけチェック
→ 数秒後に条件変化

正しい設計

// エントリー直前
if(!IsTradingTime(_Symbol)) return;

OrderSend(...);

理由

セッション境界で状態が変わる
数秒でexecution不可になることもある

5.7 例外ケース（DST・ブローカー差異）を無視

【結論】
ブローカーごとに仕様が異なるため、テスト前提で設計する必要があります。

典型例

夏時間で1時間ズレる
同一銘柄でも時間が違う
特定日だけ異常なセッション

対策

ストラテジーテスターで検証
ログ出力で確認

Print("from:", from, " to:", to);

5.8 実務でのチェックリスト（重要）

【結論】
以下を満たせば、致命的なミスはほぼ防げます。

チェック項目

TimeCurrent()を使用している
セッションをループ処理している
時刻のみで比較している
OrderSend直前でチェックしている
スプレッドフィルターを併用している
ブローカー差異をテスト済み

6. 実務での使いどころ（戦略別の活用パターン）

【結論】
symbol-trading-hoursは「全EAで必須の基礎フィルター」であり、特に短期売買・高頻度・スプレッド依存戦略で効果が最大化します。

【定義】
実務での使いどころとは、「どの戦略で、どのタイミングで、どのように組み込むべきか」という設計指針を指します。

6.1 スキャルピング（最重要）

【結論】
スキャルピングではsymbol-trading-hoursは必須です。未実装は期待値を大きく毀損します。

理由

数pipsの利益 → スプレッドの影響が大
流動性低下で即マイナス
execution遅延＝致命傷

推奨構成

if(!IsTradingTime(_Symbol)) return;

if(IsSpreadTooWide()) return;

if(!IsHighLiquidityTime()) return;

// エントリー

補足

ロンドン・NY時間に限定するケースが多い
東京時間はスキップする設計も一般的

6.2 デイトレード

【結論】
デイトレでは「時間帯の選別」に活用します。

活用方法

ボラティリティの高い時間帯のみ許可
ロールオーバー回避
指標前後の停止

例

if(!IsTradingTime(_Symbol)) return;

if(IsRollOverTime()) return;

ポイント

symbol-trading-hours単体では不十分
ニュースフィルター併用が前提

6.3 スイングトレード

【結論】
スイングでは重要度は下がるが、「エントリー精度改善」に有効です。

活用方法

不利な時間帯のエントリー回避
スプレッド異常時の除外

特徴

保有期間が長いため影響は限定的
ただしエントリー精度には影響

6.4 グリッド・ナンピン系

【結論】
最も重要な用途の1つ。無制御だとリスクが爆発します。

問題点

取引時間外でもポジション追加
スプレッド拡大時にエントリー
ロールオーバーで含み損拡大

推奨設計

if(!IsTradingTime(_Symbol)) return;

if(IsSpreadTooWide()) return;

if(IsVolatilityAbnormal()) return;

重要ポイント

エントリー頻度が高いため影響が大きい
フィルターの質＝生存率

6.5 ニュース回避型EA

【結論】
ニュースフィルターと組み合わせて「二重防御」にします。

構成

if(!IsTradingTime(_Symbol)) return;

if(IsHighImpactNews()) return;

意味

市場が閉じている → 取引不可
市場が荒れている → 取引回避

6.6 実務での優先順位（重要）

【結論】
すべてのEAは以下の順序で設計するのが基本です。

優先順位

取引可能か（symbol-trading-hours）
不利条件か（spread / slippage / volatility）
戦略条件成立か

NG設計

// 先にエントリー条件
if(Signal())
{
   OrderSend();
}

正しい設計

if(!IsTradingTime(_Symbol)) return;

if(IsSpreadTooWide()) return;

if(Signal())
{
   OrderSend();
}

6.7 実務での最適化ポイント

【結論】
symbol-trading-hoursは「単なるチェック」ではなく、戦略の一部として最適化します。

最適化例

時間帯ごとにロット変更
セッション別のロジック切替
execution品質でON/OFF

応用例

if(IsLondonSession())
   lot = 0.2;
else
   lot = 0.1;

6.8 まとめ（実務視点）

【結論】
symbol-trading-hoursは「入れておくべき機能」ではなく、EAの基盤となる設計要素です。

本質

時間ではなく「市場状態」を制御する
execution品質を担保する
無駄なトレードを削減する

7. FAQ（よくある質問）

【結論】
symbol-trading-hoursは「正しく使えばエラー回避と収益安定に直結」しますが、誤解も多いため要点を整理します。

【定義】
FAQでは、実務・実装で頻出する疑問に対し、短く再利用可能な回答を提示します。

7.1 symbol-trading-hoursは必須ですか？

【結論】
必須です。未実装でも動きますが、長期的にパフォーマンスが悪化します。

理由

市場クローズ時のエラー防止
スプレッド異常回避
execution品質の安定化

7.2 FXは24時間なので不要では？

【結論】
不要ではありません。FXでも「完全な24時間」ではありません。

補足

ロールオーバー時間あり
週末クローズあり
流動性の低い時間帯あり

7.3 固定時間フィルターだけで十分ですか？

【結論】
不十分です。ブローカー差異とDSTに対応できません。

違い

固定時間 → 手動定義
symbol-trading-hours → 自動取得

7.4 SymbolInfoSessionTradeがfalseになるのはなぜ？

【結論】
そのセッションが存在しないためです（正常動作）。

主な原因

セッション数を超えている
その曜日に取引時間がない
土日・祝日

7.5 なぜ%86400で比較するのですか？

【結論】
時刻のみを比較するためです。

理由

from/toは「時刻のみ」
nowは「日付＋時刻」
→ そのままでは比較不可

7.6 スプレッドフィルターとどちらが重要ですか？

【結論】
両方必要ですが、優先順位はsymbol-trading-hoursが先です。

順序

取引可能か（時間）
条件が良いか（スプレッド）

7.7 OnTickで毎回チェックする必要がありますか？

【結論】
最終的には「注文直前チェック」が必須です。

理由

状態はリアルタイムで変化
数秒で市場状態が変わる

7.8 バックテストでも必要ですか？

【結論】
必要です。テスターでも取引時間は再現されます。

補足

正しく実装しないと過剰トレードになる
実運用と乖離する

7.9 CFDや指数でも使えますか？

【結論】
必須レベルで重要です。

理由

取引時間が限定されている
セッション分割が多い

7.10 完全に安全になりますか？

【結論】
なりません。あくまで「最低限の安全装置」です。

必要な追加要素

スプレッド制御
slippage対策
ボラティリティ管理

8. まとめ（実務実装の最適解）

【結論】
MQL5のsymbol-trading-hoursは「単なる時間取得」ではなく、EAの収益性と安定性を左右する基盤ロジックです。必ず他のフィルターと組み合わせて運用します。

【定義】
最適解とは、「取引可能性・市場状態・戦略条件」を順序立てて評価する実務設計を指します。

8.1 最小構成（これだけは必須）

【結論】
以下の3点を満たせば、致命的なミスはほぼ回避できます。

必須構成

symbol-trading-hoursで取引可能判定
スプレッド制御（spread）
注文直前チェック

実装テンプレート

if(!IsTradingTime(_Symbol)) return;

double spread = SymbolInfoInteger(_Symbol, SYMBOL_SPREAD);
if(spread > 30) return;

// エントリー条件
if(Signal())
{
   OrderSend(request, result);
}

8.2 実務レベル構成（推奨）

【結論】
実運用では「多層フィルター」にすることで、期待値とドローダウンのバランスが改善します。

推奨構成

if(!IsTradingTime(_Symbol)) return;

if(IsHighImpactNews()) return;

if(IsSpreadTooWide()) return;

if(IsVolatilityAbnormal()) return;

if(Signal())
{
   OrderSend(request, result);
}

意味

① execution可能か
② 異常環境か
③ 優位性があるか

8.3 よくある誤解（再整理）

【結論】
「時間管理＝戦略」ではありません。あくまで前提条件です。

誤解

これを入れれば勝てる → 誤り
時間制御だけで十分 → 誤り

正しい理解

symbol-trading-hours → 土台
ロジック → 勝敗を決める

8.4 実務での最重要ポイント

【結論】
最も重要なのは「無駄なトレードを減らすこと」です。

本質

トレード回数を減らす
不利なexecutionを避ける
ノイズ相場を排除する

結果

ドローダウン低減
PF（プロフィットファクター）改善
再現性向上

8.5 設計のチェックリスト（最終確認）

【結論】
以下を満たしていれば、実務レベルの品質です。

チェック項目

SymbolInfoSessionTradeを正しく使用
セッションをループ処理
TimeCurrent()を使用
時刻のみで比較（%86400）
OrderSend直前チェック
スプレッド制御あり
ニュース・ボラティリティ考慮

8.6 次にやるべきこと（実務アクション）

【結論】
すぐに既存EAへ組み込み、テスターで検証することが重要です。

推奨アクション

IsTradingTime関数を実装
既存EAに組み込み
バックテスト比較（ON/OFF）
ドローダウンとPFを確認

評価指標

PF（プロフィットファクター）
DD（ドローダウン）
トレード回数
勝率

8.7 最終まとめ

【結論】
symbol-trading-hoursは、
「トレードするかどうか」の最初の意思決定ロジックです。

一言でいうと

entry条件より前に必ず通すフィルター
execution品質を守る防御層
EAの再現性を高める基盤

この設計をベースにすれば、
「動くだけのEA」から「実運用できるEA」へ進化します。

この記事を書いた人

佐川直弘

株式会社トリロジー取締役

株式会社トリロジー取締役日本国財務省近畿財務局長（金商）第372号登録業者 MetaTrader黎明期よりFX自動売買システムの開発に携わる、日本最古参世代のアルゴリズムトレーダーの一人。 2015年トレーデンシー大会世界1位（全世界6,000システム中） EA-1グランプリ第3回準優勝長年にわたり、EA設計・リスク管理・フォワード検証・VPS運用までを含めた実運用環境の構築を手がける。本サイトでは、MetaTraderおよびMQL言語に関する技術解説、安全設計思想、実装ノウハウを体系的に公開する。自動売買関連の発信は X（旧Twitter）にて #東京シストレのタグで行っている。