MQL5マルチタイムフレームEAの作り方と実装手順

1. MQL5 マルチタイムフレームEAとは

【結論】
マルチタイムフレームEAとは、複数の時間足データを同時に参照して売買判断を行うことで、精度と再現性を高める手法です。
単一時間足よりも「環境認識」と「実行」を分離できる点が本質です。

1.1 定義と基本概念

【定義】
MQL5のマルチタイムフレームEAとは、異なる時間足（例：M5・H1・D1）を組み合わせてトレード判断を行う自動売買プログラムです。

通常のEAは1つの時間足（例：M5のみ）で判断しますが、MTF（Multi Timeframe）では以下のように役割を分けます。

• 上位足（H1・D1など）：トレンド・方向性の判断
• 下位足（M5・M15など）：エントリータイミングの決定

重要なポイントは、「時間足ごとに役割を分離する」ことです。
これにより、ノイズの多い低時間足だけに依存するリスクを減らせます。

1.2 単一時間足との違い

【結論】
単一時間足はシンプルだがノイズに弱く、MTFは複雑だが精度が高い傾向があります。

単一時間足EAの特徴：

• 実装が簡単（処理が軽い）
• トレード回数が多い
• ノイズ（ダマシ）に弱い

マルチタイムフレームEAの特徴：

• トレンド方向と一致したエントリーが可能
• 不要なトレードを減らせる
• 実装がやや複雑（データ管理が必要）

例えば、以下のような構造になります。

• H1で上昇トレンド確認
• M5で押し目を検出
• 条件一致時のみOrderSendでエントリー

この構造により、「逆張りの誤発注」や「無駄なexecution」を減らすことができます。

1.3 具体的に何ができるのか

【結論】
MTFを使うと、「環境認識」「フィルタリング」「エントリー精度向上」の3つが実現できます。

主な用途は以下です。

• トレンドフィルター
  • 上位足の移動平均（MA）で方向判定
• ボラティリティ判定
  • ATRなどで市場の動きの強さを判断
• エントリー最適化
  • 下位足で精密なタイミングを取る

具体例（ロジック）：

• H1のMAが上向き → 買いのみ許可
• M5でRSIが30以下 → 押し目と判断
• 条件成立 → 注文実行

このように、「条件を絞る」ことで期待値を改善します。

1.4 関連キーワードと実務上の重要概念

【結論】
MTFは単なる時間足の組み合わせではなく、execution品質やコスト要因とセットで考える必要があります。

実務で重要な関連概念：

• spread（スプレッド）
  → 広いとエントリー精度が悪化
• slippage（スリッページ）
  → 約定ズレによりロジックが崩れる
• execution（約定品質）
  → VPSやブローカー依存
• order条件
  → 発注ロジックの再現性に直結

特にMTFは「フィルターが多い＝トレード回数が少ない」ため、
1回のトレードの質（execution品質）が重要になります。

1.5 初心者がつまずきやすいポイント

【結論】
MTFは概念は簡単でも、データの扱いを誤ると簡単にロジックが破綻します。

よくある失敗：

• 異なる時間足のデータをそのまま比較する
• バー未確定状態でシグナルを出す
• CopyBufferやCopyRatesの使い方を誤る
• インデックス（配列）のズレを無視する

なぜ起こるか：

• MQL5では時間足ごとにデータ配列が独立しているため
• 時間同期を意識しないと「別の時間のデータ」を参照する可能性があるため

回避の基本：

• ArraySetAsSeriesで配列方向を統一
• バー確定を必ず確認
• 同一インデックスの意味を理解する

2. なぜマルチタイムフレームが必要なのか

【結論】
マルチタイムフレームは、トレンド方向とエントリー方向を一致させることで、無駄なトレードを減らし期待値を改善するために必要です。
単一時間足では「ノイズ」と「方向のズレ」を避けられません。

2.1 単一時間足EAの問題点

【結論】
単一時間足EAはノイズの影響を強く受けるため、勝率低下とドローダウン増加を招きやすい構造です。

低時間足（M1〜M15）では、以下の問題が発生します。

• ノイズ（ランダムな値動き）が多い
• トレンドと逆方向のシグナルが頻発
• ダマシによる損切りが増加

例：

• M5で買いシグナル発生
• しかしH1では下降トレンド
• → 結果：逆行して損切り

