取引の自動化：EA、MQLスクリプト、cBot、VPS

自動化は反復作業をプログラムに移しますが、動作への責任は自分に残ります。Expert AdvisorやcBotには、ターミナル、VPS、クラウドサービスなど明確な実行環境が必要です。その違い、エラーの診断方法、通信断や再起動後の口座保護を説明します。ホスティング費用、執行の遅延、プログラムが口座で動く前の確認も扱います。対象は次の仕組みを使う口座です： 証拠金取引.

1. ロボットが実際に動く場所 – EA、ターミナル、ブローカーのサーバー

個人向け自動化で繰り返される誤解が「自分のロボットはブローカーで取引する」です。そうではありません。MetaTraderのExpert Advisorはコンパイル済みプログラムで、ターミナルのプロセス内で実行されます。ターミナルはブローカーのサーバーから気配値を受け、各イベントでコードを動かし、完成した取引要求を送信します。ブローカーは要求を検証し、執行または拒否します。ロボットが「知る」「覚えている」ものはすべて実行環境側にあります。

障害分析で覚えておく連鎖は次のとおりです。

EAのコード → ターミナル（実行環境）→ ブローカーのサーバー → 注文の検証 → 執行または拒否 → サーバーの応答 → ログとEAの状態

各段階は独立して、異なる形で故障します。ロジックの誤りは最初の段階です。ターミナルを閉じるとローカルの処理と新しい要求は止まりますが、ブローカーは保存済み注文の処理を続けます。注文拒否は「EAがポジションを開かなかった」と見えても第四の段階の問題です。実際のブローカーとホスティング会社のインフラはもっと複雑で、この連鎖は作業用モデルでありネットワーク図ではありません。

コードが反応するイベント。 MT4とMT5の取引プログラムはイベント駆動です。 OnInit() は開始時に動きます。入力値の検証と状態の準備を行う場所です。 OnTick() はロボットを付けた銘柄の次の気配値で発火します。 OnDeinit() はチャートからの削除、パラメーター変更、ターミナル終了時に動きます。 OnTimer() による定期処理と、 OnChartEvent() によるチャート操作は両言語に存在します。MQL4文書には完全なシグネチャーとともに、 OnInit(), OnTick()、 OnDeinit() [10]と並んで掲載されています。環境の違いは取引層です。MT5にはMQL4にない OnTrade() と OnTradeTransaction() があり、口座状態の変化に反応します [14]。取引層とは別に、MT5には OnBookEvent() もあります。文書はこれを板情報、つまり注文板の変化を扱う市場データのイベントと説明します [14]。板情報が提供される場合だけ動きます。提供は銘柄とブローカーに依存し、個人向けFX口座にはないことも多いものです。これはプログラミング講座ではなく、コードがいつ動く機会を持つかを知る最低限の説明です。

実務上、注意すべき帰結があります。 OnTick() は時計ではありません。呼出回数は受信気配値とイベントキューの処理によります。MQL5では、NewTickが既にキュー内または処理中なら、新しいNewTickを追加しません[25]。同じ通貨ペアでも二つのブローカーは異なるフィルターと流動性源を使うため、tick数が大きく違うことがあります。「おおむね一定」の呼出頻度を仮定するロジックは、実際にはブローカーと口座種別に依存しています。同じコードに見えても、他社への移植性は低くなります。

ターミナルが止まった後に残るもの

口座を守る区別であると同時に、「MT4はすべてクライアント側」という誤った短絡が繰り返される点でもあります。

ポジションや待機注文に付けたStop LossとTake Profitの水準は、ブローカーのサーバーが保存し、ターミナルの稼働にかかわらず動きます。一方、MetaTraderの画面に内蔵されたトレーリングストップは受信気配値でローカル計算し、プラットフォームを閉じると移動を止めます。MT4とMT5の両方に当てはまりますが、出典は別です。MetaTrader 4ヘルプは、サーバーではなくクライアントターミナルで働き、ターミナル終了時に止まると説明します [8]。MetaTrader 5ヘルプも、Stop Lossとは異なりサーバー側ではなくプラットフォームで実行すると説明します [11]。正確にするには二つの補足が必要です。第一に、終了は移動を止めるだけで、最後に送れた変更を取り消しません。それはサーバーに残り保護を続けます。第二に、全プラットフォームへ一般化してはいけません。cTraderの構造は異なり、開発元は「すべての保護はcTraderの各アプリで動作し、セッション終了後も有効です」と説明します [22]。Trade Watchパネルのページには「cTraderアプリを閉じたり切断したりしても、トレーリングストップロスは動作します」とあります [23]。つまり条件は利用者アプリの外で維持され、起動を必要としません。同じ機能名で異なる動作モデルなので、一方の習慣を他方に持ち込んではいけません。サーバー上の注文とローカル機能の境界は 記事11.4で詳述します ［2026-08-22時点。各ブローカーの提供機能はその文書で確認してください］.

第三の危険なケースが、未熟なコードで繰り返されます。EA内の変数だけに保存する「仮想」ストップロスです。ブローカーにはそのストップが存在しません。ターミナルのプロセスが落ちれば、口座単位の仕組み以外の保護がなくなります。ストップロスがあると考える前に、チャートやログだけでなく、ポジション画面でサーバー側にも水準が見えるかを確認してください。SL/TPの許容水準と最小距離は各ブローカーの銘柄仕様に依存するため、同じコードも口座によって受付と拒否が分かれます。

完全自動化と部分自動化

ロボットはエントリーを決めなくても役立ちます。建値への移動、数量管理、所定水準での一部決済という部分自動化は、手作業で一貫しない部分を補います。コードは短く、誤りの範囲も小さく、診断も容易です。シグナルから執行までの完全自動化は、責任の規模がまったく異なる計画です。

ただし前提は共通です。規則を曖昧さなく表せなければなりません。エントリー、出口、リスクにセットアップの「質」の判断が要るなら、それは自動化できるシステムではなく市場への意見です。自動システムは悪い仕様も良い仕様と同じく一貫して、より速く休みなく実行します。そもそも正の期待値があるかは 優位性と期待値の教材で扱い、ここではその仕様を安全に稼働させる方法だけを扱います。

