MQL5クラス・構造体・配列設計完全ガイド｜EA開発で使うデータ整理の基本

MQL5でEA、インジケーター、スクリプト、補助ツールを作る時、最初は変数と関数だけでも実装できます。

しかし、機能が増えてくると、ロジックごとの状態、ポジション情報、インジケーター値、外部連携状態、通知状態、ログ設定、UI表示状態、バックテスト用の一時情報などを整理する必要が出てきます。

これらをすべてグローバル変数だけで扱うと、どの関数がどの状態を変更しているのか分かりにくくなり、改修時の影響範囲も追いにくくなります。

この記事では、MQL5でEAやインジケーターを保守しやすく作るために、変数、配列、構造体、クラス、includeファイル、mqh、runtime状態、複数ロジックEAの状態管理、position snapshot、配列範囲エラー対策を整理します。

このページは、MT5 / MQL5の技術学習記事です。特定の取引判断、売買タイミング、ロット、銘柄、運用結果を案内するものではありません。

この記事で確認すること

変数・配列・構造体・クラスの違い

MQL5では、単一の値を扱う変数、同じ型の値を複数扱う配列、関連する値をまとめる構造体、データと処理をまとめるクラスを使い分けます。

どれを使うかは、コードの規模、扱うデータの種類、将来の改修予定、ログ確認のしやすさによって変わります。

小さなEAでは、変数と関数だけで十分な場合があります。一方で、複数ロジック、複数ポジション、外部連携、通知、パネル表示、ログ制御を扱うEAでは、構造体やクラスを使って状態を整理すると保守しやすくなります。

配列を使う場面

配列は、同じ種類の値を複数まとめて扱う時に使います。

MQL5では、価格データ、インジケーターバッファ、複数ロジックの状態、複数ポジションの情報、ログ用の集計値などで配列を使う場面があります。

配列を使う時は、配列サイズとindex範囲の確認が重要です。特に、CopyRatesやCopyBufferの戻り値が想定本数より少ない時に、そのまま配列を参照すると問題につながる場合があります。

構造体を使う場面

構造体は、関連する複数の値を1つのまとまりとして扱いたい時に使います。

たとえば、ロジック状態、ポジション情報、signal判定結果、risk判定結果、ログ出力用の状態などは、構造体にまとめると読みやすくなる場合があります。

struct LogicState
{
   int      logic_id;
   long     magic;
   bool     enabled;
   datetime last_signal_time;
   string   last_reason;
};

上記は、状態をまとめる考え方を示す最小例です。取引条件や運用設定を示すものではありません。

構造体は、関連する値をまとめたい時に便利です。ただし、1つの構造体にすべてを詰め込みすぎると意味が分かりにくくなるため、目的ごとに小さく分ける方が確認しやすくなります。

クラスを使う場面

クラスは、データと処理をひとまとまりにしたい時に使います。

MQL5では、注文管理、ポジション管理、ログ管理、外部連携、UIパネル管理、設定管理などでクラスを使うことがあります。

class CLogLimiter
{
private:
   datetime m_last_time;

public:
   CLogLimiter()
   {
      m_last_time = 0;
   }

   bool CanPrint(const int interval_sec)
   {
      datetime now_time = TimeCurrent();

      if(now_time - m_last_time >= interval_sec)
      {
         m_last_time = now_time;
         return true;
      }

      return false;
   }
};

上記は、ログ出力間隔を管理する考え方を示す最小例です。特定のEA運用や取引設定を示すものではありません。

クラスは便利ですが、すべてをクラス化すればよいわけではありません。小さな処理まで過度にクラス化すると、かえって追いにくくなる場合があります。

includeファイルとmqhの役割

EA本体のmq5ファイルが大きくなる場合、共通処理やクラス定義をincludeファイルへ分けることがあります。

MQL5では、mqhファイルを使って、共通定義、構造体、クラス、ユーティリティ関数、ログ処理などを分離できます。

include分割では、ファイルを分けること自体が目的ではありません。責務ごとに分け、どこを見ればよいか分かる状態にすることが目的です。

グローバル変数を増やしすぎない考え方

MQL5では、グローバル変数を使うこと自体は珍しくありません。

