監査ログでユーザーアクティビティをトラッキングする

W&B 監査ログを使用して、組織内のユーザーアクティビティをトラッキングし、エンタープライズガバナンス要件に準拠します。このページは、W&B デプロイメントタイプ全体で監査ログデータにアクセス、フェッチ、分析する必要がある組織レベルの管理者のためのものです。監査ログは JSON 形式で利用できます。監査ログのスキーマを参照してください。監査ログへのアクセス方法は、W&B プラットフォームのデプロイメントタイプによって異なります。

W&B プラットフォームのデプロイメントタイプ	監査ログのアクセス方法
専用クラウド	インスタンスレベルの BYOB: インスタンスレベルのバケット (BYOB) に 10 分ごとに同期されます。API でも利用できます。デフォルトのインスタンスレベルのストレージ: API でのみ利用できます。
Multi-tenant Cloud	Enterprise プランでのみ利用できます。API でのみ利用できます。
セルフマネージド	インスタンスレベルのバケットに 10 分ごとに同期されます。API でも利用できます。

監査ログをフェッチした後、Pandas、Amazon Redshift、Google BigQuery、または Microsoft Fabric などのツールで分析できます。一部の監査ログ分析ツールは JSON をサポートしていません。分析前に JSON 形式の監査ログを変換するためのガイドラインと要件については、分析ツールのドキュメントを参照してください。ログの形式の詳細については、監査ログのスキーマと action を参照してください。

監査ログの保持

以下の推奨事項は、組織のガバナンスおよびコンプライアンスの義務を満たすために監査ログを保持するのに役立ちます。

監査ログを特定の期間保持する必要がある場合、W&B では、ストレージバケットまたは Audit Logging API を使用して、定期的にログを長期保存に転送することを推奨します。
Health Insurance Portability and Accountability Act of 1996 (HIPAA) の対象となる場合、必須の保持期間が終了する前に内部または外部の行為者が削除または変更できない環境で、監査ログを最低 6 年間保持する必要があります。HIPAA 準拠の専用クラウドインスタンスで BYOB を使用する場合、管理対象ストレージ (長期保持ストレージを含む) に対してガードレールを設定する必要があります。

監査ログのスキーマ

このスキーマを使用して、各監査ログエントリで返されるフィールドを解釈します。次の表は、監査ログエントリに含まれる可能性のあるすべてのキーをアルファベット順に示しています。action や状況によっては、個々のログエントリに含まれるのは、これらのフィールドの一部のみである場合があります。

キー	定義
`action`	イベントの action。
`actor_email`	action を開始したユーザーのメールアドレス (該当する場合) 。
`actor_ip`	action を開始したユーザーの IP アドレス。
`actor_user_id`	action を実行したログイン中のユーザーの ID (該当する場合) 。
`artifact_asset`	action に関連付けられたアーティファクト ID (該当する場合) 。
`artifact_digest`	action に関連付けられたアーティファクトのダイジェスト (該当する場合) 。
`artifact_qualified_name`	action に関連付けられたアーティファクトの完全名 (該当する場合) 。
`artifact_sequence_asset`	action に関連付けられたアーティファクトシーケンス ID (該当する場合) 。
`cli_version`	action を開始した Python SDK のバージョン (該当する場合) 。
`entity_asset`	action に関連付けられた entity またはチームの ID (該当する場合) 。
`entity_name`	action に関連付けられた entity 名またはチーム名 (該当する場合) 。
`project_asset`	action に関連付けられた project (該当する場合) 。
`project_name`	action に関連付けられた project の名前 (該当する場合) 。
`report_asset`	action に関連付けられた report ID (該当する場合) 。
`report_name`	action に関連付けられた report の名前 (該当する場合) 。
`response_code`	action の HTTP 応答コード (該当する場合) 。
`timestamp`	RFC3339 形式で表したイベントの時刻。たとえば、`2023-01-23T12:34:56Z` は 2023 年 1 月 23 日 12:34:56 UTC を表します。
`user_asset`	action の影響を受けるユーザーアセット (action を実行したユーザーではありません) (該当する場合) 。
`user_email`	action の影響を受けるユーザーのメールアドレス (action を実行したユーザーのメールアドレスではありません) (該当する場合) 。

Personally identifiable information (PII)

Personally identifiable information (PII) (メールアドレスや project、チーム、report の名前など) は、API エンドポイントのオプションでのみ利用可能です：

