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は、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ステータス、応答サイズ、エラー番号を出すようにしてください。

外部連携ログの出し方

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

通信失敗時に、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ログを保存した
• □ 問い合わせ前に機密情報をマスクした

次に読む技術講座

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

次に確認するページ

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

よくある質問

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全文は原則として出さないでください。

まとめ

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 技術講座へ戻る