先生と生徒の会話形式で理解しよう

生徒

「Azureで動かしているシステムが急に重くなったり、エラーが出たりしたとき、原因を調べる良い方法はありますか？」

先生

「そんなときはAzure Monitor（アジュール・モニター）の『ログ』を確認するのが一番です。KQL（クルト・クエリ・ランゲージ）という専用の言語を使うと、膨大なデータから一瞬で原因を見つけ出せますよ。」

生徒

「KQL...なんだか難しそうですね。初心者でも書けるようになりますか？」

先生

「大丈夫です！KQLは直感的で、読み書きしやすいのが特徴です。まずは基本の書き方から、障害調査に役立つ実践的なテクニックまで順番に学んでいきましょう！」

1. Azureログクエリ（KQL）とは？

Azure（アジュール）を利用していると、サーバーの動作記録やユーザーのアクセス履歴など、膨大な「ログ」が蓄積されます。これらを集約して管理するのがAzure Monitor Logs（アジュール・モニター・ログ）というサービスです。そして、その中から必要な情報を取り出すための道具がKQL（Kusto Query Language：クルト・クエリ・言語）です。

Kusto（クルト）という名前の由来は、フランスの海洋探検家ジャック＝イヴ・クストーから来ています。広大なデータの海を深く探索し、隠れた真実を見つけ出すという願いが込められているのです。SQL（エスキューエル）に似ていますが、よりパイプ記号「|」を活用した連鎖的な記述が得意で、左から右へ、上から下へと流れるように思考をコードに落とし込めるのが魅力です。

2. KQLの基本構造とパイプ記号の役割

KQLの書き方は非常にシンプルです。まず「どのテーブル（データの箱）を見るか」を指定し、その後にパイプ記号「|」を繋いで「どう加工するか」を命令していきます。これは、工場のベルトコンベアをイメージすると分かりやすいでしょう。

例えば、アクセスログが格納されているAppRequestsというテーブルから、特定の条件でデータを絞り込む場合は以下のように記述します。データの流れを意識することが、上達への近道です。


AppRequests
| where ResultCode == "500"
| take 10

このクエリは、「AppRequestsテーブルから」「結果コードが500（エラー）のものを選び」「最初の10件だけ表示する」という意味になります。非常に読みやすいですよね。

3. 障害調査に必須のwhere演算子でフィルタリング

システム障害が発生した際、まず最初に行うのが「時間の絞り込み」と「エラーの抽出」です。全期間のデータを眺めても原因は見つかりません。where演算子（ウェアー・えんざんし）を使いこなして、ノイズを除去しましょう。

以下の例では、直近24時間以内で発生した、応答時間が5秒以上かかっている遅いリクエストを探しています。トラブルシューティング（問題解決）の第一歩は、この絞り込みから始まります。


TimeGenerated        | Name          | DurationMs | ResultCode
---------------------+---------------+------------+-----------
2026-03-31 10:00:00  | GET /home     | 5500       | 200
2026-03-31 10:05:00  | POST /login   | 1200       | 200
2026-03-31 10:10:00  | GET /api/data | 8000       | 500
2026-03-31 10:15:00  | GET /search   | 300        | 200


AppRequests
| where TimeGenerated > ago(24h)
| where DurationMs >= 5000
| where ResultCode != "200"


    TimeGenerated        | Name          | DurationMs | ResultCode
    ---------------------+---------------+------------+-----------
    2026-03-31 10:10:00  | GET /api/data | 8000       | 500

このように、複数のwhereを重ねることで、どんどん条件を厳しくしていくことができます。

4. summarize演算子でエラーの発生傾向を分析する

個別のログを見るだけでなく、全体で何が起きているかを把握することも重要です。そこで使うのがsummarize（サマライズ：要約する）演算子です。これを使うと、データの件数を数えたり、平均値を計算したりできます。

例えば、「どのエラーが何回起きているか」を種類別に集計してみましょう。これにより、一番頻発している致命的な問題を特定できます。count()関数（カウント・かんすう）を組み合わせて使用します。


OperationName | ResultCode | ClientIp
--------------+------------+------------
GetOrder      | 500        | 192.168.1.1
GetOrder      | 500        | 192.168.1.2
PostPayment   | 403        | 192.168.1.1
GetOrder      | 500        | 192.168.1.3
PostPayment   | 403        | 192.168.1.5


AppRequests
| summarize ErrorCount = count() by OperationName, ResultCode
| order by ErrorCount desc


    OperationName | ResultCode | ErrorCount
    --------------+------------+-----------
    GetOrder      | 500        | 3
    PostPayment   | 403        | 2

