Claude Admin APIで監査ログは取れるか

Admin APIで直接取れるのは、組織の「いまの状態」です。誰がどのロールか、どのキーが生きているか、ワークスペースがいくつあるか。「誰が何をしたか」の記録はAdmin APIの外にあり、Compliance APIのActivity Feedが返します。同じAdmin APIキーで両方に届きますが、エンドポイントの系統は別物です。

そのため「Admin APIで監査ログを取る」という言い方は半分だけ正しい、というのがこの記事の出発点です。状態を管理する側と証跡を読む側をどうつなぐか、どのキーで何に届くか、取りこぼさない取得の組み方までを順に見ます。

Admin APIの操作は、Activity Feedにどう残るのか

Activity Feedの各エントリには、操作の主体を示すactorが付きます。種類は7つで、そのうち1つがAdmin API専用です。

残りの3つは、顧客の管理操作とは別の系統です。サインイン完了前のunauthenticated_user_actor(sso_login_initiatedなど)、Anthropic側の内部ツールを示すanthropic_actor、Anthropicの自動処理を示すsystem_actorです。

Admin APIキーを使った管理はadmin_api_key_actorとなり、admin_api_key_id・IPアドレス・User-Agentが付きます。管理系のactivity_types[]にはmember_role_changed・workspace_created・workspace_member_added・api_key_updated・org_user_deletedなどがあります。操作と型の対応は、APIリファレンスのGET /v1/compliance/activitiesにある型の一覧で確かめます。

読み取りの側も記録されます。Compliance APIを呼ぶとcompliance_api_accessedが発生し、api_actorのapi_key_idで、どのキーが引いたかまで特定できます。監査データを誰が引いたかも、監査の対象になります。

読むときの注意が3点あります。

1つ目は、user_actorが必ずしも本人の操作を意味しないことです。Anthropicがユーザーに代わって動かす処理(たとえばメモリー移行に伴うplatform_memory_created)は、現状system_actorではなくuser_actorとして出ることがあり、この帰属は変わる可能性があります。メモリー関連の活動は誰が行ってもIPアドレスが0.0.0.0になりうるので、IPだけでは人の操作と判別できません。

2つ目は、claude_chat_viewed・claude_file_viewed・claude_project_viewedのようなviewed系です。これは「人が見た」ではなく「Claudeアプリがサーバーから内容を読み込んだ」を意味し、重複排除もされません。ウェブ・デスクトップ・モバイルで読み込みのタイミングが違うため、件数はプラットフォームで変わります。閲覧回数を指標にした統制ルールは、ここで破綻します。

3つ目は、名前の欠落です。ファイル・プロジェクト文書・アーティファクトに関する活動には、名前もタイトルも入りません。2026年9月24日からfilenameとtitleは常にnull・空文字・省略のいずれかで、それ以前に記録された活動も同じ扱いです。名前が必要なら、活動に含まれるclaude_file_*などのIDを使い、Compliance Access Keyでメタデータ取得のエンドポイントを呼びます。

どのキーで何に届くのか

認証情報ごとの到達範囲を並べます。

Admin APIキー(sk-ant-admin01-で始まる)が持てるのは、read:compliance_activitiesスコープだけです。チャット本文やセッションの文字起こしを読むread:compliance_user_data、削除するdelete:compliance_user_dataは付与できず、Activity Feed以外を呼ぶと403になります。

ここに、見落としやすい条件が1つあります。Admin APIキーがこのスコープを持つのは、キーを作った時点でCompliance APIが有効になっていた場合だけです。有効化より前に作ったキーはスコープを持たないので、Activity Feedを呼ぶ鍵は有効化の後に作ったものを使います。

403のメッセージには、キーが持つスコープとエンドポイントが求めるスコープが並びます。

{
  "error": {
    "type": "permission_error",
    "message": "Missing required scopes. Got: ['read:compliance_activities'] Needed one of: ['read:compliance_user_data', 'read:org_audit']"
  }
}

