Microsoft Entra の Cross-tenant security group synchronization は、複数の Microsoft Entra テナント間でセキュリティグループを同期し、共有アプリやリソースへのアクセスをソーステナント側で一元管理しやすくする機能です。結論から言うと、複数テナントを運用している管理者は、対象グループの棚卸し、ターゲットテナント側のクロステナントアクセス設定、属性マッピング、ライセンス、未対応のグループ種別を先に確認すべきです。
特に重要なのは、この機能が「すべてのグループを自動で安全に複製してくれる機能」ではない点です。Microsoft 公式のリリース情報では、Cross tenant group synchronization は 2026 年 5 月に一般提供として案内され、ソーステナントのグループメンバーシップを一元管理しつつ、1 つ以上のターゲットテナントで利用できるようにする機能と説明されています。管理者はオプトインし、属性マッピングとクロステナントアクセスポリシーを構成する必要があります。(Microsoft Learn)
Microsoft EntraのCross-tenant security group synchronizationとは
Cross-tenant security group synchronization は、Microsoft Entra のテナント間同期機能を拡張し、ユーザーだけでなくセキュリティグループもターゲットテナントに同期できるようにする仕組みです。
Microsoft Entra のテナント間同期は、組織内の複数テナント間で B2B コラボレーションユーザーとグループの作成、更新、削除を自動化する機能です。これにより、ユーザーは Teams、SharePoint、SaaS アプリなど、アプリがどのテナントに統合されているかに関係なくアクセスしやすくなります。(Microsoft Learn)
今回のポイントは、アクセス制御の単位として使われることが多い「セキュリティグループ」を、テナントごとに手作業で作り直す必要性を減らせることです。
たとえば、次のような環境で効果があります。
| 利用シーン | これまで起きやすかった課題 | 導入後に期待できること |
|---|---|---|
| 親会社・子会社で別テナントを運用 | 各テナントで同じ用途のグループを手動作成していた | ソーステナントのグループを基準にアクセス制御をそろえやすい |
| 部門別・地域別に複数テナントがある | メンバー追加・削除の反映漏れが起きやすい | メンバーシップ管理を一元化しやすい |
| 共有アプリを別テナントで運用 | アプリ割り当て用グループを重複管理していた | ターゲットテナント側で同期グループを権限付与に使いやすい |
| M&A・組織再編後の暫定運用 | すぐにテナント統合できず、権限管理が複雑化する | 完全移行前の共同利用環境を整理しやすい |
ただし、テナント移行そのものを行う機能ではありません。Microsoft のドキュメントでも、テナント間同期は移行ツールではなく、同期されたユーザーの認証にはソーステナントが必要だと説明されています。(Microsoft Learn)
今回の変更点：グループベースのアクセス管理を複数テナントへ広げやすくなる
大きな変更点は、既存のクロステナント同期構成にグループ同期を含められるようになったことです。Microsoft のリリース情報では、共有アプリケーションアクセス、リソース承認、テナント間で一貫したグループベースのアクセス制御といったシナリオをサポートすると説明されています。(Microsoft Learn)
実務上の意味は、次の3つです。
アクセス権の起点をソーステナントに寄せられる
複数テナントで同じ利用者グループを管理している場合、最も危険なのは「片方のテナントでは退職者が削除されたが、別テナントのグループには残っている」という状態です。
Cross-tenant security group synchronization を使うと、ソーステナントのグループメンバーシップを基準にしやすくなります。人事異動、退職、プロジェクト離任などの変更があったとき、各テナントで同じ作業を繰り返す運用よりも、反映漏れのリスクを減らせます。
共有リソースの権限設計がシンプルになる
複数テナント環境では、SharePoint サイト、業務アプリ、Azure リソース、SaaS アプリなどが特定テナントに集約されることがあります。この場合、利用者は別テナントに所属しているのに、リソースはターゲットテナントにあるという構成になります。
グループ同期を使えば、ターゲットテナント側で作成された同期済みセキュリティグループを、アプリ割り当てやリソース承認の単位として使いやすくなります。
手作業やスクリプト依存を減らせる
これまでは、Microsoft Graph や PowerShell で独自にグループ同期スクリプトを組む、CSV でメンバーを突き合わせる、各テナントの管理者が個別に更新する、といった運用になりがちでした。
標準機能として同期できるようになることで、運用設計を Microsoft Entra のプロビジョニング機能に寄せられます。ただし、完全に「放置できる」わけではありません。同期対象、属性マッピング、監査、失敗時の対応手順は引き続き設計が必要です。
影響を受ける管理者・開発者・利用部門
この更新の影響を受けるのは、単に Microsoft Entra 管理者だけではありません。アクセス権の設計やアプリ認可にグループを使っているチームも確認が必要です。
| 対象者 | 確認すべきこと |
|---|---|
| Microsoft Entra 管理者 | クロステナントアクセス設定、同期構成、対象グループ、ロール、ライセンス |
| セキュリティ担当 | グループ所有者、アクセスレビュー、退職・異動時の削除フロー |
| アプリ管理者 | 同期グループをアプリ割り当てに使うか、既存グループと競合しないか |
| 開発者 | アプリ内の認可ロジック、グループID参照、トークン内グループクレーム |
| 情シス・運用担当 | 申請フロー、変更依頼、障害時の切り戻し、監査ログ確認 |
| 法務・コンプライアンス担当 | 組織外テナントとの同期可否、個人データの扱い、同意要件 |
Microsoft は、テナント間同期を組織間で使う場合は追加のコンプライアンス責任が生じる可能性があり、ユーザー同意、データ最小化、その他の保護策が必要かどうかを顧客側で評価すべきだと説明しています。特にグループ同期は、誰がどのテナントでどのリソースにアクセスできるかに直結するため、組織外との利用では法務・コンプライアンス確認を先に行うべきです。(Microsoft Learn)
管理者が最初に確認すべき設定
Cross-tenant security group synchronization を展開する前に、次の項目を確認します。
| 確認項目 | 主な確認先 | 判断基準 |
|---|---|---|
| ライセンス | ソーステナント | グループのテナント間同期には Microsoft Entra ID Governance または Microsoft Entra Suite が必要 |
| 管理者ロール | ソース・ターゲット両方 | ソース側は Security Administrator、Hybrid Identity Administrator、Cloud/Application Administrator などが関係する |
| クロステナントアクセス設定 | ターゲットテナント | 対象ソーステナントからの同期を許可する |
| グループ同期の許可 | ターゲットテナント | 「このテナントへのグループ同期を許可する」を有効にする |
| 自動引き換え | ソース・ターゲット両方 | 初回アクセス時の同意プロンプトを抑制するには両側設定を確認する |
| 同期スコープ | ソーステナント | 最初は「割り当てられたユーザーとグループのみ」で小さく始める |
| 属性マッピング | ソーステナント | ユーザー属性・グループ属性が想定どおりに流れるか確認する |
| 監視方法 | ソーステナント | プロビジョニングログ、エラー通知、運用担当者を決める |
Microsoft Learn の構成手順では、ターゲットテナント側でソーステナントを追加し、クロステナント同期タブから「このテナントへのユーザー同期を許可する」と、必要に応じて「このテナントへのグループ同期を許可する」を選択します。また、自動引き換えはソーステナントとターゲットテナントの両方で有効にする必要があります。(Microsoft Learn)
ライセンス面では、同じクラウド内のグループのテナント間同期には、ソーステナントで Microsoft Entra ID Governance または Microsoft Entra Suite ライセンスが必要です。ターゲットテナント側では、テナント間同期そのものにライセンスは不要とされていますが、ターゲット側で使う機能によって追加ライセンスが必要になる場合があります。(Microsoft Learn)
展開前に整理すべきグループ設計
グループ同期を有効にする前に、まず「どのグループを同期するべきか」を決めます。ここを曖昧にしたまま設定を進めると、不要なアクセス権が別テナントに広がるおそれがあります。
同期対象に向いているグループ
次のようなグループは、同期対象として検討しやすいです。
- 複数テナントの共有アプリで使う業務ロールグループ
- 子会社・関連会社向けの共通アクセスグループ
- プロジェクト単位で複数テナントのリソースにアクセスするグループ
- 退職・異動時に確実に削除したい重要リソース用グループ
- アクセスレビューや承認フローと連携させたいグループ
同期対象にする前に見直すべきグループ
次のようなグループは、すぐに同期対象へ入れず、整理してから進めるべきです。
- 所有者が不明な古いグループ
- 用途が分からない「test」「old」「temp」などのグループ
- 手動追加が多く、棚卸しされていないグループ
- 動的メンバーシップの条件が古いグループ
- 特権アクセスや管理者権限に近い権限を持つグループ
- メール配布や Microsoft 365 グループの用途と混在しているグループ
グループ同期は便利ですが、ソーステナントのグループ設計が乱れていると、その乱れもターゲットテナント側に持ち込まれます。導入作業の前に、最低限「所有者」「用途」「付与される権限」「削除条件」を一覧化しておくことが重要です。
対応グループと未対応グループの違い
Microsoft Learn では、テナント間同期でターゲットテナントにセキュリティグループを作成でき、グループが同期されると同期スコープ内のメンバーも同期されると説明されています。一方で、すべてのグループ種別がそのまま同期できるわけではありません。(Microsoft Learn)
| 項目 | 対応状況 | 注意点 |
|---|---|---|
| セキュリティグループ | 対応 | 静的・動的グループをソースにできる |
| Microsoft 365 グループ | ソースとして扱える場合があるが、ターゲットでは静的セキュリティグループ | Microsoft 365 グループとして作成されるわけではない |
| メールが有効なセキュリティグループ | 非対応 | メール用途とアクセス制御用途を分ける |
| 配布グループ・動的配布グループ | 非対応 | Exchange 配布用途の置き換えにはならない |
| ネストされたグループ | 非対応 | 直接メンバーを設計し直す必要がある |
| ロール割り当て可能なグループ | 現時点では作成非対応 | 特権管理用途のグループは慎重に扱う |
| クロスクラウド環境をまたぐグループ同期 | 非対応 | Azure 商用、Azure Government、中国クラウドをまたぐ設計では制限を確認する |
特に失敗しやすいのは、ネストされたグループです。構成にグループを割り当てた場合、プロビジョニング対象になるのはグループ内の直接メンバーであり、入れ子になったグループにはカスケードされません。(Microsoft Learn)
展開手順の実務イメージ
実際の展開では、いきなり本番グループを大量に同期するのではなく、段階的に進めます。
| フェーズ | 作業内容 | 失敗を防ぐポイント |
|---|---|---|
| 事前調査 | 同期したいグループ、利用アプリ、権限、所有者を一覧化 | グループ名だけで判断せず、実際の割り当て先を確認する |
| 設計 | ソース・ターゲット、同期方向、命名規則、運用責任者を決める | 双方向同期のつもりで設計しない |
| 設定 | ターゲットテナントでクロステナントアクセスとグループ同期を許可 | 対象組織を間違えないようテナントIDで確認する |
| 構成作成 | ソーステナントでクロステナント同期構成を作成 | 本番用と検証用の構成名を分ける |
| 接続テスト | ターゲットテナントへの接続をテスト | 失敗時は資格情報、ポリシー、ロールを確認する |
| パイロット | 少数のユーザー・グループだけを割り当てる | まず1〜2グループで動作確認する |
| 検証 | ターゲット側のグループ作成、メンバー、属性、アプリ割り当てを確認 | ターゲット側で手動修正しない |
| 本番展開 | 対象グループを段階的に追加 | 追加前後でアクセス権を記録する |
| 運用 | プロビジョニングログ、失敗通知、アクセスレビューを運用に組み込む | 同期エラーを放置しない |
Microsoft Learn でも、全員にロールアウトする前に少数のユーザーでテストすること、グループ同期では「割り当てられたユーザーとグループのみを同期する」を選ぶ必要があること、グループプロビジョニングのトグルは既定で「いいえ」であることが説明されています。(Microsoft Learn)
移行・切り替え時に注意すべきポイント
既にターゲットテナント側で手動作成したグループを使っている場合、単純に同期グループへ置き換えるだけでは済まないことがあります。特に、アプリ割り当て、SharePoint 権限、Azure RBAC、SaaS 側のグループ参照が絡む場合は、切り替え計画が必要です。
既存グループと同期グループの競合を確認する
ターゲットテナントに、テナント間同期の外部で作成されたグループが既に存在する場合、テナント間同期ではそのグループは更新されません。つまり、同じ用途・似た名前のグループが並び、管理者が誤って古いグループを使い続ける可能性があります。(Microsoft Learn)
対策として、次のような命名規則を決めておくと運用しやすくなります。
| 種別 | 命名例 | 目的 |
|---|---|---|
| ソース側の管理グループ | SRC-HR-App-Approvers | 管理元が分かる |
| ターゲット側の同期グループ | SYNC-HR-App-Approvers | 手動作成グループと区別する |
| 廃止予定グループ | OLD-HR-App-Approvers-DoNotUse | 移行中の誤使用を防ぐ |
ターゲットテナント側で手動変更しない
ターゲットテナント内の同期済みグループを手動変更すると、その変更がすぐにソース側で上書きされるとは限りません。Microsoft Learn では、ターゲットテナント内のグループ変更は自動的にはオーバーライドされず、ソーステナント内のグループに変更がある場合にのみ上書きされると説明されています。(Microsoft Learn)
これは運用上かなり重要です。ターゲット側で一時的にメンバーを追加したつもりが、その状態が想定より長く残る可能性があります。同期グループは「ターゲット側で編集しない」ルールを明文化し、必要な変更はソーステナント側で行うべきです。
同期解除時の挙動を事前に決める
ユーザーやグループを同期構成から外すと、後続の同期サイクルでプロビジョニング解除が発生します。Microsoft Learn では、すべてのユーザーとグループの割り当てを解除すると、割り当て解除されたユーザーが後続の同期サイクルでプロビジョニング解除され、完了までターゲットテナントの受信ポリシーを有効にしておく必要があると説明されています。(Microsoft Learn)
本番展開では、次のような切り戻し条件を決めておきます。
- 同期失敗が一定数を超えたら対象グループの追加を停止する
- 誤ったメンバー同期が発生したらソース側でメンバーを修正する
- ターゲット側のアプリ割り当てを旧グループへ戻す手順を用意する
- 同期構成を削除する前に、対象ユーザー・グループへの影響を確認する
開発者が確認すべきポイント
アプリケーション側で Microsoft Entra のグループを認可に使っている場合、開発者も確認が必要です。
グループIDをハードコードしていないか
ソーステナントのグループとターゲットテナントの同期済みグループは、実務上は別オブジェクトとして扱う前提で設計すべきです。アプリ内でソーステナントのグループIDを固定参照している場合、ターゲットテナント側の認可にそのまま使えない可能性があります。
確認すべき箇所は次のとおりです。
- アプリ設定ファイルにグループIDを直接書いていないか
- Microsoft Graph で特定テナントのグループIDを前提にしていないか
- トークン内の
groupsクレームだけで権限判定していないか - グループ数が多いユーザーでクレームの省略や overage が起きた場合の処理があるか
- ターゲットテナント側の Enterprise Application 割り当てを確認しているか
グループ同期の遅延を前提にする
テナント間同期はリアルタイム処理ではありません。Microsoft Learn では、同期間隔は現在 40 分間隔で開始するよう固定され、初期同期サイクルは後続の増分同期より大幅に長くなる可能性があると説明されています。(Microsoft Learn)
そのため、アプリ側で「グループに追加した直後に必ずアクセスできる」ことを前提にすると、問い合わせや障害扱いが増えます。アクセス申請フローやヘルプデスク向け手順には、「反映まで時間がかかる場合がある」ことを明記しておくと安全です。
権限判定のテストはターゲットテナントで行う
ソーステナントで正しくグループに所属していても、ターゲットテナント側で期待したグループとして認識され、アプリに割り当てられているとは限りません。
テストでは、次の順序で確認します。
- ソーステナントでユーザーが対象グループの直接メンバーになっている
- 同期構成のスコープにユーザーとグループが含まれている
- ターゲットテナントに同期済みグループが作成されている
- ターゲットテナントのグループに対象ユーザーが含まれている
- アプリまたはリソースが同期済みグループに割り当てられている
- 実際のサインイン・トークン・アプリ内権限が期待どおりになっている
セキュリティ運用で見落としやすい注意点
Cross-tenant security group synchronization は、管理効率を上げる一方で、ソーステナントのグループ管理ミスが複数テナントに波及しやすくなります。導入時は「同期できるか」だけでなく「同期してよいか」を判断してください。
| 注意点 | 起こり得る問題 | 対策 |
|---|---|---|
| グループ所有者が不明 | 誰がメンバー追加を承認するのか分からない | 所有者を最低2名設定し、定期レビューする |
| 動的グループ条件が古い | 想定外のユーザーが同期対象に入る | ルール条件と対象人数を確認する |
| 特権に近いグループを同期 | 複数テナントへ高権限が広がる | 管理者権限系は原則別設計にする |
| 退職者削除フローが弱い | ターゲットテナントにアクセスが残る | 人事・IDライフサイクル連携を確認する |
| 監査ログを見ていない | 同期失敗や過剰付与に気づけない | プロビジョニングログ確認を運用に入れる |
| ターゲット側で手動修正 | ソースとの整合性が崩れる | 同期グループの編集禁止ルールを作る |
実務では、グループ同期の導入と同時にアクセスレビューも見直すのがおすすめです。特に、複数テナントにまたがって共有リソースへアクセスするグループは、通常の部門グループよりリスクが高くなります。
よくある誤解
「Microsoft 365グループもそのまま同期される」は誤解
ソース側で Microsoft 365 グループを扱えるケースがあっても、ターゲット側に Microsoft 365 グループとして作成されるわけではありません。Microsoft Learn では、ターゲット側では静的セキュリティグループとして扱われ、Microsoft 365 グループ、配布グループ、メールが有効なセキュリティグループなどは作成されないと説明されています。(Microsoft Learn)
メール、予定表、Teams チーム、SharePoint サイトなどの Microsoft 365 グループ機能を複製する用途には向きません。
「ネストされたグループも全部展開される」は誤解
ネストされたグループはサポートされていません。グループを構成に割り当てても、直接メンバーのみが対象です。既存のオンプレミス AD や Entra ID で入れ子グループを多用している組織は、同期対象グループをフラットに再設計する必要があります。
「双方向同期として使える」は誤解
テナント間同期は、1つのソースと1つのターゲットの間で構成される単一方向の同期です。複数の同期インスタンスを作ることはできますが、1つのソース・ターゲット間に存在できる同期インスタンスは1つだけです。(Microsoft Learn)
双方向のように見せたい場合でも、ループや権限の競合を避けるため、どのテナントを正とするかを明確に決める必要があります。
「既存のB2Bユーザーが必ずmemberになる」は誤解
既存の B2B コラボレーションユーザーがいる場合、テナント間同期はユーザーを照合して必要な更新を行いますが、既定では userType は guest から member に更新されません。このプロパティは属性マッピングで構成できます。(Microsoft Learn)
アプリや Power BI、Teams などで userType を前提にした制御をしている場合は、事前に検証が必要です。
管理者向けチェックリスト
本番展開前に、最低限次の項目を確認してください。
- 同期対象グループの一覧、用途、所有者、付与先リソースを整理した
- ソーステナントとターゲットテナントの関係をテナントIDで確認した
- Microsoft Entra ID Governance または Microsoft Entra Suite のライセンス要件を確認した
- 必要な管理者ロールを持つ担当者を決めた
- ターゲットテナントでグループ同期を許可した
- ソース・ターゲット両方で自動引き換え設定を確認した
- 同期スコープを「割り当てられたユーザーとグループのみ」にした
- ネストされたグループを同期対象にしていない
- メールが有効なセキュリティグループや配布グループを対象外にした
- ターゲットテナント側で同期グループを手動編集しないルールを作った
- プロビジョニングログの確認担当と頻度を決めた
- 失敗時の切り戻し手順を用意した
まず何から対応すべきか
Cross-tenant security group synchronization は、複数テナント運用のグループ管理を大きく簡素化できる一方、設計を誤るとアクセス権の過剰付与や運用混乱につながります。
最初にやるべきことは、設定画面を開くことではなく、同期対象候補のグループを棚卸しすることです。次に、テスト用の小さなグループを1つ選び、ターゲットテナントのクロステナントアクセス設定、グループ同期許可、属性マッピング、アプリ割り当てまでを一連の流れで検証します。
特に重要なのは、次の3点です。
- ソーステナントを権限管理の正とする
- 同期対象は最小限から始める
- 未対応グループとネスト構造を事前に除外する
Microsoft 365 Roadmap は予定や内容が変更される可能性があるため、実際の展開時には自社テナントの Microsoft Entra 管理センター、Microsoft 365 管理センターの Message center、Microsoft Learn の最新情報を併せて確認してください。Microsoft 365 Roadmap 自体も、リリース予定日や説明は変更される可能性があると案内しています。(Microsoft)
コメント