2. 指標・スクリプト・EA・cBot – 異なる四種類の道具

「代わりに取引するスクリプトが欲しい」という相談は多く、言葉通りとは違う意味であることがよくあります。MetaTraderのスクリプトは取引関数を使い、一回の実行で複数の操作を送れるため、「取引するスクリプト」自体に矛盾はありません。矛盾は別です。入口は一つの OnStart()で、その関数とともに終了するため、一週間市場を監視し続ける仕組みがありません。MetaTraderの三種のプログラムは寿命とアクセス範囲が違い、cTraderでは別の分類です。

アクセスの分離は利点ですが、保証は一般的な説明より限定的です。指標は取引関数にアクセスできないので、自分では注文を送りません。言えるのはそこまでです。指標の誤りが無害という意味ではありません。EAがバッファーを読んで判断するなら、計算ミスはEAの誤取引になります。それでも明瞭な構造は同じです。指標が計算結果をバッファーに公開し、EAが読んで取引を判断します。分析と執行が分かれ、各層を個別にテストできます。ただしEAのロジックだけでなく、バッファーの中身もテストする必要があります。

cTraderの分類は異なり、一対一には対応しません。EAに相当するのはcBotで、指標に相当するのは指標です。独立した「スクリプト」の種類はなく、一回限りの処理はcBotが開始メソッドで仕事を終え、自分を停止して実行します。

時間を無駄にする三つの誤り：

• 指標に取引を期待する。 MetaTraderの指標は取引関数にアクセスできません。「自分で取引する指標」という製品は指標ではないか、別のプログラムが裏で動いています。注文の責任を担うのはそのコードです
• スクリプトで足りるのにEAを使う。 一度ですべて決済するのはスクリプトの仕事です。チャートに付けたEAは生き続け、次の気配値に反応するため監督が要ります
• モジュールではなく一枚岩にする。 五戦略、口座全体のリスク監視、描画、通知を同時に行うプログラムは診断しにくくなります。戦略ごとの自動システムと独立したリスク監視なら、一部ずつ停止できます

ロボットの前に、情報用スクリプトを書く。 初心者の練習だからではありません。取引関数の呼出しを意図して一つも含めないプログラムなら、銘柄、気配値、費用、使用可能資金を正しく読めるかを確認できます。読み違えれば、ロボットはすべての判断をその誤りの上に築きます。

次はコンパイル用のプログラムではなく、確認順序と自分の実装で使うMQL4関数名を示す構造の概略です。完成ファイルとして貼り付けて実行しないでください。コンパイルでもブローカー口座でのテストでも検証していません。コンパイルは構文を確認するだけで、選んだ環境の読取値、権限、動作を確定しません。順序を保ち、完全な実装を作ってデモ口座で結果を確認してください。その記録が動作評価の根拠になります。

構造の概略 - ロボットを書く前の環境診断
MQL4向けの指針。完全なコンパイル可能コードではない。

入口: OnStart() - 一回実行し、関数とともに終了

1. symbol   := Symbol()
   名前を固定しない。ブローカーの接尾辞で変わる。

2. bid, ask := MarketInfo(symbol, MODE_BID / MODE_ASK)
   point    := MarketInfo(symbol, MODE_POINT)
   spread   := if point > 0 then (ask - bid) / point
               それ以外: 読取り未確定
   pointがゼロなら仕様の読取り失敗であり、スプレッドゼロではない。
   二つのケースは別のログ記録にする。

3. lotMin   := MarketInfo(symbol, MODE_MINLOT)
   lotStep  := MarketInfo(symbol, MODE_LOTSTEP)
   言語の定数でなく、各ブローカーの銘柄属性。

4. ログへ: symbol, bid, spread, lotMin, lotStep,
   OrdersTotal(), AccountFreeMargin()

5. tradePossible := IsTradeAllowed()
   ログのラベル: 現時点で取引可能。
   「自動取引の許可」ではない。下の段落を参照。

この概略に含まず、含めてはならないもの:
   OrderSend、OrderClose、OrderModifyの呼出しはない。

後のすべてのロボットでも、ここから三点が戻ってきます。銘柄名を固定せず環境から読むこと、数量の刻みを銘柄仕様から読むこと、今取引できるかを明示的に確認することです。最後の点には一般的な短絡の訂正が必要です。 IsTradeAllowed() が答えるのは自動化への許可だけではありません。MQL4文書は「Expert Advisorに取引が許され、取引コンテキストが使用中でないか」を調べると説明します [15]。したがって false という結果は、許可がない場合も、取引コンテキストが使用中という自然に解消する一時的状態の場合もあります。関数の結果と、追加確認で特定した理由は別に記録してください。そうしないと、無効でないものを「取引無効」と診断します。本番障害の節では、この三つの読取りを再び扱います。

3. MQL4とMQL5 – 同じものの二つの版ではなく、二つの環境

「MQL5は関数が増えたMQL4」という説明は、実務上重要な注文とポジションのモデルで誤っています。もう一つの神話も除きましょう。MQL4は純粋な手続型言語ではなく、MetaQuotesの文書はクラス、継承、仮想関数、テンプレートを説明しています [1]。違いはプログラミングの方式ではなく、取引インターフェース、指標の読取り、保有エクスポージャーの表し方です。

取引層。 MQL4では単一の OrderSend()でポジションを開き、 OrderSelect() で待機注文と保有ポジションが並ぶ一覧の次の要素へ処理対象を切り替えます。MQL5では注文、ポジション、過去の約定を分けます。要求送信では構造体を埋め、サーバーの応答コードを含む戻りの構造体を確認します。標準ライブラリの CTrade などは、この仕組みの便利なラッパーであり別の動作方式ではありません [2]。

データ層。 MQL4の指標呼出しは指定ローソク足の値を返します。MQL5では一度作るハンドルを返し、通常は OnInit() で生成して、バッファーコピー関数で配列に値を取得します。直訳したコードは既存ハンドルを使わず毎気配値で新規作成しますが、誤りは構文ではなく作成場所なのでコンパイラーは指摘しません。すぐ表面化しないため、典型的な移行の落とし穴です。

