研究289 エッジ・ディケイ逐次検知ハーネス = フォワード監視を「人間が思い出した時に見る」から「毎時の自動統計判定+Discord警報」へ(VPS常駐・stdlib専用)。閾値はNORM分布ブートストラップで較正: CUSUM κ0.25でS>8=警戒(誤警報中央~464営業日)/S>10=警報(~1254日)・単日フロア-3.39%(11年最悪×1.2=故障検知)・21日平均<p1。初回実測=全口座OK(主力S=2.43)
設計: 実口座equity CSVの日次(day_pct)を実効レバ(lev列)でデレバし、NORM(研究287)を帰無仮説に3系統で判定: ①下方CUSUM=エッジの緩やかな死の最速検知(検出中央: 警戒~244日/警報~486日=日次SR0.097の統計的限界も較正で明示)…
1. 仮説とねらい
検証基盤・方法論に関するノートです。
この検証で確かめたい出発点は次の通りです。
設計: 実口座equity CSVの日次(day_pct)を実効レバ(lev列)でデレバし、NORM(研究287)を帰無仮説に3系統で判定: ①下方CUSUM=エッジの緩やかな死の最速検知(検出中央: 警戒
244日/警報486日=日次SR0.097の統計的限界も較正で明示) ②単日フロア=バックテストに存在しない一日(EA/ブローカー故障) ③21日平均のp1帯逸脱。入出金日は残高急変検知で自動スキップ。状態は_decay_state.json永続・警報遷移時のみwebhook.local.txt(任意設置・git外)へDiscord POST。
2. 検証の設計(どう組んだか)
いきなり走らせる前に、後知恵や偽エッジが入り込まないよう検証の枠組みを先に固めます。
| 項目 | 内容 |
|---|---|
| 時間軸 | H1 |
| 検証期間 | 2026-08 |
この枠組みで、下のステップを順番にくぐらせていきます(どこかで落ちれば不採用)。
3. 検証の手順(ステップ・バイ・ステップ)
ステップ1: 検証ステップ
まず、較正(ブロック・ブートストラップ4000経路): (κ,h)グリッドのARL0とH1検出遅延を実測して閾値決定(κ0.25/h8: ARL0=464日・エッジ死244日・逆転114日 / h10: 1254日・486日・189日)。
ステップ2: 既存システムとの統合評価
次に、実装規律: stdlib専用(VPSのembeddable Python対応)・手計算ユニットテスト4本(tests/test_decay_check.py: CUSUMステップ/フロア即警報/入出金スキップ/累積警戒)・update_forwardへtry/except統合(本処理を壊さない)・–dry-run無影響を確認。
ステップ3: 検証ステップ
続いて、初回実測(2026-08-08): Fintokei主力=OK S=2.43(21日平均+0.013%/日)・HFM=OK S=0.25=現在エッジ劣化の統計的兆候なし。
ステップ4: 検証ステップ
さらに、運用: VPSの毎時update_forwardが自動実行→deploy.logに[DECAY]行・警報時[DECAY-WARN/ALARM]。Discord即時通知が欲しければforward/telemetry/webhook.local.txtにWebhook URLを1行置く(ユーザー任意・git管理外)。
ステップ5: 検証ステップ
加えて、開いている道: (1)レジーム条件付き帰無(提案キュー2)でARL/検出力の改善 (2)スリーブ別PFのディケイ分解(reconcileの自動化版) (3)Personal(HFM)用の帰無分布分離(現在は構成E帰無を流用=k5デレバで近似)。
用語と検証手法
この記事で出てくる主な用語です。
- PF(プロフィットファクター): 総利益÷総損失。1.0超で純利益、値が大きいほど効率的です。
- ロジックと優位性(エッジ): 「ロジック」は売買ルールそのもの(仕組み)。「優位性(エッジ)」はそのロジックが持つ“勝てる性質”(コストや偶然を超えたプラスの期待値)。ロジックは無数にありますが、本物の優位性を持つものはごく一部です。
この検証のつながり
この検証は、過去の次の検証を踏まえています(前回ダメだった→今回こうした、別ロジックとの比較など)。