Azure Blob Storage入門 オブジェクトストレージの基礎からアクセス制御・料金まで現場で使える実践ガイド

「Azureで大量のログやバックアップを保存したいが、Blob Storageの構造がよくわからない」——オンプレのファイルサーバーからクラウドストレージへの移行で、多くのインフラ担当者がぶつかる壁です。

オンプレでは、NFSやCIFSで共有フォルダを切り出し、容量が足りなくなればディスクを追加する運用が一般的でした。しかしAzureのオブジェクトストレージでは、ストレージアカウント・コンテナ・BLOBという独自の階層構造があり、アクセス制御の仕組みも大きく異なります。

この記事では、Azure Blob Storageの基本構造から、Azureポータル・Azure CLIでの操作方法、アクセス制御、料金体系まで、オンプレ経験者が押さえるべきポイントを体系的に解説します。

なぜAzure Blob Storageなのか？オンプレファイルサーバーとの違い

オンプレのストレージ運用を振り返ると、まずSANやNASを調達し、RAIDを構成して、ボリュームを切り出す。容量の監視、ディスク交換、バックアップ用テープの管理まで、インフラ担当者が面倒を見る範囲は広いものでした。

Azure Blob Storageは、こうした物理ストレージの管理から解放してくれるサービスです。主な違いを整理します。

・容量制限が事実上ない: オンプレでは物理ディスクの上限に縛られるが、Blob Storageは1ストレージアカウントで最大5 PiBまで格納できる。容量計画から解放される
・冗長性が組み込み済み: LRS（ローカル冗長）でも同一データセンター内で3重コピーが自動で行われる。オンプレのRAID構成やレプリケーション設計が不要
・アクセス頻度に応じた料金最適化: ホット・クール・コールド・アーカイブの4つのアクセス層があり、データの利用頻度に応じてコストを最適化できる
・HTTP/HTTPSでどこからでもアクセス: NFSマウントのようなネットワーク依存がなく、REST APIで世界中からアクセスできる

オンプレのファイルサーバーが「社内ネットワーク上の共有ドライブ」だとすれば、Blob Storageは「インターネット上に置いた容量無制限のデータ倉庫」です。ファイルシステムのディレクトリ構造とは設計思想が異なるため、まず階層構造を理解することが重要です。

Azure Blob Storageの基本構造（アカウント・コンテナ・BLOB）

Blob Storageは3層の階層で構成されています。オンプレのストレージに置き換えながら説明します。

1. ストレージアカウント

ストレージアカウントは、Azure上のストレージリソースの最上位の管理単位です。オンプレでいえば「ストレージ装置（NASやSAN）」に相当します。

アカウントの種類は「汎用v2（General-purpose v2）」を選んでおけば間違いありません。Blob Storage専用アカウントもありますが、汎用v2であればBlob・File・Queue・Tableすべてのサービスが使えます。

命名ルールとして、ストレージアカウント名はAzure全体で一意でなければなりません。3〜24文字、小文字英数字のみです。たとえば「stlogsprodjpe001」のように、用途・環境・リージョンを含めた命名規則を決めておくと運用が楽です。

2. コンテナ

コンテナは、BLOB（データ）をグループ化する入れ物です。オンプレの「共有フォルダ」や「ボリューム」に近い概念です。

1つのストレージアカウント内に複数のコンテナを作成でき、コンテナ単位でアクセス権限を設定できます。たとえば「logs」「backups」「static-assets」のように用途ごとにコンテナを分けるのが一般的です。

3. BLOBの種類

BLOBはBinary Large OBjectの略で、実際に格納されるデータの単位です。オンプレの「ファイル」に相当します。Blob Storageには3種類のBLOBがあります。

・ブロックBLOB: 最も一般的なタイプ。ログファイル、画像、動画、バックアップデータなどの格納に使う。最大約190.7 TiBまで対応
・追加BLOB: データの末尾への追記に特化したタイプ。アプリケーションログやイベントログの書き込みに適している
・ページBLOB: ランダムアクセスに最適化されたタイプ。Azure VMのOS/データディスク（VHDファイル）に使われている

実務で最も使う頻度が高いのはブロックBLOBです。「とりあえずファイルを置きたい」という用途なら、ブロックBLOBを選べば問題ありません。

基本的な使い方（Azureポータル＆Azure CLI）

1. ストレージアカウントの作成

Azureポータル（https://portal.azure.com）から作成する手順です。

1. ポータル上部の検索バーで「ストレージアカウント」と入力し、サービスを選択
2. 「作成」をクリック
3. サブスクリプションとリソースグループを選択（リソースグループがなければ新規作成）
4. ストレージアカウント名を入力（例: stlogsprodjpe001）
5. リージョンは「東日本（japaneast）」を選択。国内向けサービスならレイテンシの面で有利
6. パフォーマンスは「Standard」を選択。Premium（SSD）はBlob Storage単体ではあまり使わない
7. 冗長性は「LRS（ローカル冗長ストレージ）」がコスト最安。重要データなら「GRS（地理冗長ストレージ）」を検討
8. 「確認および作成」→「作成」でデプロイ開始。通常1分以内で完了する

2. コンテナの作成とBLOBのアップロード

ストレージアカウントの作成が完了したら、コンテナを作ってデータをアップロードします。

1. 作成したストレージアカウントを開き、左メニューの「コンテナー」を選択
2. 「＋コンテナー」をクリックし、名前を入力（例: logs）
3. パブリックアクセスレベルは「プライベート（匿名アクセスなし）」のままにしておく。公開する理由がなければ、デフォルトが最も安全
4. 作成したコンテナを開き、「アップロード」からファイルを選択して送信