このように、時間足単体では市場全体の文脈（コンテキスト）を捉えられないのが根本原因です。

2.2 マルチタイムフレームの基本構造

【結論】
MTFは「上位足＝環境認識」「下位足＝実行」という役割分担で構成されます。

基本構造：

• 上位足（H1・D1）
  → トレンド方向・市場環境の判定
• 下位足（M5・M15）
  → エントリータイミングの最適化

この構造により、以下が実現します。

• トレンドに沿ったトレードのみ実行
• 不利な局面（レンジ・逆張り）を回避
• executionの無駄を削減

重要な考え方：

• 上位足は「フィルター」
• 下位足は「トリガー」

この分離が、MTFの本質です。

2.3 期待値が改善する理由

【結論】
MTFは「勝率向上」と「損失削減」の両方に作用し、結果として期待値（Expected Value）を改善します。

期待値の構造：

• 期待値 ＝ 勝率 × 利益 − 負率 × 損失

MTFによる変化：

• 勝率：上昇（トレンド一致）
• 負率：低下（逆行エントリー減少）
• 損失：減少（無駄な損切り削減）

具体的な改善メカニズム：

• フィルタリング効果
  → 条件に合わないトレードを排除
• 精度向上
  → エントリー位置が改善
• DD抑制
  → 不利な局面を回避

結果として、PF（プロフィットファクター）とDD（ドローダウン）のバランスが改善されます。

2.4 トレード回数とのトレードオフ

【結論】
MTFは精度が上がる代わりにトレード回数が減少するため、設計バランスが重要です。

一般的な変化：

• トレード回数：減少
• 精度：上昇
• 1トレードの重要度：増加

注意点：

• フィルターを増やしすぎると「機会損失」になる
• 条件が厳しすぎるとバックテストでは良くても実運用で機能しない可能性

設計の目安：

• 「無駄を削る」ことが目的
• 「トレードを減らす」ことが目的ではない

2.5 他手法との違い（軽い比較）

【結論】
MTFは「構造的に精度を上げる手法」であり、単なるインジケータ追加とは異なります。

比較：

• 単一時間足＋インジケータ増加
  → ノイズに対する対症療法
• マルチタイムフレーム
  → 市場構造を利用した本質的改善

つまり、MTFは「情報の質」を上げるアプローチです。

2.6 実務視点での重要性

【結論】
実運用では、MTFは「不要なトレードをしないための仕組み」として機能します。

特に重要な場面：

• スプレッド拡大時（spread widening）
• 指標発表前後
• ボラティリティ異常時

MTFを使うことで：

• 無理なエントリーを防止
• executionの質を維持
• 不要なslippageの影響を回避

これは、EAの長期安定性に直結する要素です。

3. MQL5での実装方法

【結論】
マルチタイムフレームEAは、上位足データを取得→トレンド判定→下位足でエントリー判断→注文実行という流れで実装します。
重要なのは「データ取得」と「時間足のズレ管理」です。

3.1 基本実装フロー

【結論】
実装は5ステップで構成され、順序を守ることで再現性が担保されます。

手順：

• ① 上位時間足を定義する
• ② 上位足データを取得する
• ③ トレンド（方向）を判定する
• ④ 現在足でエントリー条件を確認する
• ⑤ 注文を実行する（OrderSend）

コード例（基本構造）：

// 上位足設定
ENUM_TIMEFRAMES higher_tf = PERIOD_H1;

// MA取得用ハンドル
int ma_handle = iMA(_Symbol, higher_tf, 50, 0, MODE_SMA, PRICE_CLOSE);

// バッファ取得
double ma_buffer[];
CopyBuffer(ma_handle, 0, 0, 2, ma_buffer);

// トレンド判定
bool uptrend = ma_buffer[0] > ma_buffer[1];

// エントリー条件（現在足）
if(uptrend)
{
    // 買い条件成立時に注文
    MqlTradeRequest request;
    MqlTradeResult result;
    
    ZeroMemory(request);
    
    request.action = TRADE_ACTION_DEAL;
    request.symbol = _Symbol;
    request.volume = 0.1;
    request.type = ORDER_TYPE_BUY;
    request.price = SymbolInfoDouble(_Symbol, SYMBOL_ASK);
    
    OrderSend(request, result);
}

ポイント：

