更新時刻を起点に、変わったものを一列に並べる
「プラグインを更新したから原因はそれだ」と決めつける前に、同じ時間帯の変更を洗い出します。自動更新では複数プラグインが続けて変わることがあり、テーマ、PHP、キャッシュ、接続先モデルの変更が重なっている場合もあります。
更新前後30分のバージョン、設定差分、デプロイ履歴、Cron登録数を残します。利用急増の開始時刻が更新より前なら、別原因を優先できます。
変更台帳には、更新ボタンを押した時刻だけでなく、新しいコードが実際に動き始めた時刻も残します。キャッシュやキューのため、更新が午前1時でも新しい挙動が午前3時から始まることがあります。費用グラフの折れ目と実行ログを分単位で重ね、時間的な前後関係を証拠にします。
本番を戻す前に、増えた処理名を特定する
総リクエスト数だけでは、どの機能が増えたか分かりません。投稿保存、商品更新、フォーム送信、Cron、Webhookなど、WordPressの動作単位で件数を比較します。更新によって従来は手動だった要約が自動実行になった、保存フックが下書きにも反応するようになった、といった仕様変更もあります。
たとえば1記事の公開で従来1回だった要約が、自動保存5回、改訂保存1回、公開1回の計7回になっていれば、アクセスが同じでも費用は7倍です。テスト投稿を一つ用意し、操作ごとに相関IDを付けて、どの保存イベントが送信を生んだか数えます。
- 1操作あたりのAI送信回数
- 新規・更新・自動保存での発火条件
- Cronイベントの追加と実行間隔
- 失敗応答に対する再試行設定
- 利用モデルと入力・出力トークンの変化
ステージングでは、更新前後を同じ入力で比べる
本番データのコピーを必要最小限にし、同じ投稿・同じ操作・同じモデルで旧版と新版を比較します。見るのは画面の結果だけではありません。リクエスト数、トークン、処理時間、保存回数、再試行を並べ、どの差が費用へつながったかを確認します。
直接ロールバックできない場合は、新しく追加されたAI機能だけを無効化できるか調べます。影響範囲の狭い変更ほど、顧客機能を残したまま検証できます。
比較環境では同じ入力データと同じモデルを使い、キャッシュ条件も揃えます。旧版はキャッシュ済み、新版は未キャッシュという状態では差を評価できません。それぞれ3回ずつ実行し、初回と2回目以降を分けてリクエスト数、トークン、処理時間を記録します。
ロールバックにも、終了条件を付ける
旧版へ戻して利用量が下がれば強い証拠になりますが、脆弱性修正まで巻き戻す危険があります。ロールバック前に既知のセキュリティ問題、データベース変更、復元手順を確認し、観察時間を決めます。利用量が下がらなければ、更新以外の仮説へ戻ります。
- 合格：同一操作の送信回数が更新前と一致
- 不合格：無操作でも定期的な送信が継続
- 中止：データ整合性またはセキュリティに影響
- 記録：検証版、時刻、入力、結果、判断者
次回更新前に、平常値を保存しておく
更新後に比較できるよう、主要操作ごとのリクエスト数と推定費用を平常時に記録します。標準のAI Clientを通る処理なら、AI Cost Guardrails-CNXTの無料版で基本のハードストップ保護を試し、更新直後の暴走に備えられます。直接APIを呼ぶプラグインは対象外になり得るため、通信経路の確認を導入条件にしてください。更新差分チェックリストは次回リリースの受け入れ条件として保存します。主要操作の送信回数、1件あたりトークン、Cron登録数のいずれかが基準を超えた場合は公開を保留し、差の理由を確認してから承認します。
「プラグイン更新後にAI利用量が急増したときの切り分け方」で整理した判断を「AI利用増加の更新差分チェックリスト」だけで終わらせないでください。AI Cost Guardrails-CNXTを無料でダウンロードし、次の費用急増に備えてBasic hard-stop protectionを設定しましょう。