MQL5 EA設計パターン完全ガイド｜signal・execution・risk・exitの責務分離

MQL5でEAを開発する時は、エントリー条件だけを作ればよいわけではありません。

EAには、条件判定、注文処理、リスク確認、決済処理、認証、外部制御、通知、画面表示、ログ出力、バックテスト確認など、複数の責務があります。

これらを1つの巨大なロジックにまとめてしまうと、どこで判定され、どこで注文され、どこで停止し、どこで通知されたのかが分かりにくくなります。結果として、検証、改修、販売後サポート、不具合調査が難しくなります。

この記事では、MQL5 EAを長期保守しやすくするために、signal、execution、risk、exit、auth、external control、notification、UI / panelを分けて考える設計パターンを整理します。

このページは、MT5 / MQL5の技術学習記事です。投資判断、売買タイミング、利益保証、勝率保証、推奨ロット、推奨銘柄、推奨エントリー、特定ブローカー誘導を目的とした内容ではありません。

MQL5 EAを設計パターンで考える理由

EA開発では、最初に「どんな条件でエントリーするか」に目が行きやすくなります。

しかし、実務上のEAは、エントリー条件だけで成立するものではありません。注文できる状態か、ロットが正しいか、同じポジションを重複して持たないか、損切りや決済条件をどう扱うか、外部制御や通知をどう扱うかまで確認する必要があります。

EAを設計パターンで整理すると、仕様変更や不具合確認の時に、どの層を見ればよいかが明確になります。

1枚の巨大ロジックにしない理由

EAの処理を1つの大きな関数や1つの条件式にまとめると、最初は分かりやすく見える場合があります。

しかし、機能追加が進むと、エントリー条件、時間制御、スプレッド制御、ポジション数制御、外部停止、通知、ログ、決済処理が混ざり、原因切り分けが難しくなります。

巨大ロジックを避ける目的は、コードを細かく分けること自体ではありません。検証、改修、サポート時に、責務とログを追いやすくすることです。

signal / execution / risk / exitの全体像

EAの中心になるのは、signal、execution、risk、exitの4層です。

signalは「候補を出す層」、executionは「注文を出す層」、riskは「許可・停止・制限を見る層」、exitは「保有後の終了条件を管理する層」です。

signalが成立しても、riskで止まることがあります。riskが許可しても、executionで注文が失敗することがあります。ポジションを保有した後は、signalではなくexitが中心になります。

GATE / SCORE / SPECIAL FILTERS / ENTRYの考え方

signal層を整理する時は、GATE、SCORE、SPECIAL FILTERS、ENTRYを分けると確認しやすくなります。

GATEは通過条件、SCOREは評価点、SPECIAL FILTERSは例外的な除外条件、ENTRYは最終的なエントリー候補です。

GATEで止まった場合は、SCOREを計算しない設計にすることがあります。SCOREが高くても、SPECIAL FILTERSで止まることがあります。

このように分けると、「条件は良かったのになぜ入らなかったのか」をログで追いやすくなります。

TREND / REVERSE / RANGEの役割差

EAのsignal設計では、TREND、REVERSE、RANGEを同じ条件として扱わないことが重要です。

それぞれのモードは、見ている相場状態、判定条件、見送り理由、exitとの関係が異なります。

TREND、REVERSE、RANGEを分ける目的は、どれが有利かを決めることではありません。EAの判定構造を整理し、検証時にどのモードが何を判定したかを追えるようにするためです。

signal層で扱うこと

signal層は、エントリー候補を作る層です。

ここでは、価格、インジケーター値、時刻、ローソク足、スコア、GATE、フィルターなどを確認します。ただし、注文処理は行いません。

signal層の出力は、BUY候補、SELL候補、NO ENTRY、見送り理由などにします。

signal層が注文まで行ってしまうと、後からriskやexecutionの失敗と混ざるため、検証が難しくなります。

execution層で扱うこと

execution層は、注文、決済、変更リクエストを実際に処理する層です。

signalがBUY候補を出したとしても、executionが必ず注文を成功させるとは限りません。取引サーバー、ロット条件、価格条件、自動売買許可、接続状態などで失敗することがあります。

execution層では、成功時だけでなく失敗時のログが重要です。

注文関連エラーやretcodeの確認は、MQL5エラーコード辞典も参考にしてください。

risk層で扱うこと

risk層は、EAの新規処理や運用制限を確認する層です。

ここで重要なのは、risk層を「必ず損失を防ぐ仕組み」と誤解しないことです。risk層は、ロット、ポジション数、証拠金、外部停止、日次制限などを確認し、EAの動作条件を整理するための層です。

risk層で新規エントリーを止める場合でも、既存ポジションのexitや保護処理は継続する設計が必要になることがあります。

exit層で扱うこと

exit層は、保有ポジションをどう終了するかを管理する層です。

エントリー条件と決済条件は別責務です。エントリー条件が出なくなったから決済するのか、別の決済条件で終了するのかを仕様として明確にします。

exit層は、保有後に常時確認されることが多い層です。新規エントリーが停止されている状態でも、exit層を止めるべきかどうかは慎重に設計します。

