MQL5長時間稼働・安定化完全ガイド｜メモリ・ハンドル・ログ・オブジェクト管理の基本

MQL5でEAやインジケーターを長時間動かす場合、最初は問題なく動いていても、時間の経過とともにチャートが重くなる、パネルが反応しにくくなる、ログが増えすぎる、Objectが残る、再セット後に表示が混ざる、といった問題が出ることがあります。

これらは、単純なコンパイルエラーとは違い、短時間の起動確認だけでは見つけにくい問題です。OnTickに重い処理を置きすぎている、indicator handleを毎回作っている、不要なログを出し続けている、Objectを毎tick再作成している、OnDeinitで重いcleanupを行っている、外部連携の失敗処理が本体処理と混ざっている、といった設計上の原因が関係する場合があります。

この記事では、MQL5のEA・インジケーターを長時間稼働させる時に確認したい、メモリ、indicator handle、IndicatorRelease、ログ抑制、Object管理、OnTimer分離、VPS運用、フリーズ・ブラックアウト時の確認項目を整理します。売買判断、推奨銘柄、推奨ロット、運用成績に関する助言は扱いません。技術的な安定化と問い合わせ前整理に限定します。

この記事で扱う範囲

本記事では、MQL5 EA・インジケーターを長時間動かす時の安定化に関係する実務項目を扱います。対象は、EA、インジケーター、パネルEA、外部連携EA、通知機能付きツール、複数銘柄・複数時間足を扱うツールです。

主に扱う内容

この記事で扱わないこと

本記事では、売買ロジックの良し悪し、運用成績の評価、具体的なパラメータ調整、特定環境への誘導は扱いません。MQL5プログラムを長時間動かすための構造、ログ、表示、終了処理、確認手順に絞ります。

MT5 EAやインジが重くなる主な原因

EAやインジケーターが重くなる原因は、1つとは限りません。短時間では目立たなくても、長時間稼働や複数チャート運用、VPS環境、バックテスト、外部連携、Object表示を組み合わせると、負荷が蓄積して見える場合があります。

重くなる原因表

短時間確認だけでは分からない問題

起動直後は軽く見えても、数時間後や翌日に重くなる場合があります。長時間稼働では、ログ量、Object数、handle作成回数、外部連携の失敗回数、通知queue、再描画回数などが影響します。

そのため、長時間稼働確認では、単に「起動したか」だけではなく、時間経過後のExpertsログ、Journalログ、チャート表示、Object残存、CPU使用率、VPSの応答、MT5の操作感も確認します。

OnTickに重い処理を置かない理由

OnTick は、EAが新しいtickを受け取るたびに呼ばれます。tickが多い銘柄や時間帯では短時間に何度も呼ばれるため、ここに重い処理を置くと、処理が追いつきにくくなります。

OnTickに置くべき処理は、価格変化に依存する軽量な確認、現在価格の取得、新バー判定、必要な評価helperの呼び出しなどです。外部通信、全Object走査、全履歴走査、大量ログ、パネル全再構築などは、OnTimerや別helperへ分けることを検討します。

OnTickに置く処理・分ける処理

OnTickを軽く保つ最小例

void OnTick()
{
   UpdateTickSnapshot();

   if(IsNewBar())
   {
      EvaluateOnNewBar();
   }

   RunLightRuntimeCheck();
}

この例では、OnTick内に長い処理を直接書かず、役割ごとのhelperを呼び出しています。重い処理を後から見つけやすくするためにも、OnTickは短く保つ方が確認しやすくなります。

ログ出力が多すぎる時の問題

ログは、不具合確認や販売後サポートで重要です。ただし、同じログが毎tick出続けると、必要な情報が埋もれます。バックテストでは、ログ量が多すぎることで確認や実行時間に影響することもあります。

長時間稼働では、ログを「常時出すもの」「状態変化時だけ出すもの」「debug時だけ出すもの」「終了時summaryにするもの」に分けます。

