EAに通知機能を追加したい時に整理すること|Discord・メール・LINE・ログ出力

EAファンクラブ

EAを運用していると、「エントリーや決済をDiscordへ通知したい」「エラーが出た時にメールで知りたい」「稼働状態や停止理由をログにも残したい」と考えることがあります。

通知機能は便利ですが、単に「通知を付けたい」だけでは仕様が不足する場合があります。何を通知するのか、いつ通知するのか、どこへ送るのか、同じ通知を何度も送らないか、送信失敗時にどう記録するかを分けて整理する必要があります。

また、Discord、メール、LINEなどの外部サービスを使う場合は、送信方式、認証情報、送信頻度、サービス仕様、MT4/MT5側の設定、WebRequest許可、エラー時のログ確認も重要です。

特に、外部サービスは仕様変更や提供状況の変更が起きる場合があります。LINE連携についても、現在利用できる方式を確認したうえで、通知方法を検討する必要があります。

この記事では、EAに通知機能を追加したい時に、開発依頼前に整理したい通知タイミング、通知内容、通知先、Discord、メール、LINE連携、WebRequest、ログ出力、送信失敗時の確認項目をまとめます。

なお、この記事はEA改修や開発依頼前の技術確認を目的とした内容です。通知内容を使った売買指示、推奨エントリー、推奨決済、利益保証を行うものではありません。

この記事で確認すること

確認項目内容依頼前の確認ポイント
通知タイミングいつ通知するかです。エントリー、決済、エラー、停止、起動、認証などを分けます。
通知内容通知メッセージに含める情報です。銘柄、方向、ロット、価格、理由、エラー内容を整理します。
通知先Discord、メール、LINE連携、ログなどです。どの方式を使うか、複数送信するかを確認します。
WebRequest外部URLへHTTP送信する仕組みです。MT5側の許可URL、送信先、タイムアウトを確認します。
送信頻度通知の連投を防ぐ条件です。同一イベントの重複通知、送信間隔、上限を確認します。
失敗時ログ通知に失敗した時の記録です。HTTP結果、エラーコード、再試行有無を確認します。

EAの通知機能とは

EAの通知機能とは、EAの状態や取引イベントを、チャート上だけでなく外部の通知先やログへ送る機能です。

通知対象には、エントリー、決済、注文失敗、SL/TP変更、建値移動、トレーリング、認証結果、WebRequestエラー、稼働開始、稼働停止、スプレッドブロック、時間帯ブロックなどがあります。

通知対象内容確認すること
エントリー通知新規注文が出た時の通知です。BUY / SELL、ロット、価格、Magic Numberを含めるか確認します。
決済通知ポジションを閉じた時の通知です。決済理由、損益、チケット、close_reasonを確認します。
エラー通知注文失敗や外部送信失敗の通知です。retcode、GetLastError、HTTP結果を確認します。
起動通知EA起動時や初期化完了時の通知です。口座、銘柄、時間足、設定状態を含めるか確認します。
停止通知EA停止や条件ブロック時の通知です。停止理由、時間帯、スプレッド、認証状態を確認します。
ログ出力通知とは別にExpertsログへ記録します。通知成功・失敗を後から確認できるようにします。

依頼前には、通知したいイベントを一覧にし、「必ず通知するもの」と「必要な時だけ通知するもの」を分けて整理してください。

通知先を整理する

通知機能を追加する場合は、どこへ通知するかを先に決める必要があります。

通知先によって、実装方法、必要な設定、送信形式、認証情報、失敗時の確認方法が変わります。

通知先主な用途依頼前の確認ポイント
DiscordEAの稼働状態、注文、決済、エラーをチャンネルへ通知します。Webhook URL、送信先チャンネル、通知形式を確認します。
メール重要イベントやエラーをメールで受け取ります。MT5側のメール設定、送信先、件名、本文を確認します。
LINE連携LINE側で通知を受け取りたい場合に検討します。現在利用できる方式、認証、送信条件を確認します。
ExpertsログEA側の動作記録として残します。通知成功、通知失敗、送信内容を確認できるようにします。
ファイル出力CSVやテキストへ通知履歴を残します。保存場所、ファイル名、蓄積上限、削除ルールを確認します。
Google Sheetsなど運用記録や集計に使います。API仕様、認証、送信頻度、失敗時処理を確認します。

