Microsoft Entra External IDの外部テナントは、顧客向けアプリやSaaSにサインアップ／サインイン機能を追加するためのCIAM基盤です。今回まず押さえるべき結論は、従業員用テナントのゲスト管理とは分けて考え、外部ユーザー専用のテナント、アプリ登録、ユーザーフロー、MFA、監視基盤を設計し直す必要があるという点です。
特に管理者と開発者が急いで確認すべきなのは、User Insightsの廃止予定、Azure AD B2Cからの移行方針、アプリ登録方式、認証方式、条件付きアクセス、ログ監視です。Microsoft Learnでは、User InsightsとMicrosoft Graphのreports/userInsights/*ベータエンドポイントが2026年8月31日に廃止されるため、Azure Monitor with Log AnalyticsまたはMicrosoft Graphのサインイン／監査ログAPIへの移行を計画するよう案内されています。(Microsoft Learn)
Microsoft Entra External IDの外部テナントとは
Microsoft Entra External IDの外部テナントは、企業の従業員ではなく、アプリを利用するコンシューマーやビジネス顧客のIDを管理するための専用テナントです。Microsoft公式ドキュメントでは、External IDはセルフサービス登録、パーソナライズされたサインイン体験、顧客アカウント管理などのCIAM機能を提供し、Microsoft Entra IDのセキュリティ、コンプライアンス、スケーラビリティの利点も利用できると説明されています。(Microsoft Learn)
誤解しやすいのは、「外部ユーザー」という言葉だけでB2Bゲスト招待と同じものだと考えてしまうことです。Microsoft Entra External IDには、従業員テナントで外部パートナーと共同作業するB2Bコラボレーションと、外部テナントで顧客向けアプリのID管理を行うCIAMの両方のシナリオがあります。顧客向けアプリを公開する場合は、従業員ディレクトリとは別の外部テナントでアプリユーザーを管理する構成が基本です。(Microsoft Learn)
| 観点 | 従業員テナントの外部ID | 外部テナントのExternal ID |
|---|---|---|
| 主な用途 | 取引先、協力会社、ゲストとの共同作業 | 顧客向けアプリ、SaaS、会員サイトの認証 |
| ユーザーの位置づけ | 従業員テナント内のゲストユーザー | 外部テナント内の顧客アカウント |
| 代表例 | Teams、SharePoint、業務アプリへのゲスト招待 | EC、予約サイト、B2Bポータル、モバイルアプリ |
| 設計の中心 | 招待、テナント間アクセス、権限管理 | ユーザーフロー、サインアップ、MFA、ブランド設定 |
| 注意点 | 社内リソースへのアクセス制御 | 顧客体験、本人確認、ログ監視、移行計画 |
今回の公式情報で重要な変更点
Microsoft Entra External IDの外部テナント概要で特に重要なのは、「CIAM基盤としての位置づけがより明確になったこと」と「周辺機能の移行・廃止対応が必要になっていること」です。
User Insightsは2026年8月31日に廃止予定
もっとも実務影響が大きいのは、Application user activity dashboards、いわゆるUser Insightsの扱いです。Microsoft Learnでは、User Insightsが2026年8月31日に廃止され、その後はApplication user activity dashboardsとMicrosoft Graphのreports/userInsights/*ベータエンドポイントがデータを返さなくなると説明されています。代替として、Azure Monitor with Log Analytics、またはMicrosoft Graphのサインインログ／監査ログAPIへの移行が推奨されています。(Microsoft Learn)
これは、アプリの利用状況をダッシュボードで見ている管理者だけでなく、Power BIや独自レポートでreports/userInsights/*を参照している開発者にも影響します。ユーザーのログイン数、MFA成功率、アクティブユーザー数を運用KPIにしている場合は、廃止日までにログ取得元を切り替える必要があります。
| 確認対象 | 影響 | 対応 |
|---|---|---|
| Application user activity dashboards | 2026年8月31日以降に利用できなくなる予定 | Azure Monitor、Log Analytics、Workbookへ移行 |
Graph reports/userInsights/* | ベータエンドポイントがデータを返さなくなる予定 | signIns、directoryAuditsなどのログAPIへ置き換え |
| Power BIレポート | データソースが切れる可能性 | クエリ、権限、更新スケジュールを再設計 |
| 運用レポート | MAU、MFA、サインイン傾向の可視化に影響 | KQLまたはGraph APIベースで再構築 |
Azure AD B2Cの新規購入停止を前提に移行を考える
Azure AD B2Cは、2025年5月1日以降、新規顧客が購入できない状態になっています。Microsoft公式ドキュメントでは、既存のAzure AD B2C顧客に対して、Microsoft Entra External IDへの移行計画を参照するよう案内しています。(Microsoft Learn)
既存のAzure AD B2Cを利用している組織は、すぐに全機能が停止するという意味ではありません。ただし、新規開発やリニューアルでは、今後のCIAM基盤としてMicrosoft Entra External IDを前提に設計するのが現実的です。既存B2C環境を維持する場合でも、ユーザー移行、アプリのエンドポイント変更、カスタムポリシー相当の再実装、ログ監視の切り替えを早めに洗い出す必要があります。
影響範囲は管理者・開発者・セキュリティ担当で異なる
Microsoft Entra External IDの外部テナントは、単に管理センターで新しいテナントを作るだけの変更ではありません。アプリの認証方式、トークン検証、ユーザー管理、監査ログ、MFA、ブランド体験まで影響します。
| 役割 | 主な影響 | 最初に確認すべきこと |
|---|---|---|
| Microsoft Entra管理者 | テナント作成、管理者ロール、MFA、条件付きアクセス、ログ | 外部テナントを従業員テナントと分離できているか |
| アプリ開発者 | OIDC/OAuth、SAML、リダイレクトURI、トークン検証 | アプリ登録とAuthority URLをExternal ID向けに変更できるか |
| セキュリティ担当 | 不正登録、SMS MFA悪用、監査、WAF連携 | サインアップ不正対策と監視先を定義しているか |
| 運用担当 | アカウント作成、ロック解除、問い合わせ対応 | 顧客アカウントと管理者アカウントの運用ルールがあるか |
| 事業部門 | サインアップ体験、規約同意、離脱率 | 収集属性と同意文言が過不足ないか |
外部テナントでまず確認すべき基本構成
外部テナントには、顧客アカウントを保存するディレクトリ、アプリ登録、ユーザーフロー、拡張機能、サインイン方法、暗号化キーなどの構成要素があります。Microsoft Learnでは、外部テナントに顧客の資格情報とプロファイルデータを保存するディレクトリ、OIDCまたはSAMLを使うアプリ登録、セルフサービス登録やパスワードリセットを含むユーザーフローなどが含まれると説明されています。(Microsoft Learn)
アプリ登録はOIDC中心、SAMLはEnterprise applicationsで扱う
外部テナントでは、アプリ登録によってMicrosoft Entra IDとアプリの信頼関係を作ります。OIDCベースのアプリは通常のアプリ登録で扱いますが、SAMLアプリはEnterprise applications機能を使って登録する点に注意が必要です。(Microsoft Learn)
開発者が見落としやすいのは、既存のAzure AD B2Cや従業員テナントの設定値をそのまま流用しようとすることです。外部テナント向けアプリでは、Authority URLやリダイレクトURI、発行者、スコープ、トークン内のクレームを確認し直してください。
外部テナントのOIDC/OAuthフローでは、MSALがトークンを要求するAuthority URLとして<tenant-name>.ciamlogin.com形式を使用するよう公式ドキュメントで示されています。(Microsoft Learn)
{
"AzureAd": {
"Authority": "https://<tenant-subdomain>.ciamlogin.com/",
"ClientId": "<application-client-id>"
}
}実装時は、login.microsoftonline.comを使っていた既存コードが残っていないかを検索してください。認証は成功しているように見えても、想定外のテナントやエンドポイントを参照していると、SSO、サインアウト、トークン検証で問題が出ます。
ユーザーフローは「最初に集める情報」を絞る
外部テナントのユーザーフローでは、サインアップ、サインイン、パスワードリセットの体験を構成します。ユーザーフローでは、利用できるサインイン方法、外部IDプロバイダー、サインアップ時に収集する属性、ブランドや言語設定を指定できます。(Microsoft Learn)
実務では、最初のサインアップ画面で多くの項目を集めすぎると離脱率が上がります。たとえばB2Cアプリなら、初回はメールアドレス、パスワード、氏名程度に抑え、住所や会社情報は購入時や申請時に取得する設計が向いています。一方、B2B顧客向けポータルでは、会社名、部署、国または地域、利用目的を初回に取ることで、承認や権限付与の自動化につなげやすくなります。
| アプリ種別 | 初回サインアップで集める情報の例 | 後で集める情報の例 |
|---|---|---|
| 一般消費者向けアプリ | メール、氏名、同意チェック | 住所、電話番号、支払い情報 |
| B2B顧客ポータル | メール、氏名、会社名、国・地域 | 部署、契約番号、利用ロール |
| 会員制メディア | メール、表示名、関心カテゴリ | 詳細プロフィール、通知設定 |
| 金融・保険系アプリ | メール、氏名、本人確認導線 | 本人確認書類、追加属性、リスク判定 |
認証方式はブラウザー委任かネイティブ認証かを選ぶ
Microsoft Entra External IDでは、ブラウザー委任認証とネイティブ認証という2つのアプローチがあります。公式ドキュメントでは、ブラウザー委任認証はMicrosoftホストのサインインページへリダイレクトし、Microsoft Entraが認証フロー全体を処理する方式、ネイティブ認証はMSAL SDKまたはAPIを使ってアプリ内にサインインUIを構築する方式と説明されています。(Microsoft Learn)
| 判断基準 | ブラウザー委任認証 | ネイティブ認証 |
|---|---|---|
| 実装負荷 | 低い | 高い |
| セキュリティ責任 | Microsoft側の管理範囲が広い | アプリ側の責任が増える |
| UI自由度 | ブランド設定の範囲で調整 | アプリ内で細かく制御可能 |
| 向いているケース | Web、一般的な業務アプリ、短期導入 | モバイルアプリ、UX重視の消費者アプリ |
| 注意点 | リダイレクト体験を受け入れる必要 | 資格情報を扱う設計と保守が重要 |
迷った場合は、まずブラウザー委任認証を基準に検討するのが安全です。公式ドキュメントでも、ブラウザー委任認証はMicrosoftがサインイン面を管理するため、フィッシングや資格情報窃取への露出を減らせる、より安全な選択肢と説明されています。一方、ネイティブ認証では開発チームが資格情報の取り扱いに関するベストプラクティスを守る責任を負います。(Microsoft Learn)
管理者が確認すべきセキュリティ設定
外部テナントは顧客が直接触れる認証基盤です。社内ユーザーだけの環境よりも、ボット登録、SMS不正利用、クレデンシャルスタッフィング、アカウント乗っ取りのリスクを意識する必要があります。
MFAはアプリ単位・リスク単位で設計する
Microsoft Entra External IDはMicrosoft Entra MFAと統合され、サインアップやサインイン体験に追加の認証要素を要求できます。公式ドキュメントでは、すべてのユーザーとアプリを対象にMFAを有効化する例や、複数アプリのうち特定アプリだけにMFAを要求する例が示されています。(Microsoft Learn)
実務では、すべての場面でMFAを必須にすれば安全というわけではありません。低リスクの閲覧系アプリではMFAを緩め、高リスクの操作、たとえば契約変更、支払い情報変更、個人情報閲覧、管理者操作ではMFAを要求する設計が現実的です。
| 操作 | 推奨される制御 |
|---|---|
| 初回登録 | CAPTCHA、メールOTP、必要最小限の属性収集 |
| 通常ログイン | パスワードまたはOTP、リスクに応じたMFA |
| 個人情報の変更 | MFA必須 |
| 支払い情報の変更 | MFA必須、監査ログ確認 |
| 管理者による顧客アカウント操作 | 管理者MFA、ロール分離、監査ログ |
| SMS OTP多用 | 使用量監視、不正検知、代替認証手段の用意 |
条件付きアクセスは外部テナントの制限を踏まえる
Microsoft Entraの条件付きアクセスは、ユーザー、アプリ、場所、デバイスなどのシグナルをもとにアクセスを制御する仕組みです。外部テナントでもMFA要求、アクセスブロック、パスワードリセット要求、セッション制御などを利用できますが、従業員テナントと同じ前提で全機能が使えるとは限りません。外部テナントの機能比較では、条件付きアクセスや利用条件ポリシー、ログ、アプリ登録に関する違いが整理されています。(Microsoft Learn)
条件付きアクセスを設計するときは、次の順で確認すると失敗しにくくなります。
| 手順 | 確認内容 | 失敗しやすいポイント |
|---|---|---|
| 現状把握 | どのアプリに誰がアクセスするか | 顧客ユーザーと管理者を同じポリシーで扱う |
| リスク分類 | 個人情報、決済、契約情報の有無 | 重要操作と通常閲覧を区別しない |
| MFA設計 | どの条件でMFAを出すか | 全ユーザー一律MFAで離脱率が上がる |
| 除外設計 | 緊急用管理者、運用アカウント | 除外が広すぎて穴になる |
| 検証 | テストユーザーでサインアップから退会まで確認 | ログインだけ試して本番投入する |
開発者が確認すべき実装ポイント
外部テナントへの対応では、管理センター側の設定だけでなく、アプリ側のコード修正が必要になることがあります。特にAzure AD B2Cや従業員テナント向けに作ったアプリを移行する場合は、認証エンドポイント、アプリ登録、トークン検証、クレーム、サインアウト処理を確認してください。
アプリ登録はシングルテナントを基本にする
外部テナントのアプリ登録では、サポートされるアカウント種類に注意が必要です。機能比較では、外部テナントでは「この組織ディレクトリ内のアカウントのみ」、つまりシングルテナント構成を使用するよう示されています。(Microsoft Learn)
マルチテナントアプリとして設計していた既存アプリをそのまま移行しようとすると、想定した顧客アカウントがサインインできない、管理者同意の動きが異なる、トークンの発行者が変わるといった問題が起きます。新規構築では、まず外部テナント専用のアプリ登録を作り、開発・検証・本番で登録を分ける運用をおすすめします。
トークンとクレームは「アプリの認可」に直結する
External IDでは、ユーザー属性やカスタム属性をトークンに含め、アプリ側で認可判断に使えます。公式ドキュメントでは、外部システムからクレームを追加するためにカスタム認証拡張機能を使えると説明されています。(Microsoft Learn)
ただし、トークンに何でも入れるのは避けるべきです。トークンサイズが大きくなり、アプリ間で不要な個人情報が渡る原因になります。実務では、アプリが画面表示やアクセス制御に本当に必要な属性だけを含めます。
| クレーム候補 | 含める判断 | 注意点 |
|---|---|---|
| ユーザーID | 多くのアプリで必要 | メールアドレスをID代わりにしない |
| メールアドレス | 通知や表示に必要な場合のみ | 変更される可能性を考慮 |
| 国・地域 | 法令、表示制御、提供可否に使う場合 | 自己申告か検証済みかを区別 |
| 会員ランク | 認可や表示制御に使う場合 | アプリ側DBとの整合性を確認 |
| 契約番号 | 原則トークンに入れすぎない | 必要ならAPI側で参照 |
| 規約同意フラグ | 初回導線制御に有効 | 同意日時とバージョンも別途管理 |
Azure AD B2Cから移行する場合の注意点
既存のAzure AD B2CからMicrosoft Entra External IDへ移行する場合、単純な「テナントコピー」では済みません。Microsoftの移行計画ドキュメントでは、多くの顧客には標準移行が推奨され、非常に大規模なB2CテナントではHigh Scale Compatibility、いわゆるHSCモードが選択肢になると説明されています。HSCモードは約500万以上のディレクトリオブジェクトを持つ既存Azure AD B2C顧客向けの特殊な選択肢です。(Microsoft Learn)
| 移行方式 | 向いているケース | 注意点 |
|---|---|---|
| 標準移行 | 多くのAzure AD B2C利用組織 | 新しいExternal IDテナントへユーザー、アプリ、設定を移す |
| JITパスワード移行を含む標準移行 | パスワードを事前に完全移行しにくい場合 | 移行期間、失敗時対応、パスワードリセット導線が必要 |
| HSCモード | 約500万以上のディレクトリオブジェクトを持つ大規模環境 | 機能制限があり、アプリ移行は自動ではない |
HSCモードでは、Azure AD B2CとMicrosoft Entra External IDを同じテナント内で並行稼働させ、既存アプリはB2Cエンドポイントを使いながら、新規または移行済みアプリをExternal IDエンドポイントへ段階的に移せます。ただし、アプリの移行は利用者側が実施する必要があり、自動的に移動されるわけではありません。(Microsoft Learn)
移行計画では、次の棚卸しを最初に行ってください。
| 棚卸し項目 | 確認内容 |
|---|---|
| アプリ一覧 | Web、SPA、モバイル、API、SAMLアプリをすべて洗い出す |
| 認証方式 | OIDC、OAuth、SAML、カスタムポリシー、ネイティブ認証の有無 |
| ユーザー属性 | 必須属性、カスタム属性、規約同意、会員ランク |
| IDプロバイダー | Google、Facebook、Apple、Microsoft Entra ID、カスタムOIDC |
| パスワード移行 | 事前移行かJIT移行か、失敗時のリセット導線 |
| トークン検証 | issuer、audience、署名キー、クレーム名の変更 |
| ログ・監視 | User Insights依存、Graph依存、SIEM連携 |
| サポート体制 | ログイン不可、MFA変更、アカウント削除依頼への対応 |
User Insights廃止に向けた移行手順
User Insightsを使っている場合は、2026年8月31日を待たずに移行作業を始めるべきです。廃止後は過去のダッシュボードデータが自動移行されないため、必要な履歴は事前にエクスポートまたは再取得できる設計にしておく必要があります。Microsoft Learnでは、User Insightsに依存するダッシュボード、Power BIレポート、アプリ登録を棚卸しし、Azure MonitorまたはMicrosoft GraphのアクティビティログAPIで再構築するよう案内されています。(Microsoft Learn)
| フェーズ | 作業 | 完了条件 |
|---|---|---|
| 棚卸し | User Insights画面、Power BI、Graph呼び出しを洗い出す | 依存レポート一覧がある |
| ログ設計 | SigninLogs、AuditLogs、必要なKQLを決める | 代替指標が定義されている |
| 権限設計 | Log Analytics、Graph API、閲覧者ロールを見直す | 最小権限で参照できる |
| 実装 | Workbook、Power BI、API連携を作り直す | 旧レポートと同等の指標が出る |
| 並行運用 | 旧User Insightsと新レポートを比較 | 差分理由を説明できる |
| 切り替え | 運用手順書、通知、監視アラートを更新 | 廃止後も運用が継続できる |
KPIを再設計する際は、「見られる数値」ではなく「判断に使う数値」を残すことが重要です。たとえば、単純なサインイン回数よりも、MFA失敗率、SMS送信ブロック数、国・地域別の異常増加、新規登録後の初回利用率のほうが、セキュリティと事業改善の両方に役立ちます。
展開前に確認したいチェックリスト
Microsoft Entra External IDの外部テナントを本番投入する前に、次の項目を確認してください。
| チェック項目 | 確認ポイント |
|---|---|
| テナント分離 | 従業員用テナントと顧客用外部テナントを混同していないか |
| 管理者アカウント | 緊急用管理者、MFA、ロール分離が設計されているか |
| アプリ登録 | OIDC/SAML、リダイレクトURI、シークレット、証明書を確認したか |
| Authority URL | <tenant-name>.ciamlogin.com形式を使っているか |
| ユーザーフロー | サインアップ、サインイン、パスワードリセットを通しで検証したか |
| 収集属性 | 初回登録で必要最小限に絞っているか |
| 規約同意 | 同意文言、リンク、同意バージョンの管理方法があるか |
| MFA | 高リスク操作にMFAを要求しているか |
| 条件付きアクセス | 外部テナントで利用可能な条件と制御を確認したか |
| ログ監視 | Azure Monitor、Log Analytics、SIEM連携を準備したか |
| User Insights移行 | 2026年8月31日の廃止前に代替レポートを用意したか |
| 移行計画 | Azure AD B2C利用中の場合、標準移行かHSCか判断したか |
| 障害対応 | ログイン不可、MFA変更、アカウント削除依頼の手順があるか |
よくある失敗と回避策
外部テナントをB2Bゲスト招待の延長で設計してしまう
顧客向けアプリのID管理では、従業員テナントのゲストユーザー管理とは考え方が違います。B2Bは社内リソースへの共同作業が中心ですが、外部テナントは顧客体験、セルフサービス登録、アプリ単位の認証、スケール、ログ監視が中心です。
回避策は、最初の設計書で「このユーザーは従業員か、取引先ゲストか、顧客アカウントか」を明確に分けることです。ユーザー種別が曖昧なまま進めると、ロール設計、サポート窓口、データ保持、同意管理で後から混乱します。
サインアップ時の属性を増やしすぎる
マーケティングや営業の要望をそのまま入れると、初回登録フォームが長くなります。顧客向けアプリでは、登録完了までの摩擦が大きいほど離脱しやすくなります。
回避策は、属性を「認証に必要」「認可に必要」「法務・同意に必要」「後で聞けばよい」に分類することです。初回は認証と最低限の同意に絞り、追加情報は利用開始後の自然なタイミングで収集します。
User Insightsの廃止をレポート担当だけの問題にする
User Insightsの廃止は、単なるダッシュボードの置き換えではありません。Graph APIを使った自動レポート、セキュリティ監視、MFA利用状況の可視化、事業KPIにも影響します。
回避策は、管理者、セキュリティ担当、データ分析担当、アプリ開発者で依存先を共同確認することです。Power BIだけでなく、バッチ処理、監視アラート、経営レポート、CS向けダッシュボードも確認してください。
Azure AD B2Cのカスタムポリシーをそのまま移せると考える
Azure AD B2CでIdentity Experience Frameworkや複雑なカスタムポリシーを使っている場合、Microsoft Entra External IDに一対一で移せるとは限りません。移行計画ドキュメントでも、カスタムポリシーロジックはカスタム認証拡張機能で再作成する必要があり、一対一の互換性は保証されないと説明されています。(Microsoft Learn)
回避策は、既存ポリシーをコードやXMLの単位ではなく、業務要件の単位に分解することです。「どの条件で何を判定し、どのクレームを発行し、どの画面へ進めるのか」を整理すれば、External IDのユーザーフロー、カスタム属性、カスタム認証拡張で再設計しやすくなります。
管理者と開発者が次に取るべき行動
Microsoft Entra External IDの外部テナント対応で最初にやるべきことは、新機能を試すことではなく、現在の認証・ユーザー管理・ログ監視の依存関係を棚卸しすることです。
まず、顧客向けアプリがある場合は、外部テナントで管理すべきユーザーと、従業員テナントで管理すべきゲストを分けます。次に、アプリ登録、Authority URL、ユーザーフロー、MFA、条件付きアクセス、ログ出力先を確認します。Azure AD B2Cを使っている場合は、標準移行かHSCモードかを判断し、アプリ単位で移行計画を作ります。
最後に、User Insightsを利用している環境では、2026年8月31日の廃止日より前にAzure Monitor with Log AnalyticsまたはMicrosoft GraphのログAPIへ移行してください。認証基盤は、問題が起きてから直すと利用者影響が大きい領域です。小さな検証用アプリで外部テナント、ユーザーフロー、ログ監視を一通り確認し、本番アプリへ段階的に展開するのが安全です。
コメント