MQL5 WebRequest・JSON・外部API実装完全ガイド｜Discord通知・Google Sheets連携前に知ること

MQL5でEAやインジケーターから外部サービスへ通知・記録・状態送信を行う場合、WebRequest、JSON、HTTPステータス、外部API、Webhook、Google Apps Scriptなどの理解が必要になります。

Discord通知、Google Sheets連携、外部API連携、認証サーバー確認、稼働状態送信などは便利ですが、URL設定、GET / POST、header、body、timeout、HTTPステータス、MT5側の許可URL、APIキー管理、ログ設計を誤ると、通知が届かない、シートへ書き込まれない、4014や5203系のエラーが出る、原因が追えないといった問題につながります。

この記事では、MQL5のWebRequestを使った外部連携実装について、GET / POST、JSON、Discord Webhook、Google Apps Script、HTTPステータス、エラー確認、Strategy Testerでの注意点、送ってはいけない情報、問い合わせ前に整理する情報を実務向けに整理します。

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

この記事で扱う範囲

この記事で扱うのは、MQL5から外部サービスへ通信する時の技術確認です。

LEARN-004では、WebRequest、Webhook、APIキー、Google Sheets連携を安全に扱うための情報管理を中心に整理しました。この記事では、そこから一段進めて、実装構造、送受信形式、JSON、HTTP応答、エラー確認、ログ設計を扱います。

外部連携の情報管理やWebhook URLの扱いは、MT5外部連携・通知セキュリティガイドもあわせて確認してください。

MQL5 WebRequestとは

WebRequest()は許可URLの登録が必要で、直接呼び出せるのはEAとスクリプトです。インジケーターから直接呼び出すことはできず、Strategy Testerでも実行されません。外部APIの到達確認は通常チャートまたは検証用デモ環境で分けて行います。

WebRequestは、MQL5からHTTP通信を行うための関数です。

EAやスクリプトから外部APIへGETやPOSTを行い、外部サービスへ通知を送ったり、Webサーバーから設定情報を取得したり、Google Apps Scriptへデータを渡したりする時に使われます。

ただし、WebRequestは通常の計算処理やチャート表示処理とは違い、通信先URL、許可設定、timeout、HTTP応答、ネットワーク状態、外部サービス側の仕様に影響されます。そのため、実装時は通信層をsignalやexecutionから分離することが重要です。

外部連携は、EA本体の判定や注文処理と同じ場所へ直書きしない方が保守しやすくなります。signal、execution、risk、auth、external control、notificationの責務分離は、MQL5 EA設計パターン完全ガイドも参考になります。

MT5側の許可URL設定

MQL5でWebRequestを使うには、MT5側で通信先URLを許可する必要があります。

許可URLが登録されていない場合、EA側のコードが正しくても通信できないことがあります。通知が届かない、外部APIへ接続できない、Google Sheets連携が動かない場合は、まずMT5のWebRequest許可設定を確認してください。

MT5側のWebRequest設定確認は、MT5のWebRequest設定で確認することも参考になります。

GETとPOSTの違い

外部API連携では、GETとPOSTの違いを理解しておく必要があります。

GETは、主に情報取得や簡単な問い合わせに使われます。POSTは、JSONやフォームデータなどのbodyを送る時に使われることが多い方式です。Discord Webhook通知やGoogle Apps Scriptへの記録送信では、POSTを使う構成がよくあります。

GETとPOSTは、どちらが常に正しいというものではありません。連携先APIの仕様、送るデータ量、認証方法、ログ方針、機密情報の扱いに合わせて選びます。

header・body・timeoutの基本

WebRequestでは、HTTPメソッドだけでなく、header、body、timeout、応答データ、HTTPステータスを確認します。

JSONをPOSTする場合は、Content-Typeを意識し、送信bodyの文字列化、文字コード、応答内容、通信失敗時のエラーをログで追えるようにします。

string method = "POST";
string url = endpoint_url; // 実値はログへ出さない
string headers = "Content-Type: application/json\r\n";
int timeout_ms = 5000;

string json_body = "{\"event\":\"status\",\"result\":\"check\"}";

