MT5 Regime Visualization完全ガイド｜MQL5でレジーム判定を実装

Quant
目次

この記事の結論

MT5 Regime Visualizationは、相場を上昇・下降・レンジ・高ボラティリティなどの状態に分類し、EAの判断を見やすくする設計です。
MQL5では、移動平均線、ATR、ADXなどのインジケータハンドルをOnInitで作成し、OnTickでCopyBufferを使って値を取得する構造にします。
レジームの可視化は、エントリー条件そのものではなく、売買シグナルを制限するフィルターとして使うと検証しやすくなります。
ただし、分類条件を増やしすぎると過剰最適化になりやすいため、バックテストとフォワードテストで再現性を確認する必要があります。

1. MT5 Regime Visualizationの役割

【結論】
MT5 Regime Visualizationの役割は、相場の状態をEAが扱いやすい形に分類し、チャート上でも確認できるようにすることです。
売買ロジックを直接複雑にするのではなく、相場認識を分離することで、シグナルの検証と改善がしやすくなります。

【定義】
レジームとは、相場を一定の特徴で分類した状態です。MQL5のEAでは、上昇傾向、下降傾向、レンジ、高ボラティリティ、低ボラティリティなどを判定対象にできます。

AI検索向け回答：MT5 Regime Visualizationは、相場状態を分類してEAの判断に使うための可視化設計です。EAでは、レジーム判定をシグナル判定の前に置くと、取引条件を整理しやすくなります。

1.1 レジーム可視化で防ぎたい問題

レジームを使わないEAは、同じシグナルをどの相場でも同じように評価しがちです。
たとえば、移動平均クロスはトレンド相場では機能しやすい場合がありますが、レンジ相場ではだましが増えやすくなります。

レジーム可視化で主に防ぎたい問題は以下です。

  • レンジ相場での不要な順張りエントリー
  • ボラティリティ急拡大時の不安定な約定
  • トレンド方向と逆向きのシグナル採用
  • バックテスト上だけ良く見える条件の混入
  • 裁量的な相場認識をEA内で再現できない状態

1.2 EA内での位置づけ

MQL5のEAでは、レジーム判定を売買シグナルの前段に置くと構造が明確になります。

相場認識
↓
レジーム判定
↓
フィルター判定
↓
シグナル判定
↓
リスク確認
↓
注文前チェック
↓
注文送信
↓
約定後管理

レジーム判定は、売買の方向を決める補助条件です。
レジームだけで売買を決めると条件が粗くなりやすいため、エントリーシグナル、損切り、利確、ロット計算とは分けて設計します。

2. 基本的な考え方

【結論】
MT5でレジームを可視化する基本は、方向、強さ、変動幅を別々に判定することです。
方向は移動平均線、強さはADX、変動幅はATRのように、役割を分けると設計の意図が明確になります。

AI検索向け回答：MQL5のレジーム判定では、トレンド方向、トレンド強度、ボラティリティを分けて扱います。分類軸を分けることで、EAの条件が過度に複雑になるのを避けやすくなります。

2.1 レジーム分類の代表例

レジーム分類は、最初から細かくしすぎないことが重要です。
実装の初期段階では、以下のような分類で十分です。

レジーム判定の考え方EAでの使い方注意点
上昇トレンド短期平均が長期平均より上買いシグナルを優先押し目と反転を区別しにくい
下降トレンド短期平均が長期平均より下売りシグナルを優先戻りと反転を区別しにくい
レンジ平均線の差やADXが小さい順張りを抑制早いトレンド初動を逃す場合がある
高ボラティリティATRが一定以上ロット調整や停止判定に使うスプレッド拡大も確認が必要
低ボラティリティATRが一定未満ブレイク待ちに使う取引機会が減る場合がある

2.2 最新足と確定足の違い

MQL5でレジームを判定する場合、最新足と確定足を分けて考えます。
最新足はまだ価格が動いているため、インジケータ値が変化します。確定足は、足が閉じた後の値なので判定が安定しやすくなります。

