AI 自動化の課金インフラストラクチャは、エージェントのワークロードを財務的に説明可能な状態に保つ、計測、会計、ポリシー、レポート層です。これは、通常の API 分析よりも難しい質問に答えます。何が起こったかだけでなく、誰が料金を支払うべきか、実行前に許可されたかどうか、価格設定方法、料金が最終的なものであるかどうか、プロバイダーの請求書とどのように調整されるかなどです。

AI エージェントや自動化が単純なワンショット チャット リクエストのように動作することはほとんどないため、これは重要です。 1 つのユーザー アクションが、複数のモデル呼び出し、ツール呼び出し、再試行、キャッシュされたコンテキストの読み取りと書き込み、コード実行、ファイル検索、Web 検索、イメージ生成、ストリーミング応答、非同期ジョブ、バッチ行に展開される可能性があります。耐久性のある請求設計がなければ、コストは事後的にしか明らかにならず、その原因を特定したり説明したりするのはすでに困難です。

個人の開発者、創設者、コンサルタント、またはサービス構築者にとって、請求インフラストラクチャは大規模な財務システムとして開始する必要はありません。使用状況イベント、属性、価格バージョン、支出管理、調整のための明確なモデルが必要です。目標は、チャートを請求書として扱う、またはプロバイダー ダッシュボードを顧客向けの請求の信頼情報源として扱うというよくある罠を回避することです。

AI 自動化請求インフラストラクチャに含まれるもの

完全な請求レイヤーが、リクエスト受付から最終レポートまでのライフサイクルをカバーします。リクエストが実行される前に、呼び出し元に権限、予算、モデルへのアクセス、ツールへのアクセス、および十分な予想される残高があるかどうかがチェックされます。実行中に、選択されたプロバイダー、解決されたモデル、トークン カテゴリ、ツール イベント、再試行、ストリーム状態、および非同期ジョブ ID が記録されます。実行後は、実際の使用量を決済し、未使用の予約を解放し、調整を記録し、レポートを公開します。

その範囲により、課金インフラストラクチャはオブザーバビリティとは異なります。可観測性ツールは、モデルの呼び出しを追跡し、レイテンシー、トークン数、障害を測定できます。請求インフラストラクチャは、監査可能な金銭記録を生成する必要があります。不変性、冪等性、価格カタログのバージョン管理、10 進数を安全な算術演算、テナント スコープの権限、および内部記録とプロバイダの使用状況 API または請求書を照合する方法が必要です。

同じ区別が分析ダッシュボードにも当てはまります。モデルごとの支出を示すグラフは便利ですが、払い戻し、紛争、再販業者のマージン、前払い残高、または顧客の請求書をサポートするには十分ではありません。請求には台帳が必要です。分析はその台帳から構築できますが、台帳をチャートからリバース エンジニアリングしてはなりません。

リクエストのライフサイクル: 見積り、予約、実行、決済、調整

1.入場料と見積もり

請求ライフサイクルはプロバイダーのディスパッチ前に始まります。ゲートウェイまたはアプリケーションは、アカウント、テナント、ユーザー、API キー、ワークフロー、エージェント実行、モデル エイリアス、要求されたツール、および資格情報モードを識別する必要があります。次に、選択したモデル、エンドポイント、予想される入力、最大出力、ツール構成、および現在の価格カタログのバージョンを使用してコストを見積もる必要があります。

見積もりは多くの場合不確実です。出力の長さが不明です。エージェントはツールの使用を決定する場合があります。ホストされたツールでは別の料金が発生する場合があります。配信が中止される場合がございます。バッチ ジョブは部分的に失敗する可能性があります。適切な見積もりは、リクエストを実行する前に最終的なコストが決まっているように見せるのではなく、見積もりと不確実性の両方を記録します。

2.予約

前払いアカウントまたは厳密な予算の場合、システムは実行前に資金を予約する必要があります。予約は、最大トークン、予想されるツールの使用、ワークフローの予算、または上限付きの見積もりに基づいて行うことができます。リクエストが予約を下回って終了した場合、未使用の残高は解放されます。見積もりを超えた場合、システムは追加の作業を拒否するか、承認を要求するか、ポリシーに従って超過分を精算します。

予約はエージェント ループでは特に重要です。実行後にのみ支出制限がチェックされる場合、再試行の嵐や境界が不十分な計画ループにより、課金レイヤーが介入する前に費用が消費される可能性があります。

3.実行キャプチャ

