変更要約: SC-200 第5章を新規作成（ドメイン3: Defender XDR でのハンティング(KQL テーブル選択 DeviceProcessEvents 等/KQL で脅威特定/Advanced Hunting クエリ作成/threat analytics の解釈)、ハンティンググラフ(blast radius)/Sentinel Graph でのエンティティ間の関係分析、Sentinel プラットフォーム(ハンティングクエリ/ブックマーク/Data lake の KQL ジョブ/Summary rule テーブル/Notebooks・Sentinel MCP Server 接続)）。
5.3Sentinel プラットフォームでのハンティング
Microsoft Sentinel のハンティングクエリの作成と監視、Data lake の KQL ジョブの作成と管理、Summary rule テーブルの作成と管理、Notebooks（Sentinel MCP Server への接続を含む）によるハンティングを理解します。
Microsoft Sentinel は、全社のログに対する大規模なハンティングの基盤を提供します。アナリストは、対話的なクエリから、大量データへのバッチ的なジョブ、集計テーブル、Notebooks による高度な分析までを使い分けます。
5.3.1ハンティングクエリと KQL ジョブ
ハンティングクエリ は、仮説に基づく KQL を保存・実行・監視し、ヒットを ブックマーク して調査に引き継ぎます（必要なら分析ルール化）。大量データ（とくに Data lake 階層）に対しては、対話実行ではなく KQL ジョブ を作成し、バッチ的に大規模クエリを実行して結果を保存します。コストの高い Analytics 階層を避け、安価な Data lake で広く探索したいときに有効です。
5.3.2Summary rules と Notebooks
Summary rule テーブル は、大量の生ログを事前に集約して小さな要約テーブルを作る仕組みで、頻繁に使うクエリを高速・低コストに保ちます（例：日次の集計を要約しておく）。Notebooks（Jupyter）は、KQL に加え Python による高度な分析・機械学習・可視化を可能にし、Sentinel MCP Server へ接続して AI エージェント/外部ツールからハンティングを駆動できます。アナリストは規模と高度さに応じて、これらを組み合わせます。
決め手：「仮説 KQL を保存/実行/監視しヒットをブックマーク」＝ハンティングクエリ。「Data lake の大量データへバッチで大規模クエリ」＝KQL ジョブ。「生ログを事前集約し高速/低コストに」＝Summary rules。「Python の高度分析/ML・MCP Server 接続」＝Notebooks。
混同に注意：
①対話的なハンティングクエリと、Data lake へのバッチ的な KQL ジョブを取り違えない。
②Summary rules（事前集約テーブル）と分析ルール（検知）は別物。
③Notebooks は高度分析向け＝単純な探索は通常のハンティングクエリで十分。
5.3.3この節のまとめ
- ハンティングクエリ＝仮説 KQL を保存/実行/監視しブックマーク。大量データの Data lake はバッチの KQL ジョブ
- Summary rules＝生ログを事前集約し高速/低コスト。Notebooks＝Python 高度分析/ML・Sentinel MCP Server 接続
- 規模(対話/バッチ)と高度さ(集約/Notebooks)で手段を使い分ける
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. Data lake 階層に格納した大量のログに対して、対話実行ではなくバッチ的に大規模な KQL クエリを実行し結果を保存したい。最適なのはどれですか？
Q2. 頻繁に使う集計クエリを高速・低コストにするため、大量の生ログを事前に集約した小さなテーブルを作りたい。最適なのはどれですか？
Q3. KQL に加え Python による高度な分析や機械学習を行い、Sentinel MCP Server に接続してハンティングを駆動したい。最適なのはどれですか？
Q4. 仮説に基づく KQL を保存・実行・監視し、ヒットを調査に引き継ぎたい。最適なのはどれですか？
Q5. Summary rules と分析ルールの違いとして正しいのはどれですか？