GitHub Pages 記載の取引機構・ロジック実装検証レポート

検証日: 2025年12月2日 対象: AEGIS プロジェクト (GitHub Pages 記載事項 vs 現行コードベース)

本レポートでは、GitHub Pages に記載されている主要な取引機構やロジックが、現在のバックテスト (BT) およびペーパートレード (PT) 環境に実装されているかを検証した結果を報告する。

検証サマリー

検証項目	実装状況	詳細
1. 80:20 バーベル戦略	❌ 未実装	資金配分ロジック（Track A/B）が存在しない。main.py は初期段階。
2. すなっちゃん Spear	⭕️ 実装済	SunacchanSpear クラスおよびモメンタム分析基盤は実装されている。
3. 決算トレード戦略 (v3.0)	❌ 未実装	仕様書 (EARNINGS_PLAY_SPEC.md) はあるがコードが存在しない。
4. イグジットロジック	⭕️ 実装済	各戦略クラス内に個別に実装されている（共通モジュールではない）。
5. Plan I 動的パラメータ調整	⭕️ 実装済	DynamicAdjuster クラスにより実装されている。
6. UW Flow Schema	⚠️ 部分的	APIクライアントは存在するが、戦略への統合とWebSocketが未実装。
7. Crisis Alpha	⭕️ 実装済	CrisisAlpha クラスとして実装されている。

---

詳細検証結果

1. 80:20 バーベル戦略

• ドキュメントの定義: 資金の80%を安全資産（Track A）、20%をリスク資産（Track B: $13k）に配分する構造。
• 現状の実装:
  • AEGIS/strategies/beat_shield.py (Beat Shield) は存在するが、これは「守備的戦略」のロジックであり、ポートフォリオ全体の資金配分を管理するコードではない。
  • AEGIS/core/portfolio_manager.py には Track A / Track B の区分けや、資金配分を強制するロジックが見当たらない。
  • AEGIS/main.py は "Phase 1: The Watcher" の段階であり、マルチ戦略のオーケストレーションや資金管理機能はまだ統合されていない。
• 結論: ドキュメントと実装に大きな乖離がある。現在は「構想」段階であり、コード上は単一のデモ口座（またはバックテスト上の単一資金）で動く形になっている。

2. すなっちゃん Spear

• ドキュメントの定義: モメンタム、ボリューム、GEX谷を利用した短期・攻撃的戦略。
• 現状の実装:
  • AEGIS/strategies/sunacchan_spear.py に完全なロジックが実装されている。
  • パラメータ（SunacchanSpearParams）も「2025-11-29 Discord分析」に基づいて詳細に定義されている。
  • AEGIS/core/momentum.py に必要なテクニカル指標（ROC, RSI, Volume Spike）の実装も確認できた。
• 結論: 実装されている。ただし、実行環境（main.py）からの呼び出し接続が必要。

3. 決算トレード戦略 (v3.0)

• ドキュメントの定義: 決算発表後のドリフト (PEAD) などを狙う戦略。
• 現状の実装:
  • AEGIS/docs/EARNINGS_PLAY_SPEC.md という仕様書は存在する。
  • しかし、AEGIS/strategies/ 配下に該当するコード（例: earnings_play.py）が存在しない。
  • grep 検索でも、仕様書やログ以外に有意なコードヒットなし。
• 結論: 完全に未実装。

4. イグジットロジック

• ドキュメントの定義: 明確な損切り、利確、時間経過による手仕舞いルール。
• 現状の実装:
  • 各戦略クラス（SunacchanSpear, BeatShield, CrisisAlpha）の on_existing_positions メソッド内に個別に実装されている。
  • 実装内容:
    • 損切り（Stop Loss）
    • 利確（Take Profit）
    • 部分利確（Partial Profit）
    • モメンタム反転による即時エグジット
    • DTE（満期までの日数）による強制決済
    • 最大保有日数による決済
• 結論: 実装されている。ただし、戦略ごとにコードが重複しており、共通基盤（core）へのリファクタリングの余地がある。

5. Plan I 動的パラメータ調整

• ドキュメントの定義: 市場環境（IV, トレンド）に応じて、利確・損切り幅やポジションサイズを動的に変更する。
• 現状の実装:
  • AEGIS/strategies/dynamic_adjuster.py に DynamicAdjuster クラスが実装されている。
  • 前日までのデータ（20MA傾き、IV Rank平均、勝率）に基づいて DynamicParams を生成するロジックがある。
• 結論: 実装されている。

6. UW Flow Schema

