従量課金は新しい概念ではありませんが、人工知能 (AI) 製品はその要求水準を、標準的なプロセスでは対応できないレベルにまで引き上げています。トークン数の変動、数百のダウンストリーム呼び出しに広がるエージェントループ、そして数分でスパイクしうるワークロードは、従来のアプリケーションプログラミングインターフェース (API) 課金では解決する必要がなかった、イベント帰属・メータリングの正確性・コスト管理における技術的課題を生み出しています。実際、IT リーダーの 46% は、予測不可能な料金体系が組織における生成 AI 導入の主な障壁だと回答しています。

以下では、AI サービスへの従量課金の実装方法、生のイベントを明確な課金合計に変換する方法、そして不審請求の申し立てになる前にコストの暴走を検知するガードレールの追加方法について説明します。

ハイライト

• 使用イベントコントラクトは、すべてのダウンストリーム処理の基盤です。早期のスキーマ設計の判断は、料金モデルの変更時や不審請求の申し立てを解決する際の難易度を左右します。

• 重複排除、遅延イベントのポリシー、修正、ルールのバージョニングにより、信頼性の高い請求書を生成するシステムと、最終的に二重計上が発生するシステムが区別されます。決定性とべき等性はオプションではありません。

• コスト管理は実行レイヤーに組み込む必要があります。クレジットの予約、エージェントループのサーキットブレーカー、異常検知は、使用量が発生する前に機能する必要があります。

AI 企業における従量課金とは

従量課金は、定額料金ではなく、消費量 (処理されたトークン、コンピューティング秒数、API コール、エージェントアクションなど) に比例して顧客に請求します。

このモデルが柔軟である理由は、推論コストが顧客によって桁違いに異なるためです。定額料金制はヘビーユーザーを補助するか、ライトユーザーを遠ざけることになります。従量制価格設定では、使用イベントを出力し、確実に取り込み、正確にメータリングし、多くの場合ほぼリアルタイムで請求書に変換できるパイプラインが必要です。

AI 企業における従量課金の仕組み

大まかに言うと、システムはプロダクト内の課金対象アクションから顧客の請求書の項目へと移行します。各ステージには固有の障害モードがあり、適切に設計されていない場合は問題が連鎖的に拡大します。

各ステージとその仕組みを以下に示します:

• 出力: アプリケーションは、課金対象のアクション (補完、埋め込みリクエスト、ツールエージェント、エージェントステップ) が発生するたびに使用イベントを出力します。

• 取り込み: イベントはパイプラインを通じて流れ、検証され、バッファリングされ、永続的に保存されます。パイプラインはレコードの欠落や性能の低下を招くことなく、トラフィックを吸収できる必要があります。

• メータリング: 生のイベントは請求期間にわたって課金対象の数量に集計されます。このレイヤーは単位定義、価格ロジック、集計ルールを一貫して適用します。

• 請求書: メータリングされた合計が請求システムに渡され、請求書の項目が生成され、クレジットや割引が適用され、顧客に請求されます。

各レイヤーは独立して正確である必要があります。数週間後に収益の不一致が判明した際に取り込みの問題を発見するような事態は避けるべきです。

AI 固有の動作が従量課金の運用をより困難にする理由

従来の API は、1 つのリクエストが 1 つのレスポンスと 1 つの課金イベントを生成するというシンプルなマッピングを前提としています。AI ワークロードはそのような動作をしません。

AI 固有の動作が従量課金の運用をより困難にする理由を以下に示します:

エージェントループとツール呼び出しのファンアウト

「このトピックを調査してレポートを作成する」などの 1 つのユーザーアクションが、数十から数百の大規模言語モデル (LLM) 呼び出し、ツール呼び出し、検索ステップを起動することがあります。帰属の判別はすぐに複雑になります。どのアクションが課金対象なのか。1 つのエージェントセッションが複数のユーザー、プロジェクト、テナントにまたがる場合、誰に請求すべきか。イベントスキーマのレベルで定義されていなければ、後から修正することがより困難になります。

トークンの変動性

