MQL5 trade-session-filterの使い方と実装手順

リファレンス
目次

1. MQL5 trade-session-filterとは

【結論】
mql5 trade-session-filterは「特定の時間帯のみトレードを許可する仕組み」であり、無駄なエントリーや不利な相場を避けて期待値を安定させるための基本フィルターです。

【定義】
trade-session-filterとは、取引時間（セッション）を条件にして、EA（自動売買）の注文実行（execution）を制御するロジックです。

1.1 なぜtrade-session-filterが必要か

【結論】
相場は時間帯ごとに性質（ボラティリティ・スプレッド）が異なるため、全時間でトレードすると期待値が悪化しやすいからです。

FX市場は24時間動いていますが、実際には以下のような特徴があります。

  • ロンドン時間：ボラティリティ（値動き）が大きい
  • ニューヨーク時間：トレンドが発生しやすい
  • 東京時間：レンジ（横ばい）になりやすい
  • 早朝・週明け：スプレッド（売買差）が広がりやすい

つまり、

  • 不利な時間帯 → spread拡大、slippage増加、execution悪化
  • 有利な時間帯 → 安定した約定、ロジック通りに動く

という構造があります。

そのため、時間帯を制御せずにEAを動かすと、

  • 無駄なトレードが増える
  • ドローダウン（損失幅）が拡大する
  • バックテストと実運用が乖離する

といった問題が発生します。

1.2 trade-session-filterでできること

【結論】
「いつトレードするか」ではなく「いつトレードしないか」を定義できる点が本質です。

主に以下の制御が可能です。

  • 特定時間帯のみエントリー許可
  • 指標前後のトレード停止
  • スプレッド異常時間の回避
  • 流動性の低い時間帯の排除

例：

  • 09:00〜17:00のみトレード
  • 22:00以降は停止
  • 月曜早朝はトレード禁止

このように、order条件の一部として時間を組み込むことで、

  • 無駄なシグナルを除外
  • execution品質の安定化
  • EA全体の期待値向上

が実現できます。

1.3 trade-session-filterの基本的な考え方

【結論】
「時間条件を満たしたときだけ注文処理を実行する」というシンプルな条件分岐で実装されます。

基本構造は以下です。

bool IsTradingTime()
{
   int hour = TimeHour(TimeCurrent());

   if(hour >= 9 && hour < 17)
      return true;

   return false;
}

そして、注文処理に組み込みます。

void OnTick()
{
   if(!IsTradingTime())
      return;

   // ここにエントリーロジック
}

この構造のポイント：

  • OnTickごとに時間をチェック
  • 条件外なら即return（処理停止）
  • 条件内のみexecution実行

1.4 よくある誤解と注意点

【結論】
「時間だけ制御すれば勝てる」という考えは誤りで、他のフィルター（spread・indicator）と組み合わせる必要があります。

よくある失敗：

  • 時間条件だけで最適化してしまう
  • ブローカー時間（サーバー時間）を無視する
  • 夏時間（DST）を考慮しない
  • バックテストと実運用で時間ズレが発生

特に重要なのは「時間の基準」です。

  • TimeCurrent() → サーバー時間
  • TimeLocal() → PCローカル時間

通常はサーバー時間を基準にしますが、ブローカーごとに異なるため注意が必要です。

1.5 他フィルターとの位置づけ（軽い比較）

【結論】
trade-session-filterは「時間軸のフィルター」であり、他のフィルターと役割が異なります。

代表的なフィルターとの違い：

  • spread filter → コスト制御
  • slippage filter → 約定品質制御
  • indicator filter → 相場状態の判定
  • session filter → 時間帯制御（今回）

つまり、

時間 × 相場状態 × コスト

を組み合わせて初めて、実務レベルのEAになります。

2. mql5 trade-session-filterの実装手順（How）

【結論】
mql5 trade-session-filterは「時間を取得 → 条件判定 → 条件外なら処理停止」という3ステップで実装できます。

【定義】
実装とは、EA内で時間条件（trade session）を判定し、注文（order execution）を制御するコードを書くことです。

2.1 実装の全体フロー

【結論】
実装は以下の3ステップに分解すると理解しやすく、再利用性も高くなります。

手順：

  1. 現在時間を取得する
  2. 許可する時間帯を定義する
  3. 条件外なら処理を停止する

この構造を関数化することで、他のEAでも使い回しが可能になります。

