MT4のWebRequest設定とFX自動売買の外部通信を確かめる手順

MT4で外部認証やニュース取得を使うEAを設定したのに、URLを追加するよう表示される。取引口座にはつながっているのに、外部データだけ取得できない。このような場合は、WebRequestの許可と、外部サービスから返された結果を順番に確認します。

結論からいうと、配布元が指定した通信先をMT4の許可リストへ登録し、対象EAで通信を確かめるのが基本です。ただし、URLの登録は認証成功やデータ取得の完了を保証しません。HTTP応答とMQL4のエラーを分けることで、設定の問題か、送信内容やサービス側の問題かを判断しやすくなります。

この記事ではPC版MT4を対象に、FX自動売買の外部通信を確認する手順を説明します。MQL4のWebRequestを直接使えないインジケーターやバックテストの制約、通信待ちがEAに与える影響も整理します。新しいEAの導入や本番での発注を、接続確認のために行う必要はありません。

MT4のWebRequest設定でFX自動売買の通信先を許可する

外部通信と取引接続を分けて考える

WebRequestは、MQL4のプログラムが指定したサーバーへHTTPリクエストを送り、応答を受け取るための関数です。認証先へ問い合わせる、外部データを取得する、管理サービスへ情報を送る、といった使い方があります。どの情報を扱うかはEAの実装によるので、設定する前にその製品の説明書を確認してください。

MT4が取引業者のサーバーにつながっていることと、EAが外部のWebサービスへ接続できることは別です。価格が更新され、口座情報が表示されていても、認証サービスへの通信が成功しているとは限りません。逆に、ニュースを取得できても、注文条件や取引許可が整っていることの証明にはなりません。

たとえば外部認証を使う製品なら、確認する結果は「認証に必要なリクエストが送られたか」と「その製品が利用可能な応答を受け取ったか」です。ニュース連携なら、接続に加えて更新日時や必要な項目が取得できているかを見ます。チャート上の表示が消えたことだけを、通信成功の根拠にはしないでください。

DLLの許可とも目的が違います。MQL4のWebRequestはHTTP通信の許可、DLLは外部ライブラリの呼び出しに関する許可です。両方を求める製品はありますが、WebRequestの失敗だけを理由にDLLを許可しません。権限の違いはMT4のDLL許可と安全確認で確認できます。

TradingViewから外部へ送るWebhookと、MT4から送るWebRequestは別です。連携製品でもURLを取り違えないようにしましょう。受信側の構成はTradingViewのWebhookとEA連携で確認できます。

指定URLと送信する情報を確認する

許可するURLは、現在使っているEAの正規の説明書やサポートで確認します。検索記事に出てきたURL、別製品の設定例、古い配布ファイルに書かれた宛先を、そのまま自分の端末へ追加しないでください。名前が似ているサービスでも、認証先とデータ取得先は一致するとは限りません。

URLの表記では、httpとhttps、ホスト名、wwwの有無、サブドメインを説明書と照合します。見慣れたサイトの名前が含まれていても、ホスト名全体が違えば別の宛先です。コピーしたときに全角文字や空白が混ざっていないかも確認します。アドレスの一部を自己判断で短くして通そうとするより、指定の登録単位を合わせてください。

MT4の許可リストへ入れるアドレスと、EAが実際に呼ぶデータ取得用のパスを含むURLは、説明書で分けて案内されることがあります。許可リストの登録、EAの入力値、APIの送信先を同じものと決めつけず、それぞれの欄に何を指定するか確認しましょう。本記事では製品と無関係な接続先URLを例として登録させることはしません。

HTTPSの宛先が案内されている場合は、その指定を守ります。接続が失敗したからといってHTTPへ変えると、製品の想定や通信の保護条件を変えてしまいます。一方、HTTPSであることだけで運営者や送信内容が適切と判断できるわけではありません。通信方式の確認と、相手を信頼できるかの確認は両方必要です。

送る情報も確認します。ニュースの取得だけなのか、ライセンス識別子を送るのか、口座番号や取引履歴を扱うのかで、許可する判断に必要な材料が変わります。MT4のURL設定画面を見ても、EAが何を送るかまでは分かりません。公開ソースがない製品では、説明書のデータ取扱いと開発元の回答が確認材料になります。

許可リストを設定して対象端末で確かめる

操作はEAを稼働させるPC版MT4で行います。自宅PCからVPSを遠隔操作しているなら、設定するのはVPS内のMT4です。複数のMT4が入っている環境では、取引業者や口座、対象EAがあるチャートを先に照合してください。似た画面の別端末へURLを入れても、確認したいEAの設定にはなりません。

本番EAがポジションを管理中なら、再起動や付け直しの影響を製品の手順で確認してください。新しい通信確認には対応するデモ環境や専用機能を使います。デモ口座でも、未知のプログラムの安全性は保証されません。