char post_data[];
StringToCharArray(json_body, post_data, 0, WHOLE_ARRAY, CP_UTF8);

char result[];
string result_headers = "";

ResetLastError();

int status = WebRequest(method,
                        url,
                        headers,
                        timeout_ms,
                        post_data,
                        result,
                        result_headers);

PrintFormat("DIAG/WEBREQUEST result status=%d bytes=%d last_error=%d",
            status,
            ArraySize(result),
            GetLastError());

上記はWebRequestの構造を示す最小例です。実運用のWebhook URL、APIキー、GAS URL、認証トークンなどは、本文やログに含めないでください。

JSONを扱う時の考え方

JSONは、外部APIへ構造化データを送る時によく使われます。

MQL5でJSONを扱う場合、送信したい情報を文字列として組み立て、必要に応じてエスケープ処理を行い、Content-Typeを指定してPOSTします。受信側が求めるキー名、型、必須項目、文字コード、改行、長さ制限を確認する必要があります。

JSON送信ログでは、payload全文をそのまま出すより、event名、送信先種別、bodyサイズ、必須項目の有無、HTTPステータスを残す方が安全です。

string BuildSafeStatusJson(const string event_name, const string result_text)
{
   string json = "{";
   json += "\"event\":\"" + event_name + "\",";
   json += "\"result\":\"" + result_text + "\"";
   json += "}";

   return json;
}

この例はJSON文字列を組み立てる考え方を示すものです。実装時は、送信値のエスケープ、文字コード、必須項目、長さ制限を連携先仕様に合わせて確認してください。

Discord Webhook通知の基本構造

Discord Webhook通知は、EAやインジケーターから外部チャンネルへ通知を送る構成で使われることがあります。

一般的には、Discord側でWebhook URLを作成し、MT5側でそのURLをWebRequest許可URLへ登録し、EA側からPOSTでJSONを送信する構造になります。ただし、Webhook URLは通知先へ直接送信できる重要情報です。本文、ログ、スクリーンショット、問い合わせ本文へ実値を含めないでください。

Discord通知は、signal判定や注文処理そのものではありません。通知が失敗しても売買本体を止めるのか、通知失敗だけをログに残すのかは、EA仕様として分けて考える必要があります。

Discord通知が届かない時の確認は、MT5でDiscord通知が届かない時の確認ポイントも参考になります。

Google Apps Script連携の基本構造

Google Sheets連携では、Google Apps ScriptをWebアプリとして公開し、MQL5からWebRequestでPOSTまたはGETを行い、スプレッドシートへデータを書き込む構成が使われることがあります。

この構成では、MT5側、EA側、Google Apps Script側、スプレッドシート側の4つを分けて確認します。どこか1か所でも設定がずれていると、送信できない、書き込めない、権限エラーになる、期待した行へ反映されないといった問題が起きます。

Google Sheets連携では、GAS URLや認証用tokenをログへそのまま出さないことが重要です。ログでは、送信先種別、HTTPステータス、応答サイズ、結果分類だけを残す設計にしてください。

Google Sheets連携の確認は、MT5でGoogle Sheets連携を確認する記事も参考になります。

HTTPステータスの見方

WebRequestの結果確認では、MQL5側のGetLastErrorだけでなく、HTTPステータスも確認します。

HTTPステータスは、外部サービス側がどのように応答したかを確認するための重要な情報です。通信自体ができていないのか、通信はできたが認証に失敗したのか、送信形式が不正なのか、外部サービス側でエラーが起きたのかを分けて考えます。

HTTPステータスだけで原因を断定せず、GetLastError、送信method、body概要、response概要、外部サービス側ログを合わせて確認してください。

4014 / 5203系エラーの確認

MQL5のWebRequestでは、4014や5203系のエラーが確認対象になることがあります。

4014系は、関数呼び出しが許可されていない、実行環境上の制約に該当する、といった観点で確認します。5203系は、WebRequestの実行やHTTPリクエスト失敗に関係する観点で確認します。実際の確認では、エラー番号だけでなく、MT5側許可URL、実行場所、通信先、HTTPステータス、Journalログをセットで確認してください。