計上方式の行は意外な障害の原因なので補足します。ネッティングは一銘柄一つの純ポジションです。反対注文は二つ目を開かず、既存分を減らすか反転します。同じ銘柄に多数の独立したポジションがある前提のMT4由来ロボットは、自分のエントリーを決済し始めます。方式はブローカーが設定するため「MT5の既定動作」ではなく各口座の属性です。導入前に確認し、できればコードで読み取ります。

移行に意味がある場面。 旧環境が実際に制約になる場合です。複数通貨のテスト、テスターでのフォワードテスト、精密なtickモデル、ブローカーがMT4で扱わない商品などが必要なときです。単に「新しい」ことは理由になりません。取引層と指標の読取りを書き直せば、動いていたコードに新しいバグ群が生まれます。期間はシステム規模に依存し、一律の数字は誠実には示せません。移行するなら集計結果ではなく約定ごとに比較します。合計だけ一致して約定一覧が違うなら、違うロジックが偶然似た結果を出しただけです。

MT5にはMetaQuotes計算ネットワークでの有料分散最適化もあります。ただし計算力が増すと試すパラメーターの組合せが増え、過去への過適合リスクも直接高まります。データ分割、費用、試行した派生形の数という検証方法は、 デモ・バックテスト・フォワードテストの記事 で詳しく扱います。

4. cTrader Algo – C#、Python、ローカルとクラウドの実行

古い製品説明を繰り返しやすい節です。古い資料はcAlgoやcTrader Automateという名前で、C#専用かつローカル専用と説明します。どちらも現在は正しくありません。

Spotwareの公式文書での環境名は cTrader Algo で、C#とPythonの二言語でアルゴリズムを作れます [3]。cBotはローカルでもクラウドでも動きます。クラウド機能文書は、cTraderが提供する隔離環境で動き、Windows、Mac、モバイル、ブラウザーの利用者アプリは開いたままでもインターネット接続中でもある必要がないと明記します [4]。これにより、後で述べるホスティング費用の考え方が大きく変わります。

クラウド実行の制限、2026-08-22時点。 文書では実口座で最大十インスタンスを同時に継続稼働でき、デモは一インスタンスで遅くとも七日後に自動停止するとします。ブローカーにより規則が異なり得ること、外部パッケージを使うcBotは追加条件を満たすとクラウドで動くことも説明しています [4]。公開日時点の製品状態と捉え、アーキテクチャを依存させる前に再確認してください。

cBotの構造。 ロボットの基本クラスを継承します。開始時のメソッドはMQLの初期化に、次の気配値の処理は OnTick()に、停止メソッドは終了処理に相当します。実務的な違いはバー確定イベントの標準対応です。MetaTraderでは現在の足の始値時刻と記憶した時刻を比較して、自分で検出します。

Open APIはRESTではない。 二次資料には「cTraderにREST APIがある」という短絡があるため、正確に記します。Spotware文書はOpen APIのデータ交換をJSONオブジェクトまたはGoogle Protocol Buffersで行うと説明します [5]。FIX APIは別サービスです。権限の範囲、提供の有無、接続条件はブローカー次第なので、一般的な製品紹介ではなく実際の提供元の文書を読んで連携を計画します。

環境選びは「良い方のプラットフォーム」選びではありません。ブローカーが一方だけを提供するなら決定済みです。両方なら、理解できる動作のコードを何で書き、維持できるか、継続稼働をどう確保するかが実務上の基準です。言語そのものは優位性を生まず、保守費用と途中で犯すミスの数を変えます。

他システムへの橋渡しとしてのWebhook

もう一つの自動化経路はプラットフォーム内のコードを通りません。チャートアラートなど外部システムのイベントが所定のアドレスにHTTP要求を送り、中間アプリがブローカーAPIの呼出しに変換します。経路は イベント → Webhook → 中間アプリ → ブローカーAPI → 検証 → 注文 → サーバー応答です。Webhookの担当は要求送信の一段だけです。到達は執行ではありません。受信できても、数量が仕様に合うか、余剰証拠金があるか、サーバーが注文を受けたかは分かりません。中間点ごとに遅延と、再接続後の同一要求の再送など独自の障害が増えます。アドレスは守るべきですが、知っていることを認可の代わりにしてはいけません。仲介側は送信者、要求の新しさ、一意の識別子を検証します。チャート側のアラート設定は 別の記事で扱います。ここで重要なのは、この橋が執行経路のどこにあり、何を保証しないかだけです。

5. 権限、コンパイル、ログ、自分のポジションの識別

「ロボットが取引しない」はよくある報告で、戦略ロジックとは無関係かもしれません。エントリー条件を調べる前に、コンパイル済みか、正しいチャートに付いているか、すべての層で自動取引が許可されているか、ログに何が残ったかの四点を確認します。

コンパイルとファイルの場所

MetaEditorのソースはテキストの拡張子ですが、チャートに載るのはコンパイル済みファイルです。プログラムの種類に合うデータフォルダー内のサブフォルダーに置かなければ認識されません。データフォルダーはメニューから開き、通常異なるインストール先と同じだと思わないでください。コピー後はナビゲーターの一覧を更新します。コンパイラーの警告も読みます。暗黙の型変換の警告は、数量がゼロに切り捨てられる意味かもしれません。

自動取引の三段階の許可

許可は一つのスイッチではありません。第一はツールバーのアルゴリズム取引ボタンという全体設定。第二はチャートに追加する個別プログラムのプロパティー。第三は自分の管理外の口座です。ブローカーは種類ごとに自動取引を禁止したり、閲覧専用口座などで取引全体を制限したりできます。確認しないロボットは理由を示さず失敗だけを報告します。

次もコンパイル用ファイルではなく、MQL5向けの構造の概略です。権限と数量正規化の確認順を示しますが、検証済みの実装ではありません。コンパイルだけでは各口座の動作を確定できず、接続中の端末応答、銘柄属性、権限を個別に調べます。この記事にはその試験はありません。完成済み取引モジュールではなく、自分の確認の土台にしてください。発注する呼出しは含みません。

