Azure Log Analyticsとは？主要機能や使い方、料金体系について解説

Azure Log Analyticsは、Azureやオンプレミス、他クラウドのログを一元収集し、障害調査・監視・監査対応を支える基盤です。現在は、ログ基盤全体をAzure Monitor Logs、保存先をLog Analytics workspace、分析画面をLog Analyticsと分けて理解するのが実務的で、「Azure Log Analytics」はそれらをまとめて指す呼び方として使われることが増えています。

クラウド運用が複雑になるほど、「どのログをどの保持期間で保存し、どこまでリアルタイム監視に使うか」の設計が重要になります。Azure Log Analyticsは、KQLによる詳細分析だけでなく、Analytics・Basic・Auxiliaryのテーブルプランや長期保持、Microsoft Sentinel連携によって、運用監視とコスト管理を両立しやすい点が強みです。


本記事では、Azure Log Analyticsの位置づけ、Azure Monitorとの違い、2026年3月時点の料金の見方、設定の進め方を整理して解説します。これから導入する担当者だけでなく、既存環境のワークスペース設計やコスト見直しをしたい方にも役立つ内容です。


✅Azure全体の監視基盤を先に整理したい方は、以下の記事も参考になります。
Azure Monitorとは？主な機能やメリット、料金をわかりやすく解説

Azure Log Analyticsとは

Azure Log Analyticsは、Azureのログ分析基盤を指す実務上の呼び方です。検索キーワードや現場の会話ではこの名称が広く使われていますが、現在は機能ごとの役割を分けて理解したほうが実務では扱いやすくなっています。

現在の公式上の位置づけ

Azure Monitor Logs は、Azureや非Azureのリソース、アプリケーションから生成されるテレメトリを収集、分析、活用するログ基盤です。
Log Analytics workspace は、そのログデータを保存するデータストアです。さらに Log Analytics は、Azureポータル上でクエリを実行する分析ツールです。

つまり、現在の理解としては次の3層で捉えるのが実務的です。

層	役割
Azure Monitor Logs	ログ収集・分析の基盤全体
Log Analytics workspace	ログを保存するワークスペース
Log Analytics	クエリを実行するポータル上の分析画面

本記事では検索上の分かりやすさを優先して「Azure Log Analytics」という表現を使いますが、導入設計ではこの3つを分けて理解しておくと混乱しません。

Azure Monitorとの関係

Azure Log Analyticsは、Microsoft Azure 全体の統合監視サービスであるAzure Monitorの中で、主にログ領域を担う存在です。Azure Monitorはメトリクス、ログ、トレース、イベントを横断して扱いますが、障害調査や詳細分析で中心になるのがAzure Monitor LogsとLog Analytics workspaceです。

(出典元：公式ホームページ)

両者の関係を整理すると、次のようになります。

観点	Azure Monitor	Azure Log Analyticsで担うこと
役割	監視全体の統合基盤	ログの収集、保存、検索、分析
主なデータ	メトリクス、ログ、トレース、イベント	ログとトレースをワークスペースに保存
主な使い方	アラート、Insights、Workbooks、Autoscale	KQL、Simple mode、ログアラート、エクスポート
判断ポイント	何を監視するか	どのログをどの保持期間で使うか

この切り分けを押さえておくと、「Azure Monitorを導入したが、どこでログを見るのか」「料金がどこで発生するのか」といった疑問が整理しやすくなります。

Azure Log Analyticsを使うメリット

Azure Log Analyticsの主な利点は、単なるログ置き場ではなく、運用とコスト管理を同時に設計しやすい点です。

• Azure、オンプレミス、他クラウドのログを一つのワークスペースに集約しやすい
• Simple modeとKQLの両方があり、非エンジニアと技術者で使い分けしやすい
• テーブル単位で料金プランや保持期間を変えられるため、重要ログと監査ログを分けて管理しやすい
• Workbooks、Power BI、アラート、外部出力まで同じ基盤上でつなげやすい

特に、日常監視ではAnalytics、たまに調べるログはBasic、監査や長期保管はAuxiliaryというように用途別に切り分けると、運用負荷とコストのバランスを取りやすくなります。

---

Azure Log Analyticsの主要機能

ここでは、Azure Log Analyticsを導入すると何ができるのかを、現在の機能整理に沿って確認します。

データ収集とルーティング