エラーコードの意味を調べるだけでは不十分です。どの処理で、どのURL種別へ、どのmethodで、どのpayload概要を送り、どの応答が返ったのかをログで追えるようにしてください。

GetLastErrorやretcode確認の考え方は、MQL5エラーコード辞典も参考になります。

Strategy TesterとWebRequestの注意点

Strategy TesterでWebRequestを確認する場合は、リアル環境と同じように動くとは限らない点に注意が必要です。

バックテスト中は、外部通信を実行しない設計、送信をdry-runにする設計、送信内容だけをログに出す設計、テスター専用のmock応答を使う設計などを検討します。実通信を前提にすると、テスト速度、再現性、外部サービスへの連投、ログ肥大化の問題が出る場合があります。

バックテストでは、通知や外部書き込みがEA本体の判定検証を邪魔しないように、tester専用分岐、送信抑制、ログ要約を設計すると確認しやすくなります。

バックテスト条件の確認は、MT5ストラテジーテスター・最適化完全ガイドも参考になります。

APIキー・Webhook URLを公開しない

外部API連携で最も重要な注意点の1つが、APIキー、Webhook URL、GAS URL、認証トークンを公開しないことです。

これらは、外部サービスへ送信したり、データへアクセスしたりするための重要情報です。ログ、スクリーンショット、問い合わせ本文、記事本文、マニュアル、サンプルコードへ実値を含めないでください。

ログには、raw URLではなく、endpoint種別、マスク済み状態、送信成否、HTTPステータス、応答サイズ、エラー番号を出すようにしてください。

外部連携の送信情報と端末設定を点検する

MT5外部連携で最初に知っておくこと

外部連携とは

MT5の外部連携とは、EAやインジケーター、補助ツールがMT5の外側にあるサービスと情報をやり取りする仕組みです。

代表的な例として、Discord通知、Google Sheets記録、外部サーバーへの送信、外部設定の取得、認証確認、CSVやログファイルの出力などがあります。

外部連携を使う場合、MT5内の設定だけではなく、接続先URL、WebRequest許可、外部サービス側の権限、通知先、送信ログ、エラーコードなどを確認する必要があります。

通知・記録・設定取得の違い

外部連携には、主に通知、記録、設定取得があります。

通知が失敗しているのか、記録が失敗しているのか、外部設定の取得が失敗しているのかで、確認する場所は変わります。

売買ロジックと外部連携を分けて考える

EAの売買条件と、外部連携の成否は分けて確認する必要があります。

外部連携が失敗していても、EA本体の判定や表示は動いている場合があります。逆に、通知が成功していても、売買条件が成立しているとは限りません。

そのため、外部連携を使うEAや補助ツールでは、次のように責務を分けて確認します。

WebRequestの基本

WebRequestとは

WebRequestは、MQL5から外部URLへHTTP通信を行うために使われる仕組みです。

Discord通知、Google Sheets連携、外部認証、外部設定取得などでは、WebRequestを使ってMT5の外側にあるサービスへアクセスする場合があります。

WebRequestを使うEAや補助ツールでは、MT5側で許可URLを設定していないと、通信が失敗することがあります。

許可URLとは

MT5では、WebRequestでアクセスするURLを、あらかじめ許可リストへ登録する必要があります。

許可URLが未登録の場合、EAやインジケーター側で正しい設定をしていても、通信できないことがあります。

外部連携が動かない場合は、まずMT5のオプションでWebRequestの許可URLが設定されているか確認します。

許可URLとWebhook URLの違い

WebRequestの許可URLと、DiscordなどのWebhook URLは混同しやすい項目です。

許可URLは、MT5が外部通信を許可する接続先の登録情報です。Webhook URLは、通知や送信を受け付けるための具体的な送信先URLです。

問い合わせ時には、許可URLを設定したかどうか、設定欄の状態、エラーコード、ログは共有しても、Webhook URLやGAS URLの実値は送らないようにしてください。

VPS環境での確認

外部連携は、PCごと・MT5ごとに設定を確認する必要があります。