ただし、EAの規模が大きくなるにつれて、グローバル変数が増えすぎると、どの関数がどの状態を変更しているのか分かりにくくなります。

すべてのグローバル変数をなくす必要はありません。重要なのは、何をグローバルに置くのか、何を構造体やクラスへまとめるのかを意図的に決めることです。

EAの状態管理を構造化する方法

EAでは、現在の稼働状態、認証状態、外部制御状態、signal結果、risk結果、exit状態、通知状態などを管理することがあります。

これらを1つずつ別変数にすると、規模が大きくなった時に追いにくくなります。状態を目的別に構造化すると、ログ確認や改修がしやすくなります。

EAの状態管理では、input初期値とruntime状態を混同しないことが重要です。Inputs欄に表示される値と、稼働中に変化した状態は分けて管理してください。

複数ロジックEAでのデータ分離

複数ロジックEAでは、ロジックごとにsignal、ポジション、Magic Number、risk、exit、ログ、設定を分ける必要があります。

ロジック1とロジック2が同じ変数や同じMagic Numberを使っていると、どちらの処理でエントリーしたのか、どちらのexit条件で決済したのかが分かりにくくなります。

struct LogicRuntime
{
   int    logic_id;
   long   magic;
   bool   enabled;
   string last_signal_reason;
};

LogicRuntime g_logic_states[4];

この例は、複数ロジックの状態を配列で持つ考え方を示すものです。実際のEAでは、初期化、index範囲、Magic Numberの重複確認、ログ出力をあわせて設計してください。

position snapshotの考え方

position snapshotとは、現在保有しているポジション情報を、ある時点の状態として整理しておく考え方です。

MQL5では、保有ポジションをその場で毎回探すだけでなく、symbol、magic、ticket、volume、price、profit、directionなどを一度整理してから、riskやexitで使う設計にすることがあります。

snapshotは、保有状態を固定的に記録するというより、特定時点の状態を整理して後続処理へ渡す考え方です。最新状態が必要な処理では、取得タイミングと更新タイミングを明確にしてください。

配列範囲エラーを避ける方法

配列範囲エラーは、配列の存在しないindexへアクセスした時に発生します。

MQL5では、CopyRatesやCopyBufferで取得できた本数が不足しているのに、想定本数がある前提で配列を読むと、実行時エラーや誤判定につながる場合があります。

double close_values[];

int copied = CopyClose(_Symbol, PERIOD_M15, 0, 3, close_values);

if(copied < 3)
{
   PrintFormat("DIAG/DATA close_not_enough requested=%d copied=%d", 3, copied);
   return;
}

double last_closed_bar = close_values[1];

この例は、配列を読む前に取得本数を確認する考え方を示すものです。実際の処理では、配列の向き、shift、必要本数、データ不足時の扱いを仕様として決めてください。

初期化・リセット・runtime状態の分離

EAでは、input初期値、OnInitで作る初期状態、稼働中に変わるruntime状態、再起動後も保持する状態を分けて考えます。

これらを混同すると、設定を変えていないのに状態が変わる、リセット後に一部だけ古い状態が残る、時間足変更後に挙動が変わる、といった問題につながる場合があります。

input初期値とruntime状態の分離は、不具合調査やサポート対応でも重要です。再現条件を確認する時は、setファイルだけでなく、稼働中に変更された状態がないかも確認してください。

保守しやすい命名とコメント

変数、構造体、クラス、includeファイルを整理しても、命名が曖昧だと保守しにくくなります。

名前は、何を表すのか、どの層のデータなのか、runtime状態なのか、input設定なのかが分かるように付けると確認しやすくなります。

コメントは、多すぎても少なすぎても読みづらくなります。何をしているかではなく、なぜその処理が必要なのか、どの責務に属するのかを補足するコメントが有効です。

悪い設計と整理された設計の比較

MQL5の設計では、動くことだけを優先すると、後から改修しにくいコードになることがあります。

特に、大規模EA、複数ロジックEA、外部連携EA、パネル付きEAでは、状態管理と責務分離が重要になります。

整理された設計とは、必ず複雑なクラス構成にすることではありません。変更点、影響範囲、ログ、再現条件を追いやすい構造にすることです。

開発依頼時に伝えるべき構造情報