複数の通知先を使う場合は、すべてに同じ内容を送るのか、通知先ごとに内容を変えるのかも整理してください。

通知タイミングを整理する

通知機能では、いつ通知するかが重要です。

通知タイミングが曖昧だと、同じイベントが何度も通知されたり、重要なエラーだけ通知されなかったりする場合があります。

通知タイミング内容依頼前の注意点
EA起動時OnInitや初期化完了時に通知します。毎回通知するか、エラー時のみ通知するか確認します。
認証結果ライセンス認証や口座確認の結果を通知します。成功も通知するか、失敗だけ通知するか確認します。
エントリー時新規注文が成功した時に通知します。注文送信時か約定後かを確認します。
決済時ポジション決済時に通知します。TP、SL、手動、内部決済など理由を含めるか確認します。
SL/TP変更時建値移動やトレーリング更新時に通知します。更新のたびに通知するか、初回だけにするか確認します。
エラー発生時注文失敗、WebRequest失敗、認証失敗などを通知します。同じエラーの連投を防ぐ条件を確認します。
停止条件成立時時間停止、スプレッド停止、証拠金停止などを通知します。毎Tick通知にならないよう制御します。

通知タイミングは、OnTickごとに送るのではなく、状態変化やイベント発生時に送る設計にすると整理しやすくなります。

通知内容を整理する

通知内容は、あとから見返した時に何が起きたか分かるように整理します。

ただし、通知文に情報を詰め込みすぎると読みづらくなります。通知先ごとに、必要な項目を分けて考えます。

通知項目内容
EA名・バージョンどのEAからの通知かを識別します。EA名、version
口座情報デモ・リアルや口座識別に使います。口座番号は必要に応じてマスクします。
銘柄・時間足どのチャートで発生したかを示します。GOLD、USDJPY、M15など
注文方向BUY / SELLを示します。BUY、SELL
ロット注文数量です。0.10 lotなど
価格約定価格、SL、TPなどです。entry_price、sl、tp
理由通知の発生理由です。ENTRY_OK、CLOSE_TP、SPREAD_BLOCKなど
エラー内容失敗時の詳細です。retcode、GetLastError、HTTP code
時刻サーバー時間やPC時間です。server_time、local_time

口座番号、トークン、Webhook URL、APIキーなどの機密情報は、通知文や公開ログにそのまま出さないように注意してください。

Discord通知を追加したい場合

Discord通知では、指定したチャンネルへEAの状態やイベントを送る設計がよく使われます。

Discordへ通知する場合は、Webhook URL、通知先チャンネル、メッセージ形式、送信頻度、失敗時ログを整理します。

確認項目内容依頼前の注意点
Webhook URLDiscordへ送信するためのURLです。公開場所に貼らず、取り扱いに注意します。
送信先チャンネル通知を受け取るDiscordチャンネルです。テスト用と本番用を分けるか確認します。
通知形式通常テキスト、整形メッセージなどです。読みやすさと情報量のバランスを確認します。
送信頻度通知を送る間隔や上限です。同一通知の連投を防ぐ設計が必要です。
失敗時処理送信に失敗した時の扱いです。HTTPコード、エラー内容、再試行有無をログに残します。
テスト通知設定確認用の通知です。EA起動時やボタン操作で送るか確認します。

Discord通知は、送信頻度が多すぎると確認しづらくなったり、外部サービス側の制限にかかったりする場合があります。依頼前に、どのイベントだけ通知するかを整理してください。

メール通知を追加したい場合

メール通知は、重要なイベントやエラーをメールで受け取りたい場合に検討します。

MT4/MT5側のメール設定を使う場合は、送信先、件名、本文、送信タイミング、送信失敗時の確認方法を整理します。

