Bot CEX 開発ログ

🛠️開発記録#459(2026/2/21)「テールを殺せば戦えるのか ― case_c_v1におけるEXIT構造の再設計と検証」

テールを殺せば、戦えるのか。

これ、実は2段階あります。

段階１

テールが主因だったのか？

段階２

テールを削った後に、残りの分布はエッジを持つのか？

ここを履き違えると、
「改善＝戦える」って錯覚してしまうので、本記事ではそれも踏まえて実例ベースで解説記事をまとめました。(現時点で、段階１はYes寄り。段階２→ まだ未検証です)

直近のcase_c_v1のログを精査すると、平均損益そのものよりも、分布の“端”が問題であることが見えてきました。-94bps、-56bpsという少数の深い被弾が、全体のパフォーマンスを大きく毀損しています。一方で、勝ちトレードは存在しており、構造そのものが完全に破綻しているわけではありません。

本記事では、エントリーは一切変更せず、EXITロジックのみを再設計することで、このテール損失を抑制できるかを検証します。対象ログ範囲を凍結し、executable（ToB）基準PnLで評価し、rawデータを用いた再生バックテストによりEXIT_LOCK_V1の効果を再計算しました。

結論は単純ではありません。10トレードの再計算ではテール損失は大幅に改善し、勝ち毀損も確認されませんでした。しかし、サンプルは限定的であり、全期間での確証には至っていません。

これは最適化の話ではありません。
「勝ちを伸ばす」前に、「致命傷を固定化できるか」という構造の問題です。

テールを殺せば、本当に戦えるのか。
ログと再計算結果をもとに、その可能性を検証します。

Ⅰ. 背景：なぜEXITだけを再設計するのか

case_c_v1の検証を進める中で、最初に直面したのは「微損」という言葉では説明しきれない違和感でした。平均損益だけを見るとマイナス。しかしログを分解すると、その内訳は均質ではありませんでした。

10トレードの実績では、合計 -101bps、平均 -10bps前後という結果でしたが、その損失の大半は -94bps と -56bps という2本の深い被弾によって構成されていました。一方で、+60bps超の勝ちトレードも存在しており、全体が一様に機能不全を起こしているわけではありません。

つまり問題は「期待値が少し足りない」のではなく、

分布のテールが壊れている

という構造的な問題でした。

ここで重要なのは順番です。

  • エントリーが完全に誤っているなら、勝ちトレードは生まれません。
  • しかし現実には、大きく伸びる個体は存在しています。
  • それでもトータルで負けるのは、深い損失が分布を歪めているからです。

この状況で最初に触るべきはどこか。

エントリーをさらに複雑にする前に、まずは「致命傷を固定化できるか」を確認するべきだと判断しました。つまり、攻撃力を高める前に、防御を整えるという順序です。

今回の再設計では、エントリー条件は一切変更していません。case_c_v1の20秒観測×180秒保持という思想も維持しています。変更対象はEXITロジックのみです。

目的は明確です。

  • 深い初動被弾を早期に切る
  • 20秒経過時点で反応のない個体を構造的に負けとみなす
  • 勝ちトレードは壊さない
  • 180秒保持の思想は維持する

この設計が成立すれば、「勝ちを増やす」前に「負けを制御できる」段階に進めます。

今回の検証は最適化ではありません。閾値の微調整でもありません。

これは、

テールを制御すれば、戦える構造に近づくのか

という問いへの実証的アプローチです。

まずはEXITだけでどこまで改善できるのか。
その答えを、ログとraw再計算で確認していきます。

Ⅱ. 検証対象の定義（スコープ凍結）

検証で最も危険なのは、「いつの間にか対象が広がっている」ことです。
ログを追加し、条件を変え、評価期間を混ぜる。その瞬間に、比較は意味を失います。

今回のEXIT再設計では、まず最初にスコープを凍結しました。

1. 対象戦略の固定

検証対象は case_c_v1 のみ とします。

  • continuation_A や imbalance_v1 は含めない
  • ENTRYロジックは変更しない
  • EXITのみ再設計対象

つまり、

ENTRYは凍結、EXITのみを変数とする

という前提を明確にしました。

2. 対象ログ範囲の固定

対象データは以下に限定します。

  • events_20260220.jsonl の 1945行目以降
  • events_20260221.jsonl の 全範囲