構造の概略 - 権限確認と数量正規化
MQL5向けの指針。完全なコンパイル可能コードではない。

A. 取引できるか - 四つの読取り、それぞれ独自のログを残す

   TerminalInfoInteger(TERMINAL_TRADE_ALLOWED)
      false -> プラットフォームで自動取引が無効
   MQLInfoInteger(MQL_TRADE_ALLOWED)
      false -> プログラムのプロパティーで取引が無効
   AccountInfoInteger(ACCOUNT_TRADE_ALLOWED)
      false -> 口座側で取引を禁止
   AccountInfoInteger(ACCOUNT_TRADE_EXPERT)
      false -> ブローカーがここで自動取引を許可していない

   四つすべてtrueの場合だけ取引可能。
   どれが失敗したかをログに残さないと、診断は
   「ロボットが取引しない」で止まる。

B. 数量を刻みの格子へ正規化する

   入力: symbol, vol
   出力: 刻みの倍数、または「送信しない」を意味する0.0

   B1. if not MathIsValidNumber(vol) or vol <= 0.0
          -> エラーを記録し0.0を返す
       通常の比較はNaNを確実には排除しない。
       計算前に有限入力を明示的に検証する。
       そうしなければ結果も不正なままになり得る。

   B2. 成否を返す版で仕様を読む:
          SymbolInfoDouble(symbol, SYMBOL_VOLUME_MIN,  vmin)
          SymbolInfoDouble(symbol, SYMBOL_VOLUME_MAX,  vmax)
          SymbolInfoDouble(symbol, SYMBOL_VOLUME_STEP, vstep)
       いずれかfalse、またはvstep <= 0.0
          -> _LastErrorを記録し0.0を返す
       数値だけの版は失敗しても黙り、本当のゼロと
       区別できないゼロを返す。

   B3. TOL   := 1e-8            二進除算の許容誤差
       steps := MathFloor(vol / vstep + TOL)
       result := NormalizeDouble(steps * vstep, 8)

       この関数が保証する事後条件は、次だけ:
         結果は刻みの整数倍である。
         入力を超える量は
         TOL * vstep以下である。
       入力を絶対に超えないという保証ではない。

   B4. if result > vmax
          -> result := NormalizeDouble(MathFloor(vmax / vstep + TOL) * vstep, 8)
       if result < vmin
          -> return 0.0
       順序が重要。最小と最大は、刻みの格子に
       乗せた値に対してだけ確認する。

第二の関数は細部に見えて、拒否の一分類を担います。数量の刻み、最小、最大は各ブローカーの銘柄属性で、口座間でも異なります。リスクから計算した数量が許容刻みにぴったり合うことはほとんどなく、サーバーは代わりに丸めず、不正な数量として拒否します。

この関数の二点は、コンパイラー警告の節と同じ「コードは動くが結果が黙って変わる」問題なので補足します。第一に、数量は一定の小数桁で丸めず、刻みの整数個数を数えて再び掛け合わせて求めます。小数二桁へ丸めると、セント口座や一部CFDの0.001刻みで数量0.003がゼロになります。刻みの対数から桁数を決める方法も、十の累乗でない刻みで壊れます。0.25刻みの1.75を1.8へ丸めれば刻みの倍数でなくなり、未正規化と同じく拒否されます。第二に、浮動小数点の除算は整数よりわずかに小さくなり、補正値なしの切捨ては一刻みを黙って失います。0.3を0.1で割ると三未満になり、リスク計算より小さなポジションになります。最小と最大は最後、刻みの格子に乗せてから確認します。切捨てで直前まで満たした最小値を割り得ますし、最大値への切詰めも同じ格子上にある必要があります。

ただし補正値にも裏面があり、関数以上の保証をせず明示すべきです。切捨て前に加算するため、入力をわずかに超え得ます。数量0.2999999995、刻み0.1なら0.3を返し、入力より百億分の五ロット多くなります。この例の刻みでは無視できる差でも、宣言は正確にします。結果は刻みの倍数で、入力超過は許容誤差内です。補正なしでは0.3で一刻み全体を失うため、意図して選ぶ境界です。また、通常の比較で確実に排除できない非有限入力と、仕様読取りの失敗を個別に止める必要があります。忘れやすいこの二点のため、概略では入力に MathIsValidNumber() を使い、 SymbolInfoDouble() も数値だけでなく成否を返す版を使います。数値だけの版は失敗時に本物のゼロと区別できないゼロを返します。

ログ – 障害後の基本的な診断記録

プラットフォームは別々のログを持ち、その分離が役立ちます。プログラムログのタブにはコードの出力と初期化・削除のメッセージがあり、全体ログにはログイン、切断、再接続、要求送信、サーバー応答というインフラの事象があります。ストラテジーテスターも独自ログを持ちます。データフォルダーのファイルにも複製されるので再起動後に残り、それによって初めて夜間障害を再現できます。

ロボット自身が残す最低限は、判断時点と価格・スプレッド、送信要求のパラメーター、サーバー応答コード、実際の約定価格、水準変更、保護機構の発動です。価格と応答コードがなければ、ロジックの誤りとブローカー側の拒否という別問題を区別できません。

障害の節でも戻る区別を先に押さえます。ログは何をし何を見たかを示す基本記録ですが、執行の正本ではありません。正本はブローカーのサーバー上の口座状態と約定履歴です。必要なときにこそ実務的な違いになります。通信断でロボットのログが送信エラーで終わっても、サーバーは既に約定しているかもしれません。矛盾したらサーバー側が基準です。

自分のポジションの識別

ロボットは「これは自分のポジションか」に答えなければなりません。口座には手動、他のロボット、同じ戦略の別銘柄の取引が同時に存在し得ます。送信時に注文へ付ける数値識別子、両MetaTraderでいうマジックナンバーとコメント欄を使います。実務原則は、ポジションの各ループで識別子と銘柄の両方を絞り、銘柄だけにしないことです。

