AI時代の課金システム設計：クレジット・トークン管理と高スループット対応のインフラ

導入：現代のAIアプリケーションにおける課金インフラの進化

こんにちは、AutumnのCTOジョンと、当社の創業エンジニアであるチャーリーです。本日は、AIアプリケーションの収益化において、なぜ従来の課金システムとは異なるインフラが必要になるのかについてお話しします。

Autumnは「AI企業のための請求サービス」を提供していますが、これは具体的に何を意味するのでしょうか。私たちは「現代の企業のための請求サービス」と捉えています。

歴史を振り返ると、約10年前の課金システムは、ほとんどがサブスクリプションベースでした。毎月一定額を請求するシンプルなモデルです。そして数年前からは、使用量ベースの課金が主流となりました。インフラ企業が台頭し、コンピューティング時間など、期間全体で発生した使用量に基づいて月末に請求書を発行する形です。

しかし、AIアプリケーションの登場により、課金パターンに新たな変化が見られます。課金がアプリケーションと密接に連携するようになったのです。ユーザーがリクエストを送信する前に、トークン、クレジット、アクションといった要素を事前にチェックする必要が生じています。これには、これまでのシステムとは異なるインフラが求められます。

例えば、CodeXのようなサービスでメッセージを送信しようとした際に、「使用量制限に達しました」というエラーを見たことがある方もいるかもしれません。一見すると、Redisでレート制限を追跡している、あるいはPostgresで利用状況を記録しているだけのように見えるかもしれません。しかし、特に高スループットで並行処理がアトミックに実行される必要がある場合、その裏側には非常に多くの処理が存在します。本日は、その詳細と、私たちが他社で見てきた課題に対する解決策をご紹介します。

AI向け課金システムの基礎：シンプルなアプローチとその限界

まずは非常にシンプルな例から始めましょう。AIコーディングアシスタント向けの課金システムを構築するケースを考えます。すべてのユーザーに月100メッセージを付与するとします。

シンプルなカラム追加による初期アプローチ

データベースには既にcustomersテーブルがあるため、この機能を実装するために、単一のbalanceカラムを追加し、すべての顧客に初期値として100を設定します。モデルを呼び出す際には、単純に残高を確認し、使用量を減算するトランザクション処理を実行します。この方法であれば、Redisや他の外部キューを呼び出すことなく、安全な並行処理を実現できます。これは非常に基本的な課金設定ですが、このユースケースでは十分に機能します。

シンプルなアプローチが抱える課題：機能追加による複雑化

しかし、このシンプルなアプローチでは、拡張する際に問題が生じます。

例えば、アプリケーションにプロモーションコード機能を追加したいとします。プロモーションコードが「生涯残高」を提供するものだとすると、これは毎月リセットされる既存のbalanceとは異なる残高になります。これをどう管理するでしょうか？

新しいlifetime_balanceカラムをデータベースに追加することを検討するかもしれません。しかし、これには以下のような複雑性が伴います。

• アプリケーションロジックの追加: コードベースに新たなロジックを追加する必要があります。
• データベースマイグレーション: データベースのスキーマ変更が必要となります。
• 全体的な変更の複雑化: 全体として、かなりの複雑さが増します。

さらに、自動トップアップ機能やメッセージの繰り越し機能などを追加していくと、アプリケーションロジックはますます複雑になり、多くのマイグレーションが必要となることが容易に想像できます。そのため、私たちは一歩下がって、より良い方法を考えるべきです。

より柔軟な課金管理へ：行ベースのアプローチ

シンプルなアプローチの限界を克服するために、私たちは「行ベースのアプローチ」への移行を提案します。

残高を個別の行で管理する

新しいbalancesテーブルを作成し、各残高タイプを個別の行として管理します。例えば、月次残高、プロモーション残高、そして今後追加されるであろう自動トップアップ残高なども、それぞれが独立した行として追加されます。これらの残高行には、それぞれ独自の有効期限（expiries）やメタデータを付与することができます。

行ベースの課題と解決策

この方法では、残高の追跡が複数の行にわたるため、少し複雑になります。また、どの残高から優先的に差し引くかを決定する必要があります。これは、「最も有効期限が近い残高から優先的に差し引く」といった一貫したアルゴリズムを用いることで解決できます。このシステムにより、私たちは現在の残高がどのように構成されているかを正確に把握できるようになります。

トランザクションの履歴管理：台帳（Ledger）の導入

残高がどのように構成されているかはわかるようになりましたが、新たな問題として「なぜその状態になったのか」という経緯が不明であるという点があります。

