はじめに
Log Analytics ワークスペースのデフォルト保持期間は 30 日。でも、Log Analytics 側の保持期間を 90 日に延ばすと、分析状態のデータ保持はコストが高い です。
本記事では Log Analytics は 30 日、Blob Storage にエクスポートして 90 日 という構成で、コストを抑えつつ長期保持を実現する方法を紹介します。
全体アーキテクチャ
| 層 | 保持期間 | 用途 | コスト感 |
|---|---|---|---|
| Log Analytics（分析保持） | 30 日 | KQL でリアルタイム分析・アラート | 高（GB あたり課金） |
| Blob Storage | 90 日 | 長期保管・監査・振り返り | 低（ストレージ料金のみ） |
💡 Log Analytics の長期保持（旧アーカイブ）との違い:
ワークスペース内で「総保持期間」を最大 12 年まで延ばすことも可能です（長期保持期間中は検索ジョブ経由でのみアクセス可）。ただし、改ざん防止が必要な場合や外部ツールで参照したい場合は Blob エクスポートが適しています。要件に応じて使い分けてください。
Step 1：Log Analytics の保持期間を確認
デフォルト 30 日のままでOKです。変更する場合：
- Azure Portal → Log Analytics ワークスペース
- [使用量と推定コスト] → [データ保有期間]
- スライダーで日数を設定（30 / 60 / 90 / ... / 730 日）
⚠️ 31 日分の分析保持はインジェスト料金に含まれています。30 日→ 31 日に延ばしてもコスト増はありません。逆に 30 日未満にしてもコストは下がりません（API/CLI でのみ 4 日まで短縮可）。
Step 2：データエクスポートルールの設定
Log Analytics に到着したデータを リアルタイムで Blob Storage に自動エクスポート します。
Azure Portal での設定手順
- Log Analytics ワークスペース → [データ エクスポート]
- [新しいエクスポートルール] をクリック
- ルール名を入力（例:
export-to-blob-90d） - エクスポートするテーブルを選択
FunctionAppLogsADFPipelineRunADFActivityRun-
AzureDiagnostics（PostgreSQL 用）
- 宛先に Storage Account を選択
- 作成
エクスポートされるデータの構造
Storage Account
└ am-functionapplogs/ ← コンテナ（自動作成）
└ WorkspaceResourceId=.../y=2026/m=04/d=28/h=17/m=30/
└ PT05M.json ← 5分ごとの追加Blob（JSON）
| 項目 | 内容 |
|---|---|
| コンテナ名 |
am-<テーブル名> で自動作成 |
| ディレクトリ |
y=YYYY/m=MM/d=DD/h=HH/m=mm の階層 |
| ファイル |
PT05M.json（5分間のログが追記。50,000 件超で連番ファイル） |
| 形式 | JSON（追加 Blob） |
📝 注意点:
- エクスポートルール作成前に取り込まれたログは遡ってエクスポートされません（作成後の新規データのみ）
- Storage Account は Log Analytics と同じリージョン に配置する必要があります
- Storage Account のネットワーク設定で 「信頼された Microsoft サービス」を許可 しておく必要があります
Step 3：Blob Storage のライフサイクル管理ポリシー
ここが肝です。Blob 側で「90 日経過したら自動削除」のルール を設定します。
Azure Portal での設定手順
- Storage Account → [データ管理] → [ライフサイクル管理]
- [ルールの追加] をクリック
- 設定内容：
| 設定項目 | 値 |
|---|---|
| ルール名 | delete-after-90days |
| ルールのスコープ | 「ルールをストレージ アカウント内のすべての BLOB に適用する」 or フィルタでプレフィックス指定 |
| Blob の種類 | 追加 Blob（Append Blob）を含める |
| アクション | 最終変更から 90 日後に削除 |
Blob の種類に注意！
Log Analytics のデータエクスポートは 追加 Blob（Append Blob） で出力されます。ライフサイクルルール作成時に「Blob の種類」で Append Blob を対象に含めている ことを必ず確認してください。
⚠️ ブロック Blob 用のルールだけ作っても追加 Blob は削除されません。これはハマりポイントです。
プレフィックスフィルタ（オプション）
テーブルごとに異なる保持期間を設定したい場合は、プレフィックスフィルタを使います：
am-functionapplogs/ → 90 日
am-adfpipelinerun/ → 180 日
am-adfactivityrun/ → 180 日
全体の保持期間イメージ
Day 0 Day 30 Day 90
|←── Log Analytics（KQL で即座にクエリ可）──→|
|←──────── Blob Storage（JSON で長期保管）──────────→|
↑ 自動削除
- 直近 30 日: Log Analytics で KQL 分析・アラート・ダッシュボード
- 31〜90 日: Blob Storage から JSON をダウンロードして確認
- 91 日〜: 自動削除（ライフサイクル管理）
コスト最適化のポイント
| 施策 | 効果 |
|---|---|
| Log Analytics 保持は 30 日（デフォルト）のまま | 分析保持の追加コストゼロ |
| Blob は Cool 層 を選択 | Hot 層比で約 50% のストレージコスト削減 |
| ライフサイクルで Hot → Cool → 削除の段階移行も可 | さらに細かいコスト最適化 |
| エクスポート対象テーブルを必要なものだけに絞る | エクスポート料金 + ストレージ料金の両方を削減 |
💡 データエクスポート自体にも エクスポート料金（GB あたり）がかかります。全テーブルを無差別にエクスポートするとコストが膨らむので、長期保持が必要なテーブルだけに絞りましょう。
おわりに
「Log Analytics 30 日 + Blob 90 日」は、コストと保持期間のバランスが取りやすい鉄板構成 です。設定自体は Portal の GUI でポチポチやるだけなので、構築フェーズの最初にサクッと入れておくのがおすすめです。
Blob のライフサイクル管理で Append Blob を対象に含める のだけ忘れずに。ここハマりポイントでした。