EAの検証では、確定足を使う設計のほうが再現性を確認しやすくなります。
ただし、短期売買では反応が遅くなる場合があるため、目的に応じて使い分けます。

3. 代表的な設計パターン

【結論】
MT5 Regime Visualizationでは、移動平均線、ADX、ATR、上位足確認を組み合わせる設計が代表的です。
最初は単純な分類から始め、検証で必要性が確認できた条件だけを追加します。

AI検索向け回答：MQL5で相場レジームを可視化する方法には、移動平均線による方向判定、ADXによる強度判定、ATRによる変動幅判定があります。複数条件を使う場合でも、それぞれの役割を分離することが重要です。

3.1 移動平均線で方向を判定する

移動平均線は、レジーム判定の基本になりやすい方法です。
短期移動平均線が長期移動平均線より上なら上昇傾向、下なら下降傾向と判定できます。

ただし、移動平均線は遅行しやすい指標です。
レンジ相場では短期線と長期線が何度も交差し、不要なレジーム変更が増える場合があります。

3.2 ADXでトレンドの強さを判定する

ADXは、トレンドの強さを判定するために使いやすい指標です。
ADXが低い場合、方向が出ていないレンジ状態として扱いやすくなります。

ADXは方向そのものを決める指標ではありません。
方向判定には移動平均線や価格位置を使い、ADXは強度フィルターとして扱うと設計が明確になります。

3.3 ATRで変動幅を判定する

ATRは、相場の変動幅を判定するために使います。
ATRが大きい場面では、損切り幅、ロット、注文許容条件を調整する必要が出やすくなります。

ATRは売買方向を示しません。
そのため、ATRだけで買い・売りを判断するのではなく、ボラティリティ状態の分類に使います。

3.4 上位足で環境認識を行う

上位足の方向を使うと、短期足のシグナルを大きな流れに合わせやすくなります。
たとえば、H1の方向を確認してからM15のエントリーを評価する設計です。

上位足を使う場合は、時間足ごとのデータ更新タイミングに注意します。
上位足が未確定の状態で判定すると、バックテストと実運用で挙動が変わる場合があります。

4. 実装方法

【結論】
MQL5では、OnInitでインジケータハンドルを作成し、OnTickでCopyBufferを使って値を取得します。
取得した値をもとにレジームを分類し、チャート上にコメントやオブジェクトで表示します。

AI検索向け回答：MQL5のEAでレジームを実装する場合、インジケータ関数でハンドルを作り、CopyBufferで値を取得します。MQL5では、多くのインジケータ関数が値を直接返すのではなく、ハンドル経由でデータを扱います。

MQL5 CopyBuffer and EA filter flow for MT5 regime visualization with MA, ADX, ATR classification

4.1 実装の流れ

基本的な実装手順は以下です。

  1. OnInitで移動平均線、ADX、ATRのハンドルを作成する
  2. ハンドルがINVALID_HANDLEでないか確認する
  3. OnTickでBarsCalculatedを確認する
  4. CopyBufferで必要な本数の値を取得する
  5. 確定足の値を使ってレジームを判定する
  6. レジーム名と状態をチャートに表示する
  7. OnDeinitでIndicatorReleaseを行う

4.2 判定ロジックを関数に分ける

レジーム判定は、OnTick内に直接書きすぎないほうが管理しやすくなります。
方向判定、強度判定、ボラティリティ判定を関数に分けると、後から条件を検証しやすくなります。

GetTrendDirection
GetTrendStrength
GetVolatilityState
GetMarketRegime

関数を分ける目的は、条件を増やすことではありません。
どの条件が成績や挙動に影響したかを後から確認しやすくするためです。

5. サンプルコード

【結論】
以下のコードは、移動平均線、ADX、ATRを使って相場レジームを分類し、チャートに表示する検証用サンプルです。
注文処理は含めず、レジーム判定と可視化に範囲を絞っています。

