Claude Media
Analytics APIでchat_cowork_unifiedに数字が移る仕組みと合算の仕方
AnthropicCoworkTips

Analytics APIでchat_cowork_unifiedに数字が移る仕組みと合算の仕方

Chat and Cowork unified(ベータ)の利用は、Analytics APIでchatやcoworkでなくchat_cowork_unifiedに入ります。移る先、開始前の日の扱い、プロジェクトの分岐、合算の方法を示します。

読了目安 約11分

Enterprise Analytics APIで、ある週からchatやcoworkの数字が急に減った。そう見えたら、まず疑うのはChat and Cowork unified(ベータ)です。この機能を使うメンバーの利用は、chatやcoworkではなくchat_cowork_unifiedという別の行に計上されます。数字は消えたのではなく、移っています。

組織全体の合計は変わりません。変わるのは内訳です。この記事では、数字がどこへ移るか、過去の日がどう残るか、プロジェクト絞り込みだけ例外的に分岐する点、そして合算して元の傾向に戻す方法を順に見ます。

chat_cowork_unifiedとは — 製品別の行が1つ増える

Chat and Cowork unifiedは、Coworkの機能をclaude.aiのチャットに取り込んだ体験です。Analytics APIでは、この体験の活動の大半がchat_cowork_unifiedというproduct値で報告されます。従来のチャットやCoworkの行には入りません。

呼び名は場所ごとに違います。

場所現れ方
ユーザー活動現れ方chat_cowork_unified_metricsオブジェクト
スキル・コネクタ・プラグインの利用現れ方同じくchat_cowork_unified_metrics
活動サマリー現れ方chat_cowork_unified_daily_active_user_count、..._weekly_...、..._monthly_...
コスト・利用状況レポート現れ方products[]の値chat_cowork_unified

統合体験を組織で有効にする手順は、Claude EnterpriseでCowork統合を有効にする手順にあります。ここでは、有効にしたあとにAPIの数字がどう動くかだけを扱います。

数字が移る日と、移らない日

ユーザーが統合体験を使い始めると、そのユーザーの新しい利用は統合の行に入ります。ここで押さえる点は3つです。

あゆみ

1人のメンバーの数字が動く順序

  1. 開始前の日元の行のまま

    統合体験を使い始める前の日の利用は、chatまたはcoworkに残ります。後から書き換わりません。

  2. 開始した日2つの行に割れうる

    その日の活動は、productの間で分かれることがあります。割れ方は保証されません。

  3. 開始後の日大半が統合の行

    利用の大半はchat_cowork_unifiedに入ります。音声モードのように、chatやcoworkに残る活動もあります。

オフにした日にも同じことが起きます。無効にされたメンバーの活動は、その日にproductの間で割れることがあります。

つまりグラフを日次で引くと、chatとcoworkの線は、利用者が統合体験へ移るにつれて下がり、統合の線がその分だけ立ち上がります。開始前の日の値は元のままなので、過去のグラフは書き換わりません。

同じ人が両方の人数に入る

ユーザー数の読み方には、もう一段注意が要ります。

1人のユーザーが、chatまたはcoworkの人数と、統合の人数の両方に数えられることがあります。統合体験を使った日に、一部の活動がまだchatやcoworkとして報告されると、日次でも起きます。

週次・月次ではもっと起きやすくなります。集計の窓の中に、統合体験を使い始める前の日と後の日が両方あれば、使った日が別々でも両方の人数に入ります。たとえば開始が窓の途中にあるケースです。

したがって、次の2つは避けます。

  • chat、cowork、統合の3つの人数を足して「全体の人数」とする
  • 統合の人数が増えた分だけ、chatの人数が減ったとみなす

全体の人数は、daily_active_user_count、weekly_active_user_count、monthly_active_user_countで見ます。製品別の人数は、傾向を見る補助にとどめます。

ユーザー活動の中身 — chatとsessionsに分かれる

ユーザー活動(/v1/organizations/analytics/users)のchat_cowork_unified_metricsは、2つの部分でできています。

  • chat: チャット側の活動。メッセージ数、会話数、プロジェクトの作成と利用、ファイルのアップロード、スキルやコネクタの利用など
  • sessions: Cowork側の活動。アクション数、セッション数、ファイル編集数、ディスパッチのターン数など

項目の名前と意味は、既存のchat_metricsとcowork_metricsに対応します。リファレンスでは各項目が「chat_metrics.message_countと同じ測定で、統合体験をオンにしている間の活動」と説明されています。つまり、中身の定義を新しく覚える必要はなく、「どの行に入るか」だけが変わります。

ここに落とし穴が1つあります。統合体験を提供していない環境では、chat_cowork_unified_metricsそのものが応答から省かれます。ほかの製品別ブロックは、未使用でも全項目が0で返ります。この違いがあるので、集計コードでは次のように分けて書きます。

  • 通常のブロック(chat_metricsなど)は、存在する前提で読む
  • 統合のブロックは、無いことを許す(欠落を0として扱う)

プロジェクトで絞ると、活動は片側にだけ入る

プロジェクトでの絞り込みだけは、扱いが変わります。ユーザー活動にfilter[]=project_id:...を付けると、その日のプロジェクト活動はどちらか1か所にまとめて計上されます。

  • その日に統合体験でチャットメッセージを送っていた場合、そのユーザーのプロジェクト活動はすべてchat_cowork_unified_metrics.chatに入る
  • 送っていなかった場合は、chat_metricsに入る

