Azure Log Analytics Workspace設計入門｜ログ保持期間・コスト体系・テーブルプラン移行でAzureモニタリング費用を最適化する実践ガイド

オンプレでsyslogやsyslog-ngを使ってログを一元管理していたエンジニアがAzureに移行すると、まず戸惑うのが「ログの集め方が根本的に違う」という点です。Azure Monitorを使えばVMのログもKubernetesのログも一か所に集まりますが、その「一か所」に当たるのがLog Analytics Workspaceです。

セットアップ自体はAzureポータルから数分でできます。問題はその後です。「Workspaceはいくつ作るべきか」「保持期間は何日にすればいいか」「なぜ先月の請求が想定の2倍だったのか」。こういった設計・運用の判断基準を知らないまま走り出すと、コストが静かに積み上がっていきます。

この記事では、Log Analytics Workspaceの役割・料金体系・テーブルプランの選び方・Workspace数の設計判断を、オンプレ経験者の視点から体系的に解説します。2026年8月時点の料金情報をもとに、コスト削減の実践ポイントも具体的に示します。

Azure MonitorとLog Analytics Workspaceの関係を整理する

「Azure Monitor」と「Log Analytics Workspace」は混同されがちですが、役割が違います。整理しておきましょう。

AWSに慣れている方向けに言い換えると、Log Analytics WorkspaceはCloudWatch Logsに近い立場ですが、KQLという強力なクエリ言語を持ち、複数サービスのログを統一されたスキーマで横断検索できる点が大きく異なります。

ポイントは「メトリクスはWorkspaceに入らない」という点です。VMのCPU使用率はAzure Monitorメトリクスストアに格納されており、Workspaceへの転送は別途設定が必要です。ログ（テキスト形式のイベントデータ）のみがWorkspaceに流れ込みます。

Azure Monitorの全体像については、Azure Monitor入門｜ログ収集・メトリクス・アラート設定をゼロから学ぶ実践ガイドで詳しく解説しています。本記事ではWorkspace設計に絞って掘り下げます。

Workspace数の設計判断——単一か複数か

Workspaceを何個作るかは、最初の設計フェーズで必ず議論になります。「環境ごとに作る？チームごとに作る？」という議論です。

1. 単一Workspaceを選ぶべき場面

原則は「1組織1Workspace」からスタートすることです。理由は次のとおりです。

・KQLで横断クエリが簡単: 複数サービスのログを一つのWorkspaceに集めると、サービスをまたいだ相関分析がKQL1本で書けます。Workspaceが分かれると結合クエリが複雑になります。
・コミットメント層の適用が有利: 後述するコミットメント層（日次取り込みGB単価の割引）はWorkspaceごとに適用されます。ログ量を集約すればコミットメント層のしきい値に早く到達し、割引が受けやすくなります。
・権限管理がシンプル: Workspaceへのアクセス権はAzure RBACで制御できます。テーブルレベルのアクセス制御（TBAC）を使えば、単一Workspace内でもチームごとにアクセスを分離できます。

2. 複数Workspaceが必要な場面

以下のような要件がある場合は、Workspaceを分割する正当な理由になります。

・データ主権・コンプライアンス: GDPRや各国データローカライズ法により、特定国のリージョン外にデータを出せない場合。Workspaceはリージョン単位で作成するため、国別にWorkspaceを分ける必要があります。
・完全分離が必要な環境: 本番環境のログを開発チームに絶対に見せられない、監査法人から環境分離の証明を求められるなど、論理的分離では不十分な規制要件がある場合。
・Azure Sentinelの導入: セキュリティ情報イベント管理（SIEM）にAzure Sentinelを使う場合、Sentinel用のWorkspaceを運用ログとは分けることが一般的です（課金体系が異なるため）。

3. 判断のまとめ

料金体系を正しく理解する

Log Analytics Workspaceの料金は大きく「データ取り込み」と「データ保持」の2軸で構成されます。ここを押さえないとコスト試算が的外れになります。

1. データ取り込み料金（Pay-as-you-go vs コミットメント層）

データ取り込みには2種類の料金モデルがあります（2026年8月時点・東日本リージョン）。

コミットメント層は1日単位で切り替えられ、購入した量を超えた分は従量課金が適用されます。重要なのは「過去31日間の平均取り込み量を見て、コミットメント層が従量課金より安くなるしきい値を超えているか」を定期的に確認することです。

Azure Cost Managementのコスト分析でWorkspace単位のログ取り込み量を確認する方法は、Azure Cost Management入門で解説しています。

2. データ保持料金

Workspaceに取り込んだログの保持にも料金がかかります。保持期間は2段階で設計します。

