Microsoft Entra の Cross-tenant access settings は、社外組織との B2B collaboration を「誰に、どのアプリへ、どの条件で許可するか」まで制御するための重要な設定です。2026年4月24日に Microsoft Learn の該当ページが更新されましたが、今回の確認で特に押さえるべき点は、単なる機能追加ではなく、既存のテナント間アクセス設定を棚卸しし、既定値・組織別設定・MFA/デバイス信頼・招待の引き換え順序を見直すことです。
とくに security admins、identity teams、compliance teams は、「B2B collaboration を許可しているか」だけでなく、既定設定のまま外部組織すべてに広く開いていないか、重要アプリだけを許可した結果、MFA登録や My Apps へのアクセスを壊していないか、外部テナントの MFA やデバイス準拠状態を信頼してよい相手かを確認する必要があります。
Microsoft EntraのCross-tenant access settingsとは
Microsoft Entra の Cross-tenant access settings は、外部の Microsoft Entra 組織と B2B collaboration を行う際のアクセス制御を管理する機能です。Microsoft 公式ドキュメントでは、外部組織のユーザーが自社リソースへアクセスする inbound access と、自社ユーザーが外部組織のリソースへアクセスする outbound access の両方を制御できる設定として説明されています。さらに、外部組織で実施済みの MFA や、準拠デバイス、Microsoft Entra hybrid joined device のクレームを信頼するかどうかも管理できます。(Microsoft Learn)
実務では、次のような場面で使います。
| 利用シーン | Cross-tenant access settingsで見るべき設定 |
|---|---|
| 取引先を Teams、SharePoint、社内アプリへ招待する | Inbound access settings |
| 自社社員が取引先テナントのアプリへゲスト参加する | Outbound access settings |
| 外部ユーザーに毎回 MFA を求めず、相手テナントの MFA を信頼したい | Inbound trust settings |
| M&A、グループ会社、海外拠点間でユーザー同期したい | Cross-tenant synchronization 関連設定 |
| 招待時に Microsoft アカウントではなく、組織IDやメールOTPを優先したい | Redemption order |
ポイントは、これは単なる「ゲスト招待のオン・オフ」ではないことです。B2B collaboration の入口、出口、信頼条件、対象アプリ、対象ユーザーを分けて設計する設定です。
2026年4月更新で確認すべきポイント
2026年4月24日の GitHub 履歴を見ると、対象ページ cross-tenant-access-settings-b2b-collaboration.yml では ms.date が 2026年4月24日に更新され、ai-usage: ai-assisted のメタデータが追加されています。差分上、このページ自体は大規模な本文改訂というより、公式ドキュメントのメタデータ更新として扱うのが正確です。(GitHub)
ただし、Microsoft Learn の公開ページは同日付で更新されており、現在の記載内容として管理者が再確認すべき論点は明確です。特に重要なのは、次の5点です。
| 確認ポイント | 管理者が見るべき理由 |
|---|---|
| Default settings | すべての外部 Microsoft Entra 組織に適用されるため、影響範囲が大きい |
| Organizational settings | 重要な取引先やグループ会社だけ例外ルールを作れる |
| Inbound / Outbound の整合性 | ユーザーを許可してもアプリ側をブロックするとアクセスできない |
| MFA・デバイスクレームの信頼 | 条件付きアクセスの体験とセキュリティ強度に直結する |
| Redemption order | ゲストがどのIDで招待を引き換えるかを制御できる |
「更新されたから何か新機能をすぐ有効化する」というより、2026年時点の公式記載に沿って、既存設定が過剰許可・過剰ブロック・運用不能のどれにもなっていないかを点検するのが実務的な対応です。
Default settingsは“全社の外部連携ポリシー”として扱う
Default settings は、個別の組織別設定を作成していない外部 Microsoft Entra 組織すべてに適用されます。公式ドキュメントでも、既定設定を変更する場合は Microsoft Entra 管理センターの External Identities > Cross-tenant access settings から Default settings を確認し、inbound または outbound の既定値を編集する流れが示されています。(Microsoft Learn)
ここで失敗しやすいのは、「全体を安全にしたい」という理由でいきなり既定の inbound または outbound を Block access にすることです。Microsoft も、既定の inbound / outbound を Block access に変更すると、既存の業務上重要なアプリ連携を遮断する可能性があるため、事前に必要なアクセスを特定するよう注意しています。(Microsoft Learn)
実務での判断基準
Default settings は、次のように考えると設計しやすくなります。
| 組織の状態 | 推奨される考え方 |
|---|---|
| 外部コラボレーションが少ない | Default は制限的にし、必要な取引先だけ Organizational settings で許可 |
| 取引先招待が日常的に多い | Default は許可寄りにしつつ、危険なドメインや高リスクアプリを別設定で制御 |
| 金融・医療・公共などコンプライアンス要求が高い | Default で広く許可せず、承認済み組織のみ個別設定 |
| グループ会社間で連携が多い | グループ会社ごとに Organizational settings を作り、MFA信頼や自動引き換えを個別設計 |
Default settings は「とりあえず既定値のまま」ではなく、社外コラボレーションの基本方針を表す設定としてレビューするべきです。
Organizational settingsで重要な取引先だけ個別制御する
Organizational settings は、特定の外部テナントに対して個別のアクセス設定を作る機能です。Microsoft Learn では、組織を追加する際にフルドメイン名またはテナントIDを入力し、追加後は inbound access または outbound access の列から既定値の継承を変更できると説明されています。(Microsoft Learn)
実務では、以下のような組織を個別設定の対象にします。
- 主要取引先
- グループ会社
- 委託先・開発パートナー
- 監査法人・法律事務所など機密情報に触れる外部組織
- クロステナント同期を使う予定のテナント
重要なのは、ドメイン名だけで相手を判断しないことです。テナントID、ユーザーオブジェクトID、グループオブジェクトID、アプリケーションIDなど、相手組織から正確な情報を取得してから設定する必要があります。Microsoft 公式ドキュメントでも、外部組織の特定ユーザー、グループ、アプリに設定を適用する場合は、事前に対象IDを取得するよう案内されています。(Microsoft Learn)
設定前に相手組織へ確認する項目
| 確認項目 | 目的 |
|---|---|
| テナントID | 誤った組織を追加しないため |
| 対象ドメイン | 招待・外部コラボレーション設定との整合性確認 |
| 対象ユーザーまたはグループのオブジェクトID | 特定ユーザー・グループだけ許可するため |
| 利用するアプリケーションID | 対象アプリのみ許可するため |
| 相手テナントのMFA運用 | MFAクレームを信頼してよいか判断するため |
| デバイス管理の有無 | compliant device / hybrid joined device を信頼できるか判断するため |
相手のセキュリティ水準が不明なまま MFA やデバイスクレームを信頼すると、自社の条件付きアクセス設計が弱くなる可能性があります。信頼設定は「便利だからオン」ではなく、契約・監査・技術運用の観点で確認してから有効化しましょう。
Inbound access settingsは外部ユーザーの入口を制御する
Inbound access settings は、外部 Microsoft Entra 組織のユーザーやグループが、自社のどのアプリへアクセスできるかを制御します。公式ドキュメントでは、外部ユーザー・グループの Allow / Block と、アプリケーション側の Allow / Block を組み合わせて設定する流れが示されています。(Microsoft Learn)
たとえば、次のような設定が考えられます。
| 要件 | 設定例 |
|---|---|
| 取引先Aの特定グループだけ SharePoint に招待したい | 取引先Aを Organizational settings に追加し、対象グループと対象アプリを許可 |
| すべての外部ユーザーを社内アプリから遮断したい | Inbound で外部ユーザーと対象アプリの両方をブロック |
| 特定アプリだけ外部ゲストに公開したい | Inbound で外部ユーザーを許可し、Applications で対象アプリのみ許可 |
| 外部ユーザーのMFAを相手テナント側で満たさせたい | Trust settings で相手テナントの MFA を信頼 |
注意すべきなのは、ユーザー側とアプリ側の設定はセットで考える必要があることです。Microsoft Learn でも、すべての外部ユーザー・グループをブロックする場合は、内部アプリケーション側もブロックする必要があると説明されています。また、クロステナント同期を構成している場合、すべての外部ユーザー・グループをブロックすると同期に影響する可能性があります。(Microsoft Learn)
SharePointやOneDrive連携で見落としやすい点
SharePoint や OneDrive のネイティブ共有機能を Microsoft Entra B2B integration と組み合わせて使う場合、Cross-tenant access settings に相手テナントを追加するだけでは不十分な場合があります。Microsoft Learn では、外部ドメインを external collaboration settings に追加しないと、SharePoint や OneDrive からの招待が失敗する可能性があると注意しています。(Microsoft Learn)
つまり、B2B collaboration のトラブル対応では、次の2つを分けて確認します。
| 確認対象 | 役割 |
|---|---|
| Cross-tenant access settings | Microsoft Entra 組織間の inbound / outbound / trust を制御 |
| External collaboration settings | ゲスト招待、ドメイン許可・拒否、ゲスト権限などを制御 |
「Entra 側では許可したのに SharePoint の招待が失敗する」という場合は、Cross-tenant access settings だけでなく external collaboration settings も確認してください。
Outbound access settingsは自社ユーザーの外部参加を制御する
Outbound access settings は、自社ユーザーが外部組織のアプリやリソースへ B2B collaboration でアクセスできるかを制御します。公式ドキュメントでは、自社ユーザー・グループと外部アプリケーションに対して Allow / Block を設定する流れが示されています。(Microsoft Learn)
多くの企業では inbound、つまり「外部ユーザーを自社に入れる」設定に注意が向きがちです。しかし、情報漏えいや監査の観点では outbound も重要です。自社社員が外部テナントにゲストとして参加すると、その外部環境でファイル共有、Teams参加、アプリ利用が発生するためです。
Outboundを見直すべきケース
| ケース | リスク | 見直し方 |
|---|---|---|
| 社員が多数の外部Teamsに参加している | 情報の持ち出し経路が増える | 外部組織別に許可・禁止を整理 |
| 退職者・異動者の外部参加状況が不明 | 外部側のゲスト権限が残る可能性 | サインインログや棚卸しで把握 |
| 重要部門だけ外部参加を制限したい | 機密情報を扱う部門の露出が増える | 部門グループ単位で outbound を制御 |
| 取引先ごとに利用アプリを限定したい | 不要な外部アプリ利用が広がる | External applications を限定許可 |
公式ドキュメントでは、対象ユーザー・グループを指定する場合、SMS-based authentication を構成しているユーザーを選択できない制限にも触れています。この場合は Microsoft Graph API でユーザーのオブジェクトIDを直接追加する、または対象ユーザーが所属するグループを指定する回避策が示されています。(Microsoft Learn)
MFAとデバイスクレームの信頼は“相手を信頼できるか”で決める
Cross-tenant access settings の重要な機能の一つが trust settings です。Inbound trust settings では、外部 Microsoft Entra テナントで実施済みの MFA、compliant device、Microsoft Entra hybrid joined device のクレームを、自社の条件付きアクセスで信頼するかを設定できます。(Microsoft Learn)
たとえば、相手テナントの MFA を信頼すると、外部ユーザーがホームテナントで MFA を完了している場合、自社テナント側で再度 MFA を求めずに済む場合があります。ユーザー体験は改善しますが、相手組織の MFA 強度、登録プロセス、デバイス管理、アカウント侵害時の対応を信頼することが前提になります。
Trust settingsの判断基準
| 設定 | 有効化に向くケース | 慎重にすべきケース |
|---|---|---|
| Trust MFA | グループ会社や統制済みの戦略パートナー | 相手のMFA方式や運用が不明 |
| Trust compliant devices | 相手のデバイス管理・準拠ポリシーを確認済み | BYOD中心で端末管理が弱い |
| Trust hybrid joined devices | 相手のハイブリッド参加デバイス管理を信頼できる | デバイスライフサイクル管理が不明 |
| Automatic redemption | 相互信頼のあるテナント間で招待体験を簡略化したい | 一般的な取引先や一時的な外部協力者 |
とくに compliance teams は、Trust MFA を有効にする際に「MFAが有効か」だけでなく、次の観点を確認しておくと監査対応がしやすくなります。
| 監査観点 | 確認内容 |
|---|---|
| 認証強度 | フィッシング耐性のある認証方式を使っているか |
| 登録プロセス | 外部ユーザー本人確認が適切に行われているか |
| 例外運用 | MFA除外ユーザーや緊急アカウントの扱い |
| ログ保全 | サインインログや監査ログを確認できるか |
| 契約・規程 | 相手組織とのセキュリティ責任分界が明確か |
MFA信頼はユーザー体験を改善できますが、実質的には「相手テナントの認証結果を自社のアクセス判断に使う」設定です。セキュリティ部門だけでなく、法務・監査・委託先管理の観点も含めて判断しましょう。
許可アプリを絞る場合はMicrosoft標準アプリを忘れない
Cross-tenant access settings で「指定したアプリだけ許可する」方針は、最小権限の考え方として有効です。ただし、許可アプリを絞りすぎると、ゲストユーザーが招待を受け取れても、MFA登録、My Apps、My Profile、My Sign-ins などの基本的な操作ができなくなることがあります。
Microsoft Learn では、SharePoint Online だけを許可した場合、ユーザーが My Apps にアクセスできなかったり、リソーステナントで MFA 登録できなかったりする例を挙げ、スムーズなエンドユーザー体験のために My Apps、Microsoft App Access Panel、My Profile、My Sign ins などのアプリを考慮するよう案内しています。(Microsoft Learn)
アプリ限定許可で起きやすい失敗
| 失敗例 | 原因 | 対策 |
|---|---|---|
| 招待後にユーザーが My Apps を開けない | My Apps 関連アプリを許可していない | My Apps のリソースIDを許可対象に含める |
| MFA登録画面に進めない | My Sign ins や App Access Panel が不足 | MFA登録に必要なアプリを許可 |
| 管理ポータルの外部アクセスができない | Microsoft Admin Portals グループをポータルで追加できない | 必要な管理ポータルを Microsoft Graph API で個別追加 |
| Graph APIで既存設定を上書きした | PATCH時に既存アプリを含めなかった | 事前にGETで既存設定を取得し、全対象を含めてPATCH |
Microsoft Learn では、Microsoft Entra 管理センターで選択できない一部アプリを許可する場合、Microsoft Graph API を使う方法も示されています。また、PATCH 要求では既存の構成済みアプリケーションを上書きするため、追加したいアプリだけでなく、維持したい既存アプリも含める必要があると注意しています。(Microsoft Learn)
Redemption orderでゲストの招待引き換え方法を制御する
Redemption order は、ゲストユーザーが招待を承諾する際に、どのIDプロバイダーでサインインするかの優先順位を調整する設定です。Microsoft Learn では、Cross-tenant access settings の inbound default から B2B collaboration タブを開き、Redemption order タブで ID プロバイダーの順序を変更できると説明されています。(Microsoft Learn)
特に重要なのは、Microsoft アカウントによる招待引き換えを防ぎたい場合です。公式ドキュメントでは、Microsoft accounts を無効化するには email one-time passcode を有効にする必要があり、少なくとも1つの fallback identity provider を有効にしておく必要があると説明されています。また、既に Microsoft アカウントでサインインしている既存ゲストには、そのまま後続サインインで使われるため、新しい設定を適用するには redemption status のリセットが必要です。(Microsoft Learn)
Redemption orderの実務例
| 要件 | 設定の考え方 |
|---|---|
| 取引先の組織アカウントを優先したい | Microsoft Entra identity provider を優先 |
| SAML/WS-Fed federation を優先したい | Direct federation を構成し、Redemption orderで上位に移動 |
| 個人のMicrosoftアカウント利用を避けたい | MSAを無効化し、email OTPを有効化 |
| 既存ゲストにも新しい方式を適用したい | redemption status のリセットを計画 |
ここはユーザー体験に直結します。セキュリティ上は望ましい設定でも、既存ゲストのサインイン方式を急に変えると問い合わせが増えるため、対象ユーザー、影響範囲、案内文を事前に準備してから変更しましょう。
Cross-tenant synchronizationを使う場合はブロック設定に注意する
Cross-tenant synchronization は、テナント間で B2B collaboration ユーザーの作成、更新、削除を自動化する用途で使われます。Microsoft Learn では、追加した組織の inbound access に Cross-tenant sync タブがあり、Allow users sync into this tenant のチェックボックスでユーザー同期を許可できると説明されています。(Microsoft Learn)
ここで注意したいのは、inbound access で外部ユーザーを広くブロックしている場合です。公式ドキュメントでは、すべての外部ユーザー・グループをブロックすると cross-tenant sync をブロックする可能性があると記載されています。(Microsoft Learn)
M&A、グループ会社統合、地域別テナント運用などで cross-tenant synchronization を使う場合は、次の順序で確認すると安全です。
| 手順 | 確認内容 |
|---|---|
| 1 | 対象の外部テナントを Organizational settings に追加 |
| 2 | Inbound access で対象ユーザー・グループを許可 |
| 3 | 必要なアプリケーションを許可 |
| 4 | Cross-tenant sync タブで同期許可を確認 |
| 5 | Automatic redemption の必要性を両テナントで確認 |
| 6 | 同期後のゲストユーザー権限、ライフサイクル、削除処理を確認 |
テナント間同期は便利ですが、誤って広く許可すると不要なユーザーが作成されるリスクがあります。対象グループを明確にし、同期元・同期先の責任分界を文書化しておきましょう。
管理者がすぐ実施すべきチェックリスト
2026年4月時点の Cross-tenant access settings を見直すなら、まずは次のチェックから始めるのが現実的です。
| チェック項目 | 確認ポイント |
|---|---|
| Default inbound | 外部組織すべてに対して過剰に許可していないか |
| Default outbound | 自社ユーザーが任意の外部組織へ参加できる状態になっていないか |
| Organizational settings | 重要な取引先・グループ会社が個別設定されているか |
| Inbound applications | 外部ユーザーに不要なアプリまで許可していないか |
| Outbound external applications | 自社ユーザーの外部アプリ利用範囲を把握しているか |
| Trust MFA | 相手テナントのMFA運用を確認しているか |
| Trust device claims | 相手のデバイス管理を信頼できる根拠があるか |
| Redemption order | Microsoftアカウント利用を許容するか決めているか |
| SharePoint / OneDrive | external collaboration settings との整合性が取れているか |
| Graph API変更 | PATCHで既存設定を上書きしない手順になっているか |
| 監査ログ | CrossTenantAccessSettings の変更履歴を確認できるか |
| サインインログ | 既存のinbound / outbound利用状況を把握しているか |
Microsoft の概要ドキュメントでは、現在のサインイン挙動を確認するために、PowerShell、Microsoft Graph の Get-MgAuditLogSignIn、Azure Monitor、SIEM などを使って inbound / outbound のサインインを特定する方法が案内されています。また、ログの保持期間が限られる場合があるため、業務部門への確認も推奨されています。(Microsoft Learn)
設定変更時に避けたい典型的なミス
Cross-tenant access settings は影響範囲が広いため、設定ミスがそのまま業務停止につながることがあります。特に次のミスは避けるべきです。
| ミス | 何が起きるか | 防止策 |
|---|---|---|
| Default settingsをいきなりBlockにする | 既存の外部連携が止まる | 先にサインインログと業務部門ヒアリングで棚卸し |
| ユーザーだけ許可してアプリを許可しない | 招待できてもアプリに入れない | Users / Groups と Applications をセットで確認 |
| アプリを絞りすぎる | MFA登録やMy Appsが使えない | Microsoft標準アプリの依存関係を確認 |
| Trust MFAを安易に有効化する | 相手テナントの認証品質に依存する | 相手のMFA運用・契約・監査要件を確認 |
| Graph APIのPATCHで一部だけ送る | 既存アプリ設定を上書きする | 事前にGETし、維持対象を含めてPATCH |
| SharePoint共有だけで判断する | Entra側は許可でも招待失敗する | external collaboration settingsも確認 |
| 既存ゲストのサインイン方式を考慮しない | Redemption order変更後も旧方式が残る | 必要に応じてredemption statusをリセット |
設定変更の前には、最低でも「対象組織」「対象ユーザー」「対象アプリ」「期待する認証方式」「ロールバック手順」を1枚の変更計画にまとめることをおすすめします。
グローバル運用ではクロスクラウド連携も確認する
グローバル企業では、商用 Azure、Azure Government、21Vianet 運用の Azure など、異なる Microsoft cloud 間での連携が問題になる場合があります。Microsoft Learn では、異なる Microsoft cloud のパートナー組織と B2B collaboration を構成するには、まず双方の組織で Microsoft cloud settings を有効化し、その後 inbound / outbound access settings を調整できると説明されています。(Microsoft Learn)
一方で、概要ドキュメントでは、異なる Microsoft cloud の Microsoft Entra テナントとの B2B direct connect はサポートされないと記載されています。(Microsoft Learn)
グローバル読者向けに重要なのは、次の切り分けです。
| 連携パターン | 確認ポイント |
|---|---|
| 同一Microsoft cloud内のB2B collaboration | Default / Organizational settings を中心に確認 |
| 異なるMicrosoft cloud間のB2B collaboration | Microsoft cloud settings を双方で有効化 |
| B2B direct connect | 相互のinbound / outbound設定が必要 |
| 異なるMicrosoft cloud間のB2B direct connect | サポート可否を公式ドキュメントで確認 |
国・地域・業界ごとにデータ所在地、監査、政府クラウド要件が異なるため、グローバル運用では「技術的に接続できるか」だけでなく、「接続してよいか」をコンプライアンス観点で確認してください。
まとめ：2026年4月更新は“設定棚卸し”のきっかけにする
Microsoft Entra の Cross-tenant access settings は、外部ユーザーとのコラボレーションを安全に進めるための中核設定です。2026年4月24日の更新は、該当ページの大幅な機能差分というより、現在の公式記載をもとに運用を再確認するタイミングとして捉えるのが適切です。
最初に取り組むべきことは、Default settings を見直し、重要な外部組織を Organizational settings に分け、inbound / outbound / trust / redemption order を整理することです。そのうえで、サインインログや監査ログを使って実際の利用状況を確認し、業務上必要な連携を壊さずに不要な外部アクセスを減らしていきましょう。
security admins はアクセス制御、identity teams はID・認証体験、compliance teams は監査・責任分界をそれぞれ確認し、Cross-tenant access settings を「ゲスト招待の設定」ではなく、外部組織との信頼関係を管理するポリシーとして運用することが重要です。
コメント