Bring your own bucket (BYOB)

このガイドは、W&B のすべてのデプロイメントタイプに適用されます。

Multi-tenant Cloud：チームレベルの BYOB
専用クラウド：インスタンスレベルおよびチームレベルの BYOB
セルフマネージド：インスタンスレベルおよびチームレベルの BYOB

このガイドで説明するバケットのプロビジョニング手順は、どのデプロイメントタイプでも共通です。

このページは W&B プラットフォームのセキュアストレージコネクタまたは BYOB 向けであり、Weave には適用されません。Weave にバイトをインポートせずに、独自のクラウドバケットに存在する画像とビデオをレンダリングするには、Weave BYOB reference を参照してください。

概要

Bring your own bucket (BYOB) を使用すると、W&B のアーティファクトやその他のセンシティブデータを、お客様独自のクラウドまたはオンプレミスのインフラストラクチャーに保存できます。専用クラウドまたは Multi-tenant Cloud の場合、お客様のバケットに保存されたデータが W&B の管理するインフラストラクチャーにコピーされることはありません。このページは、データガバナンス、データレジデンシー、またはコンプライアンスの要件を満たすために、アーティファクトのストレージの所有権を保持する必要がある W&B 管理者およびプラットフォームエンジニアを対象としています。

W&B SDK / CLI / UI とお客様のバケット間の通信には、事前署名付き URL が使用されます。
W&B は、ガベージコレクションとその関連プロセスによって、削除されたアーティファクトと run データをバケットから順次削除します。アーティファクトの削除については、アーティファクトを削除するを参照してください。専用クラウドおよびセルフマネージドのデプロイでは、削除された run データの扱いは、環境変数を設定するで説明されている GORILLA_DATA_RETENTION_PERIOD の設定にも左右されます。クリーンアップのタイミングは保証されません。バケットの使用量とコストの概要については、バケットのストレージとコストを管理するを参照してください。
バケットを設定する際にサブパスを指定すると、W&B がバケットのルート直下のフォルダーにファイルを保存しないようにできます。これにより、組織のバケットガバナンスポリシーにより確実に準拠できます。

中央データベースに保存されるデータとバケットに保存されるデータ

BYOB 機能を使用する場合、W&B は一部のタイプのデータを W&B の中央データベースに保存し、それ以外のタイプのデータをお客様のバケットに保存します。以下のリストで、W&B が管理するインフラストラクチャーに保持されるデータと、W&B がお客様自身のストレージに書き込むデータを確認してください。

データベース

W&B の中央データベースには、次のデータが保存されます。

ユーザー、チーム、アーティファクト、実験、project のメタデータ
Reports
実験のログ
システムメトリクス
コンソールログ

バケット

ストレージバケットには、次のデータが保存されます。

実験ファイルとメトリクス
アーティファクトファイル
メディアファイル
run ファイル
Parquet 形式でエクスポートされた履歴メトリクスとシステムイベント

バケットのスコープ

ストレージバケットのスコープは、次の 2 つのいずれかに設定できます。

スコープ	説明
インスタンスレベル	専用クラウドとセルフマネージドでは、組織またはインスタンス内で必要な権限を持つすべてのユーザーが、インスタンスのストレージバケットに保存されたファイルにアクセスできます。Multi-tenant Cloud には適用されません。
チームレベル	W&B チームがチームレベルのストレージバケットを使用するように設定すると、チームメンバーはそのバケットに保存されたファイルにアクセスできます。チームレベルのストレージバケットを使用すると、センシティブデータを扱うチームや厳格なコンプライアンス要件があるチームに対して、よりきめ細かなデータアクセス制御とデータ分離を実現できます。チームレベルのストレージを使用すると、インスタンスを共有する複数の事業部門や部署が、インフラストラクチャーと管理リソースを効率的に活用できます。また、顧客案件ごとにプロジェクトチームを分け、それぞれが AI ワークフローを管理することもできます。すべてのデプロイメントタイプで利用できます。チームレベル BYOB は、チームを設定する際に構成します。

この設計により、組織のニーズに応じてさまざまなストレージトポロジーをサポートできます。例:

1 つのバケットを、インスタンスと 1 つ以上のチームで共用できます。
チームごとに個別のバケットを使用する、一部のチームはインスタンスのバケットに書き込む、複数のチームがそれぞれサブパスに書き込んで 1 つのバケットを共有する、といった構成が可能です。
チームごとのバケットを異なるクラウドインフラストラクチャー環境やリージョンに配置し、それぞれ別のストレージ管理チームが管理することもできます。

