Azureを運用していると、あちこちのリソースが吐き出すログと向き合う場面が必ずやってきます。「仮想マシンのログを見たい」「アプリのエラーを追いたい」「誰がいつリソースを消したのか調べたい」——こうしたときに最終的にたどり着くのが、Log Analytics（ログ アナリティクス）という仕組みです。
ところが、いざMicrosoft Learnを開くと「ワークスペース」「KQL」「DCR」「テーブル」「保持期間」といった用語が一気に押し寄せてきて、「で、結局これは何をする道具なの？」と手が止まりがちです。私自身、Azureの監視まわりを学びはじめた頃、まさにここで一度つまずきました。
「Log AnalyticsってAzure Monitorと何が違うの？ Application Insightsとも被ってない？ KQLって難しそう…」
この記事では、その混乱をまず整理するところから始めます。ひとことで言ってしまえば、Log Analytics＝ログを貯めておく倉庫、KQL＝その倉庫を検索するための言語です。この記事では、ワークスペースという倉庫の正体、ログが「テーブル」という形で貯まる仕組み、そしてKQLの基礎（where／project／summarize）までを、短いクエリ例で噛み砕いて解説します。読み終わるころには、自分でLog Analyticsを開いて「まず一本、絞り込みクエリを書く」ところまでできるようになります。
まず棲み分け：Log Analytics・Azure Monitor・Application Insightsの関係
手を動かす前に、よく混同される3つの言葉の関係だけ整理しておきます。ここが曖昧なまま進むと、あとで必ず迷子になるからです。
Azure Monitorは、Azureの監視全体を束ねる「傘」だと思ってください。メトリック（数値の時系列）、アラート、ダッシュボードなど、監視にまつわる機能をまとめた大きな枠組みです。その傘の下に、Log AnalyticsとApplication Insightsがぶら下がっています。
この3者の役割分担は、次のように整理すると迷いません。
- Azure Monitor＝監視全体の傘。メトリック・アラート・ダッシュボードを統括する。
- Application Insights＝アプリの中身（APM）。応答時間・例外・依存関係など「アプリケーションのふるまい」を追う。
- Log Analytics＝あらゆるログの集約先。そこに貯まったログをKQLで掘る場所。
おもしろいのは、Application Insightsが集めたテレメトリも、その保存先は最終的にLog Analyticsのワークスペースだという点です。だからこそApp InsightsのデータもKQLで掘れるわけですが（この接点はあとで関連記事として紹介します）、本記事はLog Analytics＝ログを貯める倉庫と、それを検索するKQLに集中します。アラートやメトリックの統括はAzure Monitor側、アプリのAPMはApplication Insights側、と割り切って読み進めてください。
Log Analyticsワークスペースとは：ログを貯める「倉庫」
Log Analyticsワークスペースは、Azureのいろいろなリソースが吐き出すログを一箇所に集めて保管しておく「倉庫」です。仮想マシンのシステムログ、Azure ADのサインイン記録、リソースの操作履歴（アクティビティログ）、アプリのテレメトリ——こうしたバラバラの出所のログが、このワークスペースという一つの箱に流れ込んで貯まっていきます。
なぜわざわざ一箇所に集めるのか。答えは横断して検索・分析できるようにするためです。もしログがリソースごとにバラバラの場所にあったら、「先週の障害のとき、VMとアプリで何が起きていたか」を突き合わせるのは至難の業です。共通の倉庫に貯めておけば、そこに一本のクエリを投げるだけで複数のログをまたいで調べられます。
ワークスペース自体は、Azureポータルで「Log Analyticsワークスペース」を作成すれば数分で用意できます。作成時に決めるのはリソースグループ・名前・リージョンくらいで、身構えるほどの設定はありません。むしろ大事なのは「どのワークスペースに、どのログを集めるか」という設計のほうです。
実務では、いくつも作らずできるだけ集約するのが基本方針になります。倉庫が分散していると、結局また「横断できない」問題に逆戻りするからです。組織で1つ、あるいは環境（本番／検証）ごとに1つ、くらいの粒度に留めておくと、後々の分析がずっとラクになります。
ログは「テーブル」に貯まる：倉庫の中の棚割り
倉庫にログが貯まる、といっても、ぐちゃぐちゃに放り込まれるわけではありません。ワークスペースの中は、テーブルという単位できれいに棚分けされています。倉庫にたとえるなら、テーブルは「棚」であり、種類ごとにログの置き場所が決まっているイメージです。
たとえば、代表的なテーブルにはこんなものがあります。
- Heartbeat：エージェントが「生きてます」と定期的に送ってくる死活情報。
- AzureActivity：「誰がいつ、どのリソースに対して何をしたか」という操作の記録。
- SigninLogs：Entra ID（Azure AD）へのサインイン履歴。
- AppRequests：Application Insightsが集めた、アプリへのリクエスト記録。
そして重要なのが、それぞれのテーブルはスキーマ（列の定義）を持っているという点です。スキーマとは、Excelの表でいう「見出しの行」のようなもの。Heartbeatテーブルなら「いつ（TimeGenerated）」「どのコンピューターから（Computer）」といった列があらかじめ決まっていて、1件のログはその列に値が埋まった「1行」として記録されます。
この「テーブル＝列が決まった表」というイメージが、次に出てくるKQLを理解する土台になります。KQLは要するにこの表を絞り込んだり、集計したりする操作だからです。Excelの表をフィルタしたり、ピボットで集計したりする感覚に近い、と思っておくとハードルが下がります。
「巨大なExcelの表がテーブルごとに用意されていて、それをKQLでフィルタ＆集計する」——この一枚絵さえ持てれば、KQLはもう半分わかったようなものです。
KQLの基礎：倉庫を検索する言語
KQL（Kusto Query Language）は、Log Analyticsのログを検索・集計するための問い合わせ言語です。SQLを触ったことがある人なら「あれの親戚か」と感じるはずですが、KQLはもっと直感的に書けるように作られています。ポイントはパイプ（|）で処理をつなげていくという発想です。
KQLの基本形は、こうです。
テーブル名
| 操作1
| 操作2まず先頭にテーブル名（どの棚を見るか）を書き、そのあとに|で区切りながら「絞り込む」「列を選ぶ」「集計する」といった操作を順番につないでいきます。左から右へ、データが加工されながら流れていくイメージです。まずは覚えるべき3つの操作だけ、順に見ていきましょう。
where：条件で行を絞り込む
whereは、条件に合う「行」だけを残す操作です。Excelのフィルタそのものだと思ってください。たとえばHeartbeatテーブルから「過去1時間ぶんだけ」を取り出すなら、こう書きます。
Heartbeat
| where TimeGenerated > ago(1h)読み方はそのままで、「Heartbeatテーブルの中から、TimeGenerated（発生時刻）がago(1h)（今から1時間前）より新しい行だけ残す」という意味です。ago()は「今から◯前」を表すKQLの便利な関数で、ago(30m)（30分前）やago(7d)（7日前）のように書けます。ログ調査は「まず時間で絞る」のが鉄則なので、このwhere TimeGenerated > ago(...)は最初に覚える価値があります。
条件はandやorで組み合わせられます。「過去1時間で、かつ特定のコンピューターから」なら、こうです。
Heartbeat
| where TimeGenerated > ago(1h) and Computer == "web01"==は「等しい」の意味です（SQLの=とは違い、KQLでは2つ重ねます）。「等しくない」なら!=、「含む」ならcontainsが使えます。
project：欲しい列だけ選ぶ
projectは、表示する「列」を選ぶ操作です。テーブルには何十もの列があることが多く、そのまま見ると横に長すぎて読めません。そこでprojectで必要な列だけに絞ります。
Heartbeat
| where TimeGenerated > ago(1h)
| project TimeGenerated, Computer, OSTypeこれで「発生時刻・コンピューター名・OS種別」の3列だけがすっきり表示されます。whereが「行を減らす」のに対し、projectは「列を減らす」——この役割の違いを押さえておくと混乱しません。結果が見づらいと感じたら、まずprojectで列を絞る。これだけで調査効率がぐっと上がります。
summarize：集計する
summarizeは、行をまとめて集計する操作です。Excelでいうピボットテーブルにあたります。「コンピューターごとに、ログが何件あるか数える」なら、こう書きます。
Heartbeat
| where TimeGenerated > ago(1h)
| summarize count() by Computer読み解くと、「過去1時間ぶんを、Computer（コンピューター）ごとにグループ分けして、それぞれの件数（count()）を数える」という意味です。byのうしろに書いた列が「グループ分けの軸」になります。count()のほかにも、平均を出すavg()、合計のsum()、最大・最小のmax()／min()などが使えます。
この3つ——行を絞るwhere、列を選ぶproject、まとめるsummarize——を|でつなぐだけで、ログ調査の8割はこなせてしまいます。KQLは覚えることが山ほどあるように見えて、入り口はこの3つだけ。まずはここを体に入れるのが最短ルートです。
保持期間とアーカイブ：貯めっぱなしはコストになる
倉庫にログを貯める以上、避けて通れないのが保持期間（どれだけ長く保管するか）とコストの話です。ここを知らずに運用すると、あとで請求額を見て青くなることがあります。私も最初のうちは「とりあえず全部貯める」で痛い目を見かけました。
Log Analyticsのログには、大きく2つの「保管ステージ」があります。
1つ目が対話型保持（Interactive Retention）です。これは「いつでもKQLで即座に検索できる」状態でログを持っておく期間のこと。倉庫でいえば、取り出しやすい手前の棚に置いてある状態です。既定では一定期間ぶんが無料で、そこから先は期間を延ばすほど料金がかかります。日々の調査で使うのは、ほぼこの対話型のログです。
2つ目が長期アーカイブ（Archive）です。「頻繁には見ないけれど、監査やコンプライアンスのために年単位で残しておきたい」ログを、倉庫の奥の低コストな棚に移しておくイメージです。アーカイブは対話型より保管料が安い代わりに、すぐには検索できません。見たいときは「検索ジョブ」を回して一時的に取り出す、というひと手間が必要になります。
使い分けの考え方はシンプルで、よく調べる直近のログは対話型で短めに、長期保存が要るログはアーカイブへです。すべてを対話型で長期間持つと料金がかさむので、「直近◯日は対話型、それ以降はアーカイブ」という二段構えでコストを抑えるのが定石になります。テーブルごとに保持期間を個別に設定できるので、重要なログだけ長く、そうでないものは短く、と調整できます。
なお、収集するログの「量」そのものが課金の中心なので、そもそも不要なログを集めすぎない設計も効いてきます。とはいえ、収集の細かい制御（データ収集ルール＝DCRなど）やコスト最適化の踏み込んだ話は範囲が広いので、この記事では「対話型とアーカイブの二段構え」という骨格だけ押さえて、詳細は実践編に譲ります。
まずクエリを書いてみる
概念を押さえたら、あとは実際に一本書いてみるのが一番です。Azureポータルで対象のLog Analyticsワークスペースを開き、左メニューの「ログ」を選ぶと、KQLを入力する画面が出てきます。ここが、これまで説明してきたクエリを打ち込む場所です。
最初の一本としておすすめなのが、次のクエリです。エージェントを入れたVMがあれば、これで「どのマシンから、どれだけ死活情報が届いているか」がすぐ分かります。
Heartbeat
| where TimeGenerated > ago(24h)
| summarize count() by Computer
| sort by count_ descやっていることを順に追うと、「Heartbeatテーブルを開く」→「過去24時間で絞る」→「コンピューターごとに件数を数える」→「件数の多い順に並べる」です。最後のsort by count_ descは並べ替えで、count_はsummarize count()が自動で付ける件数の列名、descは降順（多い順）を意味します。where → summarize → sortと|でつないだだけの、ごくシンプルな組み立てです。
もしログの中身をそのまま眺めたいだけなら、集計せずに件数を絞って表示するのが手軽です。
AzureActivity
| where TimeGenerated > ago(1d)
| project TimeGenerated, Caller, OperationNameValue
| take 20これは「過去1日ぶんのアクティビティログから、時刻・操作した人・操作内容の3列を選び、先頭20件だけ表示する」クエリです。takeは「とりあえず数件だけ見たい」ときに使う操作で、大量のログを全部返させて画面を固まらせないための安全弁にもなります。まずtakeで中身を確認し、狙いが定まったらwhereで本格的に絞り込む——この流れが実務の基本動作です。
つまずきやすいのは、データがまだ貯まっていない状態でクエリを打って「結果ゼロ」に焦るケースです。ワークスペースを作りたてだったり、エージェントを入れた直後だったりすると、テーブルにログがまだ流れ込んでいないことがあります。その場合は時間をおいて再実行するか、ago(1h)をago(7d)のように広げて、そもそもデータが1件でもあるかを確認してみてください。
まとめ
この記事では、Log Analyticsを「ログを貯める倉庫」、KQLを「その倉庫を検索する言語」というたとえで、入門の骨格を通しで見てきました。要点を振り返っておきます。
- 棲み分け：Azure Monitorが監視の傘、Application Insightsがアプリの中身（APM）、Log Analyticsはログの集約先＋KQLで掘る場所。
- ワークスペース＝ログを一箇所に集める倉庫。横断分析のため、なるべく集約する。
- テーブル＝倉庫の中の棚。ログはスキーマ（列定義）を持つ表として貯まる。
- KQLの基礎＝
where（行を絞る）・project（列を選ぶ）・summarize（集計する）を|でつなぐ。まずはこの3つ。 - 保持＝すぐ検索できる対話型保持と、安く長期保管するアーカイブの二段構えでコストを抑える。
ここまでできれば、Azureのログを前にして「どこを開いて、まず何を打てばいいか」で固まることはもうありません。あとは調べたいテーブルを見つけて、whereで絞り、summarizeでまとめる——この基本動作を繰り返すだけで、たいていの調査はこなせます。
シリーズ導線：さらに深く学ぶ
本記事は入門編として「倉庫（ワークスペース）とテーブル、KQLの基礎、保持の考え方」に絞りました。実運用に踏み込むと、次のようなテーマが待っています。これらは実践編でまとめて扱います。
- データ収集ルール（DCR）とエージェント：どのログを、どこから、どう集めるかの制御。
- 横断クエリ（複数テーブル・複数ワークスペースをまたぐ検索）と、KQLの
joinや関数。 - ログアラート：KQLの結果を条件にアラートを鳴らす。
- コスト最適化とRBAC：収集量の抑制と、ワークスペースへのアクセス制御。
続きはこちら：Azure Log Analytics 実践編｜DCR・エージェント・横断クエリ・ログアラート・コスト最適化（準備中）
あわせて読みたい：
- Azure Application Insightsとは？APMの仕組み・テレメトリ・計装・基本メトリックを入門から解説（アプリの中身を追うAPM。集めたデータの保存先はLog Analyticsのワークスペース）
- Application Insightsで深掘り分析・運用する｜分散トレース・可用性テスト・スマート検出・サンプリング・KQL（App InsightsのデータをKQLで掘る、まさにLog Analyticsとの接点）
Azureのスキルを「年収」に変えるなら
ここまで手を動かせるようになったなら、そのスキルは市場価値のある武器です。私自身、クラウドの実務経験を軸に単価を上げてきました。今の職場で活かすのはもちろん、クラウドエンジニアとして転職・フリーランスで年収を上げたいなら、まずは自分の市場価値を知るところからです。
未経験・学生・ハイクラスなど、状況別におすすめのエージェントを比較した記事を用意しています。あわせてどうぞ。
