AUDR by Chargebee
Chargebee · 生産性向上 · ビジネス
AUDR by Chargebeeは、誰がAIエージェントの実行を始め、モデル呼び出しやツール呼び出しがいくらかかったかを記録するオープンJSON標準だ。同じレコードから課金と予算管理を回せる。
AUDR by Chargebee について
What Is AUDR by Chargebee
AUDRはAgent Usage Detail Recordの略で、仕様であってダッシュボードではない。計測対象の操作ごとにJSONオブジェクトを1件作り、エージェントの実行基盤、ルーター、モデル提供者、課金システムのどれでも書けて読めるスキーマを定める。Chargebeeが起草し、Apache 2.0で公開している。
埋めるのは帰属の穴だ。アプリはどの顧客が実行を起こしたか知っている。ルーターはトークン数を知っている。ツール層はサンドボックスが4分間開いていたことを知っている。どの層も単独では観測できるのに、先週火曜にAcmeのサポートエージェントが38セントかかったと答える層はない。多くのチームが最初にぶつかるのはエージェントコスト追跡の問題で、月次のモデル請求書からはどの機能が予算を食っているか見えない。
設計の元ネタは通信業界にある。事業者は通話明細レコード（Call Detail Record）を採用し、どの交換機が処理したかに関係なく通話を共通形式で記述できるようにした。AUDRは同じ考えをエージェント実行に当てる。共有の実行ID、項目ごとに1人の正規ライター、そしてシンクが推測なしに適用できるマージ規則だ。
範囲の線引きも重要だ。AUDRが表すのは利用量であり、請求書ではない。トークンを請求額に変えるレーティングは仕様の外にあり、シンクは検証、重複排除、保存だけを担う。
Getting Started
- 自分のスタックに合うコアパッケージを入れる。
pip install audrかnpm install @openaudr/audrを選び、シンクはローカルJSONLファイルかChargebeeを用意する。 - そのシンクとemitterブロックでクライアントを作る。コンポーネント名、アプリ名、バージョンを書く。
- すでに使っている実行基盤のアダプターを登録する。LiteLLM、Vercel AI SDK、Mastra、NeMo Relayなどが対象だ。自分で
client.record()を呼んでもよい。 - リクエストごとに帰属情報を渡す。通常はアカウントIDかサブスクリプションIDに環境名を添える。あとはJSONL出力か、課金システム側で結合されたレコードを読む。
AIツール情報
AUDR by Chargebeeの料金、対応プラットフォーム、性能を簡単に確認できます。
こんな人におすすめ
このツールが最も力を発揮するユーザー、タスク、シーン。
ユーザー
- AIプロダクトのエンジニア：既存スタックにSDK呼び出しかアダプターを1つ足せるなら、顧客ごとの実行コストが手に入る。
- AI企業の財務チーム：支出とアカウントを紐づけられる。ただしAIエージェント課金には、トークンを請求書に変えるレーティング層が別に要る。
- 従量課金を運用するプラットフォームエンジニア：ChargebeeやLagoがすでに流れの終端にあるなら相性がいい。
- エージェント製品の価格を決める創業者：出てくるのは実行あたりのコスト基準で、目標粗利の答えではない。
タスク
- モデル支出を顧客に割り当てる：ルーターのトークン数と実行基盤のアカウントIDを突き合わせる。平均値と照合する作業は不要になる。
- ツール費用を監査する：サンドボックスの分数、検索呼び出し、有料APIリクエストを拾う。これらはモデルルーターまで届かない。
- 従量課金の請求書を用意する：結合済みレコードをレーティングに渡し、実行単位、成果単位、クレジット単位で請求する。
- 粗利の問題を調べる：ある機能の提供コストと、料金ページの価格を並べる。
シーン
- 1社の利用量が他を圧倒するサポートエージェント：実行単位のレコードがあれば、その大口を平均から切り離せる。
- 複数モデルとフォールバックを組む構成：ルーターと提供者のレコードは同じspanで結合されるため、再試行が合計から消えない。
- 固定サブスクから従量課金へ移る実証実験：価格を公表する前に、実行あたりのコスト履歴を数か月分そろえる必要がある。
主な機能
各ホップを越える共有実行ID
実行基盤がrun_idとspan_idを操作ごとに発行し、リクエストのメタデータに載せて渡す。ルーター、提供者、ツール層は同じ組を返す。シンクは2つの値が一致するレコードを結合するので、3つのコンポーネントが記述した1回のモデル呼び出しは3つの断片ではなく1行になる。
項目ごとに1人のライター
AUDRは所有権を分ける。共通ブロブを各コンポーネントに上書きさせない。帰属は実行基盤が持つ。顧客、環境、実行者だ。利用量はルーターが持つ。トークンと提供者だ。競合は拒否され、最後に書いた者の勝ちにはならない。
追記だけで済む訂正
レコードは不変だ。誤った数値を直すには同じemitterコンポーネントから新しいレコードを出し、シンクがrecord_idで古い方を置き換える。元の値は消えず、監査の履歴が残る。
価格ではなく生のカウンタ
レコードが持つのは入力トークン、出力トークン、ツール呼び出し、計算秒数といったカウンタだ。コスト項目は任意の参考情報にすぎない。この分離があるから、提供者が料金を変えたときに過去を再計算でき、測った値を書き換えずに済む。
主要な実行基盤向けアダプター
LiteLLM、NVIDIA NeMo Relay、Merge Gateway、Vercel AI SDK、Mastra、OpenRouter向けのアダプターがそろう。1つ登録すれば、モデル呼び出しもツール呼び出しも所属アカウント付きでレコードを出す。
課金システムにつながるシンク
ChargebeeとLagoには参照実装のシンクがあり、ファイルシンクは初期検証に向く。契約は短い。検証、重複排除、結合、保存だ。同じレコードをデータウェアハウスやキューへ流すのも、週末で終わる作業になる。
メリットとデメリット
メリット
- Apache 2.0でスキーマと適合性テスト用のフィクスチャが公開されており、本格導入の前に実装を試せる。
- ベンダー非依存の設計だ。OpenRouter経由でもLiteLLM経由でも自前ゲートウェイでも、同じレコードが使える。
- 表面積が小さい。レコードは素のJSONで、マージ規則3つは1ページに収まる。
- PythonとTypeScriptのSDKにファイルシンクを組み合わせれば、1人で半日あれば使えるデータになる。
- 開始にホスト型アカウントも最低利用額も営業との商談も要らない。
デメリット
- 仕様はまだ若い。バージョン1.1.0は2026年10月に出たばかりで、項目の範囲はこれからも動く。
- アダプターとシンクの一覧は短い。他のゲートウェイを使うチームは自前で統合を書くことになる。
- レーティングは標準の外にある。利用量を請求書にするには、課金ロジックを別に用意する必要がある。
- 保存、検索、アラートは付いてこない。レポートは自前で持つことになる。
よくある質問
Agent Usage Detail Recordだ。エージェントシステム内の計測対象の操作1件について、誰が始めて何を消費したかを表すJSON仕様である。
関連コンテンツ
AUDR by Chargebeeに関連するツール、スキル、記事を探す。
AUDR by Chargebeeの代替ツール
Base Code
Base44 (Wix) · コーディング · 生産性向上Base CodeはBase44の共有クラウド開発環境だ。既存のGitHubリポジトリに対する変更をチャットで伝え、プレビューで確認し、プルリクエストとして返せる。
Knocket
Knocket (Tencent RTC team) · 生産性向上 · ビジネス · チャットボットKnocketは無料のライブチャット兼コンタクトページだ。訪問者はウェブサイト、アプリ、共有リンクから書き込み、こちらはTelegramか一つの受信トレイから返信する。
FloorGen
Vinit Kumar (FloorGen) · 生産性向上 · 中国のAIFloorGenはブラウザで動く間取り作成ツールだ。文章かスケッチから編集できる2D間取り図と3Dウォークスルーを作る。PDF、DXF、動画に書き出せ、アカウントなしでも描き始められる。