# AIエージェントの緊急停止設計とキルスイッチ実装

> AIエージェントの緊急停止は、LLMの推論経路の外側にトリガー・3段階エスカレーション・監査ログを実装します。EU AI Act第14条は高リスクAIシステムに停止手段を義務付けています。

- Canonical: https://kuucorp.com/blog/agent-kill-switch-emergency-stop-design/
- Date: 2026-08-20
- Last modified: 2026-08-20
- Publisher: Kuu株式会社 (https://kuucorp.com)

---
AIエージェントがコストの上限を超え続けている、あるいは想定外のツールを繰り返し呼び出している——そう気づいたとき、システムプロンプトに「止まってください」と書き足しても止まらない。緊急停止は、モデルの推論に頼らない別の制御経路として最初から設計しておく必要がある。

本記事は[AIエージェントガバナンス](/ai-governance/)のピラーコンテンツと連動しています。

## AIエージェントの緊急停止はなぜプロンプトの指示だけでは効かないのか

> 緊急停止の指示をシステムプロンプトに書いても、プロンプトインジェクションや推論エラーで無視される可能性があり確実性がありません。

エージェントは確率的に動作する。長い文脈の中に埋もれた「絶対に停止せよ」という指示は、メモリの欠落や不安定なワークフロー実行、あるいは悪意ある入力による迂回によって無視されうる。停止機構をモデルの出力やプロンプトに依存させている限り、エージェント自身がその機構を無効化する経路が理論上残る。

したがって緊急停止は、[ポリシーエンジンによる実行時ガードレール](/blog/agent-runtime-policy-engine-guardrails/)と同様に、LLMの推論とは独立したオーケストレーション層・インフラ制御層に置く必要がある。オーケストレーターがAPIキーを失効させる、推論エンドポイントを無効化する、実行環境そのものを停止するといった手段は、エージェントの「意思」を経由しない。EU AI Actの第14条（人間による監督）は、高リスクAIシステムについて「'stop'ボタンまたは類似の手続きによってシステムに介入・中断し、安全な状態で停止させる」能力を人間側に確保するよう求めている。この要件は、停止手段がシステムの外側にあることを前提にしている。

## 停止トリガーはどう設計するか——コスト・エラー率・禁止操作の3系統

> トリガーはコスト閾値・エラー率・禁止操作アクセスの3系統に分け、単発異常と継続異常を区別して検知します。

トリガーを1種類の閾値だけで設計すると、正常な高負荷処理まで止めてしまうか、逆に緩すぎて実害が出てから気づくかのどちらかになる。実務では最低でも3系統を分けて定義する。

1. **コスト系トリガー**: 累計コスト上限・日次コスト上限・トークン消費レートの急増を監視する。単発の高コスト呼び出しと、継続的な暴走を区別するため、瞬間値と移動平均の両方を見る。
2. **エラー率系トリガー**: 連続失敗回数とエラー率のパーセンテージを組み合わせる。1回のツール失敗で止めると誤検知が多く、逆に閾値なしだと壊れたループを放置してしまう。
3. **禁止操作系トリガー**: 認証情報ファイルへのアクセス、force push、データベースの破壊的操作、大量の外部通信など「発生した時点で即座に停止すべき」操作を個別に列挙する。これはコストやエラー率のような連続値ではなく、検知＝即トリガーの二値判定にする。

エージェント安全性に関する仕様である`KILLSWITCH.md`は、この3系統の考え方をYAML形式で機械可読に定義し、エージェント起動時に読み込ませる規約として整理している。ライブラリ依存のないファイル規約であるため、フレームワークをまたいで同じ定義を再利用できる点が実装上のメリットになる。

## エスカレーションは3段階で設計する——スロットル・一時停止・完全停止

> エスカレーションはスロットル・一時停止・完全停止の3段階に分け、異常の深刻度に応じて対応を切り替えます。

トリガーが発火した瞬間にすべてを完全停止すると、軽微な異常でも業務が止まり、運用チームの心理的な「オオカミ少年化」を招く。段階を分けることで、深刻度に応じた反応速度と実害のバランスを取る。

1. **スロットルモード**: 実行速度・並列度を落とし、監視を強化する。処理は継続するが、被害の拡大速度を落とす。
2. **一時停止モード**: 新規タスクの受付を止め、実行中のタスクを安全なチェックポイントまで進めてから待機状態に入る。人間への通知はこの段階で必須にする。
3. **完全停止モード**: エージェントのAPIキー・認証情報を失効させ、推論エンドポイントへのアクセスを遮断する。状態は破棄せず保持し、事後調査と復旧に使えるようにする。

3段階を用意しておくことで、「止めすぎて業務が止まる」と「止めなさすぎて被害が拡大する」の両極端を避けられる。どの段階からどの段階への遷移を自動で行い、どこから人間の承認を必須にするかは、業務の重大性に応じて事前に定義しておく。

## 停止後の監査ログと人間承認オーバーライドはどう設計するか

> 停止イベントは追記専用ログに記録し、再開には明示的な人間承認を必須とすることで説明責任を担保します。

停止機構そのものが改ざん・迂回されては意味がない。トリガーの発火・エスカレーション段階の遷移・人間の承認/却下は、すべて追記専用（append-only）のログに記録する。ログの改ざん防止設計は[監査ログのスキーマと改ざん防止](/blog/audit-log-tamper-proof-schema-design/)で扱ったハッシュチェーンや署名の仕組みと共通する。

再開（オーバーライド）は「エージェントが自分で判断して再開する」経路を持たせてはならない。一時停止・完全停止からの復帰は、常に人間による明示的な承認をトリガーにする。Claude Agent SDKの`PreToolUse`や`SessionStart`/`Stop`といったフックは、ツール呼び出しやセッションのライフサイクルの節目でコールバックを差し込める仕組みで、危険な操作の事前ブロックや、機微な操作への人間承認要求を、エージェントのロジックの外側で実装するための土台になる。停止・再開の判定をこうしたフック層やオーケストレーション層に置くことで、モデルの推論結果に左右されない制御を保てる。

### 規模別の留意点（SMB / エンタープライズ）

**SMB**では、まず禁止操作系トリガー（認証情報アクセス・破壊的コマンド）とコスト上限の2系統だけを最初に実装し、Slack通知＋手動承認の一時停止フローから始めるのが現実的だ。3段階すべてを最初から自動化する必要はない。[KuuのAI運用管理サービス](/services/ai-ops/)では、この最小構成の設計を支援している。

**エンタープライズ**では、複数のエージェント・複数チームにまたがる停止機構を一元管理する必要がある。個々のエージェントごとにキルスイッチを実装するのではなく、[LLMゲートウェイ](/blog/llm-gateway-routing-rate-limiting/)やオーケストレーション基盤の層で全社共通のトリガー定義と承認フローを持たせ、監査ログをSIEMに集約する構成が標準になる。大規模な統制設計は[RDEサービス](/services/rde/)で対応している。

## 参考

- [Article 14: Human Oversight – EU AI Act Service Desk](https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-14)
- [KILLSWITCH.md — The AI Agent Emergency Stop Standard](https://killswitch.md/)
- [Intercept and control agent behavior with hooks – Claude Agent SDK Docs](https://code.claude.com/docs/en/agent-sdk/hooks)

## まとめ

緊急停止は、事後に付け足す機能ではなく、エージェントの推論経路とは独立した制御として最初から設計する対象だ。コスト・エラー率・禁止操作の3系統でトリガーを定義し、スロットル・一時停止・完全停止の3段階でエスカレーションし、停止と再開のすべてを改ざん防止された監査ログに残す。再開には常に人間の明示的な承認を必須にすることで、自動化と説明責任を両立できる。

自社のエージェント運用にキルスイッチの設計が組み込まれているか不安な場合は、[Kuuのエージェントガバナンス支援](/services/ai-ops/)から現状を整理するところから始めてほしい。