こんにちは。trade-engineer.com 運営者のHです。
PythonでFXの自動売買を作るには、対象の端末・口座と、データ取得・判断・注文管理の役割を先に決めます。MT5の公式連携と、オフラインで確認できるシグナル例を分け、バックテストやデモで何を確かめるかを整理します。過去の計算結果や接続の成功は、将来の利益を保証するものではありません。
- PythonとMT5をつなぐ環境の確認
- データと売買判断を分ける設計
- オフラインで再現できるシグナル例
- コスト・注文管理・停止条件の検証
作る仕組みと取引環境を決める
PythonでFXの自動売買を考えるときは、データ取得、売買判断、注文管理、記録を別の役割に分けます。利益が出るという題名や過去の成功例より、同じ入力から同じ判断を再現し、異常時に止められる条件を決めることが先です。
MT5連携と取引所APIの違い
MetaQuotesの公式Python連携資料は、MetaTrader 5端末を経由して価格や口座などの情報へアクセスする仕組みを案内しています。Pythonのプログラムが、すべての金融機関の口座へ共通の方法で接続できるという意味ではありません。FXで使うMT5、国内株の証券会社API、暗号資産の取引所APIでは、認証も注文仕様も異なります。
MT4を使用している場合にも、MetaTrader5というPythonパッケージを入れれば同じコードでMT4へ接続できるとは判断しません。まず利用先が提供する端末と接続方法を確認します。自分が使うサービスの規約、APIや自動売買の利用条件、注文可能な銘柄を確かめ、その範囲で設計してください。ここではFXとMT5の連携を主題にし、株式や暗号資産の発注方式は混在させません。
取得と判断と注文を分離する
小さな試作でも、価格を取得する処理の中へ直接注文を送る処理を埋め込むと、取得失敗時や再実行時の動きが分かりにくくなります。価格データを整える部分、条件からシグナルを出す部分、現在の注文や建玉と照合する部分に分けます。シグナルが出たという事実と、注文を送ってよいという判断は別です。同じ価格を読み直しただけで、注文が重複してはいけません。
この分離は、検証方法を明確にするためにも役立ちます。売買判断だけなら保存済みデータを入力して繰り返し確認でき、接続先の一時停止に左右されません。注文管理は、既存の建玉、約定結果、送信失敗などの状態を入力として確認します。プログラム全体を一度動かしてエラーが出なかったという確認より、何を入力し、何を出力したかが分かる単位を作ることが大切です。
何を自動化するか限定する
最初に、分析だけ行うのか、シグナルを通知するのか、デモ口座へ発注するのかを決めます。これらを一度に有効にすると、価格取得の確認をしたつもりで実注文に進むおそれがあります。目的別に動作を選べるようにし、実行時の設定とログへ残してください。分析プログラムの完成と、資金を扱う運用システムの完成を同じ状態として評価しないことが必要です。
戦略の条件も短く書き出します。対象銘柄、時間足、いつ判断するか、どの情報がそろったら中止するかを定めます。「相場がよいときに買う」といった言葉だけでは、結果を再現できません。移動平均などの指標を使う場合も、期間、確定足の扱い、同時に複数の条件が成立した場合の優先順位を決めます。ここでの条件は検証対象であり、収益性が確認された売買推奨ではありません。
接続前に環境と入力を確認する
Pythonが動くこと、パッケージを導入できること、MT5端末へ接続できることは、それぞれ別の確認です。環境と入力を記録しないままコードだけ保存すると、後で同じ結果を再現しにくくなります。
OSと配布ファイルを照合する
導入するPythonの版とOS、CPUの構成に対応するパッケージを確認します。MetaTrader5のPyPI配布情報には、リリースごとのファイルがあります。2026年11月6日の確認ではWindows向けのwheelが示されており、別OSでも同じ導入手順がそのまま通ると判断しないでください。公開されているファイルと実行環境を照合します。
パッケージの最低要件を満たすことと、自分の端末・周辺ライブラリを含めて動作が確認されたことも別です。Python、MetaTrader5パッケージ、端末の版を記録し、仮想環境を分けます。動いていた環境へ無条件で最新版を上書きするより、変更内容と再検証する項目を決める方が、問題を切り分けやすくなります。過去の記事にあるPythonの版を、現在の推奨版としてそのまま使わないことも必要です。
接続先を自動選択に任せない
MT5の接続処理では、端末や口座が意図したものかを確認します。公式のinitializeには端末の指定や口座に関する引数があり、省略時には既存の設定が使われる場合があります。したがって、接続に成功したという戻り値だけで、予定したデモ環境に接続したと判断しません。取引の前には、サーバー、口座の種別、銘柄、接続状態を照合する段階を設けます。
端末を複数入れている、普段の手動取引用口座が保存されているといった環境では、特に接続先を明確にします。口座番号や鍵をサンプルコードへ直接書き込み、そのまま公開することも避けてください。ログにはエラーの種類や処理の段階を残し、認証情報を出さないようにします。エラー文を共有する場合も、本人の口座情報が含まれていないかを確認します。
時刻と価格の意味を固定する
価格データには、銘柄名と数値だけでなく、時刻、時間帯、時間足、確定状態が必要です。端末に表示された日付と、取得したデータのタイムスタンプの扱いを照合します。取得順序が変わると、同じ移動平均の計算でも別の値になります。過去データを保存する際には、どのサービスから、いつ、どの条件で取得したかを一緒に残すと、比較の前提が分かります。
取引価格についても、終値、Bid、Ask、約定した価格を区別します。終値だけの検証で成立した売買が、その価格で実際に注文できたことにはなりません。銘柄による桁数や最小単位、取引時間の違いも確認します。異なるサービスの価格系列を途中で混ぜた場合は、その事実を記録してください。データの違いによる結果を、戦略そのものの優劣と取り違えないことが大切です。
まず判断ロジックを単独で検証する
以下は価格配列から売買判断の形を確認する、標準ライブラリだけのオフライン例です。仮の価格を使い、MT5への接続や発注、収益の計算は行いません。完成した取引システムではなく、データと判断を分けるための最小単位です。
再現可能なシグナル例
この例では、判断する位置より前の価格だけで短期・長期の平均を計算します。現在位置の価格を参照せず、準備期間が足りなければ判断を出しません。出力の1は買い方向、マイナス1は売り方向、0は方向を出さない状態を表します。新規注文や決済の命令ではありません。窓の長さ3と5も説明用の仮定であり、推奨するパラメーターではありません。
from math import isfinite
def directions(closes, fast=3, slow=5):
if type(fast) is not int or type(slow) is not int:
raise ValueError("periods must be integers")
if not 0 < fast < slow:
raise ValueError("require 0 < fast < slow")
prices = list(closes)
for value in prices:
if type(value) not in (int, float) or not isfinite(value) or value <= 0:
raise ValueError("prices must be finite positive numbers")
result = []
for i in range(len(prices)):
if i < slow:
result.append(0)
continue
short_mean = sum(prices[i-fast:i]) / fast
long_mean = sum(prices[i-slow:i]) / slow
result.append((short_mean > long_mean) - (short_mean < long_mean))
return result
if __name__ == "__main__":
sample = [100, 101, 102, 101, 103, 104, 102, 100, 99, 101, 103, 102]
print(directions(sample))
保存してPythonで実行すると、仮の入力に対する方向の配列が表示されます。出力された方向が変化することと、売買すると利益が出ることは別です。注文の数量、手数料、スプレッド、約定できる価格、反対方向へ変わった際の決済などを定めなければ、取引損益は計算できません。この関数へ発注処理を直接足す前に、入力検証と売買ルールの範囲を確認してください。
未来のデータを混ぜない
過去を検証するときには、その時点で利用できなかった価格を判断へ入れないことが重要です。例えば、足の終値で条件を計算して、同じ足の始値で注文できたことにすると、時間の順序が逆になります。判断に使うデータの終端と、約定を仮定する時点を別々に決めてください。データを追加しても、既に確定した過去の判断が変わらないかを確認する方法もあります。
未確定足の高値・安値・終値は、足が完成するまで変わる場合があります。確定後のデータだけで作った結果を、そのままリアルタイムでも同じと説明しないでください。時間足をまたぐ指標を使う場合も、上位足がいつ確定するかを確認します。グラフの見た目がきれいであることより、各判断でどこまでの情報を使っていたかを追えることが、検証の信頼性につながります。
異常な入力への動きを決める
欠損値、無限大、重複時刻、逆順のデータが入ったときに、計算を続けるのか停止するのかを決めます。今回の関数は、有限の正の数でない価格や不適切な期間を受け付けず、例外で止まる形にしています。実際のデータでは、欠けた時間帯が休場なのか取得失敗なのかも確認が必要です。欠損を前の価格で埋めれば常に正しいという扱いにはしません。
テストでは、正常なデータが動く場合に加えて、空の配列、期間未満の配列、同値が続く配列、不正な価格を確認します。外部からのデータを受け取る部分と判断の関数を分けておけば、同じ異常入力での動きを繰り返し確認できます。停止した理由を記録することも必要です。異常を無視して取引を継続することを、安定稼働やエラーに強い設計と混同しないようにします。
バックテストの条件をそろえる
シグナルが計算できたら、次に売買の仮定を明確にします。指標の方向と、ポジションの保有・変更を区別し、コストと約定の条件をそろえて比較します。数字の大きさだけで成功例と呼ばないことが大切です。
売買の規則を先に定義する
どのシグナルで新規建てを行い、どの条件で決済し、同じ方向が続く間は何もしないのかを定めます。方向が1である各足に毎回注文を追加する設計と、最初の一回だけ建てる設計では、資金の使い方も損失の範囲も異なります。最大保有数、反転時の扱い、取引をしない時間を含め、プログラムへ書く前に矛盾がないかを確認してください。
仮定した注文は、いつのどの価格で成立したものとするかも必要です。価格が飛んだ場合や、指値に到達したように見えても実際の約定が分からない場合は、都合のよい値を採用しないようにします。終値だけの簡単な検証で扱えない注文は、その制約を結果に添えます。バックテストの処理が実取引の完全な再現であるかのように書かないことが重要です。
コストをゼロに固定しない
FXでは売買価格の差、手数料、保有に伴う費用などが結果へ影響します。検証で何を含めたか、含めていないかを明示してください。価格系列に既に含まれるものと別に加えるものを区別し、同じ費用を二重に引くことも避けます。将来の実際のコストを一定値で保証するのではなく、仮定を変えた場合に結果がどう変化するかを確認します。
特に短い値幅を狙う設計では、わずかな仮定の違いで結果が変わることがあります。コストなしの成績だけを見てから実運用の都合に合わせるより、使う予定の環境で確認可能な条件を最初に整理する方が実用的です。必要なデータがない部分は未評価と明示します。ゼロとして計算した未確認項目を、実際にも発生しない費用として扱ってはいけません。
一つの期間だけで最適化しない
期間や条件を何度も変更して、過去の一つのデータで最もよい結果を選ぶと、その期間の値動きへ合わせ過ぎるおそれがあります。条件を決めるためのデータと、決めた後に確認するデータを分けます。別期間を何度も見てから修正すれば、その別期間も事実上の調整に使ったことになるため、変更の履歴を残してください。
勝率だけでは損益の性質は分かりません。利益と損失の大きさ、最大の資産減少、取引数、連続して負けた場面、保有時間などを併せて確認します。実際に得られていない数値を、例として作った表へ実績のように掲載しないことも必要です。ヒストリカルデータを整える確認点も読み、入力の準備と成績の解釈をつなげてください。
デモと運用で確かめること
過去の計算に合格しても、実行中の通信・注文・記録の問題が残ります。デモ環境では取引結果だけでなく、予定した動作と実際の動作の差を確認します。過去の検証やデモの結果は、将来の利益の保証にはなりません。
注文を再送する前に照合する
通信が途切れたとき、送信側に応答が届かなかったことと、サーバーが注文を受け付けなかったことは同じではありません。失敗したと思ってすぐ再送すると、注文が重複する場合があります。注文や約定の照合方法、識別する情報、再送を許す条件を設計してください。単に例外を捕まえてループを続けるコードでは、取引状態を正しく把握できません。
手動取引や別のプログラムが同じ口座で動く場合も、口座全体の建玉と自分の処理が作った建玉を分けて扱う必要があります。思いがけない建玉を見つけた際に自動で決済するのか、人の確認を待つのかも、あらかじめ決めます。自動売買は注文を送る機能だけでなく、状態が不明なときに止まり、何が起きたかを確認できる仕組みを含めて考えてください。
停止条件と復帰条件を記録する
データが更新されない、接続先が予定と違う、数量や価格が想定外、損失が自分で定めた範囲へ達したなど、停止の条件を明確にします。停止した後に、自動で再開してよいかどうかも別に決めてください。通信が戻っただけで、停止中に変化した建玉や注文を照合せず再開することは避けます。数値の上限は本人の資金管理に関する判断であり、この例で共通の適正値を指定するものではありません。
記録には、実行の識別、判断時刻、入力データの時刻、シグナル、注文を出した理由、応答、停止理由を残します。口座の秘密情報は記録しません。設定を変えた場合には、どの版のルールが動いていたかも追えるようにします。記録がなければ、戦略が合わなかったのか、実装や接続の問題だったのかを分けにくくなり、修正する場所を誤りやすくなります。
検証できた範囲を説明する
「Pythonで動作した」という報告には、何の環境で何を確認したのかを添えます。オフラインの関数、過去データの計算、MT5との情報取得、デモ注文、実運用では、確認範囲が異なります。この記事の掲載例も、仮の価格配列に対するロジックの例です。実取引の成績や、特定の業者での動作確認を示すものとして扱わないでください。
システムを作る順序は、利益の出るパラメーターを探すことだけではありません。対象環境を固定し、入力と判断を切り分け、取引の仮定を定め、異常系を確かめるという積み重ねです。既存のバックテストで勝率を確認する記事へ進む場合も、勝率の数字とその計算条件を必ず一緒に見てください。収益の断定より、再現できる条件と評価の限界が判断材料になります。
変更前後の結果を比較する
コードやパラメーターを変える場合は、以前の版と同じ入力で比較します。別の価格データへ入れ替えた結果を、コードの改善効果と混同しないようにします。変更点と入力の版を記録し、出力が変わった位置を追えることが重要です。
変更を一つずつ評価する
例えば期間を変えることと、欠損データの処理方法を変えることを同時に行うと、結果が変わった理由を分けにくくなります。一つの変更ごとに比較し、前の結果へ戻せるように保存します。シグナルが一つ変わっただけでも、それが意図した仕様か、入力の順序や計算の変更によるものかを確かめてください。
実行する環境を更新した際も、パッケージが入ったという確認だけで終えず、保存した入力への出力と異常時の動きを確認します。将来の利益を測る試験とは別ですが、同じ仕様を安定して実行できるかを確かめる土台になります。検証結果を記録する際には、変更した点と、今回確認した点だけを具体的に残します。
よくある質問
条件や確認する範囲について、関連する疑問を整理します。
条件と確認方法の疑問
MetaTrader5パッケージでMT4にも接続できますか？
公式Python連携はMT5端末を対象とします。パッケージの名前が似ていることを理由に、MT4でも同じ接続・注文処理が動くとは判断できません。利用する端末と取引先が提供する方式を最初に確認し、別のAPIの認証や銘柄指定を混在させないでください。
MacでもWindowsと同じ導入手順でよいですか？
確認時点の配布ファイルはWindows向けのwheelです。OSとPythonの版、CPUの構成に対応するファイルや公式要件を確認してください。端末が別OSで使えるという情報だけで、Pythonの接続環境も同じとは判断できません。この記事でMT5実接続の全OS動作を検証したとはしていません。
掲載コードの1は、そのまま買い注文の指示ですか？
1は短期平均が長期平均を上回る方向を示すだけです。注文量、既存建玉、決済、取引時間などを判断していません。同じ1が続いた各足で発注する意味でもありません。プログラムへ組み込む際は、方向と注文の状態管理を分ける必要があります。
準備期間に0が並ぶのはエラーですか？
この例では必要な過去データが足りない間は0を返します。十分なデータがあって平均が等しい場合も0です。出力だけから両者を見分けたい設計なら、判断可能かを別の状態として返すなど、用途に合わせて定義を変えます。0を無条件の決済命令にしないでください。
バックテストの勝率が高ければ実運用できますか？
勝率だけでは、利益と損失の大きさ、コスト、最大の資産減少、取引数を判断できません。未来のデータの混入や条件の合わせ過ぎも確認し、接続・注文・停止の動きはデモ等で別に検証します。過去やデモの成績から、将来の利益が保証されるものではありません。
条件をそろえて判断する
作り始める際は、環境を固定し、入力データと判断を分離して、取引の仮定を明確にしてください。オフラインの再現、過去データ、デモでの状態管理は別の確認です。何を確かめたかと評価の限界を記録し、未検証の成績を成功事例や利益の保証として扱わないことが重要です。