操作経路はOANDAのMQL4向けWebRequest解説でも確認できます。ただし掲載されているデータ取得先やコードは、その解説のための例です。自分のEAへ無関係なURLを追加したり、現在のサービスで同じ取得方法が使えると決めたりしないでください。

端末の画面を確定した後は、対象製品の手順で通信を再確認します。MT4公式の端末設定ヘルプは、ここで指定する許可項目を新しく適用するプログラムの既定値として説明し、すでに動くプログラムへ影響しない点を注意しています。稼働中EAの認証完了まで自動的に反映されたと扱わず、必要な再確認方法を開発元の案内に合わせます。

インジケーターとテスターには制約がある

MQL4のWebRequest関数を直接呼べるのは、EAとスクリプトです。カスタムインジケーターからの直接呼び出しはできず、MQL4公式ではGetLastErrorの4060が返ると説明されています。URLの許可を増やしても、この呼び出し元の制約を解消する設定にはなりません。

外部ニュースを表示するインジケーターが販売されていても、この仕様と矛盾すると決めつける必要はありません。補助EAや別の通信方式を使う構成かもしれないためです。ただし、画面にインジケーターがあるだけでは取得方法は分かりません。必要な補助プログラムと対応環境を、製品の仕様として確認します。

また、MT4のストラテジーテスターではWebRequestを実行できません。テスター内で外部認証やリアルタイムニュースが取得できない場合は、まずこの制約を確認してください。過去の売買を検証することと、現在の外部サービスへ接続できることを同じテストで確認しようとしないことがポイントです。

外部データを使うEAのバックテストでは、開発元がどのようにデータを用意しているかを確認します。保存済みの過去データを読み込む方式や、通信を使わないテスト用の設定があるかは製品次第です。現在のニュースを過去の時点でも知っていたように使うと、検証条件の意味が変わってしまいます。

呼び出し元とテスターの制約はMQL4公式のWebRequest仕様、テスター内の関数制限はMQL4のストラテジーテスター仕様を根拠にしています。MQL5の解説に出る別の番号を、MT4のエラーへそのまま置き換えないようにしましょう。

MT4のWebRequest接続テストと失敗原因を切り分ける

注文を出さずに一回の通信を観察する

通信の確認では、開発元が案内する接続テストや認証確認機能を優先します。その機能が何を送るか、注文や履歴の送信を伴うかを先に確認してください。通信できることだけを確かめるために、実口座で売買する必要はありません。テストの目的は、必要な情報が目的の宛先と往復できているかを観察することです。

専用のテストがない場合は、製品がどのタイミングで通信するかを確認します。起動時、ボタン操作時、一定間隔、価格更新時など、きっかけが分からないまま画面を眺めても原因を判断しにくいためです。とくに週末は価格更新を待つEAと、タイマーで確認するEAで動作が異なり得ます。勝手な再送操作は避けます。

自動売買ボタンをオフにしたことだけで、EAの処理や外部送信がすべて止まったとは考えません。MQL4のイベント仕様では、取引の禁止とEAの実行を区別しています。取引停止は発注を制限する準備であり、送信情報の確認や未知のプログラムの安全確認を代わりに行うものではありません。

確認時は対象EA名と時刻を合わせ、MT4下部の「エキスパート」タブで製品のメッセージを見ます。端末側の異常が疑われる場合は「操作履歴」側も見ます。ただし、WebRequestの戻り値や応答本文が自動的にすべて記録されるわけではありません。EAが情報を出していなければ、画面だけでは原因を決められません。

最初に見たい結果は、通信を実行した時刻、対象の通信先、WebRequestの戻り値、必要ならMQL4エラー、製品の認証や解析の結果です。取得データの場合は更新時刻も合わせます。ログの無いことを成功の証拠にするより、説明書で案内された成功メッセージや必要データを確認してください。

同じPCのブラウザで公式サイトを表示できるかは、回線を調べる補助になります。ただしブラウザとEAでは、アクセスするパス、認証、送信方法、ヘッダーなどが異なり得ます。サイトのトップが開いたことだけでAPI通信成功としません。ブラウザに認証情報付きのURLを貼って公開の履歴へ残すような試験も不要です。

戻り値がマイナスならMQL4エラーを見る

WebRequestの戻り値は、HTTPサーバーの応答コード、またはエラー時の-1です。HTTPの403とMQL4の4060は数字が似ていても別の種類です。数値だけが表示されるEAでは、それがHTTPステータスなのかGetLastErrorの値なのかを、先に開発元へ確認すると混同を避けられます。