実行中、課金レイヤーはプロバイダ応答メタデータ、最終ストリーミング使用状況イベント、非同期ジョブ結果、バッチ行結果、ホストされたツール イベント、およびプロバイダ コスト API（利用可能な場合）から使用状況を収集する必要があります。また、失敗とキャンセルの状態も記録する必要があります。ストリーミング中のクライアントの切断は、プロバイダーの障害と同じではなく、最終使用量の完了した応答とも同じではありません。

エージェント API の使用量測定の場合、請求対象の顧客単位はエージェントの実行である場合がありますが、インフラストラクチャ決済単位は多くの場合、モデル呼び出し、ツール呼び出し、コンテナー ランタイム、キャッシュ書き込み、キャッシュ読み取り、取得操作、またはバッチ項目などの下位レベルです。両方のレベルを保持する必要があります。

4.決済と調整

決済では、特定の価格カタログ バージョンを使用して、取得した使用量をお金に変換します。記録には、コスト基準、通貨、単価、マークアップまたは割引、プロバイダー、解決済みモデル、トークン クラス、ツール単位、および結果が暫定か最終かが含まれている必要があります。

一部のコストはすぐには確定できません。非同期ジョブは後で完了します。プロバイダーの使用 API は遅延する可能性があります。請求書には遅延調整が含まれる場合があります。ストリーミング リクエストは、切断後に最終的に使用されなくなる可能性があります。元帳は、見積、最終、調整、返金、請求済みなどの状態をサポートする必要があります。履歴の上書きは避けてください。説明がそのまま残るように調整記録を追加します。

5.調整

調整では、内部の使用状況記録をプロバイダーのダッシュボード、コスト API、請求書と比較します。差異は正常です。プロバイダーによって丸め方が異なったり、報告が遅れたり、請求書スキーマが変更されたり、要求時に取得されたゲートウェイよりも詳細が公開されなかったりする場合があります。耐久性のある内部台帳を使用すると、プロバイダーのレポートが集計されたり遅れたりする場合でも、顧客の料金を説明できます。

FOCUS などの財務指向の標準は、割り当てとチャージバックのためのクラウド費用データセットの正規化に役立ちますが、AI の請求には通常、トークン クラス、モデルのエイリアス、ホストされたツール、キャッシュの動作、エージェントの実行、およびプロバイダーの資格情報モード用の追加フィールドが必要です。

AI エージェントの測定内容と自動化

基本的なトークンのカウントだけではもはや十分ではありません。最新の AI ワークロードには、それぞれ異なる価格、制限、属性ニーズを持つ複数の請求可能なディメンションを含めることができます。

  • 入力トークンと出力トークン: プロンプト、完了、生成された応答コンテンツを含む、テキスト モデル呼び出しのベースライン。
  • キャッシュされたコンテキスト: キャッシュされた入力、キャッシュ作成、キャッシュ読み取り、およびキャッシュ書き込みには異なる値を含めることができます。
  • 推論または非表示のコンピューティング トークン: 一部のモデルは、推論または内部コンピューティング用に別個の使用カテゴリを公開しています。ユーザーから非表示にされている場合でも、コストと制限に影響を与える可能性があります。
  • 埋め込みトークン: 取得およびインデックス作成のワークフローでは、多くの場合、独自の価格と属性ニーズを持つ埋め込みモデルが使用されます。
  • マルチモーダル ユニット: 画像、音声、ビデオ、ファイルは、モダリティ固有のトークン化または請求が行われる場合があります。
  • ホストされたツール: Web 検索、ファイル検索、コード実行、コンテナ、コンピュータの使用、画像生成、接地、および外部コネクタにより、トークン以外の料金が発生する可能性があります。
  • エージェント イベント: 実行、ステップ、ツール呼び出し、ハンドオフ、サブエージェント、再試行、キャンセル、およびガードレール イベントは、 attribution.
  • バッチ項目と非同期項目: バッチ ジョブでは、失敗した項目や再試行された項目を含め、行ごとまたは項目ごとの決済を保持する必要があります。

プロバイダーは、これらのディメンションの多くをさまざまな方法ですでに公開しています。キャッシュされていない入力、キャッシュされた入力、キャッシュの作成、出力などのトークン カテゴリを提供するものもあります。ツール呼び出しの価格設定やコンテナーのランタイムを公開しているものもあります。一部のゲートウェイでは、入力トークン、出力トークン、キャッシュ読み取り、およびキャッシュ書き込みのカスタム要求レベルのコスト入力が可能です。実際的な結論は簡単です。最初から複数の請求可能なディメンションに合わせて使用​​スキーマを設計します。

あまり早く折りたたむべきではないアトリビューション境界