MQL5 trade session filter example showing how Expert Advisor controls order execution by allowed trading hours, with OnTick flow, IsTradingSession function, and trading chart highlighting active and blocked time ranges

2.2 現在時間の取得方法

【結論】
基本は「TimeCurrent()」を使い、サーバー時間を基準にするのが安全です。

datetime current = TimeCurrent();
int hour = TimeHour(current);
int minute = TimeMinute(current);

ポイント：

  • TimeCurrent() → ブローカーのサーバー時間
  • TimeLocal() → PCのローカル時間（非推奨）

注意点：

  • VPS環境ではローカル時間がズレることがある
  • ブローカーによってGMT+2 / GMT+3など差がある

2.3 時間帯フィルター関数の作成

【結論】
時間判定は関数化することで、EAの可読性と再利用性が向上します。

bool IsTradingSession()
{
   int hour = TimeHour(TimeCurrent());

   // 例：9時〜17時のみ許可
   if(hour >= 9 && hour < 17)
      return true;

   return false;
}

拡張例（分単位対応）：

bool IsTradingSession()
{
   datetime now = TimeCurrent();
   int hour = TimeHour(now);
   int minute = TimeMinute(now);

   int totalMinutes = hour * 60 + minute;

   // 9:30〜17:00
   if(totalMinutes >= (9 * 60 + 30) && totalMinutes < (17 * 60))
      return true;

   return false;
}

2.4 OnTickへの組み込み方法

【結論】
OnTickの最初にフィルターを入れることで、無駄な計算と注文処理を防げます。

void OnTick()
{
   // セッション外なら即終了
   if(!IsTradingSession())
      return;

   // スプレッドチェック（例）
   if(SymbolInfoInteger(_Symbol, SYMBOL_SPREAD) > 20)
      return;

   // エントリーロジック
}

ポイント：

  • 最初にフィルター → パフォーマンス向上
  • 他条件（spread, slippage）と併用可能
  • 無駄なindicator計算も削減できる

2.5 複数セッション対応（実務で重要）

【結論】
実務では「複数時間帯（例：ロンドン＋NY）」を許可するケースが多いです。

bool IsTradingSession()
{
   int hour = TimeHour(TimeCurrent());

   // ロンドン時間（例）
   bool london = (hour >= 16 && hour < 20);

   // ニューヨーク時間（例）
   bool ny = (hour >= 21 && hour < 24);

   return (london || ny);
}

応用：

  • セッションごとにロジックを変える
  • ボラティリティに応じてロット調整
  • 指標時間のみ停止

2.6 よくある実装ミスと対策

【結論】
時間フィルターは「時間基準」と「条件漏れ」が主なバグ原因です。

よくあるミス：

  • 0時跨ぎの条件ミス// NG例（23時〜2時） if(hour >= 23 && hour < 2)

対策：

if(hour >= 23 || hour < 2)

その他の注意点：

  • サーバー時間の確認不足
  • バックテスト時の時間ズレ
  • 夏時間（DST）未対応

DST対策（簡易）：

  • 時間を固定せず「相場状況」で補完
  • または外部パラメータ化

2.7 実務レベルの改善ポイント

【結論】
実務では「時間＋他条件」を組み合わせて初めて安定します。

推奨構成：

  • 時間フィルター（session）
  • スプレッド制御（spread）
  • 約定品質（slippage）
  • インジケータ判定（trend / range）

例：

if(!IsTradingSession()) return;
if(SymbolInfoInteger(_Symbol, SYMBOL_SPREAD) > 20) return;
if(!IsTrendCondition()) return;

この構造により：

  • 無駄なトレード削減
  • execution安定化
  • EAの再現性向上

3. trade-session-filterの仕組み（Why：なぜ有効か）

【結論】
trade-session-filterが有効な理由は「時間帯ごとに市場構造（流動性・ボラティリティ・コスト）が異なるため、期待値が変動するから」です。

【定義】
仕組みとは、時間帯によってトレードの勝率・損益比（リスクリワード）・execution品質が変化する市場の構造的要因を指します。

3.1 時間帯ごとの市場構造（ボラティリティと流動性）

【結論】
市場は時間帯によって「参加者の量と質」が変わり、それが値動き（ボラティリティ）と流動性を決定します。

主な特徴：

  • 東京時間：参加者が限定 → レンジ相場が多い
  • ロンドン時間：欧州勢参入 → 急激な値動き増加
  • ニューヨーク時間：最大流動性 → トレンド形成しやすい

