Kill Switch の使用

Kill Switch は、それが有効化されたレベルより下のトラフィックを即座にブロックする緊急用の制御です。今すぐ AI の利用を止める必要があるとき — 例えばデータ漏洩の疑いがあるとき — に使用します。 これは3 つのレベル — Organization、Project、Module Instance（Project Guardian・Project Stratum） — に存在し、それぞれが独立したオン／オフのトグルです（会社自体にはありません）。いずれかのレベルがオンの場合、その下のすべてのトラフィックがブロックされます。 v1.4 は従来の Project Guardian レベルを Module Instance 単位へ一般化したもので、Project 全体を止めずに特定のモジュールだけ — 例えば Stratum インスタンスだけ — を緊急遮断できます。Kill Switch は緊急発動専用であり、Module Instance に通常運用のオン／オフのトグルは別途ありません — 計画的な停止はインスタンスの削除で、判定を行わない運用はポリシー未割り当ての状態で表現します。

​

有効化

プロジェクトの 設定 → 全般 → 危険ゾーン を開き、Kill Switch 有効化 を選択します。 有効な間:

• その下のすべてのトラフィックがゲートウェイでブロックされます — Active な API キーであっても。キーの状態はそのまま維持され、スイッチをクリアした瞬間に再開します（両者は独立しており、すべてのリクエストで別々にチェックされます）。
• 有効なスイッチの下のどこでも、新しい API キーの作成がブロックされます。
• そのレベル配下の Desktop Agent はブロックされたレスポンスを受け取り、AI サービスへの送信リクエストを停止します。

呼び出し元は単一のブロックされたレスポンス（エラーと状態を参照）を受け取りますが、これはどのレベルやリソースが発動したかを意図的に明かしません — その詳細は監査ログと Opticon にのみ送られます。有効化と無効化は監査ログに記録されますが、有効な間にブロックされた試行は監査ログには記録されません（記録されるのは実際の変更のみです）。

​

バッチ経路での動作

リアルタイム経路では、リクエスト・検査・外部送出が 1 つの呼び出しに融合しているため、発動と同時にリクエストがインラインでブロックされます。一方、バッチ経路では受付と完了が時間軸上で分離しているため、同じ目的（即時隔離）が経路の性質に応じて異なる形で執行されます。どの tier の発動であっても、その配下のバッチ経路に波及します。 Stratum のグレード判定バッチ — 外部送信の凍結。 判定は内部分析であり、それ自体では外部への露出を生まないため、判定の演算を止めるのではなく、外部へ出ていくゲートを凍結します。 S3 連携の非識別化バッチ — 即時中断・成果物なし。 このバッチの成果物は顧客ストレージ（tgt）への書き込みそのものであり、処理を続ければ持ち出しが続きます。そのため凍結ではなく中断します。 解除後の再処理は、同じ src の再受付として行います — 非識別化は再実行で同一の結果が再現されるため、中断されたジョブをつなぎ直す復元の概念はありません。

​

復旧

同じ危険ゾーンから Kill Switch を無効化します。トラフィックは通常どおり再開します — このスイッチはポリシーやキーを変更するものではなく、有効な間だけトラフィックをゲートするだけです。