ステージングで確認できること、できないことを分ける
ステージングは、プラグインの設置、設定保存、WordPress標準のAI Clientを通るテスト、別途用意した外部通知、ロールバックを確認する場所です。一方、本番にしか現れない顧客端末、企業ネットワーク、正規クローラー、決済後処理、キャッシュ、WP-Cronの組み合わせまでは再現できません。
したがって、ProのSmart Protectionをステージングで試し、Human・Bot・Unknownの表示が期待どおりでも、本番の分類精度を証明したことにはなりません。技術的に動くことと、実際の顧客流入を正しく扱えることは別の受け入れ項目です。
本番でしか見えない流入を、先に一覧化する
本番観察の前に、どの流入があるかを業務側と整理します。広告、メール、会員ログイン、決済、検索クローラー、アクセシビリティ支援技術、監視サービス、社内作業、定期処理を並べ、顧客成果と結びつく経路を明確にします。
たとえばステージングでは社内PCから10回だけ試してすべてHumanだったとしても、本番では決済Webhookが毎時動き、検索クローラーが深夜に巡回し、プライバシー保護ブラウザの顧客がUnknownになることがあります。そこで『Botを止める』『Unknownを止める』と先に決めず、各分類がどの操作と成果に対応したかをサンプルで確認します。分類名を正解として扱わないことが、誤停止を減らします。
- 購入・予約・問い合わせなど売上に直結する操作。完了件数と失敗時の代替手段を記す
- ログイン後の会員・顧客サポート。企業ネットワークや共有端末からの利用も試す
- 検索・SNSなど正規クローラーからのアクセス。業務上残すものを運用側で指定する
- キャッシュ更新、監視、WP-Cronなどの自動処理。予定時刻と正常な反復回数を残す
- 編集者・開発者による本番確認。顧客需要と混同しないよう実施時刻を注記する
本番では監視モードで、分類と顧客成果を一緒に見る
本番導入後は、一定期間監視モードを維持します。分類の割合だけでなく、どの機能を要求したか、反復速度、成功・失敗、注文や問い合わせの完了を同じ時間帯で照合します。Unknownは悪質という意味ではなく、判断材料が足りない状態です。少なくとも通常営業日、繁忙時間、夜間の定期処理を一巡させ、分類ごとに代表例を数件確認します。全体比率だけでは少数の高価な処理を見落とすため、費用の大きい経路は個別に見ます。
なお、観測対象はWordPress標準のAI Clientを経由した処理です。直接API、ブラウザからの直接送信、外部サーバー処理は別に把握しない限り、この観察には含まれません。
分類依存の停止ルールには、誤判定の検証を入れる
停止ルールを有効化する前に、実際の顧客操作を複数の端末・ネットワークで試し、必要な機能が完了することを確認します。次に、既知の定期処理やクローラーがどのように記録されるかを見ます。分類名だけで正解を決めず、その扱いが業務目的に合うかで評価します。判定表には『期待分類』ではなく『許可すべき操作』『制御すべき反復』『判断保留』を記載すると、分類モデルが変わっても事業ルールを維持できます。
合格条件には、顧客操作の完了、異常な反復の識別、外部通知の到達、監視モードへ戻せることを含めます。誤判定が一件でも重大な売上損失につながる経路は、観察期間を延長するか別ルールに分けます。
本番観察の結果を、サイト固有の受け入れ記録にする
『本番トラフィック受け入れ記録』には、ステージングで問題なしという結論だけでなく、本番で何を観測し、どの顧客操作が完了し、何を対象外としたかを残します。プラグイン、テーマ、決済、AI連携を更新したときは、この記録を基準に再検証できます。各サンプルには日時、操作、端末・ネットワークの種類、分類、完了結果、費用の増分を記載します。個人を追跡するためではなく、正当な利用パターンが停止条件で失われないかを再現するためです。保存期間と閲覧権限も社内ルールに合わせ、必要以上の個人情報は残しません。
次にサイトで確かめるのは、監視モードの集計とWordPressログを突き合わせ、主要な顧客操作と定期処理を区別できるかです。区別できない経路に対して、分類だけを根拠に停止を有効化しないでください。テーマ、決済、キャッシュ、AI連携を変更したら該当操作だけを再試験できるよう、受け入れ記録から変更チケットへリンクします。
「ステージングで成功しても、本番トラフィックを正しく判定できるとは限らない」の「本番トラフィック受け入れ記録」を、最初の実環境導入に使ってください。AI Cost Guardrails-CNXTを無料でダウンロードし、Monitoringから始め、期待するシグナルと戻し方を確認してから制御を有効にしましょう。