たとえば、組織内に Kappa というチームがあるとします。組織 (およびチーム Kappa) は、デフォルトでインスタンスレベルのストレージバケットを使用します。次に、Omega というチームを作成し、その際にチーム Omega 用のチームレベルのストレージバケットを設定します。この場合、チーム Kappa はチーム Omega が生成したファイルにアクセスできません。一方、チーム Omega はチーム Kappa が作成したファイルにアクセスできます。チーム Kappa のデータも分離するには、チーム Kappa にもチームレベルのストレージバケットを設定する必要があります。

可用性マトリクス

始める前に、ご利用のデプロイメントタイプとストレージプロバイダーで BYOB が利用可能かどうかを確認してください。W&B は以下のストレージプロバイダーに接続できます。

CoreWeave AI Object Storage: AI ワークロード向けに最適化された、高パフォーマンスな S3互換オブジェクトストレージサービスです。
Amazon S3: スケーラビリティ、データの可用性、セキュリティ、パフォーマンスに優れたオブジェクトストレージサービスです。
Google Cloud Storage: 大規模な非構造化データを保存するためのマネージドサービスです。
Azure Blob Storage: テキスト、バイナリデータ、画像、動画、ログなど、大量の非構造化データを保存するためのクラウドベースのオブジェクトストレージソリューションです。
MinIO Enterprise (AIStor) をはじめとする、ご利用のクラウドまたはオンプレミスのインフラストラクチャーでホストされる S3互換ストレージやその他のエンタープライズグレードのソリューション。

以下の表は、W&B のデプロイメントタイプごとに、各スコープでの BYOB の可用性を示しています。

W&B デプロイメントタイプ	インスタンスレベル	チームレベル	追加情報
専用クラウド	✓	✓	インスタンスレベルおよびチームレベルの BYOB は、CoreWeave AI Object Storage、Amazon S3、Google Cloud Storage、Microsoft Azure Blob Storage、およびご利用のクラウドまたはオンプレミスのインフラストラクチャーでホストされる MinIO Enterprise (AIStor) などの S3互換ストレージでサポートされています。
Multi-tenant Cloud	該当なし	✓¹	チームレベルの BYOB は、CoreWeave AI Object Storage、Amazon S3、Google Cloud Storage でサポートされています。
セルフマネージド	✓	✓	インスタンスレベルおよびチームレベルの BYOB は、CoreWeave AI Object Storage、Amazon S3、Google Cloud Storage、Microsoft Azure Blob Storage、およびご利用のクラウドまたはオンプレミスのインフラストラクチャーでホストされる MinIO Enterprise (AIStor) などの S3互換ストレージでサポートされています。

^1.Multi-tenant Cloud のチームレベルの BYOB では、Azure Blob Storage はサポートされていません。以下のセクションでは、BYOB の設定手順について説明します。

Provision your bucket

可用性を確認したら、ストレージバケットをアクセスポリシーおよび CORS とあわせてプロビジョニングします。プロビジョニングを行うと、W&B の書き込み先となるバケットが作成され、W&B プラットフォームがユーザーに代わって事前署名付き URL を生成するために必要な権限が付与されます。続行するには、いずれかのタブを選択してください。

CoreWeave
AWS
Google Cloud
Azure
S3互換

要件：

Multi-tenant Cloud、または
専用クラウド v0.73.0 以降、または
Helm チャート v0.33.14 以降でデプロイされた セルフマネージド v0.73.0 以降
AI Object Storage が有効になっており、バケット、API アクセスキー、シークレットキーを作成する権限を持つ CoreWeave アカウント。
W&B インスタンスから CoreWeave のネットワークエンドポイントに接続できる必要があります。

詳しくは、CoreWeave ドキュメントの CoreWeave AI Object Storage バケットを作成するを参照してください。

Multi-tenant Cloud: バケットポリシーの設定に必要な組織 ID を取得します。
1. W&B App にログインします。
2. 左側のナビゲーションで Create a new team をクリックします。
3. 開いたドロワーで、Invite team members の上に表示されている W&B の組織 ID をコピーします。
4. このページは、後で W&B を設定する際に使用するため、開いたままにしておきます。
専用クラウド / セルフマネージド: バケットポリシーの設定に必要な customer namespace を取得します。
1. W&B App でユーザープロフィールアイコンをクリックし、System Console をクリックします。
2. Authentication タブをクリックします。
3. ページ下部にある Customer Namespace の値をコピーします。この値はバケットポリシーの設定に使用するので、控えておいてください。
4. System Console は閉じてかまいません。
CoreWeave で、任意の名前のバケットを希望する CoreWeave Availability Zone に作成します。必要に応じて、W&B のすべてのファイルのサブパスとして使用するフォルダーを作成します。バケット名、アベイラビリティゾーン、API アクセスキー、シークレットキー、サブパスを控えておいてください。

バケットに次のクロスオリジンリソース共有 (CORS) ポリシーを設定します。

