ステージング合格は「設置できた」の確認にすぎない
ステージングでは、管理画面が開く、設定が保存される、テスト操作が記録される、といった技術的な確認ができます。しかし、本番にしか来ない顧客、クローラー、決済後処理、キャッシュ、WP-Cron、Webhookは再現できないことがあります。
そのため、ステージング合格をそのまま停止ルールの本番許可にしません。本番導入は、まず監視モードで観察し、対象経路と通常値を確認する別工程として扱います。ステージングの成果物は『本番でも安全』という宣言ではなく、インストール手順、技術的な不具合、戻し方を確認した記録です。この役割を明記すると、顧客側の承認者も本番観察が必要な理由を理解できます。
本番を触る前に、通信経路と戻し方を一枚にする
『本番導入・受け入れチェックリスト』には、対象機能の開始URL、実行するWordPressプラグイン、WordPress標準のAI Clientを通るか、送信先プロバイダー、成功確認方法を記載します。直接APIまたは外部サーバー経由の処理は保護対象外として分けます。
同じ紙に、変更担当、顧客側の承認者、外部通知先、監視モードへ戻す操作、代替導線を記します。バックアップがあるだけでは十分ではありません。停止ルールの誤作動時に、数分で顧客操作を戻せることを事前に試します。
- 対象となる顧客操作と期待結果。入力、AI応答、完了画面までの再現手順を記す
- WordPress標準のAI Clientを通ることの確認。直接APIと外部サーバー経由は別行へ分ける
- 別途設定した外部通知が実際の担当者へ届くことの確認。営業時間外の代替通知先も一度テストする
- 監視モードへ戻す操作と担当者。管理画面へ入れない場合の連絡・復旧経路も決める
- 失敗時に案内する代替導線。通常フォームや電話番号が実際に利用できるか確認する
本番では監視モードのまま、実際の一日を観察する
導入直後は強制停止を使わず、通常営業時間、定期処理、編集作業を含む本番データを集めます。少なくとも、主要な顧客操作をテスト用アカウントで一回確認し、実際の利用も記録されることを確かめます。ECなら平日昼間だけでなく、注文が多い夕方と決済後処理が走る時間も含めます。コーポレートサイトなら問い合わせと編集者の入稿を分けて観察します。
観察期間中は、記録件数だけでなく、同一操作あたりのリクエスト数、エラーと再試行、時間帯別の変動を見ます。件数がゼロなら安全なのではなく、経路が対象外である可能性を先に調べます。観測表には『通常件数』『最大件数』『成功率』『重複の有無』『顧客成果』を日ごとに残し、停止ルールの根拠へ転用します。
最初に有効化するのは、影響が読みやすい一つのルール
最初のルールは、顧客価値が低いという意味ではなく、誤作動時の影響範囲と戻し方が明確なものを選びます。担当者が待機できる時間に有効化し、別の設定変更やプラグイン更新を同時に行いません。たとえば1日1回の社内要約ジョブなら、失敗しても手作業で補い、顧客向けチャットを巻き込まずに検証できます。反対に購入直前のAI案内は、初回ルールの試験対象としては影響が大きすぎます。
合格条件は『期待する処理が完了する』『別途設定した外部通知が届く』『費用推移が想定内』『15分後もエラーが増えない』などにします。一つでも不合格なら監視モードへ戻し、記録を保存して原因を調べます。外部通知だけ届かなかった場合も、そのまま本番許可にしません。日中は画面を見て気づけても、夜間の通知不達は発見の遅れにつながるため、原因を直して同じ条件で再試験します。
導入完了は、動作確認ではなく受け入れ記録で決める
本番導入の完了記録には、対象経路、対象外経路、観察期間、通常値、有効化したルール、合格結果、戻し方、次回見直し日を残します。これで、将来プラグインやAI連携が変わったときに再確認すべき範囲が分かります。完了記録は保守台帳へ添付し、AI関連プラグインの更新、モデル変更、ドメイン移行が発生したときに再受け入れテストを起動するチェックポイントとして使います。
次にサイトで確かめるのは、監視モードで主要操作が観測でき、別途用意した外部通知とロールバックが実際に機能するかです。そこまで確認してから、最初の一つを有効化しましょう。
「ステージングから本番へ。最初の停止ルールを安全に有効化する手順」の「本番導入・受け入れチェックリスト」を、最初の実環境導入に使ってください。AI Cost Guardrails-CNXTを無料でダウンロードし、Monitoringから始め、期待するシグナルと戻し方を確認してから制御を有効にしましょう。