手元PCでWebRequestが動いていても、VPS側のMT5で同じ設定が入っているとは限りません。

VPSへ移行した後に通知やGoogle Sheets連携が動かない場合は、VPS側のMT5でWebRequest許可URL、EA設定、通知先、Filesフォルダ、Presetsフォルダ、Expertsログを確認してください。

Discord通知で扱う情報

Webhook URL

Discord通知では、Webhook URLが使われることがあります。

Webhook URLは、通知先へメッセージを送るための重要な情報です。第三者に見える場所へ貼ったり、問い合わせ本文へ実値をそのまま書いたりしないでください。

確認が必要な場合は、URLの一部を伏せる、ドメインだけを示す、設定欄に入力済みであることだけを伝えるなど、実値を出さない形で整理します。

通知先チャンネル

Discord通知では、どのチャンネルへ通知を送るかも重要です。

Webhookごとに通知先が決まっている場合、想定と違うチャンネルへ送られている可能性があります。

通知が届かない場合は、Webhook URLの実値を共有するのではなく、通知先チャンネル、通知設定、Expertsログ、テスト送信の有無を整理してください。

通知テスト

通知機能を使う場合は、本番利用前に通知テストを行います。

通知テストでは、EA側で送信処理が実行されたか、Expertsログにエラーが出ていないか、通知先で受信できているかを確認します。

テスト通知の本文に、口座番号、認証情報、APIキーなどの実値が含まれていないかも確認してください。

通知が届かない時の確認

通知が届かない場合は、次の項目を分けて確認します。

• EA側で通知条件が成立しているか
• 通知機能がONになっているか
• Webhook URLが設定されているか
• MT5のWebRequest許可URLが設定されているか
• Expertsログに通信エラーが出ていないか
• VPS側でも同じ設定になっているか
• 通知先チャンネルが想定通りか

Discord通知の個別確認については、MT5でDiscord通知が届かない時の確認ポイントも参考にしてください。

Google Sheets連携で扱う情報

GAS URL

Google Sheets連携では、Google Apps Scriptの実行URLを使うことがあります。

GAS URLは、外部からシートへ書き込みや読み取りを行う入口になる場合があるため、実値の取り扱いには注意が必要です。

問い合わせ時にGAS URLの実値をそのまま送るのではなく、設定済みかどうか、どの処理で失敗しているか、ログにどのようなエラーが出ているかを整理してください。

共有権限

Google Sheets連携では、シート側の共有権限やGAS側の公開設定が関係することがあります。

権限が不足していると、EAや補助ツール側の設定が正しくても、読み取りや書き込みに失敗する場合があります。

権限確認を行う時も、個人情報や認証情報が見えるスクリーンショットをそのまま共有しないようにしてください。

読み取りと書き込み

Google Sheets連携には、読み取りと書き込みがあります。

読み取りは、外部シート上の設定値や制御情報をEA側で取得する用途です。書き込みは、EAの状態、通知履歴、検証結果、集計情報などをシートへ保存する用途です。

読み取りが失敗しているのか、書き込みが失敗しているのかで確認するログや設定が変わります。

外部シート設定の注意

外部シートをEA設定の参照先として使う場合、シート側の値がEAの動作に影響することがあります。

そのため、外部シートで何を変更できるのか、どのタイミングでEAが読み取るのか、読み取り失敗時にどう動くのかを確認しておく必要があります。

Google Sheets連携の個別確認については、MT5でGoogle Sheets連携を確認する記事も参考にしてください。

送ってよい情報

外部連携の不具合を相談する時は、原因確認に必要な情報を整理することが重要です。

ただし、外部連携では機密性の高い情報が関係しやすいため、送ってよい情報と送ってはいけない情報を分けてください。

EA名とバージョン

EA名やインジケーター名、バージョンは、確認対象を特定するために必要です。

同じ名前のEAでもバージョンが異なると、外部連携の仕様やログの出方が異なる場合があります。

発生時刻

外部連携エラーを確認する場合は、発生時刻が重要です。

発生時刻が分かると、Expertsログ、Journalログ、通知先、Google Sheets側の履歴を照合しやすくなります。

