ホーム / チュートリアル / Claude Code Analytics API で利用状況を取得する

Claude Code Analytics API で利用状況を取得する

Claude Code 運用管理 8分で読めます

チームで Claude Code を使っているが、どれだけ使われていて、どれだけ効いているのかを数字で説明できない。コンソールの画面では足りないが、OpenTelemetry の収集基盤を立てるほどでもない。その中間を埋めるのが Claude Code Analytics Admin API です。この記事では公式ドキュメントの内容を日本語で整理します。

概要

Claude Code Analytics Admin API は、組織の Claude Code 利用者について日次で集計した利用指標をプログラムから取得するための API です。エンドポイントは /v1/organizations/usage_report/claude_code の1本です。

公式ドキュメントは、この API の位置づけを「Analytics ダッシュボードより詳しく、OpenTelemetry 連携より簡単」と説明しています。ここが選び方の軸になります。画面で足りないが、メトリクス収集基盤を立てるほどではない、という中間の需要に当たる API です。

公式が挙げている用途は次の5つです。

使えるアカウントと必要な鍵

ここが最初の関門です。順に確認してください。

1つ目。Admin API は個人アカウントでは使えません。 組織を作る必要があり、公式は Console の Settings → Organization で設定するよう案内しています。

2つ目。ワークスペースに紐づいた API キーでは呼べません。 使えるのは次の3種類です。

3つ目。組織の種別によって、そもそも別の API を使います。 Claude Enterprise 組織の claude.ai 利用者による Claude Code の活動は、この API ではなく Claude Enterprise Analytics API が報告します。そちらは Admin API キーではなく Analytics API キーを使います。自分の組織がどちらなのかを先に確かめてください。

4つ目。AWS 上の Claude Platform では、この API は現在利用できません。 その場合は Claude Console の Usage ページで Claude Code の利用状況を確認します。

対象になるデプロイ形態

この API が追うのは Claude API 経由の Claude Code の利用だけです。公式は次の経路が含まれないことを明記しています。

つまり、社内で Bedrock 経由の Claude Code を併用している組織では、この API の数字は全体の一部にしかなりません。数字を経営報告に使う前に、自組織のデプロイ形態を棚卸ししておく必要があります。ここを確認せずに「導入が進んでいない」と読むと誤診になります。

基本概念

公式が挙げている押さえどころは6点です。

リクエストパラメータは3つだけ

パラメータ型必須説明
starting_atstring必須UTC の日付（YYYY-MM-DD 形式）。この1日ぶんの指標だけを返す
limitinteger任意1ページあたりのレコード数（既定 20・最大 1000）
pagestring任意前回のレスポンスの next_page から得た不透明なカーソル

日付は UTC です。 starting_at はその日の UTC 0時を指します。日本時間で「9月12日ぶん」を見たいときは、JST が UTC+9 であるため、UTC の 9月11日15時から9月12日15時までが該当します。この API は期間指定を受け付けないので、JST の1日をきれいに切り出すことはできません。 実務上は「UTC の1日」を単位として割り切るか、連続する2日を取得して自分で足し合わせるかのどちらかになります。時差を意識せずに日次レポートを作ると、毎日9時間ぶんずれた集計を出し続けることになります。

取得できる指標

1レコードは、次の4つの区分を持ちます。

ディメンション（誰の・どこでの活動か）

コア指標（core_metrics）

ツール操作の指標（tool_actions）

edit_tool / multi_edit_tool / write_tool / notebook_edit_tool の4つについて、それぞれ accepted と rejected を返します。利用者が提案を受け入れた数と拒否した数です。

モデル別の内訳（model_breakdown）

費用の単位に注意してください。 amount はドルではなくセントです。公式の応答例では 141 という値が入っており、これは 1.41 米ドルにあたります。ここをドルとして読むと、100倍の費用を報告することになります。

使い方

1日ぶんを取得する

まず最小の呼び出しです。ANTHROPIC_ADMIN_KEY に Admin API キーを入れておきます。

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"

limit を省略すると既定の 20 件になります。

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

連携ツールを作る場合は、公式が User-Agent ヘッダの設定を推奨しています。Anthropic 側が利用パターンを把握するためです。

