コンテナーの作成

2025-10-08

Create Container操作では、指定されたアカウントの下に新しいコンテナが作成されます。同じ名前のコンテナーが既に存在する場合、操作は失敗します。

コンテナー・リソースには、そのコンテナーのメタデータとプロパティーが含まれます。コンテナー内の BLOB の一覧は含まれません。

リクエスト

次に示すように、 Create Container 要求を作成できます。 HTTPS の使用を推奨します。コンテナの名前には小文字のみを含めることができ、これらの命名規則に従う必要があります。 URL で、 myaccount をストレージアカウントの名前に置き換えます。

メソッド	要求 URI	HTTP バージョン
`PUT`	`https://myaccount.blob.core.windows.net/mycontainer?restype=container`	HTTP/1.1

エミュレートされたストレージ・サービス要求

エミュレートされたストレージサービスに対して要求を行う場合は、エミュレーターのホスト名と BLOB ストレージポートを 127.0.0.1:10000 として指定し、その後にエミュレートされたストレージアカウント名を指定します。

メソッド	要求 URI	HTTP バージョン
`PUT`	`http://127.0.0.1:10000/devstoreaccount1/mycontainer?restype=container`	HTTP/1.1

詳細については、「ローカル Azure Storage 開発に Azurite エミュレーターを使用する」を参照してください。

URI パラメーター

要求 URI には、次の追加パラメータを指定できます。

パラメーター	Description
`timeout`	Optional. `timeout` パラメーターは秒単位で表されます。詳細については、「 Blob Storage 操作のタイムアウトを設定する」を参照してください。

要求ヘッダー

必須およびオプションの要求ヘッダーを次の表に示します。

リクエストヘッダー	Description
`Authorization`	必須。認可スキーム、アカウント名、および署名を指定します。詳細については、「 Azure Storage への要求を承認する」を参照してください。
`Date` または `x-ms-date`	必須。要求の協定世界時 (UTC) 時間を指定します。詳細については、「 Azure Storage への要求を承認する」を参照してください。
`x-ms-version`	許可されたすべての要求に必要です。この要求に使用する操作のバージョンを指定します。詳細については、「 Azure Storage サービスのバージョン管理」を参照してください。
`x-ms-meta-name:value`	Optional. メタデータとしてコンテナーに関連付ける名前と値のペア。注: バージョン 2009-09-19 の時点では、メタデータ名は C# 識別子の名前付け規則に従う必要があります。
`x-ms-blob-public-access`	Optional. コンテナー内のデータにパブリックにアクセスできるかどうか、およびアクセスレベルを指定します。指定できる値は、次のとおりです。 - `container`: コンテナーと BLOB データに対する完全なパブリック読み取りアクセスを指定します。クライアントは、匿名要求を使用してコンテナー内の BLOB を列挙できますが、ストレージアカウント内のコンテナーを列挙することはできません。 - `blob:` BLOB のパブリック読み取りアクセスを指定します。このコンテナー内の BLOB データは匿名要求で読み取ることができますが、コンテナーデータは使用できません。クライアントは、匿名要求を介してコンテナー内の BLOB を列挙することはできません。このヘッダーがリクエストに含まれていない場合、コンテナーデータはアカウント所有者のプライベートになります。
`x-ms-client-request-id`	Optional. クライアントが生成した不透明な値に、ログの構成時にログに記録される 1 キビバイト (KiB) の文字制限を提供します。このヘッダーを使用して、クライアント側のアクティビティとサーバーが受信する要求を関連付けることを強くお勧めします。詳細については、「 Azure Blob Storage の監視」を参照してください。

要求ヘッダー (暗号化スコープ)

バージョン 2019-02-02 以降では、要求で次のヘッダーを指定して、コンテナーに既定の暗号化スコープを設定できます。暗号化スコープを設定すると、コンテナーにアップロードされるすべての BLOB が暗号化されるために使用されます。

リクエストヘッダー Description

x-ms-default-encryption-scope 必須。コンテナーのデフォルトとして設定する暗号化スコープ。

x-ms-deny-encryption-scope-override 必須。値は true または false。このヘッダーを true に設定すると、このコンテナーにアップロードされるすべての BLOB で既定の暗号化スコープが使用されるようになります。このヘッダーが falseされている場合、クライアントは既定のスコープ以外の暗号化スコープを持つ BLOB をアップロードできます。

リクエストヘッダー	Description
`x-ms-default-encryption-scope`	必須。コンテナーのデフォルトとして設定する暗号化スコープ。
`x-ms-deny-encryption-scope-override`	必須。値は `true` または `false`。このヘッダーを `true` に設定すると、このコンテナーにアップロードされるすべての BLOB で既定の暗号化スコープが使用されるようになります。このヘッダーが `false`されている場合、クライアントは既定のスコープ以外の暗号化スコープを持つ BLOB をアップロードできます。

Important

コンテナーが true に設定されx-ms-deny-encryption-scope-override場合、暗号化スコープを持たない BLOB や、顧客指定の暗号化キーを持たない BLOB への更新は、そのコンテナー内で許可されません。これらの BLOB は読み取り可能なままであり、ユーザーは BLOB をコンテナーから暗号化スコープのオーバーライドポリシーのない BLOB に移動して更新を実行できます。

リクエストの本文

なし。

サンプルリクエスト

Request Syntax:  
PUT https://myaccount.blob.core.windows.net/mycontainer?restype=container HTTP/1.1  
  
Request Headers:  
x-ms-version: 2011-08-18  
x-ms-date: Sun, 25 Sep 2011 22:50:32 GMT  
x-ms-meta-Name: StorageSample  
Authorization: SharedKey myaccount:Z5043vY9MesKNh0PNtksNc9nbXSSqGHueE00JdjidOQ=

[応答]

応答には、HTTP 状態コードと一連の応答ヘッダーが含まれます。

状態コード

操作が成功すると、状態コード 201 (作成済み) が返されます。

状態コードの詳細については、「状態コードとエラーコード」を参照してください。

応答ヘッダー

この操作の応答には、次の表で説明するヘッダーが含まれます。応答には、追加の標準 HTTP ヘッダーを含めることもできます。すべての標準ヘッダーは、 HTTP/1.1 プロトコル仕様に準拠しています。

応答ヘッダー	Description
`ETag`	コンテナーの ETag。要求バージョンが 2011-08-18 以降の場合、ETag 値は引用符で囲まれます。
`Last-Modified`	コンテナーが最後に変更された日時を返します。日付形式は RFC 1123 に従います。詳細については、「ヘッダーでの日付/時刻値の表現」を参照してください。コンテナー、そのプロパティ、またはメタデータを変更する操作は、最終変更時刻を更新します。 BLOB に対する操作は、コンテナーの最終変更時刻には影響しません。
`x-ms-request-id`	行われた要求を一意に識別します。これを使用して、要求のトラブルシューティングを行うことができます。詳細については、「API 操作のトラブルシューティング」を参照してください。
`x-ms-version`	要求の実行に使用される Blob Storage のバージョンを示します。このヘッダーは、バージョン 2009-09-19 以降に対して行われた要求に対して返されます。
`Date`	サービスによって生成された UTC の日付/時刻値で、応答が開始された時刻を示します。
`x-ms-client-request-id`	要求と対応する応答のトラブルシューティングに使用できます。このヘッダーの値は、要求に存在する場合、 `x-ms-client-request-id` ヘッダーの値と等しく、値に含まれる可視 ASCII 文字は 1024 文字以下です。 `x-ms-client-request-id` ヘッダーが要求に存在しない場合、ヘッダーは応答に存在しません。

応答内容

なし。

サンプル応答

Response status:  
HTTP/1.1 201 Created  
  
Response headers:  
Transfer-Encoding: chunked  
Date: Sun, 25 Sep 2011 23:00:12 GMT  
ETag: “0x8CB14C3E29B7E82”  
Last-Modified: Sun, 25 Sep 2011 23:00:06 GMT  
x-ms-version: 2011-08-18  
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0

Authorization

Azure Storage でデータアクセス操作を呼び出す場合は、承認が必要です。以下で説明するように、 Create Container 操作を承認できます。

Important

Microsoft では、マネージド ID で Microsoft Entra ID を使用して、Azure Storage への要求を承認することをお勧めします。 Microsoft Entra ID は、共有キー承認と比較して優れたセキュリティと使いやすさを提供します。

Azure Storage では、Microsoft Entra ID を使用した BLOB データへの要求の承認がサポートされています。 Microsoft Entra ID を使用すると、Azure ロールベースのアクセス制御 (Azure RBAC) を使用して、セキュリティプリンシパルにアクセス許可を付与できます。セキュリティプリンシパルは、ユーザー、グループ、アプリケーションサービスプリンシパル、または Azure マネージド ID です。セキュリティプリンシパルは、Microsoft Entra ID によって認証されて OAuth 2.0 トークンを返します。その後、トークンを使用して、Blob service に対する要求を承認できます。

Microsoft Entra ID を使用した承認の詳細については、「 Microsoft Entra ID を使用して BLOB へのアクセスを承認する」を参照してください。

Permissions

Microsoft Entra ユーザー、グループ、マネージド ID、またはサービスプリンシパルが Create Container 操作を呼び出すために必要な RBAC アクションと、このアクションを含む最小特権の組み込み Azure RBAC ロールを次に示します。

Azure RBAC アクション:Microsoft.Storage/storageAccounts/blobServices/containers/write
最小特権の組み込みロール:Storage Blob Data Contributor

Azure RBAC を使用したロールの割り当ての詳細については、「 BLOB データにアクセスするための Azure ロールの割り当て」を参照してください。

Shared Access Signature (SAS) は、ストレージアカウント内のリソースへの安全な委任アクセスを提供します。 SAS を使用すると、クライアントがデータにアクセスする方法をきめ細かく制御できます。クライアントがアクセスできるリソース、それらのリソースに対するアクセス許可、および SAS の有効期間を指定できます。

Create Container操作では、アカウント SAS を使用した承認のサポートがサポートされます。

ストレージアカウントで共有キーアクセスが許可されていない場合、アカウント SAS トークンは BLOB Storage への要求で許可されません。詳細については、「共有キーの禁止が SAS トークンに与える影響を理解する」を参照してください。

アカウント SAS

アカウント SAS は、ストレージアカウントキーでセキュリティで保護されます。アカウント SAS は、1 つ以上のストレージサービス内のリソースへのアクセスを委任します。サービスまたはユーザー委任 SAS を介して使用できるすべての操作は、アカウント SAS を介しても使用できます。

次の表は、アクセスを委任するときに指定する署名付きリソースの種類と署名付きアクセス許可を示しています。

Operation	署名付きサービス	署名付きリソースの種類	署名されたアクセス許可
コンテナーの作成	ブロブ (b)	コンテナ(c)	作成(c)または書き込み(w)

アカウント SAS の詳細については、「アカウント SAS の作成」を参照してください。

Create Container操作は、共有キー認証をサポートします。アカウントキーを使用した承認は、安全性が低いため、ほとんどのシナリオでは推奨されません。

Microsoft では、可能であれば、ストレージアカウントの共有キー承認を許可しないことをお勧めします。詳細については、「共有キーによる承認の防止」を参照してください。

注釈

コンテナーは、ストレージアカウント内にすぐに作成されます。あるコンテナを別のコンテナ内にネストすることはできません。

必要に応じて、ストレージアカウントの既定のコンテナーまたはルートコンテナーを作成できます。ルートコンテナーを使用すると、コンテナー名を参照せずに、ストレージアカウント階層の最上位レベルから BLOB を参照できます。

ルートコンテナーをストレージアカウントに追加するには、 $root という名前のコンテナーを作成します。要求を次のように構成します。

Request Syntax:  
PUT https://myaccount.blob.core.windows.net/$root?restype=container HTTP/1.1  
  
Request Headers:  
x-ms-version: 2011-08-18  
x-ms-date: Sun, 25 Sep 2011 22:50:32 GMT  
x-ms-meta-Name: StorageSample  
Authorization: SharedKey myaccount:Z5043vY9MesKNh0PNtksNc9nbXSSqGHueE00JdjidOQ=

コンテナの作成時に、要求に 1 つ以上のメタデータヘッダーを含めることで、コンテナのメタデータを指定できます。メタデータヘッダーの形式は x-ms-meta-name:valueです。

Create Container が呼び出されたときに同じ名前のコンテナーが削除されている場合、サーバーは状態コード 409 (競合) を返し、コンテナーが削除されていることを示す追加のエラー情報を提供します。

Billing

価格要求は、Blob Storage REST API を介して直接、または Azure Storage クライアントライブラリから、Blob Storage API を使用するクライアントから発信できます。これらの要求では、トランザクションごとに料金が発生します。トランザクションの種類は、アカウントの請求方法に影響します。たとえば、読み取りトランザクションは、書き込みトランザクションとは異なる請求カテゴリに発生します。次の表は、ストレージアカウントの種類に基づく Create Container 要求の課金カテゴリを示しています。

Operation	ストレージアカウントの種類	請求カテゴリ
コンテナーの作成	Premium ブロック BLOB 標準汎用バージョン 2 標準汎用バージョン1	コンテナーの一覧表示と作成操作

指定した課金カテゴリの価格については、「 Azure Blob Storage の価格」を参照してください。

こちらも参照ください

Azure Storage への要求を承認する
 状態コードとエラーコード
 BLOB Storage エラーコード
 コンテナー、BLOB、メタデータに名前を付けて参照する
 BLOB リソースのプロパティとメタデータを設定および取得する
 コンテナ ACL の設定