マスク済みログ

ExpertsログやJournalログは、外部連携エラーの確認に役立ちます。

ただし、ログ内にWebhook URL、APIキー、認証トークン、口座番号などが含まれている場合は、共有前にマスクしてください。

設定項目名

設定項目名は、原因確認に役立ちます。

例えば、Webhook URL欄、WebRequest許可URL、通知ON/OFF、Google Sheets連携ON/OFF、送信間隔など、項目名だけであれば共有しやすい情報です。

ただし、設定欄に入力されている実値はマスクしてください。

エラーコード

HTTPエラーコード、WebRequest関連のエラー、EA側の通信失敗ログなどは、原因確認に役立ちます。

エラーコードやエラーメッセージは、発生時刻と合わせて共有すると確認しやすくなります。

スクリーンショットの加工例

スクリーンショットを送る場合は、事前に機密情報が写っていないか確認してください。

Webhook URL、APIキー、GAS URL、認証トークン、口座番号、メールアドレス、個人名などは、塗りつぶしや伏せ字にしてください。

送ってはいけない情報

外部連携の問い合わせでは、実値をそのまま送ってはいけない情報があります。

以下の情報は、第三者に見える場所、問い合わせ本文、スクリーンショット、公開ページへそのまま貼らないようにしてください。

Webhook URLの実値

Webhook URLは、通知先へメッセージを送るための重要な情報です。

実値を第三者に共有すると、意図しない通知送信に使われる可能性があります。

問い合わせ時には、Webhook URLを設定済みか、WebRequest許可URLを入れているか、送信ログにエラーが出ているかを伝え、URLそのものはマスクしてください。

APIキー

APIキーは、外部サービスを利用するための認証情報として使われる場合があります。

APIキーの実値は、問い合わせ本文やスクリーンショットに含めないでください。

確認が必要な場合は、先頭数文字と末尾数文字だけを残して中間を伏せるなど、実値が分からない形にします。

GAS URLの実値

GAS URLは、Google Apps Scriptの実行URLとして使われることがあります。

Google Sheetsへの書き込みや読み取りに関係する場合があるため、実値を不用意に共有しないようにしてください。

GAS URLが設定されているかどうか、権限エラーが出ているか、送信時刻、HTTP応答などを整理するだけでも、原因確認に役立つ場合があります。

認証トークン

認証トークンは、利用者確認や外部認証に使われる場合があります。

トークンの実値は、第三者へ共有しないでください。

ログにトークンが出ている場合は、共有前に必ずマスクしてください。

口座番号

口座番号は個人情報や取引環境に関係する情報です。

問い合わせ時に口座種別や環境情報が必要な場合でも、口座番号そのものを送る必要は通常ありません。

必要な場合は、デモ/リアル、口座タイプ、対象銘柄、時間足、EA名、ログなど、確認に必要な範囲だけを整理してください。

個人情報

氏名、メールアドレス、電話番号、住所、アカウント情報などの個人情報は、外部連携の不具合確認では原則として不要です。

スクリーンショットやログに個人情報が写っている場合は、共有前にマスクしてください。

外部連携エラー時に見るログ

外部連携が動かない場合は、チャート上の見た目だけでなく、Expertsログ、Journalログ、HTTPエラー、WebRequest許可、外部サービス側の権限を分けて確認します。

Expertsログ

Expertsログには、EAやインジケーター、補助ツールが出力するメッセージが表示されることがあります。

外部連携では、送信開始、送信成功、送信失敗、HTTPステータス、WebRequestエラー、外部応答などが出る場合があります。

問い合わせ前には、発生時刻、対象EA名、対象機能、マスク済みログを整理してください。

Journalログ

Journalログには、MT5端末側の状態や操作に関する情報が出る場合があります。

通信、ファイル、端末状態、注文関連の標準ログなど、EA本体以外の情報が含まれることがあります。

外部連携が失敗している場合、ExpertsログだけでなくJournalログも確認すると、端末側の問題を原因を確認しやすくなります。

HTTPエラー

