現在サイトリニューアル中です。更新までしばらくお待ちください。

MQL5でWebRequestを使う方法｜EAから外部サーバーへ接続

MQL5でWebRequestを使う方法｜EAから外部サーバーへ接続
yukik-aochai

MQL5のWebRequestを使うと、MT5のEAから外部サーバーへHTTP通信を行えます。

たとえば、EAの口座認証、利用期限の確認、アップデート通知、外部サーバーからの設定取得などで使われます。

ただし、WebRequestはコードを書けばすぐに動く機能ではありません。MT5側で接続先URLを許可していないと通信できませんし、インジケーターやストラテジーテスターでは使えない制限もあります。

また、EA販売用の認証に使う場合は、単にサーバーへアクセスできればよいわけではありません。許可URLの案内、通信失敗時の挙動、セキュリティ、サーバー負荷、利用者へのエラー表示まで考えて設計する必要があります。

この記事では、MQL5でWebRequestを使うための基本設定、GET/POST通信の考え方、実務でハマりやすい罠、認証システムへ組み込むときの注意点を解説します。

カオチャイ
カオチャイ

EAに外部認証を入れたいのですが、WebRequestを使えば簡単にできますか？

YUKI
YUKI

通信するだけならWebRequestで実装できます。ただし、URL許可設定、通信エラー時の扱い、認証突破への対策、利用者への案内まで考えないと、販売後のトラブルにつながります。

WebRequestを使うと、MT5 EAから外部サーバーへ接続できます。ただし、MT5側で接続先URLの許可設定が必要です。

この記事で分かること
  • MQL5のWebRequestでできること
  • MT5側で許可URLを設定する方法
  • GET通信とPOST通信の基本
  • WebRequestが動かないときの確認ポイント
  • インジケーターで外部通知を使いたい場合の代替案
  • WebRequest認証を販売用EAへ入れるときの注意点

MQL5のWebRequestとは

WebRequestは、MQL5のEAやスクリプトから、外部サーバーへHTTPリクエストを送るための関数です。

通常のEAは、MT5内の価格データや口座情報をもとに動作します。一方でWebRequestを使うと、MT5の外にあるサーバーへ接続し、認証情報や設定情報を確認できます。

用途WebRequestでできること
口座認証EAを使ってよい口座番号か外部サーバーへ確認する
利用期限確認購入者ごとの利用期限をサーバー側で確認する
アップデート確認現在のEAバージョンとサーバー上の最新バージョンを照合する
外部設定の取得サーバー側に置いた設定値をEAへ反映する
通知・記録EAの状態や認証結果を外部へ送信する

EA販売者向けの認証システムでは、WebRequestを使って「この口座番号は利用可能か」「期限は切れていないか」「アップデートが必要か」などを確認することがあります。

AIでEAへ認証を実装する方法を見る
AIでMT5 EAに口座認証を実装する方法｜プロンプトを使った認証導入
AIでMT5 EAに口座認証を実装する方法｜プロンプトを使った認証導入

WebRequestを使う前にMT5側で許可URLを設定する

WebRequestで外部サーバーへ接続するには、MT5のオプション画面で接続先URLを許可しておく必要があります。

許可していないURLへWebRequestを送ると、EA側のコードが正しくても通信できません。

MT5で許可URLを追加する手順

  1. MT5を開く
  2. 上部メニューの「ツール」をクリックする
  3. 「オプション」を開く
  4. 「エキスパートアドバイザ」タブを開く
  5. 「WebRequestを許可するURLリスト」にチェックを入れる
  6. 接続したいサーバーURLを追加する
  7. 「OK」を押して保存する

登録するURLは、実際に通信するURLのドメイン部分を正しく入力します。たとえば、次のような形です。

https://example.com

「http」と「https」は別扱いです。EAがhttpsで通信するなら、httpsから始まるURLを登録してください。

注意点

販売用EAでは、購入者側のMT5でも許可URL設定が必要です。

EA販売者は、購入者へ「このURLをMT5のWebRequest許可URLに追加してください」と案内できるようにしておきましょう。

WebRequestはEAとスクリプトで使う

WebRequestは、基本的にEAやスクリプトから使う関数です。

