SuperFunded×TradeLockerでPython自動売買botを実運用してみた｜MQL不要の技術スタック全公開

「プロップファームで自動売買＝MT4/MT5のEA」という常識は、もう半分古いです。

当サイトでは現在、SuperFunded の TradeLocker 口座で Pythonで書いた自動売買botを実運用しています。MetaTraderは一切使いません。TradingViewのWebhookも、シグナルブリッジも不要。TradeLockerの公式APIをPythonから直接叩く構成です。

この記事では、実際に動いているbotの技術スタック・設計・運用構成を解説します。「MQLは書きたくないがbotは動かしたい」「TradeLocker採用ファームで自動売買できるのか知りたい」という人向けです。

⚠️ 自動売買の可否・条件はファームごとに異なります。SuperFundedはEA・自動売買OK（HFT・アービトラージは禁止）ですが、稼働前に必ず公式ルールを確認してください。19社のEAルール比較はこちら。

なぜTradeLockerだとPythonで書けるのか

MT4/MT5の自動売買はMQL言語とターミナル常駐が前提ですが、TradeLockerは思想が違います。

• 公式REST APIが公開されている（発注・決済・ポジション照会・口座状態・価格取得まで一通り）
• 公式Pythonライブラリ tradelocker がpipで入る
• ブローカー側の約定サーバーに直接つながるため、ターミナル常駐が不要

つまり「チャートにEAをアタッチして24時間PCをつけっぱなし」ではなく、普通のPythonプログラムとしてbotを書き、普通のサーバー運用に載せられるということです。

接続はこれだけで済みます：

from tradelocker import TLAPI

tl = TLAPI(
    environment="https://live.tradelocker.com",  # demo は demo.tradelocker.com
    username="your@email.com",
    password="********",
    server="YOUR_SERVER",   # ファームから案内されるサーバー名
)

JWTトークンの取得・自動更新はライブラリが面倒を見てくれます。

実運用botの技術スタック

実際にSuperFundedで動かしているbotの構成は以下の通りです。元はMQL5のEAとして書いた時間帯ベースのゴールド戦略を、Pythonに移植しました。

ポイントは状態ストアを差し替え式にしたこと。ローカル検証ではstate.json、本番サーバーレスではFirestoreと、同じコードのまま実行環境を選べます。

設計の核心：「状態リコンサイル方式」

プロップ口座でbotを動かす場合、いちばん怖いのは二重発注と取り残しポジションです。DDルールがある以上、「意図より2倍のロットを持っていた」は即死につながります。

このbotは命令的な「時間が来たら発注」ではなく、毎ティック「あるべき状態」と「実際の状態」を突き合わせて差分だけ実行する設計にしました。Kubernetesのreconcileループと同じ発想です。

毎ティック:
  1. いま保有すべきポジション集合を計算（純粋関数）
  2. 口座の実ポジションを照会（get_all_positions）
  3. 差分を実行:
     - あるべきなのに無い＋当日未エントリー → 成行発注（SL付き）
     - あるべきでないのに有る → クローズ
     - 同一タグが2件以上 → 余剰をクローズ（二重発注の保険）

この設計にすると、bot自体がステートレスに近くなるため：

• 再起動しても現状を照会してから動くので安全
• サーバーレスで毎分起動しても二重発注しない（冪等）
• 手動で建てたポジションには一切触れない

MagicNumberの代わりは strategy_id

MT4/MT5ではEAのポジション識別にMagicNumberを使いますが、TradeLockerでは発注時に strategy_id タグを付与でき、ポジション照会時に読み戻せます：

# 発注時にタグ付け（SLはabsolute価格指定）
tl.create_order(
    instrument_id, quantity=lot, side="buy", type_="market",
    strategy_id="mybot_1",
    stop_loss=sl_price, stop_loss_type="absolute",
)

# 照会時にタグで自分のポジションだけ抽出
df = tl.get_all_positions()
mine = df[df["strategyId"].str.startswith("mybot_", na=False)]

