EA運用 on FX検証日記

コード監査で見つけた差異を、直す前に測って仕分けた話

Tue, 21 Jul 2026 00:00:00 +0000

実口座で動いているEAのソースコード約2,500行を、全数バグ監査にかけたことがあります。出てきた指摘は20件。再起動で停止ラッチが消える穴のような「即修正すべき実害」から、「検証コードと実機で細部の挙動が違う」という気になる差異まで、重さは様々でした。

実害系は優先度順に潰しました(停止状態の永続化、SL無し建玉の穴、発注価格の正規化など)。この記事で書きたいのは、その後に残った「検証コードとの差異」2件の話です。普通の感覚なら「検証と実機は一致すべき。全部直そう」となるところですが、このプロジェクトでは直す前に必ず測ることにしています。修正にもリスクとコストがあり、そして測ってみると、直す価値は差異ごとに全く違うからです。

はじめに: このブログと、前提の説明

初めての方向けに。このブログは、私(個人)がFXの自動売買プログラム(EA=MetaTrader5上で動く売買ロジック)を自作し、統計検証の記録を勝敗問わず公開している検証日記です。文中の「研究N」は検証ノートの通し番号。

私の開発体制は少し特殊で、検証用のPythonコード(過去11年の実データで手法を測る側)と、実口座で動くMT5のEA(測った結果を移植した側)の2本立てです。用語はPF=総利益÷総損失(1超で黒字)、DD=資産が最高値からどれだけ下がったか、の2つだけで読めます。

図: 検証側が示す「あるべき姿」。この曲線と実機の挙動がズレていないかを数え続けるのが、この記事のテーマである監査です。

なぜ「差異=即修正」にしないのか

前提の整理から。私の開発フローでは、Pythonの検証基盤が「正」で、MT5のEAはその移植です。移植には必ず細部の判断が入ります。フィルタをどのスリーブに適用するか、オーバーレイをどこまで掛けるか。移植時の解釈が検証側と食い違うと、「検証した姿」と「実際に動いている姿」がズレます。

このズレには2種類あります。性能を変えるズレと、変えないズレ。前者は直すべきですが、後者を反射的に「直す」と、実機の挙動を変えるという新しいリスクを、便益ゼロで背負うことになります。どちらか見分ける方法は1つしかありません。両方の挙動でバックテストを回して、差を測ることです。

件1(監査D3): 直しても無意味だった差異

1件目はequityフィルタの適用範囲です。米国株が200日線を割ったら核のサイズを半分にする防御機構を、検証コードはトレンド核だけに適用しているのに、実機EAは指数スリーブと第2サテライトにも掛けていました。このフィルタが作動している局面は全日数の25%。4分の1の期間で3つのスリーブのサイズが違うのだから、無視できる差には見えません。

全期間+期間分割で両方を測りました。

構成	PF	月利	最大DD
是正版(検証と一致)	1.69	+1.060%	-8.33%
現状のEA	1.68	+1.039%	-7.98%

月利差は+0.021%。DDに至っては現状のEAの方が0.35pt浅い。未使用期間(2023年以降)だけで見ると月利+1.392% vs +1.405%で、ほぼコインフリップです。取引数は8,478件で完全に同一(このフィルタはサイズだけを変えるため)。

判定は「無差」。性能を理由に挙動を変える動機はありません。そしてこの検証の本当の収穫は副産物のほうでした。実機EAの成績(月利+1.039%/DD-7.98%)が、公表している検証値(+1.060%/-8.33%)からほぼズレていないことを、初めて数字で確認できたんです。監査の不合格項目を測りにいったら、システム全体の健全性証明が手に入った形です。

件2(監査B3): 小さいが本物だった差異

2件目はカレンダー・スリーブのオーバーレイです。検証コードには存在しない「ボラ調整+equityフィルタ」が、実機のカレンダー・スリーブにだけ掛かっていました。移植時に「他のスリーブと同じ扱いにしておこう」とされた、悪意のない実装差です。

これを検証準拠(オーバーレイなし)に修正したところ、事件が起きます。MT5のストラテジーテスター(USDJPY・2022年Q1の窓)でPFが1.27→1.34へ跳ね上がったんです。0.07の改善は大きい。……大きすぎます。この手の「出来すぎた改善」を見たときこそ、全期間で測り直す規律の出番です。

構成	PF	月利	最大DD
修正後(検証と一致)	1.69	+1.060%	-8.33%
修正前	1.67	+1.049%	-8.72%