この違いにより：

  • トレンド系ロジック → ロンドン・NYで有利
  • 逆張りロジック → 東京時間で有利

となります。

つまり、

「ロジックと時間帯が一致していないと期待値が崩れる」

これがtrade-session-filterの本質です。

3.2 スプレッドとexecution品質の変化

【結論】
時間帯によってスプレッド（取引コスト）と約定品質（execution）が大きく変化します。

典型例：

  • 早朝・週明け
    → spread拡大、slippage増加
  • 指標発表時
    → execution遅延、リクオート発生
  • 流動性の高い時間
    → スプレッド縮小、約定安定

この結果：

  • 同じロジックでも「時間によって損益が変わる」
  • バックテストと実運用の乖離が発生

したがって、

  • spreadが安定している時間のみトレード
  • slippageが少ない時間帯を選択

という制御が必要になります。

3.3 期待値（Expected Value）の観点

【結論】
trade-session-filterは「期待値の低いトレードを排除する装置」です。

期待値の基本構造：

  • 勝率 × 平均利益
  • − 負率 × 平均損失

時間帯によって：

  • 勝率が下がる
  • 損失が増える（slippage, spread）

つまり、

期待値がマイナスの時間帯が存在する

この時間帯を除外することで：

  • トレード回数は減る
  • しかし総利益は安定する

という効果が得られます。

3.4 バックテストと実運用のズレの原因

【結論】
時間フィルターを使わないと「テスト環境では勝てるが実運用で崩れる」原因になります。

主な理由：

  • テスターは理想的なexecutionを前提
  • 実環境ではスプレッド変動・遅延あり
  • 時間帯による影響が反映されない

特に問題になるケース：

  • 早朝エントリーが多いEA
  • 指標時間を無視しているロジック
  • 高頻度トレード（スキャルピング）

対策：

  • 時間フィルターでノイズを排除
  • 不安定な時間帯を除外
  • execution依存のリスクを低減

3.5 他フィルターとの役割分担（構造理解）

【結論】
trade-session-filterは「時間」、他フィルターは「状態」を制御するため、役割が明確に分かれています。

構造整理：

  • session filter → 時間の制御
  • spread filter → コストの制御
  • slippage filter → 約定品質
  • indicator filter → 相場状態

重要なポイント：

sessionだけでは不十分、複合的に使う必要がある

例えば：

  • 良い時間帯でもspreadが広い → トレードしない
  • 良い相場でも時間外 → トレードしない

このように多層フィルターにすることで：

  • 無駄なエントリー削減
  • リスク制御強化
  • EAの再現性向上

が実現できます。

3.6 よくある誤解（重要）

【結論】
「時間フィルター＝万能」という考えは誤りで、あくまで補助的なリスク管理手法です。

誤解例：

  • 時間を最適化すれば勝てる
  • セッションを絞れば利益が増える
  • すべてのEAに同じ時間帯が有効

実際は：

  • ロジック依存（トレンド型・逆張り型）
  • 通貨ペア依存（EURUSD, GBPJPYなど）
  • ブローカー依存（execution差）

したがって、

「ロジックに合った時間帯を選ぶ」ことが重要

4. trade-session-filterと他手法の比較（vs 他フィルター）

【結論】
trade-session-filterは「時間による制御」に特化したフィルターであり、spread・slippage・indicatorなどの他フィルターとは役割が根本的に異なります。

【定義】
比較対象は、EAの注文条件（order条件）を制御する各種フィルターであり、「何を基準にトレードを制御するか」という違いで分類されます。

4.1 フィルターの全体構造（分類）

【結論】
フィルターは「時間・コスト・約定・相場状態」の4カテゴリに分けて理解すると整理しやすいです。

分類：

  • 時間：trade-session-filter
  • コスト：spread filter
  • 約定品質：slippage filter
  • 相場状態：indicator filter（RSI・MAなど）

この4つを組み合わせることで、実務レベルのEAが構築されます。

4.2 フィルター比較（表構造）

【結論】
それぞれのフィルターは役割が重複しないため、「どれか1つ」ではなく「組み合わせ」が前提です。