AI エージェントのコスト追跡は、正しい識別子の保持に依存します。多くの顧客が 1 つの API キーを共有している場合、またはワークフローがエージェントの実行に関連付けられていない場合、コスト レポートは推測になります。便利な台帳は、どの顧客、キー、ユーザー、ワークフロー、エージェント実行、モデル エイリアス、解決されたプロバイダー モデル、ツール、プロバイダー資格情報が料金の原因となったかなどの質問に答えることができます。

一般的なアトリビューション ディメンションには、アカウント、テナント、顧客、ユーザー、API キー、プロジェクト、ワークフロー、エージェント実行、リクエスト、再試行、モデル エイリアス、解決済みモデル、プロバイダー、プロバイダー資格情報、請求パス、ツール、リージョン、価格カタログが含まれます。バージョン。再販業者やパートナーのシナリオでは、下流の顧客 ID、ウォレット残高、マークアップ プラン、請求書参照、資金操作のための冪等性キーも必要になる場合があります。

これが、多くのビルダーが最終的にプロバイダー ネイティブの課金からゲートウェイ モデルまたはコントロール プレーン モデルに移行する理由の 1 つです。 チーム用のマルチモデル API ゲートウェイ は、プロバイダ ダッシュボードが同じオブジェクト モデルを共有していない場合でも、プロバイダ、モデル、キー、ユーザー間で一貫した帰属を維持できます。

認証情報モードは請求に関する決定です

認証情報モードは、プロバイダの使用に対する商業的責任を誰が負うかを決定します。ゲートウェイ資金によるトラフィック、持ち込みキーのトラフィック、テナントバインドのプロバイダ キー、プールされたプロバイダ キー、リセラー資金によるトラフィックにはすべて、異なる調整ルールとマージン ルールがあります。

BYOK ではプロバイダとの関係を直接的に保ち、マークアップの曖昧さを軽減できますが、レポートは顧客所有のアカウント間で断片化される可能性があります。プールされたプロバイダー資格情報により、ルーティングと調達が簡素化されますが、共有請求書内で 1 つのテナントの使用状況が見えなくなることがないように、強力な台帳帰属が必要です。ゲートウェイが資金を提供するトラフィックにより、統合されたプリペイド残高とマージン制御が可能になりますが、ゲートウェイは価格カタログ、プロバイダーの認証情報、調整プロセスを維持する必要があります。

すべての使用イベントで認証情報のソースと請求経路を記録します。これはセキュリティ分野だけではありません。これにより、レコードが顧客請求、パススルー プロバイダーのコスト、マージンを伴う再販イベント、または分析にのみ表示される使用状況イベントであるかどうかが決まります。

エージェント ワークロードの支出制御

支出制御は、ディスパッチ前に機能し、実行中ずっと表示される場合に最も効果的です。前払い残高チェック、キーごとの上限、ユーザーごとの予算、テナントの予算、ワークフローの予算、モデルの許可リスト、ツールの権限、ソフト アラート、ハード拒否、一時的なオーバーライドをサポートする必要があります。

API キーはアプリケーション、顧客、自動化、または環境にマッピングされることが多いため、キーごとの制御は特に便利です。各キーに明確な所有者と予算がある場合、アカウント全体を凍結することなく、暴走したワークフローを停止できます。キー スコープの制限の詳細については、LLM API キー による支出制限をご覧ください。

支出コントロールには優先度モデルが必要です。たとえば、アカウント残高が外側の制限であり、テナントの予算がその下にあり、キー キャップがテナントの下にあり、ワークフローの予算がキーの下にある場合があります。オーバーライドは期限を設け、監査され、影響するレイヤーを明示する必要があります。

優れた制御では、警告と拒否も区別されます。長期にわたって実行されるエージェントには、予算の 50、80、および 95% でソフト アラートが必要な場合があり、その後、追加のツール呼び出しやモデル ステップを適切に拒否する必要があります。すべてのアクティビティを突然停止すると、過剰支出を防ぐことができますが、実行層が適切に停止する方法を認識していない限り、ジョブが混乱した状態のままになる可能性があります。

使用状況台帳: コアの請求オブジェクト

台帳は記録システムです。各加線は、後で監査できる十分なコンテキストを備えた永続的な使用状況または金銭イベントを表す必要があります。少なくとも、元帳明細行には、タイムスタンプ、アカウント、テナントまたは顧客、可能な場合はユーザー、API キー、リクエスト ID、エージェント実行 ID、プロバイダー、解決済みモデル、エンドポイント、トークン カテゴリ、ツール ユニット、ステータス、通貨、単価、カタログ バージョン、コスト、マークアップ、決済状態、および調整参照が含まれている必要があります。