[
  {
    "AllowedHeaders": [
      "*"
    ],
    "AllowedMethods": [
      "GET",
      "HEAD",
      "PUT"
    ],
    "AllowedOrigins": [
      "*"
    ],
    "ExposeHeaders": [
      "ETag"
    ],
    "MaxAgeSeconds": 3000
  }
]

CoreWeave のストレージは S3互換です。CORS の詳細については、AWS ドキュメントの Configuring cross-origin resource sharing (CORS) を参照してください。

W&B デプロイメントがバケットにアクセスし、事前署名付き URL を生成するのに必要な権限を付与するバケットポリシーを設定します。事前署名付き URL は、クラウドインフラストラクチャー内の AI ワークロードやユーザーのブラウザーがバケットにアクセスする際に使用します。詳しくは、CoreWeave ドキュメントの Bucket Policy Reference を参照してください。

{
  "Version": "2012-10-17",
  "Statement": [
  {
    "Sid": "AllowWandbUser",
    "Action": [
      "s3:GetObject*",
      "s3:GetEncryptionConfiguration",
      "s3:ListBucket",
      "s3:ListBucketMultipartUploads",
      "s3:ListBucketVersions",
      "s3:AbortMultipartUpload",
      "s3:DeleteObject",
      "s3:PutObject",
      "s3:GetBucketCORS",
      "s3:GetBucketLocation",
      "s3:GetBucketVersioning"
    ],
    "Effect": "Allow",
    "Resource": [
      "arn:aws:s3:::<cw-bucket>/*",
      "arn:aws:s3:::<cw-bucket>"
    ],
    "Principal": {
      "CW": "arn:aws:iam::wandb:static/<wb-cw-principal>"
    },
    "Condition": {
      "StringLike": {
        "wandb:OrgID": [
          "<wb-org-id>"
        ]
      }
    }
  },
  {
    "Sid": "AllowUsersInOrg",
    "Action": "s3:*",
    "Effect": "Allow",
    "Resource": [
      "arn:aws:s3:::<cw-bucket>",
      "arn:aws:s3:::<cw-bucket>/*"
    ],
    "Principal": {
      "CW": "arn:aws:iam::<cw-storage-org-id>:*"
    }
  }]
}

"Sid": "AllowUsersInOrg" で始まるブロックは、組織内のユーザーにバケットへの直接アクセスを許可します。このアクセスが不要な場合は、ポリシーからこのブロックを削除してもかまいません。

バケットポリシー内の次のプレースホルダーを置き換えます。
- <cw-bucket>: お使いのバケット名。
- <cw-wandb-principal>:
  - Multi-tenant Cloud: arn:aws:iam::wandb:static/wandb-integration-public
  - 専用クラウド または セルフマネージド: arn:aws:iam::wandb:static/wandb-integration
- <wb-org-id>:
  - Multi-tenant Cloud: Provision your bucket で確認した組織 ID。
  - 専用クラウド または セルフマネージド: Provision your bucket で確認したお客様の namespace。
専用クラウド: 追加の手順を完了するには、サポートにお問い合わせください。
セルフマネージド: W&B デプロイメントを更新し、環境変数 GORILLA_SUPPORTED_FILE_STORES に文字列 cw:// をそのまま設定してから、W&B を再起動してください。この設定を行わないと、チームのストレージを設定する際に CoreWeave が選択肢として表示されません。

次に、W&B を設定します。

詳細については、AWS ドキュメントの Create an S3 bucket を参照してください。

KMS キーをプロビジョニングします。 W&B では、S3 バケット上のデータの暗号化と復号に使用する KMS キーをプロビジョニングする必要があります。キーの使用タイプは ENCRYPT_DECRYPT にしてください。キーに次のポリシーを割り当てます。
{ "Version": "2012-10-17", "Statement": [ { "Sid" : "Internal", "Effect" : "Allow", "Principal" : { "AWS" : "<Your_Account_Id>" }, "Action" : "kms:*", "Resource" : "<aws_kms_key.key.arn>" }, { "Sid" : "External", "Effect" : "Allow", "Principal" : { "AWS" : "<aws_principal_and_role_arn>" }, "Action" : [ "kms:Decrypt", "kms:Describe*", "kms:Encrypt", "kms:ReEncrypt*", "kms:GenerateDataKey*" ], "Resource" : "<aws_kms_key.key.arn>" } ] }
<Your_Account_Id> と <aws_kms_key.key.arn> は、ご自身の環境に合わせて置き換えてください。 Multi-tenant Cloud または専用クラウドを使用している場合は、<aws_principal_and_role_arn> を次の対応する値に置き換えてください：
- Multi-tenant Cloud: arn:aws:iam::725579432336:role/WandbIntegration
- 専用クラウド: arn:aws:iam::830241207209:root
このポリシーにより、お客様の AWS アカウントにキーへのフルアクセスが付与されるとともに、W&B プラットフォームをホストする AWS アカウントにも必要な権限が割り当てられます。KMS キーの ARN を控えておいてください。
S3 バケットをプロビジョニングします。 AWS アカウントに S3 バケットをプロビジョニングするには、以下の手順に従います。
1. 任意の名前で S3 バケットを作成します。必要に応じて、すべての W&B ファイルを保存するサブパスとして設定できるフォルダーを作成します。
2. 前のステップで作成した KMS キーを使用して、サーバー側の暗号化を有効にします。
3. 次のポリシーで CORS を設定します。
  [ { "AllowedHeaders": [ "*" ], "AllowedMethods": [ "GET", "HEAD", "PUT" ], "AllowedOrigins": [ "*" ], "ExposeHeaders": [ "ETag" ], "MaxAgeSeconds": 3000 } ]
  オブジェクトのライフサイクル管理ポリシーによってバケット内のデータが期限切れになると、一部の run の履歴を読み取れなくなる場合があります。
