Enterprise Analytics APIでコネクタ・スキル・プラグインの利用を取る
Claude Enterprise Analytics APIのコネクタ・プラグイン・スキル・アーティファクト各エンドポイントを、group_byの効き方、コネクタ名の正規化、third-partyバケットまで整理する。
Claude Enterprise Analytics APIには、コネクタ・プラグイン・スキル・アーティファクトの利用状況を返す専用エンドポイントがあります。どれも/v1/organizations/analytics/配下にあり、read:analyticsスコープのAPIキーで呼びます。group_by[]で製品・RBACグループ・ユーザーに分解でき、日付を範囲指定すれば期間ロールアップも取れます。
キーの取得や、Claude Code Analytics APIとのどちらを使うかはClaude Analytics API群の使い分けで扱っています。ここでは各エンドポイントが何を返し、group_byで何が変わり、どの値が集計バケットなのかを順に見ます。
6つのエンドポイントは何を数えるのか
コネクタ・プラグイン・スキル・アーティファクトの利用を見るときに使うのは、次の6本です。ユーザー活動とサマリーは、この4本を横断で見るときの入口になります。
| エンドポイント | 返すもの | 行の単位 | group_byで使える軸 |
|---|---|---|---|
/connectors | 返すものコネクタ別の利用ユーザー数・セッション数・呼び出し数 | 行の単位コネクタ | group_byで使える軸product / rbac_group_id / user_id |
/plugins | 返すものプラグイン別のインストール数・呼び出し数 | 行の単位プラグイン | group_byで使える軸product / rbac_group_id / user_id |
/skills | 返すものスキル別の呼び出し数・有効化数・推計コスト | 行の単位スキル | group_byで使える軸product / rbac_group_id / user_id |
/artifacts | 返すものMIMEタイプ別のアーティファクト作成数 | 行の単位タイプ × 共有状態 | group_byで使える軸product / rbac_group_id / user_id |
/users | 返すものユーザー単位の日次活動 | 行の単位メンバー | group_byで使える軸rbac_group_idのみ |
/summaries | 返すもの組織単位の日次・週次・月次アクティブユーザー数 | 行の単位日 | group_byで使える軸なし(filterでrbac_group_idのみ) |
/connectors・/skills・/usersはEnterpriseプランの組織向けと明記されています。ユーザー数やセッション数の推移を画面で見たいだけなら、Team/Enterpriseの利用状況分析ダッシュボードで足ります。APIが要るのは、自前のBIに流す、RBACグループ単位で定期集計する、といった場面です。
共通の呼び方 — 日付指定とロールアップ
日付の渡し方は2通りあります。date=YYYY-MM-DDは1日分の行を返します。starting_date(含む)とending_date(含まない)を渡すと、期間全体を1行に畳むロールアップモードになります。
dateとstarting_dateは併用できませんending_dateはstarting_dateとだけ使え、省略すると今日になります- 範囲は
starting_dateから最大366日後まで - 日付は2026-01-01以降のみ
- 直近の日付はまだ出ないことがあり、早すぎる日付を指定したときのエラーが最新の取得可能日を教えてくれます
期間ロールアップでは、足し算できる件数は日ごとの値を合算します。ユーザー数のように足すと二重に数える値は、期間全体で数え直されます。セッション数などの重複排除カウントは、HLL(近似カウント)で典型誤差2%未満の近似値になります。行が集約されて数えられないときはnullです。
基本の呼び出しは次の形です。ページングはnext_pageをそのままpageに渡します。
curl -G https://api.anthropic.com/v1/organizations/analytics/connectors \
-H "anthropic-version: 2023-06-01" \
-H "X-Api-Key: $ANTHROPIC_ANALYTICS_KEY" \
--data-urlencode "starting_date=2026-09-01" \
--data-urlencode "ending_date=2026-09-29" \
--data-urlencode "group_by[]=product" \
--data-urlencode "limit=200"limitは1〜1000で、既定は100です。order_byには、そのエンドポイントの並び替え列と、ランキング可能な指標だけを指定できます。指標を指定すると既定は降順で、上位N件の取得に使えます。
group_byとfilterは何を変えるのか
group_by[]は行を分解する軸で、filter[]はdimension:valueの形で対象を絞ります。同じ次元を繰り返すとOR、別の次元を並べるとANDです。どちらも最大100件まで渡せます。未対応の次元を指定すると400になります。
| 軸 | 行に増えるフィールド | 注意 |
|---|---|---|
product | 行に増えるフィールドproduct | 注意chat / claude_code / cowork / office_agent。エンドポイントで取り得る値が違う |
rbac_group_id | 行に増えるフィールドrbac_group_id、rbac_group_name | 注意1人が複数グループに属すと、行が重複計上される |
user_id | 行に増えるフィールドuser_id | 注意user_...形式のID。メールアドレスではない |
productの値はエンドポイントごとに絞られます。/pluginsで出るのはcoworkとclaude_codeだけです。プラグインの帰属情報を持つ利用形態がこの2つに限られるためです。/artifactsは作成元になるchat・claude_code・coworkの3つ、/connectorsと/skillsはoffice_agentを含む4つが取り得ます。
RBACグループ別の行は排他的な分割ではありません。1日のうちにそのグループに所属していたユーザーは、所属していた各グループの行に計上されます。グループ別の行を足し合わせると、組織全体の値を上回ることがあります。フィルターのrbac_group_idも同じ考え方で、対象の各UTC日にそのグループに所属していたユーザーに一致します(利用時点の所属で帰属させる方式です)。
フィルターの値は、次元ごとに書式が決まっています。
rbac_group_id:rbac_group_...のタグ付きID、または素のグループUUIDuser_id:user_...のタグ付きIDproduct: 上記の製品名connector_name・plugin_name・skill_name: 大文字小文字を区別しない一致
connectors — 名前の正規化と認証の内訳
/connectorsはコネクタ名の昇順で並びます。公式の例では、「Atlassian MCP server」と「mcp-atlassian」はどちらもatlassianとして現れます。取得元の表記が違っても1行に集約されるので、コネクタ名の表記ゆれをこちらで吸収する必要はありません。フィルターでは、GitHub MCPのような表示名でも、正規化後のgithubでも一致します。
返る主な項目は次のとおりです。
distinct_user_count: 期間内にそのコネクタを使ったユーザー数chat_metrics/claude_code_metrics/cowork_metrics: 製品ごとの会話数またはセッション数office_metrics: Excel・Outlook・PowerPoint・Wordごとのセッション数read_call_count/write_call_count/unclassified_call_count: ツール呼び出しの読み取り・書き込み・分類不能の内訳managed_auth_distinct_user_count/individual_auth_distinct_user_count: 認証方式別のユーザー数
connector_nameには、読める名前ではなく不透明なコネクタIDが入る行もあります。その行ではconnector_display_nameに解決済みの表示名が入ります。ただし表示名は一意ではなく、同じコネクタのclaude.ai側の利用が、読める名前の別行として出ることもあります。表示名を解決できない組織ではnullです。
読み取り・書き込みの内訳は、MCPのツール注釈(読み取り専用かどうか)を根拠にしています。注釈は仕様上オプションで、コネクタのアクセス制御が有効なときは破棄されるため、分類不能の呼び出しは珍しくありません。3つの合計は「分類済みの呼び出し」の総数で、unclassified_call_countの大きさが、読み書きの内訳がどこまで実態を映すかの目安になります。集計開始日は面ごとに異なり、claude.aiは2026-06-01、Claude Codeは2026-05-30、Claude in Officeは2026-05-29、Coworkは2026-06-02です。これより前に及ぶ期間はnullになります。
認証方式別のユーザー数は、組織のIdPで払い出す管理型認証(Enterprise Managed Auth)と、ユーザー自身の同意で接続した個人資格情報のどちらで動いたかを分けたものです。2つは排他ではなく、両方の資格情報を使ったユーザーは両方に数えられます。管理型認証のデータは2026-07-01以降だけで、それ以前にまたがる期間はnullです。0とnullは別物で、nullは「言えない」を意味します。
社外アカウントの接続を絞る設定はClaude Enterpriseでコネクタを制限する設定で扱っています。制限をかけたあとに、どのコネクタが実際に使われているかを確かめる用途に、この集計が使えます。
plugins — third-partyは集計バケット
/pluginsはプラグイン名の昇順で、CoworkとClaude Codeの両方の利用を返します。行ごとにinstall_count(インストールしたユーザー数)、invocation_count(呼び出し回数)、distinct_user_countが付きます。インストールだけしたユーザーもdistinct_user_countに入ります。
注意したいのはplugin_nameがthird-partyの行です。これは1つのプラグインではなく、集計バケットです。クライアントがプラグイン名を報告しなかった活動が、どちらの利用形態のものでもここに集まります。組織が自作したプラグインの活動も、名前付きの行とthird-partyの両方に分かれて入り得ます。したがってthird-partyの行を「サードパーティ製プラグインの合計」と読むのは誤りです。
plugin_idはserena@claude-plugins-officialのような安定した識別子で、取れないときはnullです。サードパーティ製のClaude Codeプラグインは取得元で伏せられ、Coworkのスラッシュコマンドはハッシュ化されたIDしか持たないためです。プラグインの提出や審査の流れはClaudeプラグイン提出ポータル、配布前後の検査はスキル・プラグインのセキュリティスキャンにあります。
skills — 呼び出し数とコストの見方
/skillsはスキル名の昇順です。件数の指標は3つで、意味が違います。
distinct_user_count: 使ったユーザーの人数invocation_count: 明示的に起動された回数。「何回使われたか」はこちらenable_count: その日にスキルを有効化したアカウント数(claude.aiのみ)
invocation_countが数えるのは、モデルまたはユーザー(スラッシュコマンド)が明示的に起動し、指示が文脈に読み込まれた場合だけです。インストールされているだけ、プリロードやフックで文脈に入っただけ、通常のファイルとして読まれただけの場合は数えません。
enable_countは組織全体の値です。user_id・rbac_group_id・productのいずれかで絞る、または分解するとnullになります。日をまたいで足すと二重計上になるため、期間ロールアップでもnullです。
コスト系には2つあります。estimated_overage_spendは、メンバーの日次の従量超過分をスキルに按分した推計で、値は通貨の最小単位(USDならセント)の文字列です。"1250"は12.50ドルです。座席の許容範囲内の利用は0として配分されます。attributed_list_priceは、そのスキルが関わったリクエストの定価ベースの価値で、資金源を問いません。請求額とは一致せず、claude.aiのチャット利用は帰属を持たないため寄与しません。
スキル名は、ユーザー定義や組織のスキル・プラグイン配信のスキルでは不透明なIDで返り、skill_display_nameに表示名が入ります。非公開(private)スキルの名前は、分析キーの保持者にも開示されないためnullのままです。share_status(private / organization / public)はclaude.aiのスキルだけに付き、filter[]=share_status:organizationのように絞り込めます。
artifacts — MIMEタイプと共有状態の全組み合わせ
/artifactsは、アーティファクト作成数をMIMEタイプ別に返します。他のエンドポイントと違い、dateが必須です。行はartifact_typeとis_sharedの組み合わせ(キューブ)で、グループ化しない限り全件が1回で返り、next_pageはnullです。group_by[]を付けた場合だけページングされます。
artifact_typeはtext/markdown、application/vnd.ant.react、image/svg+xmlなどのMIMEタイプか、otherです。Claude CodeとCoworkのアーティファクトはtext/htmlとして報告されます。返る指標はartifacts_created_count、distinct_user_count、published_artifacts_created_countの3つです。公開(published)は、Claude Code・Coworkではリンクを知っていれば誰でも開ける状態を指し、作成数を超えません。
is_sharedは、作成者以外が開ける状態に一度でもなったかどうかを示します。指名したメンバー、組織全体、リンクを知る全員のどれかに当たれば共有済みです。
usersとsummaries — 全体像の入口
/usersは、メールアドレス順でメンバーごとの日次活動を返します。チャット・Claude Code・Cowork・Claude Design・Officeの製品別ブロックが常に付き、未使用の製品はnullでなくゼロ埋めです。group_by[]で使えるのはrbac_group_idだけで、メンバー行をRBACグループ単位の集計に置き換えます。filter[]にはproject_id(claude_proj_...)も使え、そのプロジェクト内のclaude.aiチャット活動に絞れます。ただしproject_idはgroup_by[]やrbac_group_idのフィルターと併用できません。
/summariesは、starting_dateからending_date直前までの日次系列を昇順で返します。日次・週次・月次のアクティブユーザー数に、Cowork・チャット・Claude Code・Office Agentなど製品別の内訳が付きます。割当済みシート数と保留中の招待数も含まれます。filter[]で使えるのはrbac_group_idだけです。グループで絞ると、シート数・招待数と、それらから計算する導入率はnullになります。シートの割り当ては組織単位の値で、グループ単位の対応物がないためです。
実装で踏みやすい点
- グループ別の合計を組織合計と突き合わせない: RBACグループの重複計上で、合計が組織全体を超えるのは仕様どおりです
- 直近数日は変わる: 各日のデータは通常1日遅れで出て、その後の数日で数%改訂されます
nullと0を区別する: 機能が有効でない、集計開始日より前、按分できない、という状況はどれもnullで返ります- 集計期間の始点に注意する: 管理型認証は2026-07-01、読み書き分類は面ごとの開始日以降でないと値が出ません
- レート制限は組織単位: 既定は全エンドポイント合計で毎分60リクエストで、キーごとではありません
- Bedrock経由のClaude Code: Amazon Bedrock経由の利用は、Claude Enterprise Analytics APIにClaude Codeの活動として返りません
期間全体の総括を1回で取りたいときは、starting_dateとending_dateのロールアップを使うと、日次の行を自分で足し合わせる必要がありません。ユーザー数のような重複排除カウントを自前で足すと二重計上になるので、ここはAPI側の再計算に任せるのが安全です。