停止条件が曖昧だと起きる実害
異常が見えていても、停止判断が定義されていないと続行しやすくなります。結果として手戻りが大きくなり、公開直前での差し戻しが増えます。
- 異常が見えても続行してしまう
- 担当者ごとに止める基準が変わる
- 後からログを見ても判断理由が追えない
- 承認ポイントがあっても、止める条件がなければ機能しない
承認ポイント設計の記事で扱った「どこで確認するか」に対して、本記事は「何が起きたら止めるか」を独立した判断として定義します。
停止条件の5分類
安全条件
- 不適切な出力（規約違反、機密情報露出の疑い）
- 外部送信前に禁止語・禁止行為が検知された
- 未確認の法務・医療・投資助言に該当する可能性
品質条件
- 事実確認が必要な主張に出典が付かない
- 指示と異なる成果物形式が連続発生
- 主要チェック項目（必須見出し、必要リンク等）の欠落
コスト条件
- API利用量や実行回数が想定閾値を超過
- 再試行が増え続け、単位成果あたりのコストが急増
- 夜間バッチで異常な連鎖実行が発生
権限条件
- 想定外の書き込み・削除・公開操作要求
- 承認者権限が必要な処理を一般権限で実行しようとする
- 権限変更操作が事前申請なしで発生
外部依存条件
- 連携API障害、認証失敗、レート制限多発
- 参照先データの欠損・遅延・仕様変更
- 外部サービスの一時停止で結果の正当性が担保できない
即停止・承認待ち・継続監視に分ける
すべてを即停止にすると運用が止まり続けます。すべてを継続監視にすると事故を見逃します。停止条件は3区分で扱います。
| 条件例 | 判定 | 基準 |
|---|---|---|
| 機密情報露出の疑い | 即停止 | 影響範囲が不明でも先に止める |
| 公開前チェックの重要項目欠落 | 承認待ち | 人の確認で進行可否を決める |
| API遅延の一時的上昇 | 継続監視 | 閾値内なら記録して継続、超過で承認待ちへ |
| 予算上限の80%到達 | 承認待ち | 追加実行の可否を責任者判断へ |
| 未承認の権限変更要求 | 即停止 | 権限境界に触れた時点で停止 |
停止時の実務フロー
1. 検知
- 自動検知（ルール、アラート、閾値）
- 手動検知（レビュー担当の発見）
2. 停止
- 実行ジョブ停止
- 外部送信/公開処理の停止
- 影響範囲の暫定固定（対象ID、時刻、対象成果物）
3. 通知
- だれに、何を、どの優先度で伝えるかを固定
- 通知テンプレートに「事象」「影響」「現在状態」を必須化
4. 一次記録
- 発生時刻
- 検知者
- 該当条件（5分類）
- 判定区分（即停止/承認待ち/継続監視）
- 暫定対応
- 次アクション担当
5. 再開判断
- 再開条件を満たしたか
- 再発防止の暫定策が入ったか
- 次回同事象の扱いをルール化したか
誤停止を減らす運用ルール
- 閾値を曖昧にしない（回数・率・金額・時間で定義）
- 例外処理を人の記憶に置かない（記録と期限をセット）
- 停止後の再開条件をセットで決める
- 週次レビューで条件を調整する
週次レビューの土台は運用ログ設計で整え、権限や承認境界は最小ガバナンス設計と整合させると運用しやすくなります。
既存10記事との接続
- 10記事目（承認ポイント設計）: 「どこで確認するか」に対し、本記事は「何で止めるか」を定義
- 最小ガバナンス: 権限・承認・監査ルールを停止条件に落とし込む
- 運用ログ設計: 停止判断を記録し、次回改善へ接続
- VPS検証環境: 外部依存障害時の切り分け先として機能
- ツール役割分担: 検知担当・停止判断担当・再開承認担当を分離しやすくなる
まとめ
停止条件は運用を止めるためではありません。止めるべき時に止まり、理由を残し、再開できる状態を作るための基準です。最初は5分類で十分です。運用を回しながら、週次レビューで増減させていく方が安定します。