ログ抑制方針表

状態変化時だけ出す例

void PrintWhenStateChanged(const string label,
                           const string current)
{
   static string last = "";

   if(current != last)
   {
      Print("STATE_CHANGE: ", label,
            " from=", last,
            " to=", current);
      last = current;
   }
}

この例では、同じ状態が続く間はログを出さず、状態が変わった時だけ出します。実務では、labelごとに前回値を持つなど、機能別に管理します。

indicator handleの管理

MQL5では、iMA、iATR、iBands などの関数でindicator handleを作成し、CopyBuffer で値を取得する構成がよく使われます。長時間稼働では、このhandle管理が重要です。

handleを毎tick作成したり、再初期化のたびに不要なhandleを残したりすると、確認しづらい不安定要因になります。基本は、OnInitで作成し、必要な期間は再利用し、終了時や不要になった時に解放する流れです。

handle管理表

handle作成の最小例

int g_ma_handle = INVALID_HANDLE;

int OnInit()
{
   g_ma_handle = iMA(_Symbol, PERIOD_CURRENT, 20, 0, MODE_SMA, PRICE_CLOSE);

   if(g_ma_handle == INVALID_HANDLE)
   {
      Print("HANDLE_INIT_FAIL: name=MA");
      return INIT_FAILED;
   }

   Print("HANDLE_INIT: name=MA status=OK");
   return INIT_SUCCEEDED;
}

この例では、OnInitでhandleを作成しています。実務では、銘柄、時間足、期間、適用価格などをログに出すと、設定確認がしやすくなります。

IndicatorReleaseの考え方

IndicatorRelease は、不要になったindicator handleを解放するために使います。長時間稼働や再初期化が関係するEA・インジケーターでは、handleの作成と解放の流れを整理しておくことが重要です。

ただし、IndicatorReleaseを呼べばすべて解決するというより、そもそもhandleを無駄に作らない設計が先です。毎tickでhandleを作成し、それを毎回解放するような構造ではなく、必要なhandleを作成して再利用する設計にします。

IndicatorReleaseの最小例

void OnDeinit(const int reason)
{
   if(g_ma_handle != INVALID_HANDLE)
   {
      bool released = IndicatorRelease(g_ma_handle);
      Print("HANDLE_RELEASE: name=MA ok=", released ? "Y" : "N");
      g_ma_handle = INVALID_HANDLE;
   }

   EventKillTimer();
}

この例では、OnDeinitでhandleを解放し、変数を INVALID_HANDLE に戻しています。解放対象、解放結果、終了理由をログに残すと確認しやすくなります。

IndicatorReleaseで確認すること

チャートオブジェクトが増えすぎる問題

パネルUI、ライン、ラベル、ボタン、ステータス表示、通知用マークなどを使うEA・インジケーターでは、チャートObjectの管理が重要です。Objectを毎tick作成し続けたり、削除対象を絞らずに増やし続けたりすると、表示が重くなる原因になります。

Objectは、作成・更新・削除・残存時の扱いを仕様化します。特に、表示専用Objectと、実ロジックに影響するObjectを分けることが重要です。

Object管理の基本表

差分更新を基本にする

Objectは、毎回削除して作り直すのではなく、なければ作る、あれば必要なプロパティだけ更新する方式にします。これにより、ちらつきや描画負荷を抑えやすくなります。

void UpsertStatusLabel(const string name,
                       const string text)
{
   if(ObjectFind(0, name) < 0)
   {
      ObjectCreate(0, name, OBJ_LABEL, 0, 0, 0);
      ObjectSetInteger(0, name, OBJPROP_CORNER, CORNER_LEFT_UPPER);
      ObjectSetInteger(0, name, OBJPROP_XDISTANCE, 10);
      ObjectSetInteger(0, name, OBJPROP_YDISTANCE, 20);
   }

   ObjectSetString(0, name, OBJPROP_TEXT, text);
}