表示された結果	何を確認するか	次の行動
戻り値が-1	MQL4側のエラー番号、許可設定、実行環境	今回の呼び出しに対応するGetLastErrorを確認
HTTPの応答コードがある	応答したサーバーとステータス、必要なら応答内容	送信条件やサービスの案内と照合
HTTP成功でもEAが失敗扱い	認証結果、データ形式、必要項目、更新時刻	製品が求める応答と一致するか確認

-1の場合に見る主なコードは次の通りです。意味はMQL4公式のランタイムエラー一覧で確認できます。番号は調査を始める方向を示す材料で、一つの原因を断定するものではありません。

MQL4コード	公式上の意味	確認する方向
4060	関数呼び出しが許可されていない	インジケーターから直接呼んでいないか、実行方式を確認
5200	無効なURL	入力文字、プロトコル、実際の呼び出しURLを照合
5201	指定URLへの接続失敗	宛先、回線、対象端末の接続条件を確認
5202	タイムアウト超過	設定された待ち時間とサーバー応答時間を確認
5203	HTTPリクエスト失敗	送信条件と失敗箇所を開発元へ確認

5200が出たからといって、必ずURL未登録だけが原因とはいえません。登録したアドレスとEAが実際に使うアドレスが一致するか、製品の対応するURL形式かを見ます。5201も、外部サイトの停止、対象端末のネットワーク条件などを区別する必要があります。これらのコードを、取引業者へログインできない問題と直結させないでください。

ソースを確認できる場合は、通信前にResetLastErrorで以前のエラーを消し、失敗直後のGetLastErrorを保存しているかが確認点になります。途中で別の処理を挟むと、表示した番号が今回の通信に対応しているか判断しにくくなります。ResetLastErrorの公式仕様を参照してください。

さらにGetLastErrorの公式仕様では、この関数の呼び出し後にエラー値がリセットされます。何度も呼んだ結果が0だったことだけで、直前の通信を成功扱いしないようにします。購入したEAの利用者がコードを直す必要はなく、開発元へ「戻り値と、その失敗に対応するエラーを確認したい」と伝えれば十分です。

HTTP応答は認証と取得結果を確認する

HTTPの応答コードが返っている場合は、サーバーや途中の仕組みから応答を受けた段階です。許可設定のチェックを繰り返すより、宛先と送信条件を照合します。認証サービスの契約状態やアクセス制限、データのパスなど、MT4側のチェックだけでは解決できない部分があります。

HTTP応答の例	意味の目安	確認すること
200	リクエストが成功	必要な認証結果やデータが本文に含まれるか
301・302など	別の宛先への転送	現行のAPI宛先と転送の扱いを開発元へ確認
400	リクエストに問題	必要なパラメータや送信形式を照合
401	有効な認証が必要	キーの有効性や認証方法を正規サポートで確認
403	リクエストを拒否	権限やサービス側の制限を確認
404	対象が見つからない	パス、API版、提供終了の有無を確認
429	リクエストが多すぎる	再送頻度や指定された待機条件を確認
500・503など	サーバー側のエラー等	障害情報と製品の再試行手順を確認

主なステータスの意味はHTTP仕様のRFC9110、429はRFC6585のレート制限仕様が根拠です。製品独自のエラー番号は、この表とは分けて説明書で確認してください。403などの制限に対して、別の未知URLを探して接続先を置き換える方法は勧めません。

200が返っても、EAが求めていた情報を得たとは限りません。たとえばHTMLのログインページを受け取ったのに、EAは認証結果のデータを期待していた場合、通信と解析で結果が分かれます。これは判断例であり、特定のEAで発生した実測結果ではありません。応答の形式と必要項目を見れば、URL追加を続けるべき段階ではないと分かります。

ニュース取得では、表示された情報が最新か、必要な通貨や日時が含まれるかも確認します。ページのHTMLが変更された場合は、以前の抽出処理が合わなくなる可能性があります。文字化けや空欄があれば、通信許可だけでなくデータの解釈を開発元へ確認します。手動で見たページとEAに返る情報が同じとは限りません。

認証情報の確認では、自分の契約に対して発行されたものを正規の方法で使います。別ユーザーのキーで試す、公開ログからトークンをコピーする、製品の認証を回避する、といった手順にしません。問い合わせに添える応答も、秘密情報や口座識別情報を除き、必要なエラー部分に絞って共有します。

同期通信の遅延と再送頻度を確認する

WebRequestは同期処理です。応答を待つ間、その呼び出しを実行しているプログラムの処理は先へ進みません。高速な通信なら問題が目立たなくても、外部サービスが遅いときは待ち時間が長くなる可能性があります。EAがどこで通信するかを知ることは、認証を通すことと同じくらい重要です。

