Compliance API Activity Feedの使い方 — フィルタとカーソルページネーション
Compliance APIのActivity Feedをフィルタとカーソルページネーションで取得する手順と、Activityオブジェクトの構造を一次資料から示します。
Activity Feedで何が取得できるか
Activity Feedは、組織内の認証・チャット・ファイル・プロジェクト・管理操作・プラットフォームのアクティビティを記録し、新しい順に返すエンドポイントです。発生から1分以内に照会できるようになり、6年間保持されます。記録は遡及しません。Compliance APIを組織で有効化した時点から記録が始まり、それ以前のアクティビティはバックフィルされません。
Compliance APIそのものの位置づけや、監査ログエクスポート・OpenTelemetry・Inference hooksとの違いはCompliance APIとはにまとめています。ここでは、Activity Feedを実際に呼び出すところから始めます。
前提: 必要なスコープとキー
read:compliance_activitiesスコープを持つキーが必要です。Compliance Access Key(sk-ant-api01-...)とAdmin API key(sk-ant-admin01-...)のどちらでも、このスコープを持っていれば呼び出せます。Admin API keyは、組織でCompliance APIを有効化したあとに作成したものだけが、このスコープを持ちます。キーをまだ作成していない場合は、Compliance APIのセットアップとアクセスキー作成を先に済ませてください。
どちらのキーで呼ぶか
Compliance Access Key
全エンドポイントに届きます。チャット本文・ファイル・セッションのトランスクリプトまで取得する予定があるなら、最初からこちらを選びます。
Admin API key
届くのはActivity Feedだけです。親組織を持たない単独のClaude Console組織は、このキーでActivity Feedを照会します。
アクティビティを取得する
もっとも単純な呼び出しは、直近1件のActivityを取得するリクエストです。
curl --fail-with-body -sS \
"https://api.anthropic.com/v1/compliance/activities?limit=1" \
--header "x-api-key: $ANTHROPIC_COMPLIANCE_ACCESS_KEY" \
--header "anthropic-version: 2023-06-01"orderパラメータは既定がdesc(新しい順)で、ascにすると古い順に返ります。after_idとbefore_idはこの並びを基準にした向きです。以下の説明は既定のdescを前提にします。
レスポンスはdata(Activityの配列)、has_more、first_id、last_idを持つJSONオブジェクトです。limitの既定値は100、最大は5,000まで指定できます。
activity_types・created_atでフィルタする
組織・アクター・アクティビティ種別・created_atの時間窓でフィルタできます。時間窓はcreated_at.gte / .gt / .lte / .ltのドット付きサブパラメータで指定します。activity_types[]やactor_ids[]のような繰り返し可能なパラメータは、値の数だけ同じキーを配列ブラケット構文で渡します。
curl --fail-with-body -sS -G \
"https://api.anthropic.com/v1/compliance/activities" \
--data-urlencode "activity_types[]=claude_file_uploaded" \
--data-urlencode "activity_types[]=claude_chat_created" \
--data-urlencode "created_at.gte=2026-04-01T00:00:00Z" \
--header "x-api-key: $ANTHROPIC_COMPLIANCE_ACCESS_KEY" \
--header "anthropic-version: 2023-06-01"activity_types[]が受け付ける値はアクティビティの種類ごとに数百通りあります。全リストはAPIリファレンスで確認してください。
actor_ids[]に渡せるのは、今のところuser_...で始まるユーザーIDだけです。IDはGET /v1/compliance/organizations/{org_uuid}/usersで列挙します。同じ意味の別名としてuser_ids[]もあり、両方を渡すと一覧がマージされます。organization_ids[]にはorg_...か組織UUIDを渡し、IDはGET /v1/compliance/organizationsで引けます。
時間窓で定期取得するときは、上限のcreated_at.ltを現在より1分以上前に置きます。1分は、発生したアクティビティが照会可能になるまでの公式の遅延です。これより現在に近い上限で窓を進めると、後から索引に載ったアクティビティが、どの後続の窓にも現れないまま取りこぼされます。窓の継ぎ目を数分重ねてidで重複排除する運用は、Compliance APIをSIEMと連携するで扱います。
limitとレート制限
1リクエストで取れる件数はlimitの上限(5,000)までです。レート制限は、全/v1/compliance/*エンドポイントで親組織あたり毎分600リクエストを共有します(単独のClaude Console組織では組織あたり)。この枠は、キーの数や連携組織の数にかかわらず親組織の全体で1つです。リモートセッションのエンドポイントだけは、これに加えて別のリクエスト枠を持ちます。
1ページの件数を増やせば、同じ件数を取り切るのに必要なリクエスト数が減ります。取り込みパイプラインでは、limit=5000を既定にしてhas_moreでページ数を制御する構成がまず候補になります。
カーソルでページ送りする
Activitiesは新しい順に返り、created_atが同じ場合はアクティビティIDで順序が決まります。ページングの方式はエンドポイントの種類によって異なります。
| エンドポイント群 | ソート順 | 方式 | パラメータ |
|---|---|---|---|
| Activities | ソート順新しい順 | 方式カーソル | パラメータafter_id / before_id(レスポンスはfirst_id / last_id) |
| チャット・チャットメッセージ | ソート順古い順 | 方式カーソル | パラメータafter_id / before_id |
| 組織・ユーザー・ロール・グループ等 | ソート順エンドポイント固有 | 方式ページトークン | パラメータpage(レスポンスはnext_page) |
| ローカル・リモートセッション | ソート順セッションは新しい順、メッセージは既定で古い順 | 方式ページトークン | パラメータpage(レスポンスはnext_page) |
ファイルはページングされず、IDを指定して1件ずつ取得します。カーソルとページトークンは不透明な文字列として扱い、そのまま渡し戻します。内部フォーマットは安定しておらず、パースすると予告なく壊れます。
Activitiesのページ送り
- 1
古いページへ進む
レスポンスの
last_idを、次のリクエストのafter_idに渡します。新しい順に並ぶので、次のページには古いアクティビティが入ります。 - 2
新しいページへ戻る
first_idをbefore_idに渡します。1回のリクエストで指定できるのはafter_idかbefore_idのどちらか一方です。 - 3
止める
has_moreがfalseになったら停止します。
ページの方向を決めるのはカーソルのパラメータで、時間の向きを決めるのはエンドポイントのソート順です。チャットは古い順なので、同じafter_idでも新しい側へ進みます。
過去分をさかのぼって取得するバックフィルは、has_moreとlast_idを軸にループを組みます。
cursor = stored_cursor
loop:
if cursor is not null:
page = GET /v1/compliance/activities?after_id={cursor}&limit=100
else:
page = GET /v1/compliance/activities?limit=100
store(page.data)
if page.last_id is not null:
cursor = page.last_id
if not page.has_more: break
persist(cursor)最終last_idを永続化するのは、そこまでの全ページを保存し終えたあとにします。取りこぼしたページを後から特定できなくなるためです。途中で失敗したら、保存済みの位置から同じカーソルでやり直します。
Activityオブジェクトの構造
data配列の各要素は共通のトップレベル項目(id / created_at / organization_id / organization_uuid / actor / type)に加え、アクティビティ種別ごとの追加項目を持ちます。チャットイベントにはclaude_chat_id、ファイルイベントにはclaude_file_idが付きます。
organization_idは、サインインやサインアウト、Compliance API呼び出しのように特定の組織に紐づかないイベントではnullになります。取得したイベントを組織別に集計する処理には、nullの分岐を入れておきます。
actorは種別で持つ項目が変わる判別共用体です。
actor.type | 現れる場面 | 主な項目 |
|---|---|---|
user_actor | 現れる場面claude.aiかClaude Consoleにサインインしたユーザーの操作 | 主な項目email_address / user_id |
api_actor | 現れる場面顧客発行のAPIキーによるClaude APIやCompliance APIの呼び出し | 主な項目api_key_id |
admin_api_key_actor | 現れる場面管理者がAdmin API keyでユーザー・招待・ワークスペース・APIキーを管理 | 主な項目admin_api_key_id |
unauthenticated_user_actor | 現れる場面サインイン完了前の操作(sso_login_initiatedなど) | 主な項目unauthenticated_email_address |
scim_directory_sync_actor | 現れる場面IdPがSCIMのディレクトリ同期で変更を反映 | 主な項目directory_id |
このほかにanthropic_actorとsystem_actorがあります。統合の実装では、想定外のtypeやactor.typeが来ても捨てずに素通しし、未知のフィールドは無視します。アクティビティ種別が増えても動き続けるようにするためです。
件数と名前を読むときの落とし穴
Activityを解釈するときの3つの注意
viewedは閲覧ではない
claude_chat_viewedのようなclaude_*_viewedは、人が内容を見たことではなく、Claudeアプリがサーバーからチャット・ファイル・プロジェクトを読み込んだことを示します。読み込みは重複排除されません。Web・デスクトップ・モバイルが別のタイミングで、ときにはバックグラウンドで読み込み、キャッシュ表示では読み込み自体が起きません。user_actorは本人操作とは限らない
Anthropicがユーザーに代わって動かす処理が、
system_actorでなく対象ユーザーのuser_actorとして現れることがあり、この帰属は変わる可能性があります。移行に伴うメモリ関連(platform_memory_store_createdなど)がその例です。メモリ関連のip_addressは誰の操作でも0.0.0.0になりうるため、IPだけでは基盤側の処理と判別できません。ファイル名とタイトルは入らない
ファイル・プロジェクト文書・アーティファクトのアクティビティでは、
filenameとtitleは常にnull・空文字・省略のいずれかです。2026年9月24日以前に記録されたものも同じです。名前を知りたいときは、claude_file_*・claude_proj_doc_*・claude_artifact_version_*のIDを、メタデータ用のエンドポイントに渡します。read:compliance_user_dataスコープのCompliance Access Keyが必要で、削除済みの対象は引けません。
認証系のイベントも同じフィードに載ります。サインイン・サインアウトのほか、Compliance API自体への呼び出し(compliance_api_accessed)も記録されるので、誰がいつCompliance APIを叩いたかという、コンプライアンスチーム自身の操作履歴も追えます。
よくあるつまずき
- ローカルセッションのページトークンを24時間放置する: セッションメッセージのウォークは、最初のページから24時間で
pageトークンが失効します。取得を分割する場合は24時間以内に完了・再開するか、pageパラメータなしで再開始します。ローカルセッション一覧では古いpageトークンも受け付けられますが、現在の保持期間の境界で再評価され、セッションが飛ぶことがあります - セッション系エンドポイントで
has_moreを探す: ローカル・リモートセッションのエンドポイントだけはhas_moreを返さず、next_pageがnullになったら停止します - 同じアクティビティが2回返ってきたことを異常とみなす: 配信は少なくとも1回(at-least-once)の契約で、部分的な失敗のあとのリトライで取得済みのアクティビティが再配信されることがあります。集計より先に、
idでの重複排除を挟みます
まとめ
Compliance APIのうちAdmin API keyで呼べるのはActivity Feedだけで、監査証跡の取り込みはここから始められます。ファイル名や閲覧回数のように中身を読む用途は、フィードの値だけでは足りない場合があるため、取り込み設計の段階で別のエンドポイントとの併用を見込んでおくと手戻りが減ります。