Azure Log Analyticsでは、Azureリソースのログ、アクティビティログ、オンプレミスや他クラウドのサーバーログなどを集約できます。

Azureリソースのリソースログは 診断設定 で送信し、仮想マシンやハイブリッドサーバーのゲストOSログは Azure Monitor Agent とDCRで収集するのが現在の基本です。

さらに、ワークスペース変換やDCR変換を使うと、不要な列やレコードを取り込み前に削減できます。これはクエリの見やすさだけでなく、取り込み課金を抑えるうえでも重要です。

KQLとLog Analyticsによる分析

Azure Log Analyticsの分析は、Log Analytics 画面から行います。現在は、Simple modeとKQL modeの2種類を使い分ける形です。

• Simple mode
  非エンジニアでも表計算のような操作で、絞り込み、並べ替え、集計を進めやすいモードです。
  
  
• KQL mode
  開発者や運用担当者が、複雑な条件抽出や相関分析、集計ロジックを細かく書きたいときに向くモードです。

KQLは読み取り専用のクエリ言語で、大量レコードでも比較的高速に分析できます。クエリを保存して再利用したり、アラートやワークブックに流用したりできる点も実務向きです。

可視化とアラート

Azure Log Analyticsは、クエリ結果を確認するだけでなく、運用監視の画面や通知に接続できるのが特徴です。公式ではWorkbooks、Azureダッシュボード、Power BI、Grafana、ログアラートなどが主な活用先として紹介されています。

ダッシュボードイメージ（参考：マイクロソフト）

Azure Monitor alerts を使えば、ログ検索アラートで高度な条件式を扱えます。Basicログではプレビューのシンプルなログアラートも使えますが、ログはメトリクスより遅延しやすいため、「データが来ないこと」を厳密に検知したい場面ではメトリクスアラートのほうが安定しやすい点に注意が必要です。

アクセス制御とワークスペース管理

Log Analytics workspace では、ワークスペース単位だけでなく、テーブルごとの保持やコスト、アクセス制御もまとめて管理できます。

また、Log Analytics Workspace Insightsを使うと、取り込み量、クエリ、変更履歴、ヘルスなどをまとめて確認できます。運用が安定してきた後も「どのテーブルが高コストか」「遅いクエリがないか」を継続的に見直せるため、導入後の改善サイクルを回しやすい設計です。

---

Azure Log Analyticsの仕組みと設計ポイント

機能を理解したうえで重要になるのが、どのような構成で使うかです。ここでは、収集から保管、分析、長期保存までの流れを整理します。

Azure Log Analyticsのデータの流れ

Azure Log Analyticsの基本的な流れは次の4段階です。

LogAnalytics流れイメージ（参考：マイクロソフト）

1. 監視対象を決める
   Azureリソースのリソースログ、アクティビティログ、VMのイベントログ、オンプレミスサーバーのSyslogなど、収集対象を決めます。

2. 収集方法を決める
   リソースログは診断設定、ゲストOSログはAzure Monitor AgentとDCR、カスタムログはLogs Ingestion APIなどを使って送信します。

3. ワークスペース内のテーブルへ保存する
   送信されたデータはLog Analytics workspace内のテーブルに格納され、テーブルごとにプラン、保持期間、変換、アクセスを管理します。

4. 分析と活用につなぐ
   Log Analytics、Workbooks、Power BI、アラート、データエクスポートなどへ接続し、運用フローに組み込みます。

この流れを最初に整理しておくと、「ログを取りたいのにテーブル設計だけ先に決めてしまう」「すべてAnalyticsにして費用が膨らむ」といった失敗を減らしやすくなります。

Azure Log Analyticsワークスペースの役割

Log Analytics workspaceは、ログを保存するだけの箱ではありません。テーブル単位の保持、アクセス制御、変換、検索、長期保存の設定を担う中核です。

Log Analyticsワークスペースイメージ(参考：マイクロソフト)

Log Analytics workspace には複数テーブルがあり、Azure側の標準テーブルに加えて非Azure向けのカスタムテーブルも作成できます。
また、保持はinteractive retentionとlong-term retentionの2段階で管理され、総保持期間は最長12年まで伸ばせます。

Azure Log Analyticsのテーブルプランの選び方

Azure Log Analyticsでコスト差が最も出やすいのがテーブルプランです。現在は、Analytics / Basic / Auxiliary の3種類を使い分ける形です。