セルフマネージドおよび専用クラウドでは、組織管理者が監査ログを取得する際に PII を除外できます。
Multi-tenant Cloud では、API エンドポイントは PII を含む監査ログの関連フィールドを常に返します。これは設定できません。

始める前に

監査ログを取得する前に、ご利用のデプロイメントタイプについて次の前提条件を満たしていることを確認してください。

監査ログを取得できるのは組織レベルの管理者です。403 エラーが返される場合は、ご自身またはサービスアカウントに適切な権限があることを確認してください。
Multi-tenant Cloud: 複数の Multi-tenant Cloud 組織のメンバーである場合は、Default API organization を設定する必要があります。この設定によって、監査ログ API の呼び出しのルーティング先が決まります。設定していない場合は、次のエラーが返されます。
user is associated with multiple organizations but no valid org ID found in user info
デフォルトの API 組織を指定するには、次の手順を実行します。
1. プロフィール画像をクリックし、User Settings をクリックします。
2. Default API organization で組織を選択します。
サービスアカウントは 1 つの Multi-tenant Cloud 組織にしか所属できないため、この設定はサービスアカウントには適用されません。

監査ログを取得する

W&B Audit Logging API を使用して監査ログを取得します。エンドポイント、クエリパラメーター、応答の形式は、デプロイメントタイプによって異なります。

Multi-tenant Cloud
専用クラウドおよびセルフマネージド

Multi-tenant Cloud の場合は、このタブを使用します。Multi-tenant の監査ログは Enterprise プランでのみ利用できます。Audit Logging API のエンドポイントは次のとおりです。

https://api.wandb.ai/audit_logs

以下のクエリパラメーターがサポートされます：

startDate: 日付範囲の最初の UTC カレンダー日。YYYY-MM-DD 形式を使用します。startDate を省略した場合、範囲は今日の UTC 午前 0 時から、または numDays を設定した場合は今日の numDays 日前から開始します。
numDays: 0 から 7 までの整数。W&B は startDate から次の numDays 日間のログを取得します。numDays を省略するか 0 に設定した場合、W&B は 1 日分のログを取得します。
limit: 返される監査ログのエントリの最大数。正の整数を最大 1,000,000 まで使用します。デフォルトは 1,000,000 です。
cursor: 前の応答の next_cursor フィールドから取得した不透明なカーソル。解決済みの同じ日付範囲でカーソルを再利用します。

Multi-tenant Cloud エンドポイントは、PII を含む監査ログの関連フィールドを常に返します。これは設定できません。応答は、以下のフィールドを持つ JSON オブジェクトです：

audit_logs: 監査ログのエントリの配列。各エントリには監査ログのスキーマで説明されているフィールドが含まれます。
range_start_time: 解決済みの日付範囲の開始時刻 (UTC) 。
range_end_time: 解決済みの日付範囲の終了時刻 (排他的、UTC) 。
count: この応答で返された監査ログのエントリの数。
next_cursor: 次の結果ページ用の不透明なカーソル。このフィールドが null の場合、選択した日付範囲にこれ以上の結果はありません。

以下の例では、以下を置き換えてください：

[BASE64-USERNAME-API-KEY]: [USERNAME]:[API-KEY] 形式の base64 エンコード文字列。
[NEXT-CURSOR]: 前の応答の next_cursor の値。

範囲の監査ログを取得するには、次のコマンドを実行します：

curl -H "Authorization: Basic [BASE64-USERNAME-API-KEY]" \
  "https://api.wandb.ai/audit_logs?startDate=2026-08-01&numDays=2&limit=1000"

応答は次の例のようになります：

{
  "audit_logs": [
    {
      "action": "project:read",
      "actor_email": "admin@example.com",
      ...
      "timestamp": "2026-08-01T13:12:14Z"
    }
  ],
  "range_start_time": "2026-08-01T00:00:00Z",
  "range_end_time": "2026-08-04T00:00:00Z",
  "count": 1,
  "next_cursor": "eyJyb3dfa2V5Ijoi..."
}

次のページを取得するには、解決済みの同じ日付範囲でリクエストを繰り返します。cursor を前の応答の next_cursor の値に設定します。next_cursor が null になるまで続けます。

curl -H "Authorization: Basic [BASE64-USERNAME-API-KEY]" \
  "https://api.wandb.ai/audit_logs?startDate=2026-08-01&numDays=2&limit=1000&cursor=[NEXT-CURSOR]"

