Claude Code Analytics APIの使い方とツール受入率の計算

Claude Code Analytics APIで何がわかるか

Claude Code Analytics APIは、組織のClaude Code利用をユーザーごと・日ごとの集計値で返すAdmin APIのエンドポイントです。/v1/organizations/usage_report/claude_codeの1本で、セッション数・コード行の増減・コミット・PR・ツールごとの受入/拒否件数・モデル別のトークンとコストまで取れます。

OpenTelemetry連携ほど基盤を用意せずに済み、Console内の基本的なAnalyticsダッシュボードより細かい粒度でデータを扱えるのが特徴です。使い道は、経営層向けのダッシュボード、CopilotやCursorなど他のAIコーディングツールとの比較、チーム別のコスト配分、導入のROI説明などです。

使い始める順に進みます。自分の組織で使えるかの確認、最初のリクエスト、返ってくる項目、受入率の計算、全ユーザー分の取得、OpenTelemetryとの選び分けの順です。

Claude Analytics APIにはどのAPIキーが要るか

「Claude Analytics API」と呼ばれるAPIは2種類あり、鍵の種類も作る場所も違います。この記事で扱うのは、表の1行目のClaude Code Analytics APIです。

2つの鍵に互換性はありません。Admin APIキーではEnterprise側を呼べず、Analytics APIキーではAdmin API側を呼べません。Claude Enterpriseの組織は、Claude Enterprise Analytics APIで利用状況を取ります。

Admin APIキー以外の資格情報でも呼べます。詳しくは次の節にあります。

自分の組織で使えるかを先に確かめる

利用は無料ですが、条件があります。個人アカウントでは使えず、組織を作ったうえで、次のいずれかの資格情報が要ります。

• Admin APIキー
• org:adminスコープ付きのOAuthトークン
• ワークスペースに紐づかない個人・サービスアカウントキー

ワークスペースAPIキーでは呼び出せません。Admin APIキーの取得手順はClaude Admin APIキーの取得方法にあります。

次に、対象外の利用形態を押さえます。このAPIが数えるのは、Claude API経由のClaude Code利用だけです。Amazon Bedrock・Microsoft Foundry・Google Cloud経由の利用は含まれません。Claude Platform on AWSも同じく対象外で、ConsoleのUsageページで確認します。

つまり、社内のClaude CodeをBedrock経由で配っている組織は、このAPIの数字が実際の利用の一部でしかないか、空になります。ダッシュボードを作る前に、自社の利用がどの経路かを確認しておくと、後から「数字が合わない」と悩まずに済みます。

Claude Enterprise組織(claude.ai)のユーザーによるClaude Codeの活動は、Analytics APIキーを使う別のAPIが報告します。Enterprise側のAPIの使い方はClaude Analytics APIはどれを使うかにあります。

最初のリクエストを送る

指定した1日分のデータを取る最小のリクエストは次のとおりです。

curl "https://api.anthropic.com/v1/organizations/usage_report/claude_code?\
starting_at=2025-09-08&\
limit=20" \
  -H "anthropic-version: 2023-06-01" \
  -H "x-api-key: $ANTHROPIC_ADMIN_KEY"

パラメータは3つだけです。starting_atはYYYY-MM-DD形式のUTC日付で、その1日分だけを返す必須項目です。limitは1ページの件数で、既定は20、最大は1,000です。pageは前回のレスポンスのnext_pageから得るカーソルです。

日付はすべてUTC基準で、starting_atはその日のUTC午前0時を表します。日本時間の朝9時に日付が切り替わる点は、日次レポートの締め時刻を決めるときに効いてきます。

自作のインテグレーションなら、User-Agentヘッダーにアプリ名とバージョンを入れておきます。Anthropic側が利用パターンを把握しやすくなるための推奨です。

1レコードに入っている項目

レスポンスのdata配列の1件は、特定の1ユーザーの、特定の1日分の活動です。中身は、誰の何の記録かを示すディメンションと、数値のメトリクスに分かれます。

