> ## Documentation Index
> Fetch the complete documentation index at: https://docs.starfort.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Kill Switch の使用

> 緊急時に Starfort プロジェクトの全トラフィックを即座にブロックし、監査記録と再有効化手順に沿って安全に復旧する方法を解説します (Starfort v1.4 版)

**Kill Switch** は、それが有効化されたレベルより下のトラフィックを即座にブロックする緊急用の制御です。今すぐ AI の利用を止める必要があるとき — 例えばデータ漏洩の疑いがあるとき — に使用します。

これは**3 つのレベル** — **Organization**、**Project**、**[Module Instance](/ja/v1.4/concepts/module-instances)（Project Guardian・Project Stratum）** — に存在し、それぞれが独立したオン／オフのトグルです（会社自体にはありません）。**いずれか**のレベルがオンの場合、その下のすべてのトラフィックがブロックされます。

v1.4 は従来の Project Guardian レベルを **Module Instance 単位へ一般化**したもので、Project 全体を止めずに特定のモジュールだけ — 例えば [Stratum](/ja/v1.4/concepts/stratum) インスタンスだけ — を緊急遮断できます。Kill Switch は緊急発動専用であり、Module Instance に通常運用のオン／オフのトグルは別途ありません — 計画的な停止はインスタンスの削除で、判定を行わない運用はポリシー未割り当ての状態で表現します。

<Note>
  Kill Switch を切り替えられるのは **Owner** のみです: Company Owner はその下のすべて、Org Owner はその組織、Project Owner はそのプロジェクトとその Guardian を対象とします。Admin、Member、Viewer は切り替えできません。
</Note>

## 有効化

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

<Frame caption="Kill Switch の有効化（危険ゾーン）">
  <img src="https://mintcdn.com/aimintelligence/-3ie4No4rGti8Jbz/images/v1.3/admin/kill-switch.png?fit=max&auto=format&n=-3ie4No4rGti8Jbz&q=85&s=83320ad3077536e87416a383a8f9bb30" alt="Kill Switch 有効化 ボタンがハイライトされたプロジェクト設定の 危険ゾーン" width="1200" height="1618" data-path="images/v1.3/admin/kill-switch.png" />
</Frame>

有効な間:

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

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

## バッチ経路での動作

リアルタイム経路では、リクエスト・検査・外部送出が 1 つの呼び出しに融合しているため、発動と同時にリクエストがインラインでブロックされます。一方、[バッチ経路](/ja/v1.4/api/batch/overview)では受付と完了が時間軸上で分離しているため、同じ目的（即時隔離）が経路の性質に応じて異なる形で執行されます。どの tier の発動であっても、その配下のバッチ経路に波及します。

**Stratum のグレード判定バッチ — 外部送信の凍結。** 判定は内部分析であり、それ自体では外部への露出を生まないため、判定の演算を止めるのではなく、外部へ出ていくゲートを凍結します。

| バッチのライフサイクル    | 発動時                                                  |
| -------------- | ---------------------------------------------------- |
| 新規バッチの受付       | 拒否 — 受付ゲートでブロックされます                                  |
| 滞留中のキュー・進行中の判定 | 最後まで実行し、結果を保存します                                     |
| 完了判定・外部送信待ち    | **外部送信を凍結** — 「外部送信可」と判定された文書も送信しません                 |
| 二次レビュー         | 人による決裁は内部行為のため進行できますが、決裁で確定した外部送信も凍結されます             |
| 解除             | 保存済みの結果どおり即時再開 — 判定は最後まで実行済みのため、再分類なしで外部送信の承認のみが開きます |

**S3 連携の非識別化バッチ — 即時中断・成果物なし。** このバッチの成果物は顧客ストレージ（`tgt`）への書き込みそのものであり、処理を続ければ持ち出しが続きます。そのため凍結ではなく中断します。

| バッチのライフサイクル           | 発動時                                                 |
| --------------------- | --------------------------------------------------- |
| 新規受付                  | 拒否                                                  |
| 待機中のジョブ（`PENDING`）    | 実行せず失敗として確定（理由 = Kill Switch）                       |
| 進行中のジョブ（`PROCESSING`） | **即時中断** — 成果物を書き込まずに失敗として確定                        |
| ジョブの照会                | 発動中はブロック                                            |
| すでに完了したジョブ            | `tgt` に書き込まれた成果物の遡及回収はありません — 書き込み時点以降は顧客ストレージの領域です |

解除後の再処理は、同じ `src` の再受付として行います — 非識別化は再実行で同一の結果が再現されるため、中断されたジョブをつなぎ直す復元の概念はありません。

## 復旧

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

<Warning>
  Kill Switch は意図的に大雑把に作られています: 単一のルールではなく、その下にある**すべて**をブロックします。対象を絞った変更には、代わりに該当する [Guard Policy](/ja/v1.4/admin/author-guard-policy) を編集してください。
</Warning>
