最初の自動化プロジェクトは、発注しなくても成立します。シグナルの記録、数量の計算、保有量の確認など、結果を説明して検算できる一つの作業から始めます。入力する情報、規則、異常時の動作を決めてから注文の権限を検討します。自動化しただけで戦略に利益を生む優位性が備わるわけではありません。

アルゴリズム取引とは何か、何ではないか

シグナルの選択、決定済み注文の執行、ポジション管理、レポートを分けます。既存注文を分割するプログラムと、エントリー自体を選ぶロボットでは目的が違います。BISの2020年報告はFXの執行アルゴリズムと市場構造・リスクを扱うもので、個人向けロボットの収益の証明ではありません。BISのEAはexecution algorithm、MetaTraderのEAはExpert Advisorです。

銘柄、データ源、稼働時間、判断の時刻、エントリーと決済の条件、数量、エクスポージャーの上限、既存ポジションがある場合の動作を仕様にします。入力と監督を決める人の役割は残ります。手作業の誤りを減らしても、再起動後の重複送信など別の誤りを持ち込むことがあります。プログラムの正しさと、規則の経済的な結果を別に検査します。

作業に合う道具を選ぶ

通知だけならアラートで足りる場合があります。MT5標準アラートが比較するのは価格、直近約定の数量、時刻などです。任意の移動平均とATR条件を組み立てる編集画面ではありません。独自の条件には指標やEAが必要な場合があります。MQL5はMT5内で動き、Pythonはデータ分析や文書化された接続に使えます。アラート、MQL5、Python、FIXと順番に進む必要はありません。

口座、データ、作業に合う環境を選びます。すべての業者で同じAPIを使える、決まった行数や期間で実装できる、一定の遅延で約定すると考えてはいけません。EAの基礎とPythonでのバックテストは別の作業の案内です。同じ戦略を必ず両方で書き直す必要もありません。

欠けた3本目は推測できない

架空の同一銘柄・時間足の確定済み終値を、古い順にx、100、102とします。条件は「最終値102がちょうど3本の平均を上回る」です。手元に100と102しかなければ判定できません。x=98なら(98+100+102)/3=100で成立。x=106なら308/3≈102.667で不成立です。これは欠けた過去の二つの仮定であり、未来の価格ではありません。

横にスクロールすると図全体を確認できます。

欠けた3本目は推測できない架空の確定済み終値x、100、102。xが98なら平均100で102が上回る。xが106なら平均約102.667で上回らない。99〜104の共通軸と102の縦線で比較。xは未来ではなく欠けた過去であり、推測せず判定を保留する。欠損データで判定が変わる規則:最終値 > 3本の平均x = ?100102古い価格xが不明。過去の欠損を二通りで補うと:x = 98: (98 + 100 + 102) /3 = 100x = 106: (106 + 100 + 102) /3 ≈ 102.667最終値:1029910499104x = 98x = 106x不明:3本の規則は判定しない。
架空の確定済み終値x、100、102。xが98なら平均100で102が上回る。xが106なら平均約102.667で上回らない。99〜104の共通軸と102の縦線で比較。xは未来ではなく欠けた過去であり、推測せず判定を保留する。

図の両軸は99〜104の同じ線形尺度、縦線は102です。3本に等しく1/3の重みを置き、比較前に丸めていません。二つの既知値の平均101を使えば別の2本規則です。ゼロを入れれば架空の価格を作ります。「データ不足」と記録し、判定を出さないのが元の規則に忠実です。再取得に成功した後も、意図した同じ足かを確かめます。MQL5のCopyRatesの返却件数を確認してください。これは件数の反例であり、配列の添字方向の説明ではありません。

必要な技能と言語の選択

プログラミング、データ処理、数量とリスクの計算、統計的な考え方が役立ちます。短い損益曲線が示すのはその標本の結果で、将来の利益ではありません。代表性のあるデータ、開発に使わない期間での評価、デモ環境での実行確認を計画します。MQL5はMT5端末経由で動き、Pythonも端末との接続や別の文書化されたAPIを利用できます。処理全体の遅延はコード、ホスティング、通信、業者の執行によって変わり、一桁ミリ秒とは保証できません。

着想から検証まで:架空のEUR/USD H1規則

EMAとSMAのクロス、ATRの計算、シグナルを判定する時点、ストップと目標を明確に定義します。手動と自動を比べるときは同じ日付・データ・規則を使います。5年の自動テストと6カ月の手動標本が一致する必然性はありません。市場局面や配信元が違うからです。同じ期間の差を説明してから費用をモデル化し、固定した規則を別期間で評価します。

オフラインの練習仕様としてEMA21、SMA55、練習用に選ぶATR距離を使うことはできます。確定済みH1足だけを使うか、いつ判定可能かを記述し、最初は注文せずログに残します。シグナルあり、なし、足の切り替わり、履歴不足、既存ポジションありを試してください。入力不足は、有効な「エントリーなし」と同じではありません。

別の架空の数量計算です。USD建て口座の有効証拠金10,000 USD、仮に選ぶ初期価格損失の予算0.5%、ストップ距離25pips、EUR/USDの1pip=0.0001、1標準ロット=100,000 EURとします。1ロットのpip価値は10 USD。予算50 USDを25×10で割ると、費用前の数量は0.20ロット、名目数量20,000 EURです。これは普遍的なリスク推奨ではありません。名目エクスポージャー、必要証拠金、初期損失計画を区別し、手数料と約定の前提を含めて契約の最小単位に合わせます。通常のストップはギャップ時に異なる価格で約定し得るため、50 USDは無条件の最大損失ではありません。

