Azure Blob Storageの実務活用｜データ保存・アクセス制御・コスト管理の実践

「社内の大量のファイルをクラウドに移行したい」「アプリケーションの画像やログの保存先を安全に管理したい」――Azure Blob Storageは、そんな課題を解決するAzureのオブジェクトストレージサービスです。

Blob Storageは、テキスト、画像、動画、ログファイル、バックアップデータなど、あらゆる種類の非構造化データを大量に保存できます。99.999999999%（イレブンナイン）の耐久性を持ち、ペタバイト規模のデータにもスケールします。

この記事では、Azure Blob Storageの基本概念から、ストレージアカウントの作成、アクセス層（Hot / Cool / Cold / Archive）の選定、SASトークンによるアクセス制御、ライフサイクルポリシーによるコスト最適化まで、実務で必要な知識を体系的に解説します。

Azure Blob Storageの基本概念とリソース構造

Azure Blob Storageを正しく使いこなすために、まずリソースの階層構造を理解しましょう。

3階層のリソース構成

Blob Storageは、以下の3つの階層で構成されています。

ストレージアカウント：Azure上のストレージリソースの最上位単位。一意の名前空間を提供し、HTTP/HTTPSでアクセスできる
コンテナ：Blobを格納するフォルダのような単位。ファイルシステムのディレクトリに相当する。1つのストレージアカウントに複数のコンテナを作成できる
Blob：実際のデータ（ファイル）。コンテナ内にフラットな構造で格納される。ディレクトリ区切り（/）を含む名前を付けることで、仮想的なフォルダ構造を表現できる

Blobの種類

Blob Storageでは、用途に応じて3種類のBlobが用意されています。

ブロックBlob：最も一般的な種類。画像、ドキュメント、動画など、ほとんどのファイル保存に使用する。最大約190TBのデータを格納可能
追加Blob：ログファイルのように、データを末尾に追加していく用途に最適化されている
ページBlob：仮想マシンのディスク（VHD）に使用される。ランダムアクセスに最適化されている

一般的な業務利用では、ほとんどのケースでブロックBlobを使用します。

ストレージアカウントの作成と初期設定

実際にBlob Storageを使い始めるための手順を解説します。

Azure CLIによるストレージアカウントの作成

# リソースグループの作成
az group create --name rg-storage-prod --location japaneast

# ストレージアカウントの作成
az storage account create \
  --name stmyappprod001 \
  --resource-group rg-storage-prod \
  --location japaneast \
  --sku Standard_LRS \
  --kind StorageV2 \
  --min-tls-version TLS1_2 \
  --allow-blob-public-access false \
  --https-only true

ストレージアカウント名は、Azure全体で一意である必要があります。3〜24文字の小文字英数字のみが使用可能です。命名規則としてst{アプリ名}{環境}{連番}のようなパターンを推奨します。

冗長性オプションの選択

ストレージアカウント作成時に指定する--skuパラメータで、データの冗長性レベルを選択します。

LRS（ローカル冗長ストレージ）：同一データセンター内で3つのコピーを保持。最もコストが低い
ZRS（ゾーン冗長ストレージ）：同一リージョン内の3つの可用性ゾーンにデータを分散。データセンター障害に耐えられる
GRS（geo冗長ストレージ）：プライマリリージョンとセカンダリリージョン（ペアリージョン）にデータを複製。リージョン障害に耐えられる
GZRS（geoゾーン冗長ストレージ）：ZRSとGRSを組み合わせた最も高い冗長性。可用性ゾーン障害とリージョン障害の両方に耐えられる

コストと可用性のバランスを考慮して選択しましょう。開発環境ではLRS、本番環境で重要なデータにはZRS以上を推奨します。

コンテナの作成

# コンテナの作成
az storage container create \
  --name images \
  --account-name stmyappprod001 \
  --auth-mode login

az storage container create \
  --name logs \
  --account-name stmyappprod001 \
  --auth-mode login

az storage container create \
  --name backups \
  --account-name stmyappprod001 \
  --auth-mode login

コンテナ名は用途に応じてわかりやすい名前を付けましょう。images、logs、backups、uploadsなどが典型的です。

アクセス層の選定とコスト最適化

Azure Blob Storageには、データのアクセス頻度に応じた複数のアクセス層が用意されています。適切な層を選ぶことで、ストレージコストを大幅に削減できます。クラウドコスト削減の方法と合わせて押さえておきたいポイントです。

4つのアクセス層の特徴

Hot層