手元のキーが何者か分からなくなったら、プレフィックスで見分けられます。sk-ant-admin01-はAdmin APIキー、sk-ant-api01-はCompliance Access Keyです。ConsoleのSettings > Admin keysやclaude.aiのOrganization settings > APIにあるScopes列でも確かめられます。

フルのコンプライアンス機能が必要な組織向けには、Compliance Access Keyが別にあります。スコープは作成後に変えられないため、読み取りと削除は2本のキーに分けるのが公式の推奨です。使い分けはCompliance APIのセットアップとアクセスキー作成に、Activity Feed以外の取得手順はCompliance APIで組織のユーザーとグループを取得する手順にあります。

単体のConsole組織でActivity Feedを引くまで

Claude Enterpriseの親組織を持たない単体のClaude Console組織は、Compliance Access Keyを作れません。Admin APIキーでActivity Feedを引く構成になり、手順は3段です。

# Compliance APIへのアクセス自体を抽出する(Admin APIキーでも呼べる)
curl --fail-with-body -sS -G \
  "https://api.anthropic.com/v1/compliance/activities" \
  --data-urlencode "activity_types[]=compliance_api_accessed" \
  --data-urlencode "created_at.gte=2026-10-01T00:00:00Z" \
  --header "x-api-key: $ANTHROPIC_ADMIN_KEY" \
  --header "anthropic-version: 2023-06-01"

Claude Enterpriseの親組織はClaude Consoleに現れず、Admin APIキーも持ちません。この場合はclaude.aiのOrganization settings > APIで、主所有者がCompliance APIを有効にしてCompliance Access Keyを作ります。親組織向けのキーなら、配下のリンク済み組織すべてのActivity Feedを横断して読めます。

Admin APIが管理できる対象と、届かない対象

Admin APIが扱うのは次の5系統です。

• 組織メンバーとロール
• 組織への招待
• ワークスペースとワークスペースメンバー
• APIキー(照会・改名・有効/無効の切り替えのみ)
• サービスアカウント・federation issuer・federation rule(org:adminのOAuthトークンのみ)

個人アカウントでは使えず、ConsoleのSettings > Organizationで組織を立てる必要があります。組織ロールは5段階で、adminは上の4ロールの権限をすべて含みます。

Organization Owner・Primary Ownerはadminの全権限に加えて、adminの管理もできます。

「Admin APIで全部賄える」とは言えない点が3つあります。

1つ目は、サービスアカウントとfederation関連のエンドポイントです。org:adminのOAuthトークンでしか届かず、Admin APIキー1本の構成からは外れます。

2つ目は、提供形態による差です。Claude Enterprise(claude.ai)の組織は、claude.aiで作ったスコープ付きAPIキーでAdmin APIを呼び、使えるのはメンバーと招待のエンドポイントです。Enterprise限定のグループとカスタムロールの読み取り、支出上限は追加で使えますが、ワークスペースやAPIキーの管理は含まれません。Claude Platform on AWSでは逆に、ワークスペースと外部キー(CMEK用)のエンドポイントだけが使え、メンバー・招待・APIキーは使えません。

3つ目は、Admin APIでできないことです。新規APIキーは作成できず、できるのは既存キーの照会・改名・有効無効の切り替えまで。adminロールのメンバーも削除できません。

# 組織メンバー一覧(ロールの現状スナップショット用)
curl "https://api.anthropic.com/v1/organizations/users?limit=10" \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01"

APIキーの一覧には、キーごとにprincipal(個人キーならuser_actor、サービスアカウントキーならservice_account_actor、ワークスペースキーならnull)とscope(workspaceまたはorganization)が付きます。トップレベルのworkspace_idは非推奨で、デフォルトワークスペースのキーとワークスペース指定のないキーはどちらもnullになるため、区別はscopeで行います。workspace_idでフィルタしても、ワークスペース指定のないキーは返りません。キーの取得とスコープ選択はClaude Admin APIキーの取得方法とスコープ選択、ワークスペース側の実装はClaude Admin APIでワークスペース管理を実装するにまとめています。

内部統制の証跡を、2段構成で組む

要件を3つに割ると、それぞれが担える範囲が見えます。

