Azure Storage料金徹底解説とコスト削減5ステップ

2026年4月19日

Contents

1 Azure Storage の基本課金モデル
2 2026‑02 時点の主要ストレージ層別単価表
3 料金に影響を与えるポイント
4 コスト削減に向けた実践的 5 ステップ
5 モニタリング・アラート設定例
6 よくある落とし穴と対策
7 まとめと次のアクション
- 7.1 脚注

スポンサードリンク

Azure Storage の基本課金モデル

項目	説明
従量課金	使用した GB・リクエスト回数・データ転送量に対して課金。保存開始瞬間から容量料金が発生します。
ストレージ層（Tier）	Hot, Cool, Archive の 3 段階。層ごとに単価と最低保存期間が異なります。
アクセス料金	読み取り / 書き込みリクエスト、データ復元時の転送費用は別途従量課金です（層により単価が変わります）。
最小契約容量	Reserved Capacity を利用する場合は 1 TB〜。通常は最低保存期間のみが制限となります。

2026‑02 時点の主要ストレージ層別単価表

※ 本価格は「東日本 (Japan East)」リージョン、USD/JPY = 150 の為替レートで計算した概算です。
正確な数値は Azure 公式料金ページをご確認ください【^1】。

ストレージ層	単価（円 / GB / 月）	最低保存期間	アクセス料金の目安
Hot	約 2.8 円	0 日	高め（読み取り/書き込みともに従量課金）
Cool	約 1.4 円	30 日	中程度（リクエストごとに追加料金）
Archive	約 0.6 円	180 日	低め（復元時に転送費用が発生）

出典
- Azure 公式料金ページ – Blob Storage【^1】
- Azure 公式ドキュメント – Reserved Capacity の割引率【^2】

料金に影響を与えるポイント

要素	具体的な影響例
リージョン	同一単価でも日本国内と米国西部で約 5‑10% の差が生じることがあります。複数リージョンに跨ってデータを保管する場合は、各リージョンの料金表を個別に確認してください。
為替レート	Azure は基本価格を米ドルで設定しているため、JPY/USD の変動が直接円建て単価に反映されます。大幅な円安・円高時は見積もりと実際の請求額が乖離する可能性があります。
最低保存期間	Cool と Archive はそれぞれ 30 日、180 日の「最低保存期間」中に削除するとペナルティ（未満分の課金）が発生します。早期削除は割引対象外です。
データ転送	同一リージョン内での読み取りは無料ですが、別リージョンへの復元やインターネット経由のダウンロードは転送費用がかかります（Archive の復元は特に高額になることがあります）。

対策
- 予算策定時には「為替変動リスク」・「リージョン別価格差」を 5‑10% 程度のバッファとして見込む。
- 最低保存期間を超える前に削除したいデータは、事前に Cool → Hot の一時的な階層変更でペナルティ回避が可能です（ただし追加のストレージ単価が発生します）。

コスト削減に向けた実践的 5 ステップ

Step 1：使用状況の可視化と無駄データ抽出

手順	ポイント
1‑1 Azure Portal → Cost Management + Billing → 「コスト分析」	リソースタイプで「Storage」を絞り、期間は過去 30 日または 90 日を選択。
1‑2 「使用量」タブで GB 単位の容量とコストをグラフ化	コンテナ・アカウント別にフィルタリングし、急増傾向がある箇所を特定。
1‑3 「エクスポート」ボタンで CSV ダウンロード → Excel/Power BI で利用率 < 10 % の BLOB を抽出	データドリブンな削減対象リスト化がポイント。

前提条件
- アカウントに対して「Cost Management Reader」以上のロールが付与されていること。
- エクスポート先は Azure Storage アカウントか、Power BI のワークスペースへ接続できる環境を用意。

Step 2：アクセス頻度に応じた層（Tier）最適化

