複数の Microsoft Entra ID テナント（旧 Azure AD）を持つと、「どのテナントで認証し、どのテナントで権限を管理するか」が一気に難しくなります。本記事では、従業員テナントと外部委託テナントという 2 テナント構成を前提に、B2B コラボレーションとクロステナント同期を組み合わせて「認証＝ホームテナント」「認可＝従業員テナント」で一元管理する具体的な設計・実装手順を解説します。
シナリオの整理：従業員テナントと外部テナント
まずは前提条件を整理します。
- オンプレミス Active Directory（オンプレ AD）があり、
- Azure AD Connect（現 Microsoft Entra Connect）で
- 従業員用テナント（以下「従業員テナント」）
- 外部委託用テナント（以下「外部テナント」）
- 今後は
- 認証：できる限り一元化し、利用者のサインイン体験をシンプルにしたい
- 認可：グループベースで従業員テナント側に集約したい
ここに対して Microsoft が提供する 2 つの仕組みが次のものです。
- B2B コラボレーション：外部テナントのアカウントを「ゲスト／外部メンバー」として従業員テナントに招待する仕組み
- クロステナント同期（Cross-tenant synchronization）：B2B ユーザーの作成・更新・削除をテナント間で自動化するプロビジョニング機能
この記事では、
- ユーザーオブジェクトは 外部テナント→従業員テナント へクロステナント同期で流し込み、
- 従業員テナントでグループ・条件付きアクセス・監査などを集中管理する
という構成をゴールにします。
| 役割 | 外部テナント | 従業員テナント |
|---|---|---|
| ユーザーの「ホーム」 | 〇（認証を行う元テナント） | ×（B2B 表示のみ） |
| クロステナント同期のソース | 〇（source tenant） | × |
| クロステナント同期のターゲット | × | 〇（target tenant） |
| グループ／権限管理 | 必要最低限 | 集約・一元管理 |
| 利用アプリ（SharePoint/Teams 等） | 状況に応じて | メインの業務テナントとして利用 |
B2B コラボレーションとクロステナント同期の違い
B2B コラボレーションの役割
B2B コラボレーションは、外部組織のユーザーを「ゲスト（userType=Guest）または外部メンバー（userType=Member）」として自テナントに招待し、アプリやデータを共有するための基本機能です。外部ユーザーは 自分のホームテナントで認証し、その結果をもとにリソーステナント（従業員テナント）でトークンが発行される仕組みになっています。
クロステナント同期の役割
クロステナント同期は、B2B コラボレーションの上に乗る「自動プロビジョニング」です。具体的には、
- ソーステナントでスコープに含めた内部ユーザーを、
- ターゲットテナントに B2B ユーザー（external member / external guest）として自動作成・更新・削除する
という動きをします。
| 項目 | B2B コラボレーション | クロステナント同期 |
|---|---|---|
| 目的 | 外部ユーザーを招待してコラボレーション | テナント間の B2B ユーザーのライフサイクルを自動化 |
| 作成方法 | 招待メール／リンク、Entitlement Management など | プロビジョニング構成に基づく自動作成 |
| 同期対象 | ユーザー（招待された分） | ユーザーのみ（グループ・デバイス・連絡先は対象外） |
| 認証元 | 常にユーザーのホームテナント | ホームテナント（ソース側）が継続して認証 |
| 招待プロンプト | 既定では初回に consent / redemption が必要 | 自動リデンプション設定により抑制可能 |
| 同期頻度 | なし（イベントドリブン） | 約 40 分ごとのインクリメンタル同期（固定） |
重要なのは、クロステナント同期は「ユーザーを別テナントへ移住させる」ためのツールではなく、あくまで B2B ユーザー作成を自動化する仕組みだという点です。同期されたユーザーは、あくまでホームテナント側で認証されます。
全体設計：認証はホームテナント、認可は従業員テナント
以上を踏まえると、本シナリオでとれる現実的な設計は次のようになります。
- 認証：ユーザーのホームテナント（ここでは外部テナント）が継続して担当
- 認可（アクセス権）：従業員テナントに集約し、グループ・条件付きアクセス（CA）・監査を一元管理
- ユーザーオブジェクト：外部テナント → 従業員テナントにクロステナント同期で自動作成
- グループ：クロステナント同期では同期されないため、従業員テナントに「ミラー用グループ」を作る
この構成により、
- 外部テナントに新しいユーザーが追加されると自動的に従業員テナントに B2B ユーザーが作成され、
- 従業員テナント側のグループにそのユーザーを追加することで、各種アプリへのアクセス権が付与され、
- ユーザーが退職・契約終了すると、外部テナントから削除されたタイミングで B2B ユーザーも自動的にソフト削除される
というライフサイクルの自動化が実現できます。
構成手順：クロステナントアクセス設定と同期
従業員テナント：クロステナント「受け入れ」設定
まず、従業員テナント側で「このテナントは外部テナントからのユーザー同期を受け付けます」という明示的な許可を出します。
- 従業員テナントで Microsoft Entra 管理センター にサインイン。
- Entra ID > External Identities > Cross-tenant access settings を開きます。
- [Organization settings] タブで、[Add organization] をクリックし、外部テナントのドメイン名またはテナント ID を指定して追加。
- 追加した組織の [Inbound access] を開き、[Cross-tenant sync] タブで
- [Allow users sync into this tenant] にチェック（「このテナントへのユーザー同期を許可」）。
- 同じ組織の [Trust settings] タブで
- [Automatically redeem invitations with the tenant <tenant>] にチェックし、自動リデンプションを有効化。
- 必要に応じて同じ画面で
- MFA クレームを信頼
- 準拠デバイス／ハイブリッド参加デバイスのクレームを信頼
外部テナント：クロステナント「送信」設定
次に、外部テナント側でも従業員テナントを登録し、「この相手には自動リデンプションを許可する」という設定を行います。双方向で自動リデンプションを有効にしてこそ、初回サインイン時の同意プロンプトを抑制できます。
- 外部テナントで Microsoft Entra 管理センターにサインイン。
- Entra ID > External Identities > Cross-tenant access settings を開きます。
- [Organization settings] タブで従業員テナントを追加（ドメインまたはテナント ID）。
- 追加した組織の [Outbound access] を開き、[Trust settings] タブで
- [Automatically redeem invitations with the tenant <tenant>] にチェック。
外部テナント：クロステナント同期構成の作成
続いて、外部テナントで「どのユーザーを」「どの属性で」従業員テナントに同期するかを定義します。
- 外部テナントで Entra ID > External Identities > Cross-tenant synchronization を開きます。
- [Configurations] タブで [New configuration] をクリックし、わかりやすい名前（例：
To-EmployeesTenant）を付けて作成。 - 作成した構成を開き、[Provisioning] ページで
- Provisioning Mode = Automatic
- Authentication Method = Cross Tenant Synchronization Policy
- ターゲットのテナント ID を指定して [Test Connection] を実行し、成功することを確認します。
- Scope を設定。
- テスト中は [Sync only assigned users and groups] を推奨。
- まずは 1 つのグループ、数ユーザーだけをスコープに入れて動作確認します。
- [Users and groups] で同期対象ユーザー／グループを割り当て。
- [Mappings] で属性マッピングを確認。
- 最初の
alternativeSecurityIdentifierは、ソースとターゲットのユーザーを一意に結び付けるための内部属性であり、変更不可です。 - UserType（Member/Guest） の既定値を確認し、必要に応じて変更。
Member：外部メンバー（external member）として作成。多くのサービスで社内メンバーとほぼ同等の動き。Guest：ゲストユーザーとして作成。一部ワークロードで制約がある一方、外部であることを明確化。
- 最初の
- 必要に応じて表示名や UPN に対する変換ルール（Expression）を設定（例：表示名の末尾にソーステナント名を括弧書きするなど）。
- 最後に [Provisioning] ページで [Start provisioning] を実行し、プロビジョニングログで進捗を確認します。
- 初回フル同期は時間がかかりますが、その後は約 40 分ごとのインクリメンタル同期で変化分のみが処理されます。
グループによる認可：ミラー用グループのパターン
クロステナント同期はユーザーオブジェクトのみが対象であり、グループは同期されません。
そのため、従業員テナント側では「外部テナントでのグループ構成を反映したミラー用グループ」を用意し、そのグループに対してアプリやリソースのアクセス権を付与する運用が必要になります。
| パターン | 概要 | 特徴 |
|---|---|---|
| パターン A | 動的グループで同期ユーザーを自動収集 | 簡単・ノーコードだが、複雑な元グループ構成までは再現しにくい |
| パターン B | Graph API ＋スクリプトでミラーグループを定期更新 | 柔軟だがスクリプト管理が必要 |
| パターン C | Entitlement Management（アクセス パッケージ）で権限付与フローを一元化 | 申請＆承認フローを含む高度なガバナンスが可能 |
パターン A：動的グループで自動収集
一番手軽なのが、従業員テナント側に動的グループを作成し、同期された B2B ユーザーを自動的にメンバーにする方法です。
- 例 1：従業員テナント上の「すべての B2B ユーザー」グループ
- 動的ユーザーグループのメンバーシップルール：
user.userType -eq "Guest"または"Member"（外部メンバー型で作成した場合）
- 動的ユーザーグループのメンバーシップルール：
- 例 2：特定の外部テナント由来のユーザーだけを集めるグループ
- 同期時に extensionAttribute や companyName 等にテナント識別子をマッピングしておき、
- 動的ルールで
user.extensionAttributeX -eq "VendorA"のように指定
動的グループを利用するには、対象ユーザーに対して Entra ID P1 以上のライセンスが必要となる点に注意してください。
パターン B：Graph API ＆スクリプトでミラー更新
外部テナント側で既に細かくグループ設計がされている場合は、そのグループ構成を従業員テナント側に「ミラー」するのが現実的です。この場合、次のようなスクリプトパターンが考えられます。
- 外部テナントで Graph API（または PowerShell SDK）を使用し、対象グループごとにメンバー一覧を取得。
- 従業員テナントに、同名（あるいはプレフィックス付き）のセキュリティグループを作成（例：
XT-VendorA-ProjectX）。 - 外部テナントから取得したメンバーのうち、従業員テナントに同期済みの B2B ユーザーを突き合わせてミラーグループのメンバーを更新。
- 追加すべきユーザー：外部テナントのグループにいて、ミラーグループにいないユーザー
- 削除すべきユーザー：ミラーグループにいるが、外部テナント側グループにいないユーザー
- この処理を Azure Automation、GitHub Actions、オンプレジョブ等で定期実行。
こうすることで、「実際の人事／契約の所属管理は外部テナント」「アクセス権・監査は従業員テナント」という責務分担を崩さず、グループベースの認可を維持できます。
パターン C：Entitlement Management（アクセス パッケージ）
外部委託のオンボーディング／オフボーディングを厳格に運用したい場合は、従業員テナント側に Microsoft Entra Entitlement Management（アクセス パッケージ） を構成する選択肢があります。
- アクセス パッケージに
- Teams / SharePoint / アプリケーション
- ミラー用グループ
- 「申請 > 承認 > 自動割り当て > 有効期限切れ」のライフサイクルを構成
- 外部ユーザーは専用ポータルからアクセスを申請し、承認されると自動でミラーグループに加入
クロステナント同期で B2B ユーザーを自動作成しつつ、Entitlement Management で最終的な権限付与をコントロールすると、セキュリティと運用効率のバランスが取りやすくなります。
ライセンス・制約事項の整理
ライセンス要件
クロステナント同期には明確なライセンス要件があります。
| シナリオ | ソーステナント側 | ターゲットテナント側 |
|---|---|---|
| クロステナント同期（同一クラウド内） | 同期対象ユーザー 1 人ごとに Microsoft Entra ID P1 ライセンスが必要 | 同期自体にはライセンス不要（ただし、CA やその他機能を使う場合は別途ライセンスが必要） |
| クロスクラウド同期 | Microsoft Entra ID Governance または Entra Suite | 同上 |
ポイントは、ライセンスはあくまでホームテナント（ソース）側に必要であり、ターゲット（従業員テナント）側にはクロステナント同期そのもののためのライセンスは不要という点です。ただし、ターゲット側で動的グループや CA の細かなスコープ設定を行う場合は、そのテナント側にも P1 / P2 ライセンスが必要になるケースがあります。
同期対象と制約
- 同期対象オブジェクトはユーザーのみであり、グループ・デバイス・連絡先は対象外。
- ソーステナントでスコープに含めた「内部メンバー（userType=Member）」だけが同期対象。
- ソース側に既に存在するゲストは同期できない。
- 同期は 一方向 であり、1 組のソース／ターゲット間には同期インスタンスを 1 つしか持てない（一対一のペアリング）。
- 複数ソース→1 ターゲット、1 ソース→複数ターゲットといったトポロジは、インスタンスを複数作ることで実現可能。
ソース・オブ・オーソリティ
クロステナント同期では、属性の主導権（ソース・オブ・オーソリティ）は常にソーステナントにあります。
- ターゲット側（従業員テナント）で displayName や department を編集しても、ソース側で変更があれば次回同期で上書きされる。
- 逆方向に同期方向を切り替えることはできず、「認証連携の向き」を変える用途には使えない。
- 対象ユーザーがスコープから外れる、削除されるなどした場合、ターゲット側の B2B ユーザーはソフト削除される。
よくある誤解とハマりどころ
「認証の一元化＝従業員テナントに集約」はできない
よくある誤解が、「クロステナント同期でユーザーを従業員テナントに同期すれば、今後の認証はすべて従業員テナントで行える」という考え方です。しかし実際には、
- クロステナント同期で作成されたユーザーは、あくまで ホームテナントで認証した上で 従業員テナントのトークンが発行される
- ユーザーを完全に従業員テナントに「移住」させるには、別途テナントマイグレーション（メールボックスや OneDrive、SharePoint データを含む）が必要であり、クロステナント同期はその用途を想定していない
したがって、「認証の一元化」という言葉は、
- 実際のパスワード認証の場所を 1 つにすることではなく
- どのポリシー（CA）で、どのテナントのリソースへアクセスを許可するかを一元的に制御する
という意味で捉えるのが現実的です。
既存 B2B ユーザーとの重複
すでに従業員テナントに手動招待した B2B ユーザーがいる場合、「クロステナント同期で同じユーザーが二重に作成されないか？」という懸念が出がちです。
これについては、クロステナント同期が内部的に alternativeSecurityIdentifier という属性でユーザーを突き合わせ、既存 B2B ユーザーを更新する仕組みが提供されているため、通常は重複を心配する必要はありません。
条件付きアクセスと外部 MFA / デバイス信頼
条件付きアクセス（CA）設計では、次の点に注意します。
- 従業員テナント側で「外部テナントの MFA クレーム／デバイスクレームを信頼」することで、二重の MFA 要求や重複したデバイス準拠チェックを避けられる。
- 一方で、「必ず従業員テナント側で MFA をやり直させたい」場合は、信頼設定をオフにし CA ポリシーで再度 MFA を要求する。
- Cross-tenant access settings で外部ユーザー／アプリへのアクセスをブロックし過ぎると、クロステナント同期そのものが動かなくなるケースがあるため、設定を変更する前に影響範囲をよく確認する。
最小構成チェックリスト
ここまでの内容を踏まえ、クロステナント同期＋B2B コラボレーションを最小構成で成立させるためのチェックリストをまとめます。
- 従業員テナント
- [Cross-tenant access settings] > [Organization settings] で外部テナントを追加済み
- 追加した組織の [Inbound access] > [Cross-tenant sync] で
- [Allow users sync into this tenant] 有効化
- [Trust settings] で [Automatically redeem invitations with the tenant <tenant>] 有効化
- 外部テナント
- [Cross-tenant access settings] > [Organization settings] で従業員テナントを追加済み
- 追加した組織の [Outbound access] > [Trust settings] で自動リデンプション有効化
- クロステナント同期構成
- 外部テナントで [Cross-tenant synchronization] に構成を作成
- Scope = [Sync only assigned users and groups] から開始し、テストユーザー／グループを割り当て済み
- 属性マッピングで UserType（Member/Guest）を要件に合わせて設定
- プロビジョニングログで初回同期の完了を確認（以後 ~40 分ごとの差分同期）
- ライセンス
- 外部テナント側で同期対象ユーザーに Entra ID P1 ライセンスが割り当て済み
- 従業員テナント側で動的グループや CA のスコープ設定に必要なライセンスを確認
- グループ・認可設計
- 従業員テナントにミラー用グループを作成（動的グループ or スクリプトで自動更新）
- アプリ／サイトへのアクセス権は、原則としてミラーグループにのみ付与
- 条件付きアクセス
- 外部 MFA / デバイス クレームを信頼するかどうか方針を決定
- 必要に応じて CA ポリシーで外部ユーザーの MFA 再要求やデバイス条件を定義
まとめ：従業員テナントを「権限のハブ」にする
本記事では、従業員テナントと外部テナントという 2 テナント構成において、B2B コラボレーションとクロステナント同期を組み合わせる設計を解説しました。
- ユーザーのライフサイクル管理は、外部テナント（ホームテナント）で行い、その結果をクロステナント同期で従業員テナントへ自動反映する。
- 認可（アクセス権・グループ・CA・監査）は、従業員テナントにミラー用グループを用意して集約管理する。
- クロステナント同期はあくまで B2B ユーザーの自動プロビジョニングであり、テナントマイグレーションや認証基盤の移行ツールではないことを理解しておく。
これらを踏まえて設計すれば、「どのユーザーが、どのテナントのどのリソースに、どのポリシーでアクセスしているか」を従業員テナント側から一望できるようになります。テナント数が増えれば増えるほど、クロステナント同期＋B2B コラボレーションという組み合わせは、「マルチテナント組織の標準パターン」として大きな威力を発揮するはずです。
コメント