Microsoft Defender multitenant managementは、複数テナントのMicrosoft Defender XDRと、Microsoft Defenderポータル上のMicrosoft Sentinelをまとめて監視・調査するための管理機能です。2026年5月27日の公式情報更新で特に確認すべき点は、Tenant groupsによる表示対象テナントの切り替え、Microsoft Sentinelワークスペースの扱い、権限設計、Azure Lighthouseが必要になる条件です。複数顧客を管理するMSSP、グループ会社を横断管理するSOC、複数テナントを持つ情報システム部門は、設定をそのまま使い始める前に、表示範囲と権限範囲を必ず確認してください。(Microsoft Learn)
Microsoft Defender multitenant managementとは
Microsoft Defender multitenant managementは、Microsoft Defenderポータルで複数テナントのセキュリティ運用を一元化する仕組みです。対象はMicrosoft Defender XDR、Microsoft Sentinel in the Microsoft Defender portal、Microsoft Defender for Endpoint Plan 2、Microsoft Defender for Office 365 P2とされています。公式ドキュメントでは、複数テナントのインシデント調査やAdvanced Huntingを単一の統合ビューから行える点が説明されています。(Microsoft Learn)
従来の運用では、顧客ごと、部門ごと、グループ会社ごとにテナントを切り替えながら、インシデント、アラート、脆弱性、デバイス状態を確認する必要がありました。multitenant managementを使うと、SOC担当者は複数テナントの状況を横断的に把握し、優先度の高いアラートや露出度の高いテナントから対応できます。
ただし、「まとめて見える」ことは「すべてを自由に操作できる」こととは違います。表示・管理できる内容は、各テナントで付与された権限、Microsoft Entra B2B、GDAP、RBAC、ライセンス、Microsoft Sentinelの接続状態に左右されます。導入時は、機能の有効化よりも先に誰が、どのテナントの、どのデータを、どこまで操作できるのかを整理することが重要です。(Microsoft Learn)
2026年5月27日更新で押さえるべき変更点
2026年5月27日の更新で目立つのは、Tenant groups関連の追加と整理です。Microsoft Learnの概要ページは2026年5月27日に更新され、GitHub上の履歴では、Tenant groups記事の追加、概要ページへのTenant groups行の追加、Next stepsへのTenant groups記事リンク追加が確認できます。(Microsoft Learn)
| 確認ポイント | 内容 | 管理者への影響 |
|---|---|---|
| Tenant groupsの追加・整理 | 管理対象テナントを名前付きグループにまとめ、表示対象を切り替えられる | 顧客別、事業部別、地域別などのSOC運用ビューを設計しやすくなる |
| Tenant groupsの意味変更に注意 | 以前のコンテンツ配布用途のtenant groupsは、現在はdistribution profilesと呼ばれる | 旧手順書や社内ドキュメントの用語を更新する必要がある |
| 権限記述の見直し | Tenant groupsの権限からGlobal Administratorが削除された履歴がある | 「グローバル管理者なら何でもよい」という運用を避け、最小権限に寄せる |
| 概要ページの機能一覧にTenant groupsが追加 | Multi-tenant management > Tenant groupsが機能一覧に加わった | 複数テナント表示の標準機能として設計対象に入れるべき |
特に注意したいのは、Tenant groupsという名前の意味です。現在のTenant groupsは、テナントを名前付きコレクションとしてまとめ、multitenant viewを切り替えるための機能です。一方、以前tenant groupsと呼ばれていたコンテンツ配布用途はdistribution profilesという名称に整理されています。社内手順書で「tenant groupにポリシーを配布する」と書いている場合、現在の公式用語とずれている可能性があります。(GitHub)
影響範囲：誰が確認すべきか
Microsoft Defender multitenant managementの影響を受けやすいのは、単一企業の単一テナントだけで完結していない組織です。特に、次のような運用では確認優先度が高くなります。
| 対象 | 影響する理由 | まず確認すること |
|---|---|---|
| MSSP・運用代行事業者 | 複数顧客のインシデント、アラート、ハンティングを1画面で扱うため | 顧客ごとの権限、GDAP、B2B、テナントグループ設計 |
| グループ会社を持つ企業SOC | 子会社・地域会社ごとにテナントが分かれることがあるため | 事業会社別のTenant groups、閲覧権限、インシデント対応フロー |
| Microsoft Sentinel利用組織 | Microsoft Sentinelワークスペースの接続状態により、見えるSIEMデータが変わるため | Primary workspace、secondary workspace、Azure Lighthouseの要否 |
| Defender for Endpoint管理者 | デバイス、リスク、露出状態を複数テナントで集約確認できるため | オンボード状態、センサー健全性、リスク・露出の集計 |
| セキュリティ開発・検知ルール担当 | Advanced HuntingやCustom detection rulesの横断運用に影響するため | KQL、TenantId列、workspace()、重複結果、クエリ上限 |
Microsoft Sentinelを含める場合は、単にDefender側のテナントを追加するだけでは不十分です。公式情報では、各テナントのMicrosoft Sentinelワークスペースは、単一テナント構成の場合と同様に個別にDefenderポータルへオンボードする必要があると説明されています。(Microsoft Learn)
管理者が確認すべき設定
テナントアクセスはB2B、GDAP、Azure Lighthouseを分けて考える
Microsoft Defender multitenant managementでは、アクセス方式を混同しないことが重要です。Defenderデータの表示・管理にはGDAPまたはMicrosoft Entra B2B認証が使われます。一方、Microsoft SentinelデータへのアクセスではGDAPがサポートされていないため、Sentinelを含む構成ではMicrosoft Entra B2BやAzure Lighthouseの設計が重要になります。(Microsoft Learn)
| 確認項目 | Defender XDR中心の運用 | Microsoft Sentinelを含む運用 |
|---|---|---|
| テナントアクセス | GDAPまたはMicrosoft Entra B2B | Microsoft Entra B2Bを前提に確認 |
| クロステナントのSentinelクエリ | 該当しない場合あり | Azure Lighthouseが必要になるケースがある |
| 権限確認 | 各テナントのロール・RBACを確認 | ワークスペース単位の権限も確認 |
| よくある失敗 | GDAPがあればすべて見えると思い込む | Sentinelデータが表示されず、権限不足か接続漏れか切り分けに時間がかかる |
管理者は、まず「Microsoft Defenderのデータを見る権限」と「Microsoft Sentinelのワークスペースにクエリを実行する権限」を別物として棚卸ししてください。ここを分けずに設計すると、Defenderのインシデントは見えるのにSentinel由来のデータだけ欠ける、というトラブルが起きやすくなります。
Tenant groupsは運用単位に合わせて設計する
Tenant groupsは、管理対象テナントを名前付きのまとまりにして、multitenant viewを切り替えるための機能です。顧客、事業部、地域など、実際のSOC対応単位に合わせて作ると効果が出ます。Tenant groupsを作成するには、対象テナントが先にMicrosoft Defender multitenant portalへオンボードされている必要があり、オンボード済みのテナントだけが作成・編集時に表示されます。(GitHub)
おすすめの分け方は、組織構造ではなく対応責任の境界を基準にすることです。たとえば、同じグループ会社でもSOC担当チームが違うならTenant groupsを分けた方が安全です。逆に、同じ顧客で本番・開発・海外拠点にテナントが分かれていても、同じインシデント対応チームが見るなら同じTenant groupにまとめる判断もあります。
| 分け方 | 向いているケース | 注意点 |
|---|---|---|
| 顧客別 | MSSPが複数顧客を管理する | 顧客間の誤閲覧を避けるため、命名規則を厳密にする |
| 事業部別 | 大企業で事業部ごとにSOC担当が違う | 兼務者の権限が広がりすぎないようにする |
| 地域別 | 日本、APAC、EMEAなど地域SOCがある | タイムゾーンや通知ルールと合わせて設計する |
| 重要度別 | 高リスク顧客、重要子会社を優先監視する | 通常監視対象が置き去りにならないよう定期レビューする |
なお、ユーザーはTenant groupに含まれるすべてのテナントを自動的に見られるわけではありません。B2BまたはGDAPで許可されたテナントだけが表示対象になります。Tenant groupは権限を広げる機能ではなく、あくまで表示対象を整理する機能として理解する必要があります。(GitHub)
ロールとURBACは最小権限で見直す
Tenant groupsへのアクセスには、Microsoft Entra IDロール、製品別RBAC、Unified role-based access control（URBAC）などの権限が関係します。公式情報では、Microsoft Entra IDロールとしてSecurity Administrator、Security Operator、製品別RBACではSecurity Administratorや製品横断の可視性を付与するカスタムRBAC、URBACでは閲覧にSecurity / read、作成にSecurity / manageが示されています。(GitHub)
運用上のポイントは、Global Administratorを安易に使わないことです。GitHub履歴では、Tenant groupsの権限説明からGlobal Administratorを削除する更新が確認できます。これは「グローバル管理者で代用する」のではなく、セキュリティ運用に必要な権限を役割ごとに付与する方向で見直すべきサインと考えるのが安全です。(GitHub)
Microsoft Sentinel連携で注意すべきワークスペース設計
Microsoft Defenderポータルでは、各テナントに対してMicrosoft Sentinelのprimary workspaceを1つ、secondary workspaceを複数接続できます。ここでいうworkspaceは、Microsoft Sentinelが有効化されたLog Analytics workspaceです。(Microsoft Learn)
注意すべきなのは、Advanced Huntingで複数テナントや複数ワークスペースを扱うときの条件です。公式情報では、複数テナントとそのprimary workspaceへのAdvanced HuntingクエリはAzure Lighthouseなしで扱える一方、別テナントのsecondary workspaceをAdvanced Hunting、分析ルール、Workbookなどからクエリする場合はAzure Lighthouseが必要とされています。その場合はworkspace()演算子を使います。(Microsoft Learn)
| やりたいこと | Azure Lighthouseの要否 | 注意点 |
|---|---|---|
| 複数テナントのprimary workspaceをAdvanced Huntingで見る | 不要と説明されている | 各テナント・各ワークスペースのオンボードと権限は必要 |
| 同一テナント内の複数ワークスペースをクエリする | 構成次第 | workspace()で対象ワークスペースを明示する |
| 別テナントのsecondary workspaceをクエリする | 必要 | Azure Lighthouseとワークスペース権限を先に設計する |
| 分析ルールやWorkbookから別テナントのsecondary workspaceを見る | 必要 | Defenderポータル側だけでなくSentinel側の運用設計も確認する |
実務では、Microsoft Sentinelのワークスペース名、ワークスペースID、テナントID、用途を一覧化しておくとトラブル対応が速くなります。特に買収・統合・海外拠点追加でテナントが増えた組織では、「どのワークスペースがprimaryなのか」「secondaryは誰が管理しているのか」が曖昧になりやすいです。
Advanced Huntingと検知ルールで確認すべきポイント
Microsoft Defender multitenant managementのAdvanced Huntingでは、複数テナント・複数ワークスペースにまたがって、メール、データ、デバイス、アカウントの侵害兆候を検索できます。Microsoft SentinelワークスペースがDefenderポータルへオンボードされている場合、SIEMデータとXDRデータをまとめて検索できます。(Microsoft Learn)
ただし、クエリ結果には上限があります。multitenant環境のAdvanced Huntingクエリは合計で最大50,000レコードまでで、個別テナントごとの上限は50,000をクエリ対象テナント数で割った数になります。たとえば10テナントを対象にすると、単純計算では1テナントあたり5,000件が上限の目安になります。(Microsoft Learn)
KQLで起きやすい失敗
複数テナントを対象にすると、単一テナントでは問題なかったKQLでも、結果の読み取りや重複、スキーマ差異でつまずくことがあります。
| 失敗しやすいポイント | 何が起きるか | 対応策 |
|---|---|---|
TenantIdをそのまま信じる | 複数ワークスペース時にWorkspace IDとして表示される場合がある | 必要に応じて列名をWorkspaceIdなどに整理する |
take 10を全体10件と誤解する | 複数テナント選択時はテナントごとに実行され、合算表示される | 検証時は対象テナント数を明記して結果件数を見る |
| 同名テーブルのスキーマ差異を見落とす | ワークスペースごとに列が違い、クエリが失敗することがある | workspace()で対象を明示し、必要な列だけprojectする |
adx()を横断テナントで安易に使う | テナントごとにADXクエリが実行・集約され、重複結果が出る可能性がある | ADXデータとの結合が必要な場合だけ使う |
公式情報でも、複数テナントでadx()演算子を使う場合、テナントごとにADXクエリが実行されて集約されるため、重複結果が返る可能性があると注意されています。また、同じ名前でスキーマが異なるテーブルを複数ワークスペースで扱う場合は、workspace()でテーブルを一意に指定することが推奨されています。(Microsoft Learn)
Custom detection rulesは一括運用前に権限と対象テナントを確認する
Microsoft Defender multitenant managementでは、複数テナントのCustom detection rulesを表示・管理できます。公式情報では、Custom detection rulesページでTenant name列を見てルールの出所を確認でき、フィルターで特定テナントに絞り込めるとされています。また、ルールのRun、Turn off、Deleteもmultitenant managementから実行できます。(Microsoft Learn)
ここでの注意点は、検知ルールの停止や削除が広範囲に影響することです。特にMSSPや複数子会社のSOCでは、似た名前のルールが複数テナントに存在します。ルール名だけで判断せず、Tenant name、対象テーブル、実行頻度、アラート生成先、対応アクションを確認してから操作してください。
インシデントとアラート運用の変更影響
Microsoft Defender multitenant managementでは、複数テナント・複数ワークスペースに由来するインシデントとアラートをIncidents & alertsで管理できます。インシデント詳細では、特定テナントのMicrosoft Defenderポータルを新しいタブで開いたり、インシデントの割り当て、タグ、ステータス、分類を管理したりできます。(Microsoft Learn)
ただし、一括操作には制限があります。公式情報では、複数インシデントの割り当ては現在同一テナントのインシデントに限られると説明されています。また、複数アラートの管理ではステータス、分類、コメントはテナント横断で追加できますが、アラートの割り当ては同一テナントのアラートに限られます。(Microsoft Learn)
運用フローでは、次のように切り分けると混乱を減らせます。
| 操作 | テナント横断で考えること | 同一テナントで処理すべきこと |
|---|---|---|
| インシデント確認 | 重大度、発生テナント、影響範囲の比較 | 担当者割り当て、分類、詳細対応 |
| アラート確認 | 類似アラートの横断確認、優先度判断 | 担当者割り当て、特定インシデントへの移動 |
| コメント | 横断的な調査メモの付与 | 顧客・部門固有の対応記録 |
| チューニング | 誤検知傾向の把握 | テナント固有のルール調整 |
特に「複数テナントに同じ攻撃が来ているか」を見る場面では、multitenant viewが有効です。一方で、最終的な封じ込め、担当割り当て、顧客報告はテナント単位で責任範囲が分かれることが多いため、横断ビューと個別テナントビューを使い分ける必要があります。
デバイスと脆弱性管理で確認すべき項目
デバイス管理では、テナントごとのデバイス数、デバイスタイプ、高価値デバイス、高露出デバイス、オンボード可能なデバイスなどを確認できます。Device inventoryではTenant name列が追加され、リスクレベル、重要度、OS、センサー状態、ウイルス対策状態、タグなどで検索・フィルターできます。(Microsoft Learn)
脆弱性管理では、Defender Vulnerability Management dashboardを使って、複数テナントにまたがる露出スコア、露出レベル、最も露出しているテナント、過去30日で露出が大きく増えたテナントなどを確認できます。テナント別には、露出デバイス、セキュリティ推奨事項、弱点、重大なCVEなどを確認できます。(Microsoft Learn)
実務では、次の順で見ると判断しやすくなります。
| 優先度 | 見るべき項目 | 判断基準 |
|---|---|---|
| 高 | Internet facingかつHigh exposureのデバイス | 外部公開され、露出度が高い端末は優先対応 |
| 高 | Critical CVEsが多いテナント | 全社共通のパッチ展開や例外申請を確認 |
| 中 | Sensor health stateが不良の端末 | 検知できない端末を放置しない |
| 中 | Newly discoveredやCan be onboarded | 未管理端末の増加を早めに検知 |
| 低 | OSバージョンやタグの不整合 | 長期的な資産管理品質の改善対象 |
複数テナント管理でありがちな失敗は、全体の露出スコアだけを見て安心することです。全体平均が低くても、特定テナントに重大CVEや外部公開端末が集中している場合があります。ダッシュボードでは、全体集計とテナント別の両方を確認してください。
導入・移行時の実務手順
Microsoft Defender multitenant managementを本番運用に入れるときは、いきなり全テナントを追加するより、代表テナントで権限・表示・クエリ・インシデント操作を検証してから広げる方が安全です。初回利用時は、Microsoft Defender multitenant managementにサインインし、Add tenantsから管理対象テナントを追加します。公式情報では、Microsoft Defender multitenant viewには現在100 target tenantsの制限があるとされています。(Microsoft Learn)
| 手順 | 作業内容 | 確認ポイント |
|---|---|---|
| 事前棚卸し | 管理対象テナント、Sentinelワークスペース、担当チームを一覧化 | テナントID、表示名、契約・顧客名、責任者をそろえる |
| 権限確認 | B2B、GDAP、RBAC、URBACを確認 | DefenderデータとSentinelデータの権限を分けて見る |
| 小規模検証 | 2〜3テナントで追加・表示・検索を試す | インシデント、アラート、Advanced Hunting、デバイスが想定通り見えるか |
| Tenant groups設計 | 顧客別・事業部別・地域別などで作成 | 表示対象が想定どおり絞られるか確認 |
| KQL検証 | よく使うハンティングクエリを横断実行 | 件数上限、TenantId、workspace()、スキーマ差異を確認 |
| 運用手順更新 | SOC手順書、エスカレーション、顧客報告手順を修正 | 旧tenant groups表記をdistribution profilesに置き換える |
| 本番展開 | 対象テナントを段階的に追加 | ステータスインジケーターでデータ・権限エラーを確認 |
設定ページでは、管理対象テナントの追加・削除や、個別テナントのDefenderポータルへの遷移ができます。また、multitenant managementのステータスインジケーターでは、データ読み込みや権限に関する問題がある場合に警告が表示され、影響するテナント情報を確認できます。(Microsoft Learn)
展開時に失敗しやすいポイント
旧用語のまま社内手順を残してしまう
今回の更新では、Tenant groupsという用語の意味が重要です。現在のTenant groupsはビュー切り替えのためのグループであり、以前のコンテンツ配布用途はdistribution profilesと呼ばれます。旧手順書を残したままだと、運用担当者が「表示グループ」と「配布プロファイル」を混同し、ポリシーやコンテンツ配布の確認漏れにつながります。(GitHub)
Sentinelのデータ欠落をDefender側だけで調べてしまう
Microsoft Sentinelのワークスペースは、各テナントで個別にDefenderポータルへオンボードする必要があります。加えて、SentinelデータへのアクセスではGDAPがサポートされていない点も見落としやすいポイントです。Defender側のテナント追加が完了していても、Sentinel側のB2B、ワークスペース権限、Azure Lighthouse、オンボード状態が不足していると、期待したSIEMデータが見えないことがあります。(Microsoft Learn)
100テナント制限を後から知る
公式情報では、Microsoft Defender multitenant viewには現在100 target tenantsの制限があります。MSSPや大規模グループ企業では、すべての顧客・子会社・検証環境を無計画に追加すると、運用設計を見直すことになります。展開前に、対象テナントを本番監視対象、検証対象、休眠対象に分け、優先度を決めてください。(Microsoft Learn)
横断ビューで見える範囲を「権限がある範囲」と誤解する
Tenant groupsに含まれていても、ユーザーがB2BまたはGDAPで許可されていないテナントは表示されません。逆に、必要以上に広い権限を付与すると、複数顧客や複数部門の情報を同じ担当者が見られる状態になります。Tenant groupsはアクセス制御の代替ではなく、表示対象を整理する補助機能です。(GitHub)
管理者・開発者向けチェックリスト
本番展開前に、最低限以下を確認してください。
| チェック項目 | 確認内容 | 完了基準 |
|---|---|---|
| 対象テナント | 管理対象テナントが一覧化されているか | テナントID、表示名、責任者、用途が分かる |
| アクセス方式 | B2B、GDAP、Azure Lighthouseの使い分けが整理されているか | DefenderデータとSentinelデータで権限設計が分かれている |
| RBAC・URBAC | Security Administrator、Security Operator、Security / read、Security / manageなどが適切か | Global Administrator依存を避け、最小権限で運用できる |
| Sentinelワークスペース | primary workspace、secondary workspace、オンボード状態を確認したか | 期待するSIEMデータがAdvanced Huntingで見える |
| Tenant groups | 顧客別・事業部別などの表示グループを設計したか | 選択したグループだけのデータが表示されることを確認済み |
| KQL | 主要なAdvanced Huntingクエリを横断実行したか | 件数上限、TenantId、workspace()、重複結果を確認済み |
| 検知ルール | Custom detection rulesの対象テナントを確認したか | 誤って別テナントのルールを停止・削除しない運用になっている |
| インシデント運用 | 一括操作と同一テナント制限を理解しているか | 割り当て、分類、コメント、顧客報告の手順が明確 |
| 旧手順書 | tenant groupsとdistribution profilesの用語を更新したか | 旧名称による混乱が起きない |
| テナント数 | 100 target tenantsの制限を踏まえているか | 追加対象の優先順位が決まっている |
まず取るべき対応
Microsoft Defender multitenant managementの2026年5月27日更新は、単なる画面追加として見るより、複数テナントSOC運用の整理ポイントが増えたと捉えるべきです。特にTenant groupsは、テナント横断の見え方を整えるうえで便利ですが、権限を広げる機能ではありません。Microsoft Sentinelを含める場合は、ワークスペースのオンボード、B2B、Azure Lighthouse、workspace()を含むKQL設計まで確認が必要です。
管理者はまず、管理対象テナントとSentinelワークスペースを一覧化し、Tenant groupsを実際の対応チーム単位で設計してください。そのうえで、代表テナントを使ってインシデント、アラート、Advanced Hunting、Custom detection rules、デバイス、脆弱性ダッシュボードを検証します。開発者や検知ルール担当者は、横断クエリでの件数上限、スキーマ差異、TenantIdの扱い、adx()利用時の重複可能性を確認しましょう。ここまで済ませてから段階展開すれば、複数テナントのMicrosoft Defender運用を安全に統合できます。
コメント