User-Agent: YourApp/1.0.0 (https://yourapp.com)

ページを送る

レスポンスの has_more が true のとき、next_page の値を次のリクエストの page に渡します。

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"

手順は3段です。

  1. 最初のリクエストを送る（limit は任意）
  2. レスポンスの has_more が true なら、next_page の値を次のリクエストで使う
  3. has_more が false になるまで繰り返す

カーソルは最後のレコードの位置を符号化したもので、新しいデータが届いてもページ送りが安定する設計になっています。公式の表現では、ページネーションのセッションごとに一貫したデータ境界が保たれ、レコードの取りこぼしや重複が起きないようにしてあります。カーソルの中身を自分で組み立てないでください。 不透明な値として扱い、レスポンスから受け取ったものをそのまま返すのが正しい使い方です。

レスポンスの形

{
  "data": [
    {
      "date": "2025-09-08T00:00:00Z",
      "actor": {
        "type": "user_actor",
        "email_address": "developer@company.com"
      },
      "organization_id": "dc9f6c26-b22c-4831-8d01-0446bada88f1",
      "customer_type": "api",
      "terminal_type": "vscode",
      "core_metrics": {
        "num_sessions": 5,
        "lines_of_code": { "added": 1543, "removed": 892 },
        "commits_by_claude_code": 12,
        "pull_requests_by_claude_code": 2
      },
      "tool_actions": {
        "edit_tool": { "accepted": 45, "rejected": 5 },
        "multi_edit_tool": { "accepted": 12, "rejected": 2 },
        "write_tool": { "accepted": 8, "rejected": 1 },
        "notebook_edit_tool": { "accepted": 3, "rejected": 0 }
      },
      "model_breakdown": [
        {
          "model": "claude-opus-5",
          "tokens": {
            "input": 100000,
            "output": 35000,
            "cache_read": 10000,
            "cache_creation": 5000
          },
          "estimated_cost": { "currency": "USD", "amount": 141 }
        }
      ]
    }
  ],
  "has_more": false,
  "next_page": null
}

ツールの受け入れ率を計算する

公式が示している式はこれだけです。

受け入れ率 = accepted / (accepted + rejected)

ツールの種別ごとに計算します。上の応答例の edit_tool は accepted が 45、rejected が 5 なので、受け入れ率は 90% です。

この数字の読み方には注意が必要です。 受け入れ率が高いことは「提案の質が高い」とも「利用者が内容を確認せずに通している」とも読めます。逆に低い場合は「提案が的外れ」とも「利用者が慎重にレビューしている」とも読めます。1つの数字から品質を結論しないでください。 コード行数やコミット数と併せて、変化の方向を追うほうが実用的です。

鮮度と制限を押さえる

公式の FAQ が明示している点を整理します。

「1時間より古いデータだけが含まれる」という仕様は、当日ぶんを取得しても直近の活動が入っていないことを意味します。日次バッチを組むなら、当日を取りにいくのではなく前日ぶんを取得するのが安全です。

OpenTelemetry 連携との使い分け

やりたいこと向いている手段
日次の集計値を取り出して社内ダッシュボードに載せるこの Analytics API
リアルタイムの監視やアラートOpenTelemetry 連携
画面で概況を見るだけClaude Console の Analytics ダッシュボード
Claude Code 以外も含む API 全体の利用量と費用Usage and Cost API

まとめ

要点を5つに絞ります。

  1. エンドポイントは /v1/organizations/usage_report/claude_code の1本で、パラメータは starting_at（必須）・limit・page の3つだけです
  2. 1リクエストで返るのは1日ぶんで、日付は UTC です。JST の1日を切り出す機能はありません
  3. 鍵は Admin API キー（またはワークスペースにスコープされていないキー、org:admin の OAuth トークン）で、ワークスペースキーでは呼べません。個人アカウントでは使えません
  4. estimated_cost.amount は米セントです。ドルとして読むと100倍になります
  5. 対象は Claude API 経由の利用だけです。Bedrock / Microsoft Foundry / Google Cloud / Claude Platform on AWS 経由の利用は含まれません

導入状況を数字で説明したい場面で、OpenTelemetry の基盤を用意せずに始められるのがこの API の利点です。一方で、UTC 基準・1日単位・セント表記・対象デプロイの限定という4点は、そのまま集計に持ち込むと誤った数字になります。最初にこの4点を自分の環境に当てて確認してから、レポートの形を決めてください。

本記事は Anthropic 公式ドキュメント「Claude Code Analytics API」に基づく非公式の日本語解説です（確認日 2026-09-12）。仕様は更新される場合があるため、実装前に公式ドキュメントとAPI リファレンスをご確認ください。

関連チュートリアル / 次に読む

Usage and Cost API で利用量と費用を取得する OpenTelemetry で Claude Code を監視する Admin API で組織を管理する コストを効果的に管理する Amazon Bedrock 上で Claude Code を動かす
← チュートリアル一覧へ戻る カテゴリで探す