3. Azure CLIでの操作

繰り返しの操作やスクリプト化にはAzure CLIが便利です。

# ストレージアカウントの作成（Azure CLI）
az storage account create \
  --name stlogsprodjpe001 \
  --resource-group rg-storage-prod \
  --location japaneast \
  --sku Standard_LRS \
  --kind StorageV2

# コンテナの作成
az storage container create \
  --name logs \
  --account-name stlogsprodjpe001

# ファイルのアップロード
az storage blob upload \
  --account-name stlogsprodjpe001 \
  --container-name logs \
  --name app-log-20260401.log \
  --file ./app-log-20260401.log \
  --auth-mode login

# コンテナ内のBLOB一覧表示
az storage blob list \
  --account-name stlogsprodjpe001 \
  --container-name logs \
  --output table \
  --auth-mode login

--auth-mode loginはAzure ADの認証情報を使ってアクセスする方式です。後述するアクセスキーを使う場合は--account-keyを指定しますが、セキュリティ上はAzure AD認証が推奨されています。

アクセス制御の仕組み（SAS・Azure AD・アクセスキー）

オンプレのファイルサーバーでは、Active DirectoryのACLでアクセス権限を管理していた方が多いでしょう。Blob Storageでは、主に3つのアクセス制御方式を組み合わせて使います。

・アクセスキー（ストレージアカウントキー）: ストレージアカウントに紐づく2つの共有キー。このキーがあればアカウント内の全データにフルアクセスできる。オンプレでいえば「root権限」に近い。便利だが漏洩リスクが高いため、本番環境ではできるだけ使わない
・SAS（Shared Access Signature）: 有効期限・アクセス範囲・許可する操作を限定した一時的なトークン。「このコンテナに対して、24時間だけ読み取り専用でアクセスを許可する」といった細かい制御ができる。外部パートナーへの一時的なデータ共有に最適
・Azure AD（Microsoft Entra ID）認証: Azure ADのRBAC（ロールベースアクセス制御）でアクセスを管理する方式。Microsoftが最も推奨している方法で、「ストレージ BLOB データ閲覧者」「ストレージ BLOB データ共同作成者」などの組み込みロールでアクセス範囲を細かく制御できる

実務での使い分けの指針を整理します。

アクセスキーは定期的なローテーションが必要です。Azureポータルのストレージアカウント画面から「アクセスキー」を開き、キー1とキー2を交互に更新するのが一般的な運用です。

料金の仕組み（ストレージ層とコスト感覚）

Blob Storageの料金は「保存したデータ量」と「操作（読み書き）の回数」の2軸で計算されます。オンプレのストレージのように「最初にまとまった費用を払って容量を確保する」方式ではなく、使った分だけ課金される従量課金制です。

東日本リージョン（japaneast）・LRS冗長の場合の保存料金は以下のとおりです（2026年4月時点）。

ここで注意すべき点があります。保存料金が安い層ほど、読み取り操作の料金が高くなります。また、クール層は最低30日、コールド層は最低90日、アーカイブ層は最低180日の保存期間が設定されており、それより前にデータを削除すると早期削除料金が発生します。

コスト最適化のコツとしては、Azure Blob Storageの「ライフサイクル管理ポリシー」を活用する方法があります。「作成から30日経過したらクール層に移動」「90日経過したらアーカイブ層に移動」といったルールを設定すれば、手動でのデータ移行が不要です。

具体的なコスト感覚を持つために、100 GBのデータをホット層に保存した場合の月額を計算してみます。保存料金は100 GB × $0.018 = 約$1.80（約270円）です。オンプレで100 GBのNASを用意するコストと比較すれば、圧倒的に安いことがわかります。ただし、読み書きのトランザクション料金も加算されるため、大量のAPI呼び出しが発生する場合はそちらも見積もりに含める必要があります。

よくあるトラブルと対処法

現場でよく遭遇するトラブルと、その対処法をまとめます。

・403 AuthorizationFailure: アクセスキーやSASトークンの有効期限が切れているケースが多い。Azure CLIで--auth-mode loginを使っている場合は、az loginでセッションを更新する。RBACの場合はユーザーに「ストレージ BLOB データ閲覧者」以上のロールが割り当てられているか確認する
・BLOBが見つからない（404 BlobNotFound）: コンテナ名やBLOB名の大文字・小文字の違いが原因になりやすい。Blob Storageの名前はケースセンシティブ（大文字小文字を区別する）なので注意
・アーカイブ層のデータにすぐアクセスできない: アーカイブ層のBLOBはオフライン状態で、読み取るには「リハイドレーション（復元）」が必要。標準優先度で最大15時間、高優先度でも最大1時間かかる。緊急復旧が必要なデータはアーカイブ層に置かないのが鉄則
・想定外のコスト増: 大量の小さなファイルを頻繁に読み書きすると、トランザクション料金が膨らむ。ログの集約やバッチ処理でファイルをまとめてからアップロードするとコストを抑えられる

本記事のまとめ

Azure Blob Storageの基本をオンプレの知識と対比しながら整理します。

Blob Storageは一度構造を理解すれば、オンプレのストレージ運用経験がそのまま活きる場面が多いサービスです。まずはストレージアカウントとコンテナを作成し、Azure CLIでファイルをアップロードするところから始めてみてください。

AWSのオブジェクトストレージであるAmazon S3と比較検討している方は、S3の「バケット」がBlobの「コンテナ」に相当し、基本的な考え方は共通しています。姉妹サイトクラウドマスターズ.TOKYOのAWS関連記事もあわせてご参照ください。