・インタラクティブ保持（Interactive retention）: KQLでリアルタイムクエリ可能な期間。デフォルト30日、最大730日（2年）。無料枠として最初の31日間は追加料金なし。それ以降は$0.12/GB/月（目安）。
・長期保持（Long-term retention / Archive）: インタラクティブ保持期間を超えたログを低コストで格納する期間。最大12年。料金は約$0.02/GB/月と大幅に安くなるが、クエリには別途$0.10/GB（1クエリあたり）の「アーカイブ検索」コストがかかります。

長期保持は「監査要件で7年間ログを持たなければならないが、日常的には直近3か月しか見ない」というケースで効果を発揮します。全期間をインタラクティブ保持にしていると料金が跳ね上がります。

3. 料金シミュレーション（月次）

月次取り込み3TB、インタラクティブ保持90日のケースで比較してみます。

この試算は概算であり、実際の料金はリージョン・テーブルプランの構成によって変わります。Azureの料金計算ツールで実環境に即した試算を行うことを強くお勧めします。なお料金は2026年8月時点のものであり、変更になる場合があります。

テーブルプランの使い分けがコスト削減の鍵

2023年以降にAzureが導入した「テーブルプラン」は、Log Analytics Workspaceのコスト最適化において最も影響が大きい機能です。ここを知らずに全ログをデフォルト設定のままにしていると、大幅なコスト過払いになっている可能性があります。

1. 3つのテーブルプランの概要

料金はすべて2026年8月時点の目安であり、リージョン・為替によって変動します。

2. どのログをどのプランに割り当てるか

判断の基準は「どれくらいの頻度で、どんな用途でクエリするか」です。

・Analyticsプランに向くログ: Azure Activity Logs（操作履歴）、AzureAD SigninLogs（認証ログ）、Securityイベント、アラートのトリガーに使うログ。頻繁に検索し、アラートルールの評価にも使われます。
・Basicプランに向くログ: アプリケーションの詳細デバッグログ、ContainerLog（Kubernetesの標準出力）、大量に吐き出されるVMのパフォーマンスカウンター（秒単位）。インシデント発生時に直近8日分だけ確認できれば十分なことが多い。
・Auxiliaryプランに向くログ: 内部監査のためだけに長期保存が義務づけられているが、日常的には検索しないフロー系ログ・ファイアウォールログの大量データ。

3. プラン変更の手順（Azure CLIで設定）

# Azure CLI — テーブルのプランをBasicに変更する例
# 対象テーブル: ContainerLog（AKSの標準出力ログ）

az monitor log-analytics workspace table update \
  --resource-group myResourceGroup \
  --workspace-name myWorkspace \
  --name ContainerLog \
  --plan Basic

# Analyticsに戻す場合（テーブル名ごとに設定可能）
az monitor log-analytics workspace table update \
  --resource-group myResourceGroup \
  --workspace-name myWorkspace \
  --name ContainerLog \
  --plan Analytics

テーブルプランの変更はAzureポータルの「Log Analytics Workspace」→「テーブル」からGUIでも操作できます。変更後は翌日以降の取り込みから新しいプランが適用されます。

保持期間の設計——インタラクティブと長期保持の組み合わせ

保持期間の設計は「コンプライアンス要件を満たしながら、コストを最小化する」という二律背反を解消する作業です。

1. 保持期間の設計フロー

まず以下を確認します。

・コンプライアンス要件の確認: PCI DSS（1年）、SOC 2（1年）、HIPAA（6年）、金融系日本法令（一般的に5～7年）など。要件によってログの「保持義務期間」が決まります。
・実際の検索需要の確認: 「直近何日分を日常業務で検索するか」を現場運用チームに確認します。多くの場合、日常クエリは直近30日以内、インシデント対応でも90日以内で完結します。
・長期保持の適用範囲を決める: コンプライアンス保持が必要でも日常クエリが不要なログは、インタラクティブ保持を短く設定し、長期保持（Archive）で差分を補います。

2. 設定例（Azure CLIで保持期間を設定）

# Azure CLI — テーブルごとの保持期間設定
# インタラクティブ保持: 90日、長期保持（合計）: 2555日（7年）

az monitor log-analytics workspace table update \
  --resource-group myResourceGroup \
  --workspace-name myWorkspace \
  --name AzureActivity \
  --retention-time 90 \
  --total-retention-time 2555

# Workspace全体のデフォルト保持期間を変更する場合
az monitor log-analytics workspace update \
  --resource-group myResourceGroup \
  --workspace-name myWorkspace \
  --retention-time 90

3. 保持設定の判断基準まとめ

コスト削減の実践Tips

1. DCR（データ収集ルール）でログをフィルタリングする