なぜ台帳が必要か：残高の「なぜ」を追跡する

これを解決するために、「台帳（Ledger）」を追加します。この台帳には、残高に関するすべての履歴情報が記録されます。具体的には、残高の削除、作成、そして残高からの使用追跡といったすべてのイベントを台帳に記録します。これにより、私たちは任意の時点に遡り、その時点での残高がどうであったか、そしてその状態に至った経緯を正確に確認できるようになります。

台帳の活用例：カスタマーサポートの効率化

Autumn社では、この台帳が非常に役立っています。お客様が使用するSlackボットが台帳を検索し、残高がどのように変化したのか、誰が残高を追加したのか、削除したのかといった情報を正確に提供します。これにより、カスタマーサポートの多くの負担が軽減されています。

リアルタイム性と履歴の共存：カウンタと台帳の連携

台帳があることで、残高の履歴を詳細に追跡できるようになりました。ここで、台帳から現在の残高を計算しようと考える方もいるかもしれません。

台帳からの残高計算の課題

台帳のイベントを集計して残高を計算する方法（マテリアライズドビューを作成したり、台帳のすべてのイベントを集計したり）は、月末の課金計算やダッシュボードに表示する値の算出には適しています。しかし、AIコーディングアシスタントのようなリアルタイム性が求められるアプリケーションや、Autumnの課金システムでは、この方法は十分に機能しません。

リアルタイムカウンタの導入

リアルタイムな残高チェックのために、私たちは別の「カウンタ」を導入します。これは、現在の残高値を保持するためにRedisのような高速なストレージに配置される可能性があります。このカウンタを使用することで、複雑な集計処理を行うことなく、現在の残高値を非常に迅速にチェックできます。

結論として、台帳とカウンタの二つを連携させて使用するのが、このケースにおける最善のアーキテクチャです。台帳は詳細な履歴と監査のために、カウンタは高速なリアルタイムチェックのために機能します。

高スループットとアトミックな要求処理の実現

チャーリーは、クレジットベースのシステム（Redisをカウンタとして、ClickHouseなどを台帳として使用）の基礎を説明しました。次に、非常に高いスループットと、各リクエストがアトミックに処理される必要があるケースに焦点を当てます。これは、APIを構築している多くのAI企業にとって非常に重要です。

AI APIにおける高スループットとアトミック性の課題

現在のAIの世界では、多くの企業がAPIを提供し、毎秒大量のリクエストを処理しています。従来、高スループットなシナリオを解決する方法として、各イベントをキューに送信し、非同期で処理するというものがありました。しかし、AIアプリケーションの場合、この非同期処理は問題を引き起こします。

非同期メソッド（キューなど）では、残高の引き落とし処理がバックグラウンドで行われるため、タイムラグが発生します。複数のエージェントが同時に大量のリクエストを送信した場合、それぞれの要求がリアルタイムの正確な残高情報を持たないため、顧客は残高を超過して利用してしまう（オーバードラフト）可能性があり、結果として多くのクレジットが不正に使用されてしまいます。

「ロック＆リリース」モデルの導入

この問題に対し、今日多くの企業が採用しているアーキテクチャは、「ロック＆リリース」と呼ばれるモデルに似ています。例えばChatGPTでは、ユーザーがメッセージを送信すると、まずメッセージの長さなどに基づいて使用されるであろうクレジット量を推定します。そして、そのクレジット量を一時的にロックすることで、リアルタイムでの正確な残高管理とアトミックな処理を可能にしています。

まとめ

現代のAIアプリケーションの課金システムは、単なるサブスクリプションやシンプルな従量課金を超えた複雑な設計が求められます。月次、プロモーション、自動トップアップなど、多様な残高タイプを柔軟に管理するためには「行ベースのアプローチ」が有効です。また、残高の履歴を正確に追跡し、監査性やカスタマーサポートの効率化を図るためには「台帳（Ledger）」が不可欠です。

リアルタイムな残高チェックには「カウンタ（Redisなど）」を活用し、台帳と連携させることで、パフォーマンスと信頼性を両立させることができます。特に高スループットなAI APIでは、非同期処理のラグによるオーバードラフトを防ぐため、「ロック＆リリース」のようなアトミックな処理を保証する設計が重要です。これらのアーキテクチャパターンを理解し、適切に組み合わせることで、堅牢でスケーラブルなAI時代の課金システムを構築できるでしょう。

参考動画

[YouTube動画] AI時代の課金システム：なぜ特別なインフラが必要か？ https://www.youtube.com/watch?v=ZY2y0u1Qu6w