観点	Analytics	Basic	Auxiliary
向いている用途	常時監視、リアルタイム検知、パフォーマンス分析	調査や障害対応で時々見るログ	監査保管、Verboseログ、大量低頻度ログ
クエリ	フルKQL、クエリ料金込み	単一テーブル中心、クエリ課金あり	単一テーブル中心、クエリ課金あり
アラート	対応	シンプルなログアラートに対応プレビュー	非対応
インサイト機能	対応	非対応	非対応
保持の基本	約1か月込み、SentinelやApplication Insightsでは90日表記	30日込み	30日込み
総保持	最長12年	最長12年	最長12年

常時ダッシュボード表示やアラート連携が必要ならAnalytics、障害時の掘り下げ用ログならBasic、監査や長期保管ならAuxiliaryと分けると判断しやすくなります。
特にBasicとAuxiliaryは安価ですが、分析頻度が高いとクエリ課金で逆転しやすいため、「安いから全部Basicにする」という設計は避けたほうが安全です。

Azure Log Analyticsの保持期間と長期保管

Azure Log Analyticsでは、短期の分析用保持と長期保管を分けて考えるのが基本です。

Analyticsでは通常約1か月、Microsoft SentinelやApplication Insightsを使う場合は90日の保持表記が案内されています。BasicとAuxiliaryは30日が基本で、それを超えると長期保持の料金が発生します。古いデータは検索ジョブやデータ復元を使って再分析できるため、「普段は安く保管し、必要時だけ深掘りする」運用が可能です。

Azure Log Analyticsで複数ワークスペースが向くケース

小規模環境ではワークスペースを集約したほうが管理しやすい一方、次の条件では分割が有効です。

• セキュリティログと運用ログで請求体系を分けたい
• 国や部門ごとにデータ所在地やアクセス権限を分けたい
• 障害時に重要ログだけ別リージョンへ多重送信したい

Log Analytics の設計ガイド でも、重要ログを複数ワークスペースへ多重送信する構成が紹介されていますが、重複取り込み分の課金が増える点には注意が必要です。
また、セキュリティ監視を Microsoft Sentinel で行う場合は、運用ログまで同じワークスペースに入れるとSentinel課金の影響範囲が広がるため、用途別にワークスペースを分ける判断が有効です。

---

Azure Log Analyticsの使い方

ここでは、現在の基本的な設定フローを整理します。

Azure Log Analyticsの事前準備

作業前に押さえておきたい前提は以下の通りです。

• Azureサブスクリプションと、ワークスペース作成権限があること
• どのログを集めるかを決めておくこと
• 監視対象がAzureリソースなのか、VMのゲストOSなのか、オンプレミスなのかを切り分けておくこと

ワークスペース自体の作成に大きなコストはかかりませんが、ログ取り込み後に課金が始まるため、先に収集対象と保持期間を決めておくと無駄なコストを避けやすくなります。

ステップ1 Azure Log Analyticsワークスペースを作成する

Create Log Analytics workspaces に沿った現在の基本手順は、AzureポータルでLog Analytics workspacesを検索し、サブスクリプション、リソースグループ、名前、リージョンを指定して作成する流れです。

大まかな流れは次の通りです。

1. Azureポータルで「Log Analytics workspaces」を開く
2. Createを選択する
3. サブスクリプション、リソースグループ、ワークスペース名、リージョンを入力する
4. Review + Createから作成を完了する

Azureポータル画面

LogAnalyticsワークスペース選択画面

LogAnalyticsワークスペース作成画面

基本タブ画面

確認と作成タブ画面

デプロイ完了画面

画面の細かなラベルは更新されることがありますが、検索からワークスペース作成へ進む大枠は変わっていません。リージョンは、監視対象に近い場所を選ぶと運用しやすくなります。

ステップ2 Azure Log Analyticsへログを送る

Azureリソースのリソースログは、診断設定 からワークスペースへ送ります。

一方で、仮想マシンやオンプレミスサーバーのゲストOSログを集める場合は、Azure Monitor AgentとDCRを使う構成が推奨です。公式チュートリアルでも、VMの診断設定はゲストOSログ収集用の旧方式と明記されています。

設定の流れは次の通りです。