ディメンションは次の5つです。

• date: RFC 3339形式のUTC日時
• actor: 操作した主体。email_addressを持つuser_actorか、api_key_nameを持つapi_actor
• organization_id: 組織のUUID
• customer_type: api(従量課金)かsubscription(Pro/Teamプラン)
• terminal_type: 実行環境。vscode・iTerm.app・tmuxなど

actorが2種類あるのは認証方法の違いです。OAuthで認証したユーザーはメールアドレスで、APIキーで認証したユーザーはキー名で識別されます。ユーザー単位で集計するときは、この2種類が混在する前提で、どちらのフィールドを使うかをコードで吸収します。

コアメトリクスはcore_metricsの下にあります。num_sessions、lines_of_code.addedとlines_of_code.removed、commits_by_claude_code、pull_requests_by_claude_codeです。コミットとPRは、Claude Codeのコミット機能・PR機能を経由して作られた件数として定義されています。

ツールアクションはtool_actionsの下で、edit_tool・multi_edit_tool・write_tool・notebook_edit_toolのそれぞれにacceptedとrejectedがあります。受入率の計算はこの8つの数字だけで済みます。

モデル別内訳はmodel_breakdownの配列で、使ったモデルごとにmodel、tokens(input・output・cache_read・cache_creation)、estimated_costが入ります。

トークンはinputとoutputのほかに、cache_readとcache_creationが別々に返ります。inputだけを合計すると、キャッシュ経由の分が抜け落ちます。トークンの規模を見るときは、4項目を別々に扱う前提で集計を組みます。コストはestimated_costが用意されているので、まずはこの値を使う手があります。

データの鮮度は最大1時間の遅れがあります。ページネーションの一貫性を保つため、直近1時間より古いデータだけがレスポンスに含まれます。今日の朝に日付を指定しても、まだ集計が終わっていない部分は返りません。

ツール受入率を計算する

ツールごとの受入率は、次の式で求めます。

受入率 = accepted / (accepted + rejected)

APIドキュメントのサンプルレスポンスに載っている1レコードの数字を、この式に通してみます。

NotebookEditの100%は、母数が3件しかありません。4つを並べると差があるように見えますが、これだけの件数では差の意味を語れません。4ツールを合算すれば、受入68件・拒否8件で68 / 76、約89.5%になります。

受入率は、ユーザーごと・ツールごとに算出して横並びで比べます。

週次・月次では先に合算してから割る

starting_atが1日単位なので、週次・月次のレポートは複数日分のリクエストを重ねて自前で集計します。ここで順序を間違えると、数字が偏ります。

上の2日は説明用に作った数字ですが、差は現実の集計でも出ます。1件だけの日が100%になれば、平均値は簡単に実態から離れます。

実装の流れは3段です。期間内の各日についてstarting_atを変えて全ページを取得し、ユーザーとツールの組み合わせごとにacceptedとrejectedを合算し、合算後に1回だけ割り算します。

jqで書くと次のようになります。日次のレスポンスをファイルに保存してあるとして、ユーザー×ツールの受入率を出す例です。

jq -s '[.[].data[] | .actor as $u | .tool_actions | to_entries[]
    | {user: ($u.email_address // $u.api_key_name),
       tool: .key, a: .value.accepted, r: .value.rejected}]
  | group_by([.user, .tool])
  | map({user: .[0].user, tool: .[0].tool,
         accepted: (map(.a) | add), rejected: (map(.r) | add)}
    | . + {rate: (if (.accepted + .rejected) == 0 then null
        else ((.accepted / (.accepted + .rejected) * 1000 | round) / 10)
        end)})' day1.json day2.json

email_addressが無ければapi_key_nameを使い、分母が0ならrateをnullにしています。前述の2日分を渡すと、editツールはaccepted: 46, rejected: 5, rate: 90.2と出ます。この式はローカルでダミーのJSONを使って動作を確かめています。

数字を読み間違えやすい4つの場面