真の差はPF+0.02、月利+0.010%、DDが0.39pt浅くなる程度でした。テスター窓の派手な+0.07は、たまたまその3ヶ月がUSDJPYのカレンダー取引にとって差の出やすい窓だっただけです。

プロップ実口座でEAを動かしている記録（フォワード実録・随時更新）

Thu, 09 Jul 2026 00:00:00 +0000

このサイトの記事の大半は過去データでの検証（バックテスト）ですが、このページは実口座のフォワード、つまり「今まさに本物の口座で動いているEAに何が起きているか」の記録です。

先に運用方針を書いておきます。

数字は口座の実測だけを載せます。 推定・シミュレーション値を混ぜるときは必ずそう明記します。
都合の悪い結果もそのまま書きます。 失格したら「失格した」と書きます。バックテストとの乖離も隠しません。
更新は不定期です（動きがあったとき＋節目）。

何をどんな条件で動かしているか

項目	内容
口座	Fintokei ProTrader チャレンジ STEP1（実際の審査口座）
口座サイズ	1,000万円
開始日	2026-07-04
合格条件	+8%（STEP2は+6%）。日次-5%・最大-10%・建玉合計リスク-3%を一度でも破ると失格
EA	CoreSystemV14（このサイトで検証してきた確定システムのMT5実装・全7スリーブ）
リスク設定	チャレンジ用プリセット（基準レバ2.5／上限2.5・三段階運用の第1段）
安全装置	日次-4%で全建玉決済／口座DD-7%で新規停止＋全決済（失格ラインの手前で自動的に降りる設計）

バックテスト由来の期待値も先に開示しておきます（あくまで過去データでの実測です）: 基盤システムは2015〜2026年の11年で月利+0.82%／PF 1.66／最大DD -7.7%。チャレンジ設定でのモンテカルロでは、合格までの途中で口座DD-5%を一度は踏む確率が約3割、失格は素の分布で約1%です。つまり「途中で数%のDDを見るのは想定内」という前提で動かしています。

運用ログ（新しい順）

2026-07-28 — EAを v2.0.4 へ更新（自動記録）

稼働EAの版数が v2.0.2 から v2.0.4 に変わりました。変更内容は開発ログを参照。

2026-07-26 — EAを v2.0.2 へ更新（自動記録）

稼働EAの版数が v2.0.1 から v2.0.2 に変わりました。変更内容は開発ログを参照。

EAの更新をVPSへ手作業で運ぶのをやめた話

Wed, 08 Jul 2026 00:00:00 +0000

このサイトのEAはVPS上のMT5で常時稼働しています。開発は手元のPCでやるので、EAを直すたびにこういう作業が発生していました。

手元でコンパイルして動作確認、gitにpush
VPSにリモートデスクトップ(RDP)で入る
VPS側でgit pull
MetaEditorを開いて再コンパイル
チャート上のEAを手動で再起動

1回あたり数分とはいえ、本番口座で動いているものなので毎回それなりに神経を使います。しかもうちの場合、EAのコードを直すのは主にAIエージェント(Claude Code)で、人間の仕事が「AIが直した結果をVPSへ運ぶ配達員」だけになっていました。これは自動化するしかない、ということで作ったのが今回の仕組みです。

できあがった形

最終形はこうなりました。開発機で1コマンド打つと、あとは全部勝手に進みます。

開発機: deploy_ea.ps1 を実行
 ├ MetaEditor CLIで全EAをコンパイル(エラーが1つでもあれば中断)
 └ .mq5 と .ex5 を commit & push
 ↓ (GitHub)
VPS: タスクスケジューラが5分毎に pull_deploy_ea.ps1 を実行
 ├ 新しいコミットがあれば git pull
 ├ リポジトリの .ex5 と配備先の .ex5 をハッシュ比較
 ├ 差があるものだけ MQL5\Experts へコピー(旧版は退避)
 └ 配備したターミナルを自動で再起動
 ↓
MT5: チャート・EA・パラメータ・自動売買ONを自動復元して再稼働
 └ EAが起動通知をDiscordへ送信 ← これが届いたら配備完了の合図

方式は「pull型」を選びました。VPS側からGitHubを定期的に見に行く形です。逆の「push型」(開発機からSSHでVPSへ直接送り込む)も考えましたが、WindowsのVPSにSSHサーバーを立てて受信ポートを開ける手間と管理が増えるので、受信経路が一切いらないpull型にしました。5分間隔のポーリング遅延はEAの更新では実害がありません。