外部連携では、HTTPステータスや通信エラーが原因になる場合があります。

例えば、接続先にアクセスできない、権限がない、URLが間違っている、外部サービス側が応答していないなどの原因が考えられます。

エラーコードが出ている場合は、コード、発生時刻、対象機能、直前の操作を記録してください。

WebRequest許可エラー

WebRequest許可URLが設定されていない場合、MT5側で外部通信がブロックされることがあります。

EAや補助ツールの設定が正しくても、MT5のWebRequest許可がないと送信できない場合があります。

WebRequest設定の個別確認については、MT5のWebRequest設定で確認することも参考にしてください。

権限エラー

Google Sheetsや外部サービスでは、アクセス権限が原因で読み取りや書き込みが失敗する場合があります。

権限エラーが疑われる場合は、外部サービス側の共有設定、公開設定、実行権限、接続先URLを確認します。

ただし、確認時にGAS URLやAPIキーの実値を第三者へ送らないようにしてください。

複数MT5・VPSでの外部連携

PCごとのWebRequest設定

WebRequest設定は、MT5環境ごとに確認が必要です。

手元PC、VPS、別PC、複数MT5では、それぞれ設定が異なる場合があります。

ひとつのMT5で通知が届いていても、別のMT5ではWebRequest許可URLが未設定で通知されないことがあります。

VPS移行後の通知テスト

VPSへ移行した後は、必ずVPS側で通知テストを行います。

手元PCで通知が届いていたとしても、VPS側でWebRequest、EA設定、通知先、Files、Presets、ログを再確認する必要があります。

VPS移行後の初回確認では、通知が届いたかだけでなく、Expertsログにエラーが出ていないかも確認してください。

複数EAで通知が多くなる場合

複数EAや複数チャートで通知を使う場合、通知が多くなりすぎることがあります。

通知が多すぎる場合は、通知条件、通知間隔、対象チャート、対象EA、通知ON/OFF、重複通知の有無を確認します。

通知が多い状態を外部連携エラーと混同しないように、EAごとのログや通知設定を分けて確認してください。

ログを分けて保存する

複数MT5や複数EAを使う場合は、ログを分けて保存すると確認しやすくなります。

問い合わせ時には、対象EA、対象チャート、対象時刻が分かるログを整理してください。

ログを共有する場合は、URL、APIキー、認証トークン、口座番号などの実値が含まれていないか確認してください。

外部連携チェック表

MT5で外部連携や通知機能を使う前に、次の項目を確認してください。

• □ WebRequest許可URLを確認した
• □ Discord Webhook URLの実値を共有していない
• □ GAS URLの実値を本文や問い合わせに貼っていない
• □ APIキーをマスクした
• □ 認証トークンを送っていない
• □ 口座番号や個人情報をマスクした
• □ Expertsログを確認した
• □ エラーコードを確認した
• □ VPS側でも同じ設定を確認した
• □ 外部連携失敗と売買条件不成立を混同していない

問い合わせ前チェック表

外部連携の不具合を問い合わせる前に、次の情報を整理してください。

外部連携ログの出し方

外部連携ログでは、原因を追える情報と、外に出してはいけない情報を分けることが重要です。

通信失敗時に、URLやpayload全文をそのまま出せば確認しやすく見えるかもしれません。しかし、Webhook URL、GAS URL、APIキー、認証トークンが含まれると危険です。ログは、機密情報をマスクしたうえで、結果分類を追える形式にしてください。

PrintFormat("DIAG/WEB_RESULT target=%s method=%s status=%d bytes=%d last_error=%d",
            "DISCORD",
            "POST",
            status,
            ArraySize(result),
            GetLastError());

この例では、送信先の実URLを出さず、target種別だけを記録しています。外部連携ログでは、このように「追跡に必要な情報」と「秘匿すべき情報」を分けてください。

ログ設計と再現条件の整理は、MQL5デバッグ・ログファースト開発完全ガイドも参考になります。

外部連携エラーの確認順序

Discord通知やGoogle Sheets連携が動かない場合は、外部連携全体を一度に疑うのではなく、層ごとに確認ます。