フィルター種類 制御対象 主な目的 強み 弱み
trade-session-filter 時間帯 不利な時間の排除 シンプル・軽量 相場状態は見ない
spread filter スプレッド コスト削減 即時性が高い 時間要因は考慮しない
slippage filter 約定ズレ execution安定 実運用に強い テスターで再現困難
indicator filter 相場状態 エントリー精度向上 ロジックの中核 遅延・ダマシあり

重要ポイント：

trade-session-filterは「前提条件」、indicatorは「判断ロジック」

4.3 trade-session-filter vs spread filter

【結論】
sessionは「時間」、spreadは「コスト」を見ており、目的が異なります。

違い：

  • session → 不利な時間を排除
  • spread → 高コスト状態を排除

例：

  • ロンドン時間でもスプレッドが異常 → spread filterで除外
  • 深夜でもスプレッド正常 → session filterで除外

つまり：

同じ「トレード停止」でも理由が異なる

実務では両方必要です。

4.4 trade-session-filter vs indicator filter

【結論】
sessionは「外部条件」、indicatorは「内部ロジック」であり、役割が完全に分離されています。

違い：

  • session → トレードしてよい時間か
  • indicator → エントリーすべき相場か

例：

if(!IsTradingSession()) return;     // 時間条件
if(!IsTrendCondition()) return;     // 相場条件

この順序が重要：

  1. 時間でフィルター
  2. 相場で判断

理由：

  • 無駄なindicator計算を削減
  • パフォーマンス向上

4.5 trade-session-filter vs カレンダーフィルター（ニュース回避）

【結論】
sessionは「固定時間」、カレンダーは「イベントベース」で制御します。

違い：

  • session → 毎日同じ時間
  • カレンダー → 指標・ニュース時のみ

例：

  • 雇用統計 → カレンダーで回避
  • 毎日22時以降 → sessionで回避

実務では：

session + カレンダーの併用が標準

4.6 どのフィルターを優先すべきか

【結論】
優先順位は「時間 → コスト → 相場状態」の順で設計すると安定します。

推奨順：

  1. session（時間）
  2. spread / slippage（コスト・品質）
  3. indicator（相場判断）

理由：

  • 時間は最も粗いフィルター（大枠）
  • コストは即損益に影響
  • indicatorは最終判断

この順序により：

  • 無駄な計算削減
  • execution安定
  • 再現性向上

4.7 よくある設計ミス

【結論】
フィルターを単体で使う、または順序を誤るとパフォーマンスが悪化します。

典型的なミス：

  • indicatorだけで判断している
  • sessionを後段に置いている
  • spreadチェックをしていない

NG例：

if(IsTrendCondition())
{
   if(!IsTradingSession()) return;
}

問題：

  • 無駄な計算
  • ロジックの非効率

4.8 実務での最適構成（テンプレ）

【結論】
以下の構造が最も再現性と安定性が高い基本形です。

if(!IsTradingSession()) return;                 // 時間
if(SymbolInfoInteger(_Symbol, SYMBOL_SPREAD) > 20) return; // コスト
if(!IsTrendCondition()) return;                 // 相場

この構成により：

  • 無駄なトレード削減
  • execution品質向上
  • ドローダウン抑制

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

【結論】
trade-session-filterの失敗は「時間基準のズレ」「条件設計ミス」「環境差の未考慮」に集中します。ここを外すとバックテストと実運用が乖離します。

【定義】
失敗とは、意図した時間制御が機能せず、不要なトレードや想定外の停止が発生する状態です。

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

【結論】
TimeCurrent()（サーバー時間）を基準にしないと、VPSやPC環境で時間がズレます。

よくあるミス：

  • TimeLocal()を使用している
  • PCのタイムゾーン変更で挙動が変わる

対策：

datetime now = TimeCurrent(); // 常にこれを使う

補足：

  • ブローカーごとにGMTオフセットが異なる（例：GMT+2 / GMT+3）
  • ロンドン・NY時間と一致させたい場合はオフセット補正が必要

5.2 0時跨ぎ（深夜帯）の条件ミス

【結論】
「23時〜2時」のような条件はANDではなくORで書く必要があります。

NG例：

if(hour >= 23 && hour < 2) // 常にfalse

正しい例：

if(hour >= 23 || hour < 2)

理由：

  • 1日の境界（0時）を跨ぐため
  • 単純な範囲条件では表現できない

5.3 夏時間（DST）未対応

【結論】
DST（サマータイム）を考慮しないと、特定期間だけトレード時間がズレます。

