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でも使い回しが可能になります。

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安定
  • 再現性向上