Data Collection Rule（DCR）はAzure Monitorの収集設定を定義するリソースです。DCRのKQLトランスフォームを使うと、Workspaceに書き込む前にデータをフィルタリング・変換できます。

例えば、Windowsイベントログの「情報（Information）」レベルのエントリは量が多く、セキュリティ上の価値が低い場合があります。DCRのトランスフォームで「Levelが4（情報）のエントリを除外」とすれば、取り込み量を大幅に削減できます。

# DCRのKQLトランスフォーム例（Windowsイベントの情報レベルを除外）
# DCR設定ファイル（JSON）の transformKql フィールドに記述

source
| where Level != 4

2. 不要なパフォーマンスカウンターを削減する

Windows / Linux AgentがデフォルトでWorkspaceに送信するパフォーマンスカウンター（Perf テーブル）は、サンプリング間隔を60秒や300秒に延ばすだけで取り込み量が大きく減ります。10秒サンプリングをデフォルトにしたまま放置しているケースが散見されます。

Azure Monitorエージェント（AMA）の場合、DCRのdata sourcesでパフォーマンスカウンターのサンプリング間隔を変更します。

3. Log Analyticsの使用量を定期モニタリングする

Workspaceには標準で「UsageBillableDataVolume」というログが記録されており、どのテーブルがどれくらいの量を吐き出しているか確認できます。

// KQL — テーブルごとの日次取り込み量を降順表示
Usage
| where TimeGenerated > ago(7d)
| where IsBillable == true
| summarize BillableGB = sum(Quantity) / 1024 by DataType, bin(TimeGenerated, 1d)
| order by BillableGB desc

このクエリを週次でScheduled Query Rulesにしておくと、急増したテーブルをすばやく特定できます。

4. Blob Storageへのエクスポートで長期コストを下げる

コンプライアンス上は長期保持が必要だが、アーカイブ検索すら不要なログは、Log Analytics Workspaceの長期保持（$0.02/GB/月）よりさらに安い選択肢があります。

Azure Monitor LogsのData Exportを使うと、Workspaceのデータを自動的にAzure Blob Storageに書き出せます。Blob StorageのCool層（$0.015/GB/月）やCold層（$0.004/GB/月）を使えば、長期保持コストをさらに下げられます。ただし検索には別途のETLパイプラインが必要になるため、「検索が不要で保存だけが目的」の場合に限定して検討します。

よくある落とし穴と対処法

【落とし穴1】デフォルト設定のままで保持コストが積み上がる

Workspaceを作成した直後の保持期間はデフォルト30日です。多くのチームはこれを変更せずに数か月運用し、ログが増えるにつれて「なぜこんなに請求が？」と気づきます。また、セキュリティやコンプライアンスの担当者が「7年保持が必要」と言っているにもかかわらず、設定が30日のままというミスもあります。
対処: Workspaceの作成直後に、テーブルごとの保持期間設定を確認・適用する手順をチェックリスト化してInfrastructure as Codeに組み込みます。

【落とし穴2】全テーブルをAnalyticsプランにしている

テーブルプランを意識したことがない場合、すべてのテーブルがAnalyticsプランになっています。ContainerLogやAzureDiagnosticsは大量データを生成するテーブルの代表格であり、これらにBasicプランを適用するだけでコストが劇的に変わることがあります。
対処: 前述のUsageクエリで上位10テーブルを特定し、日常的なアラートやダッシュボードに使っていないテーブルはBasicプランへの移行を検討します。

【落とし穴3】Heartbeatログが長期保持になっている

Heartbeatテーブルはエージェントの死活確認ログで、1分に1行吐き出します。これを長期保持に設定している場合、保持コストがかなりの割合を占めることがあります。Heartbeatは直近30日で十分という場合がほとんどです。
対処: Heartbeatテーブルの保持期間を30日に設定します。

【落とし穴4】Workspaceを作りすぎて管理コストが増大する

「環境ごとに作る」「チームごとに作る」を繰り返すと、気づけば10個以上のWorkspaceが存在し、コミットメント層の割引が受けられず、横断クエリも困難になります。
対処: Workspaceを統合してTBACで権限分離する方向を検討します。ただし、データ主権要件がある場合は統合できないため、要件を先に整理します。

本記事のまとめ

Log Analytics Workspaceはセットアップ自体は簡単ですが、設計を誤るとコストが静かに膨らみ続けます。本記事のポイントを整理します。

オンプレのsyslog構成では「ログサーバーを増設すればディスク代だけ」という感覚でしたが、クラウドでは「取り込んだ量」と「保持した期間」と「クエリした量」すべてに課金が発生します。この構造の違いを理解した上で設計を進めることが、Azureモニタリング環境のコスト最適化の第一歩です。