問題例：

  • ロンドン時間に合わせたつもりが1時間ズレる
  • バックテストと実運用で結果が変わる

対策：

  • 入力パラメータで時間を調整可能にする
  • またはGMT基準で変換する

例：

input int StartHour = 9;
input int EndHour = 17;

これにより：

  • 手動で調整可能
  • ブローカー差にも対応

5.4 バックテストと実運用のズレ

【結論】
テスターと実環境ではexecution条件（slippage・spread）が異なるため、時間フィルターの効果も変わります。

主なズレ要因：

  • テスターはスプレッド固定が多い
  • slippageが再現されない
  • 約定遅延がない

結果：

  • テストでは有効でも実運用で崩れる

対策：

  • スプレッドフィルターと併用
  • テスト時も可変スプレッドを使用
  • 時間帯ごとのログを確認

5.5 フィルターの過剰最適化（オーバーフィッティング）

【結論】
時間帯を細かく最適化しすぎると、将来の相場で再現性が失われます。

典型例：

  • 「10:15〜11:20のみ」など細分化
  • 過去データに過剰適合

問題：

  • 汎用性がなくなる
  • フォワードで崩壊

対策：

  • セッション単位（数時間）で設計
  • シンプルな時間帯に限定

5.6 ロジックとの不整合

【結論】
時間帯とロジックが一致していないと、フィルターが逆効果になります。

例：

  • トレンド戦略なのに東京時間のみ
  • 逆張りなのにロンドン時間中心

結果：

  • 勝率低下
  • ドローダウン増加

対策：

  • ロジック特性を明確化
  • 時間帯ごとのパフォーマンスを検証

5.7 フィルターの順序ミス

【結論】
時間フィルターは最初に適用しないと、無駄な計算と誤動作の原因になります。

NG例：

if(IsTrendCondition())
{
   if(!IsTradingSession()) return;
}

問題：

  • 無駄なindicator計算
  • パフォーマンス低下

正しい構造：

if(!IsTradingSession()) return;
if(!IsTrendCondition()) return;

5.8 実務チェックリスト

【結論】
以下を満たしていれば、実務レベルで安定した動作になります。

チェック項目：

  • TimeCurrent()を使用している
  • 0時跨ぎ条件が正しい
  • DST対応または調整可能
  • スプレッドフィルターと併用
  • ロジックと時間帯が一致
  • 過剰最適化していない

6. 実務での使いどころ（戦略別の活用方法）

【結論】
trade-session-filterは「戦略タイプごとに最適な時間帯を選ぶ」ことで効果を最大化できます。特にトレンド型・逆張り型・スキャルピングで使い方が異なります。

【定義】
使いどころとは、各トレード戦略（ロジック特性）に対して、最も期待値が高くなる時間帯（trade session）を選択・制御することです。

6.1 トレンドフォロー戦略での使い方

【結論】
トレンドフォローは「ロンドン〜ニューヨーク時間」に限定するのが基本です。

理由：

  • 流動性が高い
  • 大きなトレンドが発生しやすい
  • executionが安定

推奨時間帯（例）：

  • 16:00〜24:00（ブローカー時間依存）

実装例：

bool IsTrendSession()
{
   int hour = TimeHour(TimeCurrent());
   return (hour >= 16 && hour < 24);
}

補足：

  • ブレイクアウト系（高値更新）はこの時間帯と相性が良い
  • 東京時間ではダマシ（フェイクブレイク）が増える

6.2 逆張り（レンジ）戦略での使い方

【結論】
逆張りは「東京時間」などの低ボラティリティ時間帯で有効です。

理由：

  • レンジ相場になりやすい
  • 急激なトレンドが出にくい

推奨時間帯：

  • 08:00〜15:00

実装例：

bool IsRangeSession()
{
   int hour = TimeHour(TimeCurrent());
   return (hour >= 8 && hour < 15);
}

注意点：

  • 指標前後は除外する（カレンダーフィルター併用）
  • スプレッド拡大時はエントリー禁止

6.3 スキャルピング戦略での使い方

【結論】
スキャルピングは「スプレッドが最も狭い時間帯」に限定する必要があります。

理由：

  • 小さな利益幅のためコスト影響が大きい
  • slippageの影響を強く受ける

推奨条件：

  • ロンドンオープン直後
  • NYオープン直後
  • spreadが安定している時間

実装例（組み合わせ）：

