MQL5とPython：自動化の境界、欠損、数量単位を照合

MQL5とPythonは、定義した取引過程を自動化する異なる手段です。先に口座アクセス、データ、運用形態を決めます。言語、短いスクリプト、ハイブリッドという名称だけで利益や安定性、開発速度は決まりません。

何を動かし、何を維持するか

MQL5のEAはMT5端末を通して動作。Pythonは公式MetaTrader5パッケージ、別の提供者API、過去ファイルだけの研究などに使えます。公式パッケージは端末とのプロセス間通信で、全ブローカーサーバーへの直接接続ではありません。

Python自体の対応OSと、選んだパッケージ配布物の対応は別。確認したPyPIのMetaTrader5 5.0.6231ではWindows x86-64向けwheelが掲載されています。利用する時点のインタプリタ・OS・配布物の組合せを確認します。initialize()は必要なら端末を起動するため、意図したインストール先と口座・server・demo/live区分を読み返す。接続成功は以前の注文の成否の証明ではありません。別APIも対象法人、商品、権限とデータを個別に確認します。

自動化の第一歩とEAの基礎も参照。過程が少ないと監視を簡素化できる場合でも、拒否、一部約定、未確定状態への対応を置き換えません。

MQL5の統合機能にも条件がある

端末event、取引関数、Strategy Testerを使えますが、データ、費用、執行仮定を調べ、過去の業者実態そのものと認定しません。クラウド最適化も別条件。別環境で作成したモデルを対応するONNXインターフェースで動かせるため、機械学習なら実行時Python必須とは限りません。入力・出力shapeと前処理、解釈を照合します。

OnTickは全受信tickごとの一回の呼出しを保証しません。NewTickがqueueにある、または処理中なら新しいNewTickは追加されません。実際の負荷と時刻を測る。言語名から一ミリ秒と断定したり、H1だから遅延は無関係としたりしません。

Pythonライブラリの前に、データとadapterを検査

解析・モデル作成のライブラリがあっても、共通interfaceの先で銘柄、量、session、データ可用性、注文規則を提供者ごとに扱います。マクロデータや複数口座は要件で、一方を自動的な勝者にはしません。

依存版と設定を保存。元のib_insync repositoryは2024年3月14日にarchiveされread-onlyです。既存codeが即使用不能という意味ではなく、古いtutorialが現在の保守を証明しないという確認事項です。資格情報を公開codeや通常logに置かず、分析ファイル検査には注文権限を付けません。

二種類のハイブリッドを区別する

Pythonで研究し、全実行logicをMQL5 EAへ移す方式なら、実行中にPythonを残す必要がない場合があります。Pythonが端末を通して連続的に要求を送る方式なら、両process、入力の鮮度、口座の実状態を監視します。

MetaQuotes仮想ホスティングは対応EA・chart環境の移行機能で、外部Python過程を自由に動かす汎用Windows desktopではありません。同じ端末や接続が使えない時、その上の予備EAにも決済はできません。受付済みサーバー保護も別に読み返します。

公式order_send()は要求を送信し結果structureを返す関数。決済はactionやpositionの文脈が必要で、一般的なposition_close()という関数をこの公式一覧から仮定しません。通信が未確定ならorders、deals、positionsを照合してから追加要求の必要性を判断。再接続は注文の再送ではありません。

独自の架空模型では0.10 lot要求が約定したが応答だけ失われ、盲目的な再送0.10も約定したと指定。意図0.10に対して合計0.20 lot。EUR/USD一lot＝100,000 EUR、pip＝0.0001、USD口座の線形契約ならpip損益幅は1 USDから2 USDへ倍増します。全不明注文が約定する、全口座が同じようにpositionを合算する、という一般則ではありません。

欠損を否定してTrueにしてしまう境界

独自のPython試験はx=float('nan')、閾値10。指標の欠損で、ゼロや巨大な数ではなく、事前に削除しないと指定。単一floatでx>10はFalseでも、not(x<=10)はTrueです。

有限数で同じに見える式でもNaNでは異なります。型、利用可能性、有限性を先に確認し、この方式ではmath.isfinite(x) and x>10で欠損を遮断。配列やDecimal、別の型の規則は別に検査し、全言語が同じと仮定しません。図の閾値10は架空です。

シグナル時刻、境界と指定約定を照合する

独自の架空シグナルはbarが1.1000で閉じた後に利用可能。模型Aはそこ、Bは後のAsk1.1003で買うと指定。pip0.0001なら差は3 EUR/USD pips。時間、値動き、気配の側が影響し得るので全差をPython overheadやspreadと呼びません。シグナル、要求、数量、fill、費用を個別に照合してから集計します。

vector化試験にも費用を入れられ、event駆動の名称だけでは約定modelは認証されません。MT5 Testerは任意Python scriptをnative EAとして走らせるものではなく、移植版は同じ入力・規則版が必要です。

独立した境界試験ではscalar floatの0.1＋0.2は0.30000000000000004でfloat0.3より大きい。一方、文字列から構成したDecimalはこの模型でちょうど0.3、整数単位は1＋2＝3。画面で両方0.3と表示しても保存した比較は変わりません。下・等値・上・欠損・非有限を移植時に試す。選んだ許容誤差や配列は別の意味を持ち、この試験だけでMQL5版の動作や収益を実証しません。

再現できる必要条件で選ぶ

口座/API、データ、判断時刻、必要library、OS、監視条件を書きます。維持できる小さな試作でデータを読む・signalを記録するところから始められます。固定setup時間、行数、学習時間2対1という基準で選択の正解は確定しません。

満たせない要件と単純な代替を記録。時間が重要なら予定構成で測定し、bar周期だけで遅延を無視しません。APIが存在することは日本居住者への商品提供・勧誘の許可と別で、海外免許を日本の登録の代わりにせず対象法人・契約を確認します。

次の一歩：一方式と失敗時の状態を検査する

1. 小規則を固定。入力可用性、等値、単位、期待出力を先に定義。
2. 本人・口座・server・銘柄状態を照合し、demo設定、読取試験、注文権限を分ける。
3. demoで拒否、欠損、restart、応答不明を試す。再接続だけで前注文失敗と決めない。
4. 個々のsignalと執行仮定を照合。短い成功scriptからnativeな信頼性や利益を推定しない。

Pythonでの検証でも同じ版とデータ検査を残します。

JPY模型：数量2を、二lotとして送らない

新しい架空adapter契約です。API-Aのquantity一単位を1,000 USD、MT5側の一lotを100,000 USDと指定。API-Aでquantity2の意図は2,000 USDなので、MT5側では2,000/100,000＝0.02 lotです。実際の提供者には数量刻み・最小値もあるため、この仮の単位を流用しません。

数字の2だけコピーして2.00 lotへ送ると200,000 USDで、意図の100倍。USD/JPYの指定した同じ0.050 JPY/USDの価格差に対し、正しい量の価格損益幅は100円、誤った量は10,000円です。費用・ギャップを含めた最大損失ではなく、その一価格差への感応度の模型。adapterのテストでは元quantity、元単位、基準通貨量、先のlotと刻み丸め、確認した注文結果を残し、稼働前の純粋な変換関数で比較します。