ここに含まれる type == "EXIT" のトレードを抽出し、
case_c_v1 のみをフィルタリングしました。

この定義により、検証対象は10トレードに固定されます。

重要なのは、後からログを足さないことです。
“都合の良いサンプル”を混ぜないための凍結です。

3. 時間アンカーの固定

t=0 の定義は以下で統一しました。

  • exit_fill_anchor_ts
  • フォールバック：entry_snapshot.entry_ts

すべての時間判定（3秒、20秒、180秒）は、このアンカー基準で評価します。

ここがブレると、R1やR2の判定が意味を失います。

4. PnL基準の固定（最重要）

評価基準は executable ToB PnL に統一しました。

  • LONG：best_bid
  • SHORT：best_ask

mid価格は使用しません。
realized_pnl_jpy も使用しません。

ログ上では realized_pnl_jpy が null のケースが多く、
評価は pnl_bps_executable および pnl_jpy_raw を用います。

ここを固定しないと、検証結果が揺れます。

5. 再計算手順の固定

rawデータを用いた再生バックテストは、
以下の手順で実施します。

  • 対象ログを切り出し
  • raw bucket（1秒足）データで再計算
  • missing=0 を確認
  • exit_lock_v1 ロジックで再評価

コマンド・手順を明示し、
再現可能な状態を維持します。

6. なぜここまで固定するのか

EXIT_LOCK_V1が有効かどうかを判断するためには、

  • データ範囲が変わらないこと
  • PnL基準が変わらないこと
  • ENTRYが混入しないこと

この3点が絶対条件です。

スコープを凍結することで初めて、

改善がEXITによるものかどうか

を純粋に評価できます。

この章でやったことは地味ですが、
検証としては最重要工程です。

次章では、この凍結された10トレードにおける
現行ロジックの実績を整理します。

Ⅲ. 現行ロジックでの実績（事実）

まずは評価や仮説を挟まず、事実だけを整理します。
対象は前章で凍結した10トレード（case_c_v1）です。

1. サンプル数と基本統計

  • 対象トレード数：n = 10
  • 合計 pnl_bps_executable：-101.4679 bps
  • 平均 pnl_bps_executable：-10.1468 bps / trade
  • 合計 pnl_jpy_raw：-106.035 JPY
  • 平均 pnl_jpy_raw：-10.6035 JPY / trade

この時点で「微損」という印象を持つかもしれません。しかし、平均値だけでは実態は見えません。

2. exit_reason の内訳

exit理由は以下の通りです。

  • CONTINUATION_STOP_LOSS: 5
  • CONTINUATION_TIMEOUT: 3
  • CONTINUATION_COLLAPSE: 2

ここから分かるのは、負けの大半がSTOP_LOSS系であること、そして一定数がTIMEOUTで終了しているという点です。

3. 分布の実態：テールの存在

PnL分布を並べると、構造がはっきりします。

  • -6.5 bps
  • -19.7 bps
  • +4.68 bps
  • -10.4 bps
  • +4.98 bps
  • -94.38 bps
  • -0.08 bps
  • +66.70 bps
  • -56.40 bps
  • +9.71 bps

問題は明白です。

  • -94.38 bps
  • -56.40 bps

この2本で合計 -150 bps超 を失っています。

この2本を除けば、残り8本の合計はプラス圏に近い水準になります。
つまり現行ロジックは、常に負け続けているわけではありません。

4. 構造的な読み取り

ここから読み取れる事実は3つです。

  1. 勝ちトレードは存在する（+66bpsを含む）
  2. 中小負けは比較的コントロールされている
  3. ごく少数の深い被弾が全体を毀損している

平均-10bpsという数字は、戦略全体が弱いことを意味するのではなく、

テール管理が未完成である

ことを示しています。

5. 「微損」の正体

この段階で重要なのは、
現行ロジックが完全に破綻しているわけではないという点です。

  • 勝ちは伸びている
  • TIMEOUTは極端に重くない
  • しかしSTOP_LOSSの一部が致命傷になる

これは期待値不足というよりも、

分布の非対称性が制御されていない状態

と表現する方が正確です。

この事実を出発点として、次章では
EXIT_LOCK_V1を適用した場合に何が変わるのかを、raw再計算で確認します。