実装の場合は、財務イベントの追加専用レコードを使用します。最終的な料金を適切に更新することは避けてください。後でプロバイダーが修正を報告した場合は、元の修正を参照する調整明細を作成します。返金が行われた場合は、返金を別の資金移動として記録します。これにより、顧客サポートと請求書の調整がはるかに簡単になります。

金額には 10 進数を安全な演算を使用し、使用には高精度の数値フィールドを使用します。浮動小数点の丸め誤差は、クレジット残高、再販業者のウォレット、または請求書のエクスポートでは許容されません。冪等性キーは、クレジットの補充、Webhook 取り込み、非同期決済、手動調整、顧客プロビジョニング、パートナー API の操作にも使用します。変更リクエストを再試行しても、重複したクレジットや重複した料金が作成されることはありません。

価格カタログのバージョン管理

モデルの価格は変更されます。プロバイダーの SKU が変更されます。モデルのエイリアスが再ポイントされます。ツール料金、キャッシュ料金、地域修飾子、バッチ割引、再販業者のマークアップは進化します。すべての変更後も、過去の使用状況は説明可能なままである必要があります。

価格カタログには、モデル SKU マッピング、プロバイダー、エンドポイント、トークン カテゴリ、ツール タイプ、単位、通貨、発効日、既知の場合は有効期限、バッチ層、キャッシュ動作、リージョン修飾子、マークアップまたは割引ポリシー、およびソースの出所を含める必要があります。決済では、現在のモデル名だけでなく、使用されているカタログ バージョンを保存する必要があります。

これはモデルのエイリアスについて重要です。アプリケーションが優先コーディング モデルや高速チャット モデルなどの汎用エイリアスを呼び出した場合でも、請求レコードには実行時に使用される解決されたプロバイダー モデルが必要です。そうしないと、ルーティング ルールの変更後に過去の料金を説明できなくなります。

レポートと顧客向け API

顧客向けレポートでは、集計と生の使用状況イベントの両方を公開する必要があります。集計は、ユーザーが日別、モデル別、キー別、ユーザー別、テナント別、ワークフロー別、ツールタイプ別、キャッシュ動作別、エージェント実行別の支出を理解するのに役立ちます。生のイベントは、紛争処理、デバッグ、チャージバックに役立ちます。

レポート API では、安定した順序付け、カーソル ページネーション、テナント スコープの承認、プロンプトセーフな編集、および明示的な決済状態を使用する必要があります。値が推定値、最終値、調整値、請求書のいずれであるかを示す必要があります。請求書の調整が完了したら、サポートが顧客に表示される請求を内部調整プロセスに接続できるようにする参照を公開します。

AI アクセスを再販する製品の場合、下流の顧客レポートが製品表面の一部になります。 AI API リセラー プラットフォーム を実行しているビルダーには、プロバイダの支出総額だけでなく、顧客スコープのキー、ウォレット クレジット、使用状況レポート、制限、マージン ルール、べき等プロビジョニング操作が必要です。

プライバシーを意識した請求レコード

請求レコードは、デフォルトで生のプロンプトを保存しなくても役立つはずです。ほとんどの財務上の質問には、ID、モデル、トークン数、ツールユニット、タイムスタンプ、ステータス、価格バージョン、アトリビューションディメンションなどのメタデータが必要です。プロンプト全体を保存すると、回避可能なプライバシー、保持、コンプライアンスのリスクが生じる可能性があります。

正当なサポートや悪用のケースでは、コンテンツのキャプチャを制限することで解決できる場合がありますが、それは、保持の制御、編集、アクセス ロギング、顧客の期待を考慮した個別のポリシー決定である必要があります。請求台帳は、より厳格なプライバシー モードで動作できるように、メタデータを優先する必要があります。

構築か購入かの決定

プロバイダー ネイティブの課金が最も簡単な開始点です。これは、ユーザーが 1 人で、プロバイダーが 1 つで、再販がなく、内部チャージバックがなく、プロバイダーのクォータを超えるリクエスト時間制限が必要ない場合に機能します。顧客ごとのアトリビューション、キーレベルの予算、ワークフロー レポート、統合された残高、またはモデル プロバイダーの抽象化が必要になると、この問題は解決されません。

ゲートウェイ レベルの課金により、プロバイダー間で統合された制御が可能になりますが、運用上の責任が生じます。価格カタログを維持し、プロバイダーの使用を正規化し、プロバイダー固有のエッジケースを処理し、請求書を調整し、紛争をサポートする必要があります。 AI の使用がバックオフィスの経費ではなく製品やサービスの一部となる場合、この作業は価値があります。

