実績がないときは、予測を精密にするより露出を小さくする
新規サイトでは、アクセス予測も1回あたりのトークンも外れます。そこで、最初から正確な月間額を当てようとせず、外れても受け入れられる暫定上限と短い観察期間を置きます。1か月待つのではなく、社内テスト、限定公開、一般公開の三段階でデータを増やします。
たとえば社内20人で100回、既存顧客50人で300回を試し、一般公開後は最初の3日だけ有人時間帯に観察します。各段階で成功1件あたり費用と失敗率を更新し、次の段階の上限を決めます。公開対象だけ広げ、モデル、プロンプト、上限を同時に変えないことが、データを比較できる条件です。
まず一件の最大費用を、実際の入力で測る
短い質問だけで試すと、本番の長文入力を過小評価します。想定する短文、中央値、最大文字数の三種類を用意し、それぞれ入力トークン、出力トークン、処理時間、再試行時の費用を測ります。画像や文書添付がある機能は、テキストとは別に扱ってください。
数値例として、中央値の処理が0.04ドル、最大入力が0.18ドル、再試行込み最悪値が0.36ドルなら、1,000件を単純に0.04ドルで見積もるのは危険です。実際の入力比率を仮置きし、通常ケース800件、長文150件、最悪ケース50件の加重平均を作ると、暫定予算の根拠が説明できます。
- 典型的な短い入力での推定費用
- 実務で多い入力長での推定費用
- 許可する最大入力での推定費用
- タイムアウト後に1回再試行した場合の費用
暫定上限は、想定件数ではなく失敗してもよい範囲に置く
公開初週に100人来るという予測より、「上限に達して機能が止まっても、代替フォームで対応できる件数」を基準にします。初日は低めに置き、担当者が見られる時間帯だけ公開する方法もあります。夜間まで一気に開放するより、観察できる窓を増やす方が安全です。
顧客向け機能が止まった場合の文面、有人窓口、再開判断者を準備してから制御を有効にします。上限値だけ決めても、停止後の体験が空白なら公開準備は完了していません。
ありがちな失敗は、テスト利用を本番需要として数え、初日から上限を大きくしすぎることです。社内テストには用途ラベルを付け、顧客利用と分けます。また、上限到達後に担当者が慌てて無期限で倍増しないよう、一時増額の最大幅と有効時間を公開前に合意します。
引き上げには、件数ではなく成果の証拠を求める
上限の80％に達したから自動的に増額するのではなく、成功率、顧客の完了率、成果1件あたりの費用、異常な反復の有無を確認します。正当な利用で足りないなら引き上げ、失敗やBotが消費しているなら原因を直します。
観察表には、当初仮説、実測値、差の理由、次の値、承認者を残します。初週を終えた時点で予測の倍を使っていても、成果も倍で単位原価が変わらないなら増額候補です。成果が横ばいなら、上限の問題ではなく入力肥大化や重複送信を先に調べます。引き上げを承認した場合は、新しい上限の有効期限と次回確認日を同じ行に記録します。
- 3営業日連続で成功率が基準以上
- 成果1件あたりの費用が許容範囲内
- 再試行・同一入力の反復が増えていない
- 停止時の代替導線が実際に機能する
無料版で小さく観察し、実績から次の値を決める
対象処理がWordPress標準のAI Clientを経由しているかを確認したうえで、AI Cost Guardrails-CNXTの無料版を限定公開期間に組み込みます。まず推定値と基本のハードストップ保護の挙動を確かめ、プロバイダーの実請求と照合してください。十分な実績がたまるまでは、上限を『確定値』ではなく見直し日付きの暫定値として扱います。
AI Cost Guardrails-CNXTをダウンロードし、「利用実績ゼロの新規サイトで、最初のAI上限をどう決めるか」のうち製品が対応する境界をWordPress上で動かします。Freeはサイト全体・呼び出し元別の月間USD・リクエスト試行数・トークン、Proは対応する短時間・失敗パターンを制御できます。