1: Multi-tenant Cloud では、次の対象については監査ログが収集されません。

Open または Public の project。
report:read action。
特定の組織に紐付いていない User action。

このタブは専用クラウドまたはセルフマネージドインスタンスで使用します。Audit Logging API エンドポイントはインスタンスの URL を使用します：

専用クラウド: https://[INSTANCE-NAME].wandb.io/admin/audit_logs.
セルフマネージド: https://[WANDB-PLATFORM-URL]/admin/audit_logs.

以下の例では、次の値を置き換えてください。

[INSTANCE-NAME]: 専用クラウドインスタンスの名前。
[WANDB-PLATFORM-URL]: セルフマネージドインスタンスのURL。
[API-ENDPOINT]: インスタンスのエンドポイント。
[BASE64-USERNAME-API-KEY]: [USERNAME]:[API-KEY] の形式の base64 でエンコードされた文字列。
[NEXT-CURSOR]: 前の応答の next_cursor の値。

以下のクエリパラメーターがサポートされます：

anonymize: URL に anonymize=true が含まれる場合、W&B は監査ログに PII フィールドを追加しません。それ以外の場合、PII が含まれます。詳細については、監査ログの取得時に PII を除外するを参照してください。
startDate: UTC での日付範囲の開始日 (含む) 。サポートされる形式は YYYY-MM-DD、YYYY-MM-DDTHH、YYYY-MM-DDTHH:mm、YYYY-MM-DDTHH:mm:ss です。時刻部分が欠落している場合はゼロにデフォルト設定されます。たとえば、2026-08-03T01 は 2026-08-03T01:00:00Z を意味します。startDate を省略した場合、範囲は今日の UTC 午前 0 時、または numDays を設定した場合は今日から numDays 日前から開始します。
numDays: 0 以上の整数。W&B は startDate から次の numDays 日間のログを取得します。numDays を省略するか 0 に設定した場合、W&B は startDate の日のログのみを取得します。numDays は endDate と併用できません。
endDate: UTC での日付範囲の終了日 (含まない) 。サポートされる形式は startDate と一致します。endDate を設定すると、ページ分割された JSON 応答が返されます (limit を設定していなくても) 。endDate は numDays と併用できません。
limit: ページ分割された応答で返す監査ログエントリの最大数。正の整数を最大 20,000 まで指定してください。limit を設定した場合、W&B はページ分割された JSON 応答を返します。ページ分割されたリクエストでは、デフォルトは 20,000 です。
cursor: 前の応答の next_cursor フィールドから取得した不透明なカーソル。同じ解決済みの日付範囲と anonymize の値でカーソルを再利用してください。cursor を設定する場合は、limit または endDate も設定する必要があります。

limit または endDate を設定しない場合、API は元のストリーミング応答形式を保持します。応答には改行区切りの JSON オブジェクトが含まれます。各オブジェクトには、インスタンスレベルのバケットに同期されたログと同様に、監査ログのスキーマで説明されているフィールドが含まれます。3日間の範囲で改行区切りのストリーミング JSON 応答を取得し、PII を除外するには、次のコマンドを実行します:

curl -H "Authorization: Basic [BASE64-USERNAME-API-KEY]" \
  "[API-ENDPOINT]?startDate=2026-08-01&numDays=2&anonymize=true"

limit または endDate を設定した場合、API は次のフィールドを持つ JSON オブジェクトを返します。

audit_logs: 監査ログのエントリの配列。各エントリには監査ログのスキーマで説明されているフィールドが含まれます。
range_start_time: 解決済みの日付範囲の開始時刻 (UTC) 。
range_end_time: 解決済みの日付範囲の終了時刻 (排他的、UTC) 。
count: この応答で返された監査ログのエントリの数。
next_cursor: 次の結果ページ用の不透明なカーソル。このフィールドが null の場合、選択した日付範囲にこれ以上の結果はありません。

2 時間の範囲のページ分割された応答を取得するには、次のコマンドを実行します:

curl -H "Authorization: Basic [BASE64-USERNAME-API-KEY]" \
  "[API-ENDPOINT]?startDate=2026-08-01T13:00&endDate=2026-08-01T15:00&limit=1000"

応答は次の例のようになります。