とくに価格更新の処理で毎回通信すると、そのEAの売買判断や注文管理へ進むまでの時間が延びる懸念があります。MQL4のイベント仕様では、OnTickの実行中に来た新しいティックは、そのEAのキューへ追加されないと説明されています。通信が遅いだけでMT4全体が必ず停止する、と広げて考えるのではなく、対象EAの処理がどう待つかを確認します。

タイムアウトは通信をどのくらい待つかに関わる値で、WebRequestではミリ秒単位です。値を大きくして失敗表示が減っても、その間の待機が許容できるかは別の問題です。反対に短すぎれば、正常な応答も間に合わない場合があります。一般的な万能値を決めず、製品の推奨値と実際の応答時間を合わせてください。

通信間隔、失敗時の再試行、データの保存と再利用は、開発元に確認したい設計です。ニュースが取得できない場合に新規エントリーを控えるのか、最後に取得した情報をいつまで使うのかも重要です。接続失敗を成功と同じ条件で扱っていないか、通信が復旧したときに古い情報で判断しないかを聞きます。

タイマーに移せば必ず非同期になる、という理解も避けてください。OnTimerで呼んでもWebRequest自体は同期処理のままです。MQL4のタイマー仕様では、Timerイベントが処理中またはキュー内にあるとき、新しいTimerイベントを追加しないと説明しています。呼び出すきっかけの変更と、通信中の待機をなくす設計は違います。

HTTP429が返る場合は、再送を増やすと状況を悪化させる可能性があります。サービスが待機条件を案内しているなら、その条件と製品の再試行方法を確認します。手動で再起動を繰り返す前に、起動のたびに認証や履歴送信が走るかを確認してください。通信の成功率だけでなく、相手の利用制限を守る必要があります。

ノーコードのEA作成ツールでも、任意の外部API通信をそのまま再現できるとは限りません。通信先、送信形式、失敗時の動作まで対応を確認します。本記事の設定確認を、未確認のツールを買う理由にはしないでください。

送信先を整理し端末ごとに管理する

接続を確認した後は、許可リストに残す宛先が現在必要なものかを見直します。廃止した製品の認証先、使わなくなった連携先、目的の説明がないURLを、そのまま増やし続けないようにしましょう。ただし、同じ宛先を別の稼働中EAが使うこともあるため、不要かどうかは製品ごとに照合します。

MT4公式ヘルプでは、信頼するURLを手動で明示すること、一覧からアドレスを選んでDeleteで削除することが説明されています。削除する場合は現在の注文管理や別のEAへの影響を確認したうえで行い、確定後に一覧と製品の動作を再確認します。稼働中プログラムへの反映を、画面の一覧だけで断定しないことも大切です。

自宅PCとVPS、別の取引業者のMT4、検証用と本番用のMT4では、実際に動いている端末をそれぞれ確認します。移行の際はEAファイルや入力値だけでなく、必要な通信先と認証条件も対象です。設定したはずなのに通信できない場合は、どの端末へ登録したかを先に見直すと、関係のないURLを追加せずに済みます。

共有する画面やログには、URLのパラメータ、認証ヘッダー、応答本文などの秘密情報が混ざっていないか確認します。公開の相談先へ出す情報は、キーや口座情報を隠した時刻、エラー、製品名、実行環境に絞ります。

許可リストはMQL4のWebRequestに対する設定です。DLLや別のアプリケーションの通信まで制限する一覧ではありません。外部DLLも使う製品では、そちらの送信情報を別途確認します。

MT4のWebRequestを確認する順番

• MT4のビルド、EA名とバージョン、PCまたはVPSなどの稼働先
• EA・スクリプト・インジケーターの別と、通常チャートかテスターか
• 許可リストの登録状況と、秘密部分を除いた対象の通信先
• 通信した時刻ときっかけ、戻り値、対応するMQL4エラー
• HTTP応答がある場合のコードと、製品が示す認証・取得結果
• 同じ環境で再現するか、変更した設定は何か

必要な値がEAに表示されないときは、確認用のログやテスト機能があるかを聞きます。利用者が送信先を書き換えたり、認証用のコードを独自に編集したりする必要はありません。回線や発注も含めて動作が分からない場合は、MT4のEAが動かないときの原因別チェックへ範囲を広げます。

MT4のWebRequest設定は、正規の通信先を確認し、必要なURLを登録するところから始めます。次に対象EAの通信を観察し、-1ならMQL4エラー、HTTP応答があるならステータスと内容を確認します。インジケーターやテスターの制約に当たる場合は、許可を増やすより実装や検証方法を開発元へ確かめます。

認証やデータ取得ができた後も、待ち時間、情報の新しさ、失敗時の動作を確認してから運用を判断します。通信成功とEAの取引成績を分けて考え、必要な権限と送信先に絞って確認を進めましょう。