WebRequestは通信の応答を待つ同期処理です。サーバーから返事が戻るまでプログラムの処理が止まるため、チャート描画を担当するインジケーターから直接呼ぶ用途には向いていません。

また、ストラテジーテスターではWebRequestを実行できません。バックテスト中に外部サーバーへ本番通信できるわけではないため、認証や外部通信の確認は、実際のMT5環境で行う必要があります。

WebRequestを使える場所・使えない場所
  • EA：外部認証、期限確認、アップデート確認などに使いやすい
  • スクリプト：通信テストや一度だけ実行する処理に使いやすい
  • インジケーター：直接呼ぶとエラーになるため、別設計が必要
  • ストラテジーテスター：WebRequestは実行できない

インジケーターで外部通知を使いたい場合の代替案

インジケーターから直接WebRequestを使えないとしても、「サインが出たらDiscordへ通知したい」「外部サーバーへシグナルを送信したい」という需要はあります。

その場合は、インジケーター自身にWebRequestを直接書くのではなく、裏で動かすEAへ合図を渡し、EA側からWebRequestを送る構成にします。

よくある構成は、次のような流れです。

  1. インジケーターがチャート上でサインを検出する
  2. GlobalVariableやチャートイベントなどで、裏で動くEAへ合図を渡す
  3. EA側が合図を受け取る
  4. EAからWebRequestで外部サーバーやDiscordなどへ送信する

この構成にすると、インジケーターはチャート表示に集中し、外部通信はEA側へ分離できます。

注意点

インジケーター販売では、通知用EAをセットで用意する方法もあります。

「インジケーターだけで完結させる」のではなく、「表示はインジケーター、外部通信はEA」と役割を分けると、WebRequestの制限を避けながら通知機能を作りやすくなります。

GET通信とPOST通信の違い

WebRequestでは、主にGETとPOSTという通信方法を使います。

厳密なHTTP仕様をすべて覚える必要はありません。EA制作や認証実装では、まず次のように理解しておけば十分です。

通信方法主な用途EAでの使い方
GETサーバーから情報を取得するアップデート情報、簡単な接続確認、設定取得など
POSTEA側から情報を送って判定してもらう口座番号、EA名、バージョン、認証情報の送信など

口座認証のように、EA側から口座番号や製品情報を送る場合は、POSTを使うことが多くなります。

GET通信の基本コード

以下は、WebRequestでGET通信を行う最小限のテスト用コードです。

初心者向けにコメントを多めに入れています。実際のEAへそのまま組み込むというより、通信の流れを理解するためのサンプルとして見てください。

#property strict

// 接続先URL。MT5の許可URLにも同じドメインを登録する
input string InpUrl = “https://example.com/ping”;

int OnInit()
{
// 直前のエラー情報をリセット
ResetLastError();

// Cookie。使わない場合は空文字でよい
string cookie = “”;

// Referer。使わない場合は空文字でよい
string referer = “”;

// サーバー応答を待つ時間。5000は5秒
int timeout = 5000;

// GETでは送信データがないため空配列
char data[];

// サーバーから返ってくる本文を受け取る配列
char result[];

// サーバーから返ってくるヘッダー情報
string result_headers;

// WebRequestを実行
int status = WebRequest(
“GET”, // HTTPメソッド
InpUrl, // 接続先URL
cookie, // Cookie
referer, // Referer
timeout, // タイムアウト
data, // 送信データ
0, // 送信データサイズ
result, // 受信データ
result_headers // 受信ヘッダー
);

// -1の場合はHTTP以前の段階で失敗
if(status == -1)
{
Print(“WebRequest failed. Error = “, GetLastError());
return(INIT_FAILED);
}

// 受信した文字列を確認
string response = CharArrayToString(result, 0, -1, CP_UTF8);

Print(“HTTP Status = “, status);
Print(“Response = “, response);

return(INIT_SUCCEEDED);
}

statusには、HTTPステータスコードが入ります。通信に失敗した場合は-1になり、GetLastErrorでMQL5側のエラーを確認します。
主な引数の意味
  • method：GETやPOSTなどの通信方法
  • url：接続先URL
  • timeout：サーバー応答を待つ時間
  • data：サーバーへ送るデータ
  • result：サーバーから返ってきた本文
  • result_headers：サーバーから返ってきたヘッダー情報