確認項目内容依頼前の注意点
送信先メール通知を受け取るメールアドレスです。公開場所に記載しないよう注意します。
件名メールタイトルです。EA名、銘柄、イベント種別を含めるか確認します。
本文通知内容です。注文情報、エラー理由、時刻を含めるか確認します。
送信タイミングいつメールを送るかです。エラー時だけか、通常イベントも送るか確認します。
送信テストメール設定が有効か確認します。EA側だけでなくMT5側設定も確認します。
送信失敗ログメール送信失敗時の記録です。JournalログやExpertsログで確認します。

メール通知は、重要なエラーや停止通知には向いていますが、頻繁なエントリー通知や細かい状態通知をすべて送ると確認が難しくなる場合があります。

LINE連携を検討する場合

LINEでEA通知を受け取りたい場合は、現在利用できる通知方式を確認する必要があります。

LINE系の通知サービスは、提供状況やAPI仕様が変わる場合があります。そのため、古いトークン方式や過去の通知サービスを前提にせず、現行の利用可能な方式、認証、送信条件、費用、利用規約を確認してから仕様を決めることが重要です。

確認項目内容依頼前の注意点
利用方式現在利用できるLINE連携方式です。古い方式が使える前提にしないよう確認します。
認証情報送信に必要なトークンや設定です。公開場所に貼らず、取り扱いに注意します。
送信先個人、グループ、公式アカウントなどです。方式によって送信先の扱いが異なります。
送信内容EA名、銘柄、イベント、エラー内容などです。情報量を整理します。
送信頻度通知間隔や上限です。連投防止と失敗時ログを設計します。
代替手段Discord、メール、ログ出力などです。LINE連携が難しい場合の選択肢を確認します。

LINE連携は、外部サービス仕様の確認が必要なため、依頼時点で利用可能な方式を確認したうえで、代替通知先もあわせて整理しておくと安全です。

WebRequestを使う場合に確認すること

Discord通知や外部API連携では、MT5のWebRequestを使う場合があります。

WebRequestを使う場合は、EA側の実装だけでなく、MT5側で送信先URLを許可する設定が必要になることがあります。また、送信先URL、タイムアウト、HTTP結果、失敗時ログを確認できるようにしておくことが重要です。

確認項目内容依頼前の注意点
許可URLMT5側でWebRequestを許可する送信先です。送信先ドメインを正しく登録する必要があります。
送信方式GET、POST、JSONなどの送信形式です。通知先サービスの仕様に合わせます。
タイムアウト外部通信の待ち時間です。長すぎるとEA動作に影響する場合があります。
HTTP結果送信成功・失敗の結果です。ステータスコードやレスポンスをログに残します。
失敗時処理送信できなかった時の動作です。再試行、スキップ、ログのみなどを決めます。
機密情報Webhook URLやトークンです。ログや画面表示にそのまま出さないようにします。

通知機能は、取引判断そのものとは別の外部連携機能です。通信失敗が発生しても、EA本体の売買処理や決済処理にどう影響させるかは慎重に決める必要があります。

通知頻度と重複通知を整理する

通知機能では、通知が多すぎると確認しづらくなります。

特にOnTickで条件を確認するEAでは、同じ条件が続いている間に同じ通知を何度も送ってしまう場合があります。そのため、通知済みフラグ、送信間隔、状態変化時のみ通知などの制御が必要です。

制御項目内容依頼前の確認ポイント
通知済みフラグ同じイベントを何度も送らないための管理です。イベント単位、チケット単位、状態単位で管理するか確認します。
送信間隔一定時間内の連投を防ぎます。秒、分、イベント単位で制限します。
状態変化通知状態が変わった時だけ送ります。正常から異常、停止から再開などを整理します。
エラー通知抑制同じエラーの連続通知を防ぎます。初回だけか、一定間隔ごとかを確認します。
重要度分類通知内容を重要度で分けます。通常通知、警告、エラー、緊急を分けます。
通知先分岐内容ごとに送信先を変えます。エラーだけメール、通常はDiscordなどを検討します。

依頼前には、「全部通知する」のではなく、どの通知を必須にするか、どの通知はログだけでよいかを整理してください。

ログ出力もあわせて整理する

通知機能を追加する場合は、通知そのものだけでなく、ログ出力も重要です。

