DatadogでClaudeの監査ログを見る — APIキー作成と認証イベントのモニター

DatadogにClaudeの監査ログを入れると何が見えるか

Datadogの「Claude Compliance」インテグレーションは、AnthropicのCompliance APIが返す監査アクティビティをDatadogのログとして取り込みます。取り込まれたログにはsource:claude-compliance-logsのタグが付き、Log Explorerでそのまま検索できます。

Datadogのドキュメントが挙げる用途は5つです。

• SSOのサインインと認証イベントの監視
• Admin・Platform・ScopedのAPIキーについて、作成・削除・スコープ更新の追跡
• メンバー招待・ロール変更・ワークスペース更新といったAnthropic Console操作の監査
• チャットの閲覧やプロジェクトへのアクセスなど、Claude利用の監査レベルでの調査
• 同梱のCloud SIEM検出ルールによるセキュリティ上重要なイベントの検知

ログ1件には、created_at(マイクロ秒精度のタイムスタンプ)、操作した主体(ユーザー・APIキー・SCIM・システム)、type、組織とワークスペースの文脈が入ります。主体のメールアドレス・ユーザーID・IPアドレス・User-Agentは該当するときに付きます。種類は150以上、カテゴリは35以上です。

取り込み側のパイプラインは、主体のオブジェクトをusr.*とnetwork.client.*の標準属性に展開し、送信元IPにGeoIPを、User-Agent文字列に解析を加えます。「どの国のIPから管理者キーが作られたか」をクエリだけで絞れるのはこのためです。

Compliance APIそのものの全体像はClaude Compliance APIとはにあります。取り込みパイプラインを自作する場合の設計はCompliance APIのSIEM連携が扱っています。この記事は、Datadogが用意した取り込みの口を使って、最短でモニターまで届く道筋に絞ります。

始める前に確認する前提と、公式ページ同士の食い違い

前提は3つです。ここで、Datadog側とAnthropic側の説明に差があるので先に触れます。

Datadogのドキュメントは前提に「Anthropicのエンタープライズプランの契約」と「Anthropic Organization settingsのData and privacyでCompliance APIを有効化していること」を挙げます。一方、Claudeのヘルプセンターは、同じDatadogを「Claude Platformの監査ログを取り込み、管理操作・APIキーのライフサイクル・認証イベントを可視化する」と紹介しています。Compliance API自体は「Claude EnterpriseとClaude Platformの顧客が使える」とされ、Platformでの利用はAnthropicの営業チームへの問い合わせが入口です。

Datadogの手順に沿って組織設定を探すなら、自分の契約がどちらに当たるかを先に確かめておくと迷いません。DatadogのOverviewにある「チャットの閲覧」「プロジェクトアクセス」「ファイル操作」はEnterprise側のイベントです。Platformだけの契約では、APIキー・メンバー・ワークスペース・認証まわりのイベントが中心になると読むのが自然です。

三つ目の前提はキーです。次のどちらかを使います。

Admin APIキーは、Compliance APIを有効にした後に作ったものだけがread:compliance_activitiesを持ちます。有効化の前から使っている管理者キーを流用すると、403になることがあります。スコープの選び方とキーの作り方はCompliance APIのセットアップとアクセスキー作成に詳しく書いてあります。

4ステップで取り込みを始める

Datadog側の操作は貼り付けて保存するだけです。手間がかかるのはAnthropic側の準備です。

Datadogに貼る前に、キー自体がActivity Feedを読めるか手元で確かめておくと、あとの切り分けが楽になります。Compliance APIのエンドポイントはGET /v1/compliance/activitiesです。1件だけ取る確認用のコマンドを示します。

curl --fail-with-body -sS -G \
  "https://api.anthropic.com/v1/compliance/activities" \
  --header "x-api-key: $ANTHROPIC_ADMIN_KEY" \
  --header "anthropic-version: 2023-06-01" \
  --data-urlencode "limit=1"

HTTP 200でJSONが返ればキーは使えます。403なら、Compliance APIの有効化とスコープを疑います。この確認はDatadogの外で行えるので、画面側のエラーより原因を絞りやすくなります。

Log Explorerで見る3つの検索クエリ

取り込みが動いたら、モニターを置く前に検索で件数を眺めます。普段どれくらい出るイベントかを知らないまま閾値を決めると、通知が鳴りっぱなしになるか、永遠に鳴らないかのどちらかになります。

Datadogのドキュメントが例に出すevt.nameは、Compliance APIのアクティビティtypeと同じ文字列です。次の3本が出発点になります。@evt.nameとするのは、ログ属性を検索するためのDatadogの書き方です。

Anthropic側のAPIリファレンスには、APIキーまわりの種別が複数あります。管理者キーはadmin_api_key_created・admin_api_key_deleted・admin_api_key_updated、スコープ付きキーはscoped_api_key_deleted・scoped_api_key_updated、Platformのキーはplatform_api_key_created・platform_api_key_updatedです。名前にplatform_が付くものはPlatform側のイベントで、App Attestによる認証のplatform_app_attest_authenticationや、ワークロードID連携のplatform_federation_rule_createdもここに含まれます。

APIキーの種類ごとの違いはClaude APIの認証方式まとめで整理しています。

モニターに載せる価値が高いイベント

どのイベントにモニターを置くかは、「起きたら誰かが必ず確認すべきか」で決めます。次の表は、ドキュメントに載っている種別から選んだ検討用の例です。閾値と通知先は、組織の運用に合わせて決めます。

compliance_api_accessedは、Compliance APIを呼び出した事実そのものの記録です。取り込みに使っているキー自身の呼び出しも出るため、モニターでは取り込み用のキーを除外します。

モニターの作成そのものはDatadogの標準機能なので、この記事では何を検知対象にするかの設計に絞ります。

最初から全部を通知にする必要はありません。次の順で広げると、運用側が追いつきやすくなります。

取れないものと、つまずきやすい点

もう一点、Platformのイベントに会話内容が無いのは仕様です。Datadogで「誰がAPIキーを作ったか」は追えても、「そのキーでどんなプロンプトが送られたか」は追えません。後者が必要なら、アプリ側の記録か、利用形態に応じた別の仕組みを検討します。

閲覧系のイベントは数え方にも注意が要ります。claude_chat_viewedのようなイベントは、人が画面を見た回数ではなく、Claudeアプリがサーバーから内容を読み込んだ記録です。閲覧回数をモニターにするのは向きません。この性質はCompliance APIのSIEM連携に詳しく書いてあります。

Admin APIで取れる範囲との違いは、Claude Admin APIで監査ログは取れるかにあります。Admin APIキーを使ってCompliance APIのActivity Feedだけを読める、という関係です。

Datadogの外側で決めておくこと

取り込みを始める前に、運用側で決めておく項目があります。

• キーの保管先と持ち主。Admin APIキーはCompliance Activity以外の管理機能にも使えるので、取り込み専用のキーを分けるかどうかを決めます
• ログの保持期間。Anthropic側はアクティビティを6年保持しますが、Datadog側の保持は契約とインデックス設定次第です
• 通知の宛先。作成系は組織のセキュリティ担当へ、失敗系は運用チームへ、のように分けます

最初の1週間は通知を絞り、admin_api_key_createdと認証失敗の回数だけを見ます。そのあとで、使っている機能(ワークロードID連携やManaged Agentsなど)に対応する種別を足していくと、ノイズを抑えたまま範囲を広げられます。