「Gemini API の課金体系が変わるらしいけど、自分のサービスに何か影響があるんでしょうか？」— 4月以降、知人の個人開発者から立て続けに同じ質問を受けています。
Gemini API がポストペイ（後払い）からプリペイド（前払い）に移行するというのは、実装している人にとっては地味に大きな変更です。残高が尽きた瞬間に API が止まるため、対応を後回しにすると本番障害につながります。ここでは私自身が運用中の SaaS で実際に踏んだ手順と、その過程で見えた落とし穴を整理しています。
何が変わるのか — 3つのポイント
まず移行内容を簡潔に整理します。Google のアナウンスを噛み砕くと、変更点は大きく3つです。
第1に、事前にクレジット残高をチャージする方式になる点。これまでは月末締めで請求されていましたが、今後は事前に Google Cloud Billing 上にクレジットを積んでおく必要があります。
第2に、残高ゼロで API が即座にエラーを返す点。後払い時代は多少のオーバーランが許容されていましたが、プリペイドでは残高不足が即サービス停止につながります。
第3に、自動チャージ（Auto Top-Up）の設定が事実上必須になる点。Google Cloud Console でしきい値を設定しておけば、残高が一定額を下回ったタイミングで自動的にチャージされます。これを設定しないと、人が常に残高を見張る必要があります。
移行前にやっておくべきチェックリスト
私が実際に4サイト分の API 環境を移行したときに使ったチェックリストを共有します。
1. 現在の月間消費額を把握する
過去3か月分の請求履歴を Google Cloud Billing で確認し、月平均と最大値を控えておきます。プリペイド残高の初期額は「月平均の2倍」を目安に積んでおくと安全です。
# gcloud で過去の請求情報を CSV エクスポート
gcloud billing accounts list
gcloud beta billing budgets list --billing-account=BILLING_ACCOUNT_ID2. アプリ側のエラーハンドリングを確認する
API レスポンスの 429（Too Many Requests）と 402（Payment Required）の両方を、明示的にハンドリングしているか確認します。多くの実装では 429 だけ拾っていて、残高不足の 402 は素通りしてしまいます。
// src/lib/gemini-client.ts
import { GoogleGenerativeAI } from "@google/generative-ai";
export async function callGemini(prompt: string) {
const genAI = new GoogleGenerativeAI(process.env.GEMINI_API_KEY!);
const model = genAI.getGenerativeModel({ model: "gemini-2.5-pro" });
try {
const result = await model.generateContent(prompt);
return result.response.text();
} catch (err: any) {
// 残高不足エラーを明示的にハンドリング
if (err.status === 402 || /payment required|insufficient/i.test(err.message ?? "")) {
// ユーザーには「一時的にサービスが利用できません」と返す
// 運営側にはアラートを飛ばす
await notifyOpsTeam("Gemini API balance insufficient");
throw new Error("ServiceTemporarilyUnavailable");
}
throw err;
}
}3. Auto Top-Up を設定する
Google Cloud Console の「Billing → Payment method」から Auto Top-Up を有効にします。私が推奨する設定値は以下の通りです。
- トリガーしきい値: 月平均消費額の20%
- チャージ単位: 月平均消費額の50%
- 月間上限: 月平均消費額の3倍
この設定で、突発的なトラフィック増加にもある程度耐えつつ、暴走したときの被害を抑えられます。
4. 予算アラートを2段階で設定する
月の消費が予想を超えた場合に気付ける仕組みを入れておきます。Cloud Billing の予算機能で、しきい値を50%・80%・100% の3段階に設定し、それぞれメール通知を有効にします。
移行を後回しにすると何が起きるか
実は、プリペイド移行のアナウンスを見落として何も対応していない開発者を何人も見てきました。最も典型的な事故パターンは以下の流れです。
- ある日突然、本番サービスが「サービスエラー」を返し始める
- 原因調査で API レスポンスを見ると 402 エラー
- Google Cloud Console を開くと残高ゼロ
- 慌ててチャージするが、決済反映に数十分かかる
- その間ユーザーは離脱
この事故を防ぐ唯一の方法は、移行前に上記のチェックリストを通すことです。後で対応すればいいや、と思っている方は、今すぐ対応することをお勧めします。
コスト見積もりの精度を上げる
プリペイド課金の世界では、月間予算を事前に積む必要があるため、コスト見積もりの精度が運営の質に直結します。
私が使っているコスト計算式は以下の通りです。
- 平均的な1リクエストあたりトークン: 入力500 + 出力300 = 800トークン
- モデル別単価（2026年5月時点）:
- Gemini 2.5 Pro: 入力 $1.25/1M、出力 $5/1M
- Gemini 2.5 Flash: 入力 $0.075/1M、出力 $0.30/1M
- 1リクエストあたり原価（Pro）: ($1.25 × 0.0005) + ($5 × 0.0003) = $0.002125
- 月10万リクエストの場合: $212.50
この計算を Google Sheets に組み込んでおき、ユーザー数や利用頻度を変動させたときの予測値が出るようにしておきます。プリペイド残高をどれだけ積むか、自動チャージ設定をどう変えるかの判断材料になります。
モデル選択がコストに与える影響
Gemini API のコストを抑える最大のレバーは、モデル選択です。Gemini 2.5 Pro と Flash では出力単価が約17倍違います。
すべてのリクエストを Pro で処理する設計から、「初回は Flash で試して、不十分な場合だけ Pro にエスカレーション」する設計に変えるだけで、コストが半分以下になることもあります。
// src/lib/gemini-router.ts
export async function smartCallGemini(prompt: string, complexity: "low" | "high" = "low") {
const model = complexity === "high" ? "gemini-2.5-pro" : "gemini-2.5-flash";
const genAI = new GoogleGenerativeAI(process.env.GEMINI_API_KEY!);
const m = genAI.getGenerativeModel({ model });
const result = await m.generateContent(prompt);
return result.response.text();
}複雑度の判定ロジックは「プロンプトの文字数」「特定キーワードの有無」など、単純なルールでも十分な効果があります。Flash で7割捌いて、難しい3割だけ Pro に流す、という設計が個人開発者には現実的です。
私の運用 — Cloudflare Workers + Gemini API のコスト感
私が運営している Gemini API ベースの SaaS では、月間40万リクエスト程度を Flash 中心で捌いており、API コストは月 $30〜$40 で収まっています。
Cloudflare Workers のリクエスト料金は別途 $5/月の有料プランで、合計しても月 $50 以下で運用できる構成です。プリペイド残高は月平均の2倍にあたる $80 を常時維持し、Auto Top-Up は $40 を切ったら $50 チャージする設定にしています。
詳しい設計は、別記事のGemini API でマイクロ SaaS を月額黒字化する完全ガイドで紹介しています。
移行のいま、最初にやること
ここまで読んでいただいた皆さんが、移行作業のまず一歩として今日できることを1つだけ挙げるとすれば、Google Cloud Console を開いて、過去3か月分の Gemini API 消費額を確認することです。
数字さえ手元にあれば、初期チャージ額・自動チャージ設定・予算アラートのしきい値、すべての判断ができます。コストが分からないまま設定を組むと、過剰な残高を積んで運転資金を圧迫するか、不足で本番障害を起こすか、どちらかになります。