通知が届かなかった時に、EA側で送信しなかったのか、送信したが外部サービス側で失敗したのか、WebRequestが許可されていなかったのかを切り分けられるようにします。

ログ項目確認内容
notify_check通知判定を行ったか確認します。notify_check=Y
notify_event通知対象イベントを確認します。ENTRY、CLOSE、ERROR、INIT
notify_target通知先を確認します。DISCORD、MAIL、LINE、LOG
notify_message通知文の概要を確認します。機密情報はマスクします。
send_result送信成功・失敗を確認します。success、fail、skip
http_status外部送信の結果を確認します。200、204、400、401、429など
error_detail失敗理由を確認します。webrequest_not_allowed、timeout、rate_limitなど
throttle_state連投防止で見送ったか確認します。throttle_skip、duplicate_skip

通知ログには、Webhook URLやトークンなどの機密情報をそのまま出さず、必要に応じてマスクする設計が必要です。

通知失敗時の扱いを決める

外部通知は、通信状況、サービス側の制限、設定ミス、認証情報の誤りなどで失敗する場合があります。

通知失敗時に、EAの売買処理を止めるのか、通知だけ失敗としてログに残すのかは、あらかじめ決めておく必要があります。

失敗時の扱い内容依頼前の確認ポイント
ログのみ通知失敗をログに残し、EA本体は継続します。通常は外部通知と売買処理を分離しやすい方式です。
再試行一定回数だけ再送します。連投や処理遅延に注意します。
次回にまとめる失敗した通知を後でまとめます。必要性と実装範囲を確認します。
通知停止連続失敗時に通知だけ停止します。復帰条件を決めておきます。
EA停止通知失敗でEA自体を止めます。取引処理への影響が大きいため慎重に判断します。
画面表示チャート上に通知異常を表示します。ユーザーが気付きやすい反面、表示管理が必要です。

通知機能は、EA本体のsignal、execution、risk、exitとは分けて扱うと、保守や不具合切り分けがしやすくなります。

テスト通知と本番通知を分ける

通知機能を追加する場合は、テスト通知と本番通知を分けて確認できるようにすると安全です。

たとえば、EA起動時にテスト通知を送る、設定画面で通知テストを有効にする、検証用チャンネルへ送る、本番用Webhookと検証用Webhookを分ける、といった方法があります。

テスト項目内容確認すること
起動時テストEA起動時にテスト通知を送ります。毎回送るか、設定ON時だけ送るか確認します。
手動テストボタンや入力設定でテスト通知を送ります。本番通知と区別できる文面にします。
検証用送信先テスト用チャンネルやメールへ送ります。本番環境へ誤通知しないようにします。
失敗テストURL未許可やトークン誤りで失敗ログを確認します。失敗時ログが出るか確認します。
連投テスト短時間に複数イベントが起きた時の挙動を確認します。重複通知やレート制限を確認します。
復旧テスト一度失敗した後に復旧できるか確認します。通知停止状態から戻る条件を確認します。

依頼前に用意するとよい資料

通知機能追加を依頼する場合は、EA本体だけでなく、通知したいイベント、通知内容、通知先、外部サービス設定、ログ確認項目を整理します。

資料内容注意点
現在のソースコードmq5、mqhなどのソース一式です。ex5だけでは直接改修できない場合があります。
通知したいイベント一覧エントリー、決済、エラー、起動、停止などです。必須通知と任意通知を分けます。
通知文サンプル実際に受け取りたいメッセージ例です。機密情報を含めないよう注意します。
通知先情報Discord、メール、LINE連携などです。Webhook URLやトークンは安全に扱います。
MT5設定WebRequest許可URLやメール設定です。送信先URLや設定画面を確認します。
送信頻度ルール連投防止、送信間隔、重複通知防止です。OnTickごとの連続送信を避けます。
失敗時の扱いログのみ、再試行、通知停止などです。EA本体処理との関係を確認します。
検証条件デモ口座、テスト用チャンネル、テスト用setなどです。本番通知と混同しないようにします。

依頼前チェック表