POST通信の基本コード

POST通信は、EA側からサーバーへデータを送信したいときに使います。

たとえば、口座番号、EA名、バージョン情報などをサーバーへ送り、利用可否を確認するような用途があります。

#property strict

// 認証サーバーのURL
input string InpUrl = “https://example.com/auth”;

int OnInit()
{
ResetLastError();

// 現在ログイン中のMT5口座番号
string account = IntegerToString((int)AccountInfoInteger(ACCOUNT_LOGIN));

// EA名やバージョン情報
string product = “SampleEA”;
string version = “1.00”;

// サーバーへ送るデータ
string post_text =
“account=” + account +
“&product=” + product +
“&version=” + version;

// 文字列をchar配列へ変換
char data[];
int data_size = StringToCharArray(post_text, data, 0, WHOLE_ARRAY, CP_UTF8) – 1;

// サーバーからの応答を受け取る配列
char result[];

// サーバーから返るヘッダー情報
string result_headers;

string cookie = “”;
string referer = “”;
int timeout = 5000;

int status = WebRequest(
“POST”, // HTTPメソッド
InpUrl, // 接続先URL
cookie, // Cookie
referer, // Referer
timeout, // タイムアウト
data, // 送信データ
data_size, // 送信データサイズ
result, // 受信データ
result_headers // 受信ヘッダー
);

if(status == -1)
{
Print(“WebRequest failed. Error = “, GetLastError());
return(INIT_FAILED);
}

string response = CharArrayToString(result, 0, -1, CP_UTF8);

Print(“HTTP Status = “, status);
Print(“Response = “, response);

// ここでは例として、サーバーがOKを返した場合だけ起動成功にする
if(status == 200 && response == “OK”)
{
Print(“Authentication OK”);
return(INIT_SUCCEEDED);
}

Print(“Authentication NG”);
return(INIT_FAILED);
}

この例では、EAからサーバーへ口座番号、製品名、バージョンを送信し、サーバーの応答がOKかどうかを確認しています。

実際の認証では、サーバー側の仕様に合わせて送信項目やレスポンス形式を決めます。

注意点

この記事ではJSON処理は深掘りしません。

まずは、GETで取得する、POSTで送信する、サーバーからの応答を確認する、という基本を押さえれば十分です。JSONを使う場合は、レスポンスの形式と解析方法を別途設計します。

WebRequestが動かないときの確認ポイント

WebRequestが動かない場合、コードだけを見るのではなく、MT5側の設定、URL、サーバー応答、ログを順番に確認します。

確認チェックリスト
  • MT5のオプションでWebRequest許可URLを追加しているか
  • URLのhttpとhttpsを間違えていないか
  • ドメイン、パス、末尾のスラッシュがサーバー仕様と合っているか
  • サーバー側がGETまたはPOSTを受け付けているか
  • 送信するパラメーター名がサーバー仕様と合っているか
  • HTTPステータスコードが200以外になっていないか
  • Experts・Journalにエラーが出ていないか
  • タイムアウトが短すぎないか
  • インジケーターやストラテジーテスターで実行していないか

特に多いのは、URLの許可設定漏れです。EA側のコードを修正する前に、まずMT5側の許可URLを確認してください。

左から「許可URL」「HTTPメソッド」「送信データ」「サーバー応答」「Experts・Journal」の5項目をチェックする横長フロー図

WebRequestが失敗するときは、コードだけでなくMT5設定・URL・サーバー応答・ログを順番に確認します。

ブラウザで見えるのにMT5で接続できないことがある

WebRequestの実装で厄介なのが、「Google ChromeなどのブラウザではURLを開けるのに、MT5のEAからWebRequestを実行すると接続できない」というケースです。

この場合、コードだけが原因とは限りません。

PC側の証明書、TLS設定、プロキシ、セキュリティソフト、サーバー側のSSL証明書、リダイレクト設定などが影響して、ブラウザでは見えるのにMT5からだけ失敗することがあります。

特に、https通信ではサーバー側の証明書や暗号化方式との相性でエラーになる場合があります。コードを疑う前に、別のPCや別の回線、Windows Update、セキュリティソフト、サーバー証明書の状態も確認してください。

