【MQL5】FrameAdd関数の使い方と自動売買実装コード

1. FrameAdd関数の概要と実務での活用法

MQL5におけるFrameAdd関数は、ストラテジーテスターでの最適化（最適化セッション）中に、各パス（試行）の計算結果をターミナル側に送信するための関数です。

通常のバックテストでは、最終的な損益やプロフィットファクターなどの標準的な統計値しか得られません。しかし、実務レベルのクオンツ開発においては、「特定の時間帯だけのドローダウン」や「独自に定義したリスクリバティ指標」など、標準レポートにはない詳細なデータを蓄積し、分析したい場面が多々あります。

FrameAddを活用することで、最適化の各ステップで生成された任意のデータ（数値や構造体、配列など）を「フレーム」という単位で保存し、後から一括で取り出すことが可能になります。

実務でのつまずきポイント：
初心者の多くは、この関数を通常のバックテストやリアルタイム稼働中に使おうとして、「何も起きない」という壁にぶつかります。FrameAddはあくまで最適化（Optimization）プロセス専用の関数であるという点をまず理解しておく必要があります。

2. 構文と戻り値

FrameAddには、送りたいデータの形式に合わせていくつかのオーバーロードがありますが、最も汎用的な構文は以下の通りです。

bool FrameAdd(
   const string  name,   // フレームの名前（識別子）
   long          id,     // フレームのID（ユーザー定義）
   double        value,  // 送信する数値データ（単一の値）
   const void&   data[]  // 送信する構造体や配列などのバイナリデータ
);

パラメーター解説

• name: フレームを識別するための文字列です。
• id: ユーザーが自由に定義できる数値IDです。受信側でどのデータかを判別するのに使います。
• value: 1つの数値を手軽に送りたい場合に使用します。
• data[]: 構造体や配列など、複雑なデータをまとめて送る際に使用します。

戻り値

• 成功した場合は true、失敗した場合は false を返します。

3. 具体的な使い方・実践サンプルコード

以下のサンプルは、最適化中に「最大ドローダウンが発生した日時」と「カスタムスコア」を構造体にまとめ、ターミナル側に送信するシンプルなEAの実装例です。

// カスタムデータを格納するための構造体
struct CustomResult {
   datetime max_dd_time; // 最大ドローダウン発生時刻
   double custom_score;  // 独自の評価スコア
};

//--- 最適化の各パスが終了した時に呼ばれる
double OnTester() {
   // 1. 送信したいデータを作成
   CustomResult res;
   res.max_dd_time = (datetime)TesterStatistics(STAT_MAX_DRAWDOWN_INSTANT_TIME);

   // 例：プロフィットファクターと取引回数を掛け合わせた独自スコア
   res.custom_score = TesterStatistics(STAT_PROFIT_FACTOR) * TesterStatistics(STAT_TRADES);

   // 2. FrameAddでデータを送信
   // 第3引数には簡易的な数値（ここでは残高）、第4引数に構造体を渡す
   if(!FrameAdd("MyCustomStats", 101, AccountInfoDouble(ACCOUNT_BALANCE), res)) {
      Print("フレーム送信失敗: ", GetLastError());
   }

   // OnTesterは最適化の評価基準となる値を返す必要がある
   return(res.custom_score);
}

//--- 最適化全体が終了した時にターミナル側で呼ばれる（任意）
void OnTesterDeinit() {
   Print("最適化が完了し、すべてのフレームデータが蓄積されました。");
}

このコードを最適化モードで実行すると、各パラメーターの組み合わせごとに CustomResult 構造体のデータがターミナルへ送信されます。これらは通常、OnTesterPass イベントハンドラと組み合わせて解析に利用します。

4. 使用上の注意点とよくあるエラー

1. 最適化モード以外では機能しない
   FrameAddは、通常のバックテスト（単一実行）やリアルチャートでの稼働中には動作しません。動作確認をする際は、必ずストラテジーテスターの「設定」タブで最適化を有効にしてください。
2. データ量の制限
   一度に送信できるデータサイズには上限があります。巨大な配列を頻繁に送ると、通信オーバーヘッドにより最適化のスピードが著しく低下したり、メモリ不足のエラーを招くことがあります。必要なデータだけを構造体に絞り込んで送るのがコツです。
3. 受信側の実装忘れ
   FrameAddでデータを送っても、それを受け取る側（OnTesterPassなど）が適切に記述されていないと、送信したデータは活用されません。データをCSVに書き出したり、GUIで表示したりする場合は、受信側のロジックもセットで構築する必要があります。

5. 【重要】自動売買における約定スピードと環境の罠

アルゴリズムトレードの世界では、ロジックの優位性と同じくらい、あるいはそれ以上に「執行環境」が勝敗を分けます。特にMQL5で開発したEAを自宅のPCで24時間稼働させることは、プロの視点から見ると非常にリスクが高い行為です。

家庭用のインターネット回線は、物理的な距離によるネットワーク遅延（レイテンシ）が大きく、数ミリ秒の遅れがスリッページを引き起こします。これが積み重なると、バックテストでは右肩上がりだった収益曲線が、実運用では約定拒否や不利な価格での約定によって無惨に削り取られることになります。また、OSのアップデートや停電、Wi-Fiの不安定な接続など、自宅環境には取引を停止させる「不可抗力の罠」が潜んでいます。

極限まで約定スピードを高め、機会損失をゼロに近づけるためには、取引サーバーに物理的に近いデータセンター内に設置された専用のVPS（仮想専用サーバー）が不可欠です。低レイテンシ環境での運用は、もはや上級者だけの特権ではなく、FXシステムトレードで生き残るための最低条件と言っても過言ではありません。