auth層で扱うこと

auth層は、EAの利用許可や認証状態を確認する層です。

販売用や配布用のEAでは、ライセンス、口座番号、期限、外部認証などを扱う場合があります。

auth層は、signalやexecutionとは分けて確認します。認証失敗時に新規エントリーを止めるのか、表示だけ止めるのか、保有ポジションのexitを継続するのかを仕様化します。

external control層で扱うこと

external control層は、EAの外部制御を扱う層です。

外部CSV、Google Sheets、設定ファイル、WebRequest、管理用パネル、手動ボタンなどで、EAの動作を外部から制御する場合に関係します。

外部制御は便利ですが、読み込み失敗時の挙動を必ず決めておく必要があります。

外部連携や通知の安全管理は、MT5外部連携・通知セキュリティガイドも参考にしてください。

notification層で扱うこと

notification層は、EAの状態やイベントを利用者へ知らせる層です。

通知は、signal成立、注文成功、注文失敗、決済、エラー、外部連携失敗などに使われることがあります。

通知が届いたことと、注文が成功したことは別です。通知はnotification層、注文結果はexecution層で確認します。

UI / panel層で扱うこと

UI / panel層は、EAの状態をチャート上に表示する層です。

パネル、ボタン、ラベル、ライン、ステータス表示などは、利用者にとって便利ですが、判定ロジックと混ぜると不具合調査が難しくなります。

UI層の不具合でEA本体が止まらないように、表示系と判定系は分けて設計します。

input初期値とruntime状態を分ける

EA設計で混同しやすいものに、input初期値とruntime状態があります。

inputはEAを起動する時の設定値です。runtime状態は、EA稼働中に変わる内部状態やボタン操作後の状態です。

input初期値とruntime状態を混同すると、ユーザーが「設定を変えていないのに動作が変わった」と感じる原因になります。

ログファースト設計

ログファースト設計とは、動作確認や不具合調査で必要な情報を、最初からログで追えるように設計する考え方です。

EAでは、動かなかった時に「条件が未成立だったのか」「riskで止まったのか」「注文で失敗したのか」「通知だけ失敗したのか」を分けて確認できる必要があります。

ログを出しすぎると確認しにくくなるため、通常運用、検証、バックテストでログ量を切り替えられる設計が有効です。

AdminDevとUserLiveの違い

EA開発では、開発者向けのAdminDev版と、利用者向けのUserLive版を分けて考えることがあります。

AdminDevは検証や設定確認をしやすくするための版です。UserLiveは実際の利用者向けに、不要な開発用設定を見せすぎないように整理した版です。

AdminDevとUserLiveを分ける目的は、機能差を作ることではなく、検証しやすさと利用しやすさを両立することです。

BTとLIVEの責務分離

BTはバックテスト、LIVEはリアルタイム環境での確認です。

同じEAでも、BTとLIVEでは、価格データ、spread、約定、外部連携、通知、時刻、ログ量の扱いが変わる場合があります。

バックテスト結果は将来の結果を保証するものではありません。BTでは、条件、分岐、ログ、注文処理の再現性を確認することが重要です。

表示系と判定系を分ける

EAでは、チャート表示やパネル表示を行うことがあります。

ただし、表示されている情報と内部で判定している値は分けて確認する必要があります。

表示系だけを見て「条件が成立した」と判断すると、内部判定とズレる場合があります。EAの検証では、表示、ログ、注文履歴を合わせて確認します。

関連ログ・関連エラー

責務分離したEAでは、エラーや不具合も層ごとに確認します。

エラーコードの確認は、MQL5エラーコード辞典も参考にしてください。

EA利用者向けの確認ポイント

EA利用者は、コードの詳細を理解していなくても、どの層で止まっているかを整理できます。

• 条件が成立していないのか
• 条件は成立したが新規エントリーが停止されたのか
• 注文処理で失敗したのか
• 保有後の決済条件が未成立なのか
• 通知だけが届いていないのか
• 認証や外部制御で停止しているのか
• 表示だけが更新されていないのか

問い合わせ前には、チャート画像だけでなく、Expertsログ、Journalログ、setファイル、発生時刻、銘柄名、時間足を整理してください。

MQL5開発者向けの確認ポイント

MQL5開発者は、各層の入力、出力、ログを決めてから実装すると、保守しやすくなります。

MQL5関数の役割は、MQL5関数辞書も参考になります。

検証担当者向けの確認ポイント

検証担当者は、EAの動作結果だけでなく、どの層のログがどう出ているかを確認します。

• INITログで環境と設定が確認できるか
• GATEで止まった理由が分かるか
• SCOREの内訳が確認できるか
• riskで停止した理由が確認できるか
• executionのretcodeが確認できるか
• exitの決済理由が確認できるか
• notificationの送信成否が分かるか
• BTとLIVEでログ量や分岐が整理されているか

検証環境の整理は、MT5検証・運用環境ガイドも参考にしてください。

よくある誤解

開発依頼前に仕様化する項目