活動ごとに振り分けるのではなく、ユーザーとその日の組で振り分けます。同じ日に従来のチャットでプロジェクトを使った分も、統合体験でメッセージを送っていれば統合側に寄ります。

curl -s -G "https://api.anthropic.com/v1/organizations/analytics/users" \
  --data-urlencode "date=2026-10-07" \
  --data-urlencode "filter[]=project_id:$PROJECT_ID" \
  --header "anthropic-version: 2023-06-01" \
  --header "x-api-key: $ANTHROPIC_ANALYTICS_KEY"

PROJECT_IDにはclaude_proj_...の形のIDを入れます。このリクエストの応答でも、プロジェクトの利用がchatの欄だけに出ていると思い込まないでください。chat_cowork_unified_metrics.chatも読みます。

プロジェクト単位のエンドポイントには別の制約があります。/apps/chat/projectsはproductの次元に対応せず、group_by[]やfilter[]にproductを入れるとエラーになります。なお、プラグインの利用で現れるproductはcowork、claude_code、chat_cowork_unifiedの3つ、アーティファクトではchat、claude_code、cowork、chat_cowork_unifiedの4つです。

合算して元の傾向に戻す

移動前後の推移を1本の線で見たいときは、chatとcoworkのそれぞれに統合の対応する部分を足します。対応は次のとおりです。

見たい指標足す先
チャットのメッセージ数足す先chat_metrics.message_count + chat_cowork_unified_metrics.chat.message_count
Coworkのメッセージ数足す先cowork_metrics.message_count + chat_cowork_unified_metrics.sessions.message_count

jqなら、統合のブロックが無い応答でも壊れないよう、// 0で欠落を0にします。

jq '[.data[] | {
  chat_messages:
    (.chat_metrics.message_count
     + (.chat_cowork_unified_metrics.chat.message_count // 0)),
  cowork_messages:
    (.cowork_metrics.message_count
     + (.chat_cowork_unified_metrics.sessions.message_count // 0))
}]' users.json

これは応答の形に沿った一例です。実際のレコードには上記以外の項目も入るので、使う指標ごとに足す先を決めてください。

足せない項目もあります。期間指定(date-range)モードでの「異なる〜の数」は近似値で、HLL(HyperLogLog。重複を除いた件数を少ないメモリで見積もる手法)による誤差が通常2%未満とされています。集計できない行ではnullになります。日をまたいで単純に足すと、同じ会話を二重に数えます。足し合わせるのは、メッセージ数のように日ごとに数える件数にとどめます。

コストを製品別に取るときの絞り込み

コスト・利用状況レポートは、products[]で製品を絞れます。ここでの注意は1つです。製品で絞ったとき、統合の利用はproducts[]にchat_cowork_unifiedを含めない限り結果から外れます。

たとえば次の指定で「チャットとCoworkの費用」を取ると、統合体験へ移ったメンバーの分が抜けます。

products[]=chat&products[]=cowork

統合体験を使うメンバーがいる組織では、products[]=chat_cowork_unifiedも加えます。絞り込みを使わない組織全体の合計費用は変わりません。

なお、統合体験の指定は、提供していない環境ではフィルタとして受け付けられません。リストのパラメータはproducts[]=を値の数だけ繰り返す書き方で、ページネーションのカーソルは発行したクエリに結び付きます。products[]を途中で変えると400になるので、条件を変えるときは最初のページから取り直します。

既存の集計を直すときの確認点

移行に伴う見かけの減少を、障害と取り違えないための点検項目です。

数字が減ったと感じたときの点検

  • 全体のアクティブユーザー数や総コストが同じなら、移動です。問題ではありません
  • 製品別のグラフに、chat_cowork_unifiedの行や系列を足しているか
  • 応答のproduct名を固定リストで検査していないか。新しい値で弾かれる実装は修正が要ります
  • 統合のブロックが無い応答を想定しているか
  • 3つの製品別人数を足して全体の人数にしていないか

製品別の線がなだらかに入れ替わっているなら、ほぼ移動で説明がつきます。入れ替わりの日付が、ロールで統合体験を展開した日と重なるかを突き合わせると確実です。

関連する前提

データの鮮度や、アクティブユーザーの定義、APIキーの種類は、統合の有無にかかわらず変わりません。Enterprise Analytics APIの全体像はClaude Analytics API群の使い分けに、コネクタ・スキル・プラグインの各エンドポイントの読み方はEnterprise Analytics APIでコネクタ・スキル・プラグインの利用を取るにまとめています。ユーザー別のコストを取る手順はClaude Analytics APIでユーザー別コストを取得する方法が詳しいです。

データはEnterprise Analytics APIで2026年1月1日以降の日付から取れます。ただしAmazon Bedrock経由のClaude Codeの利用は、このAPIには返りません。統合体験とは無関係な制約ですが、「数字が少ない」の原因を探すときの除外項目になります。

まとめ

chat_cowork_unifiedは、利用者が統合体験へ移った分だけ、chatとcoworkの数字を引き取ります。見かけの減少は内訳の移動で、全体の合計は動きません。製品別の推移を続けて見たい集計は、統合の行を足して読む設計に変えます。人数は足さず、全体の値で見ます。

この記事を共有:XはてブLinkedIn

関連する記事

Anthropic をもっと見る →