Skip to main content
OpenAIは、APIの使用量に対する前払いの法定通貨クレジットと、コンシューマー向け製品の定額サブスクリプションを組み合わせています。前払い方式ではOpenAIが先に現金を受け取れ、開発者は営業担当者とのやり取りなしに使用量を拡大できます。多くのAI企業がこのモデルを採用しています。

なぜOpenAIのモデルが標準なのか

従来のSaaS課金では、AI使用量の変動コストを適切に扱えません。OpenAIのモデルは、次の3つの問題を同時に解決します。
  1. 予測可能な収益と低リスク: APIの使用量は前払いされるため、ユーザーが支払えない請求額まで使い込むことはありません。OpenAIは先に代金を受け取り、ユーザーはサービスの利用に応じてその金額を消費します。
  2. 開発者向けのスケーラビリティ: $5のトップアップは導入へのハードルが低い金額です。アプリケーションの成長に応じて、開発者はトップアップを自動化したり、より大きなパックを購入したりできます。安価に始められ、プランを変更せずに使用量を増やせます。
  3. ユーザー心理: 抽象的な「トークン」や「ポイント」ではなく米ドルで表示されたクレジットにより、価値が明確になります。残高はAIサービス用のプリペイドアカウントのように機能するため、企業は予算を管理しやすくなります。

OpenAIの請求方法

OpenAIは、ユーザーの種類に応じて2つの課金モデルを運用しています。
  1. API (Pay-as-you-go): APIでは、米ドル建ての前払いクレジットを使用します。ユーザーはアカウントに $5、$10、$50、またはそれ以上をチャージします。クレジットにはドルの価値が表示されますが、OpenAI以外では使用できません。OpenAIはトークン単位で請求し、入力トークンと出力トークンで異なる料金を設定しています。購入したクレジットの有効期限は購入から1年後で、返金はできません(OpenAI Help Center)。残高が$0になると、API呼び出しは失敗します。
  2. ChatGPT Plus、Business、Enterprise: これらは定額制のサブスクリプションです。ChatGPT Plusは月額$20、Businessプラン(旧Team)は月払いの場合、ユーザー1人あたり月額$25です。いずれもソフトな使用量上限があり、使用量の多いユーザーはブロックされる代わりに、より小さいモデルへ移行します。
  3. Spend-based rate tiers: 累積支出が時間とともに増えると、アカウントでより高いAPI rate limitsが利用可能になります。請求履歴に応じてアクセス範囲が広がります。
以下のトークン価格は、執筆時点で公開されている料金です。

独自性

OpenAIの請求方式をAIサービスに適したものにしているのは、次の4つの特徴です。
  • 法定通貨建てクレジット: クレジットは米ドル建てのため、実際のお金のように感じられます。開発者はリクエストの価格を直接確認できます。
  • 長い有効期限: 購入したクレジットは1年間有効なため、「使わなければ失う」というプレッシャーが軽減されます。ユーザーはより大きな金額を安心してチャージできます。
  • 多次元メータリング: 入力トークンと出力トークンは別々に追跡されますが、同じ残高から差し引かれます。OpenAIは、コストの高い出力トークンに入力トークンより高い価格を設定できます。
  • 信頼度 tiers: 累積支出に応じてrate limitsが上がる仕組みにより、長期顧客が優遇され、継続利用が促されます。

戦略上のメリット

このモデルは自己強化されます。低い導入コストによって開発者を呼び込みます。前払いクレジットは即時のキャッシュフローを生みます。使用量ベースの価格設定により、開発者が成功するほどOpenAIの収益も増加します。サブスクリプションは、開発者以外のユーザーから安定した基礎収益をもたらします。

Dodo Paymentsで構築する

Dodo Paymentsを使って、OpenAIの請求モデルを構築できます。API側にはCredit-Based Billingを使用し、ChatGPT Plus側には標準のサブスクリプションを使用します。
1

Create a Fiat Credit Entitlement

