◉GEMINI LABEN
●ARGON — gemini-4-argon が 10/13 に GA。複雑なコーディング・エージェント・数学・科学向けです●DEEP RES — deep-research-pro-preview-12-2025 は 10/23 に停止、残り6日。移行先は deep-research-preview-04-2026●NANO — gemini-nano-banana-2.1 が GA(10/06)。gemini-3.1-flash-image は非推奨で停止日は未発表です●MCP — ツール結果が 8.5万トークンに膨らんだ事例を、ADK で 310 トークンに包んで抑えた報告が出ています●FLASH — gemini-3.7-flash と 3.5-flash は新しい Flash モデルに自動で回されます(10/08)●NEW — クラッシュ報告を毎回ゼロから読ませない — 既知バグ早見表を先に grep し…●ARGON — gemini-4-argon が 10/13 に GA。複雑なコーディング・エージェント・数学・科学向けです●DEEP RES — deep-research-pro-preview-12-2025 は 10/23 に停止、残り6日。移行先は deep-research-preview-04-2026●NANO — gemini-nano-banana-2.1 が GA(10/06)。gemini-3.1-flash-image は非推奨で停止日は未発表です●MCP — ツール結果が 8.5万トークンに膨らんだ事例を、ADK で 310 トークンに包んで抑えた報告が出ています●FLASH — gemini-3.7-flash と 3.5-flash は新しい Flash モデルに自動で回されます(10/08)●NEW — クラッシュ報告を毎回ゼロから読ませない — 既知バグ早見表を先に grep し…
記事一覧/API / SDK
◈ API / SDK/2026-04-26上級

マルチテナント SaaS で Gemini API を安全に提供する設計 — テナント分離・課金計測・暴走防止の本番アーキテクチャ

Gemini API を複数テナントに提供する SaaS の本番アーキテクチャを Python コードつきでまとめました。テナント分離モデルの選択、テナント別レート制限、リクエスト単位の課金計測、月予算ガードとサーキットブレーカーによる暴走防止まで扱います。

Gemini API248マルチテナント3SaaS11本番運用49課金4アーキテクチャ14

✦ プレミアム記事

個人開発で Gemini API をバックエンドに使った SaaS を運用していて、最初に冷や汗をかいたのは「ある1社が無限ループで自分のテナントを叩き続けた結果、その日のうちに私の Cloud Billing が想定の何倍にも跳ね上がった」夜のことでした。

幸い検知できたのは、Cloud Billing アラートではなく、Slack に流していた1リクエストごとのコストログでした。アラートは翌朝届きました。本記事は、個人開発でこの規模の運用に一人で向き合ってきた私自身が、あの夜の自分に渡したかったマルチテナント設計の地図です。

シングルテナント(1社1インスタンス、1社1APIキー)の運用とは、考えるべきことが大きく変わります。「テナントを跨いだ巻き添え障害を起こさない」「テナントごとの利用量を、月末の請求と紐づくレベルで正確に取る」「想定外のトラフィックでコストが指数関数的に膨らんだ瞬間に止める」——この3点をどう設計するかが、SaaS としての耐久力を決めます。

なお、本記事は Gemini API の REST 呼び出しを Python の google-genai SDK 経由で行う前提で書きますが、設計思想はどの言語でも変わりません。

なぜ Gemini API のマルチテナント化は難しいのか

「自前のキャッシュサーバーを複数テナントで共有する」程度のマルチテナント化と、AI API のマルチテナント化には決定的な違いがあります。

第一に、1リクエストの単価がテナントごとに大きくぶれることです。同じ「メッセージ送信API」でも、テナントAは300トークンの問い合わせ、テナントBは80万トークンの長文要約を投げてくる、ということが普通に起こります。テナントごとの「トラフィック量(リクエスト数/秒)」だけでは利用量を測れません。「投入トークン数」「出力トークン数」「使用モデル」の3軸で記録する必要があります。

第二に、APIキー(プロジェクト)が単一であるため、ある1テナントの暴走が全テナントに波及することです。Google AI Studio キー(generativelanguage.googleapis.com)の場合は1分あたりのリクエスト数(RPM)の制限が、Vertex AI の場合は1分あたりのトークン上限が、プロジェクト全体に対して効いてきます。テナントBが秒間100リクエストを撃ち続けると、テナントAは何の前触れもなく 429(または DEADLINE_EXCEEDED)を返され続けることになります。

