Claude Media
Claude監査ログの見方 — Enterprise組織の変更履歴を追跡する

Claude監査ログの見方 — Enterprise組織の変更履歴を追跡する

Enterprise組織の監査ログをエクスポートする手順、ログの列構造とエンティティ、記録される主なイベントのカテゴリー分けをまとめます。

Claudeの監査ログは、Enterprise組織の操作履歴を過去180日分まとめて取り出す機能です。取得できるのはOrganization OwnerとPrimary Ownerで、Teamプランにはありません。ただし中身は「誰が何をしたか」の記録に限られ、チャットやプロジェクトの本文は入りません。この記事は、取りたい情報ごとの窓口の選び方から始めて、エクスポート手順、ログの列とイベントの読み方、公式のイベント一覧に見られる食い違いまでを書きます。

何を知りたいかで、取得方法は変わる

監査ログのボタンを押す前に、欲しい情報がそこにあるかを確かめます。取得方法は3つあり、対象が重なりません。

切り分け

知りたいことごとの取得方法

  • 誰がいつ何を操作したか

    Enterpriseの監査ログが窓口です。サインイン、招待、SSO設定、プロジェクトや会話の作成・削除が、時刻とIPアドレスつきで残ります。

  • 会話の中身そのもの

    監査ログには入りません。チャットの入出力は、Primary Ownerが実行するデータエクスポートで取ります。手順は組織データエクスポートの記事にあります。

  • CMEKを使っている組織

    「Export logs」ボタンが使えません。監査ログのイベントは、Compliance APIから取ります。

  • ボタンを押さずに繰り返し取りたい

    Export logsは手動の操作で、範囲は直近180日です。自分たちのツールへプログラムから取り込みたい場合は、Compliance APIが選択肢になります。

Compliance APIは、監査ログのイベントに加えて、チャットデータとファイルの内容もプログラムから取れる仕組みです。Claudeのチャットに加え、Cowork、Claude Codeも対象に含まれます。ただしClaude Codeのクラウドセッション、Amazon BedrockやGoogle Vertex AIで動かしたセッション、Claude Platform経由のClaude Codeは対象外です。EnterpriseでもPublic Sector組織は対象外です。

有効化できるのはPrimary Ownerだけで、画面はOrganization settings > APIにあります。Ownerはそのページを見られますが、オン・オフのトグルは操作できません。キーの作成はOwnerにもでき、その場合は自分の組織に限ったキーになります。Adminにはこのページ自体が表示されません。Compliance APIの設計と運用はCompliance APIの解説記事にまとまっています。

監査ログをエクスポートする手順

Enterprise組織のOwnerまたはPrimary Ownerが、Organization settings > Data and Privacyから実行します。

手順

監査ログのエクスポートの流れ

  1. 1

    Data and Privacyを開く

    Organization OwnerまたはPrimary Ownerでサインインし、Organization settingsからData and Privacyを開きます。

  2. 2

    Export logsを押す

    ボタンを押すと、組織の過去180日分のログが集約されます。即時には終わりません。

  3. 3

    メールのリンクからダウンロードする

    依頼したOwner宛てにダウンロードリンク付きのメールが届きます。リンクは24時間有効です。

集約に時間がかかる分、ボタンを押してからメールが届くまでにはラグがあります。過去180日分をボタン1回でまとめて取る形なので、常時更新されるダッシュボードのように使うことはできません。インシデント対応で証跡が急ぎなら、待ち時間を見込んで早めに押します。リンクが切れたときは、もう一度ボタンを押して取り直します。

だれがエクスポートできるか

ロールと権限の一覧表で、「Request audit logs」に印が付いているのはOwnerとPrimary Ownerです。同じ表で「Request data exports」に印が付くのはPrimary Ownerだけなので、監査ログのほうが実行できる範囲は広くなっています。

カスタムロールを使う組織では、少し判断が要ります。カスタムロールのPrivacy権限には、保持設定、エクスポート設定、データエクスポートの実行が含まれ、Data and Privacyページの表示はこの権限のViewまたはManageで決まります。一方で、Export logsボタンがこの権限で使えるかどうかは、カスタムロールのページに書かれていません。「監査ログの取得担当をOwner以外に任せられるか」は、実際にカスタムロールを付けたアカウントで画面を確かめるまで分かりません。

