Microsoft Defender XDR のカスタムレポート作成で今回押さえるべきポイントは、Power BI から Microsoft Graph security API のデータを読み込み、SOC 向けのアラート・インシデント可視化を自社要件に合わせて作れるという点です。標準レポートだけでは追いにくい「検出元別のアラート傾向」「重大度別の件数」「平均対応時間」「MITRE ATT&CK 観点の攻撃傾向」を、Power BI で柔軟に分析できます。
一方で、単に Power BI に接続すればよいわけではありません。Microsoft Graph の権限、Defender XDR 側のロール、OData フィルター、API 制限、旧 API からの移行期限を確認しないと、レポートが重い、必要なデータが見えない、将来データ取得が止まるといった問題につながります。この記事では、2026年6月に更新された Microsoft Defender XDR API 関連の公式情報と、Microsoft Graph security API と Power BI を使ったカスタムレポート作成手順をもとに、管理者が実務で確認すべきポイントを整理します。(Microsoft Learn)
Microsoft Defender XDR のカスタムレポート作成で何が変わるのか
今回の公式情報は、新しい画面機能をオンにするタイプの更新ではなく、Microsoft Defender XDR のデータ活用を Microsoft Graph security API と Power BI に寄せていくための実装ガイドとして見るのが適切です。
Microsoft Defender XDR には標準レポート、Microsoft Sentinel ワークブック、高度なハンティングの render 関数、Power BI 連携など複数の可視化手段があります。その中で Power BI を使う方法は、標準画面では不足しやすい経営報告、SOC 月次報告、拠点別・部門別の分析、対応時間のトレンド確認に向いています。(Microsoft Learn)
特に注目すべき点は、サンプルが Microsoft Graph security API の alerts_v2 と incidents を前提にしていることです。Microsoft Graph security API は、Microsoft とパートナーのセキュリティソリューションを統合的なスキーマで扱うための API とされており、アラート、インシデント、Secure Score、高度なハンティングなどを横断的に活用できます。(Microsoft Learn)
影響範囲：対象になる管理者・SOC・レポート利用者
この更新の影響を受けるのは、Microsoft Defender XDR を直接操作するセキュリティ担当者だけではありません。Power BI を使ってセキュリティデータを二次利用する組織では、次の担当者が関係します。
| 対象者 | 影響する内容 | 確認すべきこと |
|---|---|---|
| SOC アナリスト | アラート、インシデント、重大度、検出元、対応状況を Power BI で確認できる | 日々の分析に必要な列とフィルター条件 |
| Microsoft Defender 管理者 | API 接続に必要なロールとアクセス許可を管理する | Security Reader などの最小権限設計 |
| Power BI 管理者 | Power BI Desktop、Power BI Service、更新スケジュールを管理する | 資格情報、データ更新、共有範囲 |
| セキュリティ責任者 | 月次・四半期レポートの指標を統一する | MTTR、重大度別件数、インシデント傾向 |
| グローバル IT 管理者 | 国・リージョン、テナント、権限モデルの差異を確認する | 利用可能なクラウド環境と RBAC |
実務上のポイントは、「誰が見るか」より先に「どの権限で取得するか」を決めることです。Power BI レポートは見やすい反面、共有設定を誤るとセキュリティインシデント情報を広く見せてしまう可能性があります。SOC 以外にも展開する場合は、詳細なアラート名、端末名、ユーザー名、IP アドレス、推奨対応などをそのまま出すか、集計値だけにするかを分けて設計してください。
まず理解すべき構成：Power BI から Microsoft Graph security API に接続する
公式手順では、Power BI Desktop で空のクエリを作成し、Advanced Editor に OData クエリを貼り付けて Microsoft Graph security API のアラートデータを取得します。基本形は次のような構成です。(Microsoft Learn)
let
Source = OData.Feed("https://graph.microsoft.com/v1.0/security/alerts_v2", null, [Implementation="2.0"])
in
SourcePower BI 側では、接続時に Organizational account を選び、Microsoft Defender XDR のインシデントやアラートにアクセスできるアカウントでサインインします。公式手順はユーザーコンテキストでのアクセスを前提としており、アラートやインシデントを表示するには、対象ユーザーに対応する権限が必要です。(Microsoft Learn)
標準レポートと Power BI カスタムレポートの使い分け
標準レポートで十分なケースと、Power BI カスタムレポートを作るべきケースを混同すると、運用負荷が増えます。まずは次の基準で判断するとよいでしょう。
| やりたいこと | 向いている方法 | 理由 |
|---|---|---|
| 日々のアラート確認 | Microsoft Defender ポータル | 調査・対応アクションと一体で使える |
| SOC の週次・月次報告 | Power BI カスタムレポート | 期間、重大度、検出元、対応時間を自由に集計できる |
| Sentinel を含む統合監視 | Microsoft Sentinel ワークブック | Sentinel と統合済みのテンプレートを活用しやすい |
| ハンティング結果の即時可視化 | 高度なハンティングの render | KQL 結果を素早くグラフ化できる |
| 経営層向けダッシュボード | Power BI | セキュリティ以外の KPI と組み合わせやすい |
Power BI 化すべきなのは、調査画面の代替ではなく、傾向分析・報告・改善判断に使う指標です。たとえば「直近7日で高重大度アラートが増えている検出元」「解決までに時間がかかるカテゴリ」「特定拠点に偏るインシデント」などは、Power BI の方が把握しやすくなります。
設定変更のポイント：フィルターとパラメーターを必ず設計する
Power BI で Microsoft Defender XDR のアラートを取得する場合、最初に失敗しやすいのがデータを絞らずに読み込むことです。Microsoft Graph API は OData の $filter などを使えますが、環境によってはアラート量が多く、無条件で取得すると読み込みに時間がかかります。公式ドキュメントでも、読み込み時間を改善するためにフィルター処理が重要だと説明されています。(Microsoft Learn)
直近数日だけを取得する例
まず検証するなら、直近3日程度に絞るのが現実的です。
let
AlertDays = "3",
TIME = "" & Date.ToText(Date.AddDays(Date.From(DateTime.LocalNow()), -AlertDays), "yyyy-MM-dd") & "",
Source = OData.Feed("https://graph.microsoft.com/v1.0/security/alerts_v2?$filter=createdDateTime ge " & TIME & "", null, [Implementation="2.0"])
in
Sourceこの方法は、初期検証や直近の運用状況確認には向いています。ただし、月次レポートや監査報告では期間を固定しづらいため、次の段階では開始日・終了日をパラメーター化します。
開始日・終了日をパラメーター化する
Power BI の Query Editor で StartDate と EndDate をパラメーターとして作成し、クエリ内で参照します。公式手順でも、毎回コードを修正するのではなく、レポートを開くたびに開始日と終了日を指定できるようにする方法が示されています。(Microsoft Learn)
let
Source = OData.Feed("https://graph.microsoft.com/v1.0/security/incidents?$filter=createdDateTime ge " & StartDate & " and createdDateTime lt " & EndDate & "", null, [Implementation="2.0"])
in
Sourceこの設計にしておくと、SOC 月次報告では前月1日から月末まで、四半期レビューでは3か月分、重大インシデントの振り返りでは特定期間だけ、といった使い分けがしやすくなります。
取得列を絞る設計も重要
履歴分析では期間を広く取りたい場面があります。その場合、すべての列を取得するのではなく、$select で必要な列だけを取得します。公式例では、id、title、severity、createdDateTime などのフィールドを選択する例が示されています。(Microsoft Learn)
let
Source = OData.Feed("https://graph.microsoft.com/v1.0/security/alerts_v2?$filter=createdDateTime ge " & StartLookbackDate & " and createdDateTime lt " & EndLookbackDate & "&$select=id,title,severity,createdDateTime", null, [Implementation="2.0"])
in
Source実務では、最初から「使うかもしれない列」を全部持つより、レポートの目的ごとにデータセットを分ける方が安定します。たとえば、経営層向けには件数・重大度・傾向だけ、SOC 向けには検出元・MITRE technique・対応状況まで含める、という分け方です。
権限設計：Power BI で見えない原因の多くはアクセス許可にある
Power BI の接続自体は成功しても、期待したアラートやインシデントが表示されないことがあります。その原因として多いのが、Microsoft Graph の API 権限と、Microsoft Defender XDR 側のロールが不足しているケースです。
alerts_v2 を取得する Microsoft Graph API では、委任アクセスとアプリケーションアクセスのどちらでも SecurityAlert.Read.All が最小権限として示されています。また、委任アクセスでは、サインインユーザーに Security Reader、Global Reader、Security Operator、Security Administrator などの対応するロールが必要です。(Microsoft Learn)
incidents を取得する場合は、最小権限として SecurityIncident.Read.All が示されており、委任アクセスでは同様に Security Reader、Global Reader、Security Operator、Security Administrator などのロールが必要です。(Microsoft Learn)
| 取得対象 | 主な API | 最小権限の例 | 管理上の注意 |
|---|---|---|---|
| アラート | /security/alerts_v2 | SecurityAlert.Read.All | 検出元、重大度、ステータスの分析に使う |
| インシデント | /security/incidents | SecurityIncident.Read.All | 複数アラートを束ねた攻撃単位の分析に使う |
| インシデント＋アラート | /security/incidents?$expand=alerts | インシデントとアラートの権限を確認 | レポートは便利だがデータ量が増えやすい |
| Secure Score | /security/secureScores など | APIごとの権限確認が必要 | 経営報告向けの改善指標に使いやすい |
| 高度なハンティング | runHuntingQuery | Threat Hunting 系権限 | 旧 API 移行の影響を受けやすい |
最小権限の考え方では、Power BI 作成者に Security Administrator を安易に付与するのは避けるべきです。まずは Security Reader など読み取り中心のロールで要件を満たせるか確認し、書き込み権限や管理権限は別アカウントに分離してください。
グローバル環境で確認すべきクラウド対応
グローバル企業では、Microsoft 365 のテナントやクラウド環境が国・地域で異なる場合があります。Microsoft Graph の alerts_v2 と incidents API は、Global service、US Government L4、US Government L5 では利用可能と示されていますが、中国 21Vianet 運用環境は対象外とされています。(Microsoft Learn)
そのため、海外拠点を含むレポートを作る場合は、次の順で確認すると安全です。
| 確認項目 | 見るべきポイント | 失敗しやすい例 |
|---|---|---|
| テナントのクラウド種別 | Global、Government、China など | 一部リージョンだけ API が使えない |
| Defender 製品の有効化状況 | Endpoint、Office 365、Identity、Cloud Apps など | データソースごとにアラート量が異なる |
| Sentinel 連携 | Defender ポータルへのオンボード状況 | Sentinel アラートが想定通り含まれない |
| ロールモデル | Defender 統合 RBAC、Entra ロール | 管理者は見えるが作成者は見えない |
| Power BI 共有範囲 | ワークスペース、アプリ、行レベルセキュリティ | セキュリティ詳細を広く共有してしまう |
特にグローバル SOC では、すべての地域を同じレポート設計にすると、権限・データ保持・クラウド対応の違いで欠損が起きることがあります。まずは本社テナントまたは代表リージョンでテンプレートを作り、各地域に横展開できる項目とローカル調整が必要な項目を分けてください。
移行期限：旧 API を使った Power BI レポートは棚卸しが必要
今回のポイントは、Power BI の作り方だけではありません。既存の Defender XDR 関連レポートが古い API に依存していないか確認する必要があります。
Microsoft Graph security API の公式情報では、高度なハンティングの旧 API が Microsoft Graph の Advanced Hunting API に置き換えられ、旧エンドポイントは 2027年2月1日にデータを返さなくなると説明されています。また、Power BI のカスタムレポートで古い API を使っている場合は、Microsoft Graph のパラメーターに更新するよう案内されています。(Microsoft Learn)
さらに、レガシー alerts API は非推奨で、2026年8月31日に廃止予定とされています。新しい alerts and incidents API への移行が求められているため、/security/alerts を使った古い実装が残っている場合は、/security/alerts_v2 や /security/incidents を前提に見直す必要があります。(Microsoft Learn)
| 確認対象 | 旧実装の例 | 推奨される見直し | 期限・注意点 |
|---|---|---|---|
| レガシー alerts API | /security/alerts | /security/alerts_v2 へ移行 | 2026年8月31日廃止予定 |
| 旧 Advanced Hunting API | api.security.microsoft.com などの旧エンドポイント | Microsoft Graph の runHuntingQuery へ移行 | 2027年2月1日に旧 API がデータ返却停止予定 |
| Power BI カスタムレポート | 旧 API を直接参照する Power Query | Graph security API 前提に修正 | 更新スケジュール前に検証が必要 |
| 自動化フロー | Power Automate、Logic Apps、独自スクリプト | 認証・権限・レスポンス形式を再確認 | レポート以外も影響する |
管理者が最初にやるべきことは、Power BI ファイルやデータフロー内で使われている URL を検索し、security/alerts、api.security.microsoft.com、api.securitycenter.microsoft.com などの旧系統が残っていないか洗い出すことです。
管理者が確認すべきチェックリスト
Power BI レポート作成前に、次の項目を確認してください。
| チェック項目 | 確認内容 | 実務での判断基準 |
|---|---|---|
| 目的 | 誰に何を見せるレポートか | SOC 用、管理職用、監査用を分ける |
| API | alerts_v2、incidents などの対象 | 古い /security/alerts を新規採用しない |
| 権限 | Graph API 権限と Defender ロール | 読み取り最小権限から開始する |
| フィルター | 期間、重大度、検出元、ステータス | 初回は直近3〜7日で検証する |
| データ量 | 列数、行数、更新頻度 | $select と期間指定で絞る |
| 更新方式 | 手動更新かスケジュール更新か | 本番共有前に認証切れを検証する |
| 共有範囲 | Power BI ワークスペースと閲覧者 | インシデント詳細を広く出さない |
| 移行 | 旧 API の利用有無 | 2026年8月、2027年2月の期限を確認する |
| 国・地域 | クラウド対応状況 | China 21Vianet など対象外環境に注意 |
| 運用 | 失敗時の担当者と復旧手順 | データ更新失敗を監視する |
このチェックリストで重要なのは、Power BI の見た目よりも先に、権限・API・データ量・共有範囲を固めることです。ダッシュボードは後から改善できますが、権限設計とデータ取得方式を後から直すと、レポート全体の作り直しになりやすくなります。
実務で使いやすい SOC ダッシュボードの設計例
公式サンプルでは、SOC の効率を把握するダッシュボードとして、最近のアラート概要、検出ソース、重大度、総アラート数、平均解決時間、攻撃データ、MITRE ATT&CK とのマッピングなどを確認する構成が示されています。(Microsoft Learn)
実務で作るなら、次のようなページ構成にすると運用しやすくなります。
SOC 概要ページ
最初のページでは、細かいアラート一覧ではなく、全体像を見せます。
| 指標 | 目的 | 例 |
|---|---|---|
| 総アラート数 | ノイズや検出量の変化を見る | 前月比、前週比 |
| 高重大度アラート数 | 優先対応が必要な増減を見る | High / Medium / Low |
| 未解決インシデント数 | 滞留状況を見る | Active、In progress |
| 平均解決時間 | SOC 効率を見る | MTTR |
| 検出元別件数 | どの製品・領域で多いか見る | Endpoint、Office 365、Identity |
ここでは、経営層や管理職が見ても理解できる表現にします。アラート名を大量に並べるより、「どこが増えたか」「何が遅れているか」が分かる構成にしてください。
アラート分析ページ
SOC アナリスト向けには、検出元、重大度、ステータス、分類、担当者、発生日などで絞り込めるページを作ります。alerts_v2 では、createdDateTime、lastUpdateDateTime、severity、serviceSource、status などがフィルター対象として示されています。(Microsoft Learn)
具体的には、次のような分析軸が有効です。
- 重大度別のアラート件数
- 検出元別のアラート件数
- ステータス別の未対応件数
- 担当者別の対応件数
- 曜日・時間帯別の発生傾向
- MITRE technique 別の頻出傾向
インシデント分析ページ
アラート単位だけで見ると、複数のアラートが同じ攻撃に属しているケースを見落としやすくなります。Microsoft 365 Defender は、同じ攻撃技術や攻撃者に関連するアラートをインシデントに相関するため、インシデント単位のページも用意すべきです。(Microsoft Learn)
インシデント分析ページでは、次の指標が役立ちます。
| 指標 | 使い方 |
|---|---|
| インシデント重大度 | 対応優先度の判断 |
| ステータス | 未対応・対応中・解決済みの把握 |
| 分類 | True positive / False positive などの品質確認 |
| 発生から解決までの時間 | SOC 効率の改善 |
| 関連アラート数 | 複雑な攻撃の把握 |
| 影響範囲 | デバイス、ユーザー、メールボックスなどの確認 |
よくある失敗と対策
データを全部読み込んでレポートが重くなる
Power BI で最初にやりがちな失敗は、期間も列も絞らずに全データを読み込むことです。アラートが多い環境では、数百 MB 規模の読み込みになる可能性があるため、まずは期間を短くして検証し、必要な列だけを取得してください。(Microsoft Learn)
対策は、$filter で期間を絞る、$select で列を絞る、Power BI 側で不要な列を早めに削除する、更新頻度を必要最小限にすることです。
作成者には見えるが閲覧者には見えない
Power BI のレポート作成者が Security Administrator など強い権限を持っていると、作成時には問題なく見えます。しかし、共有された閲覧者に同じデータが見えるとは限りません。逆に、データセットの資格情報設定によっては、閲覧者が本来見るべきでない情報をレポート経由で見てしまう可能性もあります。
対策は、開発用アカウント、本番更新用アカウント、閲覧者を分け、公開前に権限の異なるユーザーで表示確認することです。
旧 API のまま運用している
既存の Power BI レポートや自動化スクリプトが古い API を使っている場合、現時点で動いていても将来的に停止する可能性があります。レガシー alerts API は 2026年8月31日廃止予定、旧 Advanced Hunting API は 2027年2月1日にデータを返さなくなる予定とされているため、早めの移行計画が必要です。(Microsoft Learn)
対策は、Power BI の Advanced Editor、Power Query、データフロー、Power Automate、Logic Apps、Azure Functions、独自スクリプトの接続先を棚卸しすることです。
セキュリティ詳細を広く共有してしまう
Microsoft Defender XDR のアラートやインシデントには、端末名、ユーザー情報、攻撃手法、推奨対応、URL、IP アドレスなど機微な情報が含まれることがあります。Power BI の共有範囲を広げる前に、集計レポートと詳細レポートを分けるべきです。
経営層向けには件数や傾向を中心にし、SOC 向けには詳細情報を含める。部門長向けには自部門の集計のみを表示する。こうした分離をしないと、セキュリティ可視化のためのレポートが情報漏えいリスクになります。
移行・導入の進め方
初めて Microsoft Defender XDR の Power BI カスタムレポートを作る場合は、いきなり全社展開せず、次の順序で進めると失敗しにくくなります。
| フェーズ | 実施内容 | 完了条件 |
|---|---|---|
| 調査 | 既存レポートと旧 API 利用箇所を棚卸し | 接続先 URL と所有者が分かる |
| 検証 | alerts_v2 を直近3〜7日で取得 | Power BI Desktop で読み込み成功 |
| 権限確認 | 最小権限ロールで表示を確認 | 管理者以外でも必要データが見える |
| 設計 | 指標、期間、共有範囲を決定 | SOC 用と管理職用を分ける |
| 実装 | パラメーター、フィルター、列選択を設定 | 更新時間が許容範囲に収まる |
| 公開 | Power BI Service に発行 | 閲覧者別に表示確認済み |
| 運用 | 更新失敗、API 変更、権限変更を監視 | 月次でレビューできる |
特に移行対象が多い組織では、「古い API の置き換え」と「新しいダッシュボード作成」を同時に進めると混乱します。まずは既存レポートの停止リスクを潰し、その後に Power BI の指標改善を進める方が安全です。
まとめ：管理者は API・権限・期限を先に確認する
Microsoft Defender XDR の「Create custom Microsoft Defender XDR reports using Microsoft Graph security API and Power BI」は、Power BI で SOC 向けのカスタムレポートを作るための実践的なガイドです。標準レポートでは足りない分析を補い、アラート、インシデント、重大度、検出元、対応時間、MITRE ATT&CK との関係を自社の運用に合わせて可視化できます。
管理者が最初に確認すべきことは、画面デザインではなく、次の4点です。
alerts_v2、incidentsなど Microsoft Graph security API を前提にするSecurityAlert.Read.All、SecurityIncident.Read.Allなど最小権限を確認する$filter、$select、期間パラメーターでデータ量を制御する- レガシー alerts API と旧 Advanced Hunting API の移行期限を確認する
次に取るべき行動は、既存の Power BI レポートや自動化処理で使っている API を棚卸しし、旧 API が残っていないか確認することです。そのうえで、直近数日の alerts_v2 取得から小さく検証し、SOC 用、管理職用、監査用のレポートを分けて設計すると、実務で使える Microsoft Defender XDR レポートに育てやすくなります。
コメント