https://etherpoc.com/ja/tags/%E7%9B%A3%E6%9F%BB/Recent content in 監査 on FX検証日記HugojaTue, 21 Jul 2026 00:00:00 +0000https://etherpoc.com/ja/posts/audit-verify/Tue, 21 Jul 2026 00:00:00 +0000https://etherpoc.com/ja/posts/audit-verify/<p>実口座で動いているEAのソースコード約2,500行を、全数バグ監査にかけたことがあります。出てきた指摘は20件。再起動で停止ラッチが消える穴のような「即修正すべき実害」から、「検証コードと実機で細部の挙動が違う」という気になる差異まで、重さは様々でした。</p> <p>実害系は優先度順に潰しました(停止状態の永続化、SL無し建玉の穴、発注価格の正規化など)。この記事で書きたいのは、その後に残った「検証コードとの差異」2件の話です。普通の感覚なら「検証と実機は一致すべき。全部直そう」となるところですが、このプロジェクトでは<strong>直す前に必ず測る</strong>ことにしています。修正にもリスクとコストがあり、そして測ってみると、直す価値は差異ごとに全く違うからです。</p> <h2 id="はじめに-このブログと前提の説明">はじめに: このブログと、前提の説明</h2> <p>初めての方向けに。このブログは、私(個人)がFXの自動売買プログラム(EA=MetaTrader5上で動く売買ロジック)を自作し、統計検証の記録を勝敗問わず公開している検証日記です。文中の「研究N」は検証ノートの通し番号。</p> <p>私の開発体制は少し特殊で、<strong>検証用のPythonコード</strong>(過去11年の実データで手法を測る側)と、<strong>実口座で動くMT5のEA</strong>(測った結果を移植した側)の2本立てです。用語はPF=総利益÷総損失(1超で黒字)、DD=資産が最高値からどれだけ下がったか、の2つだけで読めます。</p> <p><img src="https://etherpoc.com/charts/equity.png" alt="図: 確定システムの資産曲線(実データ2015-2026)。"></p> <p><em>図: 検証側が示す「あるべき姿」。この曲線と実機の挙動がズレていないかを数え続けるのが、この記事のテーマである監査です。</em></p> <h2 id="なぜ差異即修正にしないのか">なぜ「差異=即修正」にしないのか</h2> <p>前提の整理から。私の開発フローでは、Pythonの検証基盤が「正」で、MT5のEAはその移植です。移植には必ず細部の判断が入ります。フィルタをどのスリーブに適用するか、オーバーレイをどこまで掛けるか。移植時の解釈が検証側と食い違うと、「検証した姿」と「実際に動いている姿」がズレます。</p> <p>このズレには2種類あります。<strong>性能を変えるズレ</strong>と、<strong>変えないズレ</strong>。前者は直すべきですが、後者を反射的に「直す」と、実機の挙動を変えるという新しいリスクを、便益ゼロで背負うことになります。どちらか見分ける方法は1つしかありません。両方の挙動でバックテストを回して、差を測ることです。</p> <h2 id="件1監査d3-直しても無意味だった差異">件1(監査D3): 直しても無意味だった差異</h2> <p>1件目はequityフィルタの適用範囲です。米国株が200日線を割ったら核のサイズを半分にする防御機構を、検証コードはトレンド核だけに適用しているのに、実機EAは指数スリーブと第2サテライトにも掛けていました。このフィルタが作動している局面は全日数の25%。4分の1の期間で3つのスリーブのサイズが違うのだから、無視できる差には見えません。</p> <p>全期間+期間分割で両方を測りました。</p> <table> <thead> <tr> <th>構成</th> <th>PF</th> <th>月利</th> <th>最大DD</th> </tr> </thead> <tbody> <tr> <td>是正版(検証と一致)</td> <td>1.69</td> <td>+1.060%</td> <td>-8.33%</td> </tr> <tr> <td>現状のEA</td> <td>1.68</td> <td>+1.039%</td> <td>-7.98%</td> </tr> </tbody> </table> <p>月利差は+0.021%。DDに至っては現状のEAの方が0.35pt浅い。未使用期間(2023年以降)だけで見ると月利+1.392% vs +1.405%で、ほぼコインフリップです。取引数は8,478件で完全に同一(このフィルタはサイズだけを変えるため)。</p> <p>判定は「無差」。性能を理由に挙動を変える動機はありません。そしてこの検証の本当の収穫は副産物のほうでした。<strong>実機EAの成績(月利+1.039%/DD-7.98%)が、公表している検証値(+1.060%/-8.33%)からほぼズレていない</strong>ことを、初めて数字で確認できたんです。監査の不合格項目を測りにいったら、システム全体の健全性証明が手に入った形です。</p> <h2 id="件2監査b3-小さいが本物だった差異">件2(監査B3): 小さいが本物だった差異</h2> <p>2件目はカレンダー・スリーブのオーバーレイです。検証コードには存在しない「ボラ調整+equityフィルタ」が、実機のカレンダー・スリーブにだけ掛かっていました。移植時に「他のスリーブと同じ扱いにしておこう」とされた、悪意のない実装差です。</p> <p>これを検証準拠(オーバーレイなし)に修正したところ、事件が起きます。MT5のストラテジーテスター(USDJPY・2022年Q1の窓)でPFが1.27→1.34へ跳ね上がったんです。0.07の改善は大きい。……大きすぎます。この手の「出来すぎた改善」を見たときこそ、全期間で測り直す規律の出番です。</p> <table> <thead> <tr> <th>構成</th> <th>PF</th> <th>月利</th> <th>最大DD</th> </tr> </thead> <tbody> <tr> <td>修正後(検証と一致)</td> <td>1.69</td> <td>+1.060%</td> <td>-8.33%</td> </tr> <tr> <td>修正前</td> <td>1.67</td> <td>+1.049%</td> <td>-8.72%</td> </tr> </tbody> </table> <p>真の差はPF+0.02、月利+0.010%、DDが0.39pt浅くなる程度でした。テスター窓の派手な+0.07は、たまたまその3ヶ月がUSDJPYのカレンダー取引にとって差の出やすい窓だっただけです。</p>