結論：Gemini API の課金方法は、登録日から推測せず、サインインした Google AI Studio の表示で確認します。 API キーはリクエストを認証するだけです。キーが属するプロジェクト、そのプロジェクトにリンクされた Cloud Billing アカウントが、前払い／後払いプラン、利用ティア、アカウント全体の月間上限を決めます。
まず押さえるべき境界は三つです。
- 前払い残高が 0 になると、同じ請求先アカウントに接続された Gemini API プロジェクトは停止し、Free へ自動的には戻りません。
- 前払い残高が残っていても、同じ Cloud Billing アカウントに未払い・カード拒否・無効な支払方法があれば停止することがあります。
- Project spend cap、利用ティアの月間上限、Cloud Budget、短時間の spend-rate limit は別の仕組みです。どれか一つを設定しても、他の役割までは代替しません。
60秒で現在の課金状態を確認する
AI Studio の Projects、Billing、Spend、Usage、Rate Limits を開き、次のカードを埋めてください。公開ページの表より、サインイン後に表示される自分の値が優先です。
| 確認項目 | 記録する値 | 判断できること |
|---|---|---|
| Project ID | API キーが属するプロジェクト | どの使用量と通常の rate limit が合算されるか |
| Billing account ID | プロジェクトにリンクされた請求先 | 支払履歴、プラン、利用ティア、アカウント上限の所有者 |
| Billing plan | Free / Prepay / Postpay | 先に残高を入れるか、利用後に請求されるか |
| Usage tier | Free / Tier 1 / Tier 2 / Tier 3 | 利用可能な rate limit とアカウント月間上限の枠 |
| 支払状態 | 前払い残高、または後払いの決済状態 | 残高不足や未払いによる停止リスク |
| 支出設定 | Project spend cap と account monthly cap | 一つのプロジェクト停止か、同一アカウント全体停止か |
この6項目が揃わないまま「新しいキーを作る」「クレジットを追加する」「ティアを上げる」と決めると、原因と対策がずれます。キーを増やしても同じプロジェクトの quota pool は増えず、プロジェクトを別の請求先へ移すと新しいアカウントのプランとティアを引き継ぎます。
課金の所有関係は次の順です。
APIキー → Google Cloudプロジェクト → Cloud Billingアカウント → 課金プランと利用ティア → 支出コントロール
課金プラン：前払いと後払いは「ティア」と別
Google の現行 Billing 文書では、2026年3月23日から新しい課金プランが有効とされています。ただし、作成日だけで「必ず前払い」とは判定できません。移行中の既存アカウント、新規セットアップ、資格のあるアカウントで提示される選択肢が異なるため、AI Studio の Billing setup に表示されたプランが正解です。
| 比較 | Prepay（前払い） | Postpay（後払い） |
|---|---|---|
| 支払タイミング | クレジットを購入してから利用 | 利用額を Cloud Billing に蓄積し、請求サイクルで支払う |
| 開始条件 | Free から Paid へ進み、割り当てられた場合は最低 $10 または現地通貨相当を入金 | 資格やセットアップによって提示される場合がある |
| 運用上の停止点 | 残高 0 で同じ請求先の Gemini API プロジェクトが停止 | 未払い、カード拒否、無効な支払方法が停止原因になり得る |
| 注意点 | 残高上限は $5,000、クレジットは12か月で失効、原則返金不可 | Tier 3 が切替資格を得る場合があるが、手動切替は現在一時停止中 |
前払いの残高はほぼリアルタイムで差し引かれますが、計上には最大およそ10分の遅れがあり得ます。Batch や長時間動く agent は、残高や設定した上限を検知する前に処理が続くことがあります。したがって「残高が上限だから絶対に1円も超えない」とは扱いません。
自動チャージを使う場合は、残高トリガー、補充額、月間自動課金上限の三つを確認します。手動購入は月間自動課金上限に含まれません。サービス継続を優先して大きな残高を置くと、12か月の失効リスクも増えるため、トラフィックと補充リードタイムから決めます。
後払いについても「Tier 3 なら今すぐ切り替えられる」とは限りません。Google は現在、手動切替オプションを一時的に無効化していると案内しています。また一度同じ Billing アカウントを Postpay に切り替えると、同じアカウントを Prepay に戻せないという境界があります。
利用ティア：資格、rate limit、月間上限を同じ数字にしない
利用ティアは Cloud Billing アカウントの支払履歴に基づきます。資格判定の累積支出には、そのアカウントに紐づく Gemini API だけでなく、他の Google Cloud サービスも含まれます。
以下は2026年7月22日に公式 Billing ページで再確認した現行条件です。
| 利用ティア | 現行の資格条件 | Billing-account monthly cap |
|---|---|---|
| Free | 有効な無料プロジェクト／無料トライアル | 支出なし |
| Tier 1 | 有効な Billing アカウントを設定してリンク | $250 |
| Tier 2 | 累積支払 $100 以上、かつ最初の完了済み支払から3日 | $2,000 |
| Tier 3 | 累積支払 $1,000 以上、かつ最初の完了済み支払から30日 | $20,000〜$100,000+ |
条件を満たせば通常は昇格しますが、追加審査によって承認されない場合があり、quota increase も保証されません。Free から Tier 1 は通常すぐ、上位ティアは通常10分以内に反映されると案内されていますが、画面同期を即時と約束しないでください。
ティアは rate limit の資格に影響しますが、公開値は保証 capacity ではありません。Google の Rate limits 文書にある RPM、TPM、RPD とモデル固有値は、サインイン後の Rate Limits 画面で自分の active limit を確認します。詳しい 429 の切り分けは、Gemini APIのレート制限ガイドに分けています。
料金と「上限」を6つに分ける
「Gemini API の上限」という言葉だけでは、安全な判断ができません。対象、集計期間、到達時の動作を分けます。
| 仕組み | 所有単位 | 何を制御するか | 到達・発火時 |
|---|---|---|---|
| Billing plan | Billing アカウント | Prepay / Postpay の支払方法 | 残高または支払状態に従う |
| Usage tier | Billing アカウント | rate-limit 資格と account cap の枠 | 条件達成後に昇格候補 |
| Account monthly cap | Billing アカウント | 接続プロジェクトの月間 Gemini 支出合計 | 同じアカウントの対象プロジェクトが停止 |
| Project spend cap | プロジェクト | 一つのプロジェクトの月間支出 | 当該プロジェクトが停止。計上遅延あり |
| Cloud Budget | 指定した請求スコープ | しきい値通知 | 通知するだけで API を止めない |
| Spend-rate limit | プロジェクト／短時間窓 | 短時間の支出速度 | 429 RESOURCE_EXHAUSTED。月間上限到達とは別 |
Cloud Billing の Budgetは、予算に近づいたことを知らせる仕組みです。メールやプログラム通知には遅延や重複があり得て、リアルタイムの kill switch ではありません。
Project spend cap は一つの暴走プロジェクトを隔離するのに役立ちますが、実験的機能であり、設定には適切な IAM 権限が必要です。計上が最大およそ10分遅れることがあるため、金額を「絶対上限」として会計保証に使わず、アプリ側の request 制限やジョブ停止条件も併用します。
APIが止まったときの診断マトリクス
Google 公式 Troubleshootingと照合できるよう、最初にエラーコード、影響するプロジェクト範囲、AI Studio の plan／balance／tier、Cloud Billing の支払状態を同じ時刻で記録します。その後、次の順で切り分けます。
| 観測した状態 | 影響範囲 | 最初に確認する場所 | 安全な次の一手 |
|---|---|---|---|
| Prepay 残高が 0 または負数 | 同じ Billing アカウントの全 Gemini API プロジェクト | AI Studio Billing / credits | 必要量を入金し、支払確認を待つ。Free への自動復帰を期待しない |
| Project spend cap 到達 | そのプロジェクト | AI Studio Spend | 意図した上限か確認し、原因を直してから必要な場合だけ変更 |
| Account monthly cap 到達 | 同じ Billing アカウントの対象プロジェクト | Billing / tier 表示 | 次の請求サイクル、承認済み上限変更、正当なティア変更を確認 |
| 未払い・支払方法エラー | 共有 Billing アカウント。前払い残高が残っていても影響し得る | Cloud Billing Console | 期限切れ・拒否・past-due を解消し、回復を確認 |
429 RESOURCE_EXHAUSTED | 多くは当該プロジェクト | AI Studio Rate Limits と request rate / size | RPM、TPM、RPD、spend-rate を特定。むやみにチャージしない |
400 FAILED_PRECONDITION | リクエスト地域や project 条件による | エラー本文、利用地域、Billing | Free tier 非対応地域かを確認。billing 障害と決めつけない |
403、500、503、504 | 権限またはサービス状態など | エラー本文と公式 troubleshooting | 課金ティア障害として処理せず、コード別に診断 |
請求グラフは最大24時間程度遅れる場合があります。一方、前払い残高やティア変更は通常より早く更新されます。同じ「画面が古い」でも、見る surface によって同期時間が違います。
安全に有料化・昇格・継続運用する順序
Free から Paid に進む
- Paid が必要な理由を、モデル availability、実際の rate limit、データ条件のどれかで明確にする。
- API キーの Project ID と、接続する Billing account ID を照合する。
- AI Studio が提示する plan を確認する。Prepay なら最低入金額と利用可能な支払方法をその場で確認する。
- 小さな request を送り、Usage と残高または請求表示が同じプロジェクトに記録されるか照合する。
- Project spend cap、Budget 通知、アプリ側の traffic 制限を設定してから本番トラフィックを増やす。
モデルごとの現行単価はこのページに複製しません。Gemini APIの料金ガイドでモデル、機能、入力／出力単位を確認してください。無料対象モデルやデータ利用条件はGemini API無料枠ガイドに分けています。
上位ティアが必要な場合
月間上限だけでなく、実際に不足している次元を特定します。429 の原因が短時間の TPM や spend-rate なら、累積支払だけを増やしても即時解決しないことがあります。要件を満たした後は画面で昇格を確認し、承認や capacity を前提にトラフィックを先行させません。
複数プロジェクトを運用する
- 本番、ステージング、個人検証を分け、事故時の影響範囲を小さくする。
- 各 project に用途に合う spend cap を置く。根拠のない固定推奨額は使わない。
- account monthly cap は全プロジェクトの合算なので、個別 cap の合計と実際のトラフィックを定期的に見直す。
- 前払いでは残高と auto-reload を監視し、後払いでは支払方法と未払いを監視する。
- Batch／agent の長時間処理には、請求計上より先に止めるアプリ側の上限を持たせる。
日本で使うときの支払・地域境界
現在の利用可能地域一覧には日本が含まれています。ただし、対応地域であることと、特定のカード、請求通貨、消費税表示、組織ポリシーが全アカウントで同じであることは別です。
日本円表示、為替換算、税、利用可能な支払方法は、契約主体と checkout／invoice に表示される条件を確認してください。ドル額を固定為替で円換算して予算保証にせず、カード会社の換算、税、請求時刻も含めて社内見積りを作ります。
Google AI Pro / Ultra などの個人向けサブスクリプションは、Gemini Developer API の Billing plan や usage tier と同じ契約ではありません。また、Google Cloud の Welcome／free-trial credit は原則として現在の Gemini API／AI Studio 利用に充当されず、過去の適格なプロモーション credit には期限まで例外があり得ます。最終判断は Billing 画面に表示される利用可否に従います。
今日のチェックリスト
- すべての本番 API キーについて Project ID を記録した
- 各 project の Billing account ID、plan、tier を確認した
- Prepay は残高、失効日、auto-reload、月間自動課金上限を確認した
- Postpay は決済手段、未払い、請求サイクルを確認した
- Project spend cap と account monthly cap を別々に記録した
- Cloud Budget を停止装置ではなく通知として設定した
- 429 は active Rate Limits で原因次元を確認する手順を用意した
- 日本円、税、支払方法は自分の checkout／invoice で確認した
このチェックが終われば、次に取る行動は一つに絞れます。残高不足なら入金、支払失敗なら Cloud Billing を修復、project cap なら当該 workload を調査、account cap なら全プロジェクトの合算を見直し、429 なら rate-limit 次元を特定する。課金状態を一つの「ティア問題」にまとめないことが、最短の復旧手順です。
