Compliance APIとは — 監査ログ・OpenTelemetry・Inference hooksとの違い
Compliance APIは組織のActivity Feedやチャット・ファイル・セッションへプログラムでアクセスする仕組みです。監査ログ・OpenTelemetry・Inference hooksとの違いを一次資料で確認します。
Compliance APIとは何か
Compliance APIは、Claude EnterpriseとClaude Consoleの顧客が、自社組織のActivity Feedへプログラムでアクセスするための機能です。Claude Enterprise組織ではさらに対象が広がります。リンクされた全組織のユーザー・ロール・グループのディレクトリ、各組織の実効設定、claude.ai上のチャット・ファイル・プロジェクト、そしてCowork・Claude Code・Claude Science・Claude for Microsoft 365のセッションまでを1つのAPI体系で扱えます。セキュリティ・法務・コンプライアンスの各部門が、アクティビティの監査、コンテンツの取得や削除、下流ツールへのイベント連携に使う仕組みです。
エンドポイントはすべてhttps://api.anthropic.comの/v1/compliance/*配下にあり、x-api-keyヘッダーで認証します。有効化とキー作成の手順はCompliance APIのセットアップとアクセスキー作成にまとめています。
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を取得できます。キーは2種類あります。claude.aiで作成するCompliance Access Keyは全エンドポイントに到達し、Claude Consoleで作成するAdmin API keyはActivity Feedのみに到達します。どちらを使うべきかは、キーの発行元と用途で決まります。単独のClaude Console組織はCompliance Access Keyを発行できません。Activity Feedより先の機能が必要になった時点で、Claude Enterpriseへの移行を検討することになります。
レスポンスに含まれるdata配列の各要素はActivityと呼ばれ、誰が何をしたかをactorフィールドで表します。このactorは種別によって持つ項目が変わる判別共用体です。サインイン済みユーザーが操作したuser_actor、顧客発行のAPIキーで呼び出されたapi_actor、Admin API keyで組織を操作したadmin_api_key_actorの3つが中心になります。ほかに、サインイン完了前の操作を表すunauthenticated_user_actor、Anthropic側の操作を表すanthropic_actor、IDプロバイダーからのSCIM同期を表すscim_directory_sync_actorもあります。読み取り側の実装は、想定外のtypeが来ても無視せず素通しする作りにしておくと安全です。新しい活動種別が追加されたときに壊れずに済みます。
Compliance APIが対応する範囲
Claude Enterpriseテナントは、アイデンティティを一元管理する親組織を1つ持ちます。そこに、2種類のリンク組織がぶら下がる構成です。ユーザーがチャット・コンテンツを扱うclaude.ai組織と、APIワークロードを管理するClaude Console組織です。親組織を対象とするキーでは、ディレクトリ系のエンドポイント(組織・ユーザー・ロール・グループ)がどちらの種類のリンク組織からもデータを返します。一方、コンテンツ系のエンドポイント(チャット・ファイル・プロジェクト・添付・セッション)はClaude Enterpriseのデータのみが対象です。
セッションのエンドポイントは2種類のトランスクリプトを返します。1つは、ユーザーの端末で動くローカルセッションです。Cowork・Claude Code・Claude Science・Claude for Microsoft 365が、Enterpriseアカウントでサインイン中に実行したものが対象になります。もう1つは、claude.aiのWeb・モバイルから起動しAnthropic管理環境のクラウドで動くリモートセッションです。親組織を持たない単独のClaude Console組織はClaude Enterpriseテナントの一部ではありません。Admin API keyでActivity Feedのみを照会できます。
全エンドポイントは親組織単位(単独のClaude Console組織なら組織単位)で、毎分600リクエストのレート制限を共有します。ローカルセッションのエンドポイントはこの共有枠だけを消費します。リモートセッションのエンドポイントは、別枠のリクエスト予算を追加で持ちます。
監査ログエクスポートとの違い
claude.aiの組織設定にある監査ログエクスポートは、OwnerやPrimary Ownerが手動でCSVをダウンロードする別機能です。取得できる期間に上限があり、フォーマットもCSV限定で、チャット・ファイル・プロジェクトの中身は含まれません。継続的にプログラムで取得したいなら、Compliance APIを標準にします。Console UIでの監査ログの読み方や項目構造はClaude監査ログの見方にまとめてあるので、手動ダウンロードで足りる場面ではそちらを参照してください。
OpenTelemetry監視との違い
Cowork・Claude Codeが対応するOpenTelemetry(OTel)ログは、個々のイベントを発生の都度、自社が運用するコレクターへストリーミングする仕組みです。トークン数・コスト・実行ホストの情報を含みます。対してCompliance APIは、Anthropic側に保持されたセッション単位のトランスクリプトを、リクエストのたびに取得する仕組みです。既存のCompliance Access Keyでそのまま使えます。OTelもプロンプト・応答の本文を記録できますが、CoworkとClaude Codeのセッション内容を取得する用途では、AnthropicはCompliance APIを推奨しています。ローカルセッション・リモートセッション・OTelログを横断した比較表はCoworkのOpenTelemetry監視設定にあります。
Inference hooksとの違い
Inference hooksはインラインで動きます。組織のAIセキュリティサーバーが、統治対象のプロンプトを推論の直前に受け取り、リアルタイムで許可か拒否かを判定する仕組みです。Compliance APIは事後に記録を取得する仕組みで、組織設定や非テキストファイル全体まで含む、より詳細なデータを返します。作動するタイミングと呼び出す方向が逆です。リクエストを推論前に止めたいならInference hooks、起きたことを事後に監査したいならCompliance API、という住み分けになります。
Analytics APIとの違い
Anthropicが提供する分析系APIには、Claude Enterprise Analytics APIとClaude Code Analytics APIの2つがあります。どちらもIT・FinOps・プラットフォームチーム向けに、利用量とコストの集計値を返します。Compliance APIが返すのはイベント単位の個別レコードで、対象読者もセキュリティ・法務・コンプライアンスの各部門です。集計値が欲しいのか個々の記録が欲しいのかで、そもそも問いの立て方が違います。キーの発行経路も別なので、両方必要な組織は別々にプロビジョニングします。
4つの仕組みをどう組み合わせて使うか
| 仕組み | 作動タイミング | 主な読者 | 向く用途 |
|---|---|---|---|
| 監査ログエクスポート | 作動タイミング事後・手動 | 主な読者Owner | 向く用途単発の証跡確認 |
| OpenTelemetry | 作動タイミングリアルタイム・自動 | 主な読者セキュリティ運用 | 向く用途異常検知・ダッシュボード |
| Inference hooks | 作動タイミングインライン・推論前 | 主な読者セキュリティ・法務 | 向く用途リクエストの遮断 |
| Compliance API | 作動タイミング事後・オンデマンド | 主な読者法務・コンプライアンス | 向く用途網羅的な監査証跡 |
4つは互いに排他ではありません。日常のアラートはOTelで拾います。統治が必要な入力はInference hooksでインラインに遮断し、インシデント発生後の正式な証跡確認と削除対応はCompliance APIで行う、という重ね方が実際の運用に近い構成です。監査ログエクスポートは、この3つを導入する前の単発確認や、Compliance APIを使うほどでもない小規模な照会に残しておく位置づけになります。どれか1つに寄せて他を切り捨てるのではなく、リアルタイム性が要る用途とオンデマンドで足りる用途を仕分けるところから設計を始めるのが実務的です。
たとえば機密情報の持ち出しをDLPポリシーで止めたい組織を考えます。まずInference hooksで危険なプロンプトをインラインに拒否し、拒否されなかった分をCompliance APIのActivity Feedで事後にレビューする、という2段構成が現実的です。OTelは、この2つとは別に、コスト超過や異常なツール呼び出し頻度をダッシュボードで検知する用途に向いています。導入の優先順位を1つに決め打ちせず、監査対象のデータがどのタイミングで必要になるかを軸に選びます。後から機能を足すたびに設計をやり直さずに済みます。
まとめ
Compliance APIは、Activity Feedを軸にチャット・ファイル・セッション・組織ディレクトリまでを1つのAPI体系でプログラムから取得する仕組みです。監査ログエクスポートより深く、OpenTelemetryより事後寄りで、Inference hooksとは作動する向きが逆になります。すでにCompliance Access Keyがある場合は、Compliance APIのActivity Feedを使うでフィルタとページネーションの具体的な使い方に進んでください。