デメリット

「ブラウザで開ける＝WebRequestでも必ず成功する」ではありません。

WebRequestの調査では、MQL5コード、MT5設定、PC環境、サーバー証明書、セキュリティソフトを分けて確認することが大切です。

ストラテジーテスターではWebRequestを確認できない

WebRequestは、ストラテジーテスターでは実行できません。

つまり、バックテスト中に外部サーバーへ接続し、本番の認証通信やアップデート確認をテストすることはできません。

WebRequestを使うEAでは、売買ロジックのバックテストと、外部通信の動作確認を分けて考える必要があります。

確認したい内容確認方法
売買ロジックの検証ストラテジーテスターで確認する
外部サーバーとの通信実際のMT5でEAまたはスクリプトを動かして確認する
認証OK/NG時の挙動実口座またはデモ口座のチャート上で確認する
許可URL未設定時の表示MT5の許可URLを外した状態で確認する

「バックテストでは動いたのに、実際のチャートでは認証で止まる」という状態を避けるためにも、通信部分は別途テストしてください。

簡易WebRequest認証だけでは突破される可能性がある

WebRequestを使えば、EAからサーバーへ口座番号を送り、OKまたはNGを返すような簡易認証を作れます。

ただし、ソースコード内にURLを直接書き、サーバーから返ってきた文字列だけで利用可否を判断するような単純な仕組みは、販売用EAの保護としては弱くなりがちです。

通信内容の解析、ローカル環境での偽応答、URLの差し替え、コード内の判定部分の改変などにより、認証を回避されるリスクがあります。

具体的な突破方法を公開することはしませんが、販売用EAでは「WebRequestでサーバーへ接続しているから安全」とは考えない方がよいです。

デメリット

自作の簡易認証は、販売数が増えるほど狙われやすくなります。

販売用EA・インジケーターでは、口座番号、利用期限、アップデート通知、遠隔管理、エラー表示まで含めた認証システムとして設計することが大切です。

外部認証でWebRequestを使うときに決めておくこと

WebRequestは、EA販売者向けの口座認証や利用期限管理でも使われます。

EA起動時に口座番号や製品情報をサーバーへ送り、サーバー側で利用可否を判定することで、購入者だけが使えるEAにできます。

ただし、認証処理を作る場合は、通信成功時だけでなく、通信失敗時の挙動も決めておく必要があります。

認証処理で決めておきたいこと
  • 認証に使う口座番号・製品ID・バージョン情報
  • サーバーからOKが返ったときの動作
  • NGが返ったときにEAを止めるかどうか
  • 通信失敗時に再試行するか
  • 許可URL未設定時に利用者へ何を表示するか
  • タイムアウト時の扱い
  • チャート上へ表示するエラーメッセージ
  • サーバー負荷を抑える通信間隔
  • 不正利用や改変への対策

認証処理では、単にWebRequestでサーバーへ接続するだけでなく、利用者が原因を理解できるメッセージ設計も重要です。

MT5の口座番号認証について見る
MQL5でWebRequestを使う方法｜EAから外部サーバーへ接続
MQL5でWebRequestを使う方法｜EAから外部サーバーへ接続
MQLAuth認証実装の流れを見る
AIを使ったMQLAuth認証実装｜EA・インジケーターへ導入する手順
AIを使ったMQLAuth認証実装｜EA・インジケーターへ導入する手順

WebRequestの使いすぎに注意する

WebRequestは便利ですが、使いすぎるとEAの動作やサーバー負荷に影響します。

特に、OnTickで毎回WebRequestを実行すると、価格が動くたびに外部サーバーへ通信することになります。

認証確認や設定取得は、次のようなタイミングに絞ると運用しやすくなります。

  • EA起動時
  • 一定時間ごと
  • 日付が変わったとき
  • 利用期限を再確認したいタイミング
  • アップデート確認が必要なタイミング

EA販売者側でサーバーを用意する場合は、利用者が増えても耐えられるよう、通信回数を抑えた設計にしておくことが大切です。

MQLAuthならWebRequestを使った認証導入を整理しやすい

WebRequestを使った外部認証は、自作でも実装できます。