• 上位足の情報で方向を決める
• 下位足でタイミングを取る
• OrderSendは条件成立時のみ実行

3.2 上位足データ取得の方法

【結論】
データ取得は「価格データ」と「インジケータデータ」で方法が異なります。

主な方法：

① 価格データ（ローソク足）

MqlRates rates[];
CopyRates(_Symbol, PERIOD_H1, 0, 10, rates);

用途：

• 高値・安値・終値の取得
• ローソク足パターン分析

② インジケータ（MA・RSIなど）

int handle = iRSI(_Symbol, PERIOD_H1, 14, PRICE_CLOSE);

double buffer[];
CopyBuffer(handle, 0, 0, 2, buffer);

用途：

• トレンド判定
• オシレーター判断

③ カスタムインジケータ

int handle = iCustom(_Symbol, PERIOD_H1, "CustomIndicator");

用途：

• 独自ロジックの利用

選び方：

• シンプルなロジック → CopyRates
• 指標ベース → CopyBuffer
• 独自ロジック → iCustom

3.3 時間足ズレを防ぐための重要処理

【結論】
MTFで最も重要なのは「時間同期」と「配列方向の統一」です。

配列方向の統一

ArraySetAsSeries(ma_buffer, true);

理由：

• 最新データを index 0 にするため
• 他の配列と整合性を取るため

バー確定の判定

static datetime last_time = 0;
datetime current_time = iTime(_Symbol, PERIOD_H1, 0);

if(current_time != last_time)
{
    last_time = current_time;
    // 新しいバー確定
}

理由：

• 未確定足の誤判定を防ぐ
• ダマシシグナルを回避

データ不足チェック

if(CopyBuffer(handle, 0, 0, 2, buffer) < 2)
{
    return;
}

理由：

• 初期化直後のデータ不足対策
• エラー回避

3.4 実装時の重要ポイント

【結論】
MTF実装では「正確さ」と「安定性」を優先しないと、バックテストと実運用が乖離します。

重要ポイント：

• OnTick依存の注意
  → ティックが来ないと処理されない
• executionのタイミング
  → spread拡大時は回避すべき
• slippage対策
  → 許容スリッページ設定
• ロット管理
  → 過剰リスク防止

例（スプレッドチェック）：

double spread = (SymbolInfoDouble(_Symbol, SYMBOL_ASK) - 
                 SymbolInfoDouble(_Symbol, SYMBOL_BID)) / _Point;

if(spread > 20)
{
    return; // スプレッドが広いのでエントリー回避
}

3.5 よくある失敗と対策

【結論】
MTFの失敗はほぼ「データの扱いミス」で発生します。

よくある失敗：

• CopyBufferの戻り値を確認しない
• 異なる時間足のデータを直接比較
• 未確定バーを使う
• インデックスズレ

対策まとめ：

• 必ずバー確定を確認
• 配列方向を統一
• データ取得結果をチェック
• 同一時間基準で比較する

3.6 最小構成の考え方（初心者向け）

【結論】
最初は「上位足1つ＋下位足1つ」のシンプル構成から始めるべきです。

推奨構成：

• H1：トレンド判定（MA）
• M5：エントリー（RSIなど）

理由：

• デバッグが容易
• ロジックの因果が明確
• 過剰最適化を防止

4. よくある失敗と注意点

【結論】
マルチタイムフレームEAで多い失敗は、ロジックそのものよりも時間足データの扱いミス、未確定バーの誤使用、過剰条件化です。
実装難易度よりも、整合性管理の甘さが成績悪化の主因になりやすいです。

4.1 未確定バーで判定してしまう

【結論】
未確定バーを使うと、バックテストや目視では良く見えても、実運用ではシグナルが消えることがあります。

これはMTFで特に起こりやすい失敗です。
たとえばH1の移動平均やRSIを参照するとき、まだH1バーが確定していない状態で値を使うと、次のティックで値が変わる可能性があります。すると、エントリー時点では条件成立に見えても、バー確定後には条件不成立になることがあります。

よくある失敗例：

• 上位足のindex 0をそのまま売買判断に使う
• 新バー判定を入れず、毎ティックで上位足条件を評価する
• テスターでは見えにくい「途中経過の値」を前提にしてしまう

対策は明確です。

• 上位足の判定は原則として確定バーを使う
• 必要ならindex 1を使う
• iTime()で新バー発生を確認してから更新する