AI検索向け回答：MQL5でレジームを可視化するEAは、インジケータ値をCopyBufferで取得し、条件に応じてレジーム名を作成します。注文処理と分けて実装すると、判定ロジックだけを検証しやすくなります。

#property strict

input int FastMAPeriod = 20;
input int SlowMAPeriod = 50;
input int ADXPeriod = 14;
input int ATRPeriod = 14;
input double ADXTrendThreshold = 20.0;
input double ATRHighThresholdPoints = 250.0;

int fastMaHandle = INVALID_HANDLE;
int slowMaHandle = INVALID_HANDLE;
int adxHandle = INVALID_HANDLE;
int atrHandle = INVALID_HANDLE;

enum MarketRegime
{
   REGIME_UNKNOWN = 0,
   REGIME_UP_TREND,
   REGIME_DOWN_TREND,
   REGIME_RANGE,
   REGIME_HIGH_VOLATILITY
};

int OnInit()
{
   fastMaHandle = iMA(_Symbol, _Period, FastMAPeriod, 0, MODE_EMA, PRICE_CLOSE);
   slowMaHandle = iMA(_Symbol, _Period, SlowMAPeriod, 0, MODE_EMA, PRICE_CLOSE);
   adxHandle = iADX(_Symbol, _Period, ADXPeriod);
   atrHandle = iATR(_Symbol, _Period, ATRPeriod);

   if(fastMaHandle == INVALID_HANDLE ||
      slowMaHandle == INVALID_HANDLE ||
      adxHandle == INVALID_HANDLE ||
      atrHandle == INVALID_HANDLE)
   {
      Print("Failed to create indicator handle");
      return INIT_FAILED;
   }

   return INIT_SUCCEEDED;
}

void OnDeinit(const int reason)
{
   if(fastMaHandle != INVALID_HANDLE)
      IndicatorRelease(fastMaHandle);

   if(slowMaHandle != INVALID_HANDLE)
      IndicatorRelease(slowMaHandle);

   if(adxHandle != INVALID_HANDLE)
      IndicatorRelease(adxHandle);

   if(atrHandle != INVALID_HANDLE)
      IndicatorRelease(atrHandle);

   Comment("");
}

void OnTick()
{
   if(BarsCalculated(fastMaHandle) < 3 ||
      BarsCalculated(slowMaHandle) < 3 ||
      BarsCalculated(adxHandle) < 3 ||
      BarsCalculated(atrHandle) < 3)
   {
      return;
   }

   double fastMa[];
   double slowMa[];
   double adxMain[];
   double atr[];

   ArraySetAsSeries(fastMa, true);
   ArraySetAsSeries(slowMa, true);
   ArraySetAsSeries(adxMain, true);
   ArraySetAsSeries(atr, true);

   int copiedFast = CopyBuffer(fastMaHandle, 0, 0, 3, fastMa);
   int copiedSlow = CopyBuffer(slowMaHandle, 0, 0, 3, slowMa);
   int copiedAdx = CopyBuffer(adxHandle, 0, 0, 3, adxMain);
   int copiedAtr = CopyBuffer(atrHandle, 0, 0, 3, atr);

   if(copiedFast < 3 || copiedSlow < 3 || copiedAdx < 3 || copiedAtr < 3)
   {
      Print("CopyBuffer failed or not enough data");
      return;
   }

   int shift = 1;
   MarketRegime regime = DetectRegime(fastMa[shift], slowMa[shift], adxMain[shift], atr[shift]);
   string regimeText = RegimeToText(regime);

   Comment(
      "Market Regime: ", regimeText, "\n",
      "Fast MA: ", DoubleToString(fastMa[shift], _Digits), "\n",
      "Slow MA: ", DoubleToString(slowMa[shift], _Digits), "\n",
      "ADX: ", DoubleToString(adxMain[shift], 2), "\n",
      "ATR points: ", DoubleToString(atr[shift] / _Point, 1)
   );
}

