MT4のEA（エキスパートアドバイザー）はどのように計算されるのか：数式、パラメータ、データ要件

MT4のEAにおける「計算」とは何を意味するのか

MT4のEA（エキスパートアドバイザー）は、数学のワークシートのように単一の固定された「数式」を計算することは、通常ありません。代わりにEAは、コードとして書かれたルールを継続的に評価します。各イベント（一般的には新しい価格ティックや／またはバーのオープン）ごとに、利用可能なデータを読み取り、（該当する場合）使用するインジケーター値を計算し、その後、どの注文アクションを試みるかを判断するためにロジックを適用します。

したがって「どのように計算されるのか」を最も良く説明する方法は、EAの実行パイプラインを説明することです：

1. 入力を集める（市場データと時間データ、ならびに設定パラメータ）、
2. 中間値を計算する（多くの場合、インジケーター出力やカスタム式）、
3. 意思決定条件を適用する（if/elseルール）、
4. 注文パラメータを計算する（EAに含まれている場合、エントリー／エグジット価格やポジションサイズのロジックなど）、
5. 注文を送信または管理する（プラットフォームとブローカーの制約に従う）。

この枠組みにより、安定した仕組み（コードがどのように構造化され評価されるか）と、変動する条件（価格がどのように到達するか、コスト、そして執行品質）を分けて考えられます。

中核となる「計算」モデル：入力 → 関数 → 意思決定 → アクション

一般的なEAループは、抽象的なモデルとして次のように書けます：

• 時刻 t における入力：

  • EAが必要とする価格系列（例：bid/ask、open/high/low/close、ボリュームなど。コードが要求する内容に応じて異なります）、
  • 現在の時間コンテキスト（サーバー時刻および／またはバーインデックス）、
  • EA設定からの構成パラメータ（例：参照期間の長さ、しきい値、リスクパラメータ、取引制限）、
  • 任意の状態変数（現在の保有ポジション、過去のアクション、内部フラグなど）。

• 中間計算：

  • EAがそれを使う場合のインジケーターのような関数（例：ローリングウィンドウ上で計算される移動平均やオシレーター）、
  • EAの作者が書いたカスタム式。

• 意思決定ルール：

  • アクションが許可されるかどうかを決めるブール条件（例：「エントリー条件が真で、取引上限に達していない場合」）。

• アクション計算：

  • 意思決定から導かれる注文パラメータ（EAに含まれている場合、意図したエントリーレベル、ストップ／リミットレベル、そしてサイズ計算ロジックなど）。

• 執行結果：

  • プラットフォーム／ブローカーがリクエストを受け入れるかどうか、そして実際にどの価格で約定するか。

実際には、EAのコードが正確な関数としきい値を決めるため、2つの異なるEAでも、共有されたこのパイプラインに従っている一方で、「計算」の中身はまったく別のやり方になることがあります。

EAのロジックを再現するために必ず列挙すべきパラメータとデータ要件

EAの計算を独立して説明するには、それが依存しているすべての入力を特定する必要があります。一般的なカテゴリは次のとおりです：

1. 市場データ入力 EAは通常、実行時および／またはバックテストで、MT4で利用可能な価格系列を読み取ります。重要なポイントは、EAが「計算」できるのはアクセスできるものだけだということです：もしEAのコードがbid/askを使うなら、スプレッドが計算の一部になります。もしEAがOHLCバーを使うなら、バー形成のルールが重要になります。

2. 時間と評価タイミング 多くのEAは次のいずれかで動作します：

• 受信する各ティックごと、
• 新しいバー（バーオープン）ごと、または
• 両方。

これにより、インジケーターの参照ウィンドウに含まれる価格と、意思決定がトリガーされる正確な時刻が変わります。

3. 設定パラメータ これらはユーザーが設定するEAの項目です。一般的な例（説明は一般的に）としては次のようなものがあります：

• ローリング計算の参照期間の長さ、
• 条件のしきい値、
• ポジション数または取引頻度に関する上限、
• ストップロス／テイクプロフィットの距離、またはロジック、
• 任意のスケーリングや平均化ルール。

4. 状態とポジションのコンテキスト 一部のルールは現在のエクスポージャーに依存します。つまり、ポジションが存在するかどうか、保有中の取引数、その方向、そしてEAがそれらを管理すべきかどうかです。

5. 執行に関する前提 EAが意図した価格を計算していても、最終的にはプラットフォームが制約を適用する執行環境と相互作用し、実現価格で約定する可能性があります（最小ストップ距離、フリーズレベルなど）。

実際のライブ価格を仮定せずに「計算」を示す具体例

仕組みを明確にするために、参照平均を条件の一部として使うEAを考えてみましょう。この場合の一般的な構造は、抽象的には次のようになります：

• 時刻 t で値を計算する：
  • MA(t) = 直近N本の終値の平均（EAの作者が、定義の正確な内容を決めます）。
• 次に意思決定条件を適用する：
  • 現在の価格が MA(t) に対してあるしきい値を満たすなら、エントリーのリクエストを許可する。
• エントリーが許可されるなら、注文パラメータを計算する：
  • 設定された距離またはレベルに基づいて、意図したストップ／リミットの水準を決める。
• EAはリクエストを送信し、後でそれを管理します（管理ロジックが含まれている場合）。

MA(t) の厳密な数式は、EAが選んだインジケーター定義に依存しますが、全体の考え方は変わりません。EAは過去のウィンドウから中間量を計算し、その結果をブールロジックに使います。

重要な制限と失敗パターン

同じ入力であればEAのコードが決定論的に動作するとしても、実際の結果が異なることが多いのは、入力ストリームと執行が環境ごとに同一ではないためです。

1. バックテストとライブの不一致 テストに使われる過去データは、将来の市場のミクロ構造を反映していない可能性があります。また、MT4のバックテストがティックや注文約定をモデル化する方法は、実際の執行と異なる場合があります。つまり、ある環境では整合して見える計算でも、別の環境では挙動が変わり得ます。

2. スプレッド、コスト、約定品質 EAがbid/askを使うなら、コストやスプレッドの変動が実効的な入力を変えます。さらに、EAは意図した価格を「計算」していても、ブローカーは乖離し得る、実現可能な価格で約定します。

3. データ利用可能性とインジケーターのウィンドウ端のケース EAが、起動時に利用可能な履歴よりも長い参照期間を要求する場合、初期の計算は不完全になったり、別の挙動を示したりすることがあります。同様の問題は、バー形成がEAの評価タイミングと一致していない場合にも起こります。

4. 状態管理の違い 一部のEAは内部状態（フラグ、カウンター、最後のアクション時刻など）を保存します。この状態が異なる形で初期化されたり、設定を変更したりすると、結果が分岐することがあります。

5. プラットフォームとブローカーの制約 パラメータが制約に違反していると、注文の受け付けに失敗する可能性があります。このような場合、EAの「計算」は有効な意思決定を生成していても、プラットフォームが期待どおりに実行しないことがあります。

計算を独立して検証する方法

EAの「計算」は、実際にそのコードが何をしているかを確認することで検証できます：

• 入力を列挙する：どの価格フィールドと時間イベントを読み取っているかを文書化する。
• 中間計算を特定する：EAが呼び出す各関数を再現する（EAが使うインジケーターの数式を含む）。
• 意思決定条件を記録する：EAのブールルールを平易な言葉に翻訳する。
• アクションのパラメータロジックを追跡する：注文水準とサイズ計算をどのように算出するかを明示する（含まれている場合）。
• 前提をテストする：異なる過去データセット、または異なる執行モデル化設定のもとで結果を比較し、どの部分が敏感かを確認する。

DOCUMENT END