• ドキュメントの定義: Unusual Whales のオプションフローデータを活用した分析・エントリー。
• 現状の実装:
  • AEGIS/core/unusual_whales.py に API クライアント (UnusualWhalesClient) は実装されている。
  • しかし、WebSocket 接続はスタブ（未実装）状態である。
  • また、SunacchanSpear などの戦略コード内で、この UnusualWhalesClient を使用してエントリー判断を行うロジックが見当たらない（現在は MomentumSignal のみを使用）。
• 結論: データ取得基盤は部分的（RESTのみ）に存在するが、戦略ロジックへの統合が未完了。

7. Crisis Alpha

• ドキュメントの定義: 暴落時に利益を狙うヘッジ戦略。
• 現状の実装:
  • AEGIS/strategies/crisis_alpha.py に実装されている。
  • Long Put や Bear Put Spread を構築するロジックが存在する。
• 結論: 実装されている。

推奨アクション

1. 80:20 バーベル戦略の実装: main.py または portfolio_manager.py に、資金を論理的に分割（Track A/B）して管理する機能を実装すること。
2. オーケストレーターの完成: main.py を拡張し、BeatShield や SunacchanSpear を適切に初期化・実行できるようにすること。現在は "The Watcher"（監視のみ）の状態である。
3. 決算トレードの実装: 仕様書に基づき earnings_play.py を作成すること。
4. UW Flow の統合: SunacchanSpear に Unusual Whales のフロー情報を判定条件として組み込むこと。

---

実装計画

策定日: 2025年12月2日
目的: 検証レポートで指摘された未実装機構を段階的に実装する。

実装範囲

項目	実装内容	優先度
80:20 バーベル戦略	Track A/B 仮想資金管理	高
決算トレード戦略	3戦略（IV Run-up / Expected Move Edge / PEAD）	中
UW Flow 完全統合	戦略へのフローデータ統合	高

---

Phase 1: 80:20 バーベル戦略（資金管理基盤）

1.1 TrackManager クラス作成

新規ファイル: AEGIS/core/track_manager.py

• TrackConfig データクラス: Track A/B の設定を保持
• Track A: 80%配分、$50k初期資金、守備的戦略向け
• Track B: 20%配分、$13k初期資金、攻撃的戦略向け
• TrackManager クラス: 仮想資金管理
• get_available_capital(track_id): Track別の利用可能資金を取得
• allocate_to_trade(track_id, amount): トレードへの資金割り当て
• release_from_trade(track_id, amount): トレード終了時の資金解放
• get_track_positions(track_id): Track別のポジション一覧

1.2 PortfolioManager 拡張

修正ファイル: AEGIS/core/portfolio_manager.py

• PositionDelta に track_id フィールドを追加
• calculate_portfolio_risk() に Track別集計を追加
• Track A/B それぞれのデルタ集計
• Track別のリスクレベル判定
• check_entry_allowed() に Track別限度チェックを追加
• Track別のデルタ上限チェック
• Track別の資金制約チェック

1.3 PT v2 統合

修正ファイル: AEGIS/scripts/run_paper_trading_v2.py

• TrackManager インスタンスを初期化
• 各シナリオ（I, F, H, B, D）を Track A/B に紐付け
• Plan I, F, H → Track A（守備的）
• Plan B, D → Track B（攻撃的）
• トレードログ（pt_trades.jsonl）に track_id を記録

---

Phase 2: UW Flow 完全統合

2.1 フローモニター実装

修正ファイル: AEGIS/core/unusual_whales.py

• FlowMonitor クラスを追加
• RESTポーリングベースのリアルタイム監視（30秒間隔）
• 重複排除機能（_seen_flows セット）
• コールバック機能（新規フロー検知時に戦略に通知）
• start_monitoring(symbols, callback): 監視開始
• stop_monitoring(): 監視停止

2.2 SunacchanSpear 統合

修正ファイル: AEGIS/strategies/sunacchan_spear.py

• SunacchanSpearParams に UW関連パラメータ追加
• require_whale_confirmation: bool = False: Whale確認を必須とするか
• min_whale_premium: float = 50000: 最小Whaleプレミアム
• _is_spear_ready_with_tracking() に UWフローチェックを追加
• flow_validator.validate_flow_quality() を呼び出し
• 有効なSweep/Block検知でエントリー確度を向上
• on_existing_positions() に UWフロー反転検知を追加
• 大口Put買い検知で即時エグジット判定

2.3 BeatShield 統合

修正ファイル: AEGIS/strategies/beat_shield.py

• _is_shield_ready() に UWフローチェックを追加
• 大口Put買いがあれば反転シグナルとして活用
• FlowValidatorで検証済みフローのみ使用

---

Phase 3: 決算トレード戦略（v3.0）

3.1 決算データモジュール

新規ファイル: AEGIS/core/earnings_data.py