Dodo Paymentsダッシュボードで Products → Credits に移動し、Create Credit をクリックします。このクレジットが各ユーザーの基準残高になります。
  • Credit Type: Fiat Credits、Unit Currency はUSD
  • Credit Expiry: Customで365日(OpenAIの1年間の有効期限に一致)、またはNever
  • Rollover: 不要(クレジットは各サイクルでリセットされません)
  • Allow Overage: 無効
Fiat creditsは小数点以下2桁を使用するため、1クレジットは1ドルに相当し、残高はセント単位で追跡されます。Dodo Paymentsは残高がゼロになっても使用をブロックしません。OpenAIと同様に$0でAPI呼び出しを失敗させるには、各リクエストの前にアプリケーションで残高を確認します(下記の Handle Balance Depletion を参照)。
2

Create Top-Up Products

$5、$10、$50、$100など、異なるクレジットパック用のone-time payment productsを作成します。各製品にfiat creditを紐付けます。発行するクレジット数を、パックのドル価値に設定します。$50のパックでは50クレジットが発行されます。
3

Create Usage Meters

トークン使用量を追跡するため、2つのメーターを作成します。
  • llm.input_tokens: tokensプロパティに対するSum aggregation。
  • llm.output_tokens: tokensプロパティに対するSum aggregation。
usage-based productで両方のメーターの Bill usage in Credits をオンにし、fiat creditを選択します。次に、それぞれの Meter units per credit を設定します。

Meter units per creditの計算

OpenAIのGPT-4o pricingに合わせるには、1 fiat creditである$1あたりに何トークンかかるかを計算します。
  • Input Tokens: 1,000,000 tokens / $2.50 = $1あたり400,000 tokens。
  • Output Tokens: 1,000,000 tokens / $10.00 = $1あたり100,000 tokens。
Dodo Paymentsダッシュボードで、入力の Meter units per credit を400,000、出力を100,000に設定します。Dodo Paymentsは各メーターの集計トークン数をこの値で割り、差し引くクレジット数を算出します。
4

Send Usage Events

各LLMリクエストの後、使用量をDodo Paymentsに送信します。1つのリクエストに入力イベントと出力イベントの両方を含めることができます。このスニペットでは、前の手順のclientを再利用します。
5

Handle Balance Depletion

APIリクエストを処理する前に、ユーザーの残高を確認します。残高がゼロ以下の場合は、たとえば402 statusでリクエストを拒否します。

残高不足Webhookの処理

ユーザーが$0に達する前に通知します。クレジットを紐付ける際に Low Balance Threshold を設定し、credit.balance_low webhookが届いたら、メールまたはアプリ内通知を送信します。
OpenAIはauto rechargeを提供しており、ユーザーが設定したしきい値を残高が下回ると、追加のクレジットを購入します。
6

Build the ChatGPT Subscription Side (Optional)

ChatGPT Plusのようなサブスクリプションプランを提供するには、Dodo Paymentsで別のサブスクリプション製品を作成します。クレジットentitlementを付与する必要はありません。Teamプランには、seat-based billingを使用します。これは、ユーザー数を数量とする、シート単位のアドオンです。

ソフトな上限の実装

ソフトな上限を構築するには、クレジットに紐付けず、同じメーターでサブスクリプションユーザーの使用量を追跡します。アプリケーションで、現在の請求期間の使用量を確認します。

LLM Ingestion Blueprintで高速化する

上記の手順では、使用量イベントを手動で作成して送信します。一方、LLM Ingestion BlueprintはOpenAI clientをラップし、トークンを自動的に追跡します。
このBlueprintは、各APIレスポンスからinputTokens、outputTokens、totalTokensを読み取り、modelとともにイベントメタデータとして送信します。請求対象にするトークンキーを、メーターの Over Property に設定します。
LLM Blueprintは、OpenAI、Anthropic、Groq、Google Gemini、OpenRouter、Vercel AI SDKをサポートしています。プロバイダー固有の例や高度な設定については、完全なBlueprintドキュメントを参照してください。

Spend-Based Rate Tiersの実装

