SHOTAI · 第6部 · 第24章 戦略の死亡判定と更新 エッジは陳腐化する。階段ではなくループだ。

あなたが検証で見つけたエッジは、見つけた瞬間から劣化し始めている。市場は静止画ではない。 参加者が同じ歪みに群がれば歪みは埋まり、レジームが変われば前提が崩れる。だから運用とは 「正解にたどり着いて終わり」ではなく、死んだエッジを判定し、捨て、また探しに戻る ――終わらないループだ。次に身につけるのは「いつ、何を根拠に、この戦略を捨てるか」を、 痛みが来る前に文章で確定させる技術である。

この記事のサマリ

この章を一言で

あなたが検証で見つけたエッジは、見つけた瞬間から劣化し始めている。 市場は静止画ではない。 参加者が同じ歪みに群がれば歪みは埋まり、レジームが変われば前提が崩れる。だから運用とは「正解にたどり着いて終わり」 ではなく、死んだエッジを判定し、捨て、また探しに戻る――終わらないループだ。第23章で実弾を回し始めたあなたが、 次に身につけるのは「いつ、何を根拠に、この戦略を捨てるか」を、痛みが来る前に文章で確定させる技術である。 この章で覚えるのは、たった一個だ。

   エッジは減衰する。
   ──────────────────────────────
   だから運用は「階段(staircase)」ではなく
   「ループ(loop)」である。

   階段 = 上り続けて到達点に着く（幻想）
   ループ = 検証→運用→死亡判定→再定義→…（現実）

01エッジは減衰する ― なぜ「見つけたら終わり」ではないのか

第10章で「エッジ＝源泉＋裁定で消えない理由＋ベンチマーク超過」と定義した。だが 「裁定で消えにくい」は「永遠に消えない」ではない。 エッジには寿命がある。 エッジが減衰する理由は、抽象論ではなく構造で説明できる。

減衰は「ある日突然ゼロ」ではなく、期待値がじわじわ削られていくのが典型だ。だからこそ 「気づいたら手遅れ」になりやすい。これを1枚の図にする。

02階段(staircase)でなくループ(loop) ― 運用の本当の形

多くの教材は、検証→運用を「上りきって完成」する階段のように描く。これが最初の誤解だ。 当デスクは運用をループとして設計している。

03撤退基準を「事前定義」する ― 3つの死亡条件

ループの心臓は「死亡判定」だ。そしてその判定は、痛みが来てから決めてはいけない。 含み損の渦中で「もう少し様子を見よう」と思った瞬間、基準は気分に乗っ取られる。だから当デスクは死亡条件を 3種類、事前に数値で固定する。

① DD閾値 ― 最大ドローダウン

最も機械的で誤魔化しにくい基準。第20章・第21章で学んだサイズ・テール管理の延長だ。

② レジーム転換 ― 前提が壊れたか

エッジは多くの場合「あるレジームでだけ効く＝条件付き」（第12章）。だからそのレジームが壊れたら、 エッジの前提も壊れている。 当デスクのマクロスタック（米実質金利10Y TIPS／2s10sカーブ状態／hawk-dove NLP／ risk_regime）は、まさにこの「前提が生きているか」を日々監視する装置だ。

③ 期待値の有意な劣化 ― コスト後Rが落ちたか

最も難しいが最も本質的な基準。「最近負けている」は不調かもしれないし、エッジの死かもしれない。 これを分けるのが第17章の統計的有意性だ。

04死亡判定の3層 ― 即死／観察／要再検証

3つの死亡条件（DD／レジーム／期待値）を組み合わせると、判定は単純な「生／死」の二択ではなくなる。 当デスクは3層で切り分ける。

05監視サイクル ― 何を、どの頻度で見るか

死亡条件を決めても、見ていなければ発火しない。 だから「監視は永続」を、具体的な サイクルに落とす。頻度の異なる指標を、頻度の異なる箱に入れる。

当デスクの実装との接続：日次のリスク監視は第9章の risk_regime / curve_state、月次の期待値点検は 第18章の前向き蓄積（公開採点 synchronize に信頼区間で積む）、四半期の正式判定は第10章への復帰トリガー――というように、 監視サイクルは既存の章で作った道具をそのまま使い回す。新しい道具は要らない。要るのは 「見続ける箱を決めて、淡々と回す」ことだけだ。

06ループの全体図 ― 死亡判定から第10章へ

ここまでを1枚に畳む。死亡判定が出たら、第10章（エッジの定義）へ戻る。 これがループの閉じ方だ。

この章の結論：戦略は完成しない。エッジは見つけた瞬間から減衰する。だから運用は、上りきって終わる階段 ではなく、検証→運用→死亡判定→再定義を回し続けるループだ。勝ち続ける人は「死なないエッジ」を持って いるのではなく、死んだエッジを早く正確に判定して捨て、次を探しに戻れる人である。そして当デスクは、 その判定を気分でなく「事前定義した閾値の機械的発火」で行い、「監視は永続」を運用思想の中心に据えている。

体験 ― 今すぐ手を動かす

読んで終わりにしない。自分の戦略の「死に方」を、痛みが来る前に文章で確定させるのがこの章の体験だ。

① 死亡条件を事前に文章化する（3条件）

自分の戦略（または検証中の仮説）について、下表を今、平穏なうちに埋める。

→ ここに数値で書けないなら、その戦略はまだ運用してはいけない。 死に方を決めていない戦略は、 死ぬまで気づけない。

② 監視サイクルに指標を割り付ける

③ ループ復帰を1枚で設計する

「もし③要再検証で死亡と出たら、自分は第10章のどの問い（源泉／消えない理由／ベンチマーク超過）から 再定義を始めるか」を、1〜2行で書く。

→ これを書いておくと、死亡判定が出たときに呆然とせず、淡々と第10章へ戻れる。

アクション ― 次の一歩

① 死亡条件3つを、運用ルール文書に正式に追記する（第23章のスケール基準・第20章のサイズ規則と 同じ文書に）。口頭やイメージではなく、改変履歴が残る形で凍結する（第16章）。

② 監視サイクルをカレンダー化する：日次チェック（即死トリガー）、月次の期待値点検（コスト後R・信頼区間を 公開採点 synchronize 上で更新）、四半期の生死レビュー。当デスクのレジーム指標 （/desk/usdjpy の risk_regime / curve_state / 金利相関）を、死亡条件②の監視に毎営業日 組み込む。

③ 「死亡判定が出たら第10章へ戻る」ループを、自分の運用の標準手順として固定する。 1つの戦略の死は、 運用の終わりではなくループの1周。次の章（第25章）では、戦略でなく「人としての自分が続けるか」の撤退判定に 進む――戦略の死とは別レイヤーの、より重い判定だ。

さらに深掘りするなら――レジーム転換の判定は事件シリーズ /cases、エッジ再定義の作法は 教科書 /learn、そして自分の戦略の現在地を信頼区間で点検するなら /synchronize（公開採点）。検証ループを自分で回し始めたら /research と /synchronize が同行者になる。