コード例：

datetime current_h1_time = iTime(_Symbol, PERIOD_H1, 0);
static datetime last_h1_time = 0;

if(current_h1_time != last_h1_time)
{
    last_h1_time = current_h1_time;
    // ここで上位足シグナルを更新
}

なぜそうするかというと、EAは再現性が重要であり、途中で変わる値を基準にすると検証可能性が下がるためです。

4.2 配列インデックスと時間足のズレを軽視する

【結論】
MTFでは、同じindex 0でも同じ時刻を意味するとは限りません。
ここを誤ると、別時間のデータ同士を比較する壊れたEAになります。

MQL5では、M5とH1は別の時系列です。
そのため、M5のclose[0]とH1のbuffer[0]をそのまま比較しても、両者が同じ時点を表している保証はありません。

ありがちな誤実装：

• 下位足の最新バーと上位足の最新バーを直接比較
• CopyRatesやCopyBufferの取得順を理解せず使う
• ArraySetAsSeries(true)を忘れる

最低限やるべきこと：

• 配列方向を統一する
• 上位足は「方向判定用」、下位足は「実行用」と役割を分ける
• 時刻を使って整合性を確認する

コード例：

double ma_buffer[];
ArraySetAsSeries(ma_buffer, true);

if(CopyBuffer(ma_handle, 0, 0, 3, ma_buffer) < 3)
{
    return;
}

注意点として、ArraySetAsSeriesを入れても「時間足間の意味のズレ」自体は自動解決されません。
これは配列の向きを揃える処理であり、時刻対応までは面倒を見ません。

4.3 条件を増やしすぎてトレードできなくなる

【結論】
MTFは有効なフィルターですが、条件を積みすぎると期待値改善ではなく、単なる取引停止装置になります。

初心者ほどやりがちな流れは次のとおりです。

• H1でMA上向き
• H4でもMA上向き
• M15でRSI条件
• ATR条件
• spread制限
• slippage制限
• 時間帯フィルター
• 曜日フィルター

ここまで重ねると、理屈上は綺麗でも、実際にはほとんど約定しません。
トレード回数が減りすぎると、PFや勝率の統計的信頼性も落ちます。

判断基準は単純です。

• 条件追加の目的が明確か
• その条件で何の損失を減らしたいのか説明できるか
• 追加後にサンプル数が極端に減っていないか

代替手段として、条件を増やすよりも「上位足の役割を1つに限定する」ほうが安定しやすいです。
たとえば、H1はトレンド判定だけ、M5はエントリーだけ、という設計です。

4.4 executionコストを無視する

【結論】
MTFでシグナル精度を上げても、spread・slippage・約定遅延を無視すると実運用成績は崩れます。

これは、特に低時間足側でエントリーする場合に重要です。
たとえばM5で絶妙な押し目を狙っても、スプレッドが広がっていれば、実際の約定価格は想定より悪くなります。さらにslippageが大きいと、テスト上の優位性がそのまま失われます。

最低限チェックしたい項目：

• 現在のspread
• 取引時間帯
• 指標発表前後
• ブローカーのexecution特性

コード例：

double ask = SymbolInfoDouble(_Symbol, SYMBOL_ASK);
double bid = SymbolInfoDouble(_Symbol, SYMBOL_BID);
double spread = (ask - bid) / _Point;

if(spread > 20)
{
    return;
}

なぜ必要かというと、MTFはトレード回数が少なくなりやすいため、1回ごとのコスト悪化の影響が相対的に重いからです。

4.5 テスター結果を過信する

【結論】
MTF EAはテスターで有望に見えても、データ同期やexecution差で実運用と乖離することがあります。

特に注意したい点：

• 上位足データの参照タイミング
• ティック生成方式
• スプレッド固定テスト
• リアル口座とデモ口座の約定差

よくある誤解は、「バックテストで勝っているから実運用でも勝つ」という考え方です。
実際には、MTFの優位性はロジックの整合性に依存するため、テスト環境の前提が崩れると成績も崩れます。

実務では、次の順で確認するのが安全です。

• バックテスト
• フォワードテスト
• 小ロット実運用

この順番を踏むことで、設計ミスとexecutionリスクを切り分けやすくなります。

4.6 初心者向けの注意点まとめ

【結論】
最初から複雑なMTFを作るより、上位足1つ・下位足1つ・役割1つずつで始めるほうが成功率は高いです。

