◉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上級

Gemini API × Stripe で組む AI SaaS 課金 — 使用量ベースの本番実装ガイド

Gemini API を使った個人開発 SaaS で「使った分だけ請求する」課金システムを Stripe Metered Billing と Webhook で本番実装する実践ガイド。トークン計測・サブスク同期・ティア別ゲーティング・落とし穴まで網羅します。

Gemini API248Stripe10SaaS11課金4Webhook3Metered Billing本番運用49

✦ プレミアム記事

Gemini API を組み込んだ SaaS を一人で作っていると、最初に立ち止まるのは「課金をどう設計するか」だと感じています。私自身、無料枠で使い始めた読者がそのまま定着してくれるのは嬉しい一方で、ヘビーユーザーが API コストを上回って赤字になる構造をそのままにしておくのは持続可能ではありません。

定額のサブスクリプションだけだと、月に 1 万トークンしか使わない人と 1,000 万トークン使う人が同じ料金になってしまいます。逆に純粋な従量課金だけにすると「いくら使うか分からない」という不安から、潜在ユーザーが登録自体をためらいます。

そこでここでは**「定額のベースプラン + 一定量を超えた分の従量課金」というハイブリッドモデル**を、Gemini API と Stripe の組み合わせで本番運用できるレベルまで実装する手順を、私が実際に運用している設計を元にまとめます。Webhook ハンドリング・Idempotency・トークン計測の精度・ティア別ゲーティングといった、実運用で必ずぶつかる論点を最初から織り込んだ構成です。

個人開発 SaaS で使用量ベース課金を選ぶ判断基準

「定額にすべきか、従量にすべきか」を最初に整理しておきましょう。私の経験では、Gemini API のような LLM をバックエンドに使うサービスでは、純粋な定額制は早晩破綻します。

理由はシンプルで、AI を使うアプリケーションの利用量はユーザー間で 1,000 倍以上の差が出るからです。ライトユーザーが月に数十リクエスト、ヘビーユーザーが月に数十万リクエストというのは珍しくありません。これを単一の月額で吸収しようとすると、ライトユーザーの料金を引き上げるか、ヘビーユーザーで赤字を出すかの二択になります。

私が現在採用しているのは、以下のハイブリッドモデルです。

  • Free: 月 50,000 トークンまで無料(離脱を防ぐためのオンボーディング枠)
  • Pro(月額 ¥980): 月 500,000 トークンまで含み、超過分は 100,000 トークンあたり ¥150 の従量課金
  • Team(月額 ¥4,800): 月 5,000,000 トークンまで含み、超過分は 100,000 トークンあたり ¥100

このモデルの良い点は、「月額のベースプランで安心感を提供しつつ、ヘビーユーザーからも適切に費用を回収できる」ことです。Stripe ではこれを Subscription(定額)+ Metered Subscription Item(従量) として 1 つの請求書にまとめられます。

システム全体の構成 — トークン使用量から請求書発行までの流れ

実装に入る前に、データの流れを把握しておくと迷子になりません。私が運用している構成は以下の通りです。

  1. ユーザーが Gemini API を呼ぶたびに、サーバー側で usageMetadata.totalTokenCount を取得して DB に記録する
  2. バックグラウンドジョブが 1 分ごとに、未集計のトークン使用量を Stripe Meter Event API に送信する
  3. Stripe が月末に「ベースプラン + 計測されたトークン量 × 単価」で請求書を自動発行する
  4. Stripe Webhook(invoice.payment_succeeded / customer.subscription.updated)でアプリ側のユーザー権限を同期する

この設計のポイントは、Gemini API の呼び出しと Stripe への報告を分離していることです。リアルタイムで Stripe に送ろうとするとレイテンシが乗りますし、Stripe 側のレート制限にも引っかかります。一旦自前 DB に貯めてバッチで送るのが本番では現実的です。

✦

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

この記事の続きを読む

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

この記事で得られること
✦Gemini API の使用量に応じた従量課金システムを、Stripe Metered Billing でつくる手順を、コピペで動くコード付きで持ち帰れる
✦Webhook によるサブスクリプション状態の同期と、ティア別 AI 機能ゲーティングを、本番で安定稼働させる設計パターンを習得できる
✦Idempotency・リトライ・監視まで、個人開発の AI SaaS が事故を起こさず運用できる本番ノウハウを、一通り押さえられる
Stripe による安全な決済 · いつでもキャンセル可能
✦

この記事を購入する

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

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

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

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

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

関連記事

◈ API / SDK2026-04-26
マルチテナント SaaS で Gemini API を安全に提供する設計 — テナント分離・課金計測・暴走防止の本番アーキテクチャ
Gemini API を複数テナントに提供する SaaS の本番アーキテクチャを Python コードつきでまとめました。テナント分離モデルの選択、テナント別レート制限、リクエスト単位の課金計測、月予算ガードとサーキットブレーカーによる暴走防止まで扱います。
◈ API / SDK2026-05-03
Gemini API × Cloudflare Workers で月額課金SaaSを構築する実装ガイド — 2026年版
Gemini API・Stripe・Cloudflare Workers で月額課金の SaaS を組む手順を、実コード付きで書き残しました。Workers で署名検証が通らない原因、Webhook の冪等性、KV でのアクセス制御、レート制限の限界まで、個人開発で実際に踏む所を順に辿ります。
◈ API / SDK2026-07-27
消えないプロンプト資産をたたむ — 静的参照だけでは見えない稼働経路を炙り出す退役台帳
一本化したはずの旧プロンプトがまだ毎日呼ばれている——そんな見えない稼働経路を炙り出す退役台帳の設計です。静的参照、フラグ既定値、観測窓、モデル停止日、キャッシュ実効率の5つを突き合わせる判定基準と、実運用で得た設計の勘所を実行結果とともにまとめました。