Microsoft Entraのクロステナント同期（Configure cross-tenant synchronization）は、複数のMicrosoft Entraテナント間でB2Bユーザーやセキュリティグループを自動作成・更新・削除するための設定です。結論から言うと、管理者が最初に確認すべきなのは、ターゲットテナント側の同期許可、両テナントの自動招待承諾、ソーステナント側の同期範囲、属性マッピング、小規模テストの5点です。
2026年5月末時点の公式情報では、同一クラウド内のクロステナント同期でB2Bユーザーに加えてセキュリティグループも対象にできる点が重要です。Microsoft Entraのリリース情報でも、Cross tenant group synchronizationは一般提供として案内されており、グループベースのアクセス制御を複数テナントへ展開しやすくなっています。(Microsoft Learn)
ただし、これは「テナント移行ツール」ではありません。同期されたユーザーは引き続きソーステナントで認証され、SharePointやOneDriveなどのデータ移行も行われません。まずは少人数または検証用グループで動作を確認し、ログと属性の反映結果を見てから本番展開するのが安全です。(Microsoft Learn)
Microsoft Entraのセキュリティ更新で管理者が確認すべき影響範囲
Microsoft Entraのクロステナント同期は、ソーステナントからターゲットテナントへIDを「プッシュ」する仕組みです。ターゲット側から取りに行く構成ではなく、同期対象ユーザー、同期対象グループ、属性マッピングは主にソーステナント側で管理します。(Microsoft Learn)
2026年5月末時点で特に確認すべき変更・影響は次の通りです。
| 確認項目 | 管理者への影響 | まず見るべき設定 |
|---|---|---|
| B2Bユーザーの自動プロビジョニング | 手動招待や個別削除の運用負荷を減らせる | ソース側の同期範囲、ターゲット側の同期許可 |
| セキュリティグループ同期 | 複数テナントでグループベースのアクセス制御をそろえやすくなる | ターゲット側の「Allow group synchronization」、ソース側のグループ属性マッピング |
| 自動招待承諾 | 初回アクセス時の招待メールや同意プロンプトを抑制できる | ソース側アウトバウンド、ターゲット側インバウンドのTrust settings |
| ライセンス要件 | ユーザー同期とグループ同期で必要なライセンスが異なる | ソーステナントのMicrosoft Entra ID P1/P2、Microsoft Entra ID Governance、Microsoft Entra Suite |
| 同期範囲の設計 | 誤って大量のユーザーやグループを同期すると、削除・属性更新の影響も広がる | 「Sync only assigned users and groups」から開始 |
セキュリティグループ同期は、既存のクロステナント同期構成にグループを含める形で有効化できます。公式情報では、共有アプリケーションアクセス、リソース認可、一貫したグループベースアクセス制御などが代表的な利用シーンとして示されています。(Microsoft Learn)
クロステナント同期で解決できること、できないこと
Microsoft Entra クロステナント同期が向いているのは、同一企業グループや同一組織内に複数テナントがあり、ユーザーやグループのライフサイクル管理を標準化したいケースです。
| 判断軸 | 向いているケース | 注意が必要なケース |
|---|---|---|
| 組織構造 | 持株会社、地域別テナント、事業会社別テナントを持つ組織 | 別会社・外部パートナーとの一時的な共同作業 |
| ID管理 | B2Bユーザーの作成、更新、削除を自動化したい | ソーステナントを廃止して完全移行したい |
| アクセス制御 | 複数テナントで同じセキュリティグループを使いたい | Microsoft 365グループや配布リストまで同期したい |
| ユーザー体験 | 招待メールや初回同意プロンプトを減らしたい | ユーザーごとに明示的な同意取得が必要な業務 |
| 開発・運用 | Microsoft GraphやPowerShellで設定の自動化も検討したい | 同期方向や属性の責任範囲を曖昧にしたまま展開したい |
公式ドキュメントでは、クロステナント同期は組織内のコラボレーション向けとして説明されています。組織外との利用では、プライバシー、同意、データ最小化、法務・コンプライアンス上の確認が必要になる可能性があります。(Microsoft Learn)
設定前に確認すべき前提条件
クロステナント同期の設定では、ソーステナントとターゲットテナントで必要な役割が異なります。作業者がGlobal Administratorである必要はありませんが、最小権限で進める場合は役割の分担を明確にしておく必要があります。
| 対象 | 必要な確認 | 実務上のポイント |
|---|---|---|
| ソーステナント | ユーザー同期はMicrosoft Entra ID P1/P2、グループ同期はMicrosoft Entra ID GovernanceまたはMicrosoft Entra Suite | グループ同期だけ別ライセンス要件になるため、検証前にライセンス割り当てを確認する |
| ソーステナントの権限 | Security Administrator、Hybrid Identity Administrator、Cloud Application AdministratorまたはApplication Administrator | 信頼設定、同期構成、ユーザー割り当てで必要な権限が分かれる |
| ターゲットテナントの権限 | Security Administrator | インバウンドのクロステナントアクセス設定を変更できることが必要 |
| 対象オブジェクト | ユーザー、セキュリティグループ | デバイス、連絡先、配布リストなどは同期対象として想定しない |
| 同期方向 | ソースからターゲットへの一方向 | 双方向にしたい場合は、方向ごとに別構成を設計する |
公式の構成ページでは、ソース側にMicrosoft Entra ID P1/P2またはMicrosoft Entra ID Governance / Microsoft Entra Suite、各管理ロールが必要であり、ターゲット側ではSecurity Administratorが必要とされています。(GitHub)
サポートされるクラウドとグループ同期の制約
同一クラウドのクロステナント同期では、Azure commercial同士、Azure Government同士、21Vianet同士の組み合わせが示されています。一方、クロスクラウド同期ではAzure commercialからAzure Government、Azure GovernmentからAzure commercial、Azure commercialからAzure operated by 21Vianetへの組み合わせが示されています。(Microsoft Learn)
ただし、セキュリティグループ同期には制約があります。クロスクラウド環境をまたぐグループ同期はサポート対象として扱わず、同一クラウド内での利用を前提に設計する必要があります。(Microsoft Learn)
| グループ関連の項目 | 対応状況 | 注意点 |
|---|---|---|
| ソース側の静的セキュリティグループ | 対応 | ターゲット側では静的セキュリティグループとして扱われる |
| ソース側の動的セキュリティグループ | 対応 | 動的ルール自体をターゲットへ複製する設計ではない |
| Microsoft 365グループ | 制限あり | ターゲット側にMicrosoft 365グループとして作成されるわけではない |
| メール有効セキュリティグループ | 非対応 | メール配送や配布用途の代替にはならない |
| 配布グループ、動的配布グループ | 非対応 | Exchange系の配布設計とは切り分ける |
| 入れ子グループ | 非対応 | 直接メンバーを同期対象に含める必要がある |
| ロール割り当て可能グループ | 非対応 | 管理者ロール付与の複製用途には使わない |
グループがターゲットテナントに既に存在していても、クロステナント同期の外で作成されたグループは自動更新の対象になりません。また、ターゲット側で加えた変更は、ソース側で変更が発生するまで自動的に上書きされない点にも注意が必要です。(Microsoft Learn)
Microsoft Entra admin centerでの設定手順
設定は大きく分けて、ターゲット側の受け入れ設定、両テナントの信頼設定、ソース側の同期構成、テスト、監視の順で進めます。
ターゲットテナントでユーザー同期とグループ同期を許可する
最初に、ターゲットテナントでソーステナントからの同期を許可します。ここを設定していないと、ソース側で構成を作っても接続テストやプロビジョニングで失敗します。
| 手順 | 操作 | 確認ポイント |
|---|---|---|
| 1 | Microsoft Entra admin centerでターゲットテナントにサインイン | 作業者がSecurity Administrator権限を持つことを確認 |
| 2 | Entra ID > External Identities > Cross-tenant access settingsを開く | 対象テナントを間違えない |
| 3 | Organization settingsでソーステナントを追加 | テナントIDまたはドメイン名を使う |
| 4 | Inbound accessのCross-tenant syncタブを開く | デフォルト継承のままにするか、組織別設定にするかを確認 |
| 5 | Allow user synchronization into this tenantを有効化 | ユーザー同期の必須設定 |
| 6 | 必要に応じてAllow group synchronization into this tenantを有効化 | グループ同期を使う場合のみ有効化 |
| 7 | 保存時に自動招待承諾の確認ダイアログが出たら内容を確認 | Yesを選ぶとターゲット側の自動招待承諾が有効化される |
公式手順では、ターゲットテナントのCross-tenant syncタブで「Allow user synchronization into this tenant」を選択し、同一クラウドのグループ同期では「Allow group synchronization into this tenant」も選択できます。(Microsoft Learn)
自動招待承諾をターゲット側とソース側の両方で有効化する
クロステナント同期では、自動招待承諾の設定が重要です。ターゲット側だけ、またはソース側だけで有効化しても、同意プロンプトの抑制としては不十分です。
| 設定場所 | 方向 | 設定内容 |
|---|---|---|
| ターゲットテナント | Inbound | Automatically redeem invitations with the tenantを有効化 |
| ソーステナント | Outbound | Automatically redeem invitations with the tenantを有効化 |
公式ドキュメントでは、自動招待承諾はソース側アウトバウンドとターゲット側インバウンドの両方で選択された場合に、ソーステナントのユーザーに対する同意プロンプトが抑制されると説明されています。(Microsoft Learn)
実務では、この設定を「ユーザー体験の改善」だけでなく「接続テスト成功の前提」として扱うべきです。後述するAzureActiveDirectoryCrossTenantSyncPolicyCheckFailureは、この設定漏れが原因になる代表的なエラーです。
ソーステナントで同期構成を作成する
ターゲット側の準備が終わったら、ソーステナントで同期構成を作成します。
| 手順 | 操作 | 確認ポイント |
|---|---|---|
| 1 | ソーステナントでEntra ID > External Identities > Cross-tenant synchronizationを開く | Azure portalを使う場合はMicrosoft Entra ID > Manage > Cross-tenant synchronization |
| 2 | ConfigurationsからNew configurationを選択 | 構成名は「同期元-同期先-用途」が分かる名前にする |
| 3 | 構成を作成 | 作成直後は一覧に表示されるまで時間がかかる場合がある |
| 4 | Provisioning ModeをAutomaticに設定 | 手動同期ではなくプロビジョニングサービスで継続同期する |
| 5 | Authentication MethodにCross Tenant Synchronization Policyを選択 | 通常の管理者資格情報ではなくポリシーベースの接続として扱う |
| 6 | ターゲットテナントIDを入力し、Test Connectionを実行 | 成功メッセージが出るまで次に進まない |
公式手順では、ソーステナントで構成を作成し、Provisioning ModeをAutomatic、Authentication MethodをCross Tenant Synchronization Policyにしたうえで、ターゲットテナントIDを入力してTest Connectionを実行します。(Microsoft Learn)
同期範囲は「割り当て済みユーザーとグループ」から始める
本番展開で最も事故につながりやすいのが同期範囲です。最初から全ユーザーを同期すると、想定外のB2Bユーザー作成、属性更新、削除処理が広範囲に及ぶ可能性があります。
推奨は、まずSync only assigned users and groupsを選び、1〜2名の検証ユーザーまたは小さな検証用グループだけを割り当てる方法です。公式ドキュメントでも、最初は小さなユーザーセットでテストすること、またパフォーマンス面からもSync all usersではなくSync only assigned users and groupsが推奨されています。グループ同期を使う場合、このスコープ設定が必要です。(GitHub)
| スコープ設定 | 向いている状況 | 注意点 |
|---|---|---|
| Sync only assigned users and groups | 検証、本番初期展開、グループ同期 | 運用対象の追加漏れに注意 |
| Sync all users | 小規模かつ全ユーザー同期が明確なテナント | グループ同期では使えない |
| 属性ベースのscoping filter | 部署、会社コード、雇用区分などで絞りたい場合 | 保存時に再同期が発生し、規模によって時間がかかる |
グループを割り当てた場合、同期対象になるのはそのグループの直接メンバーです。入れ子グループのメンバーにはカスケードしないため、大規模組織では「直接メンバー化するグループ」と「業務上の入れ子グループ」を分けて設計すると安全です。(GitHub)
属性マッピングは変更前に必ずレビューする
属性マッピングは、どの属性をソーステナントからターゲットテナントへ流すかを決める重要な設定です。ここを軽く扱うと、表示名、ユーザー種別、検索表示、アプリ側の認可条件に影響します。
特に重要なのがalternativeSecurityIdentifierです。これはソーステナントの内部ユーザーとターゲットテナントの既存B2Bユーザーを一致させるための内部属性で、マッチング属性として使われます。公式情報では、このマッチング属性は変更できず、変更や追加のマッチング属性設定を試みるとschemaInvalidエラーになると説明されています。(GitHub)
| 属性・設定 | 確認すべき内容 | 失敗しやすいポイント |
|---|---|---|
| alternativeSecurityIdentifier | 既存B2Bユーザーとの照合に使われる | 変更しようとしない |
| userType | MemberまたはGuestとして作成するか | 既存B2BユーザーのuserTypeは設定次第で期待通り変わらない場合がある |
| displayName | 表示名の形式 | 姓名順、ドメイン名付与などを式で変換する場合は小規模検証が必須 |
| showInAddressList | Microsoft 365のユーザー検索に出すか | People searchを使う場合に確認 |
| directory extensions | 拡張属性を同期するか | スキーマ更新の影響範囲を事前確認する |
| group mappings | グループ同期を有効化するか | 既定ではグループのEnabledがNoになっているため見落としやすい |
デフォルトでは、ユーザーは外部メンバー、つまりB2B collaboration usersとしてターゲットテナントに作成されます。userTypeをMemberにするかGuestにするかは、Teams、Power BI、Azure Virtual Desktopなどの利用シーンにも影響するため、単に「権限が強そうだからMember」と決めるのではなく、利用するワークロードごとに確認する必要があります。(GitHub)
グループ同期を使う場合はソース側のマッピングも有効化する
ターゲット側でAllow group synchronizationを有効化しただけでは、グループ同期は完了しません。ソーステナント側のProvisioning > MappingsでProvision Microsoft Entra ID Groupsを開き、EnabledをYesにする必要があります。公式手順では、このトグルは既定でNoとされています。(GitHub)
管理画面で「ユーザーは同期されるがグループだけスキップされる」という場合は、ターゲット側の同期許可だけでなく、ソース側のグループマッピングが有効かを確認してください。
テストと本番展開の進め方
いきなりStart provisioningを押すのではなく、Provision on demandでテストユーザーを1名選び、ターゲットテナントで実際に作成・更新された属性を確認します。公式手順でも、構成後にProvision on demandでテストユーザーをプロビジョニングし、ターゲットテナントで結果を確認してから追加ユーザーを割り当てる流れが示されています。(GitHub)
| フェーズ | 実施内容 | 合格条件 |
|---|---|---|
| 接続テスト | Test Connectionを実行 | 認可成功メッセージが表示される |
| 1ユーザーテスト | Provision on demandで検証ユーザーを同期 | ターゲット側にB2Bユーザーが作成され、主要属性が期待通り |
| グループテスト | 検証用セキュリティグループを同期 | グループと直接メンバーが意図通り同期される |
| アプリ確認 | 対象アプリへアクセス | Conditional Access、アプリロール、グループ認可が期待通り |
| 削除確認 | 検証ユーザーをスコープ外にする | ターゲット側の削除・無効化挙動を把握できる |
| 本番展開 | 部署・会社・用途ごとに段階展開 | エラー率、処理時間、問い合わせ件数が許容範囲 |
Start provisioningを実行すると、初回同期サイクルが始まります。初回サイクルは後続サイクルより長くかかり、その後のサイクルはMicrosoft Entra provisioning serviceが動作している限り、おおむね40分間隔で実行されます。(Microsoft Learn)
監視で見るべきログと通知設定
クロステナント同期は、設定して終わりではありません。同期の失敗や属性不一致は、アプリ利用時のアクセス拒否やユーザー検索の不整合として表面化します。
| 監視項目 | 確認場所 | 見るべき内容 |
|---|---|---|
| プロビジョニング進行状況 | ソーステナントのOverview | 同期サイクルの進捗、停止、検疫状態 |
| Provisioning logs | ソーステナント | 成功、失敗、スキップ、属性変更内容 |
| Audit logs | ソーステナント | 構成変更、管理操作 |
| Users > Audit logs | ターゲットテナント | Microsoft.Azure.SyncFabricによるユーザー管理イベント |
| 失敗通知 | Provisioning settings | エラー通知先、検疫状態への移行 |
公式手順では、ソース側で進行状況、Provisioning logs、Audit logsを確認でき、ターゲット側のユーザー監査ログではクロステナント同期のアクターがMicrosoft.Azure.SyncFabricとして記録されます。(GitHub)
追加設定として、失敗時のメール通知と誤削除防止も確認しておきましょう。誤削除防止のしきい値は既定で500とされており、大量削除を伴う変更の安全弁として機能します。(GitHub)
管理者と開発者が押さえるべき設計上の注意点
クロステナント同期は移行ではなくライフサイクル管理
クロステナント同期は、別テナントにユーザーを複製して完全移行する仕組みではありません。同期されたユーザーはソーステナントで認証され、同期先にはB2B collaboration userとして作成されます。テナント統合や分割でSharePoint、OneDrive、Teamsデータまで移す場合は、別の移行計画が必要です。(Microsoft Learn)
ソーステナントが属性の正と考える
ユーザーやグループの属性は、基本的にソース側を正として扱います。ターゲット側で手動変更した属性は一時的に残る場合がありますが、ソース側で対象属性に変更が入ると、次の同期サイクルでソース側の値に合わせて更新される可能性があります。ターゲット側で独自運用したい属性と、ソースから同期する属性を混在させる場合は、属性マッピングの整理が欠かせません。(Microsoft Learn)
既存B2Bユーザーがいる場合は事前棚卸しが必要
すでに手動招待済みのB2Bユーザーがいるテナントでは、クロステナント同期の導入前に状態を確認してください。特に、手動招待されたユーザーがPending acceptanceのまま残っていると、UPN更新が期待通り行われない場合があります。公式トラブルシューティングでは、対象ユーザーに対してオンデマンドプロビジョニングを実行する、または全体のプロビジョニング再開で更新する方法が案内されています。(GitHub)
Microsoft Graphで自動化する場合はポリシーの種類を分けて考える
開発者や運用自動化担当者は、UIで設定している内容を「1つの設定」として扱わないことが重要です。
クロステナント同期の許可設定は、ターゲットテナント側のインバウンド同期設定です。一方、自動招待承諾は、クロステナントアクセスの信頼設定です。公式ドキュメントでは、同期許可の構成にはUpdate crossTenantIdentitySyncPolicyPartner API、自動招待承諾の構成にはUpdate crossTenantAccessPolicyConfigurationPartner APIが関連情報として案内されています。(Microsoft Learn)
自動化スクリプトでよくある失敗は、同期許可だけを有効化して、Trust settingsの自動招待承諾を片側だけにすることです。接続テスト前に、ソース側アウトバウンドとターゲット側インバウンドの両方を確認するチェックを入れておくと、運用ミスを減らせます。
よくあるエラーと対処法
| 症状 | 主な原因 | 対処 |
|---|---|---|
Test ConnectionでAzureActiveDirectoryCrossTenantSyncPolicyCheckFailure | ソース側またはターゲット側の自動招待承諾が未設定 | ターゲット側Inbound、ソース側OutboundのAutomatically redeem invitationsを確認 |
| Automatic redemptionのチェックボックスが無効 | Microsoft Entra ID P1/P2ライセンスが不足 | 必要ライセンスを確認してから再設定 |
| ユーザーがスキップされる | SMS sign-inが有効なユーザーが含まれる場合がある | 対象ユーザーのSMS sign-in状態を確認 |
グループがEntityTypeNotSupportedでスキップ | ソース側のグループ同期マッピングが無効 | Provision Microsoft Entra ID GroupsのEnabledをYesにする |
AzureActiveDirectoryForbiddenでユーザーを作成できない | ターゲット側のGuest invite settingsが最も制限的 | 外部コラボレーション設定を見直す |
| 削除済みユーザーが次回同期で復元されない | ターゲット側でsoft deleteされた同期ユーザーの自動復元がサポートされないケース | ターゲットテナントで手動復元を検討 |
| 既存B2BユーザーのUPNが更新されない | 手動招待済みでPending acceptanceのユーザーが同期対象に入った | オンデマンドプロビジョニングまたは再同期を検討 |
これらのエラーは、公式トラブルシューティングでも代表例として整理されています。特に接続テスト失敗は、資格情報の誤りではなく、クロステナントアクセス設定や自動招待承諾の不足が原因であることが多いため、エラーメッセージをそのまま「管理者アカウントの問題」と判断しないことが重要です。(GitHub)
展開時の実務チェックリスト
本番展開前には、次の順序で確認すると失敗を減らせます。
| 項目 | 確認内容 |
|---|---|
| テナント設計 | どのテナントをソース、どのテナントをターゲットにするか決めたか |
| 同期方向 | 片方向で足りるか、双方向が必要かを整理したか |
| 対象範囲 | 最初は検証ユーザーまたは検証グループだけにしたか |
| ライセンス | ユーザー同期とグループ同期の要件を分けて確認したか |
| 管理ロール | ソース側とターゲット側で必要な管理者がそろっているか |
| 自動招待承諾 | ソース側Outbound、ターゲット側Inboundの両方で有効か |
| 属性マッピング | alternativeSecurityIdentifierを変更していないか |
| userType | MemberまたはGuestのどちらで作成するか決めたか |
| グループ制約 | 入れ子グループ、Microsoft 365グループ、配布グループを前提にしていないか |
| テスト | Provision on demandでユーザーとグループを検証したか |
| 監視 | Provisioning logs、Audit logs、通知先を確認したか |
| 削除時の挙動 | スコープ外になったユーザーの扱いを関係者に説明したか |
最後に行うべきことは、同期構成を作ることではなく、同期対象の棚卸し表を作ることです。ユーザー、グループ、属性、アプリ権限、削除時の扱いを一覧化してから、Microsoft Entra admin centerで小さく設定します。
Microsoft Entraのクロステナント同期は、うまく使えばB2B招待、グループ管理、退職・異動時の削除対応を大きく効率化できます。一方で、同期範囲と属性マッピングを誤ると、複数テナントに影響が広がります。まずは検証用ユーザーと検証用セキュリティグループで接続テスト、オンデマンドプロビジョニング、ログ確認まで完了させ、その結果をもとに段階的に展開するのが最も安全です。
コメント