4. W&B プラットフォームをホストする AWS アカウントに、必要な S3 権限を付与します。W&B プラットフォームはこれらの権限を使用して事前署名付き URLを生成します。クラウドインフラストラクチャー内の AI ワークロードやユーザーのブラウザーは、この URL を使用してバケットにアクセスします。
  { "Version": "2012-10-17", "Id": "WandBAccess", "Statement": [ { "Sid": "WAndBAccountAccess", "Effect": "Allow", "Principal": { "AWS": "<aws_principal_and_role_arn>" }, "Action" : [ "s3:GetObject*", "s3:GetEncryptionConfiguration", "s3:ListBucket", "s3:ListBucketMultipartUploads", "s3:ListBucketVersions", "s3:AbortMultipartUpload", "s3:DeleteObject", "s3:PutObject", "s3:GetBucketCORS", "s3:GetBucketLocation", "s3:GetBucketVersioning" ], "Resource": [ "arn:aws:s3:::<wandb_bucket>", "arn:aws:s3:::<wandb_bucket>/*" ] } ] }
  <wandb_bucket> を実際の値に置き換え、バケット名を控えておきます。次に、W&B を設定します。 Multi-tenant Cloud または専用クラウドを使用する場合は、<aws_principal_and_role_arn> を対応する値に置き換えます。
  - Multi-tenant Cloud の場合: arn:aws:iam::725579432336:role/WandbIntegration
  - 専用クラウドの場合: arn:aws:iam::830241207209:root

詳細については、AWS セルフマネージドホスティングガイドを参照してください。

詳細については、Google Cloud ドキュメントの Create a bucket を参照してください。

GCS バケットをプロビジョニングします。 Google Cloud プロジェクトで GCS バケットをプロビジョニングするには、次の手順に従います。
1. 任意の名前で GCS バケットを作成します。必要に応じて、W&B のすべてのファイルを保存するサブパスとして設定するフォルダーを作成します。
2. 暗号化タイプを Google-managed に設定します。
3. 論理削除を有効にします。詳しくは Edit a bucket’s soft delete policy を参照してください。
4. gsutil を使用して CORS ポリシーを設定します。この操作は UI では行えません。
  1. ローカルに cors-policy.json という名前のファイルを作成します。
  2. 次の CORS ポリシーをファイルにコピーして保存します。
    [ { "origin": ["*"], "responseHeader": ["Content-Type"], "exposeHeaders": ["ETag"], "method": ["GET", "HEAD", "PUT"], "maxAgeSeconds": 3000 } ]
    オブジェクトのライフサイクル管理ポリシーによってバケット内のデータが期限切れになると、一部の run の履歴を読み取れなくなる場合があります。
5. <bucket_name> を正しいバケット名に置き換えて、gsutil を実行します。
  gsutil cors set cors-policy.json gs://<bucket_name>
6. バケットのポリシーを確認します。<bucket_name> は正しいバケット名に置き換えてください。
  gsutil cors get gs://<bucket_name>
Multi-tenant Cloud または専用クラウドを使用している場合は、W&B プラットフォームに関連付けられた Google Cloud サービスアカウントに storage.admin ロールを付与します。W&B はこのロールを使用して、バケットの CORS 設定や、オブジェクトのバージョン管理が有効かどうかといった属性を確認します。サービスアカウントに storage.admin ロールがない場合、これらのチェックで HTTP 403 エラーが発生します。
- Multi-tenant Cloud の場合、アカウントは wandb-integration@wandb-production.iam.gserviceaccount.com です
- 専用クラウドの場合、アカウントは deploy@wandb-production.iam.gserviceaccount.com です
バケット名を控えておいてください。次に、BYOB 用に W&B を設定します。

