Microsoft Entra External IDの「Configure external collaboration」は、B2Bゲスト招待を安全に運用するための重要設定です。2026年4月更新では、外部コラボレーション設定そのものの考え方が大きく変わったというより、ゲストサインイン体験の更新完了、管理ロール要件の明確化、Graph APIで管理すべき設定領域の整理が実務上の注目点です。
特にsecurity admins、identity teams、compliance teamsは、「誰が外部ユーザーを招待できるか」「ゲストにどこまでディレクトリ情報を見せるか」「許可・拒否ドメインをどう扱うか」を棚卸しするタイミングです。Microsoft Learn上の対象記事は2026年4月24日付で更新され、関連するAllow/Blockドメイン設定記事は2026年4月25日付で更新されています。(GitHub)
Microsoft Entra External IDの外部コラボレーション設定とは
Microsoft Entra External IDの外部コラボレーション設定は、B2B collaborationで外部ユーザーを招待する際の基本ルールを決める設定です。主に次のような内容を制御します。(Microsoft Learn)
| 設定領域 | 何を制御するか | 実務上の確認ポイント |
|---|---|---|
| Guest user access | ゲストがMicrosoft Entraディレクトリ内で見られる情報の範囲 | グループ情報や他ユーザー情報を見せすぎていないか |
| Guest invite settings | 誰がB2Bゲストを招待できるか | 一般ユーザーや既存ゲストにも招待を許してよいか |
| Guest self-service sign-up | アプリ用のセルフサービスサインアップを許可するか | 業務アプリで外部ユーザー登録を自動化する必要があるか |
| External user leave settings | 外部ユーザーが自分で組織から離脱できるか | プライバシー情報の登録や退会プロセスと整合しているか |
| Collaboration restrictions | 特定ドメインへの招待を許可または拒否するか | 取引先ドメイン、個人メール、競合ドメインをどう扱うか |
ここで重要なのは、外部コラボレーション設定は「招待の入口」を制御する設定であり、すべての外部アクセス制御を単独で完結させるものではない点です。Microsoft Entra組織間のB2B collaborationでは、外部コラボレーション設定に加えて、cross-tenant access settingsでインバウンド・アウトバウンドアクセス、対象ユーザー、グループ、アプリケーションの範囲を確認する必要があります。(Microsoft Learn)
2026年4月更新で押さえるべきポイント
2026年4月更新の実務的な見方は、「新しいボタンが増えた」よりも「既存の運用前提が整理された」と捉えると分かりやすいです。特に影響が大きいのは次の3点です。
| 更新ポイント | 管理者が見るべき意味 | すぐ確認すべきこと |
|---|---|---|
| B2Bゲストのサインイン体験更新が完了済みの表現に変更 | ゲストは自社側ではなく、ホームテナント側のブランドやURLを見て認証する前提になる | ヘルプデスク手順、利用者向け案内、フィッシング注意喚起を更新する |
| 外部コラボレーション設定を更新できるロール表現が明確化 | Global Administratorだけに依存しない運用を検討しやすい | External Identity Provider Administratorなど、最小権限ロールの利用可否を確認する |
| Microsoft Graphで扱う設定リソースが整理 | 手作業だけでなく、設定監査・自動化の対象を決めやすい | authorizationPolicyなど、管理対象APIを棚卸しする |
Microsoft LearnのGitHub履歴では、対象記事のms.dateが2026年4月24日に更新され、ゲストサインイン体験の説明と管理ロール要件の記述が変更されています。特にロール要件は、以前の「Global Administratorが必要」という強い表現から、外部コラボレーション設定を更新できるロールの例としてGlobal AdministratorやExternal Identity Provider Administratorを挙げる表現に改められています。(GitHub)
B2Bゲストサインイン体験の更新完了が意味すること
Microsoftは、B2B collaborationのゲストユーザーサインイン体験の更新を2025年7月に開始し、2025年末までにロールアウトを完了したと説明しています。更新後は、ゲストユーザーが資格情報を入力する際、自分の所属組織のサインインページにリダイレクトされます。その後、認証が完了すると招待先の組織へ戻ってサインインが完了します。(Microsoft Learn)
これはセキュリティ面では自然な流れです。ゲストユーザーは普段使っているホームテナントのブランドやURLを確認して認証するため、「どの組織に資格情報を入力しているのか」を判断しやすくなります。
ただし、現場では混乱が起きやすいポイントでもあります。たとえば、外部パートナーが自社のSharePointやTeamsにアクセスする際、サインイン画面に自社ロゴではなく相手企業のブランドが表示されることがあります。これを利用者が「違うサイトに飛ばされた」と誤解すると、問い合わせが増えます。
管理者が更新すべき案内文の例
ゲスト向けの案内には、次のような説明を入れておくと実務で役立ちます。
招待リンクを開いた後、認証のために所属組織のサインインページへ移動する場合があります。認証後は、招待元組織のアプリまたはリソースへ戻ります。表示される組織名、URL、アカウントを確認してからサインインしてください。
この一文があるだけで、ヘルプデスクへの問い合わせや、誤ったアカウントでのサインイン試行を減らせます。
管理ロールは「Global Administrator依存」から見直す
今回の更新で特にsecurity adminsが注目すべきなのは、ポータルで外部コラボレーション設定を更新するためのロール表現です。Microsoft Learnでは、Microsoft Entra admin centerで外部コラボレーション設定を更新するには、Global AdministratorやExternal Identity Provider Administratorなど、設定更新が可能なロールが必要と説明されています。(Microsoft Learn)
これは「Global Administratorで作業すればよい」という意味ではありません。むしろ、日常運用ではGlobal Administratorの利用を減らし、必要最小限の権限で設定変更できる体制を作るべきです。Microsoftも、権限の少ないロールを使うことを推奨し、Global Administratorは高度な特権ロールであり、緊急時や既存ロールで対応できない場合に限定すべきと説明しています。(Microsoft Learn)
ロール見直しの判断基準
| 作業内容 | 推奨される運用の考え方 | 避けたい運用 |
|---|---|---|
| 外部コラボレーション設定の定期見直し | 専任のID管理担当に適切なロールを割り当てる | Global Administratorを日常的に使う |
| 一時的な設定変更 | PIMなどで期間限定の昇格を使う | 永続的に高権限を付けたままにする |
| ゲスト招待の委任 | Guest Inviterロールを使う | User AdministratorやGlobal Administratorを安易に付与する |
| 監査対応 | 変更履歴と承認フローを残す | 誰が変更したか分からない状態で運用する |
特にグローバル企業では、地域ごとのIT担当者に広範な管理権限を渡してしまうと、外部招待ポリシーが拠点ごとにばらつきます。IDチームが標準ポリシーを定義し、各国・各部門には必要な範囲だけ委任する設計が現実的です。
Guest user accessは「既定値のまま」でよいとは限らない
Guest user accessでは、ゲストユーザーがMicrosoft Entraディレクトリ内で見られる情報範囲を選択できます。Microsoft Learnでは、主に3つの選択肢が示されています。(Microsoft Learn)
| 設定 | 内容 | 向いているケース |
|---|---|---|
| Guest users have the same access as members | ゲストにメンバーと同等のディレクトリアクセスを許可 | 特別な理由がある限定的なケース |
| Guest users have limited access | 一部のディレクトリ列挙などを制限する既定設定 | 一般的なB2B collaboration |
| Guest user access is restricted to their own directory objects | ゲストは自分自身のプロファイルなどに限定 | コンプライアンス要件が厳しい環境 |
多くの組織では既定設定のまま運用しがちですが、コンプライアンスチームは「外部ユーザーが組織内のユーザー、グループ、メンバーシップ情報をどこまで把握できるか」を確認すべきです。
たとえば、M&A、研究開発、法務案件、医療・金融領域のプロジェクトでは、グループ名やメンバー構成そのものが機密情報になり得ます。その場合は、最も制限の強い設定を検討する価値があります。
ただし、制限を強めると、外部ユーザーが共同作業相手を探しにくくなったり、一部のアプリ体験に影響したりする可能性があります。設定変更前に、Teams、SharePoint、業務アプリで実際のゲストユーザー体験を検証してください。
Guest invite settingsは「誰が招待できるか」を業務リスクで決める
Guest invite settingsでは、B2Bゲストを招待できるユーザー範囲を指定できます。選択肢は、組織内の誰でも招待できる設定から、誰も招待できない最も制限的な設定まであります。Microsoft Learnでは、既定では組織内のすべてのユーザー、B2B collaborationゲストユーザーを含めて外部ユーザーを招待できると説明されています。(Microsoft Learn)
この設定は、利便性とリスクが正面からぶつかる領域です。
営業、調達、採用、カスタマーサクセスなど、外部とのやり取りが多い部門では、現場がすぐにゲストを招待できるほうが業務は進みます。一方で、誰でも招待できる状態では、退職済み取引先、個人メール、誤った外部ドメインへの招待が起きやすくなります。
招待権限のおすすめ設計
| 組織の状態 | 設定方針 | 理由 |
|---|---|---|
| 小規模で外部共有が少ない | 管理者またはGuest Inviterに限定 | 誤招待を防ぎやすい |
| 外部パートナーが多い | メンバー招待は許可し、ゲストからの再招待は制限 | 業務速度と統制のバランスを取りやすい |
| 規制業種・機密情報が多い | 特定管理ロールのみに限定 | 監査証跡と承認フローを合わせやすい |
| 一時的なプロジェクトが多い | Guest Inviterを期間限定で付与 | プロジェクト終了後に権限を戻しやすい |
Guest Inviterロールを使うと、高い管理者権限を付与せずに、特定ユーザーへゲスト招待権限を委任できます。Microsoft Learnでは、Guest Inviterロールを持つユーザーは、Guest invite settingsで「特定の管理ロールに割り当てられたユーザーのみ招待可能」を選んでいる場合でもゲストを招待できると説明されています。(Microsoft Learn)
Collaboration restrictionsでは許可リストと拒否リストを使い分ける
Collaboration restrictionsでは、B2B collaborationの招待を許可または拒否するドメインを指定できます。Microsoft Learnでは、個人メールドメインをブロックしたい場合はGmail.comやOutlook.comのようなドメインを拒否リストに追加し、特定のパートナー組織だけに招待を許可したい場合はContoso.comなどのドメインを許可リストに追加する例が示されています。(Microsoft Learn)
ここで注意したいのは、許可リストと拒否リストは同時に使えない点です。Microsoft Learnでは、作成できるのはallow listまたはblock listのどちらか一方であり、許可リストにないドメインは既定でブロックされ、拒否リストにないドメインは許可されると説明されています。(Microsoft Learn)
許可リストと拒否リストの使い分け
| 方式 | 向いている組織 | メリット | 注意点 |
|---|---|---|---|
| 拒否リスト | 多数の取引先と柔軟に連携する組織 | 業務を止めにくい | 未登録のリスクドメインを招待できてしまう |
| 許可リスト | 連携先が限定される組織、規制業種 | 統制しやすい | 新しい取引先追加のたびに運用が必要 |
| どちらも未設定 | 初期段階、検証環境 | 導入が簡単 | 本番運用ではリスクが高い |
許可リストは強力ですが、厳しくしすぎると現場がメール添付や個人ストレージなど、管理外の手段で情報共有し始めることがあります。セキュリティを高めるための設定が、結果的にシャドーITを増やしては本末転倒です。
おすすめは、まずサインインログと招待履歴を確認し、実際に使われている外部ドメインを棚卸しすることです。そのうえで、明確に不要な個人メールドメインや競合・高リスクドメインを拒否するか、取引先が限定されている部門から許可リスト運用を始めると失敗しにくくなります。
Cross-tenant access settingsとの違いを混同しない
外部コラボレーション設定とcross-tenant access settingsは、どちらもB2B collaborationに関係しますが、役割が異なります。
| 設定 | 主な役割 | 例 |
|---|---|---|
| External collaboration settings | 招待、ゲスト表示範囲、招待可能ドメインなど入口を制御 | 「このドメインのユーザーを招待できるか」 |
| Cross-tenant access settings | 他のMicrosoft Entra組織とのインバウンド・アウトバウンドアクセスを制御 | 「外部ユーザーがどのアプリへアクセスできるか」 |
| Conditional Access | サインイン条件やリスクに応じたアクセス制御 | 「MFA必須」「準拠デバイスのみ」 |
Microsoft Learnでは、B2B collaborationで他のMicrosoft Entra組織と連携する場合、cross-tenant access settingsも確認し、インバウンド・アウトバウンドB2B collaborationや、特定ユーザー、グループ、アプリケーションへのスコープを確認するよう案内しています。(Microsoft Learn)
また、allow/block listとcross-tenant access settingsは招待時にチェックされます。ユーザーのドメインがブロックリストにある場合、cross-tenant access settingsに関係なく招待できません。どちらのリストにもない場合は、cross-tenant access settingsで招待可否が判断されます。(Microsoft Learn)
つまり、外部コラボレーション設定だけを見て「許可されているはず」と判断するのは危険です。実際のトラブル調査では、少なくとも次の3点をセットで確認してください。
- 対象ドメインがallow/block listで制限されていないか
- 対象テナントがcross-tenant access settingsでブロックされていないか
- Conditional Accessやアプリ側の共有設定で制限されていないか
特にSharePointやOneDriveの共有では、Microsoft Entra側の設定とSharePoint/OneDrive側のドメイン制限が別に存在します。Microsoft Learnでも、SharePoint Onlineで個別ファイル共有を制限したい場合は、SharePointとOneDrive用の許可・拒否リストを設定する必要があると説明されています。(Microsoft Learn)
External user leave settingsはプライバシー運用と合わせて確認する
External user leave settingsでは、外部ユーザーが自分で組織から離脱できるかを制御できます。設定をYesにすると、外部ユーザーは管理者やプライバシー連絡先の承認なしに自分で組織から離脱できます。Noにすると、外部ユーザーは自分で離脱できず、管理者またはプライバシー連絡先へ削除を依頼する案内を受けます。(Microsoft Learn)
注意点は、この設定を構成するにはMicrosoft Entraテナントにプライバシー情報を追加している必要があることです。プライバシー情報が未設定の場合、この項目は利用できません。(Microsoft Learn)
compliance teamsにとって、この設定は単なる利便性の問題ではありません。外部ユーザーが退職した、契約が終了した、個人情報削除を求めたといったケースで、どの窓口に連絡すべきかを明確にしておく必要があります。
確認すべき運用項目
| 確認項目 | 理由 |
|---|---|
| プライバシー連絡先が登録されているか | 外部ユーザーの削除依頼先を明確にするため |
| 契約終了時のゲスト削除手順があるか | 退職者や契約終了者の残存を防ぐため |
| アクセスレビューと連動しているか | 不要なゲストアカウントを定期的に削除するため |
| ユーザー自身の離脱を許可するか | 管理統制と本人の削除希望への対応を両立するため |
ゲストが自分で離脱できる設定は便利ですが、組織側で監査証跡や契約管理を重視する場合は、削除申請フローと合わせて設計したほうが安全です。
Microsoft Graphで管理する設定領域
2026年4月更新では、Microsoft Graphで外部コラボレーション設定を管理する際のリソースも整理されています。Microsoft Learnでは、Guest user access restrictionsとGuest invite restrictionsにはauthorizationPolicy、guest self-service sign-upにはauthenticationFlowsPolicy、External user leave settingsにはexternalidentitiespolicy、メールワンタイムパスコード設定にはemailAuthenticationMethodConfigurationを使うと説明されています。(Microsoft Learn)
| 設定対象 | Microsoft Graphリソース | 自動化の用途例 |
|---|---|---|
| ゲストアクセス制限 | authorizationPolicy | ゲスト権限設定の監査 |
| ゲスト招待制限 | authorizationPolicy | 招待可能ユーザー範囲の標準化 |
| セルフサービスサインアップ | authenticationFlowsPolicy | アプリごとの登録フロー管理 |
| 外部ユーザー離脱設定 | externalidentitiespolicy | プライバシー運用との整合確認 |
| メールワンタイムパスコード | emailAuthenticationMethodConfiguration | 外部IDプロバイダー設定の棚卸し |
Graph APIを使う場合は、設定変更の自動化だけでなく「現在の設定が標準ポリシーからズレていないか」を定期的に確認する用途にも向いています。
たとえば、グローバル企業で複数テナントを運用している場合、各テナントでGuest invite settingsがばらつくと、ある地域だけゲスト招待が過剰に開放されることがあります。Graphで設定値を取得し、標準値との差分をレポート化すれば、監査前の点検がしやすくなります。
サインインログはホームテナントとリソーステナントの両方を見る
B2Bユーザーがリソーステナントへサインインして共同作業する場合、サインインログはホームテナントとリソーステナントの両方に生成されます。ログには、使用されたアプリケーション、メールアドレス、ホームテナントとリソーステナントのテナント名、テナントIDなどの情報が含まれます。(Microsoft Learn)
これはインシデント調査で重要です。リソースを提供する側だけがログを見ても、外部ユーザーのホームテナント側で何が起きたかまでは見えない場合があります。逆に、外部パートナー側も自社ユーザーの認証イベントを確認できます。
インシデント調査で確認する流れ
| 手順 | 確認内容 |
|---|---|
| リソーステナント側のサインインログを確認 | どのアプリに、どの外部ユーザーが、いつアクセスしたか |
| ホームテナント情報を特定 | 相手組織のテナント名、テナントID、ユーザー情報を確認 |
| cross-tenant access settingsを確認 | 当該テナントやアプリに対するアクセス許可が妥当か |
| 招待履歴とゲスト状態を確認 | 誰が招待したか、招待が不要になっていないか |
| 必要に応じて相手組織と連携 | ホームテナント側の認証状況やMFA状況を確認 |
特に、外部ユーザーの不審なアクセス、退職者の残存、誤招待が疑われる場合は、リソーステナントだけで完結させず、相手組織との連絡経路を確保しておくことが大切です。
2026年4月時点で管理者が実施すべきチェックリスト
今回の更新を受けて、security admins、identity teams、compliance teamsは次の順で確認すると効率的です。
| 優先度 | チェック項目 | 判断基準 |
|---|---|---|
| 高 | Guest invite settings | ゲストや一般ユーザーが自由に招待できる状態になっていないか |
| 高 | Guest user access | 外部ユーザーに不要なディレクトリ情報を見せていないか |
| 高 | 管理ロール | Global Administratorを日常作業に使っていないか |
| 高 | Collaboration restrictions | 個人メールや未承認ドメインへの招待を許していないか |
| 中 | Cross-tenant access settings | 主要取引先ごとのインバウンド・アウトバウンド設定が妥当か |
| 中 | ヘルプデスク案内 | ホームテナント側サインイン画面の説明が古くないか |
| 中 | External user leave settings | プライバシー連絡先と削除フローが整っているか |
| 中 | Graphによる監査 | 設定の標準化と差分検知ができているか |
| 低 | セルフサービスサインアップ | 業務アプリで本当に必要な場合だけ有効化しているか |
最初に取り組むべきなのは、Guest invite settingsとGuest user accessです。この2つは、外部ユーザーが増えるスピードと、見えてしまう情報の範囲に直結します。次に、許可・拒否ドメインとcross-tenant access settingsを確認し、最後にGraphによる継続監査へ進めるとよいでしょう。
失敗しやすいポイント
Microsoft Entraの外部コラボレーション設定では、設定項目自体よりも、周辺設定との組み合わせでトラブルが起きやすくなります。
| 失敗例 | 原因 | 対策 |
|---|---|---|
| 取引先を招待できない | ドメイン拒否、cross-tenant access、SharePoint側制限のどれかでブロック | Entra、cross-tenant、SharePoint/OneDriveを順に確認 |
| ゲストがサインイン画面を不審に思う | ホームテナント側ブランドが表示されることを案内していない | 利用者向け手順書を更新 |
| 外部ユーザーが増え続ける | 誰でも招待でき、棚卸しがない | 招待権限を制限し、アクセスレビューを実施 |
| 管理者権限が過剰 | Global Administratorで日常運用している | 最小権限ロールとPIMを使う |
| 許可リストが厳しすぎる | 新規取引先の追加に時間がかかる | 申請フローとSLAを決める |
| 退職済み外部ユーザーが残る | 契約終了とID削除が連動していない | 契約管理、アクセスレビュー、ゲスト削除を連携 |
特に見落としやすいのは、「招待できる」と「アクセスできる」は同じではないという点です。招待が成功しても、cross-tenant access settings、Conditional Access、アプリ側の共有設定でアクセスが止まることがあります。逆に、古い招待が残っていて、想定外のアクセス経路になることもあります。
まとめ：2026年4月更新は外部IDガバナンス見直しの合図
Microsoft Entra External IDのConfigure external collaborationに関する2026年4月更新は、B2B外部コラボレーションの運用を見直すよいタイミングです。特に、B2Bゲストのサインイン体験が2025年末までに更新完了したこと、外部コラボレーション設定を管理するロール要件が明確化されたことは、現場の案内文と管理者権限設計に影響します。
まずは、Guest invite settingsで「誰が招待できるか」を確認し、Guest user accessで「ゲストに何を見せるか」を見直してください。そのうえで、許可・拒否ドメイン、cross-tenant access settings、外部ユーザー削除フロー、Graphによる監査を整備すると、利便性を保ちながら外部IDガバナンスを強化できます。
外部コラボレーションは止めるものではなく、管理できる形に整えるものです。Microsoft Entraの設定を定期的に棚卸しし、業務部門が安全にパートナーと協業できる状態を維持することが、2026年以降のID管理でますます重要になります。
コメント