ここからが本題です。

Ⅳ. EXIT_LOCK_V1の設計思想

前章で確認した通り、問題は平均値ではなく「分布のテール」にありました。
であれば、設計の出発点も明確です。

勝ちを増やす前に、致命傷を固定化する。

EXIT_LOCK_V1は、この一点に特化したEXIT再設計です。
ENTRYロジックは変更しません。case_c_v1の「20秒観測×180秒保持」という思想も維持します。

目的は次の4つです。

  1. 初動で致命的に崩れる個体を早期に切る
  2. 20秒経過時点で反応しない個体を構造的に負けとみなす
  3. 伸びた勝ちは守る
  4. 最大保持時間の思想は崩さない
  • 実績: -10.1468 bps/trade
  • シミュレーション: +3.2518 bps/trade
  • 改善: +13.3986 bps/trade

「僅かに正に寄っている」。
ただし全体判断は別で、19件カバー全体ではまだ -0.6581 bps/trade の微負でした。

1. 設計の前提条件

まず、評価の基準を固定しました。

  • PnLは executable ToB 基準（LONG=best_bid、SHORT=best_ask）
  • t=0は exit_fill_anchor_ts（fallbackはentry_ts）
  • 判定は時間アンカー基準で統一
  • 窓内の評価は「最初の1点のみ」

特に「最初の1点のみ」というルールは重要です。
平均値や複数tick評価は一見安定しますが、環境ノイズやAPI遅延で判定がブレやすくなります。再現性を優先するため、評価点は固定しました。

2. R1：T3_CUT（初動致命カット）

  • 判定区間：t ∈ [3秒, 6秒]
  • 条件：PnL ≤ -10bps

これは「初動で明らかに崩れている個体」を固定的に切るためのルールです。

-94bpsや-56bpsのような深い被弾は、ほぼ確実にこの区間で-10bpsを通過しています。
R1は、この“崩壊の始まり”を止めるための安全弁です。

優先順位は最上位。
深い被弾を許容しないことが第一目的です。

3. R2：T20_NO_TRANSLATION（無反応負けの固定化）

  • 判定区間：t ∈ [20秒, 25秒]
  • 条件：
    • mfe_bps_so_far < +1.0
    • pnl_bps <= -6.0
    • かつ spread_bps < 8.0（spread guard）

20秒観測というcase_c_v1の思想に基づき、

20秒経過してもほぼ動かなかった個体は、構造的に負けとみなす

という判断を明文化したルールです。

spread guardを設けたのは、コストノイズによる誤発火を防ぐためです。
荒い板環境ではR2を無効化し、ノイズで負けを固定しない設計としました。

4. R3：TRAIL_PROTECT（勝ちの保護）

  • 発動開始：20秒以降
  • 条件：
    • mfe_bps_so_far ≥ +4.0
    • ドローダウン ≥ 2.0bps
    • 現在PnL ≥ 0.0bps

ここで重要なのは「現在PnL ≥ 0」という条件です。

勝ちを早く取りすぎないこと、そして勝ち毀損を防ぐことを優先しました。
攻撃的なトレイルではなく、あくまで“保守的な保護”です。

5. R4：TIMEOUT_180

  • 最大保持時間：180秒

case_c_v1の保持思想を維持するための最終出口です。
R1〜R3で該当しなければ、180秒でクローズします。

6. 優先順位

ルールの優先順位は明確です。

R1 → R2 → R3 → R4

  • まず致命傷を止める
  • 次に無反応負けを固定する
  • その後、勝ちを守る
  • 最後に時間で締める

この順序は「期待値最大化」ではなく、

テール管理を最優先する

という思想を反映しています。

7. 設計の核心

EXIT_LOCK_V1は、利益を伸ばすためのロジックではありません。
これは「損失分布を制御するためのロジック」です。

勝ち1本を守るよりも、-94bpsを止める方が戦略全体への影響は大きい。
この非対称性を前提に設計しています。

次章では、このEXIT_LOCK_V1をrawデータで再生し、
実際にどれだけテールが抑制されるのかを確認します。

Ⅴ. raw再生バックテスト手順

EXIT_LOCK_V1の有効性を評価するにあたり、最も重要だったのは「ログの見た目」ではなく、同一トレードをrawデータで再生し直すことでした。

