Azure Blob Storageとは？仕組み・Blobの種類とアクセス層・S3との違いを実装者目線で解説

Azure Blob StorageはMicrosoft Azureのオブジェクトストレージで、画像・動画・ログ・バックアップといった非構造化データを1アカウントあたり数十ペタバイト規模まで格納できます。実装で最初に押さえるべきは、ストレージアカウント〜コンテナー〜Blobという3階層のリソースモデルと、ブロック・追加・ページという3種類のBlob、そしてHot・Cool・Cold・Archiveのアクセス層とLRS〜GZRSの冗長性オプションです。この記事では定義から、料金を左右する階層設計、Amazon S3との対応関係、そして「どんなシステムで採用し、どこでは見送るか」の判断基準までを、2026年時点の公式ドキュメントの数値に基づいて整理します。

まとめ：Azure Blob Storageの要点と採用判断の分岐

Azure Blob Storageは、Azure上に構築するシステムの「非構造化データの置き場」として第一候補になるマネージドオブジェクトストレージです。データはストレージアカウント配下のコンテナーにBlobとして格納し、HTTPSやAzure SDK、SFTP、NFS 3.0からアクセスします。コスト設計の中心はアクセス層（Hot／Cool／Cold／Archive）と冗長性（LRS／ZRS／GRS／GZRS）の2軸で、保管期間とアクセス頻度に合わせてこの組み合わせを決めるのが実装者の仕事になります。

採用が合理的なのは、Azure中心のシステムで静的配信・バックアップ・アーカイブ・分析基盤の素材を大量に扱う場合です。逆に、SMB共有として使いたいならAzure Files、仮想マシンの低レイテンシーなディスクが欲しいならManaged Disks、頻繁にランダム更新する構造化データならデータベースが適します。自社システムでどのストレージを組み合わせるべきか迷う段階なら、設計から相談できる開発会社に早めに当たると手戻りを防げます。

Azure Blob Storageの仕組みと3階層のリソースモデル

Blob Storageは「Blob（Binary Large Object）」という単位で任意のバイナリを保存するオブジェクトストレージです。ファイルシステムのようなディレクトリ実体を持たず、フラットな名前空間にキーで格納する点が、後述するAmazon S3などと共通の設計思想になります。

非構造化データを大量に格納するオブジェクトストレージという位置づけ

Blob Storageが想定する用途は、ブラウザーへの画像・ドキュメント配信、動画や音声のストリーミング、ログの書き込み、バックアップ／ディザスターリカバリー／アーカイブ、そして分析サービスへの入力データの保管です。1つのBlobは最大約190.7TiB（ブロックBlobの場合・2026年時点）まで拡張でき、容量の上限はアカウント単位で管理されます。オブジェクトストレージそのものの仕組みやブロックストレージとの違いは、オブジェクトストレージとは何かを仕組みから解説した記事で前提を確認しておくと、この後のBlob種別やアクセス層の話が読み解きやすくなります。

ストレージアカウント・コンテナー・Blobから成る3階層リソース構造

リソースは3階層です。最上位のストレージアカウントがAzure内で一意な名前空間を提供し、既定のエンドポイントはアカウント名.blob.core.windows.netの形になります。その下に置くコンテナーがBlobをまとめる論理的な入れ物で、名前はDNS名として有効な3〜63文字の小文字・数字・ハイフンに制限されます。実際のデータはコンテナー内のBlobで、Blob名は最大1,024文字、大文字と小文字の区別あり。アカウント種別は汎用v2（Standard）が推奨で、高トランザクション用途にはPremiumのブロックBlobアカウント、VMディスク用途にはPremiumのページBlobアカウントが用意されています。

ブロックBlob・追加Blob・ページBlobという3種類の使い分け

Blobには3種類あり、用途で選びます。運用の大半はブロックBlobで足ります。

ブロックBlobはブロック単位で分割管理でき、大きなファイルの並列アップロードに向きます。追加Blobは末尾への追記に向いており、仮想マシンのログ集約のような書き込みパターンに向いた種類です。ページBlobはランダムアクセスファイル向けで、Azure仮想マシンのディスク実体として使われます。なお後述のアクセス層を設定できるのはブロックBlobだけで、追加・ページBlobは対象外です。

アクセス層（Hot・Cool・Cold・Archive）とコスト設計

Blob Storageの料金は「保存容量×アクセス層の単価」に「読み書きのトランザクション課金」「データ取り出し課金」を足した構造です。層が冷たくなるほど保存単価は下がり、取り出し単価は上がります。この逆相関を、データのアクセス頻度と保持期間に合わせて設計します。

ホット・クール・コールド・アーカイブという4つのアクセス層と最小保持日数

オンライン層は3つ、オフライン層が1つです。それぞれに最小保持日数（早期削除ペナルティの対象期間）が設定されています。

Hotは保存単価が最も高く取り出し単価が最も低いため、稼働中のデータに向きます。Cool（30日）とCold（90日）は保存単価が下がる代わりに読み取りに課金が乗るので、短期バックアップや当面参照しない旧データが対象です。保存単価の目安はHot・LRSで1GBあたり月額約0.02ドル前後、Archiveでは0.001ドル未満まで下がります（いずれも2026年時点・リージョンで変動）。最小日数より前に削除・上書き・層移動をすると差分日数の早期削除料金が日割りで発生する点に注意します。