これで手動トレードや他戦略との共存が安全にできます。

公式ライブラリの自動リトライには要注意

tradelocker パッケージは通信失敗時にPOSTを最大3回自動リトライします。便利な反面、タイムアウト後にリトライが走ると発注が2回通る可能性があります。対策として、botは発注後のティックで同一 strategy_id のポジション件数を照合し、2件以上あれば余剰を自動クローズするようにしました。自動売買でプロップのDDルールと付き合うなら、この種の「保険レイヤー」は必須です。

サーバーレス運用：GCPほぼ無料枠で回る

常時VMを立てる必要はありません。この戦略は取引する時間帯が決まっているため、Cloud Scheduler が取引時間帯だけ毎分 Cloud Run Job を起動する構成にしました。

• 1回の実行は数秒（接続→リコンサイル→終了）
• 状態はFirestoreの1ドキュメント
• 起動回数は1日100回未満 → ほぼGCP無料枠内
• SLはブローカー側に置いてあるので、ポジション保有中にbotを起動し続ける必要がない

MT4/MT5のEA運用で定番だった「月額数千円のWindows VPS」が不要になるのは、TradeLocker×Pythonの隠れた大きいメリットです。

live発注の安全ゲート

事故防止として、live環境での実発注は環境変数の三重ゲートにしています：

TL_ENV=live かつ TL_DRY_RUN=false かつ TL_CONFIRM_LIVE=YES

が揃わないと起動しない。DRY-RUNモードでは発注せずログだけ出すので、まずdemoで数日回してから本番に上げる運用です。

ハマりどころ（実運用で踏んだもの）

1. 口座状態のキー名はサーバー定義：get_account_state() が返すdictのキーはブローカー設定依存。balance はほぼ共通ですが、equity相当は projectedBalance だったりするので、決め打ちせず候補キーから拾う実装が安全。
2. シンボル名がファームごとに違う：ゴールドが XAUUSD の口座も GOLD の口座もある。get_instrument_id_from_symbol_name() で解決できるか最初に確認。
3. 週末明けの発注拒否：月曜早朝は相場再開前で発注が拒否される。「拒否されたら次ティックで再試行」を仕込んでおけば、再開時に自動でキャッチアップできる（リコンサイル設計ならこれが自然に実現する）。
4. スプレッドガード：再開直後や薄商い時間はスプレッドが開く。発注前にask-bidをチェックして上限超なら見送るガードを推奨。

収支の記録も自動化：トラッカーがTradeLocker対応しました

この実運用に合わせて、当サイトの収支トラッカーもTradeLocker対応しました。公式APIで残高・有効証拠金・日次損益を定期取得してprop-memo.comに送るPythonスクリプトで、botと同じ.env・同じマシンに置くだけで動きます（記録専用・発注はしません）。

👉 TradeLocker版トラッカー導入ガイド

MT4/MT5のEA版・cTraderのcBot版と同じAPIキー・同じ収支ページに集約されるので、「MetaTraderのファームはEAで、SuperFundedはPythonで」という複数ファーム運用でも収支を一元管理できます。

まとめ：TradeLocker採用ファームは「コード派」の狙い目

• SuperFundedはEA・自動売買OK（HFT・アービトラージ禁止）で、TradeLockerの公式Python APIが使える
• MQL不要・ターミナル常駐不要・Windows VPS不要。普通のPythonエンジニアリングでbotが書ける
• プロップで動かすなら冪等な状態リコンサイル設計＋二重発注の保険はほぼ必須
• Cloud Run Job + Scheduler構成ならほぼ無料で回る

「EAが使えるか」だけでなく「どのプラットフォームで、どう自動化できるか」までがファーム選びの検討材料になってきています。SuperFundedのルール詳細は完全ガイド、各社のEA可否は19社比較を参照してください。

最終更新: 2026年7月9日