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

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日に複数の取引セッションが存在する可能性があります。

例：

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

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は「最低限のフィルター」であり、単体では不十分です。

実務設計の基本

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

優先順位

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

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

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

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

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

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

4.1 手法比較（一覧）

【結論】
「精度」は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
• 危険時間か → ニュース
• 戦略に合う時間か → 固定時間

優先順位

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

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は以下の順序で設計するのが基本です。

優先順位

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

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が先です。

順序

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

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へ組み込み、テスターで検証することが重要です。

推奨アクション

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

評価指標

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

8.7 最終まとめ

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

一言でいうと

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

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