単に閾値を変えて“もしこうだったら”と想像するのではなく、
実際に約定履歴と1秒bucketデータを用いて、EXIT判定を再構築します。

ここでは、その手順を明示します。

1. 対象ログの切り出し

まず、スコープで凍結したログ範囲をそのまま切り出します。

tail -n +1945 trade_execution_logs/events_20260220.jsonl > /tmp/events_20260220_from1945.jsonl

対象は以下の2ファイルです。

  • /tmp/events_20260220_from1945.jsonl
  • trade_execution_logs/events_20260221.jsonl

ここで重要なのは、対象範囲を変更しないことです。

2. rawデータを用いたEXIT再生

次に、raw bucketデータ（1秒足）を使用して、
同一トレードのEXIT判定を再計算します。

python scripts/analysis/backtest_exit_lock_v1.py \
  --logs /tmp/events_20260220_from1945.jsonl trade_execution_logs/events_20260221.jsonl \
  --raw-glob 'data/raw/buckets_1s_2026022*.jsonl' \
  --output-json /tmp/exit_lock_v1_backtest_target10.json

このスクリプトは以下を行います。

  1. 対象ログからENTRY/EXIT情報を抽出
  2. raw bucketデータで時系列を再構築
  3. EXIT_LOCK_V1ロジックを適用
  4. 実際のexitとの差分を算出

3. 確認ポイント

再生結果で必ず確認する項目は以下です。

  • n（対象トレード数）
  • missing（raw再構築不能トレード数）
  • 平均 pnl_bps
  • 勝ち毀損数
  • exitタイプ内訳（T3 / T20 / TRAIL / TIMEOUT）

今回の対象10トレードでは、

  • n=10
  • missing=0
  • 平均 +3.25 bps
  • 勝ち毀損 0

という結果が得られました。

4. なぜraw再生が必要か

通常のログ比較だけでは、EXITロジックの真の効果は測定できません。

理由は3つあります。

  1. 実行環境の非同期性
  2. ログ時点PnLと実行可能PnLの差異
  3. EXIT判定タイミングの揺れ

raw再生では、

  • executable ToB基準PnL
  • t=0アンカー固定
  • 判定窓の再構築

を行うため、純粋にロジック差分だけを評価できます。

5. 注意点

この10トレードは有益なサンプルですが、
統計的に十分とは言えません。

また、全55トレード中rawカバーは19件であり、
imbalance_v1などは対象外です。

したがって、

この結果は「示唆」であって「確証」ではない

という位置付けを明確にします。

6. この工程の意味

raw再生バックテストは、単なる改善確認ではありません。

それは、

EXIT_LOCK_V1がテール損失を構造的に抑制できるか

を検証するための基盤です。

この工程を経て初めて、
EXIT設計が“感覚”ではなく“データ”に基づくものになります。

次章では、この再計算結果を定量的に整理し、
テール抑制の実効性を評価します。

Ⅵ. 再計算結果：+3.25bpsへの改善

前章で示した手順に従い、凍結した10トレードをrawデータで再生し、EXIT_LOCK_V1を適用した場合の損益を再計算しました。

ここでは、事実だけを整理します。

1. 再計算の概要

対象：case_c_v1 10トレード
raw再構築：missing=0
判定基準：executable ToB PnL

再計算結果は以下の通りです。

  • 平均 pnl_bps = +3.2518 bps / trade
  • 現行ロジック平均との差分 = +13.3986 bps / trade
  • 勝ち毀損数 = 0

現行ロジックでは平均 -10.1468 bps でしたが、
EXIT_LOCK_V1適用後は +3.25 bps へ転換しています。

2. 改善の源泉はどこか

改善の大半は、2本の深い被弾に由来します。

現行ロジック：

  • -94.38 bps
  • -56.40 bps
  • 合計 -150.78 bps

EXIT_LOCK_V1再計算後：

  • 合計 -16.20 bps

この2本だけで +134.59 bps の改善が発生しています。

つまり、

改善の本質はテール制御である

ということが明確になりました。

3. exitタイプの変化

再計算後のexit内訳は以下の通りです。

  • TRAIL_PROTECT: 7
  • T3_CUT: 2
  • T20_NO_TRANSLATION: 1

ここから読み取れるのは、

  • 深い被弾はT3_CUTで止まっている
  • 勝ちはTRAILで守られている
  • R2は限定的に発火している

