マクロイベント後リリース・ヘッジリセットチェックリスト

最初のスパイク後、ヘッジは方向は正しくてもタイミングがずれることがあります。

リセットは柔軟な裁量ではなく、固定時間で義務付けます。

設定:

タイマーを逃した場合は、デフォルトで複雑さを減らし、陳腐化したオーバーレイを削除します。

• `T+1分`: 現在のヘッジレッグでスプレッドと深度を確認
• `T+5分`: ヘッジ比率が元のデルタ/ベガ目標をまだ満たしているか確認
• `T+15分`: 維持・縮小・再構成のいずれかを確定

ポートフォリオネットはレッグの問題を隠します。

各レッグごとに取得:

最小条件を下回る約定品質、またはリスク許容を超える寄与があればそのレッグは除外します。

レッグが偏ると、全体はヘッジ済みに見えて実リスクが別のポイントに逃げます。

• 実際の約定数量と計画数量の差
• 新しいIV下でのガンマ寄与
• 短期ヘッジを使う場合の時間劣化感度
• リリース後リプライシング後のアサイン露出

ヘッジドリフトは、維持コストが上がった古いレイヤーから始まることが多いです。

事前に:

リセット時:

目的は予測精度の向上ではなく、脆弱性の削減です。

• 各レイヤーを「時間依存」か「安定」に分類
• スプレッドと深度で陳腐化閾値を定義
• 閾値を超えた際、どのレイヤーが自動で離脱するか定義
• 時間依存レイヤーが想定スリッページの2倍を超える場合、まずそのレイヤーをクローズ
• 安定レイヤーが有効なら必要最小サイズを維持
• 両方がドリフトした場合はクリーンな中立状態へ移行

同じルールで全シナリオを扱ってはいけません。

### シナリオA: 方向が想定どおり継続

### シナリオB: 最初の方向が逆転

### シナリオC: 継続方向が不明

• 深度が増しの再ヘッジを許容するときのみベースヘッジを維持
• 高コスト再ヘッジのあるオプションヘッジは削減
• イベント後のヘッジ損失上限をより厳格に設定
• デルタ側だけでなく、スプレッド拡大に敏感なレッグも削減
• 流動性フルのレッグを先にクローズ
• 実行信頼度が回復したときのみデルタニュートラル再計算
• 一時的ノイズとみなし、低コストの安定レギュレーションヘッジのみ保持
• 最初の15分は新規ヘッジ複雑化を避ける
• スプレッドと流動性の安定窓の後でのみ再開

多くのチームは、ヘッジのコストが上がる瞬間の監視を忘れます。

「未ヘッジ警告」を明示:

警告時の強制シーケンス:

1) オプションレイヤーを除去 2) 時間依存レイヤーを縮小 3) 陳腐露出をフラット化 4) フラット化後にのみテーマを再評価

• 3本中2本レッグが実行予算を超えた場合
• T+5後もヘッジ損失が回復しない場合
• スプレッド膨張で再ヘッジが予備キャップを超える場合

イベント後のリセットは毎回繰り返すルーチンです。

イベントごとに記録:

この履歴をチームテンプレートとして次回に活かします。

• どのレイヤーをリセットしたか
• 最初の警告がどれだったか
• 各タイマー時点の実施アクション
• リセットしなかった項目と理由