OpenAIのrate tiersは、信頼度に基づいて容量を管理します。これを構築するには、各顧客の累積支出を追跡します。
  1. 累積支出を追跡する: payment.succeeded webhooksをリッスンし、支払額をデータベース内のその顧客のtotal_spendフィールドに加算します。金額は最小通貨単位で表されるため、5000は$50.00です。
  2. tiersを定義する: 支出額をrate limitsに割り当てます。
    • Tier 1: 支出$0 - $50 -> 3 RPM
    • Tier 2: 支出$50 - $250 -> 10 RPM
    • Tier 3: 支出$250以上 -> 50 RPM
  3. 制限を適用する: API middlewareで顧客のtierを検索し、そのrate limitを適用します。

完全な実装例: API Proxy

本番環境では、通常、API proxyがユーザーとLLM providerの間に配置されます。proxyはリクエストを認証し、クレジットを確認して、使用量を報告します。 以下のhandlerがproxyを実装します。

エッジケースの処理

OpenAIのような請求システムには、計画しておくべきいくつかのエッジケースがあります。

Race Conditions

残高の少ないユーザーが複数のリクエストを同時に送信すると、イベントが処理される前に残高を超過する可能性があります。これを防ぐには、小さなバッファを確保するか、各リクエストの処理中に顧客残高の分散ロックを保持します。

Event Ingestion Latency

Dodo Paymentsはクレジットを非同期で差し引きます。バックグラウンドworkerは新しいイベントを約1分に1回処理するため、差し引きがAPI呼び出しに遅れる場合があります。厳密なリアルタイム適用が必要な場合は、各ユーザーの残高をローカルキャッシュに保持し、リクエストを処理するたびに更新します。

Refund Handling

クレジットパックの購入を返金しても、付与されたクレジットは削除されません。返金時には、debitでそのクレジットを手動で差し引きます。顧客の Credits タブで Apply Credit/Debit を使用するか、Create Ledger Entry APIを使用してください。その後、アプリケーション側の残高表示も更新し、ユーザーが保有していないクレジットを使用できないようにします。

Multi-Model Support

異なる価格の複数モデルをサポートするには、次のいずれかを選択します。
  1. Separate Meters: モデルごとに1組のメーターを作成します。たとえばgpt-4o.input_tokensとgpt-4o-mini.input_tokensを作成し、それぞれに独自の Meter units per credit を設定します。
  2. Weighted Events: 1つのメーターを使用し、イベント送信前にtokensへ重みを掛けます。たとえばGPT-4oがGPT-4o-miniの10倍の料金である場合、GPT-4oのリクエストではトークン数を10倍にして送信します。
OpenAIは各モデルに個別のrateを公開しており、Separate Metersはその構造に最も直接的に対応します。

アーキテクチャの概要

以下のループは、購入から呼び出しのブロックまでの前払いフローを示します。 メーターはトークンを追跡し、設定したrateに基づいて、そのドル価値をユーザーのクレジット残高から差し引きます。残高がゼロになると、アプリケーションが呼び出しをブロックします。

まとめ

Dodo Paymentsを使うと、OpenAIと同様に、使用量ベースの請求と前払いクレジットの予測可能性を組み合わせられます。顧客は前払いし、使用に応じて消費し、追加が必要になったらチャージします。 大規模なLLMプラットフォームでも小規模なAIツールでも、同じ要素を利用できます。fiat credit、トップアップ製品、トークンメーター、各リクエスト前の残高確認です。

使用するDodoの主な機能

実装を支えるDodo Paymentsの機能は次のとおりです。

Credit-Based Billing

ユーザー向けの前払いfiat creditsとentitlementsを管理します。

Usage-Based Billing

トークンなどの詳細な使用量を追跡し、請求します。

One-Time Payments

checkoutを通じてクレジットパックとトップアップを販売します。

Event Ingestion

大量の使用量データをDodo Paymentsに送信します。

Webhooks

クレジット残高の変更と残高不足アラートを常に把握します。

LLM Ingestion Blueprint

OpenAIおよびその他のLLM providers向けの自動トークン追跡。
最終更新日 2026年9月26日