という構造です。

4. 勝ち毀損ゼロの意味

今回の10トレードでは、

勝ちトレードの毀損は確認されませんでした。

これはEXIT_LOCK_V1の設計思想通りの結果です。

  • 攻撃的なトレイルは行っていない
  • R1/R2は負け側に寄せたルール
  • R3は保守的

そのため、テールを削りながら勝ちは維持できています。

5. それでも「確証」ではない理由

重要なのは、これは10トレードの結果であるという点です。

  • 全55トレード中、rawカバーは19件
  • imbalance_v1は対象外
  • レジーム偏りの可能性あり

したがって、この結果は

EXIT_LOCK_V1が理論上有効であることの示唆

であって、完全な証明ではありません。

6. 本質的な示唆

今回の再計算で明確になったのは、

  • 現行ロジックの問題は「期待値不足」ではなく
  • 「テール未制御」であった可能性が高い

という点です。

-94bpsと-56bpsを抑制できれば、
分布は大きく変わります。

そして、その改善幅は偶然レベルではありません。

7. 結論

EXIT_LOCK_V1は、

  • 深い被弾を抑制できる可能性が高い
  • 勝ちを壊していない
  • 平均損益をプラス圏へ転換し得る

という結果を示しました。

次に問うべきは、

この改善がライブ環境でも再現するのか

という点です。

ここからは理論ではなく、
実運用での継続検証に入ります。

Ⅶ. それでも「微損」に見える理由

10トレードのraw再計算では、平均 +3.25bps という改善が確認されました。
深いテール損失も抑制され、勝ち毀損もゼロでした。

それでもなお、「全体としてはまだ微損ではないか」という感覚が残ります。

なぜか。

1. カバレッジの問題

まず、raw再計算が可能だったのは全55トレード中19件のみです。
今回詳しく検証したcase_c_v1の10トレードはその一部に過ぎません。

  • imbalance_v1の36トレードはrawカバー外
  • continuation_Aも一部のみ

つまり、

EXIT_LOCK_V1の効果が確認できたのは限定サンプル

という事実があります。

統計的な確証には至っていません。

2. 平均値と分布のズレ

現行ロジックでの10トレードは平均 -10bpsでしたが、
その正体は-94bpsと-56bpsの2本に支配されていました。

EXIT_LOCK_V1でこの2本を抑制すれば、分布は改善します。
しかし、それでも全体サンプルを広げたときに、

  • 小さなジリ負けが積み重なる可能性
  • TIMEOUT負けが増える可能性
  • レジーム変化による挙動の変化

が残ります。

テールを抑えたからといって、
必ずしも安定的な正の期待値になるとは限りません。

3. レジーム依存性

今回の対象期間は、週末・祝日を含む特殊な相場環境でした。

  • 流動性の変化
  • スプレッドの拡大
  • 約定特性の変化

これらはEXITロジックに直接影響します。

テール抑制が特定環境でのみ機能している可能性も否定できません。

4. 「改善」と「黒字」は別物

+3.25bpsという改善は明確な前進ですが、

  • それが継続的に再現するか
  • 母数が増えても維持されるか
  • 実運用コストを含めても残るか

はまだ未検証です。

改善は確認できましたが、

それが黒字ランに直結するとはまだ言えない

というのが正確な位置付けです。

5. 本質的な理由

「微損に見える」最大の理由は、

EXIT_LOCK_V1は防御設計であり、攻撃設計ではない

という点にあります。

  • 深い負けを削ることはできる
  • しかし勝ちを積極的に増やす設計ではない

そのため、

  • 大きなマイナスは減る
  • しかし小さなプラスが爆発的に増えるわけではない

という中間状態になります。

6. 現在地の整理

現時点で言えるのは、

  • テール制御は有効である可能性が高い
  • 勝ち毀損は確認されていない
  • しかし母数不足とレジーム依存の問題が残る

ということです。

これは悲観材料ではありません。

むしろ、

構造の第一段階が整った段階

と見るのが妥当です。

次章では、この前提を踏まえ、
現在登録している仮説群（H1〜H6）を整理し、
ライブ検証の基準を明確化します。

Ⅷ. 仮説登録（Hypothesis Register）