EA開発や改修を相談する場合は、最初から関数名を指定するよりも、責務ごとに何をしたいかを整理する方が確認しやすくなります。

開発依頼前の資料整理は、MT5開発依頼前に用意する資料まとめも参考にしてください。

問い合わせ前に送る情報

MQL5 EA設計や改修について相談する場合は、次の情報を整理してください。

送ってはいけない情報

EA開発や改修相談では、ログやスクリーンショットが重要です。ただし、次の情報はそのまま送らないでください。

• 口座番号の全桁
• 投資家パスワード
• マスターパスワード
• Webhook URLの実値
• GAS URLの実値
• APIキー
• 認証トークン
• 外部サービスの秘密情報
• 個人情報
• 第三者の個人情報が入ったログ

問い合わせが必要な場合は、必要情報を整理したうえで、不具合報告・サポート依頼を確認してください。

MQL5 EA設計パターン確認チェック表

• □ signalとexecutionを分けて整理した
• □ riskとexitを分けて整理した
• □ GATE / SCORE / SPECIAL FILTERS / ENTRYを分けて確認した
• □ TREND / REVERSE / RANGEの役割差を確認した
• □ auth層の有無を確認した
• □ external control層の有無を確認した
• □ notification層の責務を確認した
• □ UI / panel層と判定系を分けた
• □ input初期値とruntime状態を分けた
• □ AdminDevとUserLiveの違いを整理した
• □ BTとLIVEの違いを整理した
• □ 各層のログを確認できるようにした
• □ setファイル、Expertsログ、Journalログを保存した
• □ 口座番号や認証情報をマスクした

次に読む技術講座

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

次に確認するページ

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

よくある質問

EA設計でsignalとexecutionを分ける理由は何ですか？

条件成立と注文実行を分けて確認するためです。signalはエントリー候補を出す層で、executionは注文や決済リクエストを処理する層です。分けておくと、条件は成立したのに注文できなかった理由を確認しやすくなります。

GATEとSCOREは何が違いますか？

GATEは必須通過条件、SCOREは条件の強さや一致度を評価する考え方です。GATEで止まった場合は、SCOREが高くてもENTRYへ進まない設計にすることがあります。

risk層とexit層は分ける必要がありますか？

分けた方が確認しやすくなります。risk層は主に新規許可や制限を確認し、exit層は保有後の決済やトレールを管理します。新規停止中でも既存ポジションのexitを継続する場合があります。

外部制御や通知はEA本体に直接入れてよいですか？

機能として入れることはありますが、責務としては分けて設計する方が安全です。外部制御はexternal control層、通知はnotification層として扱うと、不具合調査がしやすくなります。

AdminDevとUserLiveは何が違いますか？

AdminDevは開発・検証・ログ確認をしやすくする版、UserLiveは利用者向けに必要項目を整理した版です。検証用設定や詳細ログをそのまま利用者向けに出しすぎないことが重要です。

BTとLIVEは同じ設計でよいですか？

基本ロジックは同じでも、価格データ、spread、外部連携、通知、ログ量などは分けて確認する必要があります。バックテスト結果は将来の結果を保証するものではありません。

UIパネルの表示とEA内部状態は同じですか？

同じとは限りません。UIは表示層であり、内部の判定状態とは別に管理する必要があります。検証では、パネル表示、Expertsログ、注文履歴を合わせて確認してください。

ログは多いほどよいですか？

多ければよいわけではありません。INIT、GATE、SCORE、RISK、EXECUTION、EXIT、NOTIFYなど、目的別に必要なログを出し、通常運用と検証時でログ量を切り替えられる設計が有効です。

開発依頼前にどこまで仕様を決めるべきですか？

最低限、signal、execution、risk、exit、notification、UIのどこを作りたいのかを整理してください。EA名、対象銘柄、時間足、setファイル、ログ、スクリーンショットもあると確認しやすくなります。

GATE / SCORE / SPECIAL FILTERSは必ず必要ですか？

すべてのEAで必須ではありません。ただし、条件が複数あるEAでは、通過条件、点数化、例外フィルター、最終ENTRYを分けると、検証やログ確認がしやすくなります。

まとめ

MQL5 EAを長期的に保守しやすくするには、signal、execution、risk、exit、auth、external control、notification、UI / panelを分けて設計することが重要です。

signalは候補を出す層、executionは注文・決済を処理する層、riskは許可や制限を確認する層、exitは保有後の終了条件を管理する層です。

GATE / SCORE / SPECIAL FILTERS / ENTRYを分けると、条件が成立したのか、どこで止まったのか、なぜ見送ったのかをログで追いやすくなります。

AdminDevとUserLive、BTとLIVE、input初期値とruntime状態、表示系と判定系を分けることで、検証、改修、販売後サポートの負担を減らしやすくなります。

EA開発や改修を相談する場合は、EA名、バージョン、対象銘柄、時間足、setファイル、Expertsログ、Journalログ、スクリーンショットを整理し、口座番号や認証情報は必ずマスクしてください。

MT4/MT5 技術講座へ戻る