頻繁にアクセスされるデータ向け
保存コスト：高い / アクセスコスト：低い
用途：Webアプリの画像、APIレスポンスのキャッシュ、アクティブなドキュメント

Cool層

30日以上保存し、たまにアクセスするデータ向け
保存コスト：Hotの約50% / アクセスコスト：Hotの約2倍
用途：月次レポート、30日以上経過したログ、短期バックアップ

Cold層

90日以上保存し、めったにアクセスしないデータ向け
保存コスト：Hotの約30% / アクセスコスト：Coolより高い
用途：四半期レポート、コンプライアンス関連のデータ

Archive層

180日以上保存し、ほぼアクセスしないデータ向け
保存コスト：最も低い（Hotの約10分の1）/ アクセスコスト：最も高い
データの読み取りには「リハイドレーション」が必要で、数時間かかる
用途：法的保存義務のあるデータ、年次アーカイブ、長期バックアップ

アクセス層の設定方法

# Blobのアクセス層を個別に変更
az storage blob set-tier \
  --account-name stmyappprod001 \
  --container-name logs \
  --name "2025/01/access-log.csv" \
  --tier Cool \
  --auth-mode login

# ストレージアカウントのデフォルトアクセス層を変更
az storage account update \
  --name stmyappprod001 \
  --resource-group rg-storage-prod \
  --access-tier Cool

コスト試算の考え方

たとえば、毎月100GBのログデータが生成され、1年間保存する必要があるケースを考えます。

直近1か月のログはHot層（頻繁に参照する）
1〜3か月前のログはCool層（時々参照する）
3か月〜1年前のログはCold層（ほぼ参照しない）

すべてをHot層に保存した場合と比較すると、このような階層化戦略でストレージコストを40〜60%削減できます。

ライフサイクル管理ポリシーの設定

アクセス層の変更を手動で行うのは現実的ではありません。ライフサイクル管理ポリシーを使えば、ルールに基づいてBlobのアクセス層変更や削除を自動化できます。

ポリシーの定義例

以下は、ログデータのライフサイクルを自動管理するポリシーの例です。

{
  "rules": [
    {
      "enabled": true,
      "name": "move-logs-to-cool",
      "type": "Lifecycle",
      "definition": {
        "actions": {
          "baseBlob": {
            "tierToCool": {
              "daysAfterModificationGreaterThan": 30
            }
          }
        },
        "filters": {
          "blobTypes": ["blockBlob"],
          "prefixMatch": ["logs/"]
        }
      }
    },
    {
      "enabled": true,
      "name": "move-logs-to-cold",
      "type": "Lifecycle",
      "definition": {
        "actions": {
          "baseBlob": {
            "tierToCold": {
              "daysAfterModificationGreaterThan": 90
            }
          }
        },
        "filters": {
          "blobTypes": ["blockBlob"],
          "prefixMatch": ["logs/"]
        }
      }
    },
    {
      "enabled": true,
      "name": "delete-old-logs",
      "type": "Lifecycle",
      "definition": {
        "actions": {
          "baseBlob": {
            "delete": {
              "daysAfterModificationGreaterThan": 365
            }
          }
        },
        "filters": {
          "blobTypes": ["blockBlob"],
          "prefixMatch": ["logs/"]
        }
      }
    }
  ]
}

このポリシーでは、logs/プレフィックスのBlobを30日後にCool層、90日後にCold層へ移行し、365日後に削除します。

# ライフサイクルポリシーの適用
az storage account management-policy create \
  --account-name stmyappprod001 \
  --resource-group rg-storage-prod \
  --policy @lifecycle-policy.json

アクセス制御とセキュリティ設定

Blob Storageのセキュリティは、本番環境で最も重要な設定項目です。誤った設定はデータ漏洩につながるため、慎重に設計しましょう。

認証方式の選択

Blob Storageへのアクセスには、主に以下の認証方式があります。

Microsoft Entra ID（推奨）：Azure RBACを使って、ユーザーやアプリケーションに最小権限のアクセスを付与する。Microsoft Entra IDの設定方法も参考にしてください
共有キー：ストレージアカウントのアクセスキーで認証する。フルアクセス権限が付与されるため、本番環境での使用は推奨されない
SAS（Shared Access Signature）：特定のリソースに対して、期限付きの限定的なアクセスを許可するトークン

SASトークンの生成と活用

SASトークンは、外部のクライアントやサービスに対して、一時的かつ限定的なアクセスを許可する場合に使用します。