方法	手順概要
手動で階層変更 (Portal)	1. 対象コンテナ → 「設定」→「アクセストレアの変更」 2. Hot → Cool または Cool → Archive を選択し、適用開始日を指定 3. 保存すると次回請求サイクルから新単価が反映。
自動化（ライフサイクル管理ポリシー）	Step 4 で詳述するポリシーに「最終アクセス日 ≥ 30 日 → Cool」「最終アクセス日 ≥ 180 日 → Archive」等の条件を設定。

注意点
- Cool→Hot の逆転は、最低保存期間が過ぎていないと割引が無効になるため、必ず「保存開始日＋30 日」以降に実行してください。

Step 3：Reserved Capacity（予約容量）で最大 38% 割引を取得

3‑1. Reserved Capacity の概要と最新割引率

リージョン	1 年契約割引率	3 年契約割引率
Japan East	30 %〜34 %	35 %〜38 %
East US	28 %〜32 %	33 %〜36 %
West Europe	29 %〜33 %	34 %〜37 %

出典：Azure 公式ドキュメント – Reserved Capacity【^2】

3‑2. 購入前の必須チェックリスト

対象サービス：Blob Storage、Data Lake Storage Gen2（どちらも同一プランで適用可）。
最低購入単位：1 TB（実務上は 5 TB 以上を推奨）。
利用予測：過去 6 ヶ月の平均使用量が予約容量の 80‑90 % 程度であることを確認。過剰購入は無駄になるため、Azure Cost Management の「予約使用率」レポートでシミュレーション。
リージョン整合性：予約容量は同一リージョン内でのみ有効。マルチリージョン展開の場合は各リージョンごとに別途予約が必要。

3‑3. 購入手順（Portal）

Azure Portal → 「Reserved Capacity」 → 「新規予約」
サービス：Blob Storage または Data Lake Storage Gen2 を選択
容量：例）5 TB、期間は 1 年 または 3 年（長期ほど割引率が上昇）
リージョン：実際に使用しているストレージアカウントと同一を選択
「確認」→「購入」 → 完了後、Cost Management > 予約の使用状況で適用状態をモニタリング

3‑4. キャンセル・余剰分の扱い

キャンセル：原則不可（契約期間中は変更できません）。
余剰容量：同一サブスクリプション内で他リージョンへ 移行可能（ただし、移転手続きは Azure サポートに依頼）。

実装上のヒント：Reserved Capacity の利用率が 70 % 未満になる場合は、次回更新時に容量を減らすか、余剰分を他プロジェクトへ割り当てることを検討してください。

Step 4：ライフサイクル管理ポリシーで自動階層化・削除

4‑1. ポリシー定義例（JSON）

{
  &quot;rules&quot;: [
    {
      &quot;name&quot;: &quot;move-to-cool&quot;,
      &quot;enabled&quot;: true,
      &quot;definition&quot;: {
        &quot;actions&quot;: { &quot;baseBlob&quot;: { &quot;tierToCool&quot;: {} } },
        &quot;filters&quot;: {
          &quot;blobTypes&quot;: [&quot;blockBlob&quot;],
          &quot;prefixMatch&quot;: [&quot;&quot;],
          &quot;daysSinceModificationGreaterThan&quot;: 30
        }
      }
    },
    {
      &quot;name&quot;: &quot;move-to-archive&quot;,
      &quot;enabled&quot;: true,
      &quot;definition&quot;: {
        &quot;actions&quot;: { &quot;baseBlob&quot;: { &quot;tierToArchive&quot;: {} } },
        &quot;filters&quot;: {
          &quot;blobTypes&quot;: [&quot;blockBlob&quot;],
          &quot;prefixMatch&quot;: [&quot;&quot;],
          &quot;daysSinceModificationGreaterThan&quot;: 180
        }
      }
    },
    {
      &quot;name&quot;: &quot;delete-after-retention&quot;,
      &quot;enabled&quot;: true,
      &quot;definition&quot;: {
        &quot;actions&quot;: { &quot;baseBlob&quot;: { &quot;delete&quot;: {} } },
        &quot;filters&quot;: {
          &quot;blobTypes&quot;: [&quot;blockBlob&quot;],
          &quot;prefixMatch&quot;: [&quot;&quot;],
          &quot;daysSinceModificationGreaterThan&quot;: 365
        }
      }
    }
  ]
}

