> ## Documentation Index > Fetch the complete documentation index at: https://docs.coreweave.com/llms.txt > Use this file to discover all available pages before exploring further. # Bring your own bucket (BYOB) > Bring Your Own Bucket (BYOB) 機能を使用すると、W&B のアーティファクトやデータをお客様独自のクラウドストレージバケットに保存できます。 **このガイドは、W\&B のすべてのデプロイメントタイプに適用されます。** * **Multi-tenant Cloud**：チームレベルの BYOB * **専用クラウド**：インスタンスレベルおよびチームレベルの BYOB * **セルフマネージド**：インスタンスレベルおよびチームレベルの BYOB このガイドで説明するバケットのプロビジョニング手順は、どのデプロイメントタイプでも共通です。 このページは W\&B プラットフォームのセキュアストレージコネクタまたは BYOB 向けであり、Weave には適用されません。Weave にバイトをインポートせずに、独自のクラウドバケットに存在する画像とビデオをレンダリングするには、[Weave BYOB reference](/ja/products/wandb/weave/guides/tracking/byob-references#reference-media-in-your-own-bucket-byob-using-weave-op) を参照してください。

概要

Bring your own bucket (BYOB) を使用すると、W\&B のアーティファクトやその他のセンシティブデータを、お客様独自のクラウドまたはオンプレミスのインフラストラクチャーに保存できます。[専用クラウド](/ja/products/wandb/platform/hosting/hosting-options/dedicated-cloud)または [Multi-tenant Cloud](/ja/products/wandb/platform/hosting/hosting-options/multi_tenant_cloud) の場合、お客様のバケットに保存されたデータが W\&B の管理するインフラストラクチャーにコピーされることはありません。このページは、データガバナンス、データレジデンシー、またはコンプライアンスの要件を満たすために、アーティファクトのストレージの所有権を保持する必要がある W\&B 管理者およびプラットフォームエンジニアを対象としています。 * W\&B SDK / CLI / UI とお客様のバケット間の通信には、[事前署名付き URL](/ja/products/wandb/platform/hosting/data-security/presigned-urls) が使用されます。 * W\&B は、ガベージコレクションとその関連プロセスによって、削除された**アーティファクト**と **run データ**をバケットから順次削除します。アーティファクトの削除については、[アーティファクトを削除する](/ja/products/wandb/artifacts/delete-artifacts)を参照してください。専用クラウドおよびセルフマネージドのデプロイでは、削除された run データの扱いは、[環境変数を設定する](/ja/products/wandb/platform/hosting/env-vars)で説明されている `GORILLA_DATA_RETENTION_PERIOD` の設定にも左右されます。クリーンアップのタイミングは保証されません。バケットの使用量とコストの概要については、[バケットのストレージとコストを管理する](/ja/products/wandb/platform/hosting/managing-bucket-storage)を参照してください。 * バケットを設定する際にサブパスを指定すると、W\&B がバケットのルート直下のフォルダーにファイルを保存しないようにできます。これにより、組織のバケットガバナンスポリシーにより確実に準拠できます。

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

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

データベース

W\&B の中央データベースには、次のデータが保存されます。 * ユーザー、チーム、アーティファクト、実験、project のメタデータ * Reports * 実験のログ * システムメトリクス * コンソールログ

バケット

ストレージバケットには、次のデータが保存されます。 * 実験ファイルとメトリクス * アーティファクトファイル * メディアファイル * run ファイル * Parquet 形式でエクスポートされた履歴メトリクスとシステムイベント

バケットのスコープ

ストレージバケットのスコープは、次の 2 つのいずれかに設定できます。 | スコープ | 説明 | | - | - | | インスタンスレベル | [専用クラウド](/ja/products/wandb/platform/hosting/hosting-options/dedicated-cloud) と [セルフマネージド](/ja/products/wandb/platform/hosting/hosting-options/self-managed) では、組織またはインスタンス内で必要な権限を持つすべてのユーザーが、インスタンスのストレージバケットに保存されたファイルにアクセスできます。[Multi-tenant Cloud](/ja/products/wandb/platform/hosting/hosting-options/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](/products/storage/object-storage): AI ワークロード向けに最適化された、高パフォーマンスな S3互換オブジェクトストレージサービスです。 * [Amazon S3](https://aws.amazon.com/s3/): スケーラビリティ、データの可用性、セキュリティ、パフォーマンスに優れたオブジェクトストレージサービスです。 * [Google Cloud Storage](https://cloud.google.com/storage): 大規模な非構造化データを保存するためのマネージドサービスです。 * [Azure Blob Storage](https://azure.microsoft.com/en-us/products/storage/blobs): テキスト、バイナリデータ、画像、動画、ログなど、大量の非構造化データを保存するためのクラウドベースのオブジェクトストレージソリューションです。 * [MinIO Enterprise (AIStor)](https://min.io/product/aistor) をはじめとする、ご利用のクラウドまたはオンプレミスのインフラストラクチャーでホストされる S3互換ストレージやその他のエンタープライズグレードのソリューション。 以下の表は、W\&B のデプロイメントタイプごとに、各スコープでの BYOB の可用性を示しています。 | W\&B デプロイメントタイプ | インスタンスレベル | チームレベル | 追加情報 | | - | - | - | - | | 専用クラウド | ✓ | ✓ | インスタンスレベルおよびチームレベルの BYOB は、CoreWeave AI Object Storage、Amazon S3、Google Cloud Storage、Microsoft Azure Blob Storage、およびご利用のクラウドまたはオンプレミスのインフラストラクチャーでホストされる [MinIO Enterprise (AIStor)](https://www.min.io/product/aistor) などの S3互換ストレージでサポートされています。 | | Multi-tenant Cloud | 該当なし | ✓1 | チームレベルの 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)](https://www.min.io/product/aistor) などの S3互換ストレージでサポートされています。 | 1.Multi-tenant Cloud のチームレベルの BYOB では、Azure Blob Storage はサポートされていません。 以下のセクションでは、BYOB の設定手順について説明します。

Provision your bucket

[可用性を確認](#availability-matrix)したら、ストレージバケットをアクセスポリシーおよび CORS とあわせてプロビジョニングします。プロビジョニングを行うと、W\&B の書き込み先となるバケットが作成され、W\&B プラットフォームがユーザーに代わって事前署名付き URL を生成するために必要な権限が付与されます。続行するには、いずれかのタブを選択してください。 **要件**： * **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 バケットを作成する](/products/storage/object-storage/buckets/create-bucket) を参照してください。 1. **Multi-tenant Cloud**: バケットポリシーの設定に必要な組織 ID を取得します。 1. [W\&B App](https://wandb.ai/site) にログインします。 2. 左側のナビゲーションで **Create a new team** をクリックします。 3. 開いたドロワーで、**Invite team members** の上に表示されている W\&B の組織 ID をコピーします。 4. このページは、後で [W\&B を設定する](#configure-byob)際に使用するため、開いたままにしておきます。 2. **専用クラウド** / **セルフマネージド**: バケットポリシーの設定に必要な customer namespace を取得します。 1. W\&B App でユーザープロフィールアイコンをクリックし、**System Console** をクリックします。 2. **Authentication** タブをクリックします。 3. ページ下部にある **Customer Namespace** の値をコピーします。この値はバケットポリシーの設定に使用するので、控えておいてください。 4. System Console は閉じてかまいません。 3. CoreWeave で、任意の名前のバケットを希望する CoreWeave Availability Zone に作成します。必要に応じて、W\&B のすべてのファイルのサブパスとして使用するフォルダーを作成します。バケット名、アベイラビリティゾーン、API アクセスキー、シークレットキー、サブパスを控えておいてください。 4. バケットに次のクロスオリジンリソース共有 (CORS) ポリシーを設定します。 ```json theme={"system"} [ { "AllowedHeaders": [ "*" ], "AllowedMethods": [ "GET", "HEAD", "PUT" ], "AllowedOrigins": [ "*" ], "ExposeHeaders": [ "ETag" ], "MaxAgeSeconds": 3000 } ] ``` CoreWeave のストレージは S3互換です。CORS の詳細については、AWS ドキュメントの [Configuring cross-origin resource sharing (CORS)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/enabling-cors-examples.html) を参照してください。 5. W\&B デプロイメントがバケットにアクセスし、[事前署名付き URL](/ja/products/wandb/platform/hosting/data-security/presigned-urls) を生成するのに必要な権限を付与するバケットポリシーを設定します。事前署名付き URL は、クラウドインフラストラクチャー内の AI ワークロードやユーザーのブラウザーがバケットにアクセスする際に使用します。詳しくは、CoreWeave ドキュメントの [Bucket Policy Reference](/products/storage/object-storage/auth-access/bucket-access/bucket-policies) を参照してください。 ```json theme={"system"} { "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:::/*", "arn:aws:s3:::" ], "Principal": { "CW": "arn:aws:iam::wandb:static/" }, "Condition": { "StringLike": { "wandb:OrgID": [ "" ] } } }, { "Sid": "AllowUsersInOrg", "Action": "s3:*", "Effect": "Allow", "Resource": [ "arn:aws:s3:::", "arn:aws:s3:::/*" ], "Principal": { "CW": "arn:aws:iam:::*" } }] } ``` `"Sid": "AllowUsersInOrg"` で始まるブロックは、組織内のユーザーにバケットへの直接アクセスを許可します。このアクセスが不要な場合は、ポリシーからこのブロックを削除してもかまいません。 6. バケットポリシー内の次のプレースホルダーを置き換えます。 * ``: お使いのバケット名。 * ``: * **Multi-tenant Cloud**: `arn:aws:iam::wandb:static/wandb-integration-public` * **専用クラウド** または **セルフマネージド**: `arn:aws:iam::wandb:static/wandb-integration` * ``: * **Multi-tenant Cloud**: [Provision your bucket](#coreweave-org-id) で確認した組織 ID。 * **専用クラウド** または **セルフマネージド**: [Provision your bucket](#coreweave-customer-namespace) で確認したお客様の namespace。 7. **専用クラウド**: 追加の手順を完了するには、[サポート](mailto:forge-support@coreweave.com)にお問い合わせください。 8. **セルフマネージド**: W\&B デプロイメントを更新し、環境変数 `GORILLA_SUPPORTED_FILE_STORES` に文字列 `cw://` をそのまま設定してから、W\&B を再起動してください。この設定を行わないと、チームのストレージを設定する際に CoreWeave が選択肢として表示されません。 次に、[W\&B を設定します](#configure-byob)。 詳細については、AWS ドキュメントの [Create an S3 bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html) を参照してください。 1. KMS キーをプロビジョニングします。 W\&B では、S3 バケット上のデータの暗号化と復号に使用する KMS キーをプロビジョニングする必要があります。キーの使用タイプは `ENCRYPT_DECRYPT` にしてください。キーに次のポリシーを割り当てます。 ```json theme={"system"} { "Version": "2012-10-17", "Statement": [ { "Sid" : "Internal", "Effect" : "Allow", "Principal" : { "AWS" : "" }, "Action" : "kms:*", "Resource" : "" }, { "Sid" : "External", "Effect" : "Allow", "Principal" : { "AWS" : "" }, "Action" : [ "kms:Decrypt", "kms:Describe*", "kms:Encrypt", "kms:ReEncrypt*", "kms:GenerateDataKey*" ], "Resource" : "" } ] } ``` `` と `` は、ご自身の環境に合わせて置き換えてください。 [Multi-tenant Cloud](/ja/products/wandb/platform/hosting/hosting-options#w%26b-multi-tenant-cloud) または [専用クラウド](/ja/products/wandb/platform/hosting/hosting-options#w%26b-dedicated-cloud) を使用している場合は、`` を次の対応する値に置き換えてください： * **Multi-tenant Cloud**: `arn:aws:iam::725579432336:role/WandbIntegration` * **専用クラウド**: `arn:aws:iam::830241207209:root` このポリシーにより、お客様の AWS アカウントにキーへのフルアクセスが付与されるとともに、W\&B プラットフォームをホストする AWS アカウントにも必要な権限が割り当てられます。KMS キーの ARN を控えておいてください。 2. S3 バケットをプロビジョニングします。 AWS アカウントに S3 バケットをプロビジョニングするには、以下の手順に従います。 1. 任意の名前で S3 バケットを作成します。必要に応じて、すべての W\&B ファイルを保存するサブパスとして設定できるフォルダーを作成します。 2. 前のステップで作成した KMS キーを使用して、サーバー側の暗号化を有効にします。 3. 次のポリシーで CORS を設定します。 ```json theme={"system"} [ { "AllowedHeaders": [ "*" ], "AllowedMethods": [ "GET", "HEAD", "PUT" ], "AllowedOrigins": [ "*" ], "ExposeHeaders": [ "ETag" ], "MaxAgeSeconds": 3000 } ] ``` [オブジェクトのライフサイクル管理ポリシー](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html)によってバケット内のデータが期限切れになると、一部の run の履歴を読み取れなくなる場合があります。 4. W\&B プラットフォームをホストする AWS アカウントに、必要な S3 権限を付与します。W\&B プラットフォームはこれらの権限を使用して[事前署名付き URL](/ja/products/wandb/platform/hosting/data-security/presigned-urls)を生成します。クラウドインフラストラクチャー内の AI ワークロードやユーザーのブラウザーは、この URL を使用してバケットにアクセスします。 ```json theme={"system"} { "Version": "2012-10-17", "Id": "WandBAccess", "Statement": [ { "Sid": "WAndBAccountAccess", "Effect": "Allow", "Principal": { "AWS": "" }, "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:::", "arn:aws:s3:::/*" ] } ] } ``` `` を実際の値に置き換え、バケット名を控えておきます。次に、[W\&B を設定](#configure-byob)します。 [Multi-tenant Cloud](/ja/products/wandb/platform/hosting/hosting-options/multi_tenant_cloud) または[専用クラウド](/ja/products/wandb/platform/hosting/hosting-options/dedicated-cloud)を使用する場合は、`` を対応する値に置き換えます。 * [Multi-tenant Cloud](/ja/products/wandb/platform/hosting/hosting-options/multi_tenant_cloud) の場合: `arn:aws:iam::725579432336:role/WandbIntegration` * [専用クラウド](/ja/products/wandb/platform/hosting/hosting-options/dedicated-cloud)の場合: `arn:aws:iam::830241207209:root` 詳細については、[AWS セルフマネージドホスティングガイド](/ja/products/wandb/platform/hosting/hosting-options)を参照してください。 詳細については、Google Cloud ドキュメントの [Create a bucket](https://docs.cloud.google.com/storage/docs/creating-buckets) を参照してください。 1. GCS バケットをプロビジョニングします。 Google Cloud プロジェクトで GCS バケットをプロビジョニングするには、次の手順に従います。 1. 任意の名前で GCS バケットを作成します。必要に応じて、W\&B のすべてのファイルを保存するサブパスとして設定するフォルダーを作成します。 2. 暗号化タイプを `Google-managed` に設定します。 3. 論理削除を有効にします。詳しくは [Edit a bucket's soft delete policy](https://docs.cloud.google.com/storage/docs/use-soft-delete) を参照してください。 4. `gsutil` を使用して CORS ポリシーを設定します。この操作は UI では行えません。 1. ローカルに `cors-policy.json` という名前のファイルを作成します。 2. 次の CORS ポリシーをファイルにコピーして保存します。 ```json theme={"system"} [ { "origin": ["*"], "responseHeader": ["Content-Type"], "exposeHeaders": ["ETag"], "method": ["GET", "HEAD", "PUT"], "maxAgeSeconds": 3000 } ] ``` [オブジェクトのライフサイクル管理ポリシー](https://cloud.google.com/storage/docs/lifecycle)によってバケット内のデータが期限切れになると、一部の run の履歴を読み取れなくなる場合があります。 5. `` を正しいバケット名に置き換えて、`gsutil` を実行します。 ```bash theme={"system"} gsutil cors set cors-policy.json gs:// ``` 6. バケットのポリシーを確認します。`` は正しいバケット名に置き換えてください。 ```bash theme={"system"} gsutil cors get gs:// ``` 2. [Multi-tenant Cloud](/ja/products/wandb/platform/hosting/hosting-options/multi_tenant_cloud) または[専用クラウド](/ja/products/wandb/platform/hosting/hosting-options/dedicated-cloud)を使用している場合は、W\&B プラットフォームに関連付けられた Google Cloud サービスアカウントに `storage.admin` ロールを付与します。W\&B はこのロールを使用して、バケットの CORS 設定や、オブジェクトのバージョン管理が有効かどうかといった属性を確認します。サービスアカウントに `storage.admin` ロールがない場合、これらのチェックで HTTP 403 エラーが発生します。 * [Multi-tenant Cloud](/ja/products/wandb/platform/hosting/hosting-options/multi_tenant_cloud) の場合、アカウントは `wandb-integration@wandb-production.iam.gserviceaccount.com` です * [専用クラウド](/ja/products/wandb/platform/hosting/hosting-options/dedicated-cloud)の場合、アカウントは `deploy@wandb-production.iam.gserviceaccount.com` です バケット名を控えておいてください。次に、[BYOB 用に W\&B を設定](#configure-byob)します。 詳細については、Azure ドキュメントの [Create a blob storage container](https://learn.microsoft.com/en-us/azure/storage/blobs/blob-containers-portal) を参照してください。 **インスタンス レベルの BYOB**: 1. Azure Blob Storage コンテナーをプロビジョニングします。 セルフマネージドのデプロイ、および [この Terraform モジュール](https://github.com/wandb/terraform-azurerm-wandb/tree/main/examples/byob) を使用しない専用クラウドのデプロイメントでは、次の手順に従って 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` | [オブジェクトのライフサイクル管理ポリシー](https://learn.microsoft.com/en-us/azure/storage/blobs/lifecycle-management-policy-configure?tabs=azure-portal) によってバケット内のデータが期限切れになると、一部の run の履歴を読み取れなくなる可能性があります。 2. 認証方式を選択します。 * **ストレージ アカウント キー**: ストレージ アカウントのアクセスキーを生成し、キーとストレージ アカウント名を控えておきます。専用クラウドをご利用の組織では、安全な共有手段を使用して、これらの値を W\&B のアカウントチームに伝えてください。 * **ワークロード アイデンティティ**: Azure マネージド ID にストレージ アカウントへのアクセス権を付与し、W\&B がその ID を使用するように設定します。この方式では、ストレージ アカウント キーを共有する必要はありません。[デプロイメントタイプに応じたワークロード アイデンティティの手順](#set-up-azure-workload-identity) に従ってください。 **チームレベル BYOB**: 専用クラウドのデプロイメントでは、[Terraform](https://github.com/wandb/terraform-azurerm-wandb/tree/main/examples/secure-storage-connector) を使用して、必要なアクセス方式と権限を備えた Azure Blob Storage コンテナーをプロビジョニングすることを W\&B は推奨しています。Terraform を使用しない専用クラウドのデプロイメント、またはセルフマネージドのデプロイでは、インスタンス レベルのストレージのプロビジョニング手順に従ってバケットをプロビジョニングします。インスタンスの OIDC 発行者 URL を指定してください。以下の情報を控えておいてください。 * ストレージ アカウント名 * ストレージ コンテナー名 * マネージド ID のクライアント ID * Azure テナント ID S3互換バケットを作成します。次の情報を控えておいてください。 * アクセスキー * シークレットアクセスキー * エンドポイント URL * バケット名 * フォルダーパス (該当する場合) * リージョン 次に、[ストレージアドレスを確認します](#determine-the-storage-address)。

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

バケットをプロビジョニングしたら、W\&B がバケットの場所を特定して認証するためのストレージアドレスが必要です。以下のセクションでは、W\&B チームを BYOB ストレージバケットに接続するための構文について説明します。例の中の山かっこ (`<>`) で囲まれたプレースホルダーは、お使いのバケットの情報に置き換えてください。詳しい手順については、該当するタブを選択してください。 このセクションは、**専用クラウド**または**セルフマネージド**でのチームレベル BYOB にのみ該当します。インスタンス レベルの BYOB または Multi-tenant Cloud の場合は、このまま [W\&B の設定](#configure-byob)に進んでください。 次の形式を使用して、完全なバケットパスを決定します。山かっこ (`<>`) で囲まれたプレースホルダーは、バケットの値に置き換えてください。 **バケットの形式**: ```text theme={"system"} cw://:@cwobject.com/?tls=true ``` W\&B は `cwobject.com` HTTPS エンドポイントをサポートしています。TLS 1.3 が必須です。その他の CoreWeave エンドポイントの利用をご希望の場合は、[サポート](mailto:forge-support@coreweave.com)までお問い合わせください。 **バケットの形式**: ```text theme={"system"} s3://:@/?region= ``` アドレス内の `region` パラメーターは必須です。ただし、W\&B インスタンスとストレージバケットの両方が AWS にデプロイされており、かつ W\&B インスタンスの `AWS_REGION` がバケットの AWS S3 リージョンと一致する場合は省略できます。 **バケットの形式**: ```text theme={"system"} gs://:@ ``` **バケットの形式**: ```text theme={"system"} az://:@/ ``` **バケットの形式**: ```text theme={"system"} s3://:@/?region=&tls=true ``` アドレス内の `region` パラメーターは必須です。 このセクションは、[MinIO Enterprise (AIStor)](https://www.min.io/product/aistor) や、オンプレミスでホストされるその他のエンタープライズグレードの S3 互換ソリューションなど、S3 以外でホストされている S3 互換ストレージバケットを対象としています。AWS S3 でホストされているストレージバケットについては、**AWS** タブを参照してください。 MinIO Open Source は[メンテナンスモード](https://github.com/minio/minio)に移行しており、積極的な開発やコンパイル済みバイナリの提供は行われていません。本番デプロイメントには、エンタープライズグレードの S3 互換ソリューションを使用してください。 S3 互換モードをオプションで備えたクラウドネイティブのストレージバケットでは、可能な限りクラウドネイティブのプロトコル指定子を使用してください。たとえば、CoreWeave バケットには `s3://` ではなく `cw://` を使用します。 ストレージアドレスが決まったら、[チームレベル BYOB の設定](#configure-team-level-byob)に進んでください。

W\&B を設定する

[バケットをプロビジョニング](#provision-your-bucket)して[そのアドレスを特定](#determine-the-storage-address)したら、[インスタンスレベル](#instance-level-byob)または[チームレベル](#team-level-byob)で BYOB を設定できます。この最後のステップで、アーティファクト、run ファイル、その他のサイズの大きいオブジェクトをお使いのバケットに保存するよう W\&B に指示します。 ストレージバケットの構成は慎重に計画してください。W\&B 用にストレージバケットを設定した後で、そのデータを別のバケットに移行する作業は複雑で、W\&B のサポートが必要になります。これは、専用クラウドおよびセルフマネージドのストレージだけでなく、Multi-tenant Cloud のチームレベルのストレージにも当てはまります。ご不明な点がある場合は、[サポート](mailto:forge-support@coreweave.com)までお問い合わせください。

インスタンス レベルの BYOB

インスタンス レベルで CoreWeave AI Object Storage を使用する場合は、以下の手順ではなく、[W\&B support](mailto:forge-support@coreweave.com) にお問い合わせください。セルフサービスでの設定はまだサポートされていません。 **専用クラウド** の場合: バケットの詳細を W\&B チームに共有してください。インスタンスの設定は W\&B チームが行います。Azure ワークロード アイデンティティを使用する場合は、[ストレージ アカウントへのアクセス権を付与](#set-up-azure-workload-identity)したうえで、ストレージ アカウント名、コンテナー名、およびパス (任意) を伝えてください。 **セルフマネージド** の場合は、W\&B System Console でインスタンス レベルの BYOB を設定します。Azure ワークロード アイデンティティを使用する場合は、先に [アイデンティティの設定](#set-up-azure-workload-identity) を完了してください。 1. `admin` ロールを持つユーザーとして W\&B にログインします。 2. 上部のユーザーアイコンをクリックし、**System Console** をクリックします。 3. **Settings** > **System Connections** にアクセスします。 4. **Bucket Storage** で **Provider** を選択し、バケットの詳細を入力します。Azure の場合は **Azure Blob Storage (az)** を選択し、**Storage account** と **Blob container** をそれぞれ入力します。 5. オプション: 新しいバケットで使用する **Path** を入力します。 6. 選択したプロバイダーのアイデンティティまたは認証情報に、バケットへのアクセス権があることを確認します。Azure の場合は、**Authentication** 方式を選択します。 * **Storage account key**: **Storage account key** を入力します。 * **Workload identity (user-delegation SAS)**: デプロイメント管理者が設定したアイデンティティを使用します。このオプションを選択できない場合は、[アイデンティティの設定](#set-up-azure-workload-identity) を完了してください。 7. **Save** をクリックします。 保存後、W\&B はインスタンス レベルで、設定したバケットを新しいアーティファクトと run ファイルのデフォルトの保存先として使用します。 編集できない設定がある場合は、デプロイメント管理者にお問い合わせください。

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

ワークロード アイデンティティを使用すると、W\&B はストレージアカウントキーを使わずに Azure バケットにアクセスできます。お使いのデプロイメントタイプを選択して、セットアップ手順を確認してください。 デプロイメントは W\&B が設定します。お客様は Azure ストレージアカウントへのアクセスを設定してください。 1. W\&B チームにストレージアカウントのテナント ID を伝え、使用するマネージド ID を確認します。 2. アイデンティティがお客様の Azure テナント内にある場合は、以降のロール割り当てにそのプリンシパル ID を使用します。そうでない場合は、お客様のテナントでマネージド ID を作成または選択し、W\&B から提供された発行者、サブジェクト、オーディエンスの値を使用してフェデレーション認証情報を設定します。マネージド ID は[別のテナントのストレージに直接アクセスできません](https://learn.microsoft.com/en-us/entra/identity/managed-identities-azure-resources/managed-identities-faq#can-i-use-a-managed-identity-to-access-a-resource-in-a-different-directorytenant)。 3. BYOB ストレージアカウントで、ストレージアカウントのスコープにおいて、アイデンティティのプリンシパルに **Reader** と **Storage Blob Data Contributor** を付与します。 4. ストレージアカウント名、コンテナー名、パス (任意)、およびアイデンティティのテナント ID とクライアント ID を W\&B チームに共有します。 W\&B が接続を設定したら、run ファイルまたはアーティファクトをアップロードおよびダウンロードして、アクセスを検証します。 デプロイメントの管理者として、Azure と Kubernetes でワークロード アイデンティティを設定してから、System Console でワークロード アイデンティティを選択します。 このワークフローでは、以下のバージョンを使用してください。 | コンポーネント | 必須バージョン | | - | - | | W\&B Server | v0.84.0 以降 (ストレージにアクセスするすべてのコンポーネントを含む) | | Operator Helm チャート | [v0.44.13](https://github.com/wandb/helm-charts/releases/tag/operator-wandb-0.44.13) 以降 | | W\&B System Console | 認証セレクターを使用するには [v2.20.0](https://github.com/wandb/console/releases/tag/v2.20.0) 以降 | 1. Kubernetes クラスターで OpenID Connect (OIDC) トークンフェデレーションと Azure ワークロード アイデンティティを有効にします。Azure Kubernetes Service (AKS) の場合は、[Configure Microsoft Entra Workload ID](https://learn.microsoft.com/en-us/azure/aks/workload-identity-deploy-cluster) の手順に従ってください。 2. Azure マネージド ID を作成または選択し、そのテナント ID、クライアント ID、プリンシパル ID を控えておきます。BYOB ストレージアカウントで、ストレージアカウントのスコープにおいて、そのプリンシパルに **Reader** と **Storage Blob Data Contributor** を付与します。 3. Helm values の `global.azureStorageIdentity` に、アイデンティティのテナント ID、クライアント ID、プリンシパル ID を設定します。ストレージにアクセスする Kubernetes サービスアカウントに対して、フェデレーションと `azure.workload.identity/client-id` アノテーションを設定します。Helm の設定の詳細については、[Azure workload identity configuration](https://github.com/wandb/helm-charts/blob/operator-wandb-0.44.13/charts/operator-wandb/README.md#azure-managed-storage-workload-identity) を参照してください。 4. [Console の手順](#instance-level-byob)に従ってワークロード アイデンティティを選択し、バケット設定を保存します。run ファイルまたはアーティファクトをアップロードおよびダウンロードして、アクセスを検証します。

チームレベル BYOB

チームレベル BYOB は、W\&B アプリでチームを作成するとき、または [SCIM API](/ja/products/wandb/platform/hosting/iam/scim#create-team) (オプションの `storageBucket` を指定した POST Groups) でチームを作成するときに設定できます。次の 2 つの方法があります。 * **既存のバケットを使用する**: 事前にバケットの[ストレージの場所を確認する](#determine-the-storage-address)必要があります。 * **新しいバケットを作成する** (Multi-tenant Cloud のみ) : チームの作成時に、W\&B がクラウドプロバイダーにバケットを自動作成できます。この機能は CoreWeave、AWS、Google Cloud でサポートされています。 - チームの作成後にストレージを変更することはできません。 - インスタンスレベルの BYOB については、[インスタンス レベルの BYOB](#instance-level-byob) を参照してください。 - チームに CoreWeave ストレージを設定する場合は、チームの作成後にストレージの詳細を変更できないため、[CoreWeave の要件](#coreweave-requirements)を確認したうえで [サポート](mailto:forge-support@coreweave.com) に連絡し、CoreWeave でバケットが正しく設定されているかの確認と、チームの設定の検証を依頼してください。 続行するには、デプロイメントタイプを選択してください。 1. 以前に新しいチームの作成を開始したブラウザーウィンドウに切り替えて、W\&B の組織 ID を確認します。そのウィンドウがない場合は、`admin` ロールを持つユーザーとして W\&B にログインし、左上のアイコンをクリックして左側のナビゲーションを開き、**Create a team to collaborate** をクリックします。 2. チームの名前を入力します。 3. **Storage Type** を **External storage** に設定します。 4. **Bucket location** をクリックします。 5. 既存のバケットを使用するには、一覧から選択します。 6. 新しいバケットを作成するには、下部の **Add bucket** をクリックし、次の操作を行います。 1. **Cloud provider** をクリックし、**CoreWeave**、**AWS**、または **Google Cloud** を選択します。 2. バケットの詳細を入力します。 * **Name**: バケット名を入力します。 * **Path** (オプション): バケット内で使用するサブパスを入力します。 3. 選択したクラウドプロバイダーに応じて、追加の接続設定を入力します。 * CoreWeave: 追加の設定は不要です。 * AWS: 必要に応じて、暗号化用の **KMS key ARN** を入力します。 * Google Cloud: 追加の設定は不要です。 **Create team** をクリックすると、W\&B は指定された設定でクラウドプロバイダーにバケットを自動的に作成します。 7. チームにメンバーを招待します。**Invite team members** に、メールアドレスをカンマ区切りで指定します。メンバーはチームの作成後に招待することもできます。 8. **Create team** をクリックします。 W\&B がバケットへのアクセス中にエラーを検出した場合や、無効な設定を検出した場合は、ページ下部にエラーまたは警告が表示されます。問題がなければ、W\&B によってチームが作成されます。 1. **専用クラウド**: 以降の手順でストレージバケットをチームに使用する前に、バケットパスをアカウントチームに伝え、インスタンスのサポートされるファイルストアに追加してもらう**必要があります**。 2. **セルフマネージド**: 以降の手順でストレージバケットをチームに使用する前に、バケットパスを `GORILLA_SUPPORTED_FILE_STORES` 環境変数に追加し、W\&B を再起動する**必要があります**。 3. `admin` ロールを持つユーザーとして W\&B にログインし、左上のアイコンをクリックして左側のナビゲーションを開き、**Create a team to collaborate** をクリックします。 4. チームの名前を入力します。 5. **Storage Type** を **External storage** に設定します。 インスタンスレベルのストレージ (内部か外部かを問わず) をチームのストレージとして使用するには、インスタンスレベルのバケットが BYOB 用に設定されている場合でも、**Storage Type** を **Internal** のままにします。チーム専用の外部ストレージを使用するには、チームの **Storage Type** を **External** に設定し、次のステップでバケットの詳細を設定します。 6. **Bucket location** をクリックします。 7. 既存のバケットを使用するには、一覧から選択します。新しいバケットを追加するには、下部の **Add bucket** をクリックし、バケットの詳細を入力します。 **Cloud provider** をクリックし、**CoreWeave**、**AWS**、**Google Cloud**、または **Azure** を選択します。 クラウドプロバイダーが一覧に表示されない場合は、[Provision your bucket](#set-environment-variable) の手順に従って、インスタンスのサポートされるファイルストアにバケットパスを追加済みであることを確認してください。それでもストレージプロバイダーが表示されない場合は、[サポートに問い合わせて](mailto:forge-support@coreweave.com)ください。 8. バケットの詳細を指定します。 * **CoreWeave** の場合は、バケット名のみを入力します。 * Amazon S3、Google Cloud、または S3互換ストレージの場合は、[前の手順で確認した](#determine-the-storage-address)完全なバケットパスを入力します。 * 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` で接続文字列を設定していない限り、これらのフィールドは必須です。 9. **Create team** をクリックします。 W\&B がバケットへのアクセス中にエラーを検出した場合や、無効な設定を検出した場合は、ページ下部にエラーまたは警告が表示されます。問題がなければ、W\&B によってチームが作成されます。

トラブルシューティング

バケットの検証時または接続時に 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)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/enabling-cors-examples.html) を参照してください。 * `AllowedMethods` には、`GET`、`PUT`、`HEAD` の各メソッドを含める必要があります。 * `ExposeHeaders` には `ETag` を含める必要があります。 * CORS ポリシーの `AllowedOrigins` には、W\&B のフロントエンドドメインを含める必要があります。このページで紹介している CORS ポリシーの例では、`*` を使用してすべてのドメインを許可しています。 * **LOTA エンドポイントの問題** * W\&B は現時点では LOTA エンドポイントへの接続をサポートしていません。ご要望がある場合は、[サポートにお問い合わせください](mailto:forge-support@coreweave.com)。 * **アクセスキーと権限のエラー** * CoreWeave API のアクセスキーの有効期限が切れていないことを確認してください。 * CoreWeave API のアクセスキーとシークレットキーに、`GetObject`、`PutObject`、`DeleteObject`、`ListBucket` の必要な権限が付与されていることを確認してください。このページの例はこの要件を満たしています。詳しくは、CoreWeave ドキュメントの [Create and Manage Access Keys](/products/storage/object-storage/auth-access/manage-access-keys/about) を参照してください。

Google Cloud

このセクションでは、Google Cloud Storage への接続で発生する問題のトラブルシューティング方法を説明します。 * `Bucket does not have soft deletion enabled` Google Cloud Storage のバケットで論理削除が有効になっていることを確認してください。詳しくは、[バケットの論理削除ポリシーを編集する](https://docs.cloud.google.com/storage/docs/use-soft-delete)を参照してください。