入力トークンと出力トークンはコストが異なり、事前に予測することはできません。200 トークンのプロンプトを含むリクエストは、タスク、モデル設定、生成動作によって 50 トークンを返すこともあれば、数千トークンを返すこともあります。リクエストサイズに基づいて事前に課金することはできません。実際のカウントを含む実行後のイベントを出力する必要があります。

不均一なワークロード

午前 2 時のエンタープライズバッチジョブは、数時間で過去 2 週間分を合わせたよりも多くの使用量を生成することがあります。取り込みシステムは、イベントの欠落、遅延、請求の遅れを招くことなく、これらのスパイクを処理できる必要があります。

非決定論的コスト

同じプロンプトでも、特にストリーミング、関数呼び出し、エージェントチェーンを使用する場合、実行ごとに異なるトークン数が生成されることがあります。これにより決定論的テストが困難になるため、最初から分散に対応できるように設計されたメータリングロジックが必要です。

非決定論的コスト

同じプロンプトでも、特にストリーミング、関数呼び出し、エージェントチェーンを使用する場合、実行ごとに異なるトークン数が生成されることがあります。

AI 企業にとって信頼性の高い使用イベントコントラクトとは

使用イベントは、課金システムの最小単位です。メータリングから請求書発行、監査に至るすべてのダウンストリームシステムは、イベントコントラクトが安定かつ明示的であることを前提としています。

信頼性の高い使用イベントコントラクトは以下のようなものです:

• 顧客およびプロジェクトの識別子: 顧客が組織名を変更しても、アカウント階層を変更しても変わらない、安定した不変の ID。

• アクションのタイムスタンプ: イベントが送信された時刻ではなく、アクションが発生した時刻。非同期パイプラインは、期間帰属に影響する遅延を生じさせる可能性があります。

• 単位と数量: 計測対象 (例: 入力トークン、出力トークン、計算秒数) とその量。価格設定上同一に扱う場合を除き、単位はアトミックに保持してください。

• 相関 ID: 使用イベントを元のリクエスト、セッション、またはエージェント実行に紐付ける一意の識別子。これにより、請求書の項目をアプリケーションのログまでトレースできます。

• 課金フラグと理由コード: すべてのアクションが課金対象とは限りません。課金の判断は、監査が難しくなるダウンストリームのロジックに埋め込むのではなく、イベント内で明示的に行ってください。

• スキーマバージョン: 料金モデルが変更された場合、新旧のイベントが共存する必要があります。バージョニングによりそれが可能になります。

AI 企業は従量課金のために取り込みとストレージをどのように設計すべきか

このレイヤーでは、信頼性と不変性の 2 つの要件が最も重要です。その他すべて (スループット、レイテンシ、スキーマ検証) はこれらの目標のために機能します。

AI 企業が取り込みとストレージを設計する方法を以下に示します:

信頼性

「少なくとも 1 回の配信」セマンティクスを持つ耐久性のあるキューシステムへ書き込みます。キューは一時的な障害から保護し、下流のコンシューマが重複排除を処理します。アプリケーションから使用イベントを直接データベースへ書き込まないでください。

必須フィールドが存在すること、識別子が正しく解決されること、タイムスタンプが妥当であることを確認します。不正なデータがメータリングに漏れ込まないよう、形式が不正なイベントは明確なエラーとともに早期に拒否します。

バーストに対して明示的に設計します。プロビジョニングが不十分な取り込みは、通常イベントの欠落によって失敗します。

不変性

生のイベントストアは追記専用にする必要があります。つまり、ファイルやデータベースの末尾に新しいデータを追加 (追記) できますが、既存のデータは不変であり (変更や削除はできず) 残り続けます。トークン数の誤算や顧客の誤帰属などのミスが発生した場合は、元のレコードを編集するのではなく、元のレコードを参照する修正イベントを出力します。これは不審請求の申し立てを解決するうえで絶対条件です。顧客が請求書に対して不審請求を申し立てる場合、その数値を生成したイベントの正確なシーケンスを再現できる必要があります。

AI 企業はどのようにして生の使用イベントを正確な課金ロールアップに変換するか

メータリングは精度が重要なレイヤーです。同じ入力イベントとルールが与えられた場合、出力は常に同じでなければなりません。