{
  "audit_logs": [
    {
      "action": "project:read",
      "actor_email": "admin@example.com",
      ...
      "timestamp": "2026-08-01T14:00:00Z",
    }
  ],
  "range_start_time": "2026-08-01T13:00:00Z",
  "range_end_time": "2026-08-01T15:00:00Z",
  "count": 1,
  "next_cursor": "eyJ2ZXJzaW9uIjox..."
}

次のページを取得するには、解決済みの同じ日付範囲と anonymize の値でリクエストを繰り返します。cursor には前の応答の next_cursor の値を設定します。これを next_cursor が null になるまで続けます。

curl -H "Authorization: Basic [BASE64-USERNAME-API-KEY]" \
  "[API-ENDPOINT]?startDate=2026-08-01T13:00&endDate=2026-08-01T15:00&limit=1000&cursor=[NEXT-CURSOR]"

監査ログの取得時に PII を除外する

セルフマネージドおよび専用クラウドでは、W&B の組織管理者またはインスタンス管理者は、監査ログを取得する際に PII を除外できます。Multi-tenant Cloudでは、API エンドポイントは常に PII を含む監査ログの関連フィールドを返します。この動作は変更できません。PII を除外するには、anonymize=true の URL パラメーターを渡します。たとえば、過去 1 週間のユーザーアクティビティの監査ログを取得し、PII を除外する場合、W&B インスタンスの URL が https://mycompany.wandb.io であれば、以下のような API endpoint を使用します:

https://mycompany.wandb.io/admin/audit_logs?anonymize=true&[ADDITIONAL-PARAMETERS].

Basic 認証を使用する

監査ログ API へのリクエストは、毎回認証する必要があります。APIキーを使用した Basic 認証で監査ログ API にアクセスするには、HTTP リクエストの Authorization ヘッダーに、文字列 Basic、スペース、[USERNAME]:[API-KEY] 形式の文字列を base64 エンコードしたもの、の順に続けた値を設定します。つまり、ユーザー名と APIキーを実際の値に置き換えて : 文字で区切り、その結果を base64 エンコードします。たとえば、demo:p@55w0rd として認可する場合は、ヘッダーを Authorization: Basic ZGVtbzpwQDU1dzByZA== に設定します。

action

各監査ログエントリには、次のいずれかの action が記録されます。ログエントリ内の action フィールドを解釈する際は、このリファレンスを参照してください。次の表は、W&B が記録できる action をアルファベット順に示しています。

action	定義
`artifact:create`	アーティファクトが作成されました。
`artifact:delete`	アーティファクトが削除されました。
`artifact:read`	アーティファクトが読み取られました。
`project:delete`	project が削除されました。
`organization:update_member`	メンバーの組織ロールまたはシートが更新されました。
`project:read`	project が読み取られました。
`report:read`	report が読み取られました。 ¹
`run:delete_many`	複数の run が一括削除されました。
`run:delete`	run が削除されました。
`run:stop`	run が停止されました。
`run:undelete_many`	複数の run がゴミ箱から一括復元されました。
`run:update_many`	複数の run が一括更新されました。
`run:update`	run が更新されました。
`sweep:create_agent`	sweep エージェントが作成されました。
`team:create_service_account`	チームのサービスアカウントが作成されました。
`team:create`	チームが作成されました。
`team:delete`	チームが削除されました。
`team:invite_user`	ユーザーがチームに招待されました。
`team:uninvite`	ユーザーまたはサービスアカウントのチームへの招待が取り消されました。
`user:create_api_key`	ユーザーまたはサービスアカウントの APIキーが作成されました。 ¹
`user:create`	ユーザーが作成されました。 ¹
`user:deactivate`	ユーザーが無効化されました。 ¹
`user:delete_api_key`	ユーザーまたはサービスアカウントの APIキーが削除されました。 ¹
`user:initiate_login`	ユーザーがログインを開始しました。 ¹
`user:login`	ユーザーがログインしました。 ¹
`user:logout`	ユーザーがログアウトしました。 ¹
`user:permanently_delete`	ユーザーが完全に削除されました。 ¹
`user:reactivate`	ユーザーが再有効化されました。 ¹
`user:read`	ユーザープロフィールが読み取られました。 ¹
`user:update`	ユーザーが更新されました。 ¹

​監査ログの保持

​監査ログのスキーマ

​Personally identifiable information (PII)

​始める前に

​監査ログを取得する

​監査ログの取得時に PII を除外する

​Basic 認証を使用する

​action