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