最小構成の目安：

• H1で方向判定
• M5でエントリー
• spread制限だけ追加
• バー確定のみ厳守

この形なら、原因分析がしやすく、失敗したときにも修正点を特定しやすいです。
MTFは「多機能にする技術」ではなく、「判断を分業する技術」と考えると設計がぶれにくくなります。

5. 他手法との比較

【結論】
マルチタイムフレームEAは「精度重視」、単一時間足EAは「シンプル・高速」が特徴です。
どちらが優れているかではなく、目的（戦略・運用スタイル）によって使い分けるべき手法です。

5.1 比較表（意思決定用）

【結論】
MTFは精度と安定性、単一時間足はトレード回数と実装の容易さに強みがあります。

重要なポイント：

• MTFは「無駄なトレードを削る設計」
• 単一時間足は「回数で取りにいく設計」

5.2 単一時間足EAとの本質的な違い

【結論】
違いは「情報量」ではなく、「情報の質」です。

単一時間足EA：

• 同じ時間軸の情報だけで判断
• ノイズを直接処理する必要がある
• インジケータ追加で補うことが多い

MTF EA：

• 異なる時間軸の情報を組み合わせる
• 上位足でノイズをフィルタリング
• 下位足でexecutionを最適化

つまり、MTFは「構造で勝つ」設計です。
インジケータを増やすのとは異なり、市場の階層構造（時間軸）を利用する手法です。

5.3 どちらを選ぶべきか

【結論】
初心者は単一時間足、中級者以上はMTFが適しています。

判断基準：

単一時間足が向いているケース

• EA開発の初期段階
• ロジックの検証を優先したい
• デバッグしやすさを重視

マルチタイムフレームが向いているケース

• トレンドフォロー戦略
• 無駄なトレードを減らしたい
• DDを抑えたい
• 長期運用を前提としている

重要な考え方：

• 最初からMTFにする必要はない
• 単一時間足 → 問題点分析 → MTFで改善

この順番のほうが再現性が高くなります。

5.4 他の代替手法との比較

【結論】
MTFは「フィルターの質」を上げる手法であり、他のフィルター系手法と役割が異なります。

代表的な代替手法：

インジケータ追加型

• MA、RSI、MACDなどを複数組み合わせる
• 問題：ノイズ自体は減らない

ボラティリティフィルター

• ATRで低ボラ時を回避
• 問題：方向性は判断できない

時間帯フィルター

• ロンドン・NY時間のみトレード
• 問題：市場方向は考慮しない

MTFの優位性：

• トレンド（方向）を直接扱える
• ノイズの原因そのものを回避できる
• 他フィルターと併用可能

つまり、MTFは「上位概念」であり、他のフィルターを置き換えるものではなく、組み合わせて使う基盤です。

5.5 実務での最適な組み合わせ

【結論】
MTF単体よりも、「最小限のフィルターと組み合わせる」ことで安定性が上がります。

推奨構成：

• 上位足：トレンド判定（MA）
• 下位足：エントリー（RSIなど）
• 補助：
  • spread制限
  • ATRフィルター（異常値回避）
  • 時間帯制限

やりすぎないことが重要です。

• 条件は3〜5個に収める
• 目的が明確なものだけ採用

5.6 設計上の重要な視点

【結論】
MTFは「勝率を上げる技術」ではなく、負けトレードを減らす技術です。

この視点を持つと設計が安定します。

• どの負けを減らしたいのか
• どの状況を避けたいのか
• そのために上位足をどう使うか

この順番で考えると、無駄な条件追加を防げます。

6. 実務での使いどころ

【結論】
マルチタイムフレームEAは、トレンド環境での精度向上と無駄なトレード回避に強く、長期運用を前提とした戦略で効果を発揮します。
一方で、すべての相場・戦略に適しているわけではありません。

6.1 有効なケース

【結論】
MTFは「方向性が明確な相場」や「フィルターが重要な戦略」で効果を発揮します。

代表的な有効ケース：

トレンドフォロー戦略

• 上位足でトレンド方向を判定
• 下位足で押し目・戻りを狙う
• 無駄な逆張りを排除

例：

• H1で上昇トレンド
• M5で一時的な下落
• RSI低下 → 押し目買い

ボラティリティフィルターと併用