省けば痛い結果になります。手動ポジションの決済、同じ番号の二ロボットによる互いの水準変更などです。ネッティングでは純ポジションに単独所有者がないためさらに難しく、自分に配分したエクスポージャーを独自記録し、再起動後は現在状態でなく約定履歴から復元する必要があります。

6. 本番障害の一覧 – 再接続から銘柄仕様の変更まで

自動化の一部の障害は戦略規則ではなく実行環境に関係します。標準バックテストはすべてを再現せず、別の障害試験が必要な場合があります。以下は珍現象ではなく、数か月稼働させるなら備えるべき事柄です。

自分で再現するシナリオ：再接続後の注文重複

一クリックで任意に起こせないため、個別に説明します。 編集部はこの現象を再現していません 。以下には測定結果も測定環境の記録もありません。仕組みと、自分で調べる手順を示します。

条件。 ロボットがエントリー条件を確定し、要求を送ります。応答待ちの間に通信が切れます。注文は届いて約定しましたが、応答は戻りません。ロボットはエラーを記録して、ポジションはないと結論します。

予想される結果。 再接続後も条件が満たされれば再送します。ヘッジ口座では一つの代わりに二つ開き、実際のリスクは計画の二倍です。ネッティングでは記録は違ってもエクスポージャーが増え、純ポジションが大きくなるのにロボットは一回のエントリーと認識します。これは仕組みからの推論で、実施した試験の読取値ではありません。

自分で調べる方法。 「送信直後」にネットワークカードを切るのは手順ではなくくじです。要求が届いたかを制御できず、未到達なら普通の注文失敗という別ケースです。デモ口座ではファイアウォール規則や診断ツールで制御した切断ができますが、送信確認は執行証明ではありません。サーバー履歴が約定を示し、ターミナルが応答を受けなかった場合だけ、このケースが成立します。テスターでは再現できず手動試験になるため、記録が必要です。以下をすべて残してください。一つでも欠ければ判定できず、次の試験とも比較できません。

• プラットフォーム、ターミナルのバージョンとbuild番号。記憶でなく情報画面から読む
• ブローカー、デモ口座番号、接続サーバー、ヘッジかネッティングかという口座種別。結果がそれに依存するため
• 完全な接尾辞付き銘柄、要求数量、その銘柄の執行方式
• ローカルでなく、サーバー時間での試験日時
• 切断方法と、送信に対して切断が有効になった時点。このケースか別ケースかを決める唯一のパラメーター
• 結果。ロボットの完全なログとサーバーの約定履歴を照合する。到達を確定するのは履歴であり、ターミナルの知らなさ自体が研究対象なので、ターミナルログだけでは不足
• 試行回数と同じ結果になった回数。一回では何も証明しない

定番の処方箋にも訂正が要ります。マジックナンバーは一回の注文意図ではなく戦略を識別します。同じロボットの二要求は同じ番号なので、「この注文は既に送ったか」を単独で判定できません。送信前に割り当てて記録し、プロセスメモリー外に保存する一判断の永続識別子が必要です。これで再照合時に「未送信」と「送ったが結果不明」を区別できます。コメント欄は自然な運搬場所ですが、サーバーが切り詰めたり上書きしたりするため、手掛かりとし、自分の記録とサーバー履歴の比較を根拠にします。

対策。 原則は単純でも厳格です。正本はロボットの記憶ではなく口座状態です。失敗または結果未確認の要求後、再試行前に現在のポジションと最新の約定履歴を読み、自分の識別子で絞って注文が既にないかを確認します。同じ銘柄への連続送信の時間ロックは安価な追加策ですが、それだけでは足りません。

同じ原則で別の事故も防げます。保有確認なしのロボットが急相場で呼出しのたびに要求を送り、注文の雪崩、極端にはブローカー側の接続制限を招く事故です。送信前の状態確認と単位時間当たり操作数の制限なしに、デモ口座の外へ出してはいけません。

7. 稼働の継続性：コンピューター、VPS、プラットフォームのホスティングと費用計算

MetaTraderの従来型自動システムにはターミナル稼働が必要です。ホスティングを論じる理由は速度や「専門性」でなく、停止したプロセスは何も計算しないという一点です。例外はcTrader Algoのクラウドで、条件を満たすcBotには外部VPSが不要な場合があります。ただし同じ環境でローカル実行もでき、その場合は問題がすべて戻ります。インスタンス数は口座とブローカーに依存し、外部パッケージ利用には追加条件があります。

自宅のコンピューターが持ち込む要因。 停電、更新後の再起動、通信会社の回線障害、OSのフリーズ。どれも実行環境と全ロジックを止めますが、サーバーのSL/TPは止めません。この境界を知ることで、停止時に実際に何を失うかを判断できます。

VPSがしないこと。 戦略を改善せず、スリッページや拒否をなくさず、ブローカーやその流動性供給元への回線の障害を防ぎません。稼働継続も保証しません。公表稼働率は物理法則ではなく契約上の約束です。買うのは、自分の機器と回線を故障原因の一覧から外すという一点です。

同じ名前の二つの異なる製品

「VPS」は管理方法がまったく違う二つの方式に使われます。

完全なOS付き仮想サーバー は、データセンターの普通のコンピューター同様に借ります。リモートデスクトップで入り、自分でプラットフォームを入れ、OS更新、自動起動、監視、設定のバックアップを管理します。複数プラットフォーム、独自監視スクリプト、診断ツールという自由がある一方、遠隔アクセスの安全も含め保守責任は全面的に自分にあります。

プラットフォーム一体型ホスティング は別です。MetaTrader VPSはプラットフォーム内から起動し、一命令で環境を移行します。自動システムやシグナルコピー契約を稼働させ、Windows管理やリモートデスクトップ接続を必要としません [6]。簡単さの代償は、任意のソフトを入れられず、定められたリソースの中で働くことです。

明示した例によるインフラ費用の計算

検証可能な例にするため、上の価格を使います。年払いでは12 × 10 USD = 年120 USD。月払いでは12 × 15 USD = 年180 USD.