• Admin APIで足りる: ロールの現状スナップショットと前回との差分 / expires_atによる失効漏れの検知 / 未使用ワークスペースの洗い出し / 古い招待の棚卸し
• Activity Feedで足りる: activity_types[]での特定操作の抽出 / actorのIP・User-Agentによる発生源の特定 / 認証系・管理系の時系列
• Compliance Access Keyが要る: チャット・ファイル・プロジェクトの中身の監査 / セッション文字起こしの取得 / 個別チャットの削除

Admin APIのスナップショットだけでは、ロールが変わったことは分かっても誰が変えたかが欠けます。Activity Feedだけでは、操作の履歴はあっても、いまの状態が正しいかを判定する基準がありません。前者を「あるべき状態の台帳」、後者を「実際に起きた操作の記録」として突き合わせると、変更履歴と現状が整合しているかを検証できます。

Enterpriseの管理画面で見られる監査ログはClaude監査ログの見方で扱っています。この2段構成は、そのUIの内容を外部SIEMへ定期転送したいときの実装経路にあたります。

取りこぼさずに引くための窓の切り方

Activity Feedの取得で実際に事故が起きるのは、時間窓の境界です。公式の設計ガイドが挙げる数値を先に並べます。

窓で定期的に引く場合は、created_at.ltを現在時刻の1分以上前に置きます。1分は「推奨」ではなく、インデックスの遅延として扱われています。窓の上限が現在に近すぎると、遅れて索引された活動が静かに、しかも永久に取りこぼされます。created_at.gteが先へ進んだ後では、どの窓からも拾えなくなるためです。

窓をタイル状に切るときは、前の窓のltを次の窓のgteにそのまま使います。そのうえで活動のidで重複を除き、窓を数分重ねるか、古い窓を定期的に引き直す照合を足します。

カーソルで読む構成では、最新側へ進むループをbefore_idとfirst_idで回し、has_moreがfalseになってからカーソルを保存します。has_moreがtrueの段階で保存すると、間にある新しいページが未取得のまま残ります。失敗したリクエストは位置を進めないので、同じカーソルで再試行できます。

レート上限の600/分は、/v1/compliance/*のすべてのエンドポイントと、親組織の配下のすべてのキー・リンク済み組織が共有します。SIEM連携と手作業の調査を同じ組織で同時に回すと、互いの枠を食い合います。

運用で踏みやすい落とし穴

OAuthトークンまわりが最初のつまずきどころです。

• トークンの期限切れに気づかない: org:adminの対話ログインで得たトークンは短命です。401が返ったら、export ANTHROPIC_AUTH_TOKEN=$(ant auth print-credentials --profile admin --access-token)を再実行して更新します。この更新手順を、スクリプトの側にも組み込んでおきます
• ANTHROPIC_API_KEYとANTHROPIC_AUTH_TOKENが同居する: OAuthトークンを使うシェルではANTHROPIC_API_KEYは空文字ではなく未設定(unset)のままにします。未設定なら、SDKやCLIはベアラートークンを送ります
• 招待の有効期限は変えられない: 招待は21日で失効し、期間の設定変更はできません。長期休暇でオンボーディングが遅れそうなときは、再送を前提に設計します

退職者対応では、キー種別で寿命の切れ方が変わります。個人キーはユーザーが組織から削除された時点で止まります。サービスアカウントキーは、サービスアカウントをアーカイブしない限り、作成者が組織を離れても動き続けます。

ワークスペースAPIキーは、通常のワークスペースではメンバーの在籍と無関係に動作し続けるため、個人キーだけを止めても別途の棚卸しが要ります。Claude Codeワークスペースのキーだけは発行したメンバーに紐づき、そのメンバーの削除とともに止まります。

まとめ

Admin APIは組織の状態を読み書きする道具で、操作の証跡はActivity Feedにあります。監査の仕組みを作るなら、Compliance APIを有効にした日と、その後にAdmin APIキーを作る順序、時間窓の切り方の3点が、後から直しにくい設計上の分かれ目です。