• ATRなどで相場の動きの強さを判定
• 動かない相場（低ボラ）を回避

メリット：

• 無駄なレンジトレード削減
• spread負けの回避

異常値回避（リスク管理）

• 急変動や不安定相場を回避
• 指標発表前後のトレード停止

実務では以下のように使います：

• 上位足が不安定 → トレード停止
• ATR急上昇 → 回避
• spread異常 → execution停止

6.2 不向きなケース

【結論】
MTFは「高速・高頻度トレード」や「超短期戦略」には不向きです。

代表例：

スキャルピング（短期売買）

• 秒〜数分単位のトレード
• execution速度が最重要

問題点：

• 上位足の判断が遅い
• シグナル発生頻度が減少
• slippageの影響が大きい

高頻度トレード（HFT的戦略）

• ティック単位の判断
• レイテンシ（遅延）が致命的

MTFは構造的に不利です。

レンジ専用戦略

• 上下に往復する相場
• トレンドフィルターが逆効果になる場合あり

この場合：

• 上位足のトレンド判定が機能しない
• フィルターでチャンスを潰す可能性

6.3 実運用での設計ポイント

【結論】
MTFは「ロジックの正しさ」だけでなく、execution環境の最適化が必須です。

重要ポイント：

VPS運用（必須に近い）

• レイテンシ低減
• 約定遅延防止

理由：

• MTFはエントリー回数が少ない
• 1回の遅延が成績に直結

ブローカー特性の考慮

• 約定速度
• スプレッド変動
• スリッページ傾向

同じEAでも結果が変わるため注意が必要です。

スプレッド・コスト管理

double spread = (SymbolInfoDouble(_Symbol, SYMBOL_ASK) - 
                 SymbolInfoDouble(_Symbol, SYMBOL_BID)) / _Point;

if(spread > 20)
{
    return;
}

ポイント：

• spreadが広い時間帯は回避
• コスト悪化を防ぐ

トレード時間帯の制御

• ロンドン・NY時間に限定
• 流動性が低い時間を避ける

理由：

• slippageリスク低減
• execution安定

6.4 実務での設計パターン（再現性重視）

【結論】
MTFは「シンプルな構造を維持すること」が長期的な安定性に直結します。

推奨パターン：

• 上位足：トレンド判定（MA）
• 下位足：エントリー（RSI）
• フィルター：
  • spread制限
  • 時間帯制限

避けるべき設計：

• 条件の多重化
• インジケータ過多
• 過剰最適化

理由：

• ロジックがブラックボックス化する
• フォワードで崩れやすい

6.5 リスク管理との関係

【結論】
MTFはリスク管理と組み合わせて初めて効果を最大化します。

重要要素：

• ロット管理（position sizing）
• DD制御（ドローダウン管理）
• 連敗時停止

MTF単体では「負けを減らす」だけであり、
資金管理と組み合わせて初めて安定運用が可能になります。

6.6 実務での判断基準まとめ

【結論】
MTFは「使うべき場面」を選べば強力だが、万能ではありません。

判断基準：

• トレンド相場を狙う → 有効
• トレード回数を重視 → 不向き
• 長期安定運用 → 有効
• 超短期勝負 → 不向き

7. 応用パターン（発展）

【結論】
マルチタイムフレームEAは、時間足の追加・シンボル拡張・インジケータ統合により精度と汎用性を高められます。
ただし、拡張は「目的を限定」しないと過剰最適化に直結します。

7.1 トリプルタイムフレーム構成

【結論】
3つの時間足を使うことで、「大局・中期・短期」を分業し、判断の一貫性を強化できます。

基本構造：

• D1：長期トレンド（市場環境）
• H1：中期トレンド（方向確認）
• M5：エントリー（execution）

ロジック例：

• D1で上昇トレンド
• H1でも上昇継続
• M5で押し目発生 → エントリー

コードイメージ（簡略）：

bool trend_d1 = CheckTrend(PERIOD_D1);
bool trend_h1 = CheckTrend(PERIOD_H1);

if(trend_d1 && trend_h1)
{
    if(CheckEntrySignal(PERIOD_M5))
    {
        ExecuteOrder();
    }
}

メリット：

• ダマシ耐性向上
• トレンドの一貫性確保

注意点：

• フィルター過剰になりやすい
• トレード回数が極端に減る可能性