結論はこの例だけです。2,000 USD程度の口座なら、スプレッドや手数料を数える前にホスティングだけで年数%を使い、現実的な期待収益と競合します。十倍の口座なら同じサービスの資金比率は十分の一です。他人にVPSが「割に合う」「合わない」とは言えず、費用を提供元の表示価格ではなく自分の資金に対して計算すべきとだけ言えます。

仕様の選択と導入

取引だけのロボットの要件は小さく、負荷は別の場所でもできる最適化から来ます。表の中身より注記が重要です。数値はこの記事の測定でも開発元要件でもなく、確認項目を示す例示です。対象構成をデモで数日動かし、タスクマネージャーでプロセスのメモリーとCPUのピーク使用量を読み、それから選んでください。

提供市場は価格より保守費用の負担者で三分類できます。ブローカーの優遇ホスティングは一定活動量が条件の場合があり、便利でも一社に結び付きます。取引向け専門会社はFXブローカーが使うデータセンターへ置き、一般パブリッククラウドは設定全体を利用者に任せます。企業名は意図して挙げません。提供、場所、条件は記事より速く変わり、教材の一覧は推奨に変わりやすいからです。

ホスティング導入のチェックリスト：

1. デモの対象構成を固定日数でなく、強制再起動、通信の喪失と復旧、週末の市場終了と再開という三事象を通るまで動かしてから口座を切り替える
2. 取引時間外に更新窓を定め、強制再起動後の動作を調べる
3. プラットフォームの自動起動と、プログラム付きチャート群の復元を設定
4. 再起動後の自動取引の有効状態を個別確認。プラットフォームが開くだけでは保証されない
5. マシン稼働とプラットフォームのプロセスを別々に独立監視。pingだけではフリーズを検出できない
6. 画面消灯とスリープを切り、ログのローテーションと空き容量を管理
7. 遠隔接続を強固で固有のパスワードと、提供されるなら多要素認証で保護。可能ならアドレス制限
8. テンプレートとパラメーターをバックアップ。認証情報は設定ファイルやメモでなくパスワード管理ソフトへ
9. マシン喪失時、どこから何時間で復元するかを計画

最後は省かれがちです。喪失後の復元所要時間が分かり、平穏時に一度試すまでは、ホスティングも対策になりません。

8. 遅延 – 何を測り、測定から何は分からないか

「ping 2 ms」は「2 msで約定」を意味しません。インフラ販売ではここが曖昧にされるため、二度読む価値があります。執行経路の遅延は複数区間から成り、違う道具と精度で個別に測ります。

提供会社の数値はほぼ常に第一または第二の区間です。MetaQuotesがMetaTrader VPSから96%のブローカーサーバーへ10 ms未満と述べるとき [6]、説明するのは通信区間です。実際に約定する時間は、執行方針、利用できる流動性、その瞬間の負荷によるため、ここから分かりません。

自分の口座に関する唯一の測定 は自分のデータから得ます。ログに三時点と二価格を残します。判断時点と見た価格、送信時点、応答から読んだ約定時点と価格です。十分な取引数があれば、提供元ページの一数字でなく分布になります。平均でなく分布を見てください。指標発表時や薄い流動性での少数の遅い約定は、穏やかな中央値より重く効きます。

意味のある測定には注意が一つあります。最初の二時刻は自分のマシン、履歴の約定時刻はブローカーの時計です。引き算すれば別時計が混ざり、不明な時差が数字に隠れます。往復は単一のローカル高精度カウンターで、発注関数呼出しから応答まで測ってください。サーバー履歴の約定時刻は別の量として併記し、同じ区間のもう一端にしません。内部滞在時間は相手のテレメトリーなしでは未確定です。全体を測り期間比較はできますが、内部段階への分解はできません。

ロジック自体の感度はMetaTrader 5のテスターで調べられます。遅延を再現し、ブローカー提供の実tickを含む異なる生成モデルを使えます [7]。接続の測定ではなく、より悪い執行条件で戦略が生き残るかの確認です。方法の全体は 戦略検証の記事で扱います。

そもそも重要になる場面

答えは信念でなく計算です。同じ費用でも平均取引が小さいほど比率が増えます。以下は例示で、一取引の総費用を2.0 pipsとし、スプレッド、pips換算の手数料、通常のスリッページを含めます。実費は口座仕様と自分の約定から読んでください。遅延はpipsの費用ではなく執行モデルのパラメーターなので、この和には入りません。表は遅延を測らず、その影響をどちら向きにも確定しません。

数十pipsを目指す自動システムなら、削減に払う前に遅延の実質的な影響を確認すべきという例です。数pipsなら遅延とスリッページはホスティングでなく戦略の問題で、サーバーでは直せません。

悪い執行条件から守るパラメーター

コードに置くべき仕組みが二つあります。第一はスプレッドフィルターで、判断前に現在値と閾値を比べ、超えたら新規建てを見送ります。固定値でなく、自分の時間帯の銘柄の通常スプレッドの倍数で定義します。同じ閾値は別銘柄や別ブローカーでは意味を失います。

第二はしばしば約定価格の万能上限と呼ばれますが、違います。送信時の最大許容価格偏差は一方式にしか属しません。MetaTrader 4ヘルプは「発注時の価格偏差はinstant execution方式だけで使います」と明記します [18]。動作の説明も「スリッページ防止」という通俗的な意味と逆です。「偏差が指定値以下なら追加通知なしに新価格で執行します。それ以外はブローカーが執行可能な新価格を返します」 [18]。範囲内の価格変化は追加通知なしで新価格約定、範囲外だけが確認用の新価格、つまりリクオートです。market方式に欄はありません。MetaTrader 5はInstant Executionで説明し、Market Executionでは「ブローカーはトレーダーとの追加の相談なしに執行価格を決めます」「この方式での送信はその価格での執行への事前同意です」とします [11]。価格はブローカーが設定し、送信が事前同意で、フォームには偏差でなくFill Policyがあります。