既存EAの改修、大規模EAの整理、複数ロジック化、外部連携追加を相談する場合は、現在の構造情報を整理しておくと確認しやすくなります。

ソースコードがある場合は、mq5本体、includeファイル、setファイル、ログ、再現条件をセットで整理してください。ソースコードがない場合でも、Inputs欄、画面表示、ログ、動作説明から構造を推定できる場合があります。

送ってはいけない情報

ソース、setファイル、ログ、スクリーンショットを送る場合でも、機密情報はそのまま送らないでください。

送ってよいか判断できない情報は、そのまま送らず、伏せ字にするか削除してください。

MQL5クラス・構造体・配列設計チェック表

クラス・構造体・配列設計を見直す時は、以下を確認してください。

よくある質問

クラスを使わなくてもEAは作れますか？

作れます。小規模なEAでは、変数と関数だけで十分な場合もあります。ただし、複数ロジック、外部連携、通知、UI、ログ管理が増えると、クラスや構造体で整理した方が保守しやすくなる場合があります。

構造体とクラスはどう使い分けますか？

関連する値をまとめたいだけなら構造体が向いています。状態に加えて、その状態を操作する処理もまとめたい場合はクラスを検討します。過剰にクラス化すると読みにくくなるため、目的に応じて使い分けます。

配列範囲エラーはなぜ起きますか？

存在しないindexを参照した時に起きます。CopyRatesやCopyBufferの取得本数不足、ループ条件ミス、配列初期化漏れ、ロジック番号と配列indexのずれなどが原因になる場合があります。

includeファイルを分けるメリットは何ですか？

責務ごとにコードを分けることで、注文処理、ログ処理、ポジション管理、外部連携、UIなどの確認場所を整理できます。ただし、分割しすぎると依存関係が追いにくくなるため、目的を明確にして分けることが重要です。

複数ロジックEAでは何を分けるべきですか？

Magic Number、signal状態、risk状態、exit状態、position snapshot、ログタグ、input設定の意味をロジックごとに分ける必要があります。ロジック間で同じ状態を共有すると、調査や改修が難しくなる場合があります。

グローバル変数が多いと何が問題ですか？

どの関数がどの状態を変更しているのか追いにくくなります。影響範囲が広くなり、改修時に予期しない挙動が出る場合があります。関連する値は構造体やクラスにまとめると確認しやすくなります。

配列と構造体を組み合わせてもよいですか？

可能です。複数ロジックの状態を管理する場合などは、構造体を配列で持つ設計が有効な場合があります。ただし、indexとロジック番号の対応、初期化、範囲チェックを明確にしてください。

UIパネルの状態も構造体で管理できますか？

管理できます。ただし、表示用の状態とEAの判定用状態は分けてください。UIの表示更新が遅れたり失敗したりしても、判定ロジックに不要な影響を与えない設計が重要です。

関連する技術講座

クラス、構造体、配列設計を確認する場合は、MQL5開発入門、関数、EA設計、デバッグ、価格データ、注文管理、マルチシンボル設計もあわせて確認してください。

関連する確認ページ

技術講座を確認した後、導入、開発相談、不具合報告、資料整理へ進む場合は、以下のページも確認してください。

購入前・利用前に確認するページ

EA、インジケーター、補助ツールを利用する前には、商品一覧、動作環境、購入前確認、利用上の注意も確認してください。

まとめ

MQL5でEAやインジケーターを保守しやすく作るには、変数、配列、構造体、クラス、includeファイルの役割を分けて考えることが重要です。

配列は複数の値を扱う時に便利ですが、取得本数やindex範囲を確認しないと、配列範囲エラーや誤判定につながる場合があります。構造体は関連する値をまとめる時に、クラスは状態と処理をまとめる時に役立ちます。

大規模EAや複数ロジックEAでは、Magic Number、signal、risk、exit、position snapshot、ログタグをロジックごとに分離すると、検証や改修がしやすくなります。

設計を確認しても整理が難しい場合は、EA名、バージョン、setファイル、Expertsログ、Journalログ、発生時刻、スクリーンショットを整理したうえで相談してください。口座番号、Webhook URL、GAS URL、APIキー、認証トークンなどの実値は、必要に応じてマスクしてください。