金融AI・EA本番配備検証：テスト7/7通過でも「完成」と言わない理由
金融AI／AIエージェント研究開発
テスト7/7通過でも「完成」と言わない——EA本番配備で分けるべき3種類の証拠
9月17日、GOLD13へ遅い再エントリーを止めるガードを配備しました。挙動テストは7/7で通過し、リプレイでも5本目以降の遮断を確認しています。それでも完成扱いにはしていません。コードテスト、過去データの再生、本番自然取引は、それぞれ証明できる範囲が違うからです。
本投稿は、私が開発したインジケーターと自動売買ソフト（EA）を、AIエージェントと実口座で研究・検証している開発ログです。成功・失敗・未確認を分けて記録し、平日24時間のトレードライブ配信でも運用状況を公開しています。
証拠1：ロジック単体の挙動テスト
まず、決めた条件がコードどおり動くかを確認しました。4本目は許可、5本目は遮断、6bar以上でepisodeをリセット、warn1/2・LEGACY_HISTORY・staleを除外、BUYとSELLを独立、同一barの重複を加算しない、遮断後にモデル判定や注文へ進まない——この7項目はすべて通過しました。
ここで分かるのは条件分岐が期待どおり動くことです。スプレッドや通信遅延、実際の相場の偏りまでは証明できません。
証拠2：過去episodeのリプレイ
2026年9月17日の記録を使い、ticket 29721052相当のepisode 1本目が許可され、ticket 29721491相当の8本目が遮断されることを確認しました。これにより、実際に保存されたデータ形式でもガードが働くことは確認できました。
一方、リプレイは未来を知らない本番判断を完全には再現しません。入力順序や欠損、接続遅延、再起動など、本番でのみ発生する条件が残ります。
証拠3：本番自然取引
最終的に必要なのは、自然に発生した同方向warn0の5本目以降を入口で止め、guard_rejected / skip_warn0_late_clusterが保存され、signalとorderが発生しないことです。さらに、対応するチャート録画、テレメトリ、heartbeat、注文履歴を同じ時刻で照合します。
この自然取引の証拠は配備時点で未取得です。だから「実装済み」ではあっても「本番効果を証明済み」とは書きません。
変更範囲を限定した理由
今回触ったのは新規エントリーの入口ガードです。EA5、NORMAL、SOUL1の稼働、既存ポジション管理、SL・決済、lot、SL/TP、Quality Gate、AutoTrading、OBS、YouTube配信には変更を加えていません。配備時に未決済1件がありましたが、その建玉の方針や決済操作も変更していません。
複数箇所を同時に変えると、改善・悪化の原因を特定できなくなります。金融AIの研究では、一回の変更範囲を限定し、戻せる状態と比較対象を残すことを優先します。
本番配備後の監視項目
- 定期実行が例外なく終了するか
- 遮断ログが再起動後も重複しないか
- 1〜4本目の有効候補を誤って止めていないか
- 5本目以降の遮断候補がその後どう動いたか
- 録画・テレメトリ・注文履歴の時刻が一致するか
21:15の定期実行はno_breakout / exit=0で正常終了しました。今後は該当episodeが出るまで未証明事項を残し、取れた証拠だけで評価を更新します。
該当する自然取引動画はまだないため、別トレードの録画を流用しません。証拠が揃った時点で動画込みの記事を追加します。
本稿は開発・検証ログであり、利益や将来の性能を保証するものではありません。
なぜテストの種類を混ぜてはいけないのか
単体テストは条件分岐の正しさ、リプレイは保存済みデータとの互換性、本番自然取引は通信・時刻・再起動を含む運用全体を確認します。どれか一つの成功を他へ流用すると、未検証の穴が見えなくなります。
たとえばリプレイで注文を発生させなかったとしても、本番では別プロセスが古いsignalを拾う可能性があります。逆に本番で一度止まっても、同一bar重複や反対方向の扱いが正しいとは限りません。証拠ごとに答えられる質問を限定します。
ロールバックを先に決める
本番配備では「問題が起きたら考える」のでは遅いため、例外増加、正常候補の誤遮断、signalまたはorderの意図しない生成、heartbeat停止を戻す条件にします。変更前ソース、設定、ログ位置を残し、原因調査中でも旧状態へ戻せるようにします。
金融AIは24時間動くため、人が見ていない時間の障害を前提にします。停止条件と復旧条件を同時に定義し、成功時だけでなく失敗時の経路もテスト対象にします。
監視で見る数字
- 候補総数と許可・遮断の割合
- episodeごとの本数分布
- 遮断理由別の件数
- signal生成数とorder送信数の差
- 定期実行の終了コードと処理時間
- 再起動前後の重複処理件数
この数字がなければ「何となく取引が減った」で終わります。変更の影響を入口から注文まで数値で追い、意図した場所だけが変わったかを確認します。
未証明事項を公開する意味
研究開発記事では、完成した機能だけを書くと判断を誤らせます。自然取引の5本目遮断が未確認であること、対応動画がまだないこと、複数episodeでの効果測定が残っていることを明記します。
未証明を明示すれば、次に何を見れば評価が更新されるかが分かります。新しい証拠が出たときに過去記事と比較でき、成功だけを選んで見せることも防げます。
次の本番E2E
該当episode発生時は、候補生成から遮断、永続化、signal非生成、order非送信までを連続確認します。録画は候補時刻と一致するものだけを使い、テレメトリとheartbeatを合わせて公開します。複数回の観測が揃うまでルールの優位性を断定しません。
合格・保留・失敗の判定表
今後の配備では、条件分岐が通っただけなら「単体合格」、保存済みデータで再現できれば「リプレイ合格」、自然取引で録画と注文ログまで一致すれば「本番E2E合格」と表記します。途中の段階を完成と呼びません。
例外、ログ欠損、signalとorderの不一致、再起動後の重複が一つでもあれば保留または失敗です。問題を修正した後は、失敗したケースだけでなく7項目全体を再実行し、別の箇所が壊れていないことを確認します。
記事では変更ファイルや内部情報を無制限に出すのではなく、読者が判断できる入力条件、期待結果、実測結果、未確認事項を示します。成功率だけでなく、再現手順と停止条件を残すことを公開基準にします。
公開基準：本番E2Eでは候補時刻、ガード結果、signal件数、order件数、ポジション変化、録画ファイル、heartbeatを同じticketまたはepisodeへ紐付けます。一つでも対応が取れない場合は判定不能です。複数回の自然取引で再現するまで、単発成功をロジック全体の証明には使いません。
判断に迷うケースは推測で合格にせず、保留として次の観測へ送ります。検証不能な成功談を増やすより、再現できる失敗記録を残す方を優先します。