しかし、販売用EA・インジケーターとして運用する場合は、口座番号認証、利用期限、体験版、遠隔停止、アップデート通知、利用者向けメッセージ、不正利用対策まで考える必要があります。

MQLAuthでは、EA・インジケーター販売者向けに、これらの認証管理をまとめて扱えるようにしています。

AIを使って既存EAへ認証処理を組み込む導線も用意しているため、「WebRequestの基本は分かったが、自分で認証システム全体を作るのは不安」という場合にも導入しやすくなっています。

MQLAuthの機能と料金を見る
MQLAuthとは？EA・インジケーター販売者向け口座認証・販売管理システム
MQLAuthとは？EA・インジケーター販売者向け口座認証・販売管理システム

WebRequestを使うEA制作・認証実装を相談する

WebRequestを使うと、MT5 EAから外部サーバーへ接続し、認証・期限確認・更新通知などの仕組みを組み込めます。

ただし、接続先URLの許可設定、通信失敗時の処理、サーバー側の応答形式、利用者向けメッセージ、セキュリティまで含めて設計する必要があります。

シストレファクトリーでは、MT5 EA制作や、MQLAuthを使った認証実装に関する相談にも対応しています。

MT5 EA制作について見る
MT5 EA制作｜売買ルールに合わせた自動売買ツールを開発
MT5 EA制作｜売買ルールに合わせた自動売買ツールを開発
WebRequestを使った外部サーバー連携もご相談いただけます
MT5 EA制作・認証実装について相談する

よくある質問

Q
WebRequestを使うにはMT5側の設定が必要ですか？

必要です。MT5の「ツール」→「オプション」→「エキスパートアドバイザ」タブで、WebRequestを許可するURLリストへ接続先URLを追加してください。

Q
WebRequestはインジケーターから使えますか？

インジケーターから直接WebRequestを呼ぶことはできません。サイン通知などで外部通信を使いたい場合は、インジケーターからEAへ合図を渡し、EA側でWebRequestを実行する構成を検討します。

Q
WebRequestはストラテジーテスターで動きますか？

動きません。ストラテジーテスターではWebRequestを実行できないため、外部サーバーとの通信確認は実際のMT5環境で行う必要があります。

Q
GETとPOSTはどう使い分けますか？

GETはサーバーから情報を取得したいとき、POSTはEA側から口座番号や製品情報などを送信したいときに使います。認証処理ではPOSTを使うことが多くあります。

Q
ブラウザでは開けるのにWebRequestで失敗します。

URL許可設定、http/https、サーバー側のSSL証明書、PC側の証明書やTLS設定、プロキシ、セキュリティソフトなどを確認してください。ブラウザで開けるURLでも、MT5のWebRequestから必ず成功するとは限りません。

Q
WebRequestだけで安全な認証を作れますか？

単純にURLへアクセスしてOK/NGを見るだけの認証は、販売用EAの保護としては弱くなりがちです。口座番号、利用期限、通信エラー、改変対策、利用者向けメッセージまで含めて設計する必要があります。

Q
JSONの解析も必要ですか？

サーバーの応答形式によります。最初はOKやNGなどシンプルな文字列で動作確認し、必要に応じてJSON形式のレスポンスを扱う設計にすると分かりやすくなります。

まとめ

MQL5のWebRequestを使うと、MT5 EAから外部サーバーへ接続できます。

  • WebRequestは、EAから外部サーバーへHTTP通信を行うために使う
  • MT5側で接続先URLを許可しないと通信できない
  • GETは情報取得、POSTはデータ送信に使いやすい
  • インジケーターから直接WebRequestは使えないため、EAへ合図を渡す構成を検討する
  • ストラテジーテスターではWebRequestを実行できない
  • ブラウザで見えるURLでも、MT5から接続できないことがある
  • 簡易的なWebRequest認証だけでは不正利用対策として弱くなることがある
  • 販売用EAでは、認証・期限管理・エラー表示・改変対策まで含めて設計する

EAの口座認証、利用期限管理、アップデート確認などを行う場合は、WebRequestの設定だけでなく、外部サーバー側の仕様と販売後の運用まであわせて整理しておきましょう。

Recommend
こちらの記事もどうぞ
記事URLをコピーしました