公開AIチャットで料金が急増する前に。Denial of Walletを防ぐ設計

こんにちは、Ryohei（@ityryohei）です！

サイトに生成AIのチャット窓を設置し、問い合わせ対応や商品選びを助ける。利用者には便利な機能ですが、公開前に確認したいのは回答品質だけではありません。第三者がその窓を繰り返し呼び出したとき、運営者の負担でどこまでAI処理を実行できるでしょうか。

APIキーをサーバーに置き、ブラウザーへ出さないことは基本です。しかし、キーが漏れていなくても、自社の公開エンドポイントが無制限にAIサービスを呼び出せば、正規のキーを使う処理そのものが悪用されます。今回は、AIの利用料金とサービス継続性を守る設計を掘り下げます。

情報確認日：2026年10月14日。本記事は一次資料に基づく深掘り解説です。特定の企業で新たに被害が発生したという速報ではありません。OWASPの分類はそれぞれ2025版・2023版であり、確認日を資料の公開日や事件の発生日として扱いません。後半の実装・運用手順は、本サイトからの提案です。

Denial of Walletは、料金を発生させる機能の悪用

OWASP：LLM10:2025 Unbounded Consumptionは、過剰で制御されていない推論によるサービス停止、経済的損失、品質低下などを整理しています。その例の一つがDenial of Wallet（DoW）です。従量課金のAIサービスに大量の処理を行わせ、利用者ではなく運営者の費用を膨らませるリスクを指します。

これは「攻撃者もAIを使った」と断定する話ではありません。攻撃対象がAI機能であることと、攻撃手段に生成AIが使われることは別です。また、料金の増加だけでは攻撃と判断できません。広告によるアクセス増、クライアントの不具合、意図しない再試行でも同様の変化は起こり得ます。原因が何であっても、消費量に境界を設ける必要があります。

OWASP：API4:2023 Unrestricted Resource Consumptionでも、APIの資源消費がサービス停止や運用費の増加につながると説明しています。回数だけでなく、処理時間、入力サイズ、一度に行う操作数、外部サービスの支出制限などが対象です。AIチャットにもこの考え方を当てはめられます。

ブラウザーから見えないキーでも、入口は公開されている

説明用の構成として、ブラウザーがWordPressの独自APIへ質問を送り、WordPressがAI提供元へ問い合わせて回答を返す仕組みを考えます。キーはサーバー側に保存されていても、質問を受け付けるAPIは利用者に公開されています。認証や消費制限がなければ、サイトのチャット画面を使う場合以外にも処理を呼び出す余地があります。

対策の起点は、通信経路を三つに分けることです。利用者から自社APIへの入口、自社からAI提供元への呼び出し、検索や画像生成など追加ツールへの呼び出しです。どこで本人確認を行い、どこで回数を数え、どの段階で料金が発生するかを書き出してください。画面で送信ボタンを無効にするだけでは、サーバー側の利用条件にはなりません。

匿名で誰でも使えるチャットを設けること自体が誤りとは限りません。ただし、匿名利用者に与える範囲を決める必要があります。短い案内回答と、長文資料の解析や画像生成では費用と負荷が違います。まず無料公開の用途を狭め、高負荷な機能は認証済み利用者や別の申請経路へ分ける設計を提案します。

CORSとnonceを利用権限の代わりにしない

MDN：Cross-Origin Resource Sharing（CORS）が説明するCORSは、ブラウザーが別のオリジンの資源へアクセスする際の仕組みです。「自社ドメインだけ許可したから、APIを自社の画面からしか使えない」と判断するのは適切ではありません。ブラウザーの制約に従うJavaScriptと、独立したHTTPクライアントは同じ前提ではないためです。

CORS設定は正しく行ったうえで、API側で認証、認可、利用上限を判定することを提案します。OriginやRefererの値だけで費用のかかる処理を許可する設計も避けます。「ページを見た人だから利用してよい」という判断には、公開ページから取得できる情報を秘密の資格情報として扱わないことが必要です。

WordPress Developer Resources：Noncesも、nonceを認証・認可・アクセス制御の手段として頼るべきではないと明記しています。WordPressのnonceは一度限りの使用を検査する仕組みではなく、再送を防ぐ保証にもなりません。ログインしていない訪問者は、標準では同じユーザーIDに基づくnonceになります。

そのため、公開AIチャットのページにnonceを埋め込んだだけで、利用者ごとの課金上限を実現したとは言えません。ログイン必須の機能なら、認証済みユーザーの権限と残量を確認します。匿名向けなら別途セッションや不正利用対策を設計しますが、匿名セッションを大量に作られる可能性も織り込んだ全体上限が必要です。

「1分に何回」だけでなく「1回で何をするか」を制限する

短い質問一つと、長い会話履歴を伴う質問一つは、同じ一回でも同じ費用とは限りません。文章以外の入力、検索、画像、音声、複数のツール実行が加われば、別の消費も発生します。利用中の製品の課金対象を確認し、画面上の送信回数と提供元への実際の呼び出し数を区別してください。

