なぜOpenAIのモデルが標準なのか
従来のSaaS課金では、AI使用量の変動コストを適切に扱えません。OpenAIのモデルは、次の3つの問題を同時に解決します。- 予測可能な収益と低リスク: APIの使用量は前払いされるため、ユーザーが支払えない請求額まで使い込むことはありません。OpenAIは先に代金を受け取り、ユーザーはサービスの利用に応じてその金額を消費します。
- 開発者向けのスケーラビリティ: $5のトップアップは導入へのハードルが低い金額です。アプリケーションの成長に応じて、開発者はトップアップを自動化したり、より大きなパックを購入したりできます。安価に始められ、プランを変更せずに使用量を増やせます。
- ユーザー心理: 抽象的な「トークン」や「ポイント」ではなく米ドルで表示されたクレジットにより、価値が明確になります。残高はAIサービス用のプリペイドアカウントのように機能するため、企業は予算を管理しやすくなります。
OpenAIの請求方法
OpenAIは、ユーザーの種類に応じて2つの課金モデルを運用しています。- API (Pay-as-you-go): APIでは、米ドル建ての前払いクレジットを使用します。ユーザーはアカウントに $5、$10、$50、またはそれ以上をチャージします。クレジットにはドルの価値が表示されますが、OpenAI以外では使用できません。OpenAIはトークン単位で請求し、入力トークンと出力トークンで異なる料金を設定しています。購入したクレジットの有効期限は購入から1年後で、返金はできません(OpenAI Help Center)。残高が$0になると、API呼び出しは失敗します。
- ChatGPT Plus、Business、Enterprise: これらは定額制のサブスクリプションです。ChatGPT Plusは月額$20、Businessプラン(旧Team)は月払いの場合、ユーザー1人あたり月額$25です。いずれもソフトな使用量上限があり、使用量の多いユーザーはブロックされる代わりに、より小さいモデルへ移行します。
- 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: 無効
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。
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。
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が届いたら、メールまたはアプリ内通知を送信します。6
Build the ChatGPT Subscription Side (Optional)
ChatGPT Plusのようなサブスクリプションプランを提供するには、Dodo Paymentsで別のサブスクリプション製品を作成します。クレジットentitlementを付与する必要はありません。Teamプランには、seat-based billingを使用します。これは、ユーザー数を数量とする、シート単位のアドオンです。
ソフトな上限の実装
ソフトな上限を構築するには、クレジットに紐付けず、同じメーターでサブスクリプションユーザーの使用量を追跡します。アプリケーションで、現在の請求期間の使用量を確認します。LLM Ingestion Blueprintで高速化する
上記の手順では、使用量イベントを手動で作成して送信します。一方、LLM Ingestion BlueprintはOpenAI clientをラップし、トークンを自動的に追跡します。inputTokens、outputTokens、totalTokensを読み取り、modelとともにイベントメタデータとして送信します。請求対象にするトークンキーを、メーターの Over Property に設定します。
Spend-Based Rate Tiersの実装
OpenAIのrate tiersは、信頼度に基づいて容量を管理します。これを構築するには、各顧客の累積支出を追跡します。- 累積支出を追跡する:
payment.succeededwebhooksをリッスンし、支払額をデータベース内のその顧客のtotal_spendフィールドに加算します。金額は最小通貨単位で表されるため、5000は$50.00です。 - tiersを定義する: 支出額をrate limitsに割り当てます。
- Tier 1: 支出$0 - $50 -> 3 RPM
- Tier 2: 支出$50 - $250 -> 10 RPM
- Tier 3: 支出$250以上 -> 50 RPM
- 制限を適用する: 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
異なる価格の複数モデルをサポートするには、次のいずれかを選択します。- Separate Meters: モデルごとに1組のメーターを作成します。たとえば
gpt-4o.input_tokensとgpt-4o-mini.input_tokensを作成し、それぞれに独自の Meter units per credit を設定します。 - Weighted Events: 1つのメーターを使用し、イベント送信前に
tokensへ重みを掛けます。たとえばGPT-4oがGPT-4o-miniの10倍の料金である場合、GPT-4oのリクエストではトークン数を10倍にして送信します。
アーキテクチャの概要
以下のループは、購入から呼び出しのブロックまでの前払いフローを示します。 メーターはトークンを追跡し、設定した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向けの自動トークン追跡。