Azure Resource Graph 向け Kusto Query Language 入門ガイド

By Mirko Peters · 2026-10-21

Azure Resource Graph で使う Kusto Query Language (KQL) を習得しましょう。シンプルな構文、パイプラインフィルター、パイプ、クエリを学び、クラウド環境を管理できるようにします。

Automatically translated with AI from the original post. Read the English original

Azure Resource Graph で Kusto Query Language (KQL) を習得すると、クラウド管理者は、手作業でポータルをクリックすることなく、複数のサブスクリプションにまたがるクラウドインベントリ、セキュリティリスク、ガバナンスへの準拠状況を簡単に把握できる、簡潔で非常に高速なクエリを作成できるようになります。

重要なポイント

• KQL のクエリはレシピのように読めます。パイプ文字（|）で、順次のデータ処理ステップをつなげていきます。
• 既定のテーブル 'resources' には、複数の Azure サブスクリプションをまたいで同時にクエリするために必要な情報の大半が含まれています。
• project 演算子と extend 演算子を使うと、雑然とした出力を整理し、入れ子になったプロパティ値を、冗長なコードを書かずに抽出できます。
• Resource Graph は、安全策として既定で結果を 1,000 件に制限します。大規模な環境では、ページング用のトークンが必要です。
• Azure Resource Graph で学んだ KQL のスキルは、Log Analytics や Azure Data Explorer にもそのまま活用できます。

Azure Resource Graph における KQL の謎を解く

Kusto Query Language (KQL) という頭字語を初めて目にすると、難しそうに感じるかもしれません。しかし、専門用語を取り除いてみると、英語に近く、クラウドインフラストラクチャへの問い合わせを直感的に行えるよう設計された、親しみやすい構文であることがわかります。複雑なアプリケーションや大規模なスクリプトを書くのとは異なり、KQL は問いを投げかけて構造化されたデータを取得することに特化しています。

Azure Resource Graph で行うすべての問い合わせは KQL で書かれています。Azure Data Explorer や Log Analytics を使ったことがあれば、この構文はすぐに見覚えがあるでしょう。しかし、ゼロから始める場合でも、学習曲線は驚くほどなだらかです。日々のクラウド管理に必要な KQL の中核部分は、一度の学習セッションで習得できます。

KQL クエリの構造

KQL クエリは、段階的なレシピのように読めます。この読みやすさの秘訣は、個々の命令を区切るパイプ文字（|）にあります。まずデータの基本テーブルから始め、そこからパイプで後続のコマンドにつなげて、出力を絞り込んだりフィルターしたり、形を整えたりします。

KQL クエリは上から下へ読むと、ほぼ平易な英語のように聞こえます。例として、書ける最もシンプルで有用なクエリを見てみましょう。

resources | summarize count

声に出して読むと、このコマンドは「既定の resources テーブルのすべてを取得し、件数を数える」という意味になります。システムは、クラウド資産の全体規模を表す、非常に価値のある 1 つの数値を返します。

クラウド管理者のための必須演算子

資産の件数を数えられるようになったら、次はデータのフィルターと整形です。ほとんどの管理用クエリで中心的な役割を果たす基本的な演算子がいくつかあります。

• where: 特定の条件でデータセットをフィルターします。たとえば、クエリを resources | where type == "Microsoft.Compute/virtualMachines" に変更すると、件数は仮想マシンのみに限定されます。
• project: 最終出力に表示する列を選択します。大量の生の JSON データの壁ではなく、リソース名、場所、サブスクリプション ID のみを表示できます。
• order by: 結果を文字順または数値順に並べ替えます。ランダムなデータの羅列が、整理されてスキャンしやすい表に変わります。
• extend: 一時的なカスタム列を作成し、深くネストされた構成値を取り出して、短く再利用しやすいラベルを付けられます。

KQL でよくある落とし穴を避ける

KQL にはある程度の柔軟性がありますが、大文字と小文字の区別については厳格なルールがあります。=~ と書く、大文字と小文字を区別しない一致演算子を使うと、リソースの種類などの文字列値を検索する際に、大文字と小文字の違いを無視して一致させられます。一方で、プロパティ名はまったく扱いが異なります。プロパティ名のスペルを間違えたり、大文字と小文字を取り違えたりすると、KQL は明確な構文エラーを返しません。代わりに、黙って空の値を返すため、ロジックに問題がないのにバグを探し続けることになりかねません。

基本を超えたテーブルの活用

resources テーブルは日常的な管理チェックの大半に対応しますが、より詳細なガバナンス作業向けには専用のテーブルも用意されています。セキュリティ体制の監査、ポリシー割り当ての確認、管理グループ、サブスクリプション、リソース グループといった組織のコンテナーを確認する場合は、KQL クエリをこれらの専用テーブルに直接向けることができます。

KQL は Microsoft のエコシステム全体で共通の標準言語です。そのため、これらのパターンを習得することは、キャリアにすぐに効く強みになります。孤立したネットワーク セキュリティ グループの整理や、タグのない仮想マシンの特定のために今日書くクエリは、Microsoft Defender でセキュリティ アラートを作成する場合や、Log Analytics で運用ダッシュボードを構築する場合にも同様に役立ちます。

まとめと次のステップ

Kusto Query Language を学ぶことで、Azure Resource Graph は、よくわからないバックエンドのエンジンから、日常的に頼れるクラウド管理ツールへと変わります。手作業でのポータル操作や脆いスクリプトに代わって、簡潔で読みやすいクエリを使うことで、複数サブスクリプションの環境全体を完全に把握できるようになります。

クラウド管理のワークフローをさらに効率化する方法を詳しく知りたい方は、エピソード全編を聴いてください。組織で Azure Resource Graph を活用するための専門的な知見、実践的な例、ハンズオンのガイダンスが得られます。

よくある質問

KQL とは何で、なぜ Azure Resource Graph で使われるのですか。

KQL は Kusto Query Language の略です。Resource Graph で Azure 環境に対して問い合わせを行うための、軽量で直感的なクエリ言語です。読みやすいパイプ区切りの構文を使って、数千のクラウド リソースを即座にフィルタリング、並べ替え、グループ化できます。

KQL でリソースを種類ごとにフィルタリングするにはどうすればよいですか。

最初のテーブル宣言の後に 'where' 句を追加すると、リソースをフィルタリングできます。たとえば 'resources | where type =~ "microsoft.keyvault/vaults"' と書くと、Azure Key Vault のみが返されます。

KQL クエリがエラーではなく空の値を返すのはなぜですか。

KQL のプロパティ名では大文字と小文字が区別されます。プロパティ名の大文字と小文字を取り違えると、Azure Resource Graph は構文エラーを返さず、黙って空の値を返すため、デバッグが難しくなります。

Azure Resource Graph の 1,000 件の上限とは何ですか。

既定では、Azure Resource Graph クエリは最大 1,000 件のレコードを返します。これは、誤って大量のデータセットを取得することを防ぐための制限です。環境に数千ものリソースがある場合は、継続トークンを使って、この上限を回避したり、ページ単位で結果を取得したりできます。