1. 対象リソースのMonitoringからDiagnostic settingsを開く
2. Add diagnostic settingで送信カテゴリを選ぶ
3. 宛先にLog Analytics workspaceを指定する
4. 必要に応じてMetricsやresource-specific modeも調整する

VNet診断設定の追加画面

VNet診断設定保存画面

AllMetricsも同時にワークスペースへ送れますが、メトリクスをログ化するとデータ量が増えるため、メトリクスはメトリクスとして使うほうが安いケースもあります。

ステップ3 Azure Log Analyticsでクエリを実行する

ログ送信後は、Log Analytics 画面からデータを確認します。最初はQueries hubのサンプルクエリを起点にすると入りやすい構成です。

最初は次の流れで進めるとスムーズです。

1. ワークスペースまたは対象リソースのLogsを開く
2. Queries hubからサンプルクエリを選ぶ
3. Simple modeで傾向を確認する
4. 必要に応じてKQL modeへ切り替えて条件を細かく調整する

ログ選択画面

クエリ実行画面

運用初期は「どのテーブルに何が入るか」を把握することが重要です。クエリの最適化は後からでもできますが、テーブル設計や取り込みカテゴリの見直しは早いほど効果が出ます。

ステップ4 Azure Log Analyticsで可視化とアラートを設定する

ログを収集して終わりではなく、ワークブックやアラートに接続して初めて監視基盤として機能します。Azure Monitor alerts も含めて、ログ検索アラート、シンプルなログアラート、メトリクスアラートを使い分ける設計が基本です。

可視化と通知の流れは、次の順で進めると実務で扱いやすくなります。

1. まずはクエリ結果を表やグラフで確認する
2. 継続監視したいものはWorkbookやダッシュボードへ載せる
3. 即時通知が必要な条件はログ検索アラート化する
4. 欠損検知や閾値監視はメトリクスアラートと使い分ける

警告選択画面

推奨されるアラートルールの設定画面

アラートルール保存画面

Basicログは低コストですが、高度な可視化や常時監視の中心には向きません。日常監視はAnalytics、調査用はBasicという切り分けが分かりやすい運用パターンです。

---

Azure Log Analyticsの料金体系

Azure Log Analyticsの費用は、単純な「保存容量課金」ではありません。取り込み、クエリ、保持、エクスポート、復元、Sentinel連携の有無まで含めて見る必要があります。

Azure Log Analyticsの料金体系の構成要素

主要な課金要素は次の通りです。

• 取り込み量
  ワークスペースへ送信するデータ量です。通常もっとも大きい費用になります。
  
  
• クエリ量
  Analyticsはクエリ料金込みですが、BasicとAuxiliaryはスキャン量に応じて課金されます。
  
  
• 保持期間
  無料保持期間を超えた分と長期保管分に課金が発生します。
  
  
• 追加機能
  データエクスポート、データ復元、検索ジョブ、特定条件下のログ処理などが追加費用になります。

このため、見積もりでは「1日あたり何GB入るか」だけでなく、「そのログをどれくらいの頻度で検索するか」まで考える必要があります。

Azure Log Analyticsの価格例

以下は、2026年3月11日時点に Azure Monitor pricing と Azure Retail Prices API で確認した、Japan Eastリージョンの参考値です。請求通貨や契約形態により実際の請求額は変動するため、見積もり時は必ず最新の公式価格を確認してください。

項目	参考価格	補足
Analytics Logs取り込み	3.34 USD/GB	常時監視向け。クエリ料金込み
Basic Logs取り込み	0.725 USD/GB	低コストだがクエリ料金は別
Auxiliary Logs取り込み	0.07 USD/GB	監査保管や大量低頻度ログ向け
BasicとAuxiliaryのクエリ	0.00725 USD/GB scanned	スキャン量ベースで課金
Data Archive	0.029 USD/GB/月	長期保持の目安
Data Restore	0.145 USD/GB/日	復元して高性能に再分析する場合
Data Export	0.145 USD/GB	StorageやEvent Hubsへ継続出力
100 GB/日コミットメントティア	284.2 USD/日	実効単価 2.842 USD/GB

表から分かる通り、BasicやAuxiliaryは取り込み単価が大きく下がります。
ただし、頻繁に検索するログをBasicへ寄せすぎるとクエリ課金が積み上がるため、取り込み単価だけで判断しないことが重要です。

Azure Log Analyticsの価格注記

価格を見るうえで、特に押さえておきたい注記は以下の通りです。

