Gemini API不正利用で請求爆死する前に！課金アラート＋クォータ制限＋キー制限の完全ガイド【2026年最新版】
「Gemini APIを触ってみたら、ある日いきなり高額請求が来た」
この事故、実は珍しくありません。原因の多くは APIキー漏えい と 上限設定不足 です。
結論から言うと、Gemini APIの不正利用対策は次の3点セットが必須です。
- 課金アラート（Budget Alerts） で異常を早期検知
- クォータ制限（Rate Limits / Quota） で使い過ぎを技術的にブロック
- APIキー制限（Application + API Restrictions） で不正利用の入口を塞ぐ
この記事では、2026年時点の公式情報をベースに、実運用で事故を防ぐための設定手順をまとめます。
「とりあえず動いた」状態から「請求事故を防げる」状態へ、一気に持っていきましょう。
なぜGemini APIで“請求事故”が起きるのか
Gemini APIの請求事故は、だいたい次の流れで発生します。
- クライアント側にキーを直書きしてしまう
- GitHubやログ、ブラウザ経由でキーが漏れる
- 制限のないキーが第三者に使われる
- クォータ未設定でリクエストが走り続ける
- 課金アラートだけ設定していて、止まらないまま請求が膨らむ
特に重要なのが、課金アラートは基本的に通知であり、自動停止ではない という点です。
「アラートを入れたから安心」と思っていると、通知を見た頃にはすでに超過している、というのが典型パターンです。
前提知識（ここを誤解すると危険）
まず押さえておくべき公式仕様を整理します。
1. レート制限は“APIキー単位”ではなく“プロジェクト単位”
Gemini APIのRPM/TPM/RPDなどの制限は、原則としてプロジェクト単位で適用されます。
つまりキーを複数作っても、同一プロジェクトなら合算で評価されます。
2. 使用量ティアで上限が変わる
無料枠/有料Tier 1〜3で使える上限が変化します。
Tierの昇格条件や月間上限は、AI StudioとBillingドキュメントで要確認です。
3. 2026年は“Spend cap（支出上限）”の運用理解が必須
課金仕様は継続的にアップデートされています。
「どこまでが通知で、どこからが強制停止か」を、毎月一度は確認する運用にしてください。
対策① 課金アラート：最速で異常を検知する
役割
課金アラートの役割は 早期発見 です。
不正利用やバグによる急増を、被害が拡大する前に察知できます。
設定手順（Google Cloud Console）
-
Billingに移動 -
Budgets & alertsを開く -
Create budgetを選択 - 対象（請求先アカウント / プロジェクト）を決める
- 月次予算を設定
- しきい値を設定（推奨：50% / 80% / 90% / 100%）
- 通知先メールを設定
- 必要ならPub/Sub通知を有効化
実務で効く設定のコツ
- 単一プロジェクト単位の予算も作る（全体予算だけでは原因特定が遅い）
- 100%だけでなく、80〜90%の事前通知を必ず入れる
- 受信先は個人メールだけでなく、運用チームMLやSlack連携も使う
- 休日・夜間を想定し、複数人が受け取れる体制にする
注意点（超重要）
- Budget Alertは通知が中心で、それ単体で課金を自動停止しない
- 課金データには反映遅延があり、通知時点で超過していることがある
したがって、後述のクォータ制限やキー制限と必ず併用してください。
対策② クォータ制限：使い過ぎを技術的に止める
役割
クォータ制限は 実際に止めるための防波堤 です。
上限到達後はエラーを返し、無限に請求が積み上がる状態を防ぎます。
Gemini APIで見るべき代表指標
- RPM（Requests Per Minute）
- TPM（Tokens Per Minute）
- RPD（Requests Per Day）
※モデルごと・ティアごとに異なるため、AI Studioの最新値で確認します。
設定の考え方（最初は低め）
最初から大きく開けるほど危険です。
本番移行時は次の順で上げるのが安全です。
- 開発段階：かなり低い上限
- ステージング：想定負荷の50〜70%
- 本番初期：想定負荷の80〜100%
- 観測しながら段階的に増やす
例：小規模Webサービスの初期値
- RPM: 20〜60
- RPD: 1,000〜5,000
- TPM: モデル特性に応じて低めスタート
この設定にしておくと、キー漏えいやループバグが起きても被害が限定されます。
運用時のチェックポイント
- 429（rate limit）発生率
- 1日あたりトークン消費の増減
- 新機能リリース直後の急増
- 深夜帯の異常アクセス（漏えい兆候）
対策③ APIキー制限：漏えいしても悪用されにくくする
役割
キー制限は 侵入口の封鎖 です。
キーが漏れても、利用元や利用APIを縛っておけば、悪用を大幅に抑制できます。
必ず設定する2種類
- Application restrictions（利用元制限）
- API restrictions（利用先API制限）
どちらか片方だけでは不十分です。公式でも併用が推奨されています。
利用元制限の選び方
- ブラウザ利用：HTTP referrer制限（
https://example.com/*など） - サーバー利用：送信元IP制限（固定IP/CIDR）
- Android：SHA-1 + package名
- iOS：Bundle ID
API制限の考え方
- キーごとに「使ってよいAPI」を最小化
- Gemini用途のキーなら、不要な他APIを許可しない
- 可能なら用途別にキーを分割（Web用/バッチ用/検証用）
よくある危険設定
- 制限なしキーを本番で使う
- referrerに
*相当の広いパターンを入れる - API制限を設定しない
- 1本のキーを全環境で使い回す
3つを組み合わせると何が変わるか（防御の多層化）
この3対策は、それぞれ守備範囲が違います。
- 課金アラート：気づく
- クォータ制限：止める
- キー制限：そもそも通さない
どれか1つ欠けると、次のような穴が残ります。
- アラートのみ：通知は来るが請求は伸び続ける
- クォータのみ：そもそもの不正アクセスは発生する
- キー制限のみ：正規経路の暴走（バグ・無限リトライ）を止めきれない
三位一体で初めて“事故りにくい運用” になります。
まとめ：Gemini APIの不正利用対策は“設定の掛け算”で決まる
Gemini APIの請求事故を防ぐ鍵は、単一機能ではなく運用設計です。
改めて結論を整理します。
- 課金アラート で異常を早く知る
- クォータ制限 で使い過ぎを止める
- APIキー制限 で悪用の入口を閉じる
この3つを同時に入れておけば、
「気づいた時には手遅れ」という最悪パターンをかなりの確率で回避できます。
「あとでやる」は一番危険です。
まずは今日、Budget Alertとキー制限だけでも入れてください。
その10分が、将来の高額請求を防ぐ最短ルートになります。
参考（公式ドキュメント）
- Gemini API Billing: https://ai.google.dev/gemini-api/docs/billing
- Gemini API Rate limits: https://ai.google.dev/gemini-api/docs/rate-limits
- Cloud Billing Budgets & alerts: https://docs.cloud.google.com/billing/docs/how-to/budgets
- Programmatic notifications: https://docs.cloud.google.com/billing/docs/how-to/budgets-programmatic-notifications
- Disable billing with notifications: https://docs.cloud.google.com/billing/docs/how-to/disable-billing-with-notifications
- API key restrictions: https://cloud.google.com/api-keys/docs/add-restrictions-api-keys