アーカイブ層のオフライン特性とリハイドレートに要する最大15時間

Archive層はオフラインで、そのままでは読み取りも更新もできません。読み出すには一度Hot・Cool・Coldのいずれかへ「リハイドレート（再水和）」する必要があり、優先度によって最大15時間ほどかかります。メタデータとインデックスタグだけは読めるため、一覧やプロパティ照会は可能です。長期のコンプライアンス保管や原本データの退避には向きますが、数時間の取り出し遅延を許容できない用途では選べません。

ライフサイクル管理のルールによる自動的な階層移動とコスト削減設計

手動で層を動かす代わりに、ライフサイクル管理のルールで「最終更新から30日でCool、90日でArchive、365日で削除」といった遷移を自動化できます。ルールベースなので、ログや世代バックアップのように寿命が読めるデータのコスト設計に向く方式です。ただしArchiveからオンライン層へのリハイドレートはライフサイクル管理では実行できず、Set Blob TierやCopy Blob操作で明示的に戻す必要があります。複数アカウントを横断して大規模に処理したい場合はStorage Actionsのストレージタスクが選択肢になります。

データ冗長性（LRS・ZRS・GRS・GZRS）の違いと選び方

アクセス層と並ぶもう一方の設計軸が冗長性です。どこまで障害範囲を広げてもデータを守るかで、耐久性の桁とコストが変わります。可用性要件と地理的なDR要件から逆算して選びます。

ローカル冗長・ゾーン冗長・地理冗長という4系統と耐久性の桁数の違い

冗長性は大きく4系統です。実装ではまず「単一リージョンで足りるか、地理的DRが要るか」で二分すると選びやすくなります。

LRSは最も安価で単一データセンター内に3コピーを保持し、ドライブ・サーバー・ラック障害までを守ります。ZRSは同一リージョンの3つの可用性ゾーンに分散し、ゾーン障害に耐えます。GRSは一次リージョンのLRSに加えて別リージョンへ非同期複製し、RA-GRSにすると二次リージョンからの読み取りが可能です。GZRS／RA-GZRSはゾーン冗長と地理冗長を組み合わせた最上位で、コストも最も高くなります。GRSは同容量のLRSに対しておおむね2倍前後の保存単価が目安です。

アーカイブ層の冗長性がLRS・GRS・RA-GRSに限られる設計上の制約

見落としやすい制約として、Archive層をサポートする冗長性はLRS・GRS・RA-GRSに限られ、ZRS・GZRS・RA-GZRSでは使えません。つまり「ゾーン冗長で守りつつ長期アーカイブもしたい」という要件は1アカウントでは両立しないため、用途ごとにアカウントを分ける設計が要ります。アーカイブBlobがあるアカウントはLRSからGRSへの変更にも制約がかかるので、冗長性は運用開始前に確定させておくのが安全です。ブロックストレージ側の冗長性・スナップショットの考え方はAmazon EBSの仕組みを解説した記事と対比すると、オブジェクトとブロックで守り方が違うことが見えてきます。

Amazon S3との違いとData Lake Storage Gen2

Blob StorageはAWSのAmazon S3と同じオブジェクトストレージの系譜にあり、概念はほぼ対応します。マルチクラウドや移行を検討する際は、この対応関係を押さえると設計を横展開できます。

S3のバケットとコンテナー・オブジェクトとBlobの対応関係

S3の「バケット」がBlob Storageの「コンテナー」、S3の「オブジェクト」が「Blob」に対応します。ストレージクラスも、S3 Standard／Standard-IA／GlacierがおおむねHot／Cool／Archiveにほぼ対応する関係です。違いとして、Blob Storageはアカウント単位で一意な名前空間とエンドポイントを持ち、追加BlobやページBlobといったBlob種別を明示的に区別する点が挙げられます。AWS側の設計思想やストレージクラス・料金はAmazon S3の仕組みと採用判断を解説した記事と読み比べると、どちらのクラウドに寄せるかの判断材料になります。

階層型名前空間を足すData Lake Storage Gen2

Blob Storageに「階層型名前空間」を有効化すると、Azure Data Lake Storage Gen2として振る舞い、ディレクトリ単位の操作やPOSIX風のアクセス制御が使える分析基盤になります。低コストの階層型ストレージや高可用性というBlobの利点を保ったまま、ビッグデータ分析に向いた構造を得られる点が特徴です。データ基盤としての位置づけはデータレイクとデータウェアハウスの違いを整理した記事と合わせて見ると、Gen2をどのアーキテクチャーに組み込むかが判断しやすくなります。なお階層型名前空間の有効化でパスセグメント数の上限は254から63に変わるため、命名規約は事前に決めておきます。

Azure Blob Storageを採用すべき場面と見送る場面

ここからは判断です。Blob Storageは万能のストレージではなく、向く用途と向かない用途がはっきり分かれます。要件から逆算し、条件付きで採否を言い切ります。