方式はブローカーが銘柄ごとに定めます。最初は「何を入力するか」でなく「自分の銘柄に適用される欄か」を仕様で調べます。適用されれば二つの費用を選びます。狭ければリクオートと初回失敗が増え、広ければ減る代わりに判断時と違う価格の約定が増えます。技術設定でなく戦略の要素です。適用されなければ判断価格と約定価格の実際の差をログに残すことだけが残ります。どちらでも記録に価値があります。

第三は最も単純な時間制限で、新規建てしない窓を設けます。日々のロールオーバーと重要指標時にはスプレッドが広がり流動性が薄まります。数行で入口を止められますが、マシンのローカルでなくサーバー時刻を使い、時計切替の境界で試す必要があります。

9. キルスイッチ、制限、導入の最低基準

停止機構のないロボットは、利用可能証拠金の範囲で損失可能性に上限がありません。悪い実装だからでなく、停止条件がないからです。キルスイッチは追加機能でなく、放置プログラムではなく管理システムと呼ぶための条件です。

実口座の自動システムに必要な制限：

1. エクイティのドローダウン上限。 最高エクイティからの所定の下落を超えたら、自分のポジションを決済し、口座を読んで残りゼロを確認してから止まります。残れば稼働して警告します。閾値は採用したリスク計画に従い、 設定方法はリスクの教材で扱います。ここで大切なのは、コードに存在し戦略より前に確認されることです
2. 日次損失上限。 サーバー時刻の所定時刻にリセット。メモリーだけでなく、再起動後は約定履歴から再構築
3. 保有数の上限。 エントリーのロジックと独立した厳格な上限
4. 単一ポジション量の上限。 次の計算結果へ上限を適用： ポジション量の計算。計算ミスが過大数量の注文にならないようにします
5. スプレッドフィルターと、銘柄の執行方式が対応する場合の最大価格偏差。 どちらも前節で説明
6. 時間フィルター。 新規建てしない時間帯
7. 接続障害への対応。 切断や古い気配値を検出したら新規建てを止めるが、既存分を盲目的に閉じない。古い価格に基づく決済は待機より悪い場合がある

確認順が重要です。イベントハンドラーの先頭、入口の前に安全条件を置きます。違反後はエクスポージャーを開く・増やす操作をせず、自分の決済と記録だけにします。再開には人の意識的判断が必要で、時間経過後の自動復帰にはしません。

停止条件： 現在エクイティ < 最高エクイティ ×（1 − 許容ドローダウン）→ ログ記録 → 自分の決済 → 自分の保有を再計数 → ポジションも決済エラーもゼロの場合だけ削除 → それ以外は警告し稼働継続

最後の構造概略は、この記事で唯一決済関数に触れます。だから二つの関門をコメントではなく初期値に設けます。第一はドライランを既定で有効にし、操作せず決済予定をログに書くだけにします。第二は最初の気配前に口座種別を読み、デモ以外なら別の明示的同意を設定するまで初期化を拒否します。MQL4では AccountInfoInteger(ACCOUNT_TRADE_MODE)で読み、文書はデモ、コンテスト、実口座を区別します [16]。コメントの警告文は防護策ではありません。動かすために意識的変更が必要な既定値が防護策です。

構造の概略 - エクイティ下落のキルスイッチ
MQL4向けの指針。完全なコンパイル可能コードではない。

入力設定 - 最初の二つが安全を決める

   DryRun := TRUE                            既定値
      操作は送らず、決済予定の注文番号、数量、参照価格を
      ログに記録するだけ。実際に決済するには
      この設定を手で変更する必要がある。

   LiveAccountConsent := FALSE                既定値
      同意なしではデモ以外の口座での開始を拒否する。
      偶然に与えられる同意ではない。

   MagicNumber    - 自分のポジションの識別子
   MaxDrawdownPct - 最高エクイティからの許容下落率
   MaxDeviation   - 一つの執行方式だけで有効。
                    概略の下の段落を参照

開始 - OnInit()

   mode := AccountInfoInteger(ACCOUNT_TRADE_MODE)
   if mode != ACCOUNT_TRADE_MODE_DEMO
         and not LiveAccountConsent:
      ログ: デモ口座ではなく、同意もない
      エラーで初期化を終了 (INIT_FAILED) - 以上
   peak       := AccountEquity()
   stopped    := FALSE
   lastAlert  := 0          最後の警告時刻

各気配値 - OnTick()

   if stopped:
      remaining := CountOwnPositions()
      if remaining > 0
            and TimeCurrent() - lastAlert >= 3600:
         ログ: 停止状態、remaining
         人へ警告を送る
         lastAlert := TimeCurrent()
      この気配値の処理を終了
         自動では決済を再試行しない。
         次の試行は人が判断して手動で行う
   equity := AccountEquity()
   if equity > peak: peak := equity
   threshold := peak * (1 - MaxDrawdownPct / 100)

   if equity >= threshold:
      この枝は空。閾値を監視するだけで
      エントリーのロジックは一切ない

   それ以外:
      stopped := TRUE
      ログ: equity, threshold, peak, timestamp
      errors    := CloseOwnPositions()
      remaining := CountOwnPositions()
      if remaining == 0 and errors == 0 and not DryRun:
         ExpertRemove()          成功後だけ削除
      それ以外:
         ログ: errors, remaining
         人へ警告を送る
         lastAlert := TimeCurrent()
         削除しない。稼働を続け、新規建てせず、
         警告を繰り返して人を待つ

決済 - CloseOwnPositions() はエラー数を返す

   errors := 0
   for i from OrdersTotal() - 1 down to 0:

      if not OrderSelect(i, SELECT_BY_POS, MODE_TRADES):
         errors := errors + 1
         ログ: ポジションi、GetLastError()
         次へ進む                     黙って通過しない

      if OrderType() > OP_SELL: skip
                                     待機注文は別処理
      if OrderMagicNumber() != MagicNumber
            or OrderSymbol() != Symbol(): skip
                                     他のものと手動分は触らない

      RefreshRates()
      price := MarketInfo(OrderSymbol(),
                          MODE_BID for OP_BUY, MODE_ASK for OP_SELL)
      if price <= 0:
         errors := errors + 1
         ログ: 気配なし、GetLastError()
         次へ進む

      ticket := OrderTicket()
      volume := OrderLots()

      if DryRun:
         ログ: 決済予定 order, volume, price
         次へ進む                  サーバーへは何も送らない

      if not OrderClose(ticket, volume, price, MaxDeviation):
         errors := errors + 1
         ログ: 注文番号、GetLastError()

   return errors

