監視モードと強制停止は、強弱ではなく目的が違う
監視モードは、実際の通信を止めずに通常値と異常の証拠を集めるための状態です。強制停止は、原因が十分に特定され、放置する損失が顧客影響を上回る範囲にだけ使います。『不安だから止める』『安全そうだから監視する』では、担当者ごとに判断が変わります。
たとえば、同じジョブIDが数秒ごとに繰り返されている再試行ループなら、対象処理を狭く止める根拠があります。一方、ProのSmart Protectionでリニューアル後にUnknownが増えただけで、購入や問い合わせも伸びているなら、すぐ停止すると本当の顧客を失う可能性があります。
判断軸は「原因の確度」と「止めたときの事業影響」
『原因確度×事業影響の判断マトリクス』として二つの軸で四象限を作ると、緊急時でも判断を共有しやすくなります。原因の確度は、反復パターン、同一入力、エラー、発生元、費用増加の対応で評価します。事業影響は、売上、問い合わせ、サポート完了、代替手段の有無で評価します。
判断表では、原因確度と事業影響をそれぞれ高・低だけで終わらせず、根拠を一文で添えます。たとえば『同じジョブが60秒間に40回、すべて同一入力で再実行されたため確度は高い』『この処理は公開記事の下書き専用で、停止しても顧客操作へ影響しない』と書ければ、停止範囲を合意できます。逆に根拠が『いつもより多い気がする』だけなら、監視モードを続けるべき段階です。
- 原因確度が高く影響が低い：確認済みの発生元だけを停止し、15分後に再発有無を判定
- 原因確度が高く影響が高い：有人チャットや通常フォームなど代替導線を用意してから狭く停止
- 原因確度が低く影響が低い：監視モードを続け、次の30分で仮説を一つ否定できる証拠を収集
- 原因確度が低く影響が高い：顧客導線を残し、売上・完了率・反復回数を5〜15分間隔で集中監視
止める場合も、通信経路と終了条件を限定する
停止対象は『AI全部』ではなく、確認できた機能、ジョブ、時間帯など最小単位へ絞ります。AI Cost Guardrails-CNXTが扱えるのはWordPress標準のAI Client経由のリクエストです。直接APIや外部サーバーの処理が原因なら、同製品のルールだけを変更しても止まらないため、対象システム側で対処します。
停止と同時に解除条件を決めます。修正版を一回成功させる、15分間再発しない、費用の増加が止まる、といった観察可能な条件が必要です。解除条件がなければ、一時対応が恒久停止になってしまいます。
監視を選ぶ場合は、放置ではなく確認時刻を約束する
監視モードを選んだら、見る指標と次の判断時刻を決めます。『様子を見る』だけでは、異常が続いても誰も意思決定しません。監視モードの集計にWordPressログと売上・問い合わせ記録を重ね、Proを利用している場合だけSmart ProtectionのHuman・Bot・Unknownも同じ時間窓で確認します。
また、どの変化が起きたら停止へ切り替えるかを先に書きます。たとえば、売上増を伴わない反復送信が10分継続した場合、同一ジョブの再実行が5回以上確認された場合、費用が通常の1時間分を15分で超えた場合です。数値はサイトの通常値から決め、他社のしきい値をそのまま移植しません。
判断理由を一行で残せる状態が、良い運用の基準
良い判断は、後から『なぜ止めたか』『なぜ止めなかったか』を一行で説明できます。確認済み事実、顧客影響、選んだ範囲、次の確認時刻を記録すれば、担当交代や顧客説明にも使えます。記載例は『10時20分、下書き生成ジョブの同一入力が40回反復し、顧客操作への影響がないため当該ジョブのみ停止。10時35分に再確認』です。逆に『Botっぽいので停止』では、証拠も対象も解除条件も不足しています。判断マトリクスを障害チケットへ添付し、各評価を変えた新しい証拠も追記します。
次にサイトで確かめるのは、監視モードの集計、WordPressログ、プロバイダー記録、売上・問い合わせ記録を同じ時間帯で比較できるかです。原因の確度が上がるまでは、広い停止ルールではなく観察を優先してください。判断マトリクスは一度埋めて終わりではなく、新しい証拠が出るたびに時刻付きで更新します。購入完了が伸びたら停止案を狭め、同一入力の反復が判明したら原因確度を上げるなど、最終行に決定者と次の再評価時刻を残します。
「監視モードを続けるか、今すぐ止めるか。証拠と顧客影響で判断する」の「原因確度×事業影響の判断マトリクス」を、最初の実環境導入に使ってください。AI Cost Guardrails-CNXTを無料でダウンロードし、Monitoringから始め、期待するシグナルと戻し方を確認してから制御を有効にしましょう。