この例では、Objectがなければ作成し、存在する場合は文字だけ更新します。実務では、前回のtextと同じなら更新しない、一定秒数ごとに更新するなど、さらに負荷を抑える設計も考えられます。

OnDeinit cleanupの注意

EAやインジケーターの終了時に、すべてのObjectを削除したくなることがあります。しかし、OnDeinitで全Object走査や大量削除を行うと、削除時、時間足変更時、再コンパイル時、チャート切替時に不安定化する場合があります。

OnDeinitでは、見た目の完全cleanupよりも、異常終了しないことを優先します。timer停止、handle解放、Comment解除などの軽量処理を中心にし、Object整理はprefixや用途を限定します。

Object lifecycle注意表

削除対象をprefixで絞る

Objectを削除する場合は、自EAが作成したObjectだけを対象にします。手動ライン、他EA、他インジケーターのObjectを巻き込まないために、Object名prefixを設計しておきます。

bool IsMyObject(const string name)
{
   return (StringFind(name, "EAF_STABLE_") == 0);
}

このようにprefixで対象を絞ると、cleanupやstartup auditの対象を管理しやすくなります。

OnTimerへ分離する処理

長時間稼働では、OnTickに処理を集中させず、一定間隔でよい処理をOnTimerへ分けることが有効です。外部制御、認証確認、通知queue、UIメンテナンス、Object数確認、heartbeatログなどはOnTimerに向いています。

OnTimerへ分離する処理表

OnTimer分離の最小例

int OnInit()
{
   EventSetTimer(5);
   Print("INIT: timer=5sec");
   return INIT_SUCCEEDED;
}

void OnTimer()
{
   RefreshExternalStateIfNeeded();
   ProcessNotificationQueue();
   UpdatePanelIfChanged();
   PrintHeartbeatIfNeeded();
}

void OnDeinit(const int reason)
{
   EventKillTimer();
}

OnTimerに分けても、処理量が多すぎれば重くなります。周期、処理対象、ログ量、Object更新量を管理してください。

外部連携と長時間稼働

WebRequest、通知、Google Sheets連携、外部認証、外部制御などを含むEAでは、長時間稼働時の確認項目が増えます。通信失敗、stale、設定不備、通知失敗、外部側の応答変化などを、本体処理と分けて扱う必要があります。

外部連携では、Webhook URL、GAS URL、APIキー、認証トークン、口座番号、個人情報などの実値をログや画面に出さないようにします。ログには、状態分類、成功/失敗、reason、最終取得時刻、stale判定などを出します。

外部連携の長時間稼働確認表

VPSで長時間動かす時の確認

VPSでEAやインジケーターを長時間動かす場合、MQL5コードだけでなく、MT5本体、VPSのリソース、同時稼働チャート数、ログ量、通信状態、Windows更新、再起動履歴なども確認対象になります。

VPS環境では、画面を常に見ていない時間が長くなります。そのため、Expertsログ、Journalログ、定期summary、SNAP、スクリーンショット、発生時刻の記録が重要です。

VPS長時間稼働チェック表

VPSで確認しやすいログ

フリーズ・ブラックアウト時の確認

チャートが固まる、黒くなる、パネルが消える、時間足変更で戻る、EA削除時に不安定になる、といった症状では、発生時刻と直前ログが重要です。

フリーズやブラックアウトは、Object更新、描画負荷、OnDeinit cleanup、外部連携、ログ過多、他インジケーターとの競合、VPSリソースなど、複数原因が関係する場合があります。

フリーズ時の確認表

時間足変更で戻る場合

時間足変更で表示が戻る場合、パネル再配置、Object再作成、ChartRedraw、OnChartEvent、OnTimerメンテナンス、Object欠損チェックが関係している可能性があります。表示だけの問題なのか、EA内部状態も止まっているのかを分けて確認します。

販売後サポートで必要なログ