確認 - CountOwnPositions()

   一覧をもう一度たどり、この銘柄で自分のMagicNumberを持つ
   ポジション数を返す。上のループと同様に待機注文は除く。
   プログラムのメモリーでなく口座状態の読取りであり、
   これだけが終了してよいかを決める。

この概略がしないこと は、することと同じほど重要です。待機注文の削除、部分決済、再起動への耐久はありません。停止フラグと最高値はメモリーにあり、再起動すれば数え直します。決済の再試行もしません。欠落ではなく選択です。失敗後は停止状態に留まり、新規建てせず、次の気配ごとに保有数を読み、一つでもあれば最多で一時間ごとにログと警告を繰り返します。次の決済は人がターミナルやブローカーアプリで手動実行します。これは完結した動作で、自動再試行を補う余白ではありません。一方、厳格なのは削除条件です。保有を数え直してゼロ、かつ決済エラーもゼロの場合だけ削除します。失敗後も無条件で消えると、リスクとログを残して決済を試す主体がいなくなるため、エラーや残存時は稼働を続け警告します。

一見よい慣行でも、そうでない点。 RefreshRates() は真偽値を返しますが、 false をエラー扱いしてはいけません。MQL4文書は更新できたらtrueとし、「更新できない唯一の理由は、既にクライアントターミナルの最新データであるため」と続けます [17]。Falseなら既に最新です。調べるべきは、更新後の価格が正の数かどうかです。ゼロは仕様の読取り失敗か気配なしで、決済要求を送れば拒否されます。

残る偏差パラメーターでは、値より注意点が重要です。 MaxDeviation は万能な価格上限ではなくInstant Execution専用です。範囲内なら追加通知なしで新価格約定、超過時だけ確認用新価格を返します。仕組みと出典の引用は 遅延の節、より広くは プラットフォームの記事で説明します。ここでは一つの帰結が重要です。三ポイント、五桁口座の0.3 pips程度の値が例から安易にコピーされますが、穏やかな入口向けで、緊急決済向けではありません。緊急時はスプレッドとスリッページが大きいので、狭い閾値では約定でなく新価格を返し、リクオート未対応なら保有とエラーログが残ります。緊急出口は入口より明確に広くする必要がありますが、意味も正確に呼びます。保護の増強ではなく、通る可能性を高めるため判断時より悪い価格での決済へ先に同意することです。選ぶのは悪い価格か保有リスクかで、安全か危険かではありません。Market Executionなら欄はなく、ブローカーが価格を決め、送信が事前同意となり、決済価格と判断価格の差を記録するだけが残ります。

もう一つの非対称性は方式に依存せず、範囲の問題です。閾値は AccountEquity()、つまり口座全体のエクイティで計算しますが、決済は現在銘柄だけです。同じシステムを三チャートで動かすと、超過時に気配が来た銘柄だけを閉じ、他は自分の最高値を数え続けます。複数チャートでは口座全体の監督を別プログラムへ分けます。これらは各々、実資金に触れる前に意識して決める設計事項です。

三層の保護

各層の破綻シナリオが違うため、一層だけでは足りません。

1. ロボットのコード。 上述の制限。起動中だけ有効
2. ブローカーのサーバー。 ポジションのSL/TP、マージンコール、ストップアウトの自動決済。自分の環境と独立するため、変数だけでなくここに全ポジションの保護水準を持つべき
3. 人間。 新規、決済、停止、エラーの通知と、モバイルアプリで手動決済できることの事前確認。前の二層が破綻したときの最後の層

依存関係は具体的です。サーバー水準だけでは、個々はリスク内でも合計で資金を枯らす小損失の連続を止めません。それはコードのドローダウン上限の役割です。コードだけではマシン停止に対応できず、そのときはブローカー層だけが動きます。前の二層のない通知は、損失の進み具合を知らせるだけです。

保護機構もテストする

未発動の機構は防護策でなく仮定です。デモで二段階に試します。第一段階の方が安く正しさを調べられます。ドライランを有効にし、一時間内に超える低い閾値で試すと、送信なしで自分とみなした保有と予定動作が記録されます。識別子や銘柄フィルターが広すぎる初回など、一覧が違っても決済せず分かります。第二段階は一致後だけドライランを切り、繰り返します。自分の保有だけを閉じたか、ログに残ったか、残存ゼロ確認後だけ止まったかを個別に確認します。通信断も別途、数分切って復旧し、履歴と照合するか、数え直して二つ目を開くかを調べます。

導入の最低基準 は次のとおりです。制限を持つコンパイル済みプログラム、三層の権限確認、ファイルへの判断記録、強制再起動・通信断・週末越えを含む対象環境のデモ稼働、その後リスク計画が許す場合だけ実口座の最小数量へ進み、増量はさらに後で検討します。次へ進める取引数と結果は 戦略検証の別テーマ であり、ここでは運用準備だけを扱います。

外部の完成済み自動システム

マーケット購入品にも運用安全の観点から一言。販売ファイルはコンパイル済みで、ロジックを読めず、ドローダウン制限、サーバー保護、連敗後の増量を調べられません。戦略自体の評価は検証教材の道具が必要ですが、ここでは単純な規則です。障害時の動作を予測できないシステムは、掲載成績曲線が何であれ、安全には監督できません。

ロボットを書くのは最も簡単な部分かもしれません。難しいのは維持です。毎週のログで拒否と異常な執行時間を点検し、ドローダウンが想定内か、相場条件が検証時にまだ似ているかを正直に問います。自動化は執行をコードに移し、人の一部のミスを除きますが、責任は移しません。適時に止める義務とともに自分に残ります。