Claude Compliance APIとは — 監査ログ・OpenTelemetryとの違い

Claude Compliance APIとは何か

Compliance APIは、Claude EnterpriseとClaude Consoleの顧客が、自社組織のActivity Feedへプログラムでアクセスするための機能です。Claude Enterprise組織ではさらに対象が広がります。リンクされた全組織のユーザー・ロール・グループのディレクトリ、各組織の実効設定、claude.ai上のチャット・ファイル・プロジェクトを扱えます。Cowork・Claude Code・Claude Science・Claude for Microsoft 365・Claude in Chromeのセッションまで、1つのAPI体系です。セキュリティ・法務・コンプライアンスの各部門が、アクティビティの監査、コンテンツの取得や削除、下流ツールへのイベント連携に使います。

先に短く答えると、Claude Codeのセッションも取得できます。ただし、Claude Enterpriseのアカウントでサインインして端末で動かした分に限ります。必要なキーはCompliance Access Keyで、通常のClaude APIキーでは認証が通りません。

エンドポイントはすべてhttps://api.anthropic.comの/v1/compliance/*配下にあり、x-api-keyヘッダーで認証します。有効化とキー作成の手順はCompliance APIのセットアップとアクセスキー作成にまとめています。DLP製品から読ませる例はClaude DLPにCyberhavenを使うにあります。

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"

read:compliance_activitiesスコープを持つキーなら、この呼び出しで直近1件のActivityを取得できます。レスポンスにはdata配列のほか、続きがあるかを示すhas_moreと、先頭・末尾のIDを示すfirst_id・last_idが入ります。

どのキーなら何に届くか