比較するのは異なる取引の似た最終利益ではなく、同一規則と同一データです。パラメーター選択と評価を分け、選択に使った標本の好成績が選択バイアスではないか考えます。

正しい価格でも時刻が違えば偽のスプレッドになる

架空のt1はBid/Ask=1.1000/1.1002、t2は1.1010/1.1012、pip=0.0001です。各時点のスプレッドは2pips。それでもt1のAskとt2のBidを混ぜると(1.1002−1.1010)/0.0001=−8pipsです。「spread<2.5」のフィルターが受け入れても、観測された負の市場スプレッドではありません。SymbolInfoTickは価格と更新時刻を一つのMqlTick構造体に返します。成功を確認し、保存した同じ構造体の値から計算します。個別には正しい二回の読み取りを意図的に混ぜるテストも加えます。整合した気配値はデータの確認であって、将来の流動性や約定保証ではありません。

規則、コード、データ、経済的な結果を別々に検査する

失敗の原因には規則、プログラム、データ不足、執行差、運用上の問題があります。「二つだけで、コードは関係ない」と絞れません。注文の応答が不明な場合は、注文、約定、ポジションの実状態を確かめてから再送を判断します。OrderSendがtrueを返しても約定済みとは限りません。応答コードと取引状態を確認します。規則の版、情報の時刻、動いた理由・何もしなかった理由を記録します。

バックテストには商品に合うデータ、費用、時間順序が必要です。試したすべての案を記録し、開発用と評価用を分けます。評価用期間を見て規則を修正したら、その期間も開発に使ったことになります。優位性の評価を参照し、不成功の報告や変更理由も残してください。

勝率、期待値、プロフィットファクターは別の指標です。架空の100取引で40回が+2R、60回が−1Rなら、費用前平均は(80−60)/100=+0.2R、プロフィットファクターは80/60≈1.33です。選んだ算数の入力であり、検証した戦略や次の標本の成績ではありません。

言語のライセンス料がなくても、データ、ホスティング、ライセンス、時間の費用表を作ります。価格と利用権、復旧条件は構成ごとに異なります。再起動と停止も試し、環境に合うプラットフォームの資料を確認します。VPSが監督やすべての障害をなくすわけではありません。

追加の反例:同じシグナルを再起動後に二度処理する

売買をしない紙上テストです。JST10:00に確定足のシグナルSを記録し、仮想の0.20ロット注文をサーバーが受け付けたものとします。返事を保存する前にプログラムが停止しました。10:01の再起動で「返事がないから未発注」と推測して同じSを再送すると、二つとも約定する仮定では合計0.40ロット、名目数量40,000 EURになります。25pipsの初期距離なら費用前計画は100 USDで、元の50 USDの二倍です。価格や戦略の規則を変えなくても、状態管理の誤りで数量が増えます。

比較するもう一つの分岐では、再送前に履歴と未処理注文・ポジションを照合し、Sに対応する受理済みの注文を発見します。その注文を再送しなければ数量は0.20のままです。これはサーバーが必ず識別子による重複排除を提供するという説明ではありません。識別子、保存、照合の方法は実装で設計し、確認できないときは処理を保留します。JSTはUTC+9で、この例の10:00は01:00 UTCです。業者のサーバー時刻をJSTと決めつけないでください。

再起動で変わる数量:同じシグナルS

再起動で変わる数量:同じシグナルS二つの仮想注文がともに約定する場合と、実状態を照合して再送しない場合を比較。実際の注文はしません。仮定に基づく計算受理済みSを照合して再送しない0.20ロット/20,000 EUR返事なしを未発注と推測して再送0.40ロット/40,000 EUR
再起動で変わる数量:同じシグナルS. 二つの仮想注文がともに約定する場合と、実状態を照合して再送しない場合を比較。実際の注文はしません。

同じ売買規則でも重複処理で数量が二倍になる。応答が曖昧なら実状態の照合を先に行う。

小さな画面では横にスクロールするか、図を拡大できます。数値と要点は下のテキストにも記載しています。

受理済みSを照合して再送しない
0.20ロット/20,000 EUR – 25pipsなら費用前計画50 USD。
返事なしを未発注と推測して再送
0.40ロット/40,000 EUR – 二つとも約定すれば同距離で100 USD。

次に行う作業

  1. 一つの作業を選び、データ、時刻、規則、結果、判定を止める条件を書きます。信頼できるシグナルログだけでも最初の完成形になります。
  2. 少数の説明可能な例で、件数不足と気配値の整合を確かめます。確定足と形成中の足を区別し、判断に使った時刻を残します。
  3. 発注が必要なら、明示的なデモ環境で受理、拒否、再起動、曖昧な応答を試します。再送前に実状態を確認します。カレンダー上の締切を理由に実資金へ移行しません。
  4. 規則を固定して別の評価期間へ進み、商品に合う費用とデータを使います。同じ日付と個別の判断を比べ、差を一律の許容率で見逃しません。
  5. 停止、再開、更新の手順を書きます。ローカルのAutoTradingをオフにしても既存ポジションは閉じません。サーバーが受け付けた保護注文とプログラム管理の規則を分け、遠隔インスタンスも別に確認します。デモと本番で執行が同じとは保証できません。