• AnalyticsのPay-As-You-Goは、最初の5GB/月が請求アカウント単位で無料です
• Analyticsは約1か月、BasicとAuxiliaryは30日の保持が含まれます
• Microsoft Sentinelやworkspace-based Application Insightsを有効化すると、90日保持や別メーター課金の影響を受ける場合があります
• 取り込み時に50パーセントを超える大量フィルタリングを行うケースでは、ログ処理課金が発生する場合があります

なお、Analyticsの無料保持は公式資料で30日表記と31日表記が混在しているため、実際の見積もりでは価格ページとポータル設定の最新値を確認するのが安全です。
特にSentinel併用時は課金メーターが変わるため、運用ログとセキュリティログを同居させるかどうかを先に決めておくべきです。

Azure Log Analyticsの料金の読み解き

料金を見積もるときは、次の順で考えるとブレにくくなります。

1. まずログを「常時監視」「障害調査用」「監査保存用」に分類する
2. 常時監視はAnalytics、調査用はBasic、監査用はAuxiliaryやArchiveを候補にする
3. 1日あたりの取り込み量が100GBを超えそうなら、コミットメントティアも比較する
4. Microsoft Sentinelを使うなら、運用ログと同居させるかを別途判断する

Azure全体の請求構造を広く把握したい場合は、Azureの料金体系 と Azureの料金計算ツール も合わせて確認すると、より実務的な見積もりがしやすくなります。

---

Azure Log Analyticsの活用シーン

Azure Log Analyticsは、単に障害が起きた後に見るだけの仕組みではありません。監視、セキュリティ、監査、コスト最適化まで幅広く活用できます。

Azure Log Analyticsでの障害調査と運用監視

障害調査では、複数リソースの時系列ログを横断して見られることが大きな強みです。
たとえば、アプリの応答遅延、ロードバランサーのエラー、ネットワーク機器のログ、OSイベントを同じ時間帯で突き合わせると、どの層から異常が始まったかを追いやすくなります。

日常運用でも、エラーログ件数、特定例外の急増、処理時間の分布などをワークブックへ載せておくと、障害の予兆を早期に捉えやすくなります。

Azure Log Analyticsでのセキュリティ監視と監査対応

Azure Log Analyticsは、Azureのセキュリティ対策 と組み合わせることで、認証失敗や不審通信、権限変更の痕跡を追う基盤としても有効です。

運用上は、セキュリティ監視で使うログは保持期間が長くなりやすく、調査時の検索回数も増えがちです。そのため、通常の運用監視ログと分けて管理したほうが、課金や権限設計が分かりやすくなるケースが多くあります。

Azure Log Analyticsでのコスト最適化とガバナンス

Azure Log Analyticsでは、どのログがどれだけ課金に効いているかを可視化できるため、コスト最適化にも役立ちます。
たとえば、VerboseログをAnalyticsに残していた場合、BasicやAuxiliaryへ移すだけで費用が大きく下がることがあります。

また、長期保持やエクスポートを含めた設計を先に決めておくと、監査要件や社内ガバナンスにも対応しやすくなります。

Azure Log Analyticsでのハイブリッド環境の集約

Azureだけでなく、オンプレミスや他クラウドを含む環境でも、Azure ArcやAzure Monitor Agentを組み合わせることでログを集約できます。
マルチクラウドやハイブリッド環境では、監視基盤が分散しやすいため、Azure Log Analyticsのような一元基盤を用意しておくと、障害時の切り分けや権限管理が楽になります。

---

まとめ

Azure Log Analyticsを理解するときは、Azure Monitor全体と、Azure Monitor Logs、Log Analytics workspace、Log Analyticsツールの役割を分けて考えるのが重要です。これを曖昧にしたまま導入すると、料金や運用設計で迷いやすくなります。

特に2026年時点では、Analytics、Basic、Auxiliaryのテーブルプランをどう使い分けるかが、コストと運用品質を左右します。常時監視はAnalytics、障害調査用はBasic、監査保管はAuxiliaryや長期保持という切り分けが基本です。

また、Microsoft Sentinelや長期保持を前提とする場合は、ワークスペースを分けるかどうかまで含めて設計する必要があります。導入前に「何を監視し、どこまで即時検知し、何年残すか」を先に決めておくと、Azure Log Analyticsを無駄なく使いやすくなります。