Blob Storageの採用が合理的になる4つの実務上の条件

次のいずれかに該当するなら、Blob Storageが第一候補になります。

• Azure中心のシステムで、画像・動画・PDFなどをHTTPS配信したい
• バックアップ・アーカイブを、保持期間に応じて安価な層へ自動で寝かせたい
• Data Lake Storage Gen2として分析基盤の生データ置き場にしたい
• SDKやREST、AzCopyでアプリから直接読み書きする非構造化データがある

いずれもオブジェクトストレージの強み（容量無制限に近いスケール・低単価・HTTPアクセス）が効く領域です。特にアクセス頻度が時間とともに落ちるデータは、ライフサイクル管理と組み合わせるとコストが大きく下がります。

Blob Storageを選ぶべきでない場面と適切な代替サービス

一方で、次の要件にはBlob Storageを選びません。ここを混同すると設計が破綻します。第一に、既存アプリがSMBやNFSのファイル共有を前提とし、ドライブとしてマウントしたいならAzure Filesが適します。第二に、仮想マシンのOSディスクやデータベース用に低レイテンシーのブロックデバイスが必要な場合はManaged Disksの領分です。第三に、頻繁にランダム更新・トランザクション処理する構造化データは、BlobではなくリレーショナルデータベースやNoSQLの領分です。第四に、数時間の取り出し遅延を許容できない即時参照データを、コスト目当てでArchive層に置くのは失敗パターンで、リハイドレートの15時間が要件と衝突します。

受託開発におけるストレージ構成の全体設計と外注先への相談の勘所

実際のシステムでは、Blob Storage単体ではなくAzure Files・Managed Disks・データベースを役割ごとに組み合わせる構成が普通です。どのデータをどの層・どの冗長性に置くかは、可用性要件・DR要件・月次コストのトレードオフで決まり、運用開始後の変更にはリハイドレートや再複製のコストが伴います。要件定義の段階で全体設計を固めておくほど、後の作り直しを避けられる設計です。Azureを含むクラウドインフラの構築・移行の相談では、ストレージ選定を含めた設計から実装・運用までを一貫して支援できます。

よくある質問

Azure Blob Storageの実装検討でよく挙がる質問を、公式ドキュメントの仕様に沿って整理します。

Azure Blob StorageとAzure Filesはどう違いますか？

Blob Storageはキーでバイナリを格納するオブジェクトストレージで、HTTPSやSDKからアクセスします。Azure FilesはSMBやNFSでマウントできるマネージドファイル共有で、既存アプリがネットワークドライブを前提とする場合に適した共有です。ブラウザー配信やアプリからのAPIアクセスが主目的ならBlob、ファイルサーバーの置き換えならAzure Filesと切り分けます。

ホット層とアーカイブ層はどう使い分けますか？

稼働中で頻繁に読み書きするデータはHot層に置きます。数か月以上ほぼ参照せず、取り出しに数時間かかっても構わない長期保管データはArchive層に寝かせます。Archiveは保存単価が最も安い一方でオフラインのため、読み出しには最大15時間のリハイドレートが必要です。最小保持日数は180日で、途中で削除すると差分の早期削除料金がかかります。

Blob StorageとAmazon S3は互換性がありますか？

概念は対応しますが、APIやエンドポイントは別物で、直接の互換性はありません。バケットとコンテナー、オブジェクトとBlob、StandardとHotのように役割は一対一で置き換えられるため、設計の考え方は横展開できます。移行時はAzCopyやData Factoryでデータを移し、アプリ側はAzure SDKへ書き換える形になります。

料金はどの要素で決まりますか？

主に「保存容量×アクセス層の単価」「読み書きのトランザクション数」「Cool以降のデータ取り出し量」「GRS等の地理レプリケーション転送」「リージョン外への送信帯域」の合算です。層が冷たいほど保存は安く取り出しは高くなるため、アクセス頻度と保持期間からアクセス層と冗長性を決めるのがコスト最小化の勘所になります。

3種類のBlobはどう選べばよいですか？

一般的なファイル・画像・動画の保存はブロックBlobで足ります。仮想マシンのログのように末尾へ追記し続ける用途は追加Blob、Azure仮想マシンのディスク実体やVHDにはページBlobという役割分担です。アクセス層（Hot／Cool／Cold／Archive）を設定できるのはブロックBlobだけなので、コスト階層を効かせたいデータはブロックBlobにします。

関連記事

• オブジェクトストレージとは？仕組みとS3互換API・ブロックとの違いを実装視点で解説：Blob Storageの土台となる概念を仕組みから確認できます。
• Amazon S3とは？仕組み・ストレージクラスと料金・採用判断を実装者目線で解説：AWS側の対応物と読み比べ、どちらのクラウドに寄せるかの判断材料になります。
• Amazon EBSとは？仕組み・ボリュームタイプと料金モデル・採用判断を解説：オブジェクトとブロックの守り方・使い分けを対比できます。
• データレイクとは？データウェアハウス・レイクハウスとの違いを実装視点で解説：Data Lake Storage Gen2を組み込む分析基盤の設計に接続します。