Microsoft Entra External IDで外部ユーザーを安全に招待・共有する場合、2026年4月25日更新版で最初に押さえるべき結論は明確です。Workforce tenantでは、Microsoft Entra IDが外部共有の既定IDプロバイダーであり、追加のIDプロバイダーは「誰に、どのアプリを、どのリスク条件で使わせるか」に応じて選ぶ設定項目です。Microsoft EntraアカウントやMicrosoftアカウントを持つ外部ユーザーは追加設定なしでサインインできますが、Email one-time passcode、Google、Facebook、SAML/WS-Fed federationには、それぞれ適用範囲と注意点があります。(Microsoft Learn)
Security admins、identity teams、compliance teamsが今すぐ見るべきなのは、「どのIDプロバイダーを有効にするか」だけではありません。招待できるユーザーの範囲、ゲストユーザーの権限、MFAやConditional Accessの適用方法、既存ゲストの認証方式が変わるかどうかまで確認する必要があります。
Microsoft Entraの最新動向: 2026年4月更新版で何を確認すべきか
Microsoft Learnの「Identity providers for External ID in workforce tenants」は、2026年4月25日に更新されています。ただし、公開ページ上で個別の差分履歴が細かく示されているわけではないため、本記事では「更新版の現在の記述から、実務で見直すべきポイント」を整理します。対象はWorkforce tenantのB2B collaborationであり、External tenant向けの顧客ID管理、いわゆるCIAMの設計とは切り分けて読む必要があります。(Microsoft Learn)
Workforce tenantは、従業員、社内アプリ、組織リソースを管理するためのテナントで、外部パートナーやゲストとのコラボレーションにはMicrosoft Entra External IDのB2B collaborationを使います。一方、External tenantは消費者やビジネス顧客向けアプリを公開する用途に特化した構成です。つまり、今回の確認対象は「社外パートナーにSharePoint、Teams、業務アプリ、ポータルなどを使わせる」場面です。(Microsoft Learn)
まず理解すべき前提: IDプロバイダーは「認証」であり「アクセス許可」ではない
IDプロバイダーは、ユーザーが誰であるかを確認する認証基盤です。Microsoft Entra External IDのB2B collaborationでは、外部ユーザーは自分の資格情報であなたのWorkforce tenantにサインインし、共有されたアプリやリソースにアクセスします。外部ユーザーのオブジェクトは従業員と同じディレクトリ内に作成され、グループ追加やアプリ割り当てなどで管理できます。(Microsoft Learn)
ここで失敗しやすいのは、「Googleを有効にしたからGoogleユーザーにアクセス権が付く」「SAML federationを設定したから全員が業務アプリを使える」と考えてしまうことです。IDプロバイダーはサインイン方法を決めるだけで、実際のアクセス可否は、アプリ割り当て、グループ、ロール、Conditional Access、外部コラボレーション設定で制御します。
利用できるIDプロバイダーと実務での選び方
2026年4月更新版の公式情報では、Workforce tenantの外部ユーザー向けIDプロバイダーとして、Microsoft Entra accounts、Microsoft accounts、Email one-time passcode、Google、Facebook、SAML/WS-Fed identity provider federationが整理されています。Microsoft Entra accountsは既定で許可され、Google、Facebook、SAML/WS-Fed federationを構成するには、少なくともExternal Identity Provider Administrator権限が必要です。(Microsoft Learn)
| IDプロバイダー | 向いているケース | 管理者が確認すべきポイント |
|---|---|---|
| Microsoft Entra accounts | 取引先やグループ会社がMicrosoft Entra IDを使っている | 既定の選択肢として扱いやすい。Cross-tenant access settingsとMFA trustを確認する |
| Microsoft accounts | 個人事業主、外部専門家、小規模パートナーなど | 個人アカウント利用を許容する業務範囲を明確にする |
| Email one-time passcode | 相手がMicrosoft Entra ID、Microsoft account、Googleなどを使えない場合 | フォールバックとして便利だが、MFAや認証強度ポリシーの扱いに注意する |
| Google federation | Gmailユーザーを招待する場合 | Google Workspaceドメインとの federation はSAML/WS-Fedを検討する |
| 自社開発アプリのself-service sign-up | 招待の引き換え時のサインインオプションとしては使えない | |
| SAML/WS-Fed federation | 相手企業が独自IdPを持ち、Microsoft Entra IDを使っていない場合 | 証明書、メタデータURL、DNS、要求クレーム、既存ゲストの認証方式を確認する |
判断基準はシンプルです。相手がMicrosoft Entra IDを使っているなら、まずMicrosoft Entra accountを前提にします。相手がGmailを使う個人・小規模事業者ならGoogle federationまたはEmail one-time passcodeを検討します。相手が企業IdPを持つがMicrosoft Entra IDではない場合は、SAML/WS-Fed federationが候補です。
Microsoft Entra IDが既定IDプロバイダーである意味
Microsoft Entra External IDでは、アプリやリソースを外部ユーザーと共有する場合、Microsoft Entra IDが既定のIDプロバイダーとして使われます。招待した外部ユーザーがMicrosoft EntraアカウントまたはMicrosoft accountを持っている場合、管理者が追加設定をしなくてもサインインできます。(Microsoft Learn)
これは便利ですが、セキュリティ管理の観点では「既定だから放置してよい」という意味ではありません。特に大企業やグローバル組織では、次のような確認が必要です。
- 外部ユーザーを誰が招待できるか
- ゲストがディレクトリ内で何を閲覧できるか
- 特定ドメインを許可またはブロックするか
- 相手テナントのMFAやデバイス準拠状態を信頼するか
- 高リスクアプリに対して追加のMFAを求めるか
外部コラボレーション設定では、ゲスト招待を許可するロール、ゲストユーザーが参照できるディレクトリ情報、self-service sign-up、許可・ブロック対象ドメインを制御できます。既定では組織内の全ユーザーやゲストまで招待可能な構成になり得るため、厳格な環境では「誰でも招待できる」状態を避け、Guest Inviterや管理者ロールに絞る設計が現実的です。(Microsoft Learn)
Email one-time passcodeは便利だが、無効化やMFA設計に注意
Email one-time passcodeは、外部ユーザーがMicrosoft Entra ID、Microsoft account、ソーシャルIDプロバイダーなどで認証できない場合に、メールに送信される一時コードでサインインできる機能です。現在は新しいテナント、および明示的に無効化していない既存テナントで既定有効とされています。(Microsoft Learn)
実務では、Email one-time passcodeを「例外ユーザー向けの救済策」として設計するのが扱いやすいです。たとえば、短期プロジェクトの外部レビュー担当者、Microsoft Entra IDを持たない海外ベンダー、アカウント発行に時間をかけられない一時協力者には有効です。
ただし、注意点があります。Email one-time passcodeアカウントには、Conditional Accessのauthentication strength policiesを直接適用できないため、MFAを要求する場合は「Require MFA」のgrant controlを使う必要があります。さらに、一度OTPで招待を引き換えたユーザーは、その後に別のアカウント種別を取得しても自動で認証方式が切り替わるわけではありません。必要に応じてredemption statusのリセットを検討します。(Microsoft Learn)
Google federationではGmailとGoogle Workspaceを混同しない
Google federationは、GmailユーザーがMicrosoft accountを作成せずに、Googleアカウントで共有アプリやリソースにサインインできる仕組みです。Microsoft Learnでは、Google federationはGmailユーザー向けに設計されており、Google Workspaceドメインと federation する場合はSAML/WS-Fed identity provider federationを使うよう説明されています。(Microsoft Learn)
この違いは、グローバル企業や海外パートナーとの連携で特に重要です。相手が「Googleを使っている」と言っても、それが個人のGmailなのか、企業管理下のGoogle Workspaceなのかで設計が変わります。GmailならGoogle federation、企業ドメインならSAML/WS-Fed federationを検討する、という切り分けが実務的です。
また、Googleはembedded web-view sign-in supportを非推奨化しており、Microsoft Entra B2BやAzure AD B2CでGoogle federationを使う場合、埋め込みWebビューを使うアプリではGmailユーザーが認証できない可能性があります。業務アプリ、モバイルアプリ、Electron系アプリ、古い認証ライブラリを使うアプリでは、システムブラウザーや対応済みの認証フローへ移行済みか確認してください。(Microsoft Learn)
Facebookはself-service sign-up専用と考える
Facebook federationは、外部ユーザーが自社開発アプリにself-service sign-upするシナリオで使えます。一方で、外部ユーザーがあなたの組織からの招待を引き換えるときのサインインオプションとしては利用できません。(Microsoft Learn)
そのため、セキュリティ管理者がSharePoint、Teams、業務ポータルへのB2B招待を設計している場合、Facebookは通常の第一候補にはなりません。B2B collaborationでの外部パートナー招待が目的なら、Microsoft Entra accounts、Email one-time passcode、Google、SAML/WS-Fed federationを中心に設計する方が自然です。
SAML/WS-Fed federationは企業間連携に有効だが、設定後の運用が重要
SAML/WS-Fed identity provider federationを使うと、外部組織のユーザーは自社IdPで管理されたアカウントを使って、あなたのアプリやリソースにサインインできます。外部ユーザーに新しいMicrosoft Entra資格情報を作成させずに済むため、相手企業がAD FS、SAML IdP、WS-Fed対応IdPを持っている場合に有効です。(Microsoft Learn)
ただし、SAML/WS-Fed federationは「設定して終わり」ではありません。相手組織側のIdP設定、必要なクレーム、relying party trust、場合によってはDNS TXTレコードが必要です。さらに、メタデータURLを指定しない場合や、証明書が期限前にローテーションされた場合、Microsoft Entra IDが署名証明書を自動更新できないため、手動更新が必要になることがあります。(Microsoft Learn)
既存ゲストへの影響にも注意が必要です。すでに招待を引き換えた外部ユーザーは、後からfederationを設定しても認証方式が自動変更されません。次回アクセス時にfederationへ切り替えたい場合は、ユーザーのredemption statusをリセットして、引き換えプロセスを再実行させる必要があります。(Microsoft Learn)
Conditional AccessとMFAはIDプロバイダーごとに効き方が違う
外部ユーザーの認証フローは、B2B collaborationかB2B direct connectか、ユーザーのIDプロバイダー、Conditional Access policies、Cross-tenant access settingsによって決まります。Microsoft Entra IDでは、外部ユーザーに対しても従業員と同じようにConditional Accessを適用できますが、認証方式によって使える制御が異なります。(Microsoft Learn)
特に重要なのは、authentication strength policiesを現在適用できるのはMicrosoft Entra IDで認証する外部ユーザーに限られる点です。Email one-time passcode、SAML/WS-Fed、Google federationのユーザーにMFAを求める場合は、authentication strengthではなくMFA grant controlを使います。(Microsoft Learn)
| 要件 | 推奨される確認ポイント |
|---|---|
| 外部ユーザーにもMFAを必須化したい | IDプロバイダー別に、authentication strengthが使えるか、Require MFAが必要かを分けて設計する |
| 相手テナントのMFAを信頼したい | Cross-tenant access settingsのinbound trust settingsを確認する |
| デバイス準拠を要求したい | 外部ユーザーのデバイスは通常ホームテナント管理のため、device claimsを信頼するか検討する |
| 高リスクアプリを守りたい | ゲストユーザー向けConditional Accessを個別に作り、対象アプリ・対象ユーザーを限定する |
| 監査証跡を残したい | サインインログをresource tenant側で確認し、必要に応じてhome tenant側のログ確認も依頼する |
Cross-tenant access settingsでは、外部Microsoft Entra組織とのB2B collaborationやB2B direct connectについて、inbound、outbound、trust settingsを細かく制御できます。既定ではB2B collaborationが有効で、B2B direct connectはブロックされていますが、MFAやデバイス要求の信頼は別途設計が必要です。(Microsoft Learn)
2026年4月更新を受けて管理者が行うべき見直し手順
まず、外部ユーザーの棚卸しを行います。Microsoft Entra admin centerまたはMicrosoft Graphで、ゲストユーザーのUserType、Identities、招待状態、所属グループ、割り当てアプリを確認します。B2B collaborationユーザーのIdentitiesには、ExternalAzureAD、Microsoft account、google.com、facebook.com、mail、SAML/WS-Fedのissuer URIなどが反映されます。(Microsoft Learn)
次に、現在有効なIDプロバイダーを業務シナリオごとに分類します。たとえば、長期取引先はMicrosoft Entra accountまたはSAML/WS-Fed、短期協力者はEmail one-time passcode、Gmail利用者はGoogle federation、一般向けアプリのself-service sign-upはFacebookやGoogleを含めて検討する、といった整理です。
そのうえで、次の順序で設定を確認すると実務で迷いにくくなります。
| 手順 | 確認内容 | 見直しの判断基準 |
|---|---|---|
| 1 | 外部ユーザーの一覧を取得する | 退職者、契約終了者、用途不明のゲストが残っていないか |
| 2 | Identitiesを確認する | Microsoft Entra、MSA、OTP、Google、SAML/WS-Fedが混在していないか |
| 3 | 招待権限を確認する | 全社員やゲストが自由に招待できる状態になっていないか |
| 4 | 許可・ブロックドメインを確認する | 取引先ドメインのみ許可する必要があるか |
| 5 | Conditional Accessを確認する | 外部ユーザー向けポリシーが従業員向けと同じ前提になっていないか |
| 6 | SAML/WS-Fed証明書を確認する | メタデータURL、自動更新、期限切れ通知の運用があるか |
| 7 | サインインログを確認する | 失敗、OTP多発、想定外IdP、海外アクセスの傾向がないか |
特にcompliance teamsは、外部ユーザーの認証方式だけでなく、誰が招待したか、どのリソースへアクセスしたか、どの条件でブロックされたかを説明できる状態にしておくべきです。B2Bユーザーがresource tenantで共同作業すると、home tenantとresource tenantの両方にサインインログが生成され、アプリ、メールアドレス、テナント名、テナントIDなどの情報が含まれます。(Microsoft Learn)
よくある失敗と回避策
すべての外部ユーザーに同じ認証方式を強制する
外部ユーザーは、相手企業のID基盤、契約期間、アクセスするアプリの機密度が異なります。全員に同じ認証方式を強制すると、運用負荷が増えるだけでなく、例外申請が増えて統制が崩れます。高機密アプリはMicrosoft Entra accountやSAML/WS-Fedを優先し、短期・低リスクの共有にはEmail one-time passcodeを使うなど、リスクベースで分ける方が現実的です。
Google federationをGoogle Workspace向けに使おうとする
Google federationはGmailユーザー向けです。相手企業がGoogle Workspaceを使っている場合は、SAML/WS-Fed federationを検討する必要があります。ここを誤ると、企業管理されたIDではなく個人Gmailでのサインインを許してしまい、アカウントライフサイクル管理や退職時の統制が弱くなります。(Microsoft Learn)
SAML/WS-Fed設定後に既存ゲストが自動で切り替わると思い込む
既存ゲストの認証方式は、federationを後から設定しても自動変更されません。移行が必要な場合は、対象ユーザーを洗い出し、redemption statusのリセット、ユーザー通知、再サインインの手順を用意します。(Microsoft Learn)
外部ユーザーに従業員と同じデバイス条件をそのまま適用する
外部ユーザーのデバイスは、通常あなたのresource tenantではなく相手のhome tenantで管理されています。管理対象デバイス必須のConditional Accessをそのまま適用すると、外部ユーザーが条件を満たせずブロックされることがあります。外部組織のdevice claimsを信頼するか、対象アプリだけ別ポリシーにするかを検討してください。(Microsoft Learn)
次に取るべきアクション
Microsoft Entra External IDのIdentity providers for workforce tenantsを読むときは、「どのIDプロバイダーを追加できるか」ではなく、「自社の外部共有モデルにどの認証方式を許可すべきか」という観点で確認することが重要です。
まず、現在のゲストユーザーと認証方式を棚卸しします。次に、招待権限、許可・ブロックドメイン、Conditional Access、Cross-tenant access settingsを確認します。最後に、SAML/WS-Fedの証明書期限、Google federationの対象ユーザー、Email one-time passcodeの扱いを運用ルールとして文書化します。
2026年4月更新版のポイントは、Microsoft Entra IDを既定のIDプロバイダーとして使いつつ、外部ユーザーの実態に合わせてIDプロバイダーを選び、MFAとアクセス制御で補完することです。外部共有は利便性だけで設計するとリスクが膨らみます。まずは「誰が、どのIDで、どのアプリに、どの条件でアクセスしているか」を可視化するところから始めてください。
コメント