MT5側の許可URL、EA側のWebRequest処理、JSON形式、HTTPステータス、外部サービス側の権限、通知先やシート側の設定を分けて確認してください。

外部連携は、通信できたかどうかだけでなく、通信した結果、外部サービス側で期待した処理が実行されたかまで確認する必要があります。

送ってよい情報・送ってはいけない情報

外部連携の不具合を相談する場合は、確認に必要な情報を整理しつつ、機密情報を送らないようにしてください。

setファイルやログを送る前に、Webhook URL、GAS URL、APIキー、token、口座番号、個人情報が含まれていないか確認してください。

問い合わせ前に送る情報

WebRequest、Discord通知、Google Sheets連携、外部API連携の不具合を相談する場合は、状況を再現できる情報を整理してください。

「通知が届かない」「シートに書き込まれない」だけでは、MT5側の許可URL、EA側の送信処理、JSON形式、外部サービス側の権限、HTTPエラー、送信抑制のどこが原因か分かりません。

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

MQL5 WebRequest・JSON・外部API確認チェック表

• □ MT5側でWebRequest許可URLを設定した
• □ EA側の外部連携ON/OFFを確認した
• □ GET / POSTのどちらを使うか確認した
• □ header、body、timeoutを確認した
• □ JSONの必須項目と形式を確認した
• □ HTTPステータスをログで確認した
• □ GetLastErrorを確認した
• □ 4014 / 5203系の確認項目を整理した
• □ Strategy Testerでは実通信・dry-run・mockを分けて考えた
• □ Webhook URL、GAS URL、APIキー、tokenをログに出していない
• □ Discord通知失敗と売買処理を混同していない
• □ Google Sheets連携ではGAS側・シート側の権限も確認した
• □ ExpertsログとJournalログを保存した
• □ 問い合わせ前に機密情報をマスクした

外部連携処理をOnTimerへ分ける場合

WebRequest、Discord通知、Google Sheets連携などの外部連携処理は、毎tickで実行すると通信回数やログ量が増えすぎる場合があります。売買判定や注文処理はOnTick側に残し、通知、状態送信、外部制御取得、再送制御などはOnTimerで周期管理すると、処理の責務を分けやすくなります。

外部連携をOnTimerで扱う場合は、Timer周期、WebRequestのtimeout、HTTPステータス、通知間隔、再送制御、失敗時の扱い、売買処理への影響を分けて確認してください。通信失敗をすべて注文エラーとして扱わず、外部連携ログとEA本体の判定ログを分けることが重要です。

よくある質問

WebRequestを使うにはMT5で何を設定しますか？

MT5側でWebRequestの通信先URLを許可する必要があります。EA側のコードが正しくても、許可URLが未設定または不一致の場合は通信できないことがあります。

GETとPOSTはどう違いますか？

GETは情報取得や簡易問い合わせに使われることが多く、POSTはJSONやデータ送信に使われることが多い方式です。Discord通知やGoogle Sheets記録ではPOST構成を使う場面があります。

JSON送信には何が必要ですか？

送信先APIが求めるキー名、値の型、必須項目、Content-Type、文字コード、エスケープ処理、HTTPステータス確認が必要です。payload全文をログへ出す場合は機密情報に注意してください。

Discord通知が届かない時はどこを見ますか？

MT5のWebRequest許可URL、Webhook URL設定、JSON body、HTTPステータス、GetLastError、通知抑制、Discord側のWebhook状態を確認します。Webhook URLの実値は問い合わせ本文へ入れないでください。

Google Sheets連携で権限エラーが出る原因は何ですか？

GASの公開設定、デプロイURL、実行ユーザー、スプレッドシート権限、シート名、必要な列、送信method、JSON形式が原因になる場合があります。MT5側だけでなくGAS側とSheets側も確認してください。

Webhook URLを問い合わせで送ってよいですか？

送らないでください。Webhook URL、GAS URL、APIキー、認証トークンは外部サービスへ接続できる重要情報です。必要な場合はマスクした状態で状況だけを伝えてください。

バックテストでWebRequestは同じように動きますか？