チェック項目確認内容
通知したいイベントを整理したエントリー、決済、エラー、起動、停止などを分けます。
通知先を決めたDiscord、メール、LINE連携、ログ出力などを整理します。
通知文サンプルを用意したEA名、銘柄、方向、ロット、理由、時刻などを整理します。
機密情報の扱いを確認したWebhook URL、APIキー、トークン、口座情報を公開しないようにします。
WebRequest設定を確認したMT5側の許可URL、送信先、タイムアウトを確認します。
メール設定を確認したMT5側のメール送信設定や送信先を確認します。
LINE連携の現行仕様を確認した現在利用できる方式、認証、送信条件を確認します。
通知頻度を整理した連投防止、通知済みフラグ、送信間隔を確認します。
失敗時処理を決めたログのみ、再試行、通知停止、EA停止の有無を整理します。
テスト通知の方法を決めた起動時テスト、手動テスト、検証用送信先を確認します。
ログで確認したい項目を整理したnotify_event、send_result、http_status、error_detailを確認します。
ソースコードの有無を確認したmq5、mqhがあるかを確認します。

FAQ

EAにDiscord通知を追加できますか?

ソースコードがあり、外部送信が可能な設計であれば相談できます。Webhook URL、通知イベント、通知文、WebRequest設定、送信頻度、失敗時ログを整理してください。

メール通知とDiscord通知はどちらがよいですか?

用途によって異なります。頻繁な状態通知はDiscord、重要なエラー通知はメールなど、通知内容ごとに分けて設計する場合があります。

LINE通知を追加できますか?

LINE連携は、現在利用できる方式や外部サービス仕様を確認したうえで検討します。古い通知方式が使える前提にせず、代替通知先も含めて整理してください。

通知が届かない時は何を確認しますか?

WebRequest許可URL、Webhook URL、トークン、メール設定、外部サービス側の制限、Expertsログ、Journalログ、HTTP結果、エラーコードを確認します。

通知失敗でEAを止めるべきですか?

通知機能と売買処理は分けて考えるのが基本です。通知失敗時にEAを止めるか、ログだけ残して継続するかは、依頼前に仕様として決める必要があります。

ex5ファイルだけでも通知機能を追加できますか?

ex5だけでは既存EAへ直接通知機能を追加できない場合があります。通常はmq5やmqhなどのソースコードが必要です。ソースがない場合は、補助EAや外部監視ツールとして検討する場合があります。

関連ページ

EAに通知機能を追加する時は、通知内容だけでなく、外部シート連携、ログ出力、パネル操作、見積依頼前の資料整理もあわせて確認すると、通知対象や失敗時処理を整理しやすくなります。

関連ページ確認ポイント
EA開発の見積依頼前に整理すること|仕様書・ログ・setファイル・検証条件通知機能追加を依頼する前に、仕様、ログ、検証条件、外部連携の有無を整理します。
EAに外部シート連携を追加したい時に整理すること|Google Sheets・CSV・WebRequestWebRequest、Google Sheets、CSVなど、通知以外の外部連携も含めて確認します。
EAのログ出力を増やしたい時に整理すること|Experts・Journal・CSV・通知通知成功、通知失敗、HTTP結果、エラー内容をログで追跡したい場合に確認します。
EAのパネル表示を改修したい時に整理すること|ボタン・表示位置・ログ・誤操作防止パネル操作、ボタン押下、エラー状態を通知対象に含める場合に確認します。

まとめ

EAに通知機能を追加したい場合は、通知先だけでなく、通知タイミング、通知内容、送信頻度、失敗時処理、ログ出力を分けて整理することが重要です。

Discord、メール、LINE連携などは、それぞれ必要な設定、認証情報、送信形式、外部サービス仕様が異なります。特にLINE連携は、現在利用できる方式を確認したうえで検討してください。

WebRequestを使う通知では、MT5側の許可URL、送信先、タイムアウト、HTTP結果、失敗時ログを確認できるようにしておく必要があります。

また、通知機能はEA本体のsignal、execution、risk、exitとは分けて扱うと、保守や不具合切り分けがしやすくなります。依頼前には、通知イベント一覧、通知文サンプル、通知先、送信頻度、失敗時処理、ログ項目、テスト方法を整理してください。

ABOUT ME
記事URLをコピーしました