本サイトからは、入口で入力サイズを検査し、モデルや生成上限をサーバー側で選び、会話履歴や参照資料の量にも限度を設ける構成を提案します。モデル名、出力量、ツールの実行回数を利用者が自由に指定できるなら、許可範囲を検証します。LLMに「節約して」と指示するだけで、プログラム側の上限を省略しないでください。

加えて、一つの質問から何度もモデルを呼ぶエージェント処理には、合計の実行回数と経過時間の上限を設けます。回答に失敗したら自動で別のモデルへ切り替える処理や、ツールの失敗を繰り返す処理も、その上限の対象です。個別の呼び出しは軽くても、一つの仕事が終わらなければ全体の消費は増え続けます。

利用者単位・同時実行・サービス全体の三段階で守る

IPアドレス単位の制限は入口の一つとして使えますが、同じ会社や通信回線から来る複数利用者がまとめて制限されることがあります。逆に、通信元が分散していれば一つのIPだけを見る制限には限界があります。アカウント単位の枠とサービス全体の枠を組み合わせ、どの利用者も全体を使い切れない設計を提案します。

回数と別に必要なのが同時実行数です。長い生成処理が多く並行すると、サーバーの接続やワーカーを占有します。上限を超えた要求を無制限にキューへ積めば、待ち時間が伸び、後からまとめて費用が発生するおそれがあります。受付数、実行数、待機数を分けて制限し、受け付けられない場合の案内も用意します。

カウンターの実装にも注意が必要です。複数の処理が同時に「まだ残量がある」と確認してから呼び出すと、上限を超える場合があります。共有の保存先で受付を確定し、処理の重複や複数サーバーでも同じ利用枠を扱えることを検証してください。ブラウザーのlocalStorageだけで回数を管理しても、運営者側の上限にはなりません。

ゲートウェイの制限と料金停止は別に確かめる

Cloudflare AI Gateway：Rate limitingには、一定時間内のリクエスト数を制限する機能、固定窓と移動窓の方式、制限時に429を返す挙動が説明されています。確認したページには2026年9月30日の更新表示がありました。これは資料の更新日であり、本記事で新機能の公開や被害発生を確認したという意味ではありません。

このようなゲートウェイを使う場合は、制限が一人に対するものか、ゲートウェイ全体に適用されるものかを確認します。また、別の経路からAI提供元へ直接接続できれば、ゲートウェイを通る通信だけに制限を置いても全体を管理できません。設定を増やす前に、すべての呼び出し経路を揃えることを提案します。

予算通知と強制停止も区別してください。通知は気づくための仕組みであり、通知が届いた時点で課金が必ず止まるとは限りません。提供元で設定できる制限の仕様を確認し、停止が必要なら自社側にも新規受付を止める手段を設けます。集計の遅延や実行中の処理があるため、見積額ぴったりに停止できると保証するべきではありません。

日本のサイト運営で決めておく具体的な手順

小規模サイトでも、担当者が料金画面を毎日眺める運用だけに頼らず、次の項目を公開前の確認事項にすることを提案します。数値は一律の推奨値ではなく、通常利用を検証して決めます。

公開範囲：匿名利用と会員利用で使える機能を分け、誰がどの処理を実行できるかを文書にする。
受付条件：入力、出力、履歴、ツール回数、処理時間、同時実行、待機数の上限を確認する。
消費枠：利用者単位とサイト全体の枠、計測方法、リセット条件、上限に達したときの動作を決める。
監視：受付数、拒否数、提供元への呼び出し数、処理時間、推定消費量を観測し、機密情報をログへ残しすぎない。
停止と復旧：AIだけを止めてFAQや問い合わせフォームへ案内する手順、連絡先、再開の判断者を決める。

テストでは、上限を超えた要求が単にエラー表示されるだけでなく、提供元への呼び出し前に拒否されるかを確認します。通常の送信、連続送信、同時送信、長い入力、失敗時の再試行を許可された検証環境で試し、受付ログと提供元の利用記録を照合します。他人のAPIへ負荷をかけて確認する必要はありません。

429や障害への再試行には、待機時間と最大回数を設けます。受付済みの仕事を利用者が再送した場合に重複実行しない設計も検討します。ただし、同じ質問文だからという理由で全員の回答を一つにキャッシュすると、個人向けの内容を別人へ返す危険があります。料金削減策でも、認証とデータの境界を保つ必要があります。

防御の目的は、通常の利用を続けられる境界を作ること

制限を厳しくすればよいという話ではありません。短時間に質問する正規利用者を過度に止めれば、導入した機能の価値が落ちます。通常時の利用を測り、負荷の高い機能を分け、上限時には理由と代替経路を伝える設計が重要です。障害や料金増加を見つけても、記録の裏付けなしに不正アクセスと断定しないでください。

APIキーの保護、利用者の権限、資源消費の制御、料金の監視は、それぞれ違う役割を持ちます。AIチャットを公開するときは「キーが隠れているか」に加えて、「誰が、どの処理を、どこまで運営者の負担で実行できるか」を確認しましょう。その境界をサーバー側で実装することが、回答の便利さとサービスの継続性を両立させる土台になります。