集計結果から、GetOrderという処理でエラーが多発していることが一目でわかりますね。優先順位をつけて対応する際に非常に役立ちます。

5. render演算子でログを可視化（グラフ化）する

数字の羅列よりも、グラフで見たほうが異常に気づきやすい場合があります。KQLにはクエリ結果をそのまま図解するrender（レンダー：描画する）演算子があります。

障害が発生した時間帯にエラーが急増しているかを確認するために、時系列の折れ線グラフを表示してみましょう。bin()関数（ビン・かんすう）を使うと、時間を30分単位や1時間単位で区切ることができます。


AppRequests
| where TimeGenerated > ago(12h)
| summarize count() by bin(TimeGenerated, 30m)
| render timechart

Azure Portal（アジュール・ポータル）上でこのクエリを実行すると、綺麗なグラフが表示されます。急激なスパイク（突出した線）があれば、その時間に何らかの異常やデプロイ（システムの更新）があった可能性が高いと推測できます。視覚的に理解することは、チーム内での状況共有にも効果的です。

6. 複雑な文字列を解析するparse演算子

ログの中には、一つの項目にたくさんの情報が詰め込まれていることがあります。例えば「メッセージ」列の中に、ユーザーIDやエラー理由が混ざっている場合です。これをバラバラに分解して分析しやすくするのがparse（パース：解析する）演算子です。

以下の例では、自由な形式のログメッセージから特定のパターンを抽出して、新しい列を作っています。これにより、特定のユーザーだけに起きている問題なのか、全体の問題なのかを切り分けることができます。


RawData
-------------------------------------------
User:123 failed login from IP:10.0.0.1
User:456 failed login from IP:10.0.0.5
User:789 failed login from IP:10.0.0.1


AppLogs
| parse Message with "User:" UserId " failed login from IP:" SourceIP
| summarize LoginFailures = count() by SourceIP
| where LoginFailures > 1


    SourceIP | LoginFailures
    ---------+--------------
    10.0.0.1 | 2

このように、非定型なデータから意味のある情報を取り出す「データの整形」もKQLの得意分野です。セキュリティログの解析などでも頻繁に利用されるテクニックです。

7. 障害原因を特定するための実践的なワークフロー

最後に、実際の障害現場で役立つ調査の流れを整理しましょう。まずは広く浅く状況を把握し、徐々に深掘りしていくのが鉄則です。初心者のうちは、以下の手順をテンプレートとして覚えておくと落ち着いて対処できます。

ステップ1： ago()を使って、問題が起きた時間帯に絞り込む。
ステップ2： summarizeとrenderで、エラーの発生傾向を可視化する。
ステップ3： whereでエラーコードや例外メッセージを特定する。
ステップ4： project演算子で必要な列だけを選び、詳細なエラー内容を観察する。

Azure Monitorを活用すれば、以前は数時間かかっていた調査が、わずか数分で終わることも珍しくありません。KQLという強力な武器を手に、クラウドエンジニアとしてのスキルを一段上のレベルへ引き上げましょう！最初は難しく感じるかもしれませんが、コピー＆ペーストから始めて、少しずつ値を書き換えて試すだけでも十分に学習効果があります。

まとめ

今回の記事では、Azure環境における運用監視や障害調査の強力な味方であるAzureログクエリ（KQL / Kusto Query Language）の基礎から実践的な活用方法までを詳しく解説しました。クラウドネイティブなシステム開発において、膨大なログデータから瞬時に必要な情報を抽出できるスキルは、エンジニアにとって必須の技術と言えます。

KQLの最大の特徴は、パイプ記号を使って処理を連結していく直感的な構造にあります。SQLに慣れている方であれば、その親和性の高さに驚くでしょうし、プログラミング未経験の方でも、左から右へ、上から下へと流れるデータの加工プロセスを追うことで、比較的短期間で習得することが可能です。

KQLで覚えるべき主要な演算子と関数

効率的なトラブルシューティングを実現するために、まずは以下の主要な要素をマスターしましょう。これらを組み合わせるだけで、ほとんどの調査業務をカバーできます。

演算子・関数	役割	活用シーン
where	行のフィルタリング	特定のエラーコードや時間帯での絞り込み
summarize	データの集約・集計	エラー発生件数のカウントや平均応答時間の算出
project	列の選択・追加	必要な項目だけを表示して画面をスッキリさせる
render	結果の可視化	折れ線グラフや円グラフへの変換
ago()	相対時間の指定	「過去1時間」といった直近データの抽出
bin()	値のグループ化	30分単位での時系列集計など

実践的なクエリの組み合わせ例

