Microsoft Sentinel data lake and graphは、Microsoft Sentinelのログ活用を「SIEMの分析基盤」から「長期保管・横断分析・グラフ調査」へ広げるための重要な機能です。2026年4月22日に更新されたMicrosoft公式ドキュメントでは、オンボーディング時の前提条件、課金、データ所在地、既存ワークスペースへの影響、Purview連携まで、導入前に確認すべきポイントが整理されています。(Microsoft Learn)
結論から言うと、Microsoft Sentinel data lake and graphは「有効化すれば便利」な単機能ではありません。オンボーディングすると、同一リージョンかつDefenderポータルに接続されたワークスペースが自動的にデータレイクへ関連付けられ、補助ログ、長期保持、検索、KQLジョブ、グラフ調査、コスト管理の扱いが変わります。特にsecurity admins、identity teams、compliance teamsは、権限、リージョン、CMK、Azure Policy、課金メーターを事前に確認してから進めるべきです。(Microsoft Learn)
Microsoft Sentinel data lake and graphの2026年4月更新ポイント
2026年4月更新の公式ページは、Microsoft Sentinel data lakeとMicrosoft Sentinel graphへオンボーディングするための実務的な前提条件と影響範囲を説明する内容です。Microsoft Sentinel data lakeは、さまざまなソースから収集したセキュリティ関連データをテナント単位で収集・保存・管理するリポジトリであり、Microsoft Sentinel graphは、セキュリティ、コンプライアンス、ID領域でグラフベースの体験を支える統合機能として説明されています。(Microsoft Learn)
今回のポイントは、単に「データレイクが使える」ことではなく、オンボーディング後にMicrosoft Defender XDR、Microsoft Purview Data Security Investigations、Microsoft Purview Insider Risk Managementと連携し、調査・ハンティング・データリスク分析の入口が広がる点です。Microsoft公式ドキュメントでは、これらのソリューションでMicrosoft Sentinel data lake and graphを利用できるとされています。(Microsoft Learn)
特に注目すべき変更点は次のとおりです。
| 確認項目 | 更新内容として押さえるポイント | 実務での影響 |
|---|---|---|
| オンボーディング対象 | Defenderポータルに接続済みで、プライマリSentinelワークスペースと同じリージョンにあるワークスペースが対象 | 対象ワークスペースを個別に選ぶ運用ではなく、事前棚卸しが必要 |
| データレイク配置 | プライマリSentinelワークスペースと同じリージョンにプロビジョニング | リージョン設計とデータ所在地の確認が必須 |
| グラフ機能 | オンボーディング時にgraph機能も有効化 | インシデントのblast radius分析やhunting graphに活用可能 |
| 補助ログ | オンボーディング後、auxiliary log tablesはDefender Advanced Huntingではなくデータレイク側のKQLで扱う | 既存のハンティング手順や運用ドキュメントの更新が必要 |
| 課金 | 長期保持、検索、補助ログなどの一部がdata lakeベースの課金メーターへ移行 | 導入前にコスト見積もりと監視設計が必要 |
| ポリシー | Azure Policyが必要リソースの作成を妨げる可能性がある | 特定リソースタイプの例外設定を検討 |
まず理解すべき「data lake」と「graph」の違い
Microsoft Sentinel data lakeは、長期保管や大規模分析を前提にしたセキュリティデータ基盤です。Microsoftの説明では、Microsoft Defender XDR、サードパーティソース、資産、アクティビティログ、脅威インテリジェンスなどのデータを統合し、階層化されたストレージやオンデマンドのデータ昇格によって、コストと可視性のバランスを取りやすくする設計になっています。(Microsoft Learn)
一方、Microsoft Sentinel graphは、ユーザー、デバイス、クラウドリソース、データ、アクティビティ、脅威インテリジェンスの関係性をノードとエッジで表現するための機能です。テーブル形式のログだけでは見えにくい「このユーザーが侵害された場合、どの重要資産に影響が広がるか」「機密ファイルに誰がどの経路でアクセスしたか」といった調査に向いています。(Microsoft Learn)
実務では、data lakeは「大量のログを長く持ち、必要なときに分析する場所」、graphは「ログや資産の関係性から攻撃経路や影響範囲を読み解く視点」と考えると理解しやすいでしょう。
オンボーディング前に満たすべき前提条件
Microsoft Sentinel data lake and graphを導入する前に、まずMicrosoft DefenderとMicrosoft Sentinelが構成済みである必要があります。公式ドキュメントでは、Microsoft SentinelをMicrosoft Defenderポータルで利用するためにMicrosoft Defender XDRライセンスは必須ではないと説明されています。(Microsoft Learn)
また、データレイクの課金設定にはAzureサブスクリプションとリソースグループが必要です。ここで注意したいのは、管理グループレベルの所有者であるだけでは不十分で、サブスクリプションの直接の所有者である必要がある点です。(Microsoft Learn)
必須条件のチェックリスト
| 項目 | 確認すべき内容 | 担当しやすいチーム |
|---|---|---|
| Microsoft Defender / Sentinel | DefenderポータルとMicrosoft Sentinelが構成済みか | security admins |
| Azureサブスクリプション | 課金用のサブスクリプションとリソースグループを用意しているか | cloud admins / security admins |
| 権限 | サブスクリプション所有者または共同作成者、Microsoft EntraのGlobal AdministratorまたはSecurity Administrator、各ワークスペースの読み取り権限があるか | security admins / identity teams |
| プライマリワークスペース | SentinelのプライマリワークスペースがDefenderポータルに接続されているか | security admins |
| リージョン | プライマリワークスペースとデータレイクのリージョン要件を満たすか | compliance teams / cloud admins |
| Microsoft 365データ | Microsoft 365データがデータレイクと同じリージョンにない場合の同意判断が済んでいるか | compliance teams |
| CMK | Customer-Managed Keysを使うワークスペースがないか、または制約を許容できるか | compliance teams |
日本の環境で特に確認したいリージョン要件
日本の読者にとって重要なのは、Microsoft Sentinel data lakeの対応リージョンです。Microsoft公式のリージョン表では、日本のMicrosoft Sentinel SIEMはJapan EastとJapan Westが示されていますが、data lake supported regionとしてはJapan Eastが示されています。Microsoft Sentinel data lakeは、関連付けられたプライマリSentinelワークスペースと同じAzureリージョンにデプロイする必要があるとも説明されています。(Microsoft Learn)
そのため、日本国内の環境で既存のSentinelワークスペースをJapan Westに置いている場合は、Microsoft Sentinel data lakeを前提にした構成変更が必要になる可能性があります。実際の導入前には、最新の対応リージョン表と自社のデータ所在地ポリシーを必ず照合してください。
CMKを使っている組織は要注意
コンプライアンス観点で最も見落としやすいのがCustomer-Managed Keys、つまりCMKです。公式ドキュメントでは、Microsoft Sentinel data lakeに保存されるデータではCMKがサポートされず、CMKを適用しているSentinelワークスペースはdata lake experiencesからアクセスできないと説明されています。データレイクに取り込まれるカスタムテーブルや変換済みデータはMicrosoft-managed keysで暗号化されるとも記載されています。(Microsoft Learn)
これは、金融、公共、医療、グローバル企業の内部統制では大きな判断材料になります。CMKを必須とする暗号化ポリシーを運用している場合、「Microsoft Sentinel data lakeを使えるか」ではなく、「Microsoft-managed keysで暗号化されるデータを許容できるか」を先に確認すべきです。
オンボーディングすると何が変わるのか
オンボーディング時には、選択したAzureサブスクリプションとリソースグループにデータレイクがプロビジョニングされます。データレイクはプライマリSentinelワークスペースと同じリージョンに作成され、Defenderに接続済みで同一リージョンにあるすべてのワークスペースがMicrosoft Sentinel data lakeに接続されます。Defenderに接続されていないワークスペースは接続されません。(Microsoft Learn)
ここで重要なのは、ワークスペースを任意に選んでオンボーディングする仕組みではない点です。公式ドキュメントでは、同一リージョンでDefenderに接続されたワークスペースは自動的にオンボーディングされ、特定のワークスペースだけを自力でオフボードすることはできず、オフボードにはサポートリクエストが必要と説明されています。(Microsoft Learn)
オンボーディング後の主な変化
| 変化 | 内容 | 導入前にやるべきこと |
|---|---|---|
| データレイクの作成 | 選択したサブスクリプションとリソースグループに作成 | サブスクリプションの所有者、課金責任者、リソースグループ命名ルールを確認 |
| ワークスペース接続 | 同一リージョンかつDefender接続済みワークスペースが自動接続 | 対象ワークスペースを棚卸しする |
| データ階層 | Analytics tierのデータがdata lake tierでも利用可能になる | テーブルごとの保持方針を整理 |
| データ表示までの時間 | 初回有効化や階層変更後、テーブル表示に90〜120分かかる場合がある | 検証計画に待ち時間を入れる |
| System tables | Microsoft Entra、Microsoft 365、Azure Resource Graphの資産データが自動取り込みされる | ID・M365・Azure資産データの取り扱いを確認 |
| Graph機能 | Defenderのgraph調査やhunting graphに利用される | インシデント対応手順にgraph調査を追加 |
| Auxiliary logs | Advanced Huntingではなくdata lake exploration KQL queriesで扱う | 既存クエリやSOC手順書を更新 |
補助ログとAdvanced Huntingの扱いは運用変更が必要
既存のSOC運用でMicrosoft Defender Advanced Huntingを使っている場合、auxiliary log tablesの扱いに注意が必要です。公式ドキュメントでは、Microsoft Defenderに接続されたワークスペースのauxiliary log tablesは、data lake有効化後にMicrosoft Sentinel data lakeの一部となり、KQL queriesやJobsなどのdata lake experiencesで利用できる一方、Defender Advanced Huntingからはアクセスできなくなると説明されています。(Microsoft Learn)
これは小さなUI変更ではありません。たとえば、既存の調査手順で「Advanced Huntingから補助ログを確認する」と書かれている場合、オンボーディング後は「Defenderポータルのdata lake exploration KQL queriesで確認する」に変更する必要があります。SOCの手順書、トリアージテンプレート、教育資料、KQLクエリ集を事前に見直しましょう。
課金は「有効化後に気づく」と遅い
Microsoft Sentinel data lake and graphの導入では、課金の見え方も変わります。公式ドキュメントでは、オンボーディング後、既存の長期保持、検索、補助ログ取り込みといったメーターではなく、data lake tierのメーターに基づいて課金されると説明されています。(Microsoft Learn)
data lake tierでは、データレイク専用テーブルへの取り込み、データ処理、データレイクストレージ、ノートブックやジョブ、カスタムグラフのノード・エッジ構築などで使うコンピュート時間が課金対象になり得ます。一方、Defenderポータルのhunting graphやblast radius visualizations、PurviewポータルのInsider Risk ManagementとData Security Investigationsのグラフは、公式ドキュメント上では追加の課金や消費料金が発生しないとされています。(Microsoft Learn)
導入前に見るべきポイントは、単価そのものより「どのログをAnalytics tierに残し、どのログをData lake tier中心で保持するか」です。高頻度でアラートやインシデントに使うログはAnalytics tier、調査時に必要になる低頻度・大容量ログはData lake tierというように、利用頻度と調査価値で分類すると判断しやすくなります。
Azure Policyによるブロックを事前に防ぐ
企業環境では、Azure Policyでリソース作成を制御しているケースが多くあります。Microsoft公式ドキュメントでは、Microsoft Sentinel data lakeのオンボーディング時に既存のAzure Policy定義が必要リソースのデプロイをブロックする可能性があるため、オンボーディング対象のリソースグループにスコープを絞ったポリシー例外を構成することが案内されています。対象リソースタイプはMicrosoft.SentinelPlatformServices/sentinelplatformservicesです。(Microsoft Learn)
ここでのポイントは、全社ポリシーを緩めるのではなく、オンボーディング対象リソースグループに絞って例外を設けることです。セキュリティ統制を維持しながら導入を進めるには、Azure Policy担当者、Sentinel管理者、監査担当者が事前に例外範囲を合意しておく必要があります。
Microsoft Purview連携で広がる調査シナリオ
Microsoft Sentinel data lake and graphは、Microsoft Purviewのデータリスク調査でも重要になります。Data Security Investigationsでは、data risk graphが調査対象ファイルに関する過去30日のアクティビティを要約し、リスクのあるユーザーアカウントやイベントの流れを把握するために使われます。(Microsoft Learn)
Insider Risk Managementでも、data risk graphは潜在的な内部不正や不注意によるリスクに関連するアクティビティを可視化し、過去30日のアラート関連アクティビティから隠れた文脈を明らかにする用途で説明されています。ただし、匿名化ユーザー名のプライバシー設定が有効な場合、この機能は利用できないとされています。(Microsoft Learn)
Purview連携で特に注意したいのは、Microsoft 365とMicrosoft Entra IDのデータコネクタです。公式ドキュメントでは、Microsoft 365コネクタではSharePoint record types、Microsoft Entra IDコネクタではSign-In LogsとUser Risk Eventsを収集する必要があると説明されています。(Microsoft Learn)
Purview連携で確認すべきこと
| 利用シーン | 必要な準備 | 注意点 |
|---|---|---|
| Data Security Investigations | 調査の作成、Microsoft Sentinel data lake and graphの前提条件確認 | 初期作成時は直近7日分から始まり、最大30日まで段階的に広がる |
| Insider Risk Management | サポート対象のデータ流出アクティビティに関するポリシー設定 | 匿名化ユーザー名が有効だとグラフが読み込まれない |
| SharePoint / OneDrive調査 | Microsoft 365コネクタで必要なレコードタイプを収集 | ファイルダウンロードやリンク作成などの活動を調査対象にする |
| IDリスク調査 | Entra IDのSign-In LogsとUser Risk Eventsを収集 | identity teamsとの連携が必須 |
Defenderポータルへの移行もあわせて考える
Microsoft Sentinelは、今後の運用画面としてMicrosoft Defenderポータルの重要性が高まっています。Microsoft公式ドキュメントでは、2027年3月31日以降、Microsoft SentinelはAzureポータルではサポートされず、Microsoft Defenderポータルでのみ利用可能になると説明されています。(Microsoft Learn)
そのため、Microsoft Sentinel data lake and graphのオンボーディングは、単なる新機能の有効化ではなく、Sentinel運用をDefenderポータル中心へ移行する流れの一部として計画するのが現実的です。既存のAzureポータル前提の手順、教育資料、権限設計、インシデント対応フローは、早めにDefenderポータル前提へ見直しておきましょう。
導入手順の実務イメージ
Microsoft Defenderポータルからのオンボーディングは、テナント単位で一度実行されます。公式ドキュメントでは、Microsoft Defenderポータルにサインインし、オンボーディングバナーまたはSystem > Settings > Microsoft Sentinel > Data lakeから開始し、サブスクリプションとリソースグループを選択してdata lakeをセットアップする流れが説明されています。セットアップ処理は最大60分かかる場合があります。(Microsoft Learn)
実務では、次の順番で進めると失敗を減らせます。
| ステップ | 作業 | 完了条件 |
|---|---|---|
| 事前棚卸し | Sentinelワークスペース、リージョン、Defender接続状態を確認 | 自動オンボーディング対象が分かっている |
| 権限確認 | Azure、Entra ID、Sentinelワークスペースの権限を確認 | サブスクリプション所有者または必要ロールが割り当て済み |
| コンプライアンス確認 | CMK、Microsoft 365データ所在地、保持期間を確認 | データ保護方針との矛盾がない |
| ポリシー確認 | Azure Policyで必要リソースがブロックされないか確認 | 必要に応じて限定的な例外を設定 |
| コスト確認 | data lake tier、検索、保持、ジョブ、ノートブックの利用方針を整理 | 導入後のコスト監視項目が決まっている |
| オンボーディング | Defenderポータルからセットアップ | セットアップ完了を確認 |
| 検証 | KQL、Jobs、Graph、Purview連携を確認 | 調査手順に反映できる状態 |
失敗しやすいポイントと回避策
Microsoft Sentinel data lake and graphの導入では、機能そのものよりも「準備不足」によるつまずきが起きやすくなります。
| 失敗しやすいポイント | 起きる問題 | 回避策 |
|---|---|---|
| 管理グループ所有者だけで進める | サブスクリプション所有者要件を満たせない | 直接のサブスクリプション所有者を確認する |
| ワークスペースを個別選択できると思い込む | 想定外の同一リージョンワークスペースが接続対象になる | Defender接続済みワークスペースを事前に棚卸しする |
| CMKの制約を見落とす | data lake experiencesから対象ワークスペースにアクセスできない | 暗号化ポリシーとMicrosoft-managed keysの扱いを確認する |
| Advanced Huntingの既存手順を更新しない | auxiliary logsの確認場所が変わり、調査が遅れる | data lake exploration KQL queries前提に手順を改訂する |
| Azure Policyを確認しない | 必要リソースのデプロイがブロックされる | 対象リソースグループに限定した例外を検討する |
| すぐにデータが見えると思う | 初回有効化や階層変更後に待ち時間が発生する | 90〜120分の反映時間を検証計画に入れる |
| コスト監視を後回しにする | 長期保持やジョブ利用で想定外の請求につながる | 導入前からCost Managementで監視軸を決める |
チーム別に見る導入判断のポイント
security adminsが見るべきポイント
security adminsは、SOC運用への影響を中心に確認します。特に、どのワークスペースがオンボーディング対象になるか、auxiliary logsをどこで調査するか、KQL jobsやdata lake explorationを誰が使うかを決めておく必要があります。
また、インシデント対応ではblast radius analysisやhunting graphを使うことで、侵害されたユーザーやデバイスから重要資産へどのように影響が広がるかを把握しやすくなります。Microsoft Sentinel graphは、DefenderやPurviewのグラフベース機能を支えると説明されており、テーブルログだけでは把握しにくい関係性の分析に向いています。(Microsoft Learn)
identity teamsが見るべきポイント
identity teamsは、Microsoft Entra IDのSign-In Logs、User Risk Events、ユーザー・グループ・権限の関係性を中心に見ます。graphを使った調査では、侵害されたアカウント、過剰権限、重要資産への到達経路が重要になります。
導入前には、Entra IDログの収集状態、リスクイベントの扱い、特権ロールの割り当て、Global Administratorの利用範囲を確認してください。Microsoftは、Global Administratorのような高権限ロールは緊急時などに限定し、最小権限を推奨しています。(Microsoft Learn)
compliance teamsが見るべきポイント
compliance teamsは、リージョン、暗号化、保持期間、監査、Microsoft 365データの越境可能性を確認します。公式ドキュメントでは、Microsoft 365データがデータレイクと同じリージョンにない場合、オンボーディングによってデータレイクのあるリージョンへ取り込むことに同意することになると説明されています。(Microsoft Learn)
特にグローバル企業では、拠点ごとにデータ保護要件が異なることがあります。オンボーディング前に、法務、プライバシー、監査、セキュリティ運用が同じ判断材料を見て合意することが重要です。
導入後に最初にやるべき確認作業
オンボーディングが完了したら、すぐ本番運用へ組み込むのではなく、まず検証期間を設けます。
最初に、DefenderポータルでLake exploration、Table management、Data connectors、Settings、Cost management、Graphなどの機能が表示されるかを確認します。公式ドキュメントでは、オンボーディング後にこれらの新機能が有効になると説明されています。(Microsoft Learn)
次に、Microsoft Entra、Microsoft 365、Azure Resource GraphのSystem tablesがLake exploration experiencesのワークスペース選択UIで見えるかを確認します。これらの資産データは自動的にMicrosoft Sentinel data lakeのSystem tablesへ取り込まれるとされています。(Microsoft Learn)
最後に、既存のKQLクエリ、補助ログの調査、コスト監視、Purviewのdata risk graphをテストします。Data Security InvestigationsやInsider Risk Managementのdata risk graphは、初期処理に24〜48時間かかる場合があり、最初は直近7日分から始まって最大30日まで広がると説明されています。(Microsoft Learn)
まとめ：オンボーディング前に「対象・権限・データ・コスト」を固める
Microsoft Sentinel data lake and graphの2026年4月更新ポイントは、導入手順そのものよりも、オンボーディングによって何が変わるかを事前に理解することにあります。特に、同一リージョンのDefender接続済みワークスペースが自動的に対象になること、CMKがサポートされないこと、auxiliary logsのアクセス先が変わること、data lakeベースの課金メーターへ移ることは、導入前に必ず確認すべきです。
次に取るべき行動は明確です。まず、Sentinelワークスペースとリージョンを棚卸しし、対象ワークスペースを特定します。次に、Azureサブスクリプション、Entra IDロール、ワークスペース権限を確認します。そのうえで、CMK、Microsoft 365データ所在地、Azure Policy、コスト監視を関係チームでレビューしてください。ここまで準備できてからオンボーディングを実行すれば、Microsoft Sentinel data lake and graphを単なる新機能ではなく、長期的なセキュリティ分析基盤として活用しやすくなります。
コメント