販売後サポートや不具合調査では、画面上の状態だけでは判断しにくいことがあります。長時間稼働の問題では、INIT、TIMER、STATE_CHANGE、OBJECT_AUDIT、HANDLE、DEINIT、SNAPのようなログがあると、原因の切り分けに役立ちます。

問い合わせ前情報表

SNAPログに入れるとよい項目

安定化チェック表

長時間稼働前には、以下の観点で確認すると、後から問題を切り分けやすくなります。すべてを一度に完璧にするのではなく、対象EAやインジケーターの機能に応じて必要項目を確認します。

長時間稼働チェック表

次に読む技術講座

この講座とあわせて確認すると、MT5・MQL5開発、検証、不具合調査の流れを整理しやすくなります。

次に確認するページ

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

よくある質問

EAが重い時は何を確認しますか？

OnTick内の処理量、ログ出力頻度、Object更新回数、indicator handle作成回数、CopyBufferやCopyRatesの回数、外部連携処理、同時稼働チャート数を確認します。

ログを出しすぎると問題になりますか？

問題になる場合があります。同じログが大量に出ると、必要な情報が埋もれ、バックテストや長時間稼働時の確認もしづらくなります。状態変化時ログ、summary、debug切替に分けると確認しやすくなります。

IndicatorReleaseは必ず必要ですか？

indicator handleを作成している場合は、不要になったタイミングで解放する設計が重要です。ただし、毎tickで作成・解放するのではなく、必要なhandleを作成して再利用する設計が基本です。

OnDeinitで全Objectを削除してよいですか？

常に全削除すればよいとは限りません。OnDeinitでは軽量終了処理を優先し、Object削除はprefixや用途で対象を限定します。手動Objectや他EAのObjectを巻き込まないようにします。

VPSで長時間動かす時の注意点は何ですか？

MT5の起動状態、EA稼働状態、ログ量、同時稼働チャート数、CPU・メモリ、通信状態、外部連携状態、スクリーンショット、再起動履歴を確認します。

チャートがフリーズした時は何を送ればよいですか？

EA名、バージョン、setファイル、対象銘柄、時間足、発生時刻、Expertsログ、Journalログ、スクリーンショット、再現手順、同じチャートに入れているEAやインジケーターの情報を整理してください。

OnTimerに分けると安定しますか？

OnTimerへ分けるだけで必ず安定するわけではありません。ただし、tickごとに実行する必要がない処理を分離することで、OnTickの負荷を下げ、ログや外部連携の管理をしやすくできます。

外部連携EAは長時間稼働で注意が必要ですか？

注意が必要です。通信失敗、stale、通知失敗、外部応答の変化、機密値のログ出力、queue滞留などを確認します。外部連携の失敗理由は、本体処理と分けてログ化します。

Objectが残るのは不具合ですか？

仕様によります。表示専用ラインや履歴確認用Objectを残す設計もあります。ただし、再セット時に古いObjectを実ロジックへ無条件で使わないことが重要です。

時間足変更で表示が戻る場合、何が原因ですか？

パネル再配置、Object再作成、ChartRedraw、OnChartEvent、OnTimerメンテナンス、Object欠損チェックが関係している場合があります。表示だけの問題か、内部処理も止まっているかを分けて確認します。

まとめ

MQL5のEAやインジケーターを長時間安定して動かすには、OnTickに処理を詰め込みすぎないこと、indicator handleを適切に作成・再利用・解放すること、ログを状態変化時やsummaryへ整理すること、Objectを差分更新すること、OnDeinitで重いcleanupを避けることが重要です。

外部連携や通知を含むEAでは、通信失敗、stale、通知queue、機密値の扱いも確認対象になります。VPSで長時間動かす場合は、EA単体だけでなく、MT5本体、チャート数、ログ量、CPU・メモリ、通信状態、スクリーンショット、再起動履歴も整理してください。

学習内容を確認しても整理が難しい場合は、EA名、バージョン、setファイル、Expertsログ、Journalログ、発生時刻、スクリーンショットを整理したうえで相談してください。