第三に、コストの暴走が即座に金銭的損失になることです。たとえばユーザー入力をそのまま LLM に渡す素朴な実装で、ユーザーが「無限ループするスクリプト」を書いたとします。入力5万・出力4千トークンの呼び出しは、後述の単価表(サンプル値)の Pro で1回あたり約0.10ドルです。毎秒20回を1時間続けられれば約7,400ドル、Flash でも約475ドルに届きます。「フェイルセーフはコード側でやるしかない」のが現実です。

設計判断その1: テナント分離モデルの選択

最初に決めるのは「どこでテナントを分けるか」です。私が経験した3パターンを比較します。

  • Aプラン: 完全共有(1プロジェクト・1APIキー) — もっとも安価で、デプロイも簡単です。ただし、ある1テナントが Gemini API のクオータを食い尽くすと、全テナントが影響を受けます。レート制限・課金計測は完全にアプリ側の責任になります。
  • Bプラン: テナントごとに Google Cloud プロジェクトを分ける — クオータが物理的に分離される、最も堅牢な構成です。ただし、プロジェクトの自動プロビジョニングや課金アカウントの紐付けが運用上重く、テナント数が10を超え始めると現実的ではありません。
  • Cプラン: BYOK(Bring Your Own Key) — テナント自身に Google AI Studio キーを発行してもらい、預かる構成です。テナントの請求書は Google から直接届くため、サービス提供側のコスト責任はなくなります。ただし、APIキーの暗号化保管・ローテーション機構が別途必要になります。

私の推奨は、立ち上げ期は A プラン+アプリ側で厳密なテナント別レート制限・課金計測、月間利用額が一定を超えるテナントには C プラン(BYOK)を提案、です。 多くの SaaS で B プランは過剰な投資になります。

✦

ここまでお読みいただきありがとうございます。

この記事の続きを読む

この先には、実装コードやベンチマーク結果など、実務でお役に立てる内容をご用意しています。このサイトは広告を掲載しておらず、サーバーや開発にかかる費用はメンバーの皆様のご支援で成り立っています。もしお役に立てていましたら、ご支援いただけますと大変ありがたいです。

この記事で得られること
✦テナント別トークンバケットと月予算ガードを組み合わせ、1社の暴走が全テナントに波及しない分離設計を実装できます
✦request_id を背骨に、usage_records テーブルとマテリアライズドビューでリクエスト粒度の課金計測と監査を構築できます
✦FastAPI への組み込み例・偽 Gemini クライアントによるテスト・サブテナント/PII 対応まで、本番運用の落とし穴を回避できます
Stripe による安全な決済 · いつでもキャンセル可能
✦

この記事を購入する

この先の内容をすべてお読みいただけます。一度のご購入で、いつでも何度でもアクセスできます。このサイトは広告を掲載しておらず、皆さまのご支援がサーバー費用などの運営を支えています。

または
メンバーシップなら全記事が読み放題 →
シェア

お読みいただきありがとうございます

Gemini Lab は広告なしで運営しており、サーバー費用などの運営コストはメンバーシップのご支援で賄っています。実装コード・ベンチマーク・本番設計パターンなど、実務でお役立ていただける記事を毎日更新しています。もし読んでよかったと感じていただけましたら、ぜひご覧ください。

  • ✦コピー&ペーストで使える実装コード付き
  • ✦毎日新しい上級ガイドを追加
  • ✦¥580/月 または ¥1,480 の永久アクセス
メンバーシップを見る →

関連記事

◈ API / SDK2026-04-26
Gemini API × Stripe で組む AI SaaS 課金 — 使用量ベースの本番実装ガイド
Gemini API を使った個人開発 SaaS で「使った分だけ請求する」課金システムを Stripe Metered Billing と Webhook で本番実装する実践ガイド。トークン計測・サブスク同期・ティア別ゲーティング・落とし穴まで網羅します。
◈ API / SDK2026-07-27
消えないプロンプト資産をたたむ — 静的参照だけでは見えない稼働経路を炙り出す退役台帳
一本化したはずの旧プロンプトがまだ毎日呼ばれている——そんな見えない稼働経路を炙り出す退役台帳の設計です。静的参照、フラグ既定値、観測窓、モデル停止日、キャッシュ実効率の5つを突き合わせる判定基準と、実運用で得た設計の勘所を実行結果とともにまとめました。
◈ API / SDK2026-05-21
Gemini API × Cloud Pub/Sub によるイベント駆動 AI ワークフロー設計 — 個人開発者の実装メモ
Gemini API を Cloud Pub/Sub のイベント駆動型ワークフローに組み込む実装メモ。アプリレビュー解析パイプラインを題材に、リトライ・デッドレター・冪等性・コスト管理までを個人開発の視点で整理しました。