Microsoft Entra External IDの2026年4月24日更新で、まず押さえるべき結論は「External IDの役割が、顧客向けCIAMと取引先・ゲスト向けB2Bコラボレーションの両方を扱う基盤として、改めて整理された」という点です。今回の公式ページ更新は、少なくとも公開されているGitHub差分を見る限り、本文に大きな機能追加を示す変更ではなく、更新日・AI利用メタデータ・Customer intentの整備が中心です。したがって、security admins、identity teams、compliance teamsが取るべき行動は「新機能対応」よりも、External IDをどの用途で使うのか、テナント構成・外部ユーザー管理・条件付きアクセス・監査観点を再点検することです。(Microsoft Learn)
Microsoft Entra External IDとは何か
Microsoft Entra External IDは、組織外のユーザーにアプリやリソースへ安全にアクセスさせるためのMicrosoft Entraの機能群です。対象となる外部ユーザーは、取引先、委託先、サプライヤー、ゲスト、一般消費者、法人顧客などです。ユーザーは自分の職場アカウント、学校アカウント、政府発行アカウント、GoogleやFacebookなどのソーシャルIDを使ってサインインできます。(Microsoft Learn)
重要なのは、External IDが単一の使い方だけを指す名称ではないことです。大きく分けると、次の2つの用途があります。
| 用途 | 主な対象 | 使う場面 | 管理上のポイント |
|---|---|---|---|
| 外部テナントでのExternal ID | 消費者、法人顧客、アプリ利用者 | 自社アプリにサインアップ、サインイン、CIAMを組み込む | 従業員ディレクトリと分けて顧客IDを管理する |
| ワークフォーステナントでのB2Bコラボレーション | 取引先、業務委託先、ゲストユーザー | Microsoft 365、SaaS、社内業務アプリを外部パートナーと共有する | 既存の従業員テナント内でゲストとして管理する |
この違いを曖昧にしたまま設計すると、あとから「顧客アカウントが従業員テナントに混在する」「ゲスト招待の権限が広すぎる」「監査対象のユーザー範囲が分からない」といった問題が起きやすくなります。
2026年4月24日更新で確認すべきポイント
Microsoft公式のMicrosoft Learnページ「Introduction to Microsoft Entra External ID」は、2026年4月24日に更新されています。GitHub上の該当コミットでは、ms.dateの更新、ai-usage: ai-assistedの追加、Customer intent表記の整理が確認できます。一方で、External IDの本文説明そのものに大きな差分がある更新ではありません。(Microsoft Learn)
このため、今回の更新を読むときは「新しい機能が追加された」と短絡的に受け取るより、MicrosoftがExternal IDの説明をどのように整理しているかを見るのが実務的です。
更新日だけで機能変更と判断しない
Microsoft Learnでは、ページの更新日が変わっていても、本文の大幅な仕様変更を意味するとは限りません。今回のExternal ID Overviewでも、公開差分を見る限り、本文の主要機能説明ではなくメタデータ更新が中心です。(GitHub)
運用チームは、次のように確認すると安全です。
| 確認項目 | 見る場所 | 判断の仕方 |
|---|---|---|
| 本文の機能説明が変わったか | Microsoft Learn本文 | 新しい機能名、制約、対象テナントの変更があるか確認する |
| 実際の差分があるか | GitHubのHistory、Commit | 本文差分か、メタデータ差分かを切り分ける |
| 管理画面やAPIに影響があるか | Microsoft Entra admin center、Microsoft Graph関連ドキュメント | 設定項目・API・ライセンス条件が変わっていないか確認する |
| 社内手順書を更新すべきか | 自社のID管理手順、監査資料 | 用語、判断基準、運用責任者の記述を見直す |
特にコンプライアンスチームは、更新日だけを根拠に「仕様変更あり」と記録するのではなく、差分の種類を残すべきです。今回のようにメタデータ中心の更新であれば、「本文上の主要仕様変更は確認できないが、公式ページの更新日が2026年4月24日に変更された」といった記録が適しています。
External IDで扱う2つの主要シナリオ
Microsoft Entra External IDの設計で最初に決めるべきことは、「誰に、何へ、どの権限でアクセスさせるのか」です。公式ページでも、External IDは顧客向けアプリの認証・CIAMと、ビジネスパートナー向けB2Bコラボレーションの両方を扱うものとして説明されています。(Microsoft Learn)
顧客向けアプリには外部テナントを使う
消費者向けアプリや法人顧客向けSaaSにサインアップ・サインイン機能を組み込む場合は、外部テナントでのExternal IDを使います。外部テナントは、従業員や社内業務アプリを管理するワークフォーステナントとは別に作成し、アプリ登録、顧客アカウント、サインアップ・サインインのユーザーフローを管理します。(Microsoft Learn)
たとえば、次のようなケースです。
- BtoCのモバイルアプリで、メールアドレスとワンタイムパスコードによるサインインを提供する
- 法人顧客向けポータルで、顧客企業のMicrosoft Entra IDやソーシャルIDを使ったログインを許可する
- サインアップ時に会社名、国・地域、利用規約への同意状態などを取得する
- アプリごとにブランドに合わせたサインイン画面を用意する
外部テナントでは、顧客の認証体験を作り込みやすい一方で、従業員用の権限管理とは別の設計が必要です。顧客アカウントを従業員テナントに混ぜないことで、管理対象、監査範囲、アクセス権限の境界が明確になります。
取引先との共同作業にはB2Bコラボレーションを使う
一方、社内のMicrosoft 365、SaaS、業務アプリ、SharePoint、Teamsなどを取引先や委託先と共有する場合は、ワークフォーステナントでB2Bコラボレーションを使います。B2Bコラボレーションでは、外部ユーザーは自分の資格情報で認証し、自社側ではゲストユーザーとしてユーザーオブジェクトを管理します。(Microsoft Learn)
たとえば、次のようなケースです。
- 委託先メンバーをTeamsに招待し、プロジェクトチャネルに参加させる
- 取引先にSharePointサイトへの限定アクセスを付与する
- 外部監査人に一時的に証跡確認用アプリへのアクセスを与える
- パートナー企業ごとに許可・拒否のポリシーを分ける
この場合、セキュリティ管理者が特に見るべきなのは、ゲスト招待の範囲、ドメイン許可・ブロック、クロステナントアクセス設定、条件付きアクセスです。B2Bでは「招待できること」と「認証・アクセスできること」が別の設定で制御されるため、片方だけ確認しても安全とは言えません。
ワークフォーステナントと外部テナントの違い
External IDで混乱しやすいのが、ワークフォーステナントと外部テナントの違いです。ワークフォーステナントは従業員、社内アプリ、組織リソースを管理する標準的なMicrosoft Entraテナントです。外部テナントは、消費者や法人顧客向けアプリを公開するためのExternal IDシナリオ専用のテナントです。(Microsoft Learn)
| 比較項目 | ワークフォーステナント | 外部テナント |
|---|---|---|
| 主な目的 | 従業員と社内リソースの管理 | 顧客向けアプリのID管理 |
| 外部ユーザーの扱い | ゲストユーザーとして管理 | 顧客アカウントとして管理 |
| 主な用途 | B2Bコラボレーション、Teams、SharePoint、社内SaaS共有 | CIAM、サインアップ、サインイン、顧客プロファイル管理 |
| 対象アプリ | Microsoft 365、SaaS、社内業務アプリなど | 自社が公開する顧客向けアプリ |
| 設計上の注意 | ゲスト権限、招待設定、クロステナントアクセスを厳格に管理する | 従業員ディレクトリと分離し、顧客データの取り扱いを明確にする |
判断基準はシンプルです。
外部の人に社内リソースを使わせるならワークフォーステナント、外部の人を自社アプリの顧客として扱うなら外部テナントです。
この判断を間違えると、アクセス制御だけでなく、ライフサイクル管理、データ保持、監査、同意管理、ヘルプデスク運用まで影響します。
security adminsが確認すべき設定
security adminsが今回の更新をきっかけに確認すべきなのは、External IDそのものの有効・無効ではなく、外部ユーザーがどの条件で入ってこられるかです。
クロステナントアクセス設定を棚卸しする
Microsoft EntraのB2Bコラボレーションでは、他のMicrosoft Entra組織との連携をクロステナントアクセス設定で管理できます。ここでは、受信・送信のB2Bコラボレーション、B2B direct connect、MFAやデバイスクレームを信頼するかどうかなどを制御します。(Microsoft Learn)
確認すべき観点は次の通りです。
| 観点 | 確認内容 | リスク |
|---|---|---|
| 既定設定 | すべての外部組織に対する既定許可・拒否 | 意図せず広い組織からアクセス可能になる |
| 組織別設定 | 主要パートナー企業に個別設定があるか | 例外設定が残り続ける |
| MFA信頼 | 相手テナントのMFAクレームを信頼するか | 相手側のMFA運用に依存する |
| デバイス信頼 | 準拠デバイスやハイブリッド参加デバイスのクレームを信頼するか | 端末管理水準の差がリスクになる |
| 対象スコープ | 全ユーザーか、特定ユーザー・グループ・アプリか | 過剰なアクセス許可につながる |
実務では、すべての外部組織に広く許可するより、よく連携する組織を個別に登録し、対象ユーザー・対象アプリを絞る設計が扱いやすくなります。
外部コラボレーション設定を見直す
外部コラボレーション設定では、誰がゲストを招待できるか、特定ドメインを許可・ブロックするか、ゲストユーザーのディレクトリ参照権限をどこまで制限するかを制御します。Microsoftの説明では、クロステナントアクセス設定は外部Microsoft Entraテナントとの認証可否を扱い、外部コラボレーション設定はゲスト招待の可否を扱うものとして整理されています。(Microsoft Learn)
よくある失敗は、クロステナントアクセス設定だけを確認して「外部アクセスは制御できている」と判断することです。実際には、招待を送れるユーザー範囲が広すぎると、不要なゲストが増えます。
おすすめは、次の順番で見直すことです。
| 手順 | 作業 | 目的 |
|---|---|---|
| 1 | 現在のゲスト招待権限を確認する | 一般ユーザーが自由に招待できる状態か把握する |
| 2 | ゲスト招待を許可するロールや部門を決める | 業務上必要な招待だけに絞る |
| 3 | 許可ドメイン・ブロックドメインを整理する | 取引先と競合・個人メールの扱いを明確にする |
| 4 | 定期的なゲスト棚卸しを設定する | 退職者、契約終了者、不要アカウントを減らす |
identity teamsが設計で押さえるべきこと
identity teamsは、External IDを「認証機能」としてだけ見ないことが重要です。実際には、ユーザーライフサイクル、アプリ登録、属性設計、サインイン方式、MFA、監査ログ、Graph APIによる自動化まで含めたID基盤として設計する必要があります。
顧客アカウントとゲストアカウントを混同しない
顧客向けアプリの利用者は、外部テナントで顧客アカウントとして管理します。一方、取引先や委託先は、ワークフォーステナントでB2Bゲストとして管理するのが基本です。(Microsoft Learn)
たとえば、次のように分けると判断しやすくなります。
| ユーザー例 | 推奨される扱い | 理由 |
|---|---|---|
| ECアプリの一般利用者 | 外部テナントの顧客アカウント | 社内リソースではなく顧客向けアプリを利用するため |
| SaaSを契約した法人顧客の担当者 | 外部テナントの顧客アカウント | アプリ利用者として管理するため |
| 開発委託先のエンジニア | B2Bゲスト | 社内プロジェクトリソースへ限定アクセスするため |
| 外部監査人 | B2Bゲスト | 期間限定で社内リソースを確認するため |
| 販売代理店の営業担当者 | 用途によって判断 | 顧客ポータル利用なら外部テナント、社内資料共有ならB2B |
特に「法人顧客」という言葉だけで判断しないことが大切です。法人顧客でも、自社SaaSにログインする利用者なら外部テナントが適しています。一方、共同プロジェクトで社内TeamsやSharePointを使う相手ならB2Bコラボレーションです。
サインイン方式を業務リスクに合わせて選ぶ
External IDでは、メールとパスワード、ワンタイムパスコード、GoogleやFacebookなどのソーシャルアカウント、Microsoft Entra ID、カスタムOIDC IDプロバイダーなど、複数のサインイン方式を組み合わせられます。(Microsoft Learn)
選定時は、ユーザー体験だけでなく、本人確認の強度、ヘルプデスク負荷、監査可能性を見てください。
| サインイン方式 | 向いているケース | 注意点 |
|---|---|---|
| メール＋パスワード | 一般的な顧客アプリ | パスワードリセットや漏えい対策が必要 |
| メールワンタイムパスコード | パスワード管理を避けたいゲスト・顧客 | メールアカウントの安全性に依存する |
| ソーシャルID | 消費者向けアプリ | 業務用途では本人確認や所属確認が弱くなりやすい |
| Microsoft Entra ID連携 | 法人顧客、パートナー企業 | 相手テナントの運用水準を考慮する |
| カスタムOIDC | 既存ID基盤との連携 | 設計・運用・障害時対応の責任分界を明確にする |
セキュリティ重視の業務アプリでは、ソーシャルIDだけに頼る設計は避けた方が無難です。反対に、消費者向けアプリで認証を厳しくしすぎると、登録離脱が増える可能性があります。リスクと使いやすさのバランスをアプリ単位で決めるべきです。
compliance teamsが注意すべき監査・統制ポイント
compliance teamsにとって、External IDの重要ポイントは「外部ユーザーが存在すること」ではなく、「外部ユーザーの目的、権限、期間、同意、削除が説明できること」です。
外部ユーザーの目的を記録できるようにする
B2Bゲストは、プロジェクトや契約が終わっても残り続けやすいアカウントです。招待時に目的や責任者を記録しないと、半年後に「このユーザーは誰か」「なぜアクセス権があるのか」を説明できなくなります。
最低限、次の情報を管理できるようにします。
| 管理項目 | 例 | 理由 |
|---|---|---|
| 招待理由 | 〇〇プロジェクトの設計レビュー | 監査時にアクセス目的を説明するため |
| 社内責任者 | プロジェクトオーナー、部門長 | 棚卸し時の確認先を明確にするため |
| 所属組織 | 取引先企業名、委託先名 | 契約・NDAとの紐づけに必要 |
| 有効期限 | 契約終了日、レビュー完了日 | 不要アカウントの残存を防ぐため |
| 付与権限 | 対象アプリ、グループ、SharePointサイト | 最小権限を確認するため |
Microsoft Entra entitlement managementを使うと、外部ユーザーのアクセス要求、割り当て、レビュー、有効期限管理を自動化できます。公式ページでも、外部ユーザーのアクセス管理をスケールさせる機能としてentitlement managementが紹介されています。(Microsoft Learn)
条件付きアクセスとMFAを外部ユーザーにも適用する
External IDでは、外部ユーザーに対しても条件付きアクセスやMFAを適用できます。外部テナントでは、サインアップ・サインインのユーザーフローにMFAを組み込めます。ワークフォーステナントでは、B2BコラボレーションやB2B direct connectユーザーに対して、従業員と同様に条件付きアクセスを適用できます。(Microsoft Learn)
注意すべきなのは、「外部ユーザーだから一律MFA」だけでは運用が破綻しやすいことです。次のようにリスク別に分けると現実的です。
| リスク | 対象例 | 推奨される制御 |
|---|---|---|
| 低 | 一般公開に近い情報を閲覧する顧客 | 基本的なサインイン、不審リスク時の追加認証 |
| 中 | 契約顧客向けポータル、限定資料 | MFA、条件付きアクセス、国・地域やアプリ単位の制御 |
| 高 | 社内ファイル、開発環境、管理画面 | MFA必須、デバイス条件、期限付きアクセス、アクセスレビュー |
| 極高 | 機密データ、管理者権限 | 原則として外部ユーザーへの直接付与を避け、例外承認を必須にする |
Azure AD B2C利用企業が見るべきポイント
Azure AD B2Cは、2025年5月1日以降、新規顧客による購入ができなくなっています。既存顧客は継続利用できますが、MicrosoftはMicrosoft Entra External IDを次世代のCIAMソリューションとして位置づけています。FAQでは、Azure AD B2Cのサポート継続や既存顧客向けの扱いについても説明されています。(Microsoft Learn)
既存のAzure AD B2C利用企業は、すぐに移行作業へ進む前に、次の棚卸しを行うべきです。
| 棚卸し項目 | 確認内容 |
|---|---|
| アプリ一覧 | Azure AD B2Cに依存しているWebアプリ、モバイルアプリ、API |
| ユーザーフロー | サインアップ、サインイン、パスワードリセット、MFA |
| カスタムポリシー | Identity Experience Frameworkを使った独自処理 |
| IDプロバイダー | Google、Facebook、Microsoft Entra ID、SAML、OIDCなど |
| 属性・クレーム | アプリが必要とする属性、トークンに含めるクレーム |
| 運用手順 | 障害対応、ユーザー削除、問い合わせ対応、監査ログ確認 |
| コスト・ライセンス | MAU、Premiumアドオン、M2M認証などの影響 |
特にカスタムポリシーを多用している場合は、単純な設定移行では済まない可能性があります。現行の認証体験をそのまま再現するのか、External IDの標準機能に合わせて設計を整理するのかを早めに決める必要があります。
実務でのチェックリスト
今回の2026年4月更新を受けて、各チームは次の順番で確認すると効率的です。
| 担当 | 最初に確認すること | 次のアクション |
|---|---|---|
| security admins | 外部ユーザーの入口がどこにあるか | クロステナントアクセス、外部コラボレーション設定、条件付きアクセスを確認 |
| identity teams | 顧客IDとゲストIDが分離されているか | 外部テナントとワークフォーステナントの使い分けを文書化 |
| compliance teams | 外部ユーザーの目的・期限・責任者が追跡できるか | アクセスレビュー、証跡、削除基準を整備 |
| app owners | アプリごとの認証方式が適切か | サインイン方式、MFA、属性収集、同意文言を確認 |
| help desk | 外部ユーザー問い合わせの窓口が明確か | パスワード、MFA、招待再送、退会・削除の対応手順を用意 |
ここで重要なのは、External IDの管理をIDチームだけに閉じないことです。外部ユーザーは、セキュリティ、アプリ、契約、個人情報保護、監査の境界にまたがります。小さな設定変更でも、別チームの統制に影響することがあります。
よくある失敗と回避策
外部ユーザーを一括りにしてしまう
「外部ユーザー」という言葉だけで設計すると、顧客、取引先、監査人、委託先が同じ扱いになります。これは危険です。
回避策は、外部ユーザーを次のように分類することです。
- 顧客ユーザー
- 法人顧客ユーザー
- B2Bゲスト
- 一時的な監査・保守ユーザー
- 管理権限を持つ外部支援ユーザー
分類ごとに、認証方式、MFA、アクセス期間、承認者、削除ルールを決めます。
招待できる人を広くしすぎる
B2Bコラボレーションでは、招待権限が広いとゲストユーザーが増え続けます。誰が招待したか分からないゲストが残ると、監査対応が難しくなります。
回避策は、招待できるユーザーを業務上必要なロールや部門に限定し、プロジェクト終了時にゲストを棚卸しすることです。重要なアプリでは、entitlement managementやアクセスレビューを使って、承認と期限管理を仕組み化します。
外部テナントを作らず顧客IDを従業員テナントに寄せる
初期構築を急ぐと、顧客向けアプリのユーザーを従業員テナント側で扱ってしまうことがあります。しかし、顧客数が増えると、ディレクトリ管理、監査、権限設計が複雑になります。
回避策は、顧客向けアプリであれば早い段階で外部テナントを検討することです。外部テナントは、アプリ登録、顧客アカウント、ユーザーフローを従業員環境から分離して管理するための構成です。(Microsoft Learn)
MFAを設定して満足してしまう
MFAは重要ですが、MFAだけでExternal IDのリスクは解決しません。不要なゲストが残っている、過剰なグループ権限がある、外部ドメイン制御が甘い、といった問題はMFAでは防げません。
回避策は、MFAを「入口対策」と捉え、アクセス権、期限、レビュー、ログ監査と組み合わせることです。
今回の更新から取るべき次の行動
Microsoft Entra External IDの2026年4月24日更新は、本文に大きな新機能が追加されたというより、External IDの位置づけを再確認するためのタイミングとして捉えるのが実務的です。特に、顧客向けCIAMとB2Bコラボレーションを同じ「外部ID」として雑に扱わず、テナント構成とアクセス制御を分けて設計することが重要です。
まずは、次の3つを実施してください。
1つ目は、現在の外部ユーザーを「顧客」「法人顧客」「B2Bゲスト」「一時ユーザー」に分類することです。2つ目は、ワークフォーステナントと外部テナントの使い分けが設計書に明記されているか確認することです。3つ目は、クロステナントアクセス設定、外部コラボレーション設定、条件付きアクセス、アクセスレビューをまとめて棚卸しすることです。
External IDは、外部ユーザーに便利なログイン体験を提供するだけの機能ではありません。組織外の人にどこまでアクセスを許可し、どのように証跡を残し、いつ権限を終わらせるかを管理するためのIDガバナンス基盤です。2026年4月の更新をきっかけに、自社の外部ID管理が「使える状態」だけでなく「説明できる状態」になっているかを確認しましょう。
コメント