Microsoft Defender の Advanced Hunting で「Use shared queries」を使う最大のメリットは、KQLを一から書かなくても、事前定義済み・組織共有・コミュニティ提供のクエリからすぐに脅威ハンティングを始められる点です。特にSOC運用、インシデント初動調査、標準クエリの横展開では、個人の属人的なKQLをチーム資産に変えられます。
今回確認すべきポイントは、機能追加というよりも「共有クエリをどう管理するか」です。Microsoft Learnの「Use shared queries in advanced hunting」は、Microsoft Defender XDR と Microsoft Sentinel in the Microsoft Defender portal が対象で、Shared queries、My queries、Community queries をAdvanced HuntingのQueriesタブから利用できると説明しています。(Microsoft Learn)
なお、同じAdvanced Hunting領域では、Microsoft SentinelをDefenderポータルで扱う統合運用に関する公式情報が2026年6月26日に更新されており、Sentinel利用組織ではポータル移行の期限もあわせて確認が必要です。(Microsoft Learn)
Microsoft Defender の「Use shared queries」とは
Microsoft Defender の「Use shared queries in advanced hunting」は、Advanced Huntingで利用するKQLクエリを保存・共有・再利用するための機能です。Advanced Huntingは、Microsoft Defender XDRやMicrosoft Sentinelのデータに対してKQLで検索・調査を行う脅威ハンティング機能です。Microsoftの公式情報では、Advanced Huntingは最大30日分の生データを探索できるクエリベースの脅威ハンティングツールと説明されています。(Microsoft Learn)
共有クエリの仕組みを使うと、次のような運用がしやすくなります。
| 用途 | 具体例 | 効果 |
|---|---|---|
| 初動調査の標準化 | 不審なPowerShell実行、悪性URLクリック、横展開の兆候を探すクエリを共有 | 担当者ごとの調査品質のばらつきを減らせる |
| SOCメンバーのオンボーディング | よく使うKQLをShared queriesに整理 | 新任担当者がすぐ調査を始められる |
| インシデント対応の高速化 | 重大アラート発生時に使うクエリをカテゴリ別に保存 | クエリ検索や過去メモ探しの時間を削減 |
| グローバル運用 | 地域・部門をまたいで同じ調査観点を共有 | 日本、米国、欧州など複数拠点で調査手順をそろえやすい |
重要なのは、共有クエリは単なる「便利な保存機能」ではなく、セキュリティ運用のナレッジベースとして扱うべき点です。よく使うクエリを整理せずに共有すると、古いクエリ、検証不足のクエリ、用途が不明なクエリが増え、かえって現場の判断を遅らせます。
今回の更新ポイントで押さえるべき結論
今回の公式情報から、管理者がまず確認すべき内容を整理すると次のとおりです。
| 確認項目 | 要点 | 管理者の対応 |
|---|---|---|
| 影響範囲 | Microsoft Defender XDR、Microsoft Sentinel in the Microsoft Defender portal が対象 | DefenderポータルでAdvanced Huntingを利用するSOC、CSIRT、セキュリティ管理者を確認する |
| 設定変更 | 共有クエリ自体に大きなテナント設定変更は不要。クエリ保存時に保存先を選ぶ運用が中心 | Shared queriesに保存してよいクエリの基準を決める |
| 移行期限 | shared queries単体の移行期限は公式情報上示されていない | ただしSentinelをAzureポータルで使っている場合は、2027年3月31日以降のDefenderポータル移行に備える |
| 権限 | クエリを共有しても、閲覧者にデータアクセス権がなければ期待どおりに結果が出ない可能性がある | Advanced Huntingのロール、Defender XDR RBAC、Sentinel Readerなどを確認する |
| 運用リスク | 誰でも使える共有クエリが増えると、誤検知、重複、古いスキーマ参照が増える | 命名規則、レビュー、棚卸し、削除ルールを作る |
特に誤解しやすいのは、Shared queriesに保存したクエリが「すべてのユーザーに同じ結果を返す」とは限らない点です。Advanced Huntingのデータアクセスは権限に依存します。Microsoftの公式情報でも、Advanced Huntingクエリの実行には割り当てられた権限が必要で、アクセスできるデータはロールや権限によって変わると説明されています。(Microsoft Learn)
Shared queries、My queries、Community queries の違い
Advanced HuntingのQueriesタブでは、主に3種類のクエリを使い分けます。Microsoftの公式情報では、Queriesタブに Shared queries、My queries、Community queries のドロップダウンがあり、それぞれを展開して利用できるとされています。(Microsoft Learn)
| 種類 | 共有範囲 | 主な使いどころ | 注意点 |
|---|---|---|---|
| Shared queries | 組織内のユーザー | チーム標準の調査クエリ、インシデント対応手順、定期確認用クエリ | 保存前にレビューし、用途・担当・更新日を明確にする |
| My queries | 自分のみ | 個人の作業メモ、検証中のKQL、未完成の調査クエリ | 完成前のクエリをShared queriesへ移さない |
| Community queries | GitHubで共有されるコミュニティクエリ | 既知の攻撃手法、キャンペーン、脅威分析の参考 | 自社環境でそのまま正しく動くとは限らないため検証が必要 |
Microsoft Defenderポータル内で組織向けに共有する場合は、保存先としてShared queriesを選びます。一方、公開クエリとして広く共有する場合は、Defenderポータルから直接全世界へ公開するというより、Microsoftが案内するGitHubリポジトリのコミュニティクエリを利用・貢献する流れになります。公式情報では、Microsoftのセキュリティ研究者がGitHubの公開リポジトリでAdvanced Huntingクエリを共有し、公開前にレビューされると説明されています。(Microsoft Learn)
影響範囲：誰が確認すべきか
この更新で直接確認すべきなのは、Microsoft Defender XDRの管理者だけではありません。Advanced Huntingを日常的に使う担当者、Microsoft SentinelをDefenderポータルへ統合している組織、複数地域でSOCを運用している企業も対象になります。
| 対象者 | 確認すべきこと |
|---|---|
| セキュリティ管理者 | Advanced Huntingの権限、Shared queriesの管理ルール、不要クエリの削除方針 |
| SOCアナリスト | よく使う調査クエリがShared queriesに整理されているか |
| CSIRT | インシデント発生時に使う初動調査クエリが標準化されているか |
| Microsoft Sentinel管理者 | Defenderポータル統合後にSentinelのクエリや関数をどう扱うか |
| グローバルIT管理者 | 国・地域・クラウド環境ごとの差異、権限設計、命名規則の統一 |
Advanced Huntingは、Microsoft Defender for Endpoint、Defender for Office 365、Defender for Cloud Apps、Defender for Identity、Microsoft Sentinelなど、複数のデータセットを対象にできます。(Microsoft Learn)
そのため、共有クエリを作るときは「誰が実行するか」だけでなく、「どの製品のデータを参照しているか」も明記しておくと運用しやすくなります。
設定変更：共有クエリを使うために必要な操作
共有クエリの基本操作はシンプルです。公式情報では、クエリを作成または変更し、Save queryのドロップダウンからSave asを選び、名前と保存先を指定して保存する流れが説明されています。保存先には、組織内ユーザー向けのShared queriesと、自分だけが使うMy queriesがあります。(Microsoft Learn)
基本的な保存手順
| 手順 | 操作 | 実務上のポイント |
|---|---|---|
| 1 | Advanced Huntingでクエリを作成または修正 | いきなり共有せず、まず小さい期間・少ない結果件数で検証する |
| 2 | Save queryからSave asを選択 | 既存クエリの上書きと新規保存を混同しない |
| 3 | クエリ名を入力 | 用途、対象データ、重要度、更新日が分かる名前にする |
| 4 | 保存先を選択 | 個人用ならMy queries、チーム標準ならShared queries |
| 5 | 保存後に他ユーザーで確認 | 権限差により結果が変わらないか確認する |
おすすめの命名規則
Shared queriesに保存するクエリ名は、検索しやすさを重視します。たとえば次のように命名すると、後から探しやすくなります。
IR-Endpoint-SuspiciousPowerShell-v1
Hunt-Email-PhishingUrlClicks-v2
SOC-Daily-HighSeverityAlerts-v1
Threat-Campaign-ExampleName-202606命名規則に入れると便利な要素は、用途、対象データ、脅威カテゴリ、バージョンです。逆に、「test」「new query」「調査用」だけの名前は避けるべきです。数カ月後に誰も意味を判断できなくなります。
共有クエリに入れるべき情報
Shared queriesに保存するクエリは、KQL本文だけでなく、コメントも重要です。MicrosoftのKQL解説でも、クエリの先頭に目的を説明する短いコメントを入れると、後で保存・共有するときに役立つと説明されています。(Microsoft Learn)
共有用クエリには、少なくとも次の情報をコメントとして入れておくと実務で使いやすくなります。
// Purpose: Detect suspicious PowerShell commands that may download external content
// Data source: DeviceProcessEvents
// Owner: SOC Tier2
// Review cycle: Quarterly
// Notes: Validate false positives from admin scripts before escalation
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName in~ ("powershell.exe", "powershell_ise.exe")
| where ProcessCommandLine has_any ("WebClient", "DownloadFile", "DownloadString", "Invoke-WebRequest", "http", "https")
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine, InitiatingProcessFileName
| top 100 by Timestamp descこのように、クエリの目的と注意点を書いておくと、別の担当者が実行したときに「これは何を検出するためのクエリか」「結果が出たら何を確認すべきか」が分かります。
Community queries の使い方と注意点
Community queriesは、ゼロからKQLを書く余裕がないときに便利です。公式情報では、Community queriesはCampaigns、Collection、Defense evasionなどのフォルダーに分類され、各クエリには詳細を示すインラインコメントが含まれると説明されています。(Microsoft Learn)
ただし、Community queriesは「自社テナントでそのまま実行すれば必ず正しい結果が出る」ものではありません。次の観点で確認してから使うべきです。
| 確認項目 | 見るべきポイント | 理由 |
|---|---|---|
| 対象テーブル | 自社環境でそのテーブルを利用できるか | ライセンスや製品構成により存在しないテーブルがある |
| 時間範囲 | ago(30d)など広すぎないか | 重いクエリはタイムアウトや負荷の原因になる |
| 検出条件 | 自社の正常運用を誤検知しないか | 管理スクリプトや業務ツールが検出される場合がある |
| 出力列 | 調査に必要な列が含まれているか | DeviceName、AccountName、URL、ProcessCommandLineなどが不足すると追跡しづらい |
| コメント | 検出意図が明確か | 意図が不明なクエリはインシデント判断に使いにくい |
Community queriesは、調査の「出発点」として使うのが適切です。自社の端末命名規則、管理者スクリプト、プロキシ構成、メール運用に合わせて調整し、検証済みのものだけをShared queriesへ昇格させると安全です。
削除・リネーム時の注意点
共有クエリは増えやすいため、定期的な整理が必要です。ただし、削除には注意が必要です。公式情報では、保存済みクエリを削除すると恒久的に削除されるため、残したい場合は削除ではなくリネームを使うよう注意されています。(Microsoft Learn)
削除前には次のように判断すると安全です。
| 状態 | 対応 |
|---|---|
| まだ使う可能性がある | Deprecated-やArchive-を付けて一時保管 |
| 後継クエリがある | クエリコメントに後継クエリ名を記載してからリネーム |
| 誰も所有者が分からない | すぐ削除せず、SOC内で確認期間を設ける |
| スキーマ変更で動かない | 修正可能なら更新、不要ならアーカイブ後に削除 |
| テスト用・重複クエリ | 影響確認後に削除 |
特にグローバル組織では、日本チームでは不要でも別地域のSOCが使っている場合があります。Shared queriesを削除する前に、所有者、最終更新日、利用目的を確認する運用を作っておくとトラブルを避けられます。
Direct link の活用シーン
Advanced Huntingでは、クエリを直接開くリンクを作成できます。公式情報では、クエリを完成させた後にShare linkを選ぶことで、Advanced Huntingのクエリエディターでそのクエリを直接開くリンクを生成できると説明されています。(Microsoft Learn)
Direct linkは、次のような場面で役立ちます。
| 活用シーン | 使い方 |
|---|---|
| インシデントチケット | ServiceNow、Jira、Azure DevOpsなどのチケットに調査クエリへのリンクを貼る |
| SOC手順書 | 「このアラートが出たらこのクエリを実行」と手順に組み込む |
| Teams連携 | インシデント対応チャネルで調査クエリを共有する |
| 教育・引き継ぎ | 新任アナリストに標準クエリをすぐ開ける形で案内する |
ただし、リンクを共有しても、受け取ったユーザーに必要な権限がなければデータを確認できません。リンク共有はアクセス権付与ではない、という点を明確にしておく必要があります。
Microsoft Sentinel利用組織が確認すべき移行期限
「Use shared queries」そのものについて、公式情報上で個別の移行期限は示されていません。既存のShared queriesをいつまでに移行しなければならない、という種類の変更ではありません。
一方で、Microsoft SentinelをAzureポータルで利用している組織は、Advanced Huntingの統合体験に関する移行計画を確認する必要があります。Microsoftは、Microsoft SentinelがDefenderポータルで一般提供されており、2027年3月31日以降はAzureポータルでサポートされず、Defenderポータルでのみ利用可能になると説明しています。(Microsoft Learn)
| 利用状況 | 確認すべきこと |
|---|---|
| Microsoft Defender XDRのみ利用 | Shared queriesの整理、権限、SOC運用ルールを確認 |
| SentinelをDefenderポータルに接続済み | Sentinelのクエリ、関数、共有クエリの見え方を確認 |
| SentinelをAzureポータル中心で運用 | 2027年3月31日までの移行計画を作成 |
| 複数ワークスペースを運用 | どのワークスペースのクエリをDefenderポータルで使うか整理 |
| グローバルSOCで利用 | 地域ごとの担当、権限、クエリ命名規則を統一 |
Microsoftの公式情報では、Sentinelワークスペースを接続すると、Advanced HuntingページからSentinelデータをクエリできるようになり、Sentinelの関数はFunctionsタブ、共有・サンプルクエリはQueriesタブ内のSentinelフォルダーで確認できると説明されています。(Microsoft Learn)
権限設計で失敗しやすいポイント
Shared queriesの導入でよくある失敗は、「クエリを共有したのに相手が使えない」というものです。原因の多くは権限です。
Advanced Huntingでは、ユーザーがアクセスできるワークロードやデータテーブルが権限によって制御されます。Microsoftの公式情報では、統合Advanced HuntingページでMicrosoft SentinelとMicrosoft Defenderのデータを横断してクエリするには、少なくともMicrosoft Sentinel Readerロールが必要と説明されています。(Microsoft Learn)
| 症状 | よくある原因 | 対応 |
|---|---|---|
| クエリは見えるが結果が出ない | 参照テーブルへの権限がない | Defender XDR RBAC、Entraロール、Sentinel Readerを確認 |
| メール関連テーブルだけ見えない | Email & Collaboration系の権限不足 | Security Reader、Security Operatorなどの権限を確認 |
| Endpoint関連の結果が限定される | Defender for EndpointのRBACスコープ | デバイスグループやロール割り当てを確認 |
| Sentinelテーブルが見えない | ワークスペース未接続、またはSentinel権限不足 | Defenderポータルへのワークスペース接続とロールを確認 |
| 地域・クラウド環境で挙動が違う | ソブリンクラウドやGCC環境の制限 | 対象クラウドの公式制限を確認 |
Microsoftの公式情報では、GCC-M環境ではMicrosoft SentinelとDefenderの両方のテーブルを参照するクエリがサポートされない制限も示されています。グローバル向けに標準クエリを展開する場合は、商用クラウドだけでなく、政府系クラウドや地域ごとの制約も確認しておくべきです。(Microsoft Learn)
管理者が今すぐ確認すべきチェックリスト
Shared queriesを安全に運用するには、機能を使い始める前にルールを決めることが重要です。次のチェックリストを使うと、導入後の混乱を防ぎやすくなります。
| チェック項目 | 確認内容 |
|---|---|
| 利用者の棚卸し | Advanced Huntingを使う管理者、SOC、CSIRT、委託先を確認したか |
| 権限確認 | Shared queriesを使うユーザーに必要なデータアクセス権があるか |
| 命名規則 | 用途、対象データ、バージョン、所有者が分かる名前にしているか |
| レビュー体制 | Shared queriesへ保存する前に、KQLの妥当性を誰が確認するか |
| コメントルール | クエリの目的、対象テーブル、対応手順、注意点をコメントに書いているか |
| 更新サイクル | 四半期ごと、重大インシデント後、製品変更後などに見直すか |
| 削除ルール | 不要クエリをすぐ削除せず、アーカイブ期間を設けるか |
| Sentinel移行 | Azureポータル中心のSentinel運用をDefenderポータルへ移す計画があるか |
| グローバル対応 | 地域、言語、クラウド環境ごとの違いを考慮しているか |
| チケット連携 | Direct linkをインシデント手順やチケットに組み込むか |
Shared queriesは、保存するだけなら簡単です。しかし、共有範囲が広がるほど、命名、レビュー、削除、権限の管理が重要になります。
実務でおすすめの運用ルール
Shared queriesを本番運用で使うなら、次のようなルールを作ると効果的です。
My queriesからShared queriesへ昇格する流れを決める
検証中のクエリはMy queriesに保存し、一定のレビューを通ったものだけShared queriesへ移します。これにより、未完成のクエリが組織全体に広がることを防げます。
クエリにオーナーを付ける
Shared queriesには、必ず所有者または管理チームを明記します。所有者が分からないクエリは、古くなっても誰も修正できません。
調査目的別に分類する
たとえば、次のような分類にすると探しやすくなります。
| 分類 | 例 |
|---|---|
| IR | インシデント初動調査 |
| Hunt | 仮説ベースの脅威ハンティング |
| Daily | 日次確認 |
| Campaign | 特定キャンペーン・脆弱性対応 |
| Triage | アラートの一次切り分け |
実行負荷を意識する
Advanced Huntingにはクエリの時間範囲、結果件数、タイムアウト、リソース消費などの制限があります。公式情報では、Defenderデータのクエリ対象期間は通常最大30日、結果セットは最大100,000行、クエリ実行時間は最大10分などの制限が示されています。(Microsoft Learn)
そのため、共有クエリでは最初から広すぎる検索を避け、時間範囲や出力列を絞る設計が重要です。
悪い例は次のようなクエリです。
DeviceProcessEvents
| where ProcessCommandLine contains "powershell"このクエリは意図が広すぎて、結果が多くなりやすく、調査にも使いにくいです。
改善例は次のようになります。
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName in~ ("powershell.exe", "powershell_ise.exe")
| where ProcessCommandLine has_any ("DownloadString", "DownloadFile", "Invoke-WebRequest")
| project Timestamp, DeviceName, AccountName, ProcessCommandLine, InitiatingProcessFileName
| top 100 by Timestamp desc時間範囲、対象プロセス、疑わしい文字列、出力列を絞ることで、共有クエリとして使いやすくなります。
よくある疑問
Shared queriesに保存すれば全ユーザーが同じデータを見られますか？
いいえ。Shared queriesはクエリを共有する仕組みであり、データアクセス権を付与する仕組みではありません。実行結果は、各ユーザーのDefender XDR、Microsoft Sentinel、Entra ID、Defender for Endpointなどの権限に依存します。
既存のKQLをすべてShared queriesに入れるべきですか？
入れるべきではありません。Shared queriesに入れるのは、チームで再利用する価値があり、検証済みで、目的が明確なクエリに絞るべきです。個人の検証用、古いインシデント専用、用途不明のクエリはMy queriesやアーカイブで管理する方が安全です。
Community queriesはそのまま本番調査に使えますか？
参考にはなりますが、そのまま本番判断に使うのは避けた方が安全です。自社環境のテーブル、正常通信、管理ツール、端末命名規則、ログ保持期間に合わせて調整し、誤検知を確認してから使うべきです。
移行期限はありますか？
Use shared queries単体について、公式情報上で個別の移行期限は示されていません。ただし、Microsoft SentinelをAzureポータルで利用している組織は、2027年3月31日以降にSentinelがAzureポータルでサポートされなくなる点を確認する必要があります。(Microsoft Learn)
共有クエリを削除しても復元できますか？
公式情報では、クエリを削除すると恒久的に削除されると注意されています。不要に見えるクエリでも、すぐ削除せず、リネームやアーカイブ運用を挟む方が安全です。(Microsoft Learn)
まとめ：Shared queriesは「保存機能」ではなくSOCの共通知識として管理する
Microsoft Defender の「Use shared queries in advanced hunting」は、Advanced Huntingをすぐ使い始めるための実用的な機能です。Shared queries、My queries、Community queriesを使い分けることで、個人のKQLを組織の調査資産として活用できます。
管理者が次に取るべき行動は明確です。まず、現在のAdvanced Hunting利用者と権限を確認します。次に、Shared queriesへ保存してよいクエリの基準、命名規則、レビュー担当、削除ルールを決めます。Microsoft Sentinelを使っている場合は、Defenderポータルへの統合状況と2027年3月31日のAzureポータルサポート終了もあわせて確認してください。
共有クエリを整理できている組織ほど、インシデント発生時に「誰がどのクエリを使うか」で迷いません。今回の更新ポイントは、新しい画面を覚えることではなく、Advanced Huntingをチームで再利用できる運用に変えることです。
コメント