年間平均は、もっとも止めたくない日を隠す
お中元、ブラックフライデー、年末など、ECのAI商品相談や検索補助は特定期間に集中します。年間費用を12で割った平均を月間上限にすると、繁忙期の正当な需要を異常として止めます。反対に最大月の値を一年中使えば、閑散期に起きたループへ大きな余地を与えます。
仮に通常月の注文が1,000件、AI相談が500件、費用が80ドルで、セール月は注文2,500件、相談2,000件になるなら、単純な2.5倍では足りません。相談利用率そのものが上がるからです。注文数だけでなく、訪問者のうちAIを使う割合と相談1件あたりの処理量を分けて見積もります。
日を、通常・計画ピーク・想定外ピークに分ける
過去の注文数、訪問者数、AI成功処理、推定費用を日別に並べ、通常日、広告やセールがある計画ピーク、メディア掲載などの想定外ピークに分類します。前年データがない新機能なら、注文数や問い合わせ数を代理指標にして暫定比率を置きます。
基準表は月別だけでなく、イベント単位で持つと再利用できます。たとえば『メール配信5万人・割引20％・開始20時』の回に、最初の2時間で相談が何件、売上がいくら、Botによる反復アクセスが何件だったかを残します。翌年は前年同月ではなく、配信規模、割引率、開始時刻が近い施策を比較対象にします。同じ施策名でも条件が変わった回は、別イベントとして記録してください。
- 通常日：中央値と曜日差を基準にする
- 計画ピーク：開始・終了日時と想定倍率を登録する
- 想定外ピーク：売上シグナルを見て一時判断する
- 障害：成果が増えず、反復・失敗だけが増える
売上に近い機能へ、先に余裕を配る
商品相談、在庫確認、購入後サポート、社内の商品説明生成が同じ予算を使うなら、繁忙期に優先順位が必要です。購入判断に直結する商品相談と在庫確認を残し、後回しにできる一括生成は時間帯をずらすか一時停止します。
すべてのAI処理を同じ割合で増額するより、売上導線ごとに必要な件数と1件あたり費用を見積もる方が、追加予算の理由を説明できます。
失敗例は、セール当日に全体上限だけを3倍へ上げ、商品説明の一括生成が先に枠を消費することです。販売期間中は社内バッチを止める、または別時間帯へ移し、顧客向け処理の最低枠を確保します。終了後に未処理バッチを再開できるよう、対象IDと進捗を保存します。
季節ルールには、自動的に戻る日時を付ける
セール用に上限を2倍へ変更したら、終了翌日の午前2時に通常値へ戻すなど、期限を同時に決めます。終了後は、追加した費用、追加売上、ProのSmart Protectionを使った場合のBot・Unknownの構成、停止や遅延の有無を振り返り、次回の倍率を更新します。
売上が想定より弱い、失敗率が上がる、同一リクエストが急増するといった条件も、予定前にピーク設定を解除するサインとして決めておきます。完成した季節運用表は、マーケティング、EC運用、開発の三者で共有し、次回施策の開始72時間前に更新します。
通常月の安全網と、繁忙期の判断を分ける
まず無料版の基本停止で、標準のAI Clientを通るリクエストの通常期の推定上限を検証します。繁忙期にHuman・Bot・Unknownと売上シグナルを見て正当な顧客処理を残す必要が出たら、ProのSmart Protectionを検討できます。シグナルは補助であり、セール計画や実売上との照合は欠かせません。実績欄には通常上限へ戻した時刻も入れ、季節設定の解除忘れを防ぎます。翌年は前年の上限値をコピーせず、相談率、単位原価、購入転換率、Botによる反復アクセスの割合を確認してから更新します。
AI Cost Guardrails-CNXTをダウンロードし、「繁忙期と閑散期があるECサイトのAI予算設計」のうち製品が対応する境界をWordPress上で動かします。Freeはサイト全体・呼び出し元別の月間USD・リクエスト試行数・トークン、Proは対応する短時間・失敗パターンを制御できます。