詳細については、Azure ドキュメントの Create a blob storage container を参照してください。インスタンスレベルの BYOB:

Azure Blob Storage コンテナーをプロビジョニングします。セルフマネージドのデプロイ、およびこの Terraform モジュールを使用しない専用クラウドのデプロイメントでは、次の手順に従って Azure サブスクリプション内に Azure Blob Storage コンテナーをプロビジョニングします。
1. 任意の名前でコンテナーを作成します。必要に応じて、W&B のすべてのファイルを保存するサブパスとして設定するフォルダーを作成します。
2. コンテナーに CORS ポリシーを設定します。 UI から CORS ポリシーを設定するには、blob storage に移動し、Settings/Resource Sharing (CORS) までスクロールして、次の値を設定します。
  パラメーター値
  Allowed Origins *
  Allowed Methods GET, HEAD, PUT
  Allowed Headers *
  Exposed Headers *
  Max Age 3000
  
  オブジェクトのライフサイクル管理ポリシーによってバケット内のデータが期限切れになると、一部の run の履歴を読み取れなくなる可能性があります。
認証方式を選択します。
- ストレージアカウントキー: ストレージアカウントのアクセスキーを生成し、キーとストレージアカウント名を控えておきます。専用クラウドをご利用の組織では、安全な共有手段を使用して、これらの値を W&B のアカウントチームに伝えてください。
- ワークロードアイデンティティ: Azure マネージド ID にストレージアカウントへのアクセス権を付与し、W&B がその ID を使用するように設定します。この方式では、ストレージアカウントキーを共有する必要はありません。デプロイメントタイプに応じたワークロードアイデンティティの手順に従ってください。

パラメーター	値
Allowed Origins	`*`
Allowed Methods	`GET`, `HEAD`, `PUT`
Allowed Headers	`*`
Exposed Headers	`*`
Max Age	`3000`

チームレベル BYOB:専用クラウドのデプロイメントでは、Terraform を使用して、必要なアクセス方式と権限を備えた Azure Blob Storage コンテナーをプロビジョニングすることを W&B は推奨しています。Terraform を使用しない専用クラウドのデプロイメント、またはセルフマネージドのデプロイでは、インスタンスレベルのストレージのプロビジョニング手順に従ってバケットをプロビジョニングします。インスタンスの OIDC 発行者 URL を指定してください。以下の情報を控えておいてください。

ストレージアカウント名
ストレージコンテナー名
マネージド ID のクライアント ID
Azure テナント ID

次に、ストレージアドレスを確認します。

ストレージアドレスを決定する

バケットをプロビジョニングしたら、W&B がバケットの場所を特定して認証するためのストレージアドレスが必要です。以下のセクションでは、W&B チームを BYOB ストレージバケットに接続するための構文について説明します。例の中の山かっこ (<>) で囲まれたプレースホルダーは、お使いのバケットの情報に置き換えてください。詳しい手順については、該当するタブを選択してください。

CoreWeave
AWS
Google Cloud
Azure
S3互換

このセクションは、専用クラウドまたはセルフマネージドでのチームレベル BYOB にのみ該当します。インスタンスレベルの BYOB または Multi-tenant Cloud の場合は、このまま W&B の設定に進んでください。次の形式を使用して、完全なバケットパスを決定します。山かっこ (<>) で囲まれたプレースホルダーは、バケットの値に置き換えてください。バケットの形式:

cw://<accessKey>:<secretAccessKey>@cwobject.com/<bucketName>?tls=true

W&B は cwobject.com HTTPS エンドポイントをサポートしています。TLS 1.3 が必須です。その他の CoreWeave エンドポイントの利用をご希望の場合は、サポートまでお問い合わせください。

バケットの形式:

s3://<accessKey>:<secretAccessKey>@<s3_regional_url_endpoint>/<bucketName>?region=<region>

アドレス内の region パラメーターは必須です。ただし、W&B インスタンスとストレージバケットの両方が AWS にデプロイされており、かつ W&B インスタンスの AWS_REGION がバケットの AWS S3 リージョンと一致する場合は省略できます。

バケットの形式:

gs://<serviceAccountEmail>:<urlEncodedPrivateKey>@<bucketName>

バケットの形式:

az://:<urlEncodedAccessKey>@<storageAccountName>/<containerName>

バケットの形式:

s3://<accessKey>:<secretAccessKey>@<url_endpoint>/<bucketName>?region=<region>&tls=true

アドレス内の region パラメーターは必須です。

