本番でLLMコストが暴騰するのを防ぐには？（UXを殺さない運用）

結論（Conclusion）

LLMのコスト事故はだいたい原因が決まっている。

• リクエスト単位の上限がない（tokens / tools / retries）
• ユーザー/テナント単位の予算がない
• 隠れループ（エージェント、リトライ、ツール呼び出し）
• 悪用（スパム、スクレイピング、prompt bombing）

最小で効くガードレールはこれ。

1. リクエスト単位のハード上限（tokens、ツール回数、時間）
2. ユーザー/テナント予算（スロットル or ブロック）
3. スパイク検知アラート（tokens、attempts、エラー）
4. 劣化モード（軽いモデル、ツールOFF、簡易応答）

目的は「完璧」ではなく「予測できるコスト」。

背景（Explanation）

LLMは“変動費ソフトウェア”。 ガードレール無しで出すと、1日で

• 請求が跳ねる
• 本番性能が落ちる
• リトライでさらに増幅

が起きる。

コスト制御は会計だけじゃなく、信頼性とセキュリティ。

• 悪用はコストスパイクとして現れる
• retry stormは支払いを増やす

レベルは3段で考える。

• リクエスト
• ユーザー/テナント
• システム全体

実務手順（Practical Guide）

手順1：リクエスト単位のハード上限を入れる（10分）

常に効く上限を定義する。

• max tokens in
• max tokens out
• max tool calls per request
• max attempts（リトライ上限）
• max wall-clock time

ルール：

• 上限に達したら部分回答 + 再試行案内を返す

無限ループやprompt bombを止める。

手順2：リクエスト単位のコストを計測する（5分）

ログ（最低限）：

• request_id
• model
• tokens_in, tokens_out
• attempts
• tool_calls_count
• estimated_cost

概算でもいい。継続的に同じ指標を取るのが大事。

手順3：ユーザー/テナント予算を設定する（10分）

どちらかで良い。

• 日次token予算
• 日次cost予算

適用方法：

• soft limit：遅延/キュー
• hard limit：明確に拒否

ルール：

• 予算適用は決定的（deterministic）であること

“ゆるい目安”は、悪用時に効かない。

手順4：高シグナルのスパイクをアラートする（5分）

最初は3つで十分。

• tokens/request のスパイク（P95）
• attempts（リトライ）のスパイク
• 429/5xx のエラー率スパイク

手順5：フォールバックと劣化モードを用意する（10分）

• 失敗時に軽いモデルへ切替
• ツールOFF（read-only）
• 省略回答（要点だけ）
• よくある問い合わせはキャッシュ

ユーザーは「制限モード」は許容するが、ランダム失敗は嫌う。

手順6：悪用パターンに備える（5分）

よくある悪用：

• 長文連投
• 自動スクレイピング
• ツール呼び出しループ

最低限：

• IP + アカウントのレート制限
• 怪しいルートに摩擦（CAPTCHA等）
• ツール到達先allowlist

落とし穴（Pitfalls）

• 月末請求で初めて気づく
• 高額モデルの無制限リトライ
• ツール実行回数に上限がない
• 悪用とコストを別問題として扱う
• 予算超過時のユーザー向けエラーが曖昧

チェックリスト（Checklist）

• [ ] リクエスト単位のtokens上限がある
• [ ] リクエスト単位の上限がある（tools/attempts/time）
• [ ] requestごとに model/tokens/attempts/cost をログする
• [ ] ユーザー/テナント予算がある（日次token or cost）
• [ ] 予算適用の挙動（soft/hard）が決まっている
• [ ] 予算超過のユーザー向けエラーが明確
• [ ] tokensスパイク（P95/P99）アラートがある
• [ ] retryスパイクのアラートがある
• [ ] 429/5xxスパイクのアラートがある
• [ ] 劣化モードのフォールバックモデルがある
• [ ] ツールを即OFFにできる
• [ ] IP/アカウントのレート制限がある

FAQ

1) tokensを厳しく制限しすぎるべき？

まず安全な上限を置いて調整。無制限が一番危ない。

2) プロバイダが複数あるとコスト推定が難しい

単一の cost unit を持ち、modelとtokensを必ずログする。概算でもスパイク検知には十分。

3) 今日入れる最速のガードレールは？

リクエスト単位のtoken上限 + リトライ上限。これで暴騰の大半は止まる。

内部リンク（Internal links）

• Hub: AI開発
• 関連記事：
  • LLMのレート制限とリトライ設計チェックリスト
  • LLM可観測性の最小ログ設計チェックリスト
  • プロンプトインジェクション対策チェックリスト

免責

一般的な運用ガイドです。