コンプライアンス統合を設計する
ポーリングとカーソル駆動のActivity Feed消費のどちらかを選択し、Compliance APIのイベントをSIEMと相関させ、保持を計画します。
本番環境のCompliance API統合では、3つの設計上の選択を行います。Activity Feedをどのように消費するか、その出力を「security information and event management」(セキュリティ情報イベント管理)、すなわちSIEMシステムとどのように相関させるか、そしてアクティビティとコンテンツの長期コピーをどこに保管するかです。これらの選択はエンドポイント自体とは独立しています。このページは、そのトレードオフを評価するのに役立ちます。
このページは、以下のページをすでに読んでいることを前提としています。
- Activity Feedをクエリする:本ページ全体で参照されるパラメータとページネーションの契約を定義しています。
- チャット、ファイル、プロジェクトを取得および削除する:チャット、ファイル、プロジェクトのエンドポイントと、コンテンツ保持を計画するで参照される
deleted_atのセマンティクスを定義しています。 - セッショントランスクリプトを取得する:ローカルおよびリモートセッションのエンドポイントを定義しています。
フィード消費パターンを選択する
Activity Feedは2つの消費パターンをサポートしています。created_at.gte と created_at.lt で範囲を区切った定期的なウィンドウポーリングと、あるレスポンスから得たカーソルを永続化して次のリクエストで渡すカーソル駆動のインクリメンタル読み取りです。どちらも同一の Activity オブジェクトを返します。違いは、呼び出しの間にクライアントが永続化する状態です。
両方のパターンに共通する制約は次のとおりです。
- アクティビティは発生から1分以内にクエリ可能になり、6年間保持されます。記録は遡及的ではありません。組織でCompliance APIが最初に有効化された時点から記録が始まり、有効化前のアクティビティはバックフィルされません。
- 各ページの
limitの最大値は5,000です。 - カーソル値は不透明な文字列であり、解析してはいけません。
- リクエストは親組織ごとに毎分600件に制限されており、すべてのキー、すべてのリンクされた組織、すべての
/v1/compliance/*エンドポイントで共有されます。ローカルセッションエンドポイントとは異なり、リモートセッションエンドポイントにはこれに加えて2つ目のリクエスト予算があります。レスポンスヘッダーとリトライの契約については、429 Too Many Requestsを参照してください。
| パターン | 選択すべき場合 |
|---|---|
| ウィンドウポーリング | パイプラインが固定スケジュールで実行され、ステートレスなワーカーを好み、ウィンドウの再生や重複を許容できる場合 |
| カーソル駆動のインクリメンタル読み取り | アクティビティの発生からパイプラインへの取り込みまでの「latency」(レイテンシ)を最小にしたい場合、すでに読み切ったページの再読み取りを避けたい場合、そして実行間でカーソルを永続化できる耐久性のある場所がある場合 |
ウィンドウポーリング
ウィンドウ内のすべてのアクティビティがすでにクエリ可能になっているように、created_at.lt を少なくとも1分前に設定します。連続するウィンドウが隙間や重複なく並ぶように、下限には created_at.gte、上限には created_at.lt を使用します。前のウィンドウの lt の値を次のウィンドウの gte として再利用してください。
curl --fail-with-body -sS -G \
"https://api.anthropic.com/v1/compliance/activities" \
--header "x-api-key: $ANTHROPIC_COMPLIANCE_ACCESS_KEY" \
--data-urlencode "created_at.gte=2026-04-20T07:00:00Z" \
--data-urlencode "created_at.lt=2026-04-20T08:00:00Z" \
--data-urlencode "limit=5000"レスポンスが has_more: true の場合、そのウィンドウには1ページを超えるアクティビティが含まれています。レスポンスの last_id を次のリクエストで after_id として渡してウィンドウ内をページングする(has_more が false になったら停止する)か、より小さな時間ウィンドウを選択してください。完全な契約については、結果をページネーションするを参照してください。
きれいに並べた場合でも、ウィンドウが閉じた後にインデックスされたアクティビティは、後のウィンドウには決して現れません。アクティビティの id で重複排除を行い、新しい各ウィンドウを前のウィンドウと数分重なるように広げるか、古いウィンドウを再クエリする定期的な照合パスを実行してください。
カーソル駆動のインクリメンタル読み取り
first_id="activity_01XyDMpzjS89pFZXqSFUBDr6" # first_id from a previous response
curl --fail-with-body -sS -G \
"https://api.anthropic.com/v1/compliance/activities" \
--header "x-api-key: $ANTHROPIC_COMPLIANCE_ACCESS_KEY" \
--data-urlencode "limit=5000" \
--data-urlencode "before_id=$first_id"has_more が false になるまでページングし、最後のレスポンスの first_id を永続化して、次回の実行時にそのまま before_id として渡すことで、保存したカーソルより新しいアクティビティを取得します。バックフィルのために逆方向にたどる場合は、代わりに last_id を永続化して after_id として渡します。カーソルとページトークンの完全なリファレンスおよびリトライのセマンティクスについては、結果をページネーションするを参照してください。
本番環境のキャッチアップループは、has_more と first_id に基づいて反復を駆動することで、前回のポーリング以降に記録されたアクティビティを取得します。
cursor = stored_cursor
loop:
page = GET /v1/compliance/activities?before_id={cursor}&limit=5000
store(page.data)
if page.first_id is not null:
cursor = page.first_id
if not page.has_more: break
persist(cursor)カーソルはキーのローテーション後も有効です。キーを管理およびローテーションするを参照してください。
SIEMと相関させる
各 Activity には、SIEM(Splunk、Datadog、Microsoft Sentinel、Cribl、または同様のもの)にすでにあるイベントと結合できるフィールドが含まれています。
| Compliance APIのフィールド | 結合対象 |
|---|---|
actor.user_id | IDプロバイダーの安定したユーザー識別子 |
actor.email_address | 安定したIDが利用できない場合のディレクトリのメールアドレス |
actor.ip_address | ネットワーク、VPN、エンドポイントのログ |
actor.user_agent | エンドポイントおよびデバイスのインベントリ、ならびにリクエストを行ったクライアントアプリ |
created_at | あらゆるソースにわたる時間ウィンドウ相関 |
actor.user_id と actor.email_address は、actor.type が user_actor の場合に存在します。actor.ip_address と actor.user_agent は、anthropic_actor や scim_directory_sync_actor などの一部のアクタータイプでは存在しません。これらのフィールドを読み取る前に、判別子を確認してください。user_id はユーザーアカウントの安定した不透明な識別子です。すべてのCompliance APIエンドポイントとアクティビティペイロードで一貫しており、ユーザーのメールアドレスや表示名が変更されても変わりません。主結合キーには email_address ではなく user_id を使用してください。
Compliance API自体への呼び出しは compliance_api_accessed アクティビティを発行します。誰がいつコンプライアンスデータをクエリしたかをSIEMが記録できるように、これらを他のアクティビティタイプと一緒に取り込んでください。activity_types[]=compliance_api_accessed を渡してクエリの範囲を絞り、クライアント側で actor.type が api_actor である各アクティビティから actor.api_key_id を読み取って、アクセスを特定のCompliance Access KeyまたはAdmin APIキーに帰属させます。
コンテンツ保持を計画する
後で何を取得できるかは、5つの保持期間によって決まります。
| データ | 保持期間 | 管理者 |
|---|---|---|
| Activity Feedのレコード | 6年間 | Anthropic |
| チャット、ファイル、プロジェクトのコンテンツ | 組織のclaude.ai保持ポリシー(ユーザーがそれより早く削除しない限り) | お客様の組織 |
| ローカルセッショントランスクリプト(ユーザーのマシン上のセッション) | デフォルトで6年間、または有限のカスタム会話保持期間が設定されている場合は組織のその期間 | デフォルトではAnthropic、カスタム期間を設定した場合はお客様の組織 |
| リモートセッショントランスクリプト(クラウド上のセッション) | 6年間 | Anthropic |
| Compliance APIを通じてハード削除されたコンテンツ | 保持されません。削除は即時かつ永久的です | DELETE エンドポイントの呼び出し元 |
Claude Platformの他の部分が保持をどのように扱うかについては、APIとデータ保持を参照してください。
エクスポートしてアーカイブするか、オンデマンドでAPIから取得するかは、次のように決定します。
- アクティビティメタデータまたはセッショントランスクリプトについて、リーガルホールドや監査の期間が6年を超える場合は、取り込み時にActivity Feedのページとセッショントランスクリプトを自社のアーカイブにエクスポートしてください。
- コンテンツ保持ポリシーがeDiscoveryの期間より短い場合は、保持ウィンドウが切れる前にチャットとファイルのコンテンツをエクスポートしてください。Compliance APIは、保持によってすでに削除されたコンテンツを返すことはできません。同じことがローカルセッショントランスクリプトにも当てはまります。ローカルセッショントランスクリプトは、有限のカスタム会話保持期間が設定されている場合、その期間が6年より短くても組織のその期間に従います。ローカルセッションエンドポイントは、設定が変更されるとすぐに組織の現在の期間より古いメッセージを返さなくなり、後で期間を延長してもすでに期限切れになったトランスクリプトは復元されないため、その期間を超えて保持する必要があるトランスクリプトはエクスポートしてください。
- ユーザーがclaude.aiで削除した後もチャットコンテンツを保持する必要がある場合(たとえばリーガルホールド下)、取り込み時にチャット、ファイル、アーティファクトのコンテンツを自社のアーカイブにエクスポートしてください。Compliance APIは、ユーザーがすでに削除したコンテンツを返すことはできません。
- ワークフローがCompliance APIのハード削除を発行する可能性がある場合(たとえばDLPの適用)、まず対象コンテンツを取得してアーカイブしてください。ハード削除後の回復ウィンドウはありません。
それ以外のすべての場合は、APIからの直接取得に依存し、並行コピーの維持は避けてください。
配信保証と完全性
Activity Feedはat-least-once(少なくとも1回)として扱ってください。正しくページネーションされた走査はすべてのアクティビティを少なくとも1回返しますが、部分的な失敗後のリトライでは、すでに保存したアクティビティが再配信される可能性があります。アクティビティの id フィールドで重複排除を行ってください。
リストエンドポイントは total_count フィールドやチェックサムを返しません。エクスポート実行が完了したことを証明するには、次を記録してください。
- 開始カーソルと終端の
last_id。 - エクスポートしたレコード数。
- 実行タイムスタンプと最終ページの
request-id。
アクティビティの量は完全性のチェックにはなりません。claude_chat_viewed などの claude_*_viewed アクティビティタイプは、各アプリの読み込みパターンに従います(Activityオブジェクトを理解するを参照)。チャットメッセージがあるのに claude_chat_viewed アクティビティがない期間があっても、それだけでデータの欠落を示すわけではありません。代わりに、走査と、ウィンドウポーリングで説明した重複または照合パスに依存してください。
コンテンツエンドポイント(チャット、ファイル、プロジェクト、プロジェクト添付ファイル、ローカルおよびリモートセッショントランスクリプト)は、Claude Enterpriseのデータのみを提供します。Activity Feedは、組織全体の管理イベントとリソースイベントを表示します。Compliance APIには以下は含まれません。
- Claude Consoleからの、またはAPIキーで認証されたClaude APIワークロードからのプロンプトテキストやモデルの応答。
- Claudeが読み取らなかったローカルファイルなど、Anthropicに送信されることのないローカルセッション内のデバイス上のアクティビティ。
- Claude ConsoleのAPIキーで認証された、サードパーティのクラウドプラットフォーム(Amazon Bedrock、Google Cloud、またはMicrosoft Foundry)経由で実行された、またはウェブ上のClaude Codeで実行されたClaude Codeの使用。
- HIPAA対応が有効な組織のローカルセッション、およびゼロデータ保持が適用されているローカルセッション。
- セッショントランスクリプト内の思考ブロック、および画像やその他のバイナリコンテンツ(トランスクリプトにはユーザープロンプト、アシスタントの応答、ツールアクティビティのみが含まれます。ローカルセッショントランスクリプトでは、バイナリコンテンツが省略された箇所にプレースホルダーの
textブロックが表示されます)。 - 一部のWord、PowerPoint、PDFのアップロードなど、claude.aiが抽出テキストとして保存したチャット添付ファイルの元のファイル(ファイルコンテンツエンドポイントは抽出テキストを返します。ファイルとアーティファクトを取得するを参照)。
- ローカルセッションのシステムプロンプト(マーカーメッセージがその代わりになります)。
- セッショントランスクリプト(ローカルまたはリモート)内のツール定義とMCPサーバー設定、およびローカルセッショントランスクリプト内の
textブロックの引用メタデータ。 - 顧客管理の暗号化キーが現在使用できない組織のローカルセッショントランスクリプトのコンテンツ。これらのリクエストは503 Service Unavailableを返しますが、セッションメタデータは引き続きリストされます。
- 組織の保持ポリシーによって削除されたコンテンツ。
- ユーザーがclaude.aiで削除したチャットのコンテンツ(チャットは
deleted_atが設定された状態で引き続きリストされます)。 - Compliance APIを通じてハード削除されたコンテンツ。
Compliance APIが何を取得し、何を取得しないかの詳細については、Compliance API FAQを参照してください。
証拠保全の連鎖(chain of custody)のために、エクスポートしたレコードを来歴メタデータ(ソースエンドポイント、クエリパラメータ、実行タイムスタンプ、各レコードのコンテンツハッシュ)とともに保存してください。
次のステップ
フィルターパラメータ、ページネーション、および Activity オブジェクトのスキーマ。
ハード削除を含む、チャット、ファイル、プロジェクトのエンドポイント。
CoworkやClaude Codeなど、Claudeアプリやエージェントでユーザーが実行するセッションをリストし、そのトランスクリプトを取得します。
Was this page helpful?