Claude Admin APIで監査ログは取れるか
Admin APIは組織メンバー・ワークスペース・APIキーを操作するAPIで、監査ログそのものは別のCompliance API Activity Feedが担います。両者の役割分担と内部統制での組み合わせ方をまとめます。
Admin APIは組織のメンバー・ワークスペース・招待・APIキーをプログラムで管理するAPIです。「Admin APIで監査ログを取る」という発想は半分正しく半分違います。組織の状態(誰がどのロールか、どのキーが生きているか)を管理する機能と、誰が何をしたかの証跡(監査ログ)を取得する機能は、別のエンドポイント系統だからです。同じAdmin APIキーで両方に届きますが、仕組みは別物です。管理と証跡、この2軸で読み替えてください。
Admin APIが管理する対象と、管理できない対象
Admin APIが扱うのは次の5系統です。
- 組織メンバーとロール
- 組織への招待
- ワークスペースとワークスペースメンバー
- APIキー(照会・改名・有効/無効の切り替えのみ)
- サービスアカウント・federation issuer・federation rule(
org:adminのOAuthトークンのみで到達可能)
個人アカウントでは利用できず、チームでの協業を始めるにはConsoleのSettings > Organizationで組織を立てる必要があります。組織ロールは5段階で、権限は上位ロールが下位を包含します。
| ロール | 権限 |
|---|---|
| user | 権限Playgroundの利用のみ |
| claude_code_user | 権限Playground + Claude Codeの利用 |
| developer | 権限Playground + APIキーの管理 |
| billing | 権限Playground + 請求情報の管理 |
| admin | 権限上記すべて + ユーザー管理 |
Organization Owner・Primary Ownerはadminの全権限に加え、admin自体の管理も行えます。ロールの一覧は組織メンバー向けの権限設計で、federation issuer・federation ruleを扱うサービスアカウント関連のエンドポイントだけはorg:adminのOAuthトークンでしか到達できません。Admin APIキー1本ですべてを賄いたい場合、この一群だけは届きません。例外として設計に組み込む対象です。
見落としやすいのはAdmin APIでは新規APIキーを作成できないという制約です。APIキーの発行はConsoleでの操作に限られ、Admin APIでできるのは既存キーの照会・改名・有効/無効切り替えまでです。同様に、adminロールのメンバーはAdmin APIから削除できません。
# 組織メンバー一覧を取得(developerロールが自分でAPIキーを発行できる立場かを確認する用途など)
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のトップレベルフィールドは非推奨化されており、キーがどのワークスペースに紐づくかはscopeで判定する設計に変わっています。取得方法の詳細はClaude Admin APIキーの取得方法とスコープ選択、ワークスペース管理の実装はClaude Admin APIでワークスペース管理を実装するで扱っています。
「誰が何をしたか」はCompliance API Activity Feedが担う
組織の状態を管理するAdmin APIに対し、操作の証跡(認証・チャット・ファイル・プロジェクト・管理操作・プラットフォーム活動)を時系列で追うのはCompliance APIのActivity Feedエンドポイントです。ここが「Admin APIで監査ログ化する」という発想のズレどころで、正確にはAdmin APIキーという同じ認証情報を使って、Compliance APIのActivity Feedエンドポイントを呼ぶという構造になっています。
| 目的 | 使うエンドポイント | 使えるキー |
|---|---|---|
| メンバー・ワークスペース・APIキーの状態管理 | 使うエンドポイントAdmin API(/v1/organizations/*) | 使えるキーAdmin APIキー / org:adminトークン / 個人・サービスアカウントキー |
| 「誰が・いつ・何をしたか」の時系列証跡 | 使うエンドポイントCompliance API Activity Feed(/v1/compliance/activities) | 使えるキーAdmin APIキー(Activity Feedのみ)/ Compliance Access Key(全エンドポイント) |
| チャット・ファイル・セッション文字起こしの取得・削除 | 使うエンドポイントCompliance APIのその他のエンドポイント | 使えるキーCompliance Access Keyのみ |
Admin APIキーはread:compliance_activitiesスコープを持つため、Activity Feedの参照はできます。ただしチャット本文やセッションの文字起こしを取得・削除する権限(read:compliance_user_data・delete:compliance_user_data)は持ちません。フルのコンプライアンス機能が必要な組織は、claude.aiの組織設定で発行するCompliance Access Keyが別途必要になります。この使い分けはCompliance APIのセットアップとアクセスキー作成に詳しく、Activity Feedの取得手順自体はCompliance APIで組織のユーザーとグループを取得する手順とあわせて確認すると全体像がつかめます。
Admin APIだけで内部統制の証跡化がどこまで進むか
「Admin APIで組織のClaude利用を監査ログ化する」という要件を、実装できる範囲とできない範囲に分けます。
- できる: メンバーのロール変更履歴を自前でスナップショット取得し差分管理する / APIキーの
expires_atを定期的に取得し失効漏れを検知する / ワークスペース一覧を棚卸しして未使用ワークスペースを洗い出す / Activity Feedをactivity_types[]でフィルタして特定の操作(招待作成、ロール変更など)だけを抽出する - できない(Compliance Access Keyが必要): チャット・ファイル・プロジェクトの内容そのものを監査対象にする / セッションの文字起こしを取得する / ユーザーの個別チャット削除を行う
内部統制の実務では、①Admin APIでメンバー・キー・ワークスペースの「あるべき状態」を定期スナップショットし、②Compliance API Activity Feedで「実際に起きた操作」を時系列で突き合わせる、という2段構成が現実的です。①だけでは「誰が変更したか」が欠け、②だけでは「今の状態が正しいか」の判定基準がありません。両方を組み合わせて初めて、変更履歴と現状の整合性を検証できる証跡になります。
Claude Enterpriseの管理画面から見られる監査ログUIについてはClaude監査ログの見方で扱っています。本記事のAdmin API経由の取得は、そのUIの内容をプログラムから定期取得・外部SIEMへ転送したい場合の実装経路にあたります。
なお、Claude Enterpriseのテナントでは親組織の下に複数のリンク済み組織(claude.aiの組織とClaude Consoleの組織)がぶら下がる構成が取られます。親組織を対象にしたCompliance Access Keyであれば配下の全組織のActivity Feedを横断的に読めますが、単体のClaude Console組織(親組織を持たない組織)はAdmin APIキーでActivity Feedのみを参照する構成に固定され、フルのCompliance APIへは拡張できません。組織のガバナンス構造をどちらの形態にするかは、監査ログの一元化をどこまで求めるかによって選択が変わる論点です。
ベストプラクティスとよくある落とし穴
公式ドキュメントが挙げるベストプラクティスは次の5点です。
- ワークスペースとAPIキーにわかりやすい名前・説明を付ける
- 操作失敗時のエラーハンドリングを行う
- メンバーのロールと権限を定期的に監査する
- 未使用のワークスペースと期限切れの招待を掃除する
- APIキーの利用状況を監視し、
expires_atを確認し、定期的にローテーションする
実装で踏みやすい落とし穴は次の3つです。
- OAuthトークンの有効期限切れに気づかない:
org:adminスコープの対話ログインで得たトークンは短命です。401が返ってきたらant auth print-credentialsで再発行する運用を、スクリプト側にも組み込んでおきます ANTHROPIC_API_KEYとANTHROPIC_AUTH_TOKENが同一シェルで衝突する: OAuthトークンを使うときはANTHROPIC_API_KEYを空にしておかないと、SDKがどちらを送るか意図通りになりません- 招待の有効期限は変更できない: 組織招待は21日で自動失効し、この期間は設定変更できません。長期休暇でオンボーディングが遅れる運用では、再送前提の設計にします
APIキーが失効した後の挙動もキー種別によって変わります。個人キーはユーザーが組織から削除された時点で使えなくなり、サービスアカウントキーはサービスアカウント自体をアーカイブしない限り、発行者が組織を離れても動き続けます。ワークスペースAPIキーは通常のワークスペースと、Claude Codeワークスペースとで挙動が分かれます。通常のワークスペースAPIキーはメンバーの在籍状況と無関係に動作し続け、退職者対応で個人キーだけを止めても別途棚卸しが必要です。一方Claude Codeワークスペースのキーは発行したメンバーに紐づき、そのメンバーが組織から削除されると停止します。同じ「ワークスペースキー」でも寿命の切れ方が違います。
まとめ
Admin APIは組織メンバー・ワークスペース・APIキーを管理するAPIであり、「誰が何をしたか」の時系列証跡そのものはCompliance APIのActivity Feedが担います。同じAdmin APIキーでActivity Feedの参照までは届きますが、チャット内容の取得・削除などフルのコンプライアンス機能にはCompliance Access Keyが別途必要です。内部統制の証跡として使うなら、Admin APIで組織の「あるべき状態」を定期取得し、Activity Feedで「実際に起きた操作」を突き合わせる2段構成が実務的な落としどころになります。Activity Feedは有効化前の活動をバックフィルしません。統制設計の前提です。