例えば、特定のデータベース操作でエラーが発生している状況を想定してみましょう。まずは現在のテーブルの状態を確認し、その後にエラーの原因を特定するクエリを実行する流れを見ていきます。

調査対象のログデータ（AppServiceLogsテーブル）


TimeGenerated        | Level   | Message                    | OperationName
---------------------+---------+----------------------------+--------------
2026-03-31 12:00:00  | Info    | User login success         | Login
2026-03-31 12:05:00  | Error   | Database connection failed | GetUserInfo
2026-03-31 12:06:00  | Error   | Timeout occurred           | SaveOrder
2026-03-31 12:10:00  | Warning | High memory usage          | SystemCheck
2026-03-31 12:15:00  | Error   | Database connection failed | GetUserInfo
2026-03-31 12:20:00  | Error   | Database connection failed | GetUserInfo

このデータから、「Error」レベルのログを抽出し、操作名ごとに集計して原因の所在を明らかにします。


AppServiceLogs
| where TimeGenerated > ago(1h)
| where Level == "Error"
| summarize ErrorCount = count() by OperationName
| order by ErrorCount desc

クエリ実行結果


OperationName | ErrorCount
--------------+-----------
GetUserInfo   | 3
SaveOrder     | 1

このように、summarize を使うことで「GetUserInfo」という操作で集中的にエラーが発生していることが一目で分かります。ただ漫然とログを眺めるのではなく、統計的にアプローチすることが早期解決の鍵となります。

KQL学習のステップアップ

基本をマスターした後は、join 演算子を使った複数テーブルの結合や、make-series を用いた高度な時系列分析にも挑戦してみてください。Azure Sentinel（アジュール・センチネル）などのセキュリティ分析基盤でもKQLは共通言語として採用されており、一度身につけた知識はクラウドエンジニアとしてのキャリアにおいて非常に息の長い武器になります。

日々の運用の中で、「この情報はクエリで出せないかな？」と自問自答しながら、少しずつコードを書いてみる習慣をつけましょう。最初は公式ドキュメントのサンプルをコピーし、where の条件を書き換えるだけでも立派な第一歩です。

先生と生徒の振り返り会話

生徒

「先生、ありがとうございました！KQLって、まるでパズルを組み立てるみたいに条件を繋げていけるので、書いていて楽しいですね。特にパイプ記号で処理を繋ぐ感覚が、コマンドラインを触っているみたいで馴染みやすいです。」

先生

「その感覚はとても大切です！Linuxのシェル芸に近いものがありますよね。KQLは、膨大なデータの中から『砂金』を見つけ出すような作業を、驚くほど高速にしてくれます。実際にクエリを動かしてみて、何か気づいたことはありますか？」

生徒

「はい！今まではエラーが出ると、関連するサーバーにログインしてテキストファイルの中身を必死に grep（グレップ）して探していました。でもKQLを使えば、複数のインスタンスを横断して一気に検索できるのが衝撃的でした。例えば、特定のユーザーIDに関連する動きだけを追うのも簡単そうですね。」

先生

「まさにそこがクラウド管理の醍醐味です。分散された環境のログを1箇所で、かつ瞬時に相関分析できるのが強みですね。試しに、特定のユーザーの行動を抽出するクエリのイメージを書いてみましょうか。」

生徒

「やってみます！特定のユーザー『UserA』が過去3時間に行った操作を抽出するなら、こんな感じでしょうか？」


AppRequests
| where TimeGenerated > ago(3h)
| where UserId == "UserA"
| project TimeGenerated, OperationName, ResultCode, DurationMs
| order by TimeGenerated asc

先生

「完璧です！project を使って必要な列だけに絞り込んでいるので、結果も見やすくなりますね。これに応答時間がかかっているものを抽出する where DurationMs > 1000 などを加えれば、そのユーザーがどの処理でストレスを感じていたかも丸見えです。」

生徒

「すごい...！これなら障害の問い合わせが来た時も、『あなたのこの操作で、ここが原因で遅くなっていました』と自信を持って回答できそうです。可視化の render timechart も、会議の資料作成で重宝しそうですね。」

先生

「そうですね。エンジニア以外の人に状況を説明する時は、数字よりもグラフの方が圧倒的に説得力があります。KQLはただの調査ツールではなく、チームや顧客とのコミュニケーションを円滑にするツールでもあるんですよ。これからもどんどん色んなクエリを試して、自分だけの『鉄板クエリ集』を作っていってくださいね！」

生徒

「はい！自分専用のチートシートを作って、どんな障害が起きても即座に対応できるかっこいいエンジニアを目指します！」