要点
- 前払い残高が0の状態で呼び出すと、402が返った（出典: 自社の実測・2026-10-08）
- Google側のモデルごとの1日上限を300リクエストに設定し、管理APIで確認した（出典: 自社の実測・2026-10-08）
- Words Adminの鍵は、アプリとは別のプロジェクトに属していた（出典: 自社の実測・2026-10-10）
- 予算と課金を切り離す関数は、実際に鍵が属するプロジェクトを対象に置いた（出典: 自社の実測・2026-10-10）
AI機能を使う前に、支払い側の上限を決めたかった
合格ロードマップでは、学習歴の自由記述から、論点ごとの理解の深さを推定するAI機能を作っていた。この機能で使うGemini APIについて確認したのは、Google側の支払いとAPI利用に、どのような上限を掛けられるかだった。
アプリ側で呼び出し回数を制限することと、Google側で利用を止めることは、設定する場所が異なる。今回の記録では、アプリ側の上限に加え、前払いの残高とGoogle側のリクエスト上限を使う判断をした。アプリ内の回数制限の実装は、この記事の対象には含めていない。
さらに、英語学習アプリのWords Adminでは、利用している鍵の所属先と課金先も確認した。ここで分かったのが、アプリのプロジェクトに予算を付けるだけでは、Gemini APIの支払いを管理できない構成になっていたことだ。
確認すべき対象は、画面から呼べるAI機能だけではなかった。支払い方式、利用回数の上限、鍵の所属先をそれぞれ調べ、その結果に合わせて設定した。
前払い残高が尽きたときの応答を確かめた
前払いクレジット方式とは、あらかじめ入金したクレジットの残高を使ってAPIを利用する支払い方式のことだ。
合格ロードマップで使うGemini APIは、AI Studioの前払いクレジット方式だった。取得した公式の課金説明では、残高が0になると402で停止し、クレジット額を超えて請求されない方式とされていた。今回は、自動の追加入金であるauto-reloadを使わないと決めた。入金済みの残高を、支払いの上限として扱うためだ。
説明の確認に加え、実際に残高0の状態でAPIを呼び出したところ、402が返った。そこで画面のAI機能を「準備中」の表示に切り替え、画面から呼び出す経路を外した。この変更は、設定1つで戻せる形にした。
この確認で分かったのは、残高がない状態ではAPIが応答を返して止まり、その状態に合わせた画面の扱いが必要になることだった。課金方式を選ぶ判断と、使えないときの画面を整える判断を、実際の応答をもとにつないだ。
出典: Gemini APIの課金説明（2026-10-08取得）、自社の実測（2026-10-08）
リクエスト上限とモデル名を、それぞれ確認した
APIの利用には、AIのAPIだけに使える専用の鍵を作った。他のAPIには使えないように制限し、鍵の値をコードに書かず、Secret Managerから読み込む構成にした。
回数の上限は、Google側のService Usageのconsumer overrideで、モデルごとに1日300リクエストとした。設定後は管理APIを呼び、設定値として300が返ることを確かめた。アプリ側には1日150回の上限があり、それを超えてもGoogle側で止まる二重の形にした。
ここで確認した実物は、管理APIが返した設定値だった。設定を行うことに加え、読み出した値が意図した上限と一致しているところまで確認している。
同じ日のモデル確認では、gemini-2.5-flash-liteを呼び出した際に、新規利用者には提供終了という内容の404が返った。残高0で返った402とは、別の確認結果である。
この応答を受け、当時提供中で最安のLiteだったgemini-3.1-flash-liteへ切り替え、モデル名をコードの定数で固定した。呼び出しが使えない場面でも、残高の問題なのか、指定したモデルの提供状況なのかで、実際に取った対応は異なった。
出典: 自社の実測（2026-10-08）
予算の対象は、鍵が属するプロジェクトだった
Words Adminで確認したところ、使っていたGeminiの鍵は、アプリのプロジェクトのものではなかった。
所属先を調べる際は、鍵の値を表示せず、その鍵で有効にしていないAPIを1回呼び出した。返ってきた403の本文に含まれる所属先の情報を、自社で管理する情報と照合した。
その結果、鍵はAI Studioが自動で作った別のプロジェクトに属していた。そこでは課金が有効で、1日の上限の上書きは0件だった。課金先も、アプリとは別になっていた。
この構成では、アプリのプロジェクトに予算を付けても、Gemini APIの支払いはそこに乗らない。上限と予算を設定する対象は、実際に鍵が属するプロジェクト側だった。
そこで、そのプロジェクトだけを範囲とする月1,500円の予算を設定した。通知のしきい値は50%、90%、100%とし、予算を超えたら課金を切り離す関数を置いた。まず実際には止めない設定で判定を試し、確認後に本番の設定へ戻した。
翌日には、本物の通知も届いた。記録に残した値は次のとおりだ。
cost=194.25 budget=1500
この通知では何もしない判定になった。今回の記録で確認できるのは、停止させない設定での判定と、本物の通知に対する予算未満の処理である。実際に予算を超え、課金が切り離されたという実測までは記録していない。
出典: 自社の実測（2026-10-10の設定・検証、および翌日の通知記録）
業務に置き換えると
業務でAIのAPIを使う際も、今回確認した項目は、支払いと設定の対象を点検する項目として使える。
- 支払い方式と追加入金を確認する。 前払いなら残高が実質の上限になる。今回の運用では、自動の追加入金を使わないと決め、残高がない状態の応答も確かめた。
- アプリとGoogle側の両方に上限を置く。 鍵をAIのAPI専用に制限し、Google側の1日の上限を設定する。設定後は、管理APIから読み出した値も確認する。
- 鍵の所属先と課金先を照合する。 アプリが置かれたプロジェクトと、Gemini APIの支払いが乗るプロジェクトが同じかを確かめる。予算は、鍵が属する側に付ける。
- モデル名の変更箇所をまとめる。 今回は提供終了の応答を受けてモデルを差し替えた。モデル名をコードの1か所に置き、応答に合わせて変更できる形にする。
今回の費用管理では、残高で止まること、回数の設定値、予算が対象にするプロジェクトを別々に確かめた。業務への導入でも、自分たちが設定した上限が、実際に使っている鍵と支払いに適用されているかまで確認することが点検の中心になる。
この記事は、TechAthletes が自社のサービスを作る中で記録した実測をもとに書いています。業務への導入のご相談は 仕事の窓口 で受け付けています。