集計の順序以外にも、実際に数字を見ていくと引っかかりやすい点があります。

サンプル数が少ないと受入率は暴れます。1日のaccepted + rejectedが数件のユーザーは、拒否が1件増えるだけで受入率が大きく動きます。日次ではなく、週単位・チーム単位で合算してから比べると、ブレに引きずられません。

分母が0のレコードは対象外として扱います。その日そのツールを使わなかったユーザーは、acceptedもrejectedも0です。ここで受入率を0%と出すと、拒否し続けているように見えてしまいます。上のjq例のように、nullにして集計から外すのが実態に合います。

コストの単位はセントです。estimated_cost.amountは米ドルのセント単位で、サンプルの113は1.13ドルです。ドルとして読むと100倍の過大評価になります。通貨コードは現状常にUSDです。

「受け入れた」の定義は、ドキュメントに書かれていません。説明は「ユーザーが受け入れた/拒否したツール提案の数」とあるだけです。許可ルールで自動承認された編集がacceptedに入るのかは、このページから読み取れません。受入率を「人が毎回確認した割合」と解釈するのは、根拠がない読み方です。

最後の点は、指標の意味づけに直結します。受入率が高いことを、提案の質の高さの証拠とみるのか、確認が甘いことの表れとみるのか。件数だけでは決められません。ツールごとの水準の違いや、チーム間の差を見るための相対的な物差しとして使い、絶対値で良し悪しを判断しないほうが安全です。

全ユーザー分を取り切る

ユーザーが多い組織では、1回で全件は返りません。ページネーションはカーソル方式です。

2回目のリクエストは、次の形になります。starting_atは最初のリクエストと同じ値を渡します。

curl "https://api.anthropic.com/v1/organizations/usage_report/claude_code?\
starting_at=2025-09-08&\
page=page_MjAyNS0wNS0xNFQwMDowMDowMFo=" \
  -H "anthropic-version: 2023-06-01" \
  -H "x-api-key: $ANTHROPIC_ADMIN_KEY"

カーソルは最後に取得したレコードの位置をエンコードしたものです。新しいデータが届いている間も、ページ間の取りこぼしや重複を防ぎ、ひとつのページネーションの間はデータの境界が一貫します。starting_atは1日分なので、複数日を取るときは日ごとに1回目のリクエストからやり直します。

OpenTelemetry連携との選び分け

Claude Codeの利用を取る経路は、このAPIだけではありません。Claude CodeにはOpenTelemetry連携があり、選び分けの軸は「リアルタイム性」と「記録の粒度」です。

粒度の違いは、受入率の意味づけにも響きます。OpenTelemetryのtool_decisionイベントには、判断のdecision(acceptかreject)に加えて、sourceという属性があります。設定やルールによる自動判断はconfig、フックによる判断はhookです。ユーザーがプロンプトで承認したものはuser_temporaryやuser_permanent、拒否はuser_reject、答えずに閉じたものはuser_abortと分かれます。対話型CLIでは、user_*はプロンプトに答えたその1回だけを指し、一度許可した後の同種の呼び出しはconfigとして数えられます。

人が判断した分と自動で通った分を切り分けて見たいなら、この属性が使えるOpenTelemetry側になります。Analytics APIのツール指標は受入と拒否の件数だけで、判断の出どころは返りません。OpenTelemetryには、コード編集ツールの許可判断を数えるclaude_code.code_edit_tool.decisionというメトリクスもあります。OpenTelemetry側では、同じ許可判断をsourceごとに出どころ別に数えられます。両者は排他ではないので、月次の報告はAPI、原因調査だけOpenTelemetryを使う併用もできます。

Analytics APIでリアルタイム指標が取れないのは仕様です。対象は日次の集計だけで、履歴には削除期間が定められておらず、あとからAPI経由で参照できます。

まとめ

日次の件数を合算してから割れば、社内報告に使える受入率はAPIだけで出せます。人の判断と自動承認を分けて見る必要が出たときが、OpenTelemetryを足す目安です。