それを可能にする 4 つの特性があります:

• 重複排除とべき等性: 「少なくとも 1 回の配信」は重複を保証します。このべき等性 (操作の出力が同じ結果をもたらす) により、すべてのイベントに一意の ID が必要となり、集計はカウント前に重複排除を行う必要があります。これがないと、二重請求が発生しやすくなります。

• 遅延イベントの処理: イベントは順番通りに到着しません。「境界から X 分後に請求期間を終了し、そのカットオフまで遅延イベントを受け入れ、それを超えるものにはフラグを立てるか拒否する」というような明確なポリシーを定義してください。一貫性が重要です。

• 修正イベント: エラーが発生した場合、合計を調整し、元のイベントを参照し、変更の理由を説明する修正イベントを出力します。過去の集計を書き換えないでください。

• ルールのバージョン管理: 価格設定ルールは変更される可能性がありますが、イベントは発生時に有効だったルールに従ってメータリングされる必要があります。現在のルールを前四半期の使用量に適用すると、誤った請求書が生成されます。

Stripe Billing などのツールは請求書側で集計を処理しますが、内部のメータリングレイヤーは独自のロールアップを独立して生成する必要があります。これらが照合のための信頼できる情報源となります。

AI 企業はコスト管理にガードレールをどのように活用するか

AI ワークロードは、人間が介入できる速度を超えて支出 (自社および顧客の支出) を発生させることがあります。ガードレールはリアルタイムで機能する必要があります。

以下に、AI 企業がコストの暴走を防ぐためにガードレールを活用する方法を示します:

クレジット台帳と予約

使用量を発生させるアクションを実行する前に、予想コストを顧客の残高に対して予約します。予約が失敗した場合は、アクションを実行しません。実行後は、実際の使用量に基づいて精算します。これはクレジットカードのオーソリ処理と同じ考え方であり、AI 課金に適したメンタルモデルです。

ソフトリミットとハードリミット

ハードリミットは使用を完全に停止します。ソフトリミットはしきい値に近づくとアラートを発します。どちらも顧客ごと、プロジェクトごとに設定可能にする必要があります。本番ワークロードとトライアルアカウントでは許容範囲が異なります。

エージェントワークロード向けサーキットブレーカー

エージェントには特別な処理が必要です。最大ステップ数、セッションあたりの最大支出額、自動キルスイッチを設定してください。これらは課金後ではなく、実行時に適用してください。課金システムがイベントを認識した時点で、コストはすでに発生しています。

異常検知

顧客ごとの使用ペースを追跡し、定義されたしきい値 例: 1 単位あたり $0.1) を超える逸脱にフラグを立てます。多くの場合、人間によるレビューリストを伴う自動一時停止が適切な対応です。目的は、暴走したプロセスが不審請求の申し立てや売上原価 (COGS) の想定外の事態につながる前に検知することです。

Stripe Billing でできること

Stripe Billing を使用すると、シンプルな継続課金から従量課金、商談による契約まで、自由に請求や顧客管理を行えます。ノーコードで、グローバルな継続課金をわずか数分で開始できます。API を活用した独自のシステム構築も可能です。

Stripe Billing でできること:

• 柔軟な料金体系の提供: 従量課金、段階制料金体系、定額料金 + 超過料金など、柔軟な料金体系でユーザーのニーズにすばやく対応できます。クーポン、無料トライアル、比例配分、アドオンのサポートも組み込まれています。

• グローバルに拡大: 顧客が希望する決済手段を提供することでコンバージョンを向上させます。Stripe は 100 以上の現地決済手段と 130 以上の通貨をサポートしています。

• 収益を増やし解約を減らす: Smart Retries と回収ワークフローの自動化で、収益回収を改善し、決済不履行による解約を減らします。Stripe のリカバリツールは、2024 年にユーザーが 65 億ドル以上の収益を回収するのをサポートしました。

• 業務効率の向上: Stripe のモジュール型税務管理、収益レポート、データツールを活用して複数の収益管理システムを 1 カ所に統合します。外部のソフトウェアとも簡単に連携できます。

Stripe Billing について詳細を見るか、今すぐ始める。