リアル環境と同じ前提で考えない方が安全です。Strategy Testerでは、実通信ではなくdry-run、mock、送信抑制、ログ要約を使う設計にした方が、再現性と検証速度を保ちやすくなります。

HTTP 401や403は何を確認しますか？

401は認証、403は権限に関係する問題として確認することが多いです。APIキー、token、GAS公開設定、実行権限、アクセス許可、外部サービス側の仕様を確認してください。

4014や5203系のエラーでは何を確認しますか？

WebRequestが許可される実行環境か、MT5側の許可URLが正しいか、通信先が応答しているか、timeoutやHTTPステータスはどうか、GetLastErrorはどの処理直後に出たかを確認します。

外部連携ログには何を残すべきですか？

target種別、method、bodyサイズ、HTTPステータス、応答サイズ、GetLastError、送信見送り理由を残すと確認しやすくなります。raw URL、APIキー、token、payload全文は原則として出さないでください。

Webhook URLを問い合わせで送ってもよいですか？

実値は送らないでください。必要な場合は、URLの種類や設定場所だけを説明し、値はマスクしてください。

APIキーやGAS URLはどのように扱うべきですか？

第三者に見える場所へ貼らず、問い合わせ時も実値を送らないようにしてください。確認が必要な場合は、マスクした状態で共有します。

外部連携が失敗しているのか、EA条件が成立していないのか分かりません。

Expertsログ、Journalログ、通知テスト、WebRequest設定を分けて確認してください。売買条件と外部通信は別の問題として確認ます。

VPSへ移すとDiscord通知が届かなくなることはありますか？

あります。VPS側のMT5でWebRequest設定、EA設定、通知先、通信状態を再確認してください。

スクリーンショットを送る時の注意はありますか？

Webhook URL、APIキー、GAS URL、認証トークン、口座番号、個人情報が写っていないか確認し、必要に応じてマスクしてください。

WebRequest設定が正しければ必ず通知は届きますか？

必ず届くとは限りません。WebRequest設定のほかに、Webhook URL、通知ON/OFF、EA側の送信条件、外部サービス側の状態、VPS側の設定も確認する必要があります。

Google Sheetsへ書き込めない場合は何を確認しますか？

GAS URLの設定、共有権限、書き込み権限、HTTP応答、Expertsログ、Journalログを確認してください。ただし、GAS URLの実値は問い合わせ本文へ貼らないでください。

関連する確認ページ

確認したい内容に応じて、次のページを参照してください。本文中ですでに案内したページは、ここでは重ねて掲載していません。

あわせて確認したいページ

今回の確認内容に関連する補足ページです。必要な項目だけ確認してください。

まとめ

MQL5でWebRequest・JSON・外部API連携を実装する場合は、通信処理をEA本体のsignal、execution、riskから分離して設計することが重要です。

Discord通知やGoogle Sheets連携では、MT5側の許可URL、GET / POST、header、body、timeout、JSON形式、HTTPステータス、GetLastError、外部サービス側の権限を分けて確認してください。

4014や5203系のエラー、HTTP 401 / 403 / 404 / 500系の応答は、エラー番号だけで判断せず、どの処理で、どのmethodで、どのtargetへ、どのpayload概要を送り、どの応答が返ったのかをログで追う必要があります。

Webhook URL、GAS URL、APIキー、認証トークン、口座番号は、ログ、スクリーンショット、問い合わせ本文、記事本文へ実値を含めないでください。外部連携ログでは、raw URLではなくtarget種別、HTTPステータス、応答サイズ、エラー番号を中心に残すと安全に確認しやすくなります。

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

MT4/MT5 技術講座へ戻る

利用条件・相談窓口

お問い合わせはEAFC公式LINEへ

EAFCサイト内の記事、商品、導入前確認、設定確認、ログ確認、開発依頼前のご相談など、各種お問い合わせはEAFC公式LINEより受け付けています。

※投資助言、売買指示、利益保証、推奨ロット、推奨銘柄の案内は行っておりません。

口座番号、認証情報、Webhook URL、GAS URL、APIキーなどの機密情報は送信しないでください。