• EarningsEvent データクラス
• symbol: 銘柄
• earnings_date: 決算発表日
• timing: "BMO" (Before Market Open) / "AMC" (After Market Close)
• eps_estimate: EPS予想値
• eps_actual: EPS実績値
• EarningsDataProvider クラス
• Barchart統合: 決算スケジュール取得（既存の barchart-scraper/ を活用）
• ThetaData統合: 過去の決算時のIV推移データ取得
• Polygon統合: 決算翌日の株価変動データ取得
• get_upcoming_earnings(days_ahead=14): 今後14日以内の決算予定を取得
• get_historical_iv_runup(symbol, earnings_date): 過去8回分のIV上昇パターンを分析
• get_expected_move(symbol, earnings_date): ATM Straddle価格から期待変動率を計算
• get_actual_move(symbol, earnings_date): 決算翌日の実際の変動率を計算

3.2 決算トレード戦略

新規ファイル: AEGIS/strategies/earnings_play.py

• EarningsPlayStrategy クラス（3戦略統合）

戦略1: IV Run-up（決算前逃げ切り） - evaluate_iv_runup(symbol, earnings_date): IV Run-up判定 - エントリー条件: 決算14日前、過去8回中7回以上でIV上昇パターン確認 - ポジション: ATM Straddle/Strangle ロング - エグジット: 決算発表直前（マーケットクローズ前）に全決済

戦略2: Expected Move Edge（期待値の歪み取り） - evaluate_expected_move_edge(symbol, earnings_date): Expected Move Edge判定 - ケースA（売り有利）: Implied Move > Actual Move × 1.3 → Iron Condor - ケースB（買い有利）: Actual Move > Implied Move × 1.2 → Long Straddle - エグジット: IV Crush後（決算翌日以降）

戦略3: PEAD（Post-Earnings Announcement Drift） - evaluate_pead(symbol, earnings_date, market_data): PEAD判定 - エントリー条件: - ギャップアップ +5%以上 - Opening Range Breakout（寄付きから30分間の高値をブレイク） - 出来高が平均の200%以上 - ポジション: Call買い（順張り） - エグジット: 利確/損切り（通常のイグジットロジック）

• 統合メソッド
• on_new_entries(current_date, ...): 3戦略の統合判定
• on_existing_positions(current_date, ...): ポジション管理

戦略詳細:

戦略	エントリー条件	エグジット条件
IV Run-up	決算14日前、過去8回中7回以上IV上昇	決算直前（クローズ前）
Expected Move Edge	Implied > Actual×1.3 → Iron Condor	IV Crush後
PEAD	ギャップ+5%以上、ORB確認、出来高200%+	利確/損切り

---

実装順序

1. Phase 1: 80:20 バーベル戦略（資金管理基盤）

2. TrackManager → PortfolioManager → PT v2 統合

3. Phase 2: UW Flow 完全統合

4. FlowMonitor → SunacchanSpear → BeatShield

5. Phase 3: 決算トレード戦略

6. EarningsDataProvider → EarningsPlayStrategy

---

依存関係

TrackManager (Phase 1)
    └── PortfolioManager
         └── PT v2 / BT

FlowMonitor (Phase 2)
    └── flow_validator.py (既存)
         └── SunacchanSpear
         └── BeatShield

EarningsDataProvider (Phase 3)
    └── Barchart (既存: barchart-scraper/)
    └── ThetaData (既存: core/theta_provider.py)
    └── Polygon (既存: core/polygon_provider.py)

---

テスト計画

• Phase 1完了後: PT v2 で Track別資金管理の動作確認
• Track A/B それぞれの資金制約が正しく機能するか

• トレードログに track_id が記録されるか

• Phase 2完了後: UWフロー検知のバックテスト

• Sweep/Block検知でエントリー確度が向上するか

• FlowValidatorでダマシが除外されるか

• Phase 3完了後: 過去決算データでの戦略バックテスト

• IV Run-up: 過去8回分のIVパターン分析が正確か
• Expected Move Edge: Implied/Actual比較が有効か
• PEAD: ギャップ+ORB条件で勝率が向上するか

---

実装チェックリスト

• Phase 1.1: TrackManager クラス作成（core/track_manager.py）
• Phase 1.2: PortfolioManager に Track別管理を追加
• Phase 1.3: PT v2 に TrackManager 統合
• Phase 2.1: FlowMonitor 実装（RESTポーリング）
• Phase 2.2: SunacchanSpear に UW Flow 統合
• Phase 2.3: BeatShield に UW Flow 統合
• Phase 3.1: EarningsDataProvider 作成
• Phase 3.2: EarningsPlayStrategy 実装（3戦略）