同じ表の中で、SSOや認証の管理(Manage SSO / auth)もOwnerとPrimary Ownerの権限です。委譲できる権限の範囲は、組織のモデルアクセス制限やClaude CoworkのRBAC運用と同じ考え方で設計します。

ログの列とエンティティ

ログの各行は、次の9列で構成されます。

列名型内容
created_at型datetime内容ログが記録された日時
actor_info型dict内容操作を行ったアクターの情報(取得できる場合)
event型AuditEventType内容イベントの種類
event_info型dict内容イベント種別ごとの付随情報
entity_info型dict内容操作の対象となったエンティティの情報
ip_address型str | None内容該当する場合のIPアドレス
device_id型str | None内容該当する場合のデバイスID
user_agent型str | None内容実行に使われたプログラムを特定するUser-Agent情報
client_platform型str | None内容モバイルのプラットフォーム(iOS・Android)情報

entity_infoは、対象の種類(type)・UUID(uuid)・名前(name)・メタデータ(metadata)という共通構造です。nameとmetadataは、取得できる場合だけ入ります。エンティティの種類は7つあり、種類ごとにメタデータの中身が違います。

typeメタデータ対象
accountメタデータemail_address対象ユーザーアカウント
inviteメタデータrole対象組織への招待
chat_projectメタデータis_private対象チャットをまとめるプロジェクト
chat_project_documentメタデータproject_uuid対象プロジェクトの知識ベースの文書
chat_conversationメタデータproject_uuid(該当する場合)対象会話。プロジェクト内でも単独でもよい
fileメタデータなし対象アップロードされたファイル
sso_connectionメタデータconnection_type / state / domains対象SSO接続

event_infoはイベントごとに中身が変わります。org_sso_toggledならSSOを必須化したかどうかのsso_enforced、org_jit_toggledならJITプロビジョニングを有効にしたかどうかのjit_provisioning_enabledが入ります。user_name_changedならold_nameとnew_nameの組です。同じevent列だけを見て判断せず、event_infoの中身まで開いて確かめると、調査の精度が上がります。

記録されるイベントと、追加された時期

一覧にあるイベントは、認証、招待、SSO・JIT・ドメイン、データエクスポート、プロジェクト・会話・ファイルの5系統です。追加された時期は3つに分かれ、後から足された系統は、その日より前のログには存在しません。

追加日

イベント系統が追加された時期

  1. 2024-09-04最初のイベント群

    サインイン、招待、プロジェクト、会話、ファイル、ドメイン、JITなど、一覧の大半がこの日付です。

  2. 2024-09-10SSO接続の3イベント

    org_sso_connection_activated・org_sso_connection_deactivated・org_sso_connection_deletedが追加されました。

  3. 2025-07-15データエクスポートの2イベント

    org_data_export_startedとorg_data_export_completedが追加されました。日付は公式の一覧では07/15/2025の形式で書かれています。

記録されるイベントの全一覧(系統別)

認証・サインイン

イベント内容と付随情報
user_signed_in_sso内容と付随情報SSO経由でサインイン(domain)
user_signed_in_google内容と付随情報Googleアカウントでサインイン(email_address)
user_signed_in_apple内容と付随情報Appleアカウントでサインイン(email_address)
user_signed_out内容と付随情報サインアウト
user_sent_phone_code内容と付随情報電話番号確認コードを送信(phone_number / channel)
user_verified_phone_code内容と付随情報確認コードで認証(phone_number / channel)
user_requested_magic_link内容と付随情報マジックリンクをリクエスト(email_address / is_successful)
user_attempted_magic_link_verification内容と付随情報マジックリンクでの認証を試行(email_address / is_successful)
user_name_changed内容と付随情報アカウント名を変更(old_name / new_name)

組織メンバー・招待管理

イベント内容と付随情報
org_user_invite_sent内容と付随情報組織への招待を送信
org_user_invite_re_sent内容と付随情報招待を再送信(invited_email_address / invited_role / invite_uuid)
org_user_invite_accepted内容と付随情報招待が承認された(invited_role)
org_user_invite_rejected内容と付随情報招待が拒否された(invited_role)
org_user_invite_deleted内容と付随情報送信済みの招待を削除(invited_email_address / invited_role)
org_user_deleted内容と付随情報組織からユーザーを削除

SSO・JIT・ドメイン設定