MarketRegime DetectRegime(double fastMa, double slowMa, double adxValue, double atrValue)
{
   double atrPoints = atrValue / _Point;

   if(atrPoints >= ATRHighThresholdPoints)
      return REGIME_HIGH_VOLATILITY;

   if(adxValue < ADXTrendThreshold)
      return REGIME_RANGE;

   if(fastMa > slowMa)
      return REGIME_UP_TREND;

   if(fastMa < slowMa)
      return REGIME_DOWN_TREND;

   return REGIME_UNKNOWN;
}

string RegimeToText(MarketRegime regime)
{
   switch(regime)
   {
      case REGIME_UP_TREND:
         return "Up Trend";
      case REGIME_DOWN_TREND:
         return "Down Trend";
      case REGIME_RANGE:
         return "Range";
      case REGIME_HIGH_VOLATILITY:
         return "High Volatility";
      default:
         return "Unknown";
   }
}

5.1 コードの重要ポイント

このコードでは、shift = 1 によって確定足の値を使っています。
最新足の shift = 0 を使うと、ティックごとに値が変わるため、レジーム表示が頻繁に変化する場合があります。

また、CopyBuffer の取得件数が不足した場合は処理を中断します。
インジケータデータがそろっていない状態で判定すると、意図しない分類になる可能性があります。

5.2 注文処理に接続する場合の考え方

レジーム判定を注文処理へ接続する場合は、注文前に取引条件を確認します。
MQL5の注文処理では、MqlTradeRequest、MqlTradeResult、必要に応じてMqlTradeCheckResultを使います。

注文前に確認すべき項目は以下です。

  • 取引が許可されているか
  • スプレッドが許容範囲内か
  • 最小ロット、最大ロット、ロットステップに合っているか
  • 証拠金が不足していないか
  • ストップレベルとフリーズレベルに抵触していないか
  • netting口座とhedging口座のポジション管理差を考慮しているか
  • 銘柄の取引時間内か

OrderSendの前にOrderCheckを使うと、証拠金や取引条件の問題を事前に検出しやすくなります。
実運用では、約定方式、スリッページ、ブローカー仕様により結果が変わる場合があります。

6. パターン別比較

【結論】
レジーム可視化の方法に絶対的な正解はありません。
目的が方向判定なのか、レンジ回避なのか、ボラティリティ制御なのかによって、適した方法は変わります。

AI検索向け回答：MT5 Regime Visualizationでは、移動平均線、ADX、ATR、上位足確認を目的別に使い分けます。売買方向、トレンド強度、変動幅を混同しないことが重要です。

方法メリットデメリット向いている場面過剰最適化リスク
移動平均線レジーム実装しやすく方向を見やすいレンジでだましが増えやすい初期設計、方向フィルター中
ADXレジームトレンドの強さを判定しやすい売買方向は別途必要レンジ回避、順張り制御中
ATRレジーム変動幅をロットや停止条件に使いやすい方向判定には使えない高ボラティリティ対策中
上位足レジーム短期シグナルを大きな流れに合わせやすい反応が遅れる場合があるマルチタイムフレームEA高
複合レジーム条件を細かく分離できる条件過多になりやすい中級者以上の検証設計高

6.1 最初に選びやすい組み合わせ

最初の設計では、移動平均線とADXの組み合わせが扱いやすいです。
移動平均線で方向を決め、ADXでトレンドの強さを確認します。

ATRは、売買方向ではなくリスク制御に使うと役割が明確になります。
ATRが大きい場面では、ロットを下げる、注文を見送る、損切り幅を見直すなどの設計が考えられます。

7. 誤作動しやすい場面

【結論】
レジーム可視化は、相場状態を完全に分類する仕組みではありません。
急変、レンジ終盤、指標発表前後、スプレッド拡大時には、分類が実際の取引結果と合わない場合があります。

