# 公開したら請求が跳ねた — 従量課金の事故と、上限の設定方法 > AIで作ったアプリを公開したあと、クラウドやAIのAPI料金が想定外に跳ねる事故の原因と対策を、非エンジニア向けに解説します。跳ねやすい5つのパターン、Vercel・Supabase・AI APIそれぞれの上限設定、レート制限の入れ方まで。 - 公開日: 2026-08-06 - 著者: 友田 陽大 - タグ: バイブコーディング, 個人開発, Vercel, インフラ, AI - URL: https://tomodahinata.com/blog/ai-app-cloud-bill-spike-prevention - カテゴリ: AIで作ったアプリの運営 - 総合ガイド: https://tomodahinata.com/blog/ai-app-pre-launch-guide-for-non-engineers ## 要点 - 従量課金は「使った分だけ」なので上限が無い。想定外のアクセス・無限ループ・ボットのクロールで、個人開発でも数十万円の請求は現実に起こる - 跳ねやすいのは5パターン — AIのAPI呼び出し、画像・動画の変換、無限ループ、ボットの巡回、そして無料枠を超えた瞬間の従量移行 - AI APIは特に危険。1リクエストの単価が高く、しかも入力が長いほど高い。キー単位の上限額設定は必須 - アプリ側のレート制限（同じ人からの連続リクエストを制限する仕組み）は、上限設定と別に必要。上限は「被害の天井」、レート制限は「発生の抑止」 - 請求アラートは事後通知。本当に必要なのは支払上限（ハードキャップ）で、設定できるサービスでは必ず設定する --- セキュリティの事故は「攻撃されたら起きる」ものですが、これは**誰にも攻撃されなくても起きます**。自分のコードのバグだけで十分です。 そして気づくのは、たいてい請求書が届いてからです。 --- ## 1. なぜ跳ねるのか — 従量課金には天井が無い 昔のレンタルサーバーは「月1,000円で使い放題」でした。使いすぎればサイトが遅くなるだけで、請求額は変わりません。 いまのクラウドサービスは逆です。**使った分だけ請求され、上限を設定しない限り天井がありません。** 混雑しても遅くならず、スケールして、そのぶん課金されます。 これは本来メリットです。急にアクセスが増えてもサービスが落ちません。ただし**「増えた」の原因が正常なアクセスとは限らない**というのが、この記事の話です。 --- ## 2. 跳ねやすい5つのパターン ### パターン1: AIのAPI呼び出し **いちばん危険です。** OpenAI や Anthropic のAPIは、1リクエストあたりの単価がクラウドの他のサービスより桁違いに高く、しかも**入力が長いほど高くなります**。 AI が書きがちな危険な実装: - **会話履歴を毎回全部送る** — やり取りが進むほど、1回のコストが上がっていく - **ユーザーが送った文章の長さを制限していない** — 長文を貼られると1回で高額 - **リトライ（再試行）に上限が無い** — エラーが続くと同じ呼び出しを繰り返す - **ログイン不要で使える** — 誰でも無制限に呼べる 最後が特に効きます。「試しに使ってもらいたいから」とログイン無しでAI機能を公開すると、それは**あなたのお金で誰でもAIを使える窓口**になります。 ### パターン2: 画像・動画の変換 画像の最適化、サムネイル生成、動画のエンコード。これらは処理が重く、多くのサービスで「変換した枚数」や「転送量」で課金されます。 問題は、**同じ画像が何度も変換される**ことです。キャッシュ（一度作ったものを再利用する仕組み）が効いていないと、ページを表示するたびに変換が走ります。 ### パターン3: 無限ループ いちばん静かに、いちばん速く跳ねます。 ``` 【起きること】 - 処理Aが処理Bを呼び、処理Bが処理Aを呼ぶ - データ更新をきっかけに動く処理が、自分でデータを更新する - 失敗したら再試行する処理が、再試行でも失敗し続ける ``` 3番目が特に多いパターンです。「エラーが出たら再試行して」とAIに頼むと、上限を指定しない限り**永久に再試行する**コードを書くことがあります。 ループは人間の目には見えません。サーバー側で静かに回り続けます。 ### パターン4: ボットの巡回 公開したサイトには、検索エンジンやAIのクローラーが来ます。これは正常です。 ただし、**重い処理を含むページが大量にある**場合、クローラーがそれを全部踏んでいきます。 - 検索結果ページが無限に生成される（`?page=1` から `?page=99999` まで） - カレンダー機能が無限に未来の日付を生成する - フィルタの組み合わせでURLが爆発する これらは「URLは無限にあるが中身は同じ」という状態で、クローラーは律儀に全部見に行きます。 ### パターン5: 無料枠を超えた瞬間 最後に、思い込みの問題です。 「無料プランだから請求は来ないはず」——これは**サービスによって違います**。 - 無料枠を超えたら**サービスが停止する** → 請求は来ない（ただしサービスが止まる） - 無料枠を超えたら**自動的に従量課金へ移行する** → 請求が来る どちらの挙動なのかは、公開前に必ず確認してください。カードを登録した時点で後者になっているサービスもあります。 --- ## 3. 対策1: 支払上限を設定する（最優先） まずやるべきはこれです。 ### 「請求アラート」では足りない理由 多くの人は請求アラートを設定して安心します。しかしアラートは**「使いすぎました」と教えてくれるだけで、止めてはくれません**。 深夜2時に無限ループが始まったとします。アラートは2時半に届きます。あなたが気づくのは朝7時。その4時間半は、丸ごと課金されています。 必要なのは通知ではなく、**支払上限（ハードキャップ）** です。 ### 主要サービスでの設定 **Vercel** — Spend Management の機能で、金額のしきい値に達したときの動作を設定できます。通知だけでなく、**デプロイを一時停止する**選択もできます。設定できるプランと項目は公式ドキュメントで確認してください。 **AI API（OpenAI / Anthropic など）** — 管理画面で**キー単位・組織単位の使用上限**を設定できます。**これは必ず設定してください。** 金額を指定しておけば、そこで止まります。開発用と本番用でキーを分け、それぞれに上限を付けるとさらに安全です。 **Supabase** — プランごとの上限と、超過時の課金の扱いを確認してください。Spend cap の設定がある場合は有効にします。 **クラウド全般（AWS / GCP）** — 予算アラートは設定できますが、自動停止は標準では付いていません。停止まで自動化したい場合は別途仕組みが必要です。 ### 確認すべき2点 どのサービスでも、次の2つを確認してください。 1. **上限に達したら何が起きるか** — 止まるのか、課金され続けるのか 2. **止まる場合、どうやって復旧するか** — 深夜に止まったときの手順 「止まる」設定は、裏を返せば「サービスが落ちる」ということです。個人開発なら、**青天井の請求よりサービス停止のほうがましな場合がほとんど**ですが、それは自分で選ぶべき判断です。 --- ## 4. 対策2: レート制限を入れる 上限設定が「被害の天井」を決めるのに対し、レート制限は**「そもそも大量に呼ばせない」**ための対策です。 **レート制限**とは、「同じ人からのリクエストを一定時間内で制限する」仕組みです。たとえば「1人あたり1分間に10回まで」。 上限設定だけだとサービスが止まり、レート制限だけだと天井がありません。**両方あって初めて**、暴走しても止まらず、かつ課金も跳ねない状態になります。 ### どこに入れるか 全部に入れる必要はありません。**コストが高い処理だけ**で十分です。 - AI のAPIを呼ぶ処理 ← 最優先 - 画像・動画の変換 - 外部の有料APIを呼ぶ処理 - メール送信 - 重い集計・検索 ### ログイン必須にするだけでも効く AI 機能をログイン必須にするだけで、無差別な悪用はかなり減ります。「試してもらうために無料で開放したい」気持ちは分かりますが、**開放するなら回数制限とセット**にしてください。 --- ## 5. 対策3: 跳ねる原因を先に潰す 上限とレート制限は「起きたときに困らない」ための対策です。そもそも起こさない工夫も、いくつかは簡単に入ります。 **再試行に上限を付ける。** 「3回まで、間隔を空けて」と決めます。無限に再試行しない。 **AIに送る入力を制限する。** 文字数の上限を決め、会話履歴も直近N件だけ送る形にします。 **変換結果をキャッシュする。** 同じ画像を毎回変換しない。 **クローラーに見せる範囲を絞る。** `robots.txt` で、検索結果ページやフィルタの組み合わせページを除外します。中身が実質同じURLを無限に生成しない、というのも設計の話です。 **タイムアウトを設定する。** 外部サービスの応答を無限に待たない。待っている間も課金されます。 --- ## 6. AIに貼る指示 ```text このアプリが使っている従量課金のサービスを全部洗い出して、それぞれ 次を表にしてください。 (1) 何が課金の単位になるか（リクエスト数、転送量、実行時間、トークン数） (2) 想定外に費用が跳ねるシナリオ（具体的に） (3) 管理画面で設定できる上限やアラートの種類 そのうえで、コードを読んで次の危険な実装が無いか確認してください。 - 再試行（リトライ）に上限が無い箇所 - AIのAPIに送る入力の長さを制限していない箇所 - 会話履歴を毎回全部送っている箇所 - 同じ変換処理が毎回走る（キャッシュされていない）箇所 - ログイン不要で呼べる、コストの高い処理 - 外部サービスの呼び出しにタイムアウトが無い箇所 - 処理が互いを呼び合う可能性がある箇所（無限ループの元） 最後に、コストの高いエンドポイントにレート制限を実装してください。 どのエンドポイントにどんな制限値を入れたかを、理由つきで日本語で 説明してください。私はコードが読めません。 ``` --- ## 7. 公開直後にやるチェックリスト - [ ] 使っているサービスを全部書き出した（無料枠のものも含む） - [ ] それぞれの「無料枠を超えたときの挙動」を確認した（停止か課金か） - [ ] 支払上限を設定できるサービスでは設定した - [ ] AI APIのキー単位の上限額を設定した - [ ] 請求アラートを設定した（上限の代わりではなく、併用として） - [ ] コストの高い処理にレート制限を入れた - [ ] AI機能をログイン必須にした、または回数制限を付けた - [ ] 再試行に上限を付けた - [ ] 外部呼び出しにタイムアウトを設定した - [ ] `robots.txt` で無限に生成されるURLを除外した - [ ] **公開後1週間、毎日1回は請求画面を見る** ← これが最も効く 最後の項目が地味に重要です。跳ね始めは、たいてい小さな異常として現れます。毎日1回見ていれば、初日に気づけます。 --- ## まとめ - 従量課金には天井が無い。攻撃されなくても、自分のバグだけで跳ねる - 跳ねやすいのは5つ — AIのAPI、画像・動画の変換、無限ループ、ボットの巡回、無料枠超過時の自動移行 - AI APIが最も危険。単価が高く、入力が長いほど高い。キー単位の上限は必須 - 請求アラートは事後通知でしかない。設定できるなら支払上限を使う - レート制限は上限設定と別に必要。上限は「被害の天井」、レート制限は「発生の抑止」 - 公開後1週間は毎日請求画面を見る。跳ね始めは小さく現れる これは公開「前」ではなく公開「直後」の項目ですが、後回しにすると痛い出費として返ってきます。[公開前の4項目](/blog/ai-app-pre-launch-guide-for-non-engineers)を潰したら、次はここです。