イベント内容と付随情報
org_sso_toggled内容と付随情報SSOの強制設定を切り替え(sso_enforced)
org_sso_add_initiated内容と付随情報SSO接続の追加を開始
org_sso_connection_activated内容と付随情報SSO接続を有効化
org_sso_connection_deactivated内容と付随情報SSO接続を無効化
org_sso_connection_deleted内容と付随情報SSO接続を削除
org_jit_toggled内容と付随情報JITを切り替え(jit_provisioning_enabled)
org_domain_add_initiated内容と付随情報ドメインの登録を開始
org_domain_verified内容と付随情報ドメインの検証が完了(domain)

データエクスポート

イベント内容と付随情報
org_data_export_started内容と付随情報組織データのエクスポートを開始(export_type / initiated_by_anthropic)
org_data_export_completed内容と付随情報エクスポートが完了(同上)

プロジェクト・会話・ファイル

イベント内容と付随情報
project_created内容と付随情報プロジェクトを作成
project_renamed内容と付随情報プロジェクト名を変更
project_visibility_changed内容と付随情報公開範囲を変更(updated_privacy)
project_deleted内容と付随情報プロジェクトを削除
project_document_created内容と付随情報ドキュメントを追加
project_document_deleted内容と付随情報ドキュメントを削除
conversation_created内容と付随情報会話を作成
conversation_renamed内容と付随情報会話名を変更(new_name)
conversation_deleted内容と付随情報会話を削除
file_uploaded内容と付随情報ファイルをアップロード

一覧を通して読むと、載っていない操作も見えてきます。ユーザーのロール変更、データ保持設定の変更、監査ログ自体のエクスポートに対応するイベントは、一覧にありません。マジックリンクは要求と検証の試行が別イベントで、成功したかどうかはis_successfulに入ります。サインインのイベントも、SSO・Google・Appleの3種です。これらの操作を追跡する前提で運用を組む場合は、実際のエクスポートに該当行が出るかを先に確かめます。

公式の一覧と実物がずれていそうな箇所

公式の一覧表には、そのまま鵜呑みにしにくい箇所があります。

  • org_user_invite_sentの対象エンティティが、招待(invite)ではなくchat_projectと書かれている。付随情報の欄も空で、同じ招待系の他のイベントと形が揃っていません
  • org_user_invite_re_sentの対象はaccountと書かれている。承認・拒否・削除はinviteなので、再送だけ別です
  • org_domain_verifiedの説明文は「Domain capture was verified」で、対応する開始側のorg_domain_add_initiatedも「Domain capture was initiated」と書かれている。イベント名は「ドメイン検証」でも、説明はドメインキャプチャです
  • 対象エンティティの欄が空欄なのはorg_sso_toggledだけ(ほかのエンティティを持たないイベントは「n/a」)

これらが表記上の誤りか、実際の出力に表れる挙動かは、公式の記述だけでは判断できません。招待の集計を作るなら、entity_info.typeを前提にせず、実データでtypeの値を確認してから条件を書きます。

ログを使う場面

セキュリティインシデントの調査では、ip_address・device_id・user_agentの3列が起点になります。見慣れないIPアドレスからのuser_signed_in_ssoやuser_signed_in_googleがないかを見て、不審な行が見つかればactor_infoから関係するアカウントを特定します。

退職者のアクセスが止まっているかの確認では、org_user_deletedと、それ以降の該当アカウントのサインインを突き合わせます。IdP側のアカウント削除と、Claude側の記録にずれがないかのクロスチェックになります。

IdPを切り替える作業では、org_sso_connection_deactivated・org_sso_connection_activated・org_domain_verifiedを時系列に並べます。どの時点で切り替わり、途中で止まった形跡がないかを追えます。切り替えの手順そのものはIdPの切り替え手順にあります。

なお、監査ログを外部に提出する場面では、ログにemail_addressやphone_numberが含まれます。組織外に渡す前に、この2つの扱いを確認します。データ共有の全体像はClaudeのビジネスデータ共有チェックリストで確認できます。

まとめ

監査ログが答えるのは「誰が、いつ、どの対象に触ったか」で、会話の本文や180日より前の履歴は別の窓口です。実行権限や個別のイベントの出方はカスタムロールと実データで確認しておくと、証跡が必要になった日に慌てません。

この記事を共有:XはてブLinkedIn