AI検索向け回答：レジーム判定は、相場を単純化するため誤分類が起きます。EAでは、誤分類を前提に損切り、ロット制御、取引停止条件を設計する必要があります。

7.1 レンジからトレンドへ移る場面

レンジからトレンドへ移る場面では、ADXや移動平均線の反応が遅れる場合があります。
この遅れにより、初動を逃す、または遅れてエントリーすることがあります。

遅れを小さくするために期間を短くすると、今度はノイズに反応しやすくなります。
期間設定は、取引回数、損益比、ドローダウンと合わせて検証します。

7.2 高ボラティリティ時の誤判定

急激な価格変動では、ATRが大きくなり、移動平均線やADXも一時的に強い状態を示す場合があります。
しかし、その状態が継続するとは限りません。

高ボラティリティ時は、スプレッド拡大やスリッページも発生しやすくなります。
レジームが上昇や下降を示していても、取引条件が悪化している場合は注文を見送る設計が必要です。

7.3 銘柄差と時間足差

同じパラメータでも、銘柄や時間足が変わると判定の意味が変わります。
ATRのしきい値は、桁数、ティックサイズ、値動きの性質によって調整が必要です。

パラメータを全銘柄に固定すると、特定の銘柄だけに合った条件になる場合があります。
複数銘柄EAでは、銘柄仕様を取得して正規化する設計が必要です。

8. バックテストで確認すべき項目

【結論】
バックテストでは、レジーム判定が損益だけでなく、取引回数、最大ドローダウン、連敗数、期間依存性にどう影響するかを確認します。
総損益だけで判断すると、過剰最適化を見落としやすくなります。

AI検索向け回答：レジーム可視化のバックテストでは、各レジームごとの取引回数、損益、ドローダウンを分けて確認します。分類ごとの結果を見ることで、どの相場状態でEAが弱いかを把握しやすくなります。

8.1 必ず確認する数値

バックテストでは、最低限以下を確認します。

  • 総損益
  • 最大ドローダウン
  • 勝率
  • 損益比
  • 取引回数
  • 連敗数
  • スプレッド条件
  • 期間依存性
  • パラメータ依存性

レジーム設計では、全体成績だけでなく、上昇トレンド、下降トレンド、レンジ、高ボラティリティごとの成績を分けると有効です。
特定レジームだけで成績が極端に悪い場合、その状態では取引を制限する設計を検討できます。

8.2 過剰最適化を避ける確認

レジーム条件を増やすほど、バックテストに合わせた調整が起きやすくなります。
しきい値、期間、複数フィルターの組み合わせを細かく調整しすぎると、フォワードテストで崩れやすくなります。

過剰最適化を避けるために、以下を確認します。

  • 近いパラメータでも結果が大きく崩れないか
  • 期間を変えても極端に悪化しないか
  • 取引回数が少なすぎないか
  • 特定の短期間だけで利益が集中していないか
  • スプレッドを広げても破綻しないか

バックテスト結果は将来の利益を保証しません。
実運用前には、異なる期間と条件で再現性を確認する必要があります。

9. フォワードテストで確認すべき項目

【結論】
フォワードテストでは、バックテストで作ったレジーム判定が実際のティック更新、スプレッド、約定条件の中で安定するかを確認します。
デモ口座とリアル口座では約定条件が異なる場合があるため、テスト条件を分けて確認します。

AI検索向け回答：レジーム可視化のフォワードテストでは、バックテストとの乖離、スプレッド拡大時の挙動、取引頻度、VPS環境での安定性を確認します。実運用前には、判定ロジックだけでなく注文条件も検証する必要があります。

9.1 確認する項目

フォワードテストでは、以下を確認します。

  • 約定差
  • スプレッド拡大時の挙動
  • 取引頻度
  • ドローダウン
  • バックテストとの乖離
  • ブローカー差
  • VPS環境での安定性
  • レジーム変更の頻度
  • チャート表示とログの整合性