キーは発行元で到達範囲が決まります。判断の分かれ目は、組織がClaude Enterpriseテナントの一部かどうかです。モデルを呼ぶための通常のClaude APIキー(sk-ant-api03-)は、/v1/compliance/*では使えません。

Admin API keyでチャットやファイルのエンドポイントを呼ぶと、必要なスコープを示す403が返ります。Activity Feedより先の機能が必要になった時点で、Claude Enterpriseへの移行を検討することになります。なお、Claude Enterpriseの親組織はClaude Console(platform.claude.com)には表示されません。親組織にはワークロードもAPIキーもないためで、Compliance Access Keyはclaude.aiの組織設定で作ります。Consoleで探して見つからなくても異常ではありません。

read:compliance_user_dataを持つキーは、リンクされた全組織のチャット・ファイル・プロジェクト・セッションの中身を読めます。主オーナーがまだ見ていない内容も含みます。delete:compliance_user_dataなら、チャットなどを恒久的に削除できます。公式は、本番データベースの認証情報と同じ扱いで秘密情報管理の仕組みに置くよう求めています。ソース管理やSIEMの転送設定には置きません。

Activityのactorは7種類ある

レスポンスの各要素はActivityと呼ばれ、誰が何をしたかをactorフィールドで表します。このactorはtypeで持つ項目が変わる判別共用体で、7種類あります。

読み取り側の実装は、想定外のtypeが来ても無視せず素通しする作りにしておくと安全です。新しい活動種別が追加されたときに壊れずに済みます。もう一つの落とし穴はuser_actorです。メモリー移行のように、ユーザーの代わりにAnthropicが動かした処理がそのユーザーの操作として出ることがあります。メモリー系のActivityは、誰が実行してもip_addressが0.0.0.0になりえます。IPアドレスだけでは、プラットフォーム側の処理かどうか判別できません。

Compliance APIが対応する範囲

Claude Enterpriseテナントは、アイデンティティを一元管理する親組織を1つ持ちます。そこに、2種類のリンク組織がぶら下がる構成です。ユーザーがチャット・コンテンツを扱うclaude.ai組織と、APIワークロードを管理するClaude Console組織です。親組織を対象とするキーでは、ディレクトリ系のエンドポイント(組織・ユーザー・ロール・グループ)がどちらの種類のリンク組織からもデータを返します。一方、コンテンツ系のエンドポイント(チャット・ファイル・プロジェクト・添付・セッション)はClaude Enterpriseのデータのみが対象です。

セッションのエンドポイントは2種類のトランスクリプトを返します。1つは、ユーザーの端末で動くローカルセッションです。対象は、Enterpriseアカウントでサインイン中に実行したCowork・Claude Code・Claude Science・Claude for Microsoft 365・Claude in Chromeです。ただしClaude ScienceとClaude in Chromeの対応はベータです。もう1つは、claude.aiのWeb・モバイルから始めたCoworkセッションで、Anthropic管理環境のクラウドで動くリモートセッションです。

全エンドポイントは親組織単位(単独のClaude Console組織なら組織単位)で、毎分600リクエストのレート制限を共有します。ローカルセッションのエンドポイントはこの共有枠だけを消費します。リモートセッションのエンドポイントは、別枠のリクエスト予算を追加で持ちます。

取れないものと記録されないもの

「全部取れる」と期待して設計すると、監査で穴が見つかります。公式が挙げる対象外を、読者の疑問に近い順に並べます。

• Claude Codeの一部の使い方: Consoleのキーでの認証、Bedrock・Google Cloud・Microsoft Foundry経由、クラウドセッションは対象外です。クラウドセッションはリモートセッションではありません。リモートセッションのエンドポイントが返すのはCoworkのセッションだけです。クラウドで動くClaude Code routinesも同じ扱いで、セッションのエンドポイントは返しません。Coworkのクラウド定期実行は1回ごとがリモートセッションとして取れますが、タスク名やスケジュールは返りません。Coworkのスケジュールタスクを一覧するエンドポイントもありません
• Claude APIのワークロード: APIキーで認証したClaude Console・Claude APIのプロンプトや応答の本文は、一切取得できません
• Activity Feedの中身: 資源に対するイベントを記録するだけで、プロンプトや応答のテキストは含みません。ファイル名とタイトルのフィールドも、2026年9月24日以降は常にnull・空文字・省略のいずれかです。それ以前の記録も同じです。名前が要るときはメタデータのエンドポイントで引きますが、削除後は引けません
• セッションの一部の情報: thinkingブロック、画像などのバイナリ、ツール定義、MCPサーバー設定は、トランスクリプトに入りません。ローカルセッションではシステムプロンプトが目印のメッセージに置き換わり、バイナリの位置にはプレースホルダーのtextブロックが入ります。リモートセッションでは、非テキストのブロックが省かれます。テキスト抽出で保存された添付の元ファイルや、textブロックの引用メタデータも入りません
• 端末内で完結する動き: Claudeが読まなかったローカルファイルのように、APIに送られない操作は取得されません。記録はAPIに届いたリクエストが元なので、端末に何も入れずに使えます
• すでに消えた内容: 保持ポリシーで消えた内容、削除済みのリモートセッション、ハード削除した内容は返りません。ユーザーが削除したチャットは一覧に残り、deleted_atが入ります

HIPAA対応を有効にした組織では、ローカルセッションの対象がCoworkとClaude Codeに絞られ、保存期間も30日です。ゼロデータ保持(ZDR)が効いているセッションも除外されます。顧客管理の暗号化キーを使う組織で、そのキーが一時的に使えないときは、ローカルセッションのメッセージ取得が503を返します。セッションの一覧自体は引き続き返ります。

どれだけ遡れるか — 保持期間の違い

保持期間は対象によって別々に決まります。

チャット・ファイル・プロジェクトの中身は、自社が設定したclaude.aiの保持ポリシーに従います。ローカルセッションも、有限の保持期間を組織が設定しているとその期間に従います。設定を変えた時点で、新しい期間より古いメッセージは取得できなくなり、期間を延ばしても失効分は戻りません。

ここから導ける運用上の判断は次のとおりです。次のような場合は、取り込みの時点で自前のアーカイブにも書き出す選択肢があります。法的な保全の期間が6年を超える。削除前にコンテンツを残したい。削除系の運用(DLPによる強制削除など)を組む。さらに、保持ポリシーがeDiscoveryの期間より短い場合も当てはまります。ローカルセッションのカスタム保持期間もここに含まれます。ハード削除には復旧期間がなく、即時かつ恒久です。それ以外なら、都度APIで取得すれば足り、複製を持つ必要はありません。

オフにすると記録が止まる

Compliance APIは、組織の管理者が後からオフにできます。オフの間はActivityが記録されず、Activity Feedに新しいイベントが入りません。例外はオフ・オンの切り替え自体で、org_compliance_api_settings_updatedとして残ります。Access Transparencyに登録している組織では、そのイベント配信も止まります。オフの間の記録は、再びオンにしても取り戻せません。オンに戻すと、その時点から記録が再開されます。

Claude Enterpriseでは、同じ設定がローカルセッションのトランスクリプト取得も左右します。取得は有効化と同時に始まり、オフの間は止まります。止まっていた間のセッション内容は残りません。切り替えの操作ひとつで、取り戻せない監査の空白ができます。Vantaへの取り込みでの扱いはClaudeとVantaの連携にあります。

監査ログエクスポートとの違い

claude.aiの組織設定にある監査ログエクスポートは、OwnerやPrimary Ownerが手動でCSVをダウンロードする別機能です。取得できる期間に上限があり、フォーマットもCSV限定で、チャット・ファイル・プロジェクトの中身は含まれません。継続的にプログラムで取得したいなら、Compliance APIを標準にします。claude.aiでの監査ログの読み方や項目構造はClaude監査ログの見方にまとめてあるので、手動ダウンロードで足りる場面ではそちらを参照してください。

OpenTelemetry監視との違い

Cowork・Claude Codeが対応するOpenTelemetry(OTel)ログは、個々のイベントを発生の都度、自社が運用するコレクターへストリーミングする仕組みです。トークン数・コスト・実行ホストの情報を含みます。対してCompliance APIは、Anthropic側に保持されたセッション単位のトランスクリプトを、リクエストのたびに取得する仕組みです。既存のCompliance Access Keyでそのまま使えます。OTelもプロンプト・応答の本文を記録できますが、CoworkとClaude Codeのセッション内容を取得する用途では、AnthropicはCompliance APIを推奨しています。ローカルセッション・リモートセッション・OTelログを横断した比較表はCoworkのOpenTelemetry監視設定にあります。Claude APIのOpenTelemetryで本文を送る設定は、Metadata onlyとFull contentの選び方で扱っています。Claude API側のスパンを送る設定はClaude Consoleの送信先設定が扱います。

Inference hooksとの違い

Inference hooksはインラインで動きます。組織のAIセキュリティサーバーが、統治対象のプロンプトを推論の直前に受け取り、リアルタイムで許可か拒否かを判定する仕組みです。公式はInference hooksをベータとして扱っています。Compliance APIは事後に記録を取得する仕組みで、組織設定や非テキストファイル全体まで含む、より詳細なデータを返します。作動するタイミングと呼び出す方向が逆です。リクエストを推論前に止めたいならInference hooks、起きたことを事後に監査したいならCompliance API、という住み分けになります。

Analytics APIとの違い

Anthropicが提供する分析系APIには、Claude Enterprise Analytics APIとClaude Code Analytics APIの2つがあります。どちらもIT・FinOps・プラットフォームチーム向けに、利用量とコストの集計値を返します。Compliance APIが返すのはイベント単位の個別レコードで、対象読者もセキュリティ・法務・コンプライアンスの各部門です。集計値が欲しいのか個々の記録が欲しいのかで、そもそも問いの立て方が違います。キーの発行経路も別なので、両方必要な組織は別々にプロビジョニングします。

4つの仕組みをどう組み合わせて使うか

4つは互いに排他ではありません。日常のアラートはOTelで拾います。統治が必要な入力はInference hooksでインラインに遮断し、インシデント発生後の正式な証跡確認と削除対応はCompliance APIで行う、という重ね方が実際の運用に近い構成です。監査ログエクスポートは、単発の確認や、Compliance APIを使うほどでもない小規模な照会に残しておく位置づけになります。

たとえば機密情報の持ち出しをDLPポリシーで止めたい組織を考えます。まずInference hooksで危険なプロンプトをインラインに拒否し、拒否されなかった分は、Compliance APIのチャット・セッションのエンドポイントで事後に中身を見ます。2段構成が現実的です。拒否した事実そのものはActivity Feedに残ります。OTelは、コスト超過や異常なツール呼び出し頻度をダッシュボードで検知する用途に向いています。

Activity Feedの取り込みで起きやすい失敗

Activity Feedの取り込みには、窓を区切って定期的に取る方法と、前回のカーソルから続きを取る方法があります。返るActivityは同じで、違いはクライアントが保持する状態です。窓方式は状態を持たない定期バッチ向き、カーソル方式は取り込み遅延を最小にしたいときの方式で、カーソルを置く永続的な場所が要ります。どちらの方式でも、Activityは発生から1分以内に照会できるようになり、1ページの上限は5,000件です。

窓方式でもカーソル方式でも、手順を誤ると取りこぼしが静かに起きます。カーソル方式の周回は次の流れです。

窓方式には別の罠があります。窓の上端created_at.ltを現在に近づけすぎると、遅れて索引されたActivityが、窓が進んだあとは二度と取れません。上端は少なくとも1分前に置きます。それでも後から索引されるものはありうるので、Activityのidで重複を除き、窓を数分重ねるか、古い窓を再照会する突き合わせを定期的に走らせます。Activity Feedは少なくとも1回は届く前提で、再試行で同じActivityが再配信されることもあります。

SIEMと突き合わせるときの結合キーは、メールアドレスよりactor.user_idが向いています。メールや表示名が変わっても変わらず、Compliance APIのどのエンドポイントでも共通です。ただしuser_idとemail_addressはuser_actorのときだけ入ります。ip_addressとuser_agentもanthropic_actorなどでは入りません。読む前にactor.typeを確かめます。Compliance API自身の呼び出しもcompliance_api_accessedとして記録されます。activity_types[]=compliance_api_accessedで絞ると、api_actorのapi_key_idから、どのキーで照会したかを追えます。

件数は完全性の確認に使えません。一覧のレスポンスにはtotal_countもチェックサムもないためです。claude_chat_viewedのような閲覧系のActivityはアプリの読み込みの仕方に左右され、チャットがあっても閲覧記録が出ない期間がありえます。取り込みの完了を示したいなら、開始カーソルと最後のlast_id、書き出した件数、実行時刻、最終ページのrequest-idを残します。具体的な使い方は、Compliance APIのActivity Feedを使うに続きます。

まとめ

Compliance APIは、監査ログエクスポートより深く、OpenTelemetryより事後寄りで、Inference hooksとは作動する向きが逆の仕組みです。導入前に確かめる点は、組織がEnterpriseテナントか、監査対象にClaude Code(ConsoleキーやBedrock経由)やAPIのワークロードが含まれていないか、の2つです。含まれているなら、Compliance APIでは取れないので別の経路を用意することになります。Microsoft 365中心の組織がPurviewへ取り込む手順は、ClaudeとMicrosoft Purviewを連携する手順にあります。