ここまでで確認できたのは、「EXIT_LOCK_V1は理論上テールを抑制できる」という事実です。
しかし、これはまだ“確証”ではありません。

そこで本章では、検証の軸を明文化します。
感覚で判断しないために、仮説を登録し、判定条件を固定します。

H1. テール損失抑制が主エッジである

仮説
EXIT_LOCK_V1の改善の源泉は、深い損失（テール）の抑制である。

評価指標

  • pnl_bps_executable <= -40 の件数
  • 最小損失（min pnl_bps_executable）

ベースライン（D1）

  • 10トレード中 2本が <= -40bps
  • 最小値 -94.38bps

次RUN目標（case_c 30本）

  • <= -40bps が 0〜1本
  • 最小値 > -60bps
    （強目標：最小値 > -40bps）

反証条件

  • 30本中2本以上が <= -40bps
  • いずれか1本でも <= -80bps

この仮説が否定されれば、EXIT設計は根本的に再考が必要です。

H2. EVは正方向に維持される

仮説
EXIT_LOCK_V1適用後、case_c_v1の平均損益は正方向を維持する。

評価指標

  • case_c exits の平均 pnl_bps_executable

ベースライン（旧ロジック）

  • -10.1468 bps / trade

リプレイ期待値

  • +3.2518 bps / trade

次RUN目標（30本）

  • 平均 ≥ +1.0 bps

反証条件

  • 平均 < -1.0 bps

ここで重要なのは、「+3bpsを再現する」ことではありません。
最低限、正方向を維持できるかが焦点です。

H3. R1優先戦略は合理的である

仮説
深い被弾の抑制効果は、勝ち1本を失う可能性を上回る。

ベースライン

  • 10トレードで +133.98bps の改善
  • 仮に -9bps の勝ち毀損が1本あっても +124bps 余る

評価観点

  • テール抑制による純改善幅
  • 勝ち毀損の発生有無

R1を弱めるかどうかは、この仮説の成否次第です。

H4. R2のspread guardは誤爆を防げている

仮説
spread_bps >= 8.0 の場合、R2は正しく無効化される。

評価指標

  • CONTINUATION_T20_NO_TRANSLATION のうち
    t20_sample_spread_bps >= 8.0 の件数

目標

  • 違反 0件

R2は誤爆リスクが最も高いルールです。
ここが破綻すると勝ち毀損が発生します。

H5. 観測フィールドは完全である

仮説
EXIT_LOCK_V1の判定フィールドは全件で取得できる。

評価指標

  • exit_lock_v1_state
  • t3_sample_*
  • t20_sample_*
  • exit_lock_v1_timeout_debug

の非null率

目標

  • 100%

観測不能なEXITは検証不能です。

H6. 評価基準はexecutableに統一されている

仮説
戦略評価は pnl_bps_executable および pnl_jpy_raw を使用し、
realized_pnl_jpy には依存しない。

理由

  • realized値はnullが多い
  • executable基準が一貫性を担保する

この章の意味

Hypothesis Registerの目的は、
「都合の良い解釈」を防ぐことです。

次RUNで起きることを、

  • SUPPORTED
  • WEAKLY_SUPPORTED
  • UNRESOLVED
  • FALSIFIED

のいずれかで機械的に評価します。

EXIT_LOCK_V1が本当に有効かどうかは、
この登録済み仮説でのみ判断します。

感覚ではなく、条件で決める。

それが、今回の検証の前提です。

Ⅸ. 次RUNで検証すること

EXIT_LOCK_V1は理論上テール損失を抑制できることが示唆されました。
しかし、これはまだ「再計算結果」に過ぎません。

次に必要なのは、

ライブRUNでの再現性確認

です。

ここでは、次RUNで具体的に何を検証するのかを明確にします。

1. テール損失の抑制（H1の検証）

最優先で確認するのはテールです。

確認指標

  • pnl_bps_executable <= -40 の本数
  • 最小損失（min pnl_bps_executable）

目標（case_c 30本）

  • <= -40bps が 0〜1本
  • 最小値 > -60bps
    （強目標：最小値 > -40bps）

ここが改善していなければ、EXIT_LOCK_V1は失敗です。

2. 平均EVの方向性（H2の検証）

次に確認するのは、平均値が正方向に維持されるかどうかです。

