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

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

W&B Platform deployment type	Audit logs access mechanism
専用クラウド	Instance-level BYOB: 10 分ごとにインスタンスレベルのバケット (BYOB) に同期されます。API でも利用できます。デフォルトのインスタンスレベルストレージ: API でのみ利用できます。
Multi-tenant Cloud	Enterprise プランでのみ利用できます。API でのみ利用できます。
セルフマネージド	10 分ごとにインスタンスレベルのバケットに同期されます。API でも利用できます。

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

監査ログの保持

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

監査ログを一定期間保持する必要がある場合、W&B では、storage buckets または Audit Logging API を使用して、ログを長期ストレージに定期的に転送することを推奨します。
1996年医療保険の携行性と責任に関する法律 (HIPAA) の適用対象である場合、監査ログは、法令で義務付けられた保持期間が終了するまで、社内外のいかなる関係者も削除または変更できない環境で、少なくとも 6 年間保持する必要があります。BYOB を使用する HIPAA 準拠の専用クラウドインスタンスでは、長期保持用ストレージを含む管理対象ストレージに対するガードレールを設定する必要があります。

監査ログスキーマ

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

Key	Definition
`action`	イベントのアクション。
`actor_email`	該当する場合、アクションを開始したユーザーのメールアドレス。
`actor_ip`	アクションを開始したユーザーの IP アドレス。
`actor_user_id`	該当する場合、アクションを実行したログイン中のユーザーの ID。
`artifact_asset`	該当する場合、アクションに関連付けられたアーティファクト ID。
`artifact_digest`	該当する場合、アクションに関連付けられたアーティファクト digest。
`artifact_qualified_name`	該当する場合、アクションに関連付けられたアーティファクトの完全修飾名。
`artifact_sequence_asset`	該当する場合、アクションに関連付けられたアーティファクト sequence ID。
`cli_version`	該当する場合、アクションを開始した Python SDK のバージョン。
`entity_asset`	該当する場合、アクションに関連付けられた entity またはチーム ID。
`entity_name`	該当する場合、アクションに関連付けられた entity またはチーム名。
`project_asset`	該当する場合、アクションに関連付けられたプロジェクト。
`project_name`	該当する場合、アクションに関連付けられたプロジェクト名。
`report_asset`	該当する場合、アクションに関連付けられたレポート ID。
`report_name`	該当する場合、アクションに関連付けられたレポート名。
`response_code`	該当する場合、アクションに対する HTTP レスポンスコード。
`timestamp`	RFC3339 format 形式のイベント発生時刻。たとえば、`2023-01-23T12:34:56Z` は 2023 年 1 月 23 日 12:34:56 UTC を表します。
`user_asset`	該当する場合、アクションを実行したユーザーではなく、そのアクションの影響を受けるユーザーの asset。
`user_email`	該当する場合、アクションを実行したユーザーのメールアドレスではなく、そのアクションの影響を受けるユーザーのメールアドレス。

個人を特定できる情報 (PII)

メールアドレスやプロジェクト、Teams、Reports の名前などの個人を特定できる情報 (PII) は、API endpoint オプションでのみ利用できます:

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

始める前に

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

組織レベルの管理者は監査ログを取得できます。403 エラーが返される場合は、ご自身またはサービスアカウントに十分な権限があることを確認してください。
Multi-tenant Cloud: 複数の Multi-tenant Cloud 組織に所属している場合、監査ログ API 呼び出しの送信先を決定する Default API organization を必ず設定する必要があります。設定しないと、次のエラーが表示されます。
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

このタブは専用クラウドまたはセルフマネージドのインスタンス向けです。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 です。省略された時刻部分は 0 として扱われます。たとえば、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 を設定すると、limit を設定していなくてもページ分割された JSON レスポンスが返されます。endDate は numDays と併用できません。
limit: ページ分割されたレスポンスで返す監査ログエントリの最大数です。20,000 までの正の整数を指定してください。limit を設定すると、W&B はページ分割された JSON レスポンスを返します。ページ分割されたリクエストでのデフォルトは 20,000 です。
cursor: 前回のレスポンスの next_cursor フィールドで返された不透明なカーソルです。カーソルを再利用する際は、解決済みの日付範囲と anonymize の値を前回と同じにしてください。cursor を設定する場合は、limit または endDate も設定する必要があります。

limit または endDate を設定しない場合、API は元のストリーミングレスポンス形式を維持します。レスポンスには、改行区切りの JSON オブジェクトが含まれます。各オブジェクトには Audit log schema に記載のフィールドが含まれ、instance-level bucket に同期されるログと同じ内容になります。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: 監査ログエントリの配列です。各エントリには Audit log schema に記載されているフィールドが含まれます。
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 を除外する

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

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

このタブは Multi-tenant Cloud 向けです。Multi-tenant の監査ログは Enterprise プランでのみ利用可能です。Audit Logging API endpoint は次のとおりです。

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: 監査ログエントリの配列。各エントリには Audit log schema に記載のフィールドが含まれます。
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

基本認証を使用する

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

アクション

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

Action	Definition
`artifact:create`	アーティファクトが作成されます。
`artifact:delete`	アーティファクトが削除されます。
`artifact:read`	アーティファクトが閲覧されます。
`project:delete`	プロジェクトが削除されます。
`organization:update_member`	メンバーの組織ロールまたはシートが更新されます。
`project:read`	プロジェクトが閲覧されます。
`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 agent が作成されます。
`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`	ユーザーが更新されます。 ¹

Weights & Biases

CoreWeave 提供

プラットフォームの詳細

リソース

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

監査ログの保持

監査ログスキーマ

個人を特定できる情報 (PII)

始める前に

監査ログを取得する

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

基本認証を使用する

アクション

​監査ログの保持

​監査ログスキーマ

​個人を特定できる情報 (PII)

​始める前に

​監査ログを取得する

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

​基本認証を使用する

​アクション

監査ログの保持

監査ログスキーマ

個人を特定できる情報 (PII)

始める前に

監査ログを取得する

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

基本認証を使用する

アクション