if(!IsTradingSession()) return;
if(SymbolInfoInteger(_Symbol, SYMBOL_SPREAD) > 15) return;

ポイント：

  • session単体では不十分
  • spread filterとの併用が必須

6.4 指標回避（ニュースフィルター）との併用

【結論】
trade-session-filterだけでは指標リスクを回避できないため、ニュースフィルターと併用します。

例：

  • 雇用統計（NFP）
  • FOMC
  • CPI

対策：

  • 指標時間の前後でトレード停止
  • カレンダーAPIを使用

構造：

if(!IsTradingSession()) return;
if(IsNewsTime()) return;

これにより：

  • 急激なslippage回避
  • 異常なexecution防止

6.5 通貨ペア別の最適セッション

【結論】
通貨ペアごとに活発な時間帯が異なるため、セッションを最適化する必要があります。

例：

  • EURUSD → ロンドン・NY
  • GBPJPY → ロンドン時間が強い
  • USDJPY → 東京時間でも動く

ポイント：

  • 通貨の本国市場に合わせる
  • 流動性が高い時間を優先

6.6 実務テンプレート（汎用設計）

【結論】
以下のテンプレート構造にすると、ほぼすべてのEAに適用可能です。

if(!IsTradingSession()) return;                      // 時間
if(SymbolInfoInteger(_Symbol, SYMBOL_SPREAD) > 20) return; // コスト
if(IsNewsTime()) return;                             // 指標回避
if(!IsTradeSignal()) return;                         // ロジック

この構造のメリット：

  • フィルターの役割が明確
  • 再現性が高い
  • 拡張しやすい

6.7 実務での判断基準（重要）

【結論】
時間帯は「バックテスト結果」ではなく「市場構造」で決めるのが安定します。

判断軸：

  • 流動性（volume）
  • スプレッド（cost）
  • ボラティリティ（range）

NGパターン：

  • 過去データだけで最適化
  • 細かすぎる時間設定

推奨：

シンプルなセッション + 他フィルター併用

7. よくある質問（FAQ）

【結論】
trade-session-filterはシンプルな仕組みですが、「時間基準」「他フィルターとの関係」「実運用との差」で迷うケースが多いです。

【定義】
FAQでは、実装・運用時に発生しやすい疑問に対して、短く明確に回答します。

7.1 mql5 trade-session-filterは必須ですか？

【結論】
必須ではありませんが、実務レベルではほぼ必須です。

理由：

  • 不利な時間帯を排除できる
  • スプレッドやexecutionの悪化を回避できる
  • EAの安定性（再現性）が向上する

7.2 TimeCurrent()とTimeLocal()はどちらを使うべき？

【結論】
TimeCurrent()（サーバー時間）を使うのが基本です。

理由：

  • ブローカー基準でトレードされるため
  • VPS・PC環境に依存しない

7.3 どの時間帯を選べばいいですか？

【結論】
戦略（トレンド・逆張り）と通貨ペアに依存します。

目安：

  • トレンド → ロンドン・NY時間
  • 逆張り → 東京時間
  • スキャル → スプレッドが安定している時間

7.4 0時跨ぎの条件がうまく動きません

【結論】
OR条件を使う必要があります。

例：

if(hour >= 23 || hour < 2)

理由：

  • 1日の境界を跨ぐため
  • AND条件では成立しない

7.5 trade-session-filterだけで十分ですか？

【結論】
不十分です。他フィルターとの併用が必要です。

併用例：

  • spread filter → コスト制御
  • slippage filter → 約定品質
  • indicator → 相場判断

7.6 バックテストと結果が違うのはなぜ？

【結論】
execution（約定条件）とスプレッドの違いが原因です。

主な理由：

  • テスターは理想環境
  • 実運用はslippage・遅延あり

対策：

  • スプレッドフィルター併用
  • 時間帯の見直し

7.7 夏時間（DST）は対応すべきですか？

【結論】
対応した方が安定します。

理由：

  • 時間が1時間ズレるため
  • セッションが意図と異なる可能性

簡易対策：

  • inputパラメータで調整可能にする

7.8 最適な実装構造は？

【結論】
「時間 → コスト → ロジック」の順でフィルターを適用します。

if(!IsTradingSession()) return;
if(SymbolInfoInteger(_Symbol, SYMBOL_SPREAD) > 20) return;
if(!IsTradeSignal()) return;

理由：

  • 無駄な処理を削減
  • execution安定
  • 再現性向上