# 特定のコンテナに対するSASトークンの生成（読み取り専用、24時間有効）
az storage container generate-sas \
  --account-name stmyappprod001 \
  --name images \
  --permissions r \
  --expiry $(date -u -d "+24 hours" +%Y-%m-%dT%H:%MZ) \
  --auth-mode login \
  --as-user

SASトークンの運用で守るべきルールは以下のとおりです。

有効期限は最短にする：必要な期間だけアクセスを許可する
権限は最小限にする：読み取りだけで良い場合は読み取り権限のみを付与する
HTTPS専用にする：SASトークンがネットワーク上で傍受されるリスクを防ぐ
ストアドアクセスポリシーを使う：SASトークンを無効化できるようにする

パブリックアクセスの無効化

本番環境では、ストレージアカウントレベルでパブリックアクセスを無効にすることを強く推奨します。

# パブリックアクセスの無効化
az storage account update \
  --name stmyappprod001 \
  --resource-group rg-storage-prod \
  --allow-blob-public-access false

この設定により、SASトークンやMicrosoft Entra ID認証なしでは、どのBlobにもアクセスできなくなります。

アプリケーションからの利用：SDK活用例

実際のアプリケーションからBlob Storageを操作する方法を、Node.jsのSDKを例に解説します。

Node.js SDKの基本操作

// @azure/storage-blob パッケージのインストール
// npm install @azure/storage-blob @azure/identity

const { BlobServiceClient } = require("@azure/storage-blob");
const { DefaultAzureCredential } = require("@azure/identity");

// Microsoft Entra IDによる認証（マネージドID対応）
const credential = new DefaultAzureCredential();
const blobServiceClient = new BlobServiceClient(
  "https://stmyappprod001.blob.core.windows.net",
  credential
);

// コンテナクライアントの取得
const containerClient = blobServiceClient.getContainerClient("images");

// Blobのアップロード
async function uploadFile(filePath, blobName) {
  const blockBlobClient = containerClient.getBlockBlobClient(blobName);
  await blockBlobClient.uploadFile(filePath, {
    blobHTTPHeaders: {
      blobContentType: "image/jpeg"
    }
  });
  console.log(`Uploaded: ${blobName}`);
}

// Blobの一覧取得
async function listBlobs(prefix) {
  const blobs = [];
  for await (const blob of containerClient.listBlobsFlat({ prefix })) {
    blobs.push({
      name: blob.name,
      size: blob.properties.contentLength,
      lastModified: blob.properties.lastModified,
      tier: blob.properties.accessTier
    });
  }
  return blobs;
}

// Blobのダウンロード
async function downloadBlob(blobName, destPath) {
  const blockBlobClient = containerClient.getBlockBlobClient(blobName);
  await blockBlobClient.downloadToFile(destPath);
  console.log(`Downloaded: ${blobName}`);
}

DefaultAzureCredentialを使うことで、ローカル開発時はAzure CLIの認証情報、Azure上ではマネージドIDの認証情報を自動的に利用します。接続文字列やアクセスキーをコードに埋め込む必要がなく、セキュリティリスクを低減できます。

大容量ファイルのアップロード

100MBを超えるような大容量ファイルの場合、並列アップロードを活用すると転送速度が向上します。

async function uploadLargeFile(filePath, blobName) {
  const blockBlobClient = containerClient.getBlockBlobClient(blobName);
  await blockBlobClient.uploadFile(filePath, {
    blockSize: 4 * 1024 * 1024, // 4MBブロック
    concurrency: 8,              // 8並列アップロード
    onProgress: (progress) => {
      console.log(`Uploaded ${progress.loadedBytes} bytes`);
    }
  });
}

静的Webサイトホスティングの設定

Azure Blob Storageは、静的Webサイト（HTML、CSS、JavaScript、画像のみで構成されるサイト）のホスティングにも利用できます。

静的サイトホスティングの有効化

# 静的Webサイトホスティングの有効化
az storage blob service-properties update \
  --account-name stmyappprod001 \
  --static-website \
  --index-document index.html \
  --404-document 404.html

この設定を行うと、$webという特別なコンテナが作成され、ここにアップロードしたファイルが静的サイトとして配信されます。URLはhttps://stmyappprod001.z11.web.core.windows.net/の形式です。

Azure CDNやAzure Front Doorと組み合わせることで、カスタムドメインの設定やグローバルなコンテンツ配信も実現できます。Azure App Serviceと比較して、サーバーサイド処理が不要なサイトではBlob Storageホスティングのほうがコストを大幅に抑えられます。