7.2 マルチシンボル連携

【結論】
複数通貨ペアを組み合わせることで、相関（correlation）を利用した高度な判断が可能になります。

代表例：

• EURUSDとUSDJPYの方向一致確認
• ゴールド（XAUUSD）でリスクオフ判定

ロジック例：

• EURUSD上昇
• USDJPY下降
  → USD弱い → 買い優位

コードイメージ：

double eurusd_price = SymbolInfoDouble("EURUSD", SYMBOL_BID);
double usdjpy_price = SymbolInfoDouble("USDJPY", SYMBOL_BID);

メリット：

• 市場全体の強弱を判断可能
• ダマシ削減

注意点：

• execution環境の負荷増加
• データ取得コスト増加

7.3 インジケータ複合（MTF×指標）

【結論】
MTFとインジケータを組み合わせることで、トレンド＋タイミングの精度をさらに向上できます。

代表的な組み合わせ：

• MA（トレンド）＋RSI（押し目）
• MA＋ATR（ボラティリティ）
• RSI＋MACD（モメンタム）

ロジック例：

• H1 MA上昇 → トレンド判定
• M5 RSI 30以下 → 押し目
• ATR一定以上 → トレード許可

コード例：

int rsi_handle = iRSI(_Symbol, PERIOD_M5, 14, PRICE_CLOSE);

double rsi[];
CopyBuffer(rsi_handle, 0, 0, 1, rsi);

if(rsi[0] < 30)
{
    // 押し目条件
}

重要ポイント：

• インジケータは「役割を分ける」
• 同じ意味の指標を重複させない

7.4 状態管理（ステートマシン化）

【結論】
EAを状態（State）で管理すると、複雑なMTFロジックでも破綻しにくくなります。

状態例：

• WAIT（待機）
• TREND_DETECTED（トレンド確認）
• ENTRY_READY（エントリー準備）
• POSITION_OPEN（保有中）

メリット：

• ロジックの分離
• デバッグ容易
• 再現性向上

コードイメージ：

enum State
{
    WAIT,
    TREND,
    ENTRY
};

State current_state = WAIT;

なぜ有効か：

• MTFは条件が増えやすい
• 状態管理で「いつ何をするか」を明確化できる

7.5 パフォーマンス最適化

【結論】
MTFは計算コストが増えるため、最適化しないとVPS負荷や遅延が発生します。

対策：

• 必要なタイミングだけCopyBuffer実行
• 新バー時のみ計算
• 不要なシンボル参照を削減

例：

if(IsNewBar(PERIOD_H1))
{
    UpdateHigherTimeframe();
}

メリット：

• CPU負荷低減
• execution安定

7.6 過剰最適化を防ぐ設計

【結論】
応用パターンは強力ですが、検証可能性（再現性）を維持できる範囲で使う必要があります。

危険なパターン：

• 時間足を増やしすぎる
• 条件を細かく調整しすぎる
• 特定期間だけに最適化する

安全な設計：

• 各要素に明確な役割を持たせる
• 追加するたびに「何が改善されたか」を確認
• フォワードテストで検証

7.7 初心者から中級者への移行ポイント

【結論】
MTFの応用は「段階的に拡張」することで、破綻を防げます。

推奨ステップ：

1. 単一時間足EAを作る
2. 上位足フィルターを追加
3. 条件を1つずつ検証
4. 必要なら時間足を追加

この流れにより、原因と結果の対応関係が明確なまま成長できるようになります。

8. FAQ

【結論】
マルチタイムフレームEAは「データの扱い」と「設計意図」が理解できていれば安定して運用できます。
以下では、実装・運用で特に多い疑問を短く明確に整理します。

8.1 マルチタイムフレームは必須ですか？

【結論】
必須ではありませんが、トレンドフィルターとしては非常に有効です。

単一時間足でもEAは構築可能です。
ただし、トレンドと逆方向のエントリーが増えやすいため、MTFを使うことで無駄なトレードを減らせます。

8.2 どの時間足の組み合わせが最適ですか？

【結論】
「上位足1つ＋下位足1つ」の構成が基本で、H1＋M5などがよく使われます。

選び方の目安：

• スイング寄り → H4＋M15
• デイトレ → H1＋M5
• 短期寄り → M15＋M1

重要なのは、時間足の倍率（約3〜6倍）を意識することです。

8.3 CopyRatesとCopyBufferはどちらを使うべきですか？

【結論】
価格データならCopyRates、インジケータならCopyBufferを使います。

使い分け：

• CopyRates → ローソク足（open/high/low/close）
• CopyBuffer → MA・RSIなどの指標値

混同すると、ロジックが破綻する原因になります。

8.4 バー確定はどうやって判断しますか？

【結論】
iTime()の変化を使うのが最もシンプルで安全です。

理由：

• 新しいバーが生成された瞬間を検出できる
• 未確定足の誤使用を防げる

重要なポイント：

• 上位足は必ず確定後に使用する
• 未確定データは再現性を崩す

8.5 スキャルピングにも使えますか？

【結論】
基本的には不向きです。

理由：

• 上位足の判断が遅延要因になる
• execution速度が最優先になるため
• slippageの影響が大きくなる

MTFは「精度重視」であり、「速度重視」とは相性が悪いです。

8.6 パフォーマンス（処理速度）は問題になりますか？

【結論】
適切に実装すれば問題ありませんが、最適化は必要です。

対策：

• 新バー時のみ計算
• 不要なCopyBufferを減らす
• シンボル参照を最小化

これにより、VPS環境でも安定稼働できます。

8.7 バックテストは信頼できますか？

【結論】
参考にはなりますが、完全には信頼できません。

理由：

• データ同期のズレ
• スプレッド固定
• execution差異（実運用との差）

実務では：

• バックテスト
• フォワードテスト
• 小ロット運用

の順で検証します。

8.8 スプレッドやスリッページはどの程度影響しますか？

【結論】
MTFではトレード回数が少ないため、1回あたりの影響が大きくなります。

具体的影響：

• spread拡大 → エントリー精度低下
• slippage → 想定ロジックのズレ

対策：

• spread制限を入れる
• 流動性の高い時間帯のみトレード
• execution性能の高い環境を選ぶ

9. まとめ

【結論】
マルチタイムフレームEAは、上位足で環境認識・下位足でエントリーを行う構造により、無駄なトレードを減らし期待値を改善する手法です。
本質は「情報量を増やすこと」ではなく、「情報の質を高めること」にあります。

9.1 本記事の要点整理

【結論】
MTFの核心は「役割分離」と「整合性管理」です。

重要ポイント：

• 上位足＝方向判定（トレンド）
• 下位足＝タイミング（execution）
• フィルターで無駄なエントリーを削減

実装上の要点：

• CopyBuffer / CopyRatesの正しい使い分け
• バー確定の厳守（未確定データを使わない）
• 配列インデックスと時間足のズレ管理

9.2 成功する設計パターン

【結論】
シンプルな構造を維持することが、最も再現性の高い設計です。

推奨構成：

• H1：トレンド判定（MAなど）
• M5：エントリー（RSIなど）
• 補助：
  • spread制限
  • 時間帯フィルター

避けるべき設計：

• 条件の多重化
• インジケータ過多
• 過剰最適化

理由：

• ロジックの因果関係が不明確になる
• フォワードテストで崩れやすい

9.3 実務での活用指針

【結論】
MTFは「勝つための技術」ではなく、負けを減らすための構造として使うべきです。

判断基準：

• トレンド相場を狙う → 有効
• 無駄なトレードを減らしたい → 有効
• トレード回数を増やしたい → 不向き
• 超短期戦略 → 不向き

また、以下の要素と組み合わせることで安定性が向上します。

• ロット管理（position sizing）
• DD制御（ドローダウン管理）
• execution環境の最適化（VPS・ブローカー）

9.4 最短で実用レベルに到達する手順

【結論】
段階的に構築することで、破綻しないMTF EAを作れます。

推奨ステップ：

1. 単一時間足EAを作る
2. 上位足フィルターを追加
3. バー確定・データ整合性を確認
4. フォワードテストで検証
5. 必要に応じて拡張

この順序を守ることで、検証可能で再現性の高いEAになります。

9.5 最後に（実務視点）

【結論】
MTFは強力ですが、効果を出すのは「シンプルな設計＋正確な実装」です。

• 条件を増やすほど良くなるわけではない
• executionコスト（spread・slippage）も含めて設計する
• 検証と実運用の乖離を常に意識する

これらを押さえれば、MTFは長期的に安定した戦略の基盤になります。