確認指標

  • case_c exits の平均 pnl_bps_executable

目標

  • ≥ +1.0 bps

再計算で得た +3.25bps をそのまま要求しません。
まずは正方向を維持できるかどうかが焦点です。

3. R2の誤爆監視（H4の検証）

R2はテール制御の補助ルールですが、
最も誤爆リスクが高い部分です。

確認項目

  • CONTINUATION_T20_NO_TRANSLATION 発火数
  • 発火時の t20_sample_spread_bps
  • 発火時の t20_sample_mfe_bps

目標

  • spread guard違反 0件
  • 勝ちトレードの誤カット 0件

ここが崩れると、勝ち毀損が発生します。

4. TIMEOUTの性質

テールを削った結果、
TIMEOUTが増えていないかを確認します。

確認指標

  • CONTINUATION_TIMEOUT の本数
  • TIMEOUT平均PnL

テール抑制の代わりにジリ負けが増えるなら、
設計の第二段階が必要になります。

5. 観測フィールドの完全性（H5の検証）

EXIT_LOCK_V1は観測ログに依存します。

確認項目

  • exit_lock_v1_state
  • t3_sample_*
  • t20_sample_*
  • exit_lock_v1_timeout_debug

目標

  • 欠損 0件

観測が揃っていなければ、検証は成立しません。

6. 判定基準の厳守

次RUNでは、以下を徹底します。

  1. 対象ログ範囲を凍結
  2. KPIを機械的に算出
  3. Hypothesis Registerに基づいて判定
  4. 条件を満たさない限りconfig変更をしない

感覚的な「良さそう」は排除します。

7. 判断ライン

次RUN終了時に、

  • H1が支持され
  • H2が支持され
  • H4/H5に問題がない

場合のみ、EXIT_LOCK_V1を本格採用します。

それ以外は、

  • 閾値調整
  • R2例外拡張
  • あるいはENTRY再検討

へ進みます。

8. このフェーズの意味

今回のRUNは最適化ではありません。

  • 勝ちを最大化するフェーズではない
  • 攻撃力を上げる段階でもない

これは、

「戦える土台」を固めるフェーズ

です。

テールを制御できるか。
それが確認できれば、次に進めます。

できなければ、設計をやり直します。

このRUNは、その分岐点です。

Ⅹ. 結論：今は最適化ではなく、構造の固定化フェーズ

今回の検証で明らかになったのは、「もっと良いエントリーを探すべきだ」という結論ではありませんでした。

問題の本質は、エッジの有無ではなく、分布の管理にありました。

  • 勝ちは存在する
  • 伸びる個体もある
  • しかし少数の深い被弾が全体を破壊している

この状況でやるべきことは、勝率を上げることでも、利幅を広げることでもありません。

まず、負け構造を固定化すること。

EXIT_LOCK_V1はそのための設計です。

  • 初動で崩れる個体を止める（R1）
  • 20秒で反応しない個体を負けとみなす（R2）
  • 勝ちは壊さない（R3）
  • 保持思想は維持する（R4）

これは“最適化”ではありません。
攻撃的な調整でもありません。

むしろ逆です。

これ以上悪化しない構造を作る

ための保守設計です。

なぜ今、最適化ではないのか

最適化とは、

  • 閾値を詰める
  • 勝ちを最大化する
  • EVを引き上げる

といった作業です。

しかし、テールが制御できていない状態で最適化を始めると、
分布はさらに不安定になります。

まず必要なのは、

  • -94bpsの再発を防げるか
  • -56bpsが再現しないか
  • 深い損失が構造的に排除されるか

これが確認できて初めて、
“期待値を押し上げる”段階に進めます。

今のフェーズの位置付け

現在は、

攻撃フェーズではなく、防御の固定化フェーズ

です。

  • テールを削る
  • 勝ちを守る
  • 観測を完全にする
  • 仮説を機械的に評価する

この積み重ねがなければ、
一時的な黒字は出ても再現性はありません。

最後に

テールを殺せば、本当に戦えるのか。

その答えはまだ確定していません。
しかし、少なくとも方向性は見えています。

最適化はその後です。

今は、構造を固定する。
戦略が壊れない形にする。

「致命傷で即死しなくなったかもしれない」

それが、次に進むための前提条件です。

-Bot, CEX, 開発ログ