Microsoft Defenderで「Microsoft Sentinel data connectorが見つからない」「どのコネクタを使うべきか分からない」と感じた場合、まず見るべきポイントは Content hubに該当ソリューションが入っているか、Defenderポータル移行後に表示仕様が変わっていないか、Microsoft Defender XDRコネクタに統合されていないか の3つです。2026年5月14日に更新されたMicrosoft公式情報では、Microsoft Sentinelのデータ取り込みはDefenderポータル中心の運用へ移っており、Azureポータル前提の探し方だけでは見落としや重複取り込みが起きやすくなっています。(Microsoft Learn)
この記事では、Microsoft Defender環境で「Find your Microsoft Sentinel data connector」をどう読むべきか、Microsoft Defender XDRコネクタの影響、管理者・開発者が確認すべき設定、移行時に失敗しやすいポイントを実務目線で整理します。
Microsoft Defenderの「Find your Microsoft Sentinel data connector」で押さえるべき結論
Microsoft Learnの「Find your Microsoft Sentinel data connector」は、単なるコネクタ一覧ではありません。各データコネクタについて、対応サービス、取り込まれるLog Analyticsテーブル、DCR対応、Lake-only ingestion対応、前提条件、サポート元を確認するための参照ページです。公式ページでは、Microsoft Sentinel data connectorsはPreviewとされており、運用設計では仕様変更の可能性を前提に確認する必要があります。(Microsoft Learn)
特にMicrosoft Defender利用者にとって重要なのは、個別のDefender製品コネクタだけを見るのではなく、Microsoft Defender XDRコネクタを中心に設計することです。Microsoft Defender XDRコネクタは、Microsoft Defender for Endpoint、Microsoft Defender for Identity、Microsoft Defender for Office 365、Microsoft Defender for Cloud Appsなどのシグナルを統合して扱うため、従来の単体コネクタ運用とは見え方やスキーマが変わります。(Microsoft Learn)
管理者が最初に確認すべきことは、次の順番です。
| 確認項目 | 見る場所 | 判断ポイント |
|---|---|---|
| コネクタが見つからない | Content hub、Data connectors | 関連ソリューションが未インストールではないか |
| Defender関連のコネクタが表示されない | DefenderポータルのData connectors | 統合運用用コネクタとして非表示扱いになっていないか |
| データが入らない | 接続状態、Log Analytics、Advanced hunting | テーブル、取り込み先、遅延、DCR設定を確認 |
| 重複アラートが出る | Defender for Cloud、XDR連携設定 | レガシーコネクタとXDR連携が二重になっていないか |
| 既存KQLが動かない | Analytics rules、Workbooks、KQL | XDRコネクタ移行によるスキーマ差分を確認 |
何が変わるのか：Azureポータル中心からDefenderポータル中心へ
最大の変更点は、Microsoft Sentinelの操作場所がDefenderポータル中心へ移行していることです。Microsoftは、2027年3月31日以降、Microsoft SentinelはAzureポータルではサポートされず、Microsoft Defenderポータルのみで利用可能になると案内しています。AzureポータルでSentinelを運用している組織は、Defenderポータルへの移行計画を早めに立てる必要があります。(Microsoft Learn)
2026年5月14日に更新されたMicrosoft Sentinel data connectors関連の公式情報では、データコネクタの追加・構成・保持設定・データレイク連携などもDefenderポータルでの運用を前提に説明されています。Microsoft SentinelをDefenderポータルで使う場合、Data connectorsは「Microsoft Sentinel > Configurations > Data connectors」から確認します。(Microsoft Learn)
つまり、今後の実務では「AzureポータルでSentinelのコネクタを探す」よりも、DefenderポータルでContent hubからソリューションを確認し、Data connectorsで設定する流れを標準にしたほうが安全です。
Microsoft Defender XDRコネクタの影響範囲
Microsoft Defender環境で最も注意したいのが、Microsoft Defender XDRコネクタです。このコネクタは、Microsoft Defender XDRのインシデント、アラート、Advanced HuntingイベントをMicrosoft Sentinelにストリーミングし、両ポータル間でインシデントを同期します。Microsoft SentinelをDefenderポータルにオンボード済みの場合、Defender XDRコネクタは自動的に有効化されるため、Azureポータルでの手動構成は不要とされています。(Microsoft Learn)
公式のコネクタ一覧では、Microsoft Defender XDRコネクタの対象として次のテーブルが示されています。
| 主なテーブル | 用途の例 | 実務上の確認ポイント |
|---|---|---|
SecurityIncident | XDRインシデント | インシデント連携の有無を確認 |
SecurityAlert | アラート | 既存の分析ルールやWorkbookの参照先を確認 |
DeviceEvents | エンドポイントイベント | 取り込み量とコストに注意 |
EmailEvents | メール関連イベント | Defender for Office 365利用時に確認 |
IdentityLogonEvents | IDログオンイベント | Defender for Identity連携で確認 |
CloudAppEvents | クラウドアプリ操作 | Defender for Cloud Apps連携で確認 |
AlertEvidence | アラート証拠情報 | 調査・相関分析で活用 |
Microsoft Defender XDRコネクタは、DCRサポートおよびLake-only ingestionに対応するテーブルが多く、データ保持やコスト最適化の観点でも重要です。(Microsoft Learn)
Defender製品の単体コネクタとXDRコネクタはどう使い分けるか
Microsoft Defender for Endpoint、Defender for Identity、Defender for Office 365、Defender for Cloud Appsなどを使っている場合、以前は製品ごとの単体コネクタを個別に見るケースがありました。しかし、Defenderポータルで統合運用する場合は、Microsoft Defender XDRコネクタが中心になります。
特に注意すべきなのは、Microsoft Defender XDRコネクタを有効化すると、以前接続されていたMicrosoft Defenderコンポーネントの単体コネクタはバックグラウンドで自動的に切断されることです。画面上は接続済みに見える場合でも、データは流れない可能性があります。(Microsoft Learn)
| 状況 | 推奨される確認 |
|---|---|
| 新規にDefenderポータルでSentinelを使う | Microsoft Defender XDRコネクタを前提に確認 |
| Azureポータルで単体Defenderコネクタを使っていた | XDRコネクタ移行後のスキーマ差分を確認 |
| 既存のKQL、Workbook、分析ルールがある | SecurityAlertやエンティティ項目の変更を確認 |
| Defender for Cloudのアラートも扱う | テナントベースとサブスクリプションベースの重複を確認 |
実務では「コネクタ名が同じように見えるから問題ない」と判断しないことが重要です。XDRコネクタ経由のアラートは、単体コネクタ経由のアラートとフィールドマッピングやスキーマ構造が異なる場合があります。既存のKQL、Analytics rule、Workbook、外部チケット連携は移行前に必ずテストしてください。(Microsoft Learn)
コネクタが見つからないときの確認手順
Microsoft Sentinel data connectorが見つからない場合、製品名で検索するだけでは不十分です。コネクタは多くの場合、Content hubのソリューションに含まれており、該当ソリューションをインストールしてからData connectorsで構成します。Microsoft公式情報でも、必要なデータコネクタが見つからない場合は、関連ソリューションがContent hubにインストールされているか確認するよう案内されています。(Microsoft Learn)
Defenderポータルで確認する流れ
| 手順 | 操作 | 失敗しやすいポイント |
|---|---|---|
| 1 | Microsoft Defenderポータルを開く | Azureポータル側だけで探してしまう |
| 2 | Microsoft Sentinel > Content management > Content hub を開く | ソリューション未インストールでコネクタが出ない |
| 3 | 製品名またはサービス名で検索する | 略称だけで検索して見落とす |
| 4 | 該当ソリューションをインストールまたは更新する | 古いソリューションのまま使い続ける |
| 5 | Microsoft Sentinel > Configurations > Data connectors を開く | Content hubとData connectorsを混同する |
| 6 | Connector pageを開いて前提条件を確認する | 権限、APIキー、DCR、通信要件を見落とす |
| 7 | 接続後にデータ受信とテーブルを確認する | 「Connected」だけ見てKQL確認をしない |
Content hubでは、ソリューションやスタンドアロンコンテンツを検索し、必要に応じて一括インストールや更新ができます。ソリューションによっては依存関係があるため、CEF、Syslog、Custom logsなどを使う場合は依存ソリューションも同時に確認してください。(Microsoft Learn)
Defenderポータル移行後に一部コネクタが見えなくなる理由
DefenderポータルにSentinelワークスペースをオンボードすると、統合セキュリティ運用に使われる一部のデータコネクタはDefenderポータルのData connectorsページに表示されません。Microsoft公式情報では、Microsoft Defender for Cloud Apps、Microsoft Defender for Endpoint、Microsoft Defender for Identity、Microsoft Defender for Office 365、Microsoft Defender XDR、Microsoft Defender for Cloud関連コネクタなどが該当例として挙げられています。(Microsoft Learn)
これは「コネクタが消えた」「連携が壊れた」という意味ではありません。統合運用の仕組みに組み込まれたため、表示場所や確認方法が変わったと理解すべきです。
確認時は、次の観点で切り分けます。
| 症状 | 原因の可能性 | 確認方法 |
|---|---|---|
| Defender関連コネクタがData connectorsにない | 統合運用用コネクタとして非表示 | Microsoft Defender XDR連携状態を確認 |
| Azureポータルでは見えるがDefenderポータルでは見えない | ポータル間の表示仕様差 | 移行ドキュメントの対象コネクタ一覧を確認 |
| 以前の単体コネクタからデータが来ない | XDRコネクタ有効化で単体コネクタが切断 | SecurityIncidentやXDR系テーブルを確認 |
| 既存ルールの結果が減った | スキーマ差分またはフィルタリング | XDR connectorのスキーマ差分を確認 |
管理者が確認すべき設定
Microsoft DefenderとMicrosoft Sentinelを組み合わせる場合、管理者は「接続できるか」だけでなく、「誰が管理できるか」「どこに保存されるか」「重複しないか」「移行後に自動化が動くか」まで確認する必要があります。
権限とライセンス
Microsoft Defender XDRコネクタを構成するには、Microsoft Defender XDRの有効なライセンス、対象テナントでのSecurity Administrator相当の権限、Microsoft Sentinelワークスペースへの読み取り・書き込み権限などが必要です。また、コネクタ設定を変更するアカウントは、Sentinelワークスペースに関連付けられたMicrosoft Entraテナントに属している必要があります。(Microsoft Learn)
管理者が確認すべき項目は次の通りです。
| 項目 | 確認内容 |
|---|---|
| ライセンス | Microsoft Defender XDR、対象Defender製品、Sentinelの利用条件 |
| ロール | Security Administrator、Sentinel Contributor、ワークスペース権限 |
| テナント | コネクタ設定者とSentinelワークスペースのテナント整合性 |
| Content hub | Microsoft Defender XDRソリューションのインストール状態 |
| ワークスペース | プライマリワークスペース、複数ワークスペース構成 |
データ保持とData lake設定
Microsoft Sentinel data lakeにオンボードしている場合、コネクタごとにAnalytics tierとData lake tierの保持設定を確認できます。公式情報では、コネクタ有効化時の既定ではデータがAnalytics tierへ送られ、Data lake tierにもミラーされると説明されています。必要に応じて、Data lake onlyに切り替えることもできますが、その場合はAnalytics tierへの以後の取り込みが停止します。(Microsoft Learn)
実務上は、次のように判断するとよいです。
| 運用目的 | 推奨設定の考え方 |
|---|---|
| 即時検知・分析ルールで使う | Analytics tierに保持 |
| 長期保管・監査目的が中心 | Data lake tierの保持期間を検討 |
| 高ボリュームのイベントを安く保管したい | Lake-only ingestionの可否を確認 |
| Workbookや既存KQLで頻繁に使う | Analytics tierを安易に停止しない |
Data lakeへの取り込みには時間がかかる場合があり、公式情報ではデータレイクへの取り込みに90〜120分かかることがあると説明されています。接続直後にデータが見えない場合でも、即座に障害と判断せず、取り込み先と確認場所を分けて確認してください。(Microsoft Learn)
DCRとAMAの確認
「Find your Microsoft Sentinel data connector」の一覧では、各コネクタがDCRに対応しているかを確認できます。DCRはデータ収集や変換の設計に関わるため、単に「接続できるか」ではなく、どのテーブルがDCR対応か、Workspace transform DCRを使えるかを確認する必要があります。(Microsoft Learn)
SyslogやCEFを扱う場合は、Azure Monitor Agentを使う構成が重要です。AMAベースのコネクタでは、エージェントがインストールされたシステムからMicrosoft Sentinelへ接続できるよう、送信方向のポート443を許可する必要があります。(Microsoft Learn)
開発者・自動化担当者が確認すべきポイント
開発者や運用自動化担当者は、コネクタのUIだけでなく、API、KQL、スキーマ、CI/CD、チケット連携への影響を確認する必要があります。
既存KQLと分析ルールのスキーマ差分
単体コネクタからMicrosoft Defender XDRコネクタに移行すると、アラートのフィールドマッピング、派生フィールド、構造、フィルタリングが変わる場合があります。公式のスキーマ差分ページでは、Standalone connectorとXDR connectorの違いが既存のクエリ、Analytics rule、Workbookに影響し得ると説明されています。(Microsoft Learn)
特に確認したいのは、次のようなKQLです。
SecurityIncident
| where ProviderName == "Microsoft XDR"Microsoft Defender XDRインシデントがSentinelに入っているか確認する基本的なクエリです。既存のルールが ProviderName == "Azure Sentinel" や旧来の製品名を前提にしている場合、移行後に結果が変わる可能性があります。Microsoft Defender XDRコネクタの公式手順でも、SecurityIncident テーブルで ProviderName == "Microsoft XDR" を確認する例が示されています。(Microsoft Learn)
イベント量を確認する場合は、対象テーブルごとに確認します。
DeviceEvents
| summarize Count = count() by bin(TimeGenerated, 1d)
| order by TimeGenerated descEndpoint、Email、Identity、Cloud Appsなど、どのテーブルを有効化したかによって見るべきテーブルは変わります。接続状態だけで判断せず、実際に想定テーブルへデータが入っているか確認してください。
HTTP Data Collector API利用中のカスタム連携
カスタムコネクタや独自ログ連携を使っている場合は、レガシーAPIの廃止予定に注意が必要です。Microsoftの公式情報では、2026年9月14日以降、legacy HTTP Data Collector APIはサポートされなくなり、利用中のデータソース、カスタム統合、コネクタはLogs Ingestion APIまたはCodeless Connector Frameworkへの移行を計画するよう案内されています。(Microsoft Learn)
開発者は、次の切り分けで棚卸しすると移行漏れを減らせます。
| 現在の連携方式 | 確認すべきこと | 移行候補 |
|---|---|---|
| HTTP Data Collector API | 2026年9月14日以降のサポート影響 | Logs Ingestion API、CCF |
| Azure FunctionsでREST API取得 | 認証情報、実行頻度、失敗時リトライ | Logs Ingestion API、Logic Apps |
| CEF/Syslog | AMA、送信443、DCR、フォワーダー | Syslog via AMA、CEF via AMA |
| 独自テーブル | テーブル名、DCR、保持設定 | Custom Logs via AMA、Log Ingestion API |
| IaC展開 | ARM/Bicep/Terraformのテンプレート | Content hub API、ARM展開 |
Microsoft Defender for Cloudを使う組織の重複対策
Microsoft Defender for CloudのアラートをMicrosoft SentinelとMicrosoft Defender XDRの両方で扱う場合、重複アラート・重複インシデントに注意が必要です。Microsoft公式情報では、Microsoft Defender XDRインシデントをSentinelへ統合し、Defender for Cloudアラートも取り込む場合、Tenant-based Microsoft Defender for Cloudコネクタを構成し、Subscription-based Microsoft Defender for Cloudレガシーコネクタを切断することで重複を防ぐ手順が示されています。(Microsoft Learn)
確認すべき構成は次の通りです。
| 構成 | 推奨確認 |
|---|---|
| Tenant-based Microsoft Defender for Cloud | テナント全体のアラート同期に使う |
| Subscription-based Microsoft Defender for Cloud Legacy | 重複防止のため切断対象になる可能性あり |
| Defender for Cloudアラート由来の分析ルール | インシデント生成が重複していないか確認 |
| 複数ワークスペース | プライマリワークスペースへの流れを確認 |
この部分はSOC運用に直接影響します。重複したインシデントはアナリストの負荷を増やし、逆に誤って切断するとアラートを見落とします。移行作業では、本番切り替え前に特定サブスクリプションや検証ワークスペースで流入状況を確認するのが安全です。
移行・展開時に失敗しやすいポイント
Microsoft DefenderとMicrosoft Sentinel data connectorの移行では、UI上の「接続済み」だけを見て判断すると失敗します。実務でよくある落とし穴を整理します。
| 失敗例 | 原因 | 対策 |
|---|---|---|
| コネクタが見つからない | Content hubのソリューション未導入 | 先にContent hubでインストール |
| 接続済みなのにデータがない | XDRコネクタで単体コネクタが切断 | XDR側のテーブルを確認 |
| アラートが二重になる | Defender for Cloudの新旧コネクタ併用 | レガシーコネクタと分析ルールを棚卸し |
| Workbookが空になる | 参照テーブルやフィールドが変わった | スキーマ差分に合わせてKQL修正 |
| 自動化ルールが動かない | インシデント項目やProviderNameが変化 | 条件をタイトル依存からルール名・タグへ変更 |
| データが遅れて見える | Data lake取り込みの遅延 | Analytics tierとData lake tierを分けて確認 |
| 高額な取り込みコストが発生 | Advanced huntingイベントを広く有効化 | 必要テーブルだけ有効化し保持期間を調整 |
特に自動化ルールと外部チケット連携は注意が必要です。Defenderポータルへのオンボード後は、インシデント相関やProviderName、SecurityIncidentテーブルの一部項目が変わる可能性があります。Microsoft公式情報では、Defenderポータル移行後の自動化ルール、playbook、API応答、インシデント相関の変更点が詳しく説明されています。(Microsoft Learn)
実務での推奨チェックリスト
移行や新規展開の前に、次のチェックリストを使うと漏れを減らせます。
管理者向けチェックリスト
| チェック | 内容 |
|---|---|
| ポータル | DefenderポータルでSentinelを管理する前提になっているか |
| 期限 | 2027年3月31日以降のAzureポータル非サポートを計画に入れているか |
| Content hub | 必要なソリューションがインストールまたは更新済みか |
| 権限 | Sentinel Contributor、Security Administratorなどが適切か |
| Defender XDR | XDRコネクタの有効化状態を確認したか |
| Defender for Cloud | テナントベースとレガシーコネクタの重複を確認したか |
| 保持設定 | Analytics tier、Data lake tier、Lake-only ingestionを確認したか |
| サポート元 | Microsoft、Partner、Communityのどれが支援元か確認したか |
開発者・運用自動化担当者向けチェックリスト
| チェック | 内容 |
|---|---|
| KQL | SecurityIncident、SecurityAlert、各Advanced huntingテーブルを確認したか |
| 分析ルール | XDRコネクタ移行後も条件が成立するか |
| Workbook | 参照フィールドやテーブル名が変わっていないか |
| Playbook | Incident trigger、ProviderName、Description依存がないか |
| API | Sentinel APIとMicrosoft Graph APIの役割を整理したか |
| カスタム連携 | HTTP Data Collector APIを使っていないか |
| IaC | Content hubやコネクタ展開のテンプレートを最新化したか |
| ログ量 | 高ボリュームテーブルの保持期間とコストを見積もったか |
次に取るべき行動
Microsoft Defender環境でMicrosoft Sentinel data connectorを探すときは、まずDefenderポータルのContent hubで対象ソリューションを確認し、その後Data connectorsで設定します。Defender製品のデータは、単体コネクタではなくMicrosoft Defender XDRコネクタに統合されている可能性が高いため、SecurityIncident、SecurityAlert、DeviceEvents、EmailEventsなどのテーブルで実際の取り込みを確認してください。
既存のAzureポータル運用がある場合は、2027年3月31日までの移行期限を前提に、次の順で進めるのが現実的です。
- 現在使っているデータコネクタ、分析ルール、Workbook、Playbookを棚卸しする。
- Microsoft Defender XDRコネクタへ統合される範囲を確認する。
- Defender for Cloudの新旧コネクタ重複を確認する。
- 既存KQLと自動化ルールをXDRスキーマに合わせて検証する。
- Content hubのソリューション更新、DCR、Data lake保持設定を反映する。
- 本番切り替え後は、接続状態ではなく実データの流入をKQLで確認する。
「Find your Microsoft Sentinel data connector」は、コネクタ名を探すためだけのページではありません。Microsoft DefenderとSentinelを統合運用するために、どのデータを、どのテーブルへ、どのサポート範囲で、どのポータルから管理するのかを判断するための実務資料として活用しましょう。
コメント