Claude APIを社内の複数のシステムや、顧客ごとのサービスに組み込むと、月末に「どの部署、どの顧客、どのAPIキーがいくら使ったのか」を出す必要が出てきます。管理画面の数字を手で書き写す運用では、按分の根拠を残しにくく、使いすぎにも気づくのが遅れます。
Anthropicは2026年10月29日、こうした集計のための「Usage and Cost Analytics API」をベータで公開しました。同時に、これまでの「Usage and Cost API」と、Claude EnterpriseのAnalytics APIの利用量・費用のレポート（usage_report・cost_report・user_usage_report・user_cost_report）はレガシーになりました。どれも引き続き利用できます。この記事では、新しいAPIで何が集計できるか、既存の集計の仕組みを移す前に確かめる点を、公式のドキュメントから整理します。
新しいAPIで集計できること
エンドポイントは2つです。
GET /v1/organizations/analytics/usage: トークン数とリクエスト数GET /v1/organizations/analytics/cost: 米ドルの費用
ベータの間は、すべてのリクエストに anthropic-beta: analytics-usage-cost-2026-08-24 と anthropic-version のヘッダーが必要です。SDKと ant CLIは両方を自動で付け、残りのページも読み進めるときに取得します。
ドキュメントは用途として、ワークスペース・APIキー・モデル・サービスの階層・リクエストをしたIDごとの費用と使用量の内訳、使用量の多い順の並べ替え、日・時間・分ごとの時系列を挙げています。同じエンドポイントとパラメーターで、Claude ConsoleとClaude Enterpriseの両方の組織に使えます。ただし、api_key_id のようにClaude Consoleの組織だけの軸と、slack_channel_id のようにClaude Enterpriseの組織だけの軸があります。自社の組織に当てはまらない軸は、基本的にすべての行で null になり、その絞り込みには何も一致しません。
集計の軸は group_by[] で最大5つまで指定できます（費用のエンドポイントだけにある cost_type と token_type は、この数に含まれません）。ほとんどの軸には対応する絞り込み（例: models[]=claude-opus-5-5）があり、1つの絞り込みに最大100の値を渡せます。同じ絞り込みの複数の値はOR、異なる絞り込みはANDでつながります。
「誰が使ったか」は actor という軸で表されます。利用者、サービスアカウント、AWSやGoogle Cloudの連携した ID、そのどれでもない場合はAPIキーそのものです。個人のキーとサービスアカウントのキーは結び付いた人やアカウントとして記録されますが、古いワークスペースのキーは誰にも結び付かないため、キー自体が actor になります。どの ID にも結び付かない利用は actor: null です。
予算の警告に使う前に 反映の遅れと、月末の確定
組み込む前に最も確かめておきたいのが、データの反映の速さです。
- 新しいAPIのデータは、通常は利用から4時間以内、遅いと24時間かかって反映されます
- 従来のUsage and Cost APIは、通常5分以内に反映されるとされていました
- 値は、遅れて届く記録や照合によって、暦月の終わりから約7日後まで変わることがあります。ドキュメントの例では、10月1日の値は11月7日ごろまで変わりえます
応答には毎回 data_refreshed_at が入り、この時刻より後の利用は欠けているか一部だけです。ドキュメントは、繰り返し呼んでも同じ結果を得たい場合は、すでに見た data_refreshed_at 以前を ending_at に指定し、確定した合計が必要なら終わってから7日以上たった月だけを集計するよう勧めています。
ここからは編集部の整理です。従来のAPIを数分おきに呼んで「使いすぎたら止める」仕組みを作っている場合、新しいAPIに置き換えると、検知が最大で1日遅れる可能性があります。予算の上限に近づいたことを知る用途と、月次の請求を部署や顧客に按分する用途は、分けて設計するのが安全です。前者は新しいAPIだけに頼らず、自社のシステム側で送ったリクエストの記録を数える方法も検討します。後者は月末から7日以上たってから確定させます。
金額の単位で間違えない
費用のエンドポイントの cost には次の値が入ります。
amount: 割引の後、クレジットを適用する前の費用list_amount: 定価での費用currency: 常に"USD"
金額はセント単位の小数6桁の文字列で、ドキュメントの例では "41280.000000" が412.80ドルです。セント単位である点は従来のコストレポートも同じで、変わるのは小数の桁です。移行の表では、"123.45" のような値が "123.450000" の形になり、list_amount が加わるとされています。どちらも、文字列をそのまま数値にしてドルとして扱うと100倍の金額になるので、ドルにするときは100で割ります。
請求書の金額と突き合わせるときは、クレジットを適用する前の値である点に注意します。Priority Tierのコミットメントの範囲で処理したリクエストは、トークンの費用が0として集計され、コミットメントの料金はこのデータに入りません。月ごとのAPIクレジットの扱いは、Claude TeamのAPIクレジットの記事で整理しました。
従来のAPIから移すときに変わる点
ドキュメントの移行の節から、既存の集計のコードに影響しやすい違いを抜き出します。
| 項目 | 従来のUsage and Cost API | 新しいAPI |
|---|---|---|
| 時間の区切り | bucket_width、既定は 1d | time_bucket_width、既定なし。指定しないと期間全体の合計になる。指定するときは ending_at が必須 |
| ページの件数 | limit は時間の区切りの数 | limit は行の数（1〜1,000、既定20） |
| 期間 | 任意の期間 | 2026年1月1日以降かつ直近365日、1回31日まで。1m の区切りは24時間まで |
| 存在しないIDの指定 | エラー | 何にも一致しない（モデル名の綴り間違いも同じ） |
| 既定のワークスペース | workspace_id: null | 実際の wrkspc_ のID |
存在しない ID がエラーにならず空の結果になる点は、気づきにくい変更です。綴りを間違えた models[] を渡すと、利用が0のように見えます。集計の結果が急に0になったら、まず絞り込みの値を確かめます。
従来の日次レポートと同じ形を作るには、time_bucket_width=1d と同じ group_by[] を指定し、limit=1000 でページを読み進め、starting_at ごとにまとめて、利用のない日を0で埋めるよう案内されています。新しいAPIは利用のない組み合わせの行を返さないためです。
ここまでの表は、Claude Consoleの組織が使うUsage and Cost APIからの移行です。Claude Enterpriseのレポート（usage_report など）から移す場合は、ドキュメントに別の節があります。鍵、期間の制限、金額の項目は引き継がれ、時間の区切りごとの上位100グループという制限がなくなる一方、ending_at の扱いや user_ids[] の名前などが変わります。
鍵の扱い
Claude Consoleの組織はAdmin APIのキー（または org:admin の範囲を持つOAuthのトークンなど、ほかのAdmin APIの認証情報）を、Claude Enterpriseの組織は、Analytics APIを有効にした後にプライマリオーナーがclaude.aiで作る read:analytics の範囲のキーを使います。
ドキュメントは、Admin APIのキーで呼ぶ場合、集計するサービス専用のキーを用意し、シークレットの管理の仕組みに保存して定期的に入れ替えるよう求めています。可能ならWorkload Identity Federationで短い有効期限のトークンを使い、長く使えるキーを持たないことを勧めています。
なお、Claude Platform on AWSとClaude Models on Google Cloud（Anthropic managed）でも両方のエンドポイントが使え、それぞれのクラウドの認証と権限で呼び出します。AWSでは、呼び出したリージョンのワークスペースだけが対象で、user_profile_id やClaude Managed Agentsの軸はすべての行で null になります。従来のAPIは、AWSでは使えず、Google Cloudでは利用量のエンドポイントだけが使えます。
移す前に決めておくこと
新しいAPIはベータです。ドキュメントは新しい連携には新しいAPIを使うよう案内していますが、従来のAPIは「レガシー」として引き続きサポートされ、2026年11月6日の時点で終了の日付は示されていません。すでに動いている集計は、急いで切り替えるより、次の順で進めるのが編集部のおすすめです。
- 今の集計が「数分以内の反映」に頼っているかを確かめる。頼っているなら、その部分は別の方法を用意する
- 金額の変換のコードが、小数6桁の文字列を読めることと、セントからドルへ直していることを確かめる。クレジット適用前の値である点も、請求書との突き合わせに反映する
- 同じ月について、従来のAPIと新しいAPIの結果を並べて比べ、差が出たら上の表の違い（既定のワークスペース、存在しないID、利用のない日）で説明できるか確かめる
APIキーを顧客ごとに分けて運用している場合は、ユーザープロファイルの記事もあわせて確認してください。
確認した範囲
2026年10月31日と11月6日に、Claude Platformのリリースノート（2026年10月29日の項と、その後の11月5日までの項）と、ドキュメント「Usage and Cost Analytics API」「Usage and Cost API」をplatform.claude.comで直接開いて確認しました（資料調査）。Admin APIのキーを使った実際の呼び出しは行っておらず、応答の内容、反映の実際の速さ、従来のAPIとの数値の差は確かめていません。予算の監視と按分を分ける考え方と、移行の進め方は編集部の提案です。
AIを組み込んだシステムの利用量の集計や、費用を部署・顧客に按分する仕組みづくりは、開発・AI・自動化のご相談からお問い合わせください。