{

"rules": [

{

"name": "move-to-cool",

"enabled": true,

"definition": {

"actions": { "baseBlob": { "tierToCool": {} } },

"filters": {

"blobTypes": ["blockBlob"],

"prefixMatch": [""],

"daysSinceModificationGreaterThan": 30

}

{

"name": "move-to-archive",

"enabled": true,

"definition": {

"actions": { "baseBlob": { "tierToArchive": {} } },

"filters": {

"blobTypes": ["blockBlob"],

"prefixMatch": [""],

"daysSinceModificationGreaterThan": 180

}

{

"name": "delete-after-retention",

"enabled": true,

"definition": {

"actions": { "baseBlob": { "delete": {} } },

"filters": {

"blobTypes": ["blockBlob"],

"prefixMatch": [""],

"daysSinceModificationGreaterThan": 365

}

]

}

4‑2. ポリシー適用手順

手順	操作
Portal	Storage アカウント → 「データ管理」→「ライフサイクル管理」→「新しいポリシーを追加」→上記 JSON を貼り付けて保存。
CLI	`bash az storage account management-policy create --account-name <myAccount> --policy @lifecycle.json`（`lifecycle.json` に上記内容を保存）

4‑3. 前提条件・注意点

バージョニングが有効であること（Archive 移行前に必ずバージョン管理設定）。
ポリシーは 作成後最大 24 時間 で適用開始されるため、即時効果を期待しない。
daysSinceModificationGreaterThan は「最終更新日」基準のため、コピーやメタデータ更新もカウントする点に留意。

Step 5：スナップショット・古いバージョンの一括クリーンアップ

5‑1. 前提条件（スナップショット削除用コンテキスト取得）

# Azure PowerShell でストレージアカウントへの認証コンテキストを作成
$accountName = &quot;myStorage&quot;
$key         = (Get-AzStorageAccountKey -ResourceGroupName rg-demo -Name $accountName)[0].Value
$ctx         = New-AzStorageContext -StorageAccountName $accountName -StorageAccountKey $key

# Azure PowerShell でストレージアカウントへの認証コンテキストを作成

$accountName = "myStorage"

$key = (Get-AzStorageAccountKey -ResourceGroupName rg-demo -Name $accountName)[0].Value

$ctx = New-AzStorageContext -StorageAccountName $accountName -StorageAccountKey $key

必須ロール：Storage Blob Data Contributor 以上が付与されていること。

5‑2. PowerShell によるスナップショット一括削除（30 日超過）

$container = &quot;logs&quot;
$cutoff    = (Get-Date).AddDays(-30)

# 指定コンテナ内の全 Blob を取得し、30日以上前のスナップショットだけを抽出・削除
Get-AzStorageBlob -Container $container -Context $ctx |
  Where-Object { $_.SnapshotTime -and $_.SnapshotTime -lt $cutoff } |
  ForEach-Object {
      Write-Host &quot;Deleting snapshot: $($_.Name) @ $($_.SnapshotTime)&quot;
      Remove-AzStorageBlob -Blob $_.Name -Container $container `
                           -Context $ctx -SnapshotTime $_.SnapshotTime
  }

$container = "logs"

$cutoff = (Get-Date).AddDays(-30)

# 指定コンテナ内の全 Blob を取得し、30日以上前のスナップショットだけを抽出・削除

Get-AzStorageBlob -Container $container -Context $ctx |

Where-Object { $_.SnapshotTime -and $_.SnapshotTime -lt $cutoff } |

ForEach-Object {

Write-Host "Deleting snapshot: $($_.Name) @ $($_.SnapshotTime)"

Remove-AzStorageBlob -Blob $_.Name -Container $container `

-Context $ctx -SnapshotTime $_.SnapshotTime

}

5‑3. Azure CLI による古いバージョン削除（90 日超過）

# バージョニングが有効なコンテナ「archive」から、最終更新日が90日前より前のオブジェクトを一括削除
az storage blob delete-batch \
  --account-name myStorageAccount \
  --source archive \
  --if-modified-since &quot;$(date -d '90 days ago' +%Y-%m-%dT%H:%M:%SZ)&quot;

# バージョニングが有効なコンテナ「archive」から、最終更新日が90日前より前のオブジェクトを一括削除

az storage blob delete-batch \

--account-name myStorageAccount \

--source archive \

--if-modified-since "$(date -d '90 days ago' +%Y-%m-%dT%H:%M:%SZ)"

5‑4. 実装上のベストプラクティス

バックアップ取得：削除前に az storage blob download-batch で対象をローカルまたは別リージョンへコピー。
定期実行：Azure Automation または Azure Functions の Timer Trigger で週次・月次実行するスクリプトを作成し、失敗時はメール/Teams 通知を設定。

モニタリング・アラート設定例

項目	推奨手段
総容量増加率	Cost Management の「予算」機能で月間 5 % 超過時にメール通知。
Cool/Archive への自動移行遅延	Azure Monitor のカスタムメトリック `Microsoft.Storage/storageAccounts/blobServices` の `BlobTierChangeCount` をクエリし、閾値を設定。
スナップショット容量比率	Log Analytics ワークスペースで以下 KQL クエリを実行し、スナップショットが全体の 20 % 超えたらアラート: `StorageBlobInventory \| where Type == "Snapshot" \| summarize totalSnap = sum(Size) by AccountName \| join (StorageBlobInventory \| summarize total = sum(Size) by AccountName) on AccountName \| extend ratio = todouble(totalSnap)/todouble(total) \| where ratio > 0.2`

よくある落とし穴と対策

落とし穴	原因	対策
割引率が実際より高いと誤認	Reserved Capacity の割引は「リージョン別」「期間別」で変動するため、全体平均だけを見る。	公式ドキュメントのテーブル【^2】を必ず参照し、見積もりツール（Azure Pricing Calculator）でシミュレーション。
最低保存期間違反によるペナルティ	Cool/Archive のデータを期限前に削除したまま放置。	削除スクリプト実行前に `daysSinceModificationGreaterThan` 条件を満たすか確認、または一時的に Hot に戻す手順を組み込む。
リージョン間のデータ転送コスト見落とし	同一アカウント内でもリージョン横断レプリケーションが有効化されているケース。	Azure Monitor の「Network Outbound」メトリックで転送量を監視し、不要な Geo‑Replication をオフにする。
スナップショット削除時のコンテキスト取得漏れ	スクリプト実行環境が Azure AD 認証のみでキー取得を省略した結果、`New-AzStorageContext` が失敗。	Service Principal に `Storage Blob Data Contributor` ロール付与し、キーまたは SAS トークンで明示的にコンテキスト生成。

まとめと次のアクション

料金体系を正確に把握
Hot / Cool / Archive の単価と最低保存期間、リージョン・為替リスクを認識する。
可視化 → 最適化 → 自動化 の 3 ステップでコスト削減サイクルを構築
Step 1 で「どこに無駄があるか」を数値化。
Step 2・3 で 層最適化 + Reserved Capacity を実行し、最大 38 % の割引を獲得。
Step 4・5 で ライフサイクル管理ポリシー と スナップショットクリーンアップ を自動化し、ヒューマンエラーを排除。 |
モニタリングとアラート を設定し、予算超過やポリシー未適用をリアルタイムで検知。 |
定期レビュー（四半期ごと）で使用量・割引率の変化を確認し、Reserved Capacity の再調整やリージョン移行の可否を判断。 |

最終的な目標：Azure Blob と Data Lake Storage の総コストを 30 % 以上削減 しつつ、パフォーマンスとデータ保全性は維持することです。まずは「Cost Management + Billing」で現在の使用状況を把握し、本ガイドの Step 1〜5 を順に実装してください。

脚注

[^1]: Azure 公式料金ページ – Blob Storage (2026‑02 更新)
https://learn.microsoft.com/ja-jp/azure/storage/blobs/scalability-targets

[^2]: Reserved Capacity（予約容量）ドキュメント – 割引率と利用条件 (2026‑02)
https://learn.microsoft.com/ja-jp/azure/storage/common/reserved-capacity

スポンサードリンク

-Azure

comment コメントをキャンセル

: Azure

Azure Cost Managementでのコスト可視化と削減ベストプラクティス

Azure Cost Management を用いたコスト可視化、タグ付けポリシー設定、未使用リソースの自動シャットダウン、右サイズ化、RI・Savings Plans の選択、Spot VM とオートスケールによる最適化手順を網羅的に紹介します。

: Azure

Azure OpenAI Service 2026年大型アップデートと中小企業活用事例

Azure OpenAI Serviceは2026年1月にUI刷新とマルチモーダル・カスタムモデル拡張を加え、中小企業でも安全かつ迅速に導入できる基盤となりました。

: Azure

Azure Maia 200 AIアクセラレーションの設定と活用ガイド

本稿では Azure Maia 200 の導入前提条件から VM の作成、Maia Runtime と Azure ML Extension のインストール、モデルのデプロイ方法、ベンチマーク測定と最適化手法までを実務で使える形で紹介します。

: Azure

東日本・西日本 Azure リージョン比較と選定ポイント【2026年】

Japan East と Japan West のリージョン概要、拡張ロードマップ、サービス対応率、主要サービス別価格・レイテンシ比較を解説し、実務チェックリストとFAQで選定を支援します。

: Azure

中小企業向け Azure コスト最適化ガイド：3ステップと7つのテクニック

本ガイドでは中小企業が直面する Azure の高額費用課題を、Cost Management と Advisor による現状把握から、未使用リソースの自動シャットダウンや RI・Savings Plans の導入、Power BI ダッシュボードによる継続的可視化まで、実践的な3ステップと7つのテクニックで具体的に示します。

Kotlin Multiplatform の基本と2024以降の最新アップデート・導入事例

Instagramショッピング商品登録手順【2026年最新】

Azure Storage料金徹底解説とコスト削減5ステップ

Azure Storage の基本課金モデル

2026‑02 時点の主要ストレージ層別単価表

料金に影響を与えるポイント

コスト削減に向けた実践的 5 ステップ

Step 1：使用状況の可視化と無駄データ抽出

Step 2：アクセス頻度に応じた層（Tier）最適化

Step 3：Reserved Capacity（予約容量）で最大 38% 割引を取得

3‑1. Reserved Capacity の概要と最新割引率

3‑2. 購入前の必須チェックリスト

3‑3. 購入手順（Portal）

3‑4. キャンセル・余剰分の扱い

Step 4：ライフサイクル管理ポリシーで自動階層化・削除

4‑1. ポリシー定義例（JSON）

4‑2. ポリシー適用手順

4‑3. 前提条件・注意点

Step 5：スナップショット・古いバージョンの一括クリーンアップ

5‑1. 前提条件（スナップショット削除用コンテキスト取得）

5‑2. PowerShell によるスナップショット一括削除（30 日超過）

5‑3. Azure CLI による古いバージョン削除（90 日超過）

5‑4. 実装上のベストプラクティス

モニタリング・アラート設定例

よくある落とし穴と対策

まとめと次のアクション

脚注

Step 1：使用状況の可視化と無駄データ抽出

Step 2：アクセス頻度に応じた層（Tier）最適化

Step 3：Reserved Capacity（予約容量）で最大 38% 割引を取得

Step 4：ライフサイクル管理ポリシーで自動階層化・削除

Step 5：スナップショット・古いバージョンの一括クリーンアップ