このセクションは、MinIO Enterprise (AIStor) や、オンプレミスでホストされるその他のエンタープライズグレードの S3 互換ソリューションなど、S3 以外でホストされている S3 互換ストレージバケットを対象としています。AWS S3 でホストされているストレージバケットについては、AWS タブを参照してください。MinIO Open Source はメンテナンスモードに移行しており、積極的な開発やコンパイル済みバイナリの提供は行われていません。本番デプロイメントには、エンタープライズグレードの S3 互換ソリューションを使用してください。S3 互換モードをオプションで備えたクラウドネイティブのストレージバケットでは、可能な限りクラウドネイティブのプロトコル指定子を使用してください。たとえば、CoreWeave バケットには s3:// ではなく cw:// を使用します。

ストレージアドレスが決まったら、チームレベル BYOB の設定に進んでください。

W&B を設定する

バケットをプロビジョニングしてそのアドレスを特定したら、インスタンスレベルまたはチームレベルで BYOB を設定できます。この最後のステップで、アーティファクト、run ファイル、その他のサイズの大きいオブジェクトをお使いのバケットに保存するよう W&B に指示します。

ストレージバケットの構成は慎重に計画してください。W&B 用にストレージバケットを設定した後で、そのデータを別のバケットに移行する作業は複雑で、W&B のサポートが必要になります。これは、専用クラウドおよびセルフマネージドのストレージだけでなく、Multi-tenant Cloud のチームレベルのストレージにも当てはまります。ご不明な点がある場合は、サポートまでお問い合わせください。

インスタンスレベルの BYOB

インスタンスレベルで CoreWeave AI Object Storage を使用する場合は、以下の手順ではなく、W&B support にお問い合わせください。セルフサービスでの設定はまだサポートされていません。

専用クラウド の場合: バケットの詳細を W&B チームに共有してください。インスタンスの設定は W&B チームが行います。Azure ワークロードアイデンティティを使用する場合は、ストレージアカウントへのアクセス権を付与したうえで、ストレージアカウント名、コンテナー名、およびパス (任意) を伝えてください。 セルフマネージド の場合は、W&B System Console でインスタンスレベルの BYOB を設定します。Azure ワークロードアイデンティティを使用する場合は、先にアイデンティティの設定を完了してください。

admin ロールを持つユーザーとして W&B にログインします。
上部のユーザーアイコンをクリックし、System Console をクリックします。
Settings > System Connections にアクセスします。
Bucket Storage で Provider を選択し、バケットの詳細を入力します。Azure の場合は Azure Blob Storage (az) を選択し、Storage account と Blob container をそれぞれ入力します。
オプション: 新しいバケットで使用する Path を入力します。
選択したプロバイダーのアイデンティティまたは認証情報に、バケットへのアクセス権があることを確認します。Azure の場合は、Authentication 方式を選択します。
- Storage account key: Storage account key を入力します。
- Workload identity (user-delegation SAS): デプロイメント管理者が設定したアイデンティティを使用します。このオプションを選択できない場合は、アイデンティティの設定を完了してください。
Save をクリックします。

保存後、W&B はインスタンスレベルで、設定したバケットを新しいアーティファクトと run ファイルのデフォルトの保存先として使用します。編集できない設定がある場合は、デプロイメント管理者にお問い合わせください。

Azure ワークロードアイデンティティを設定する

ワークロードアイデンティティを使用すると、W&B はストレージアカウントキーを使わずに Azure バケットにアクセスできます。お使いのデプロイメントタイプを選択して、セットアップ手順を確認してください。

専用クラウド
セルフマネージド

デプロイメントは W&B が設定します。お客様は Azure ストレージアカウントへのアクセスを設定してください。

W&B チームにストレージアカウントのテナント ID を伝え、使用するマネージド ID を確認します。
アイデンティティがお客様の Azure テナント内にある場合は、以降のロール割り当てにそのプリンシパル ID を使用します。そうでない場合は、お客様のテナントでマネージド ID を作成または選択し、W&B から提供された発行者、サブジェクト、オーディエンスの値を使用してフェデレーション認証情報を設定します。マネージド ID は別のテナントのストレージに直接アクセスできません。
BYOB ストレージアカウントで、ストレージアカウントのスコープにおいて、アイデンティティのプリンシパルに Reader と Storage Blob Data Contributor を付与します。
ストレージアカウント名、コンテナー名、パス (任意)、およびアイデンティティのテナント ID とクライアント ID を W&B チームに共有します。

W&B が接続を設定したら、run ファイルまたはアーティファクトをアップロードおよびダウンロードして、アクセスを検証します。

デプロイメントの管理者として、Azure と Kubernetes でワークロードアイデンティティを設定してから、System Console でワークロードアイデンティティを選択します。このワークフローでは、以下のバージョンを使用してください。

コンポーネント	必須バージョン
W&B Server	v0.84.0 以降 (ストレージにアクセスするすべてのコンポーネントを含む)
Operator Helm チャート	v0.44.13 以降
W&B System Console	認証セレクターを使用するには v2.20.0 以降

Kubernetes クラスターで OpenID Connect (OIDC) トークンフェデレーションと Azure ワークロードアイデンティティを有効にします。Azure Kubernetes Service (AKS) の場合は、Configure Microsoft Entra Workload ID の手順に従ってください。
Azure マネージド ID を作成または選択し、そのテナント ID、クライアント ID、プリンシパル ID を控えておきます。BYOB ストレージアカウントで、ストレージアカウントのスコープにおいて、そのプリンシパルに Reader と Storage Blob Data Contributor を付与します。
Helm values の global.azureStorageIdentity に、アイデンティティのテナント ID、クライアント ID、プリンシパル ID を設定します。ストレージにアクセスする Kubernetes サービスアカウントに対して、フェデレーションと azure.workload.identity/client-id アノテーションを設定します。Helm の設定の詳細については、Azure workload identity configuration を参照してください。
Console の手順に従ってワークロードアイデンティティを選択し、バケット設定を保存します。run ファイルまたはアーティファクトをアップロードおよびダウンロードして、アクセスを検証します。

チームレベル BYOB

チームレベル BYOB は、W&B アプリでチームを作成するとき、または SCIM API (オプションの storageBucket を指定した POST Groups) でチームを作成するときに設定できます。次の 2 つの方法があります。

既存のバケットを使用する: 事前にバケットのストレージの場所を確認する必要があります。
新しいバケットを作成する (Multi-tenant Cloud のみ) : チームの作成時に、W&B がクラウドプロバイダーにバケットを自動作成できます。この機能は CoreWeave、AWS、Google Cloud でサポートされています。

チームの作成後にストレージを変更することはできません。
インスタンスレベルの BYOB については、インスタンスレベルの BYOB を参照してください。
チームに CoreWeave ストレージを設定する場合は、チームの作成後にストレージの詳細を変更できないため、CoreWeave の要件を確認したうえでサポートに連絡し、CoreWeave でバケットが正しく設定されているかの確認と、チームの設定の検証を依頼してください。

続行するには、デプロイメントタイプを選択してください。

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

以前に新しいチームの作成を開始したブラウザーウィンドウに切り替えて、W&B の組織 ID を確認します。そのウィンドウがない場合は、admin ロールを持つユーザーとして W&B にログインし、左上のアイコンをクリックして左側のナビゲーションを開き、Create a team to collaborate をクリックします。
チームの名前を入力します。
Storage Type を External storage に設定します。
Bucket location をクリックします。
既存のバケットを使用するには、一覧から選択します。
新しいバケットを作成するには、下部の Add bucket をクリックし、次の操作を行います。
1. Cloud provider をクリックし、CoreWeave、AWS、または Google Cloud を選択します。
2. バケットの詳細を入力します。
  - Name: バケット名を入力します。
  - Path (オプション): バケット内で使用するサブパスを入力します。
3. 選択したクラウドプロバイダーに応じて、追加の接続設定を入力します。
  - CoreWeave: 追加の設定は不要です。
  - AWS: 必要に応じて、暗号化用の KMS key ARN を入力します。
  - Google Cloud: 追加の設定は不要です。
Create team をクリックすると、W&B は指定された設定でクラウドプロバイダーにバケットを自動的に作成します。
チームにメンバーを招待します。Invite team members に、メールアドレスをカンマ区切りで指定します。メンバーはチームの作成後に招待することもできます。
Create team をクリックします。

W&B がバケットへのアクセス中にエラーを検出した場合や、無効な設定を検出した場合は、ページ下部にエラーまたは警告が表示されます。問題がなければ、W&B によってチームが作成されます。

専用クラウド: 以降の手順でストレージバケットをチームに使用する前に、バケットパスをアカウントチームに伝え、インスタンスのサポートされるファイルストアに追加してもらう必要があります。
セルフマネージド: 以降の手順でストレージバケットをチームに使用する前に、バケットパスを GORILLA_SUPPORTED_FILE_STORES 環境変数に追加し、W&B を再起動する必要があります。
admin ロールを持つユーザーとして W&B にログインし、左上のアイコンをクリックして左側のナビゲーションを開き、Create a team to collaborate をクリックします。
チームの名前を入力します。
Storage Type を External storage に設定します。
インスタンスレベルのストレージ (内部か外部かを問わず) をチームのストレージとして使用するには、インスタンスレベルのバケットが BYOB 用に設定されている場合でも、Storage Type を Internal のままにします。チーム専用の外部ストレージを使用するには、チームの Storage Type を External に設定し、次のステップでバケットの詳細を設定します。
Bucket location をクリックします。
既存のバケットを使用するには、一覧から選択します。新しいバケットを追加するには、下部の Add bucket をクリックし、バケットの詳細を入力します。 Cloud provider をクリックし、CoreWeave、AWS、Google Cloud、または Azure を選択します。クラウドプロバイダーが一覧に表示されない場合は、Provision your bucket の手順に従って、インスタンスのサポートされるファイルストアにバケットパスを追加済みであることを確認してください。それでもストレージプロバイダーが表示されない場合は、サポートに問い合わせてください。
バケットの詳細を指定します。
- CoreWeave の場合は、バケット名のみを入力します。
- Amazon S3、Google Cloud、または S3互換ストレージの場合は、前の手順で確認した完全なバケットパスを入力します。
- W&B 専用クラウドまたはセルフマネージドで Azure を使用する場合は、Account name に Azure アカウントを、Container name に Azure Blob Storage のコンテナーを設定します。
- 必要に応じて、追加の接続設定を入力します。
  - 該当する場合は、Path にバケットのサブパスを設定します。
  - CoreWeave: 追加の接続設定は不要です。
  - AWS: KMS key ARN に KMS 暗号化キーの ARN を設定します。
  - Google Cloud: 追加の接続設定は不要です。
  - Azure: Tenant ID と Managed Identity Client ID の値を指定します。GORILLA_SUPPORTED_FILE_STORES で接続文字列を設定していない限り、これらのフィールドは必須です。
Create team をクリックします。

トラブルシューティング

バケットの検証時または接続時に W&B がエラーを報告した場合は、以下のセクションを使用して、よくある原因をストレージプロバイダー別に診断してください。

CoreWeave

このセクションでは、CoreWeave AI Object Storage への接続に関する問題のトラブルシューティングについて説明します。

接続エラー
- W&B インスタンスが CoreWeave のネットワークエンドポイントに接続できることを確認してください。
- CoreWeave では仮想ホスト形式のパスを使用します。この形式では、バケット名がパスの先頭にサブドメインとして配置されます。たとえば、cw://bucket-name.cwobject.com は正しい形式ですが、cw://cwobject.com/bucket-name/ は正しくありません。
- バケット名には、アンダースコア (_) など、DNS ルールに適合しない文字を含めることはできません。
- バケット名は、CoreWeave のすべてのロケーションを通じてグローバルに一意である必要があります。
- cw- と vip- は予約済みの接頭辞であるため、バケット名をこれらで始めることはできません。
CORS 検証の失敗
- CORS ポリシーは必須です。CoreWeave は S3互換です。CORS の詳細については、AWS ドキュメントの Configuring cross-origin resource sharing (CORS) を参照してください。
- AllowedMethods には、GET、PUT、HEAD の各メソッドを含める必要があります。
- ExposeHeaders には ETag を含める必要があります。
- CORS ポリシーの AllowedOrigins には、W&B のフロントエンドドメインを含める必要があります。このページで紹介している CORS ポリシーの例では、* を使用してすべてのドメインを許可しています。
LOTA エンドポイントの問題
- W&B は現時点では LOTA エンドポイントへの接続をサポートしていません。ご要望がある場合は、サポートにお問い合わせください。
アクセスキーと権限のエラー
- CoreWeave API のアクセスキーの有効期限が切れていないことを確認してください。
- CoreWeave API のアクセスキーとシークレットキーに、GetObject、PutObject、DeleteObject、ListBucket の必要な権限が付与されていることを確認してください。このページの例はこの要件を満たしています。詳しくは、CoreWeave ドキュメントの Create and Manage Access Keys を参照してください。

Google Cloud

このセクションでは、Google Cloud Storage への接続で発生する問題のトラブルシューティング方法を説明します。

Bucket does not have soft deletion enabled Google Cloud Storage のバケットで論理削除が有効になっていることを確認してください。詳しくは、バケットの論理削除ポリシーを編集するを参照してください。

​概要

​中央データベースに保存されるデータとバケットに保存されるデータ

​データベース

​バケット

​バケットのスコープ

​可用性マトリクス

​Provision your bucket

​ストレージアドレスを決定する

​W&B を設定する

​インスタンス レベルの BYOB

​Azure ワークロード アイデンティティを設定する

​チームレベル BYOB

​トラブルシューティング

​CoreWeave

​Google Cloud

概要

中央データベースに保存されるデータとバケットに保存されるデータ

データベース

バケット

バケットのスコープ

可用性マトリクス

Provision your bucket

ストレージアドレスを決定する

W&B を設定する

インスタンスレベルの BYOB

Azure ワークロードアイデンティティを設定する

チームレベル BYOB

トラブルシューティング

CoreWeave

Google Cloud