前払い請求によりダウンサイド リスクが制限され、強制的な強制が簡単になりますが、予約、支払い失敗の動作、残高の保留、および明確な非同期ジョブの処理が必要になります。信頼できる顧客にとって後払い請求はよりスムーズですが、信用リスクが増大し、リアルタイム監視がより重要になります。

Model Gate は、ビルダーが統合請求、API-キー管理、使用状況分析、チーム管理、Telegram 運用ワークフロー、およびパートナー API 自動化を備えたモデル間で OpenAI 互換のアクセスを必要とする場合に関連します。より広範なアーキテクチャ原則は、どのゲートウェイまたはプロバイダ スタックにも適用されます。つまり、台帳を独立性、明示的、調整可能に保つというものです。

よくある実装の間違い

  • 分析を請求台帳として扱い、後でグラフが請求書、払い戻し、紛争、または調整をサポートしていないことが判明します。
  • キャッシュされたトークンが欠落しており、ホストされている入力トークンと出力トークンのみをカウントするツール、コード実行、コンテナ、ストレージ、マルチモーダル入力、非同期行、バッチ割引。
  • 決済時に使用される解決されたモデルと価格カタログのバージョンを記録できません。
  • 多くのテナント間で共有 API キーを使用すると、アトリビューションが破壊され、支出制限が無効になります。
  • ディスパッチ前ではなく、プロバイダの実行後に予算を確認する。予約。
  • クライアントが切断されたり、プロバイダーが応答中に失敗した場合でも、ストリーミングは常に最終使用量を返すと仮定します。
  • バッチ ジョブはジョブ レベルでのみ解決され、再試行および失敗したアイテムの行レベルの属性は失われます。
  • 資格情報ソースと請求を記録せずに、BYOK、ゲートウェイ資金によるトラフィック、およびリセラー資金によるトラフィックを混合します。パス。
  • 調整レコードを追加する代わりに、最終請求を上書きします。
  • 残高、クレジット、価格、または請求書の合計に浮動小数点演算を使用します。
  • 冪等キーを使用せずに変更するクレジット、キー、Webhook、または制限操作を再試行します。
  • テナント スコープの権限なしで顧客使用状況レポートを公開します。

実用的な開始アーキテクチャ

実用的な最初のバージョンは小さくても構いませんが、適切な境界線を持つ必要があります。 API ゲートウェイ、またはアカウント、キー、モデル エイリアス、およびワークフローを識別するリクエスト ミドルウェアから始めます。バージョン付きの価格表を追加します。生のプロバイダー応答の使用状況イベント テーブルと、決済された金額イベントの台帳テーブルを作成します。バランス、モデルへのアクセス、ツールへのアクセス、主要な予算に関するプリフライト チェックを追加します。次に、レポートを信頼できる情報源として扱うのではなく、台帳からレポートを作成します。

ワークロードのエージェント性が高まるにつれて、エージェント実行 ID、ツール イベント レコード、ストリーミング ステート マシン、非同期ジョブ決済、予約保留、調整レコード、プロバイダーのコスト API または請求書からの調整インポートを追加します。パートナーまたはリセラーのユースケースの場合は、ダウンストリームの顧客オブジェクト、顧客スコープのキー、ウォレット クレジット、冪等のトップアップ、および顧客に表示される使用状況のエクスポートを追加します。

重要な設計原則は、実行時に詳細を保持することです。ダッシュボードと請求書については、後からいつでも集計できます。元のリクエスト データが破棄された後は、テナント、認証情報、モデル、ツール、キャッシュ、または価格バージョンのコンテキストを確実に再構築することはできません。

結論

AI 自動請求インフラストラクチャは、エージェントのアクティビティを説明可能な財務記録に変えるものです。実行時実行と財務の間に位置し、詳細が失われる前に使用状況を把握し、お金が費やされる前に支出ポリシーを適用し、顧客、サポート、オペレーターが信頼できるレポートを作成します。

永続的なパターンは、見積、予約、実行、決済、調整です。トークン、キャッシュされたコンテキスト、ツール、非同期作業、再試行、エージェントの実行を個別に測定します。帰属の境界を維持します。バージョンの価格。認証情報モードを請求フィールドとして扱います。追加専用台帳からダッシュボードを構築します。その逆はできません。

単純な実験の場合は、プロバイダ ダッシュボードで十分な場合があります。実際の自動化、顧客対応製品、再販業者サービス、有意義な支出を伴う内部ツールの場合、適切な使用状況台帳と支出管理レイヤーが、財務上の後付けではなく、中核となるインフラストラクチャになります。