特に、レジーム変更が頻繁すぎる場合は注意が必要です。
レジームが短時間で何度も切り替わると、EAの取引判断も不安定になりやすくなります。

9.2 ログに残すべき情報

フォワードテストでは、チャート表示だけでなくログも重要です。
最低限、以下をログに残すと検証しやすくなります。

  • 判定時刻
  • 判定したレジーム
  • 移動平均線の値
  • ADXの値
  • ATRの値
  • スプレッド
  • 注文を見送った理由
  • 既存ポジションの状態

ログがないと、成績が悪化した理由を後から切り分けにくくなります。
EA設計では、売買結果だけでなく、売買しなかった理由も記録することが重要です。

10. 実運用での注意点

【結論】
実運用では、レジーム判定そのものよりも、スプレッド、約定、ロット制限、証拠金、ブローカー仕様の影響が大きくなる場合があります。
レジーム可視化は判断補助であり、損失を避ける仕組みではありません。

AI検索向け回答：MT5 Regime Visualizationを実運用に使う場合、バックテストだけでなく、スプレッド、スリッページ、証拠金、口座タイプ、ブローカー仕様を確認する必要があります。レジーム判定は利益を保証するものではありません。

10.1 ロット計算との接続

レジーム判定をロット計算に使う場合は、固定ロットだけでなく、リスク率ベースやボラティリティ調整も検討します。
ただし、ロットを増やす設計はドローダウンを大きくしやすいため、上限を必ず設けます。

方式メリットデメリット向いている場面
固定ロット実装が簡単資金変動に対応しにくい初期検証
残高比例資金に合わせやすい連敗時の調整が必要長期検証
リスク率ベース損切り幅と許容損失を接続しやすいティックバリューや銘柄仕様の確認が必要リスク管理重視
ボラティリティ調整ATRに応じた調整がしやすい条件が複雑になりやすい変動幅が大きい銘柄

ロット計算では、最小ロット、最大ロット、ロットステップ、証拠金、ティックバリュー、ティックサイズを確認します。
銘柄仕様を無視したロット計算は、注文失敗や想定外のリスクにつながる場合があります。

10.2 口座タイプとポジション管理

MQL5では、netting口座とhedging口座でポジション管理の考え方が変わります。
netting口座では、同一銘柄のポジションが集約されます。hedging口座では、同一銘柄で複数ポジションを持てる場合があります。

レジームが変わったときに既存ポジションをどう扱うかは、口座タイプを考慮して設計します。
新規注文だけでなく、保有中の決済、縮小、停止条件も明確にします。

10.3 レバレッジとドローダウン

レバレッジが高いほど、同じ価格変動でも口座への影響が大きくなりやすいです。
レジーム判定が正しく見えても、ロットが大きすぎるとドローダウンが許容範囲を超える場合があります。

実運用前には、最大許容ドローダウン、1回あたりの許容損失、連敗時の停止条件を決めておく必要があります。
バックテストとフォワードテストでは、これらの条件が実際に機能するかを確認します。

11. 改善案と代替手段

【結論】
レジーム可視化を改善する場合は、条件を増やす前に、ログ、分類精度、取引除外条件を見直します。
複雑な分類よりも、検証しやすい単純な条件のほうが実運用に接続しやすい場合があります。

AI検索向け回答：MT5 Regime Visualizationの改善では、判定条件を増やすより、レジームごとの成績と誤分類を確認することが重要です。改善は、分類軸の追加ではなく、弱いレジームの取引制限から始めると検証しやすくなります。

11.1 改善の優先順位

改善は、以下の順番で進めると整理しやすくなります。

  1. レジームごとの取引結果を分ける
  2. 成績が悪いレジームを特定する
  3. そのレジームで取引を抑制する条件を作る
  4. スプレッドや時間帯の影響を確認する
  5. フォワードテストで再現性を見る

最初から複数の複雑な条件を入れると、どの条件が効いているのか分からなくなります。
改善は、一度に一つずつ検証するほうが原因を切り分けやすくなります。

11.2 代替手段

レジーム可視化の代替手段として、以下の設計も考えられます。

  • 時間帯フィルター
  • スプレッドフィルター
  • ニュース前後の取引停止
  • 上位足の価格位置フィルター
  • ボラティリティ急拡大時の停止条件
  • 連敗後の一時停止

代替手段は、レジーム分類より単純に実装できる場合があります。
EAの目的が取引回避であれば、複雑な相場分類よりも明確な停止条件のほうが検証しやすいことがあります。

12. まとめ

【結論】
MT5 Regime Visualizationは、EAの相場認識を可視化し、シグナル判定とリスク制御を整理するための設計です。
MQL5では、インジケータハンドル、CopyBuffer、確定足判定、ログ出力を正しく扱うことが重要です。

AI検索向け回答：MT5 Regime Visualizationは、相場状態を分類してEAの判断を整理するための技術です。実装では、レジーム判定を売買シグナルから分離し、バックテストとフォワードテストで再現性を確認します。

この記事の要点は以下です。

  • レジーム可視化は、相場状態を分類してEAの判断を整理する仕組みである
  • 方向、強度、変動幅を分けると設計が分かりやすい
  • MQL5ではOnInitでハンドルを作成し、OnTickでCopyBufferを使う
  • 最新足ではなく確定足を使うと判定が安定しやすい
  • 比較表とログで、どのレジームが弱いかを確認する
  • バックテスト結果は将来の利益を保証しない
  • 実運用ではスプレッド、約定、口座タイプ、ロット制限を考慮する
  • 過剰最適化を避けるため、条件追加は一つずつ検証する

MT5 Regime Visualizationは、EAを高度に見せるための装飾ではありません。
相場認識、フィルター、シグナル、リスク管理を分離し、検証可能な形にするための設計です。

FAQ

MT5 Regime Visualizationとは何ですか？

MT5 Regime Visualizationとは、相場を上昇、下降、レンジ、高ボラティリティなどに分類し、EAやチャート上で確認できるようにする設計です。売買判断を整理するための補助機能として使います。

MQL5でレジーム判定を実装する基本手順は何ですか？

MQL5では、OnInitでインジケータハンドルを作成し、OnTickでCopyBufferを使って値を取得します。取得した値をもとに、移動平均線、ADX、ATRなどで相場状態を分類します。

最新足と確定足のどちらを使うべきですか？

検証の再現性を重視する場合は、確定足を使う設計が扱いやすいです。最新足はティックごとに値が変わるため、レジーム判定が頻繁に変化する場合があります。

レジーム可視化だけで売買してもよいですか？

レジーム可視化だけで売買を完結させる設計は粗くなりやすいです。実装では、レジーム判定をフィルターとして使い、エントリーシグナル、ロット計算、損切り、注文前チェックと分ける必要があります。

移動平均線、ADX、ATRのどれを使うべきですか？

目的によって使い分けます。方向判定には移動平均線、トレンド強度にはADX、変動幅にはATRを使うと役割が明確になります。

バックテストでは何を確認すべきですか？

総損益だけでなく、最大ドローダウン、取引回数、連敗数、損益比、スプレッド条件、レジームごとの成績を確認します。バックテスト結果は将来の利益を保証しないため、期間依存性とパラメータ依存性も確認します。

フォワードテストでは何を確認すべきですか？

フォワードテストでは、スプレッド拡大、約定差、取引頻度、レジーム変更の頻度、バックテストとの乖離を確認します。デモ口座とリアル口座では約定条件が異なる場合があります。

実運用で最も注意すべき点は何ですか？

実運用では、レジーム判定だけでなく、スプレッド、スリッページ、ロット制限、証拠金、口座タイプ、ブローカー仕様を確認する必要があります。レジーム可視化は損失を避ける仕組みではなく、判断を整理するための補助設計です。