コンテナーの作成

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

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

要求

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

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

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

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

Method	要求 URI	HTTP バージョン
PUT	http://127.0.0.1:10000/devstoreaccount1/mycontainer?restype=container	HTTP/1.1

詳細については、ローカルでの Azure Storage の開発に Azurite エミュレーターを使用する方法に関するページを参照してください。

URI パラメーター

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

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

要求ヘッダー

必須の要求ヘッダーと省略可能な要求ヘッダーを次の表に示します。

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

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

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

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

Response

応答には、HTTP 状態コードおよび一連の応答ヘッダーが含まれています。

status code

操作が正常に終了すると、状態コード 201 (Created) が返されます。

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

応答ヘッダー

この操作の応答には、次の表に示すヘッダーが含まれています。 応答に追加の標準 HTTP ヘッダーが含まれる場合もあります。 すべての標準ヘッダーは 、HTTP/1.1 プロトコル仕様に準拠しています。

応答ヘッダー	説明
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	要求と対応する応答のトラブルシューティングに使用できます。 このヘッダーの値は、要求に存在し、その値に 1024 文字以下の ASCII 文字が含まれている場合、ヘッダーの値 x-ms-client-request-id と等しくなります。 ヘッダーが 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  

承認

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

重要

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

Microsoft Entra ID (推奨)

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

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

アクセス許可

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

• Azure RBAC アクション:Microsoft.Storage/storageAccounts/blobServices/containers/write
• 最小特権の組み込みロール:ストレージ BLOB データ共同作成者

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

共有アクセス署名 (SAS)

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

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

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

アカウント SAS

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

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

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

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

共有キー

この操作では Create Container 、 共有キーの承認がサポートされています。 アカウント キーを使用した承認は、セキュリティが低く、ほとんどのシナリオでは推奨されません。

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

注釈

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

必要に応じて、ストレージ アカウントの既定コンテナーまたはルート コンテナーを作成できます。 ルート コンテナーを使用すると、コンテナー名を参照することなく、ストレージ アカウント階層の最上位から 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 (競合) を返し、コンテナーが削除されていることを示す追加のエラー情報を提供します。

請求

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

操作	ストレージ アカウントの種類	課金カテゴリ
コンテナーの作成	Premium ブロック BLOB Standard 汎用 v2 Standard 汎用 v1	コンテナー操作の一覧表示とCreate

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

こちらもご覧ください

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