Microsoft Entra External IDの外部テナントを使うべきか迷ったら、まず「相手が誰か」ではなく「何をさせたいか」で判断します。社外パートナーを社内リソースへ招待して共同作業させるなら従業員テナントのB2Bコラボレーション、消費者やビジネス顧客に自社アプリへサインアップ・サインインしてもらうなら外部テナントが基本です。Microsoft Learnの機能比較では、従業員テナントと外部テナントで、認証方法、アプリ登録、条件付きアクセス、ログ、課金、ガバナンス機能に差があることが示されています。(Microsoft Learn)
特に2026年5月末時点で管理者が見落としやすいのは、外部テナントのUser Insightsが2026年8月31日に廃止予定で、Azure MonitorやLog Analyticsへの移行準備が必要になっている点です。この記事では、Microsoft Entra External IDの外部テナント機能を、変更点・影響範囲・設定確認・移行時の注意点に分けて整理します。(Microsoft Learn)
Microsoft Entra External IDの外部テナントとは
Microsoft Entra External IDには、大きく分けて2つの利用形態があります。1つは従業員テナントで外部ゲストを扱うB2Bコラボレーション、もう1つは外部テナントで顧客向けアプリのID管理を行うCIAMです。
従業員テナントは、社員、社内アプリ、Microsoft 365やAzureなどの組織リソースを管理するための標準的なMicrosoft Entra IDテナントです。一方、外部テナントは、消費者やビジネス顧客にアプリを公開し、サインアップ、サインイン、MFA、ユーザーフロー、アプリ登録を管理するためのテナントです。外部テナントは従業員テナントとは分離された構成で、顧客向けID基盤として扱うのが前提です。(Microsoft Learn)
| 判断したいこと | 適したテナント | 理由 |
|---|---|---|
| 取引先をTeams、SharePoint、社内SaaSに招待したい | 従業員テナント | B2Bコラボレーションで外部ゲストを社内リソースに招待する用途に合う |
| 一般ユーザーに自社Webアプリへ会員登録してもらいたい | 外部テナント | セルフサービスサインアップや顧客向け認証フローを前提に設計されている |
| B2B顧客企業の担当者にSaaSへログインしてもらいたい | 多くの場合は外部テナント | 顧客向けアプリの認証・認可・サインアップ体験を管理しやすい |
| 社員・管理者・社内業務アプリを管理したい | 従業員テナント | 組織内ID、Microsoft 365、Azureリソース管理が主目的 |
| 既存のAzure AD B2Cから新しい顧客ID基盤へ移行したい | 外部テナント | Microsoft Entra External IDが次世代の顧客ID基盤として位置づけられている |
外部ユーザーという言葉だけで判断すると失敗しやすくなります。たとえば、社外の人でも「社内のSharePointに一時的にアクセスする人」は従業員テナントのゲストです。一方、企業の外部担当者であっても「自社SaaSの顧客ユーザーとしてログインする人」は外部テナントの対象になります。
2026年5月末時点で押さえるべき主な変更点と影響範囲
Microsoft Entra External IDの外部テナントでは、単に「Azure AD B2Cの後継」と考えるだけでは不十分です。アプリ登録、権限設計、ログ基盤、サブスクリプション、MFA、移行方式まで確認する必要があります。
| 確認項目 | 影響を受ける人 | 実務上の対応 |
|---|---|---|
| User Insightsの廃止予定 | 管理者、運用担当、データ分析担当 | 2026年8月31日までにAzure Monitor、Log Analytics、Microsoft Graphのサインイン・監査ログAPIへ移行する |
| 外部テナントと従業員テナントの機能差 | テナント設計者、セキュリティ管理者 | ID Protection、ID Governance、条件付きアクセス、ログ保持、アプリ登録の差分を設計段階で確認する |
| アプリ登録の単一テナント前提 | 開発者、アプリ所有者 | 外部テナント用に新規アプリ登録を作成し、Authority URLやトークン検証設定を見直す |
| MFA方式とSMS課金・有効化 | セキュリティ管理者、サポート担当 | Email OTP、SMS、Passkeyの利用条件を確認し、SMS利用時は有効なサブスクリプションと対象地域を確認する |
| Azure AD B2Cからの移行 | ID基盤担当、開発チーム | 標準移行、JITパスワード移行、HSCモードのどれを使うかを早期に決める |
| ログと監視の再設計 | SOC、監査、運用担当 | サインインログ、監査ログ、サインアップログ、Azure Monitor連携を前提に監視設計を作る |
User Insightsについては、Microsoft Learnで2026年8月31日の廃止が示されており、Application user activity dashboardsとMicrosoft Graphのreports/userInsights/*ベータエンドポイントは、廃止後にデータを返さなくなると説明されています。既存のPower BIレポートや独自ダッシュボードがこのAPIに依存している場合は、単なる画面変更ではなく、データ取得元の移行作業が必要です。(Microsoft Learn)
従業員テナントと外部テナントの機能差
Microsoft Entra External IDの外部テナントは、従業員テナントと同じMicrosoft Entra基盤の上にありますが、利用できる機能は同一ではありません。外部テナントで使える機能、制限される機能、プレビュー扱いの機能を分けて確認することが重要です。
| 項目 | 従業員テナント | 外部テナント |
|---|---|---|
| 主な用途 | 社員、社内アプリ、社内リソース、外部ゲストとの共同作業 | 消費者・ビジネス顧客向けアプリの認証とアクセス管理 |
| 外部IDの使い方 | B2Bコラボレーションでゲストを招待 | 顧客がセルフサービスサインアップや招待でアプリにアクセス |
| ローカルアカウント | 組織内メンバー向け | 顧客ユーザー、管理者作成の内部アカウントなどで利用 |
| Microsoft Entra ID Protection | 利用可能 | 公式比較では外部テナントは対象外 |
| Microsoft Entra ID Governance | 利用可能 | 公式比較では外部テナントは対象外 |
| アプリ登録のアカウント種類 | シングルテナント、マルチテナント、個人Microsoftアカウントなどを選択可能 | 常に「この組織ディレクトリ内のアカウントのみ」の単一テナント前提 |
| Authority URL | login.microsoftonline.com | <tenant-name>.ciamlogin.com |
| アプリケーションギャラリー | 利用可能 | アプリケーションギャラリーカタログは利用不可 |
| 監査ログ・サインインログ | 利用可能 | 従業員テナントと同様に利用可能 |
| サインアップログ | 対象外 | プレビューとして提供 |
| MAU課金 | B2Bゲストなど外部ユーザーが対象 | 外部テナント内の全ユーザーがUserTypeやロールに関係なく対象 |
外部テナントでは、顧客向けアプリの認証体験に必要な機能が中心に提供されます。一方で、従業員テナントで当然のように使っていたID ProtectionやID Governance、アプリケーションギャラリー、プロビジョニングログなどがそのまま使えるとは限りません。公式比較でも、外部テナントでは一部機能が「Not available」とされています。(Microsoft Learn)
管理者が最初に確認すべき設定
テナントタイプを誤って選ばない
最初に確認すべきなのは、外部ユーザーをどのリソースへアクセスさせるかです。社内のMicrosoft 365、Azure、業務SaaSへ招待するなら従業員テナントのB2Bが基本です。顧客に自社アプリへ登録してもらい、メール、SMS、ソーシャルID、パスキーなどを使った顧客向けログイン体験を作るなら外部テナントを選びます。
外部テナントは、Microsoft Entra管理センターで作成できます。Microsoft Learnでは、外部テナントはMicrosoft Entra管理センターから作成し、Azure portalは従業員テナント作成のみをサポートすると説明されています。既存の運用手順がAzure portal前提になっている場合は、管理者向け手順書も更新しておきましょう。(Microsoft Learn)
管理者アカウントとロールを分離する
外部テナントにも管理者ロールはありますが、顧客ユーザーと管理者アカウントを混在させる設計は避けるべきです。外部テナントは顧客IDを扱うため、管理者アカウントは通常の顧客アカウントとは別に管理し、緊急アクセス用アカウントも準備します。
特に条件付きアクセスでMFAを必須化する場合、すべてのユーザーに一括適用してから除外アカウントを作るのではなく、先に緊急アクセス用アカウントを定義してからポリシーを有効化する流れが安全です。MFA設定の公式手順でも、条件付きアクセスポリシーの対象にAll usersを含め、緊急アクセスまたはブレークグラスアカウントを除外する手順が示されています。(Microsoft Learn)
MFA方式をユーザー体験とコストの両面で選ぶ
外部テナントでは、MFAの第2要素としてEmail one-time passcode、SMS-based authentication、Passkey（FIDO2）などが利用できます。ただし、SMSは第1要素ではなくMFAの第2要素として使われ、アドオン機能として有効なサブスクリプションとのリンクが必要です。サブスクリプションが期限切れまたはキャンセルされると、SMSを使った認証ができなくなる可能性があります。(Microsoft Learn)
実務では、次の基準で選ぶと判断しやすくなります。
| 認証方式 | 向いているケース | 注意点 |
|---|---|---|
| Email OTP | メールアドレス中心の一般的な顧客ログイン | メール到達遅延や迷惑メール判定への対策が必要 |
| SMS MFA | 電話番号を本人確認に使いたいサービス | コスト、通信事業者依存、国・地域ごとの有効化、テレフォニー不正対策を確認 |
| Passkey（FIDO2） | フィッシング耐性を高めたいサービス | 対応端末、ユーザー教育、リカバリー導線の設計が必要 |
| ソーシャルID連携 | サインアップの手間を減らしたいB2Cサービス | 利用するIDプロバイダーごとの審査、同意画面、メール属性の扱いを確認 |
SMSは便利ですが、全ユーザーに一律で必須化すると、電話番号未登録、海外番号、通信遅延、サブスクリプション問題でサインイン不能になるリスクがあります。まずは重要アプリや高リスク操作に限定し、サポート窓口の対応フローまで含めて検証するのが現実的です。
開発者が確認すべきアプリ登録と認証フロー
Authority URLはciamlogin.comに変更する
外部テナントのアプリでは、OpenID ConnectやOAuth 2.0のAuthority URLとして<tenant-name>.ciamlogin.comを使います。従業員テナント向けのlogin.microsoftonline.comを流用すると、トークン発行、Issuer検証、SSO、リダイレクト処理で問題が起きる可能性があります。公式比較でも、外部テナントのAuthority URLは<tenant-name>.ciamlogin.com形式を使うと説明されています。(Microsoft Learn)
アプリ側では、少なくとも次の項目を確認します。
| 確認項目 | 確認内容 |
|---|---|
| Authority / issuer | ciamlogin.comのIssuerを受け入れるようにする |
| Client ID | 外部テナント側で新しく登録したアプリのIDを使う |
| Redirect URI | 本番、検証、ローカル開発環境のURIを外部テナントのアプリ登録に設定する |
| Logout URL | フロントチャネルログアウトURLを設定し、セッション破棄を確認する |
| Scope / API権限 | Microsoft Graphの許可範囲と自社APIの委任権限を見直す |
| Token claims | 既存アプリが参照する属性、グループ、アプリロールが同じ形で発行されるか確認する |
| Custom domain | カスタムURLドメインを使う場合、SSOのためにURLドメインを統一する |
外部テナントでは、アプリ登録のサポートされるアカウント種類は常に単一テナントです。また、API権限ではMicrosoft Graphのoffline_access、openid、User.Read、自社APIの委任権限などに制限があり、組織全体の同意は管理者のみが実行できるとされています。(Microsoft Learn)
ROPCに依存しているアプリは見直す
OAuth 2.0やOpenID Connectのフローも、従業員テナントと外部テナントで完全に同じではありません。公式比較では、OpenID Connect、認可コードフロー、PKCE、デバイス認可フロー、On-behalf-of flowなどは外部テナントでもサポートされる一方、Resource Owner Password Credentialsは外部テナントでは「No」とされています。モバイルアプリではネイティブ認証の利用が案内されています。(Microsoft Learn)
ROPCは、ユーザー名とパスワードをアプリが直接扱う古い実装で残っていることがあります。外部テナントへ移行する場合は、認可コードフロー＋PKCE、ネイティブ認証、ブラウザベースのサインインに置き換える計画を立てましょう。
グループとアプリロールの使い方を確認する
外部テナントでも、アプリロールやセキュリティグループを使ったアクセス制御は可能です。ただし、一部の操作はMicrosoft Graph経由のみです。たとえば、アプリロールをグループに割り当てる操作や、グループをアプリケーションまたはサービスプリンシパルへ追加する操作は、公式ドキュメント上でMicrosoft Graphのみとされています。(Microsoft Learn)
開発者が注意すべきなのは、トークンに出るグループ情報です。外部テナントのグループオプション要求は、グループのオブジェクトIDに制限されると説明されています。既存アプリがグループ名やオンプレミス由来の属性を前提に認可している場合は、アプリロールまたはアプリ側の権限テーブルへ置き換える方が安定します。(Microsoft Learn)
ログ・監視・レポートで確認すべきこと
外部テナントでは、監査ログとサインインログは従業員テナントと同様に利用できます。さらに、セルフサービスサインアップイベントを記録するサインアップログがプレビューとして提供されています。一方、プロビジョニングログは外部テナントでは利用不可とされ、アクティビティログの保持は7日と示されています。長期保管や監査対応が必要な環境では、Microsoft Entra管理センターの画面確認だけに頼らず、早めにエクスポート先を設計する必要があります。(Microsoft Learn)
User Insightsを使っている場合は、特に急いで棚卸しを行いましょう。Microsoft Learnでは、User Insightsのダッシュボードとreports/userInsights/*ベータエンドポイントは2026年8月31日に廃止され、履歴ダッシュボードデータは自動移行されないと説明されています。推奨代替はAzure Monitor with Log Analyticsで、SigninLogsやAuditLogsを使ってビューを再作成する方法です。(Microsoft Learn)
監視移行の実務チェックリスト
| 作業 | 確認ポイント |
|---|---|
| 依存関係の棚卸し | Microsoft Entra管理センターのUser Insights、Power BI、Graph API、社内ETLを洗い出す |
| ログ送信先の決定 | Log Analyticsワークスペース、Microsoft Sentinel、Event Hub、既存SIEMを選ぶ |
| 代替クエリ作成 | SigninLogs、AuditLogsを使ってDAU、MAU、MFA成功率、失敗率を再現する |
| アラート設計 | サインアップ失敗急増、SMS MFA失敗、国・地域の異常、CAPTCHA発生増加を監視する |
| 保存期間の確認 | 監査要件に合わせてLog Analytics側の保持期間を設定する |
| 移行リハーサル | 2026年8月31日より前に、旧レポートと新レポートの数値差を比較する |
ログ移行は、画面を置き換えるだけではありません。経営レポート、セキュリティ監視、サポート窓口の問い合わせ調査、MAU課金の把握にも影響します。特に外部テナントは顧客向けサービスで使われるため、ログ欠損は障害解析や不正検知の遅れにつながります。
課金とサブスクリプションの注意点
Microsoft Entra External IDは、月間アクティブユーザー数、つまりMAUをベースにした課金モデルです。従業員テナントのB2BコラボレーションではUserType=Guestの外部ユーザーが主な対象ですが、外部テナントではUserTypeや管理者ロールの有無にかかわらず、外部テナント内の全ユーザーにMAU課金が適用されます。(Microsoft Learn)
外部テナントの課金で失敗しやすいのは、管理者アカウント、テストユーザー、サポート用アカウントも外部テナント内で認証すればMAUに含まれる点です。大量テストや負荷試験を行う場合は、本番サブスクリプションの課金に影響しないよう、検証テナントとテスト計画を分けておくと安全です。
また、外部テナントはサブスクリプション管理機能を持たないため、外部テナントをMicrosoft Entra従業員テナントが所有するサブスクリプションにリンクする必要があります。外部テナントにサブスクリプションの所有権を移すことはできないと説明されているため、請求管理者、Azure管理者、ID管理者の責任分界も明確にしておきましょう。(Microsoft Learn)
Azure AD B2Cから移行する場合の判断基準
Azure AD B2Cは、2025年5月1日以降、新規顧客向けに購入できなくなっています。既存のAzure AD B2Cテナントがすぐに使えなくなるという意味ではありませんが、新規構築や長期運用を考えるなら、Microsoft Entra External IDへの移行計画を避けて通れません。(Microsoft Learn)
移行方式は、主に標準移行とHigh Scale Compatibility（HSC）モードに分かれます。標準移行は多くのテナント向けで、新しい外部テナントを作成し、ユーザー、資格情報、アプリケーションを移行します。HSCモードは、約500万以上のディレクトリオブジェクトを持つ非常に大規模なAzure AD B2Cテナント向けで、Azure AD B2CとExternal IDを同じテナント内で並行運用しながら段階的にアプリを移行する方式です。ただし、HSCモードにはソーシャルIDプロバイダー、パスキー、年齢ゲーティング、管理ポータル体験、条件付きアクセスなどに機能ギャップがあると説明されています。(Microsoft Learn)
| 移行方式 | 向いているケース | 注意点 |
|---|---|---|
| 標準移行 | 多くのAzure AD B2Cテナント、機能互換性を重視するケース | アプリごとにExternal IDエンドポイントへ切り替える必要がある |
| 一括ユーザー移行＋アプリ切り替え | パスワード再設定を許容できる、または別途移行できるケース | 切り替え日までにユーザー通知とサポート体制が必要 |
| 一括ユーザー移行＋JITパスワード移行 | 既存パスワードを維持し、ユーザー負担を減らしたいケース | 事前にユーザーを外部テナントへ作成し、移行フラグとカスタム認証拡張を構成する |
| Azure AD B2C起点の移行 | 既存B2C側で段階的に資格情報を収集したいケース | B2CカスタムポリシーとREST API連携の設計が必要 |
| HSCモード | 非常に大規模で、一括移行リスクが高いケース | 機能制限を許容できるかを事前に検証する必要がある |
移行で最も重要なのは、テナントだけを作っても移行は終わらないという点です。アプリケーションごとにエンドポイント、クライアントID、リダイレクトURI、トークン検証、スコープ、カスタムクレーム、ログアウト処理を変える必要があります。第三者が所有するアプリや、顧客が独自に登録したアプリがある場合は、早い段階でアプリ所有者を巻き込まないと切り替えが止まります。Microsoft Learnでも、移行はアプリケーションレベルの変更を伴い、すべてのアプリを更新するまで完了できないと説明されています。(Microsoft Learn)
JITパスワード移行で確認すべき実装ポイント
JITパスワード移行は、ユーザーが初回サインインしたタイミングで既存IDプロバイダーに資格情報を検証し、Microsoft Entra External IDへパスワードを移行する方式です。ユーザーに一斉パスワードリセットを求めずに移行できるため、顧客体験の悪化を抑えたいサービスに向いています。(Microsoft Learn)
実装の流れは次のように考えると分かりやすくなります。
| 段階 | 作業内容 | 注意点 |
|---|---|---|
| 事前準備 | 外部テナントにユーザーアカウントを作成する | ユーザーが存在しないとJITサインインは成立しない |
| 移行フラグ設定 | 移行対象ユーザーにtoBeMigrated: trueなどの拡張属性を設定する | 対象外ユーザーと混在しないように棚卸しする |
| カスタム認証拡張 | OnPasswordSubmitでAzure FunctionなどのHTTPSエンドポイントを呼び出す | URLはMicrosoft Graph、Entraサービス、旧IdPの対話型ログインURLではなく、顧客管理のHTTPSエンドポイントにする |
| パスワード検証 | 旧IdPで資格情報を検証する | REST APIのブルートフォース対策、レート制限、監査ログを実装する |
| 移行結果返却 | MigratePassword、UpdatePassword、Retry、Blockなどを返す | 弱いパスワード、ロック済みアカウント、誤入力の扱いを決める |
| 切り替え後 | 以後はExternal IDで認証する | 旧IdP停止前に未移行ユーザーを抽出する |
JIT移行では、パスワードは公開キーで暗号化され、秘密鍵はAzure Key Vaultに保持される設計が示されています。Azure FunctionのマネージドIDにKey Vaultアクセスを付与し、秘密鍵をコード内に埋め込まないことが前提です。認証フローの中心に独自エンドポイントが入るため、通常のAPIよりも厳格な監視、アクセス制御、デプロイ承認を行うべきです。(Microsoft Learn)
展開前に行うべき確認手順
外部テナントの導入は、設定画面で機能を有効化するだけでは安全に進みません。テナント、アプリ、認証、ログ、運用を1つのリリース計画として扱う必要があります。
| フェーズ | 管理者の確認 | 開発者の確認 |
|---|---|---|
| 設計 | 従業員テナントか外部テナントかを決める。顧客、ゲスト、管理者の区分を定義する | アプリの認証方式、利用フロー、既存クレーム依存を棚卸しする |
| 構築 | 外部テナント、管理者ロール、緊急アクセス、サブスクリプションリンクを設定する | アプリ登録、Redirect URI、Authority URL、API権限、ログアウトURLを設定する |
| セキュリティ | MFA、条件付きアクセス、SMS利用、CAPTCHA、不正サインアップ対策を検証する | トークン検証、Issuer、Audience、Scope、アプリロールをテストする |
| 監視 | サインインログ、監査ログ、サインアップログ、Log Analytics連携を構成する | アプリログとEntraログを相関できるようにリクエストIDやユーザーIDを記録する |
| 移行 | Azure AD B2Cや旧IdPからの移行方式を決める | JIT移行、カスタム認証拡張、旧IdP連携、切り戻し手順を実装する |
| 本番化 | 段階展開、サポート窓口、障害時の連絡経路を用意する | カナリアリリース、負荷試験、ログ監視、ロールバック手順を確認する |
実務では、本番切り替え前に「新規登録」「既存ユーザーのサインイン」「パスワードリセット」「MFA登録」「MFA失敗」「ログアウト」「セッション失効」「管理者ロックアウト」「監査ログ確認」までを一連のテストシナリオに入れてください。認証基盤の障害は、アプリの一部機能ではなくログイン全体を止めるため、通常の機能テストよりも広い観点が必要です。
失敗しやすいポイント
「外部ユーザーだから外部テナント」と決めてしまう
外部ユーザーという言葉だけでテナントを選ぶと、社内コラボレーション用途まで外部テナントに寄せてしまうことがあります。社内リソースへのゲストアクセスは従業員テナント、顧客向けアプリのCIAMは外部テナント、という区分を最初に固定しましょう。
既存アプリのlogin.microsoftonline.com設定を残す
外部テナントではciamlogin.comを使います。Authority URLだけでなく、Issuer検証、メタデータURL、ログアウトURL、Cookieドメイン、カスタムドメイン設定まで確認しないと、サインインは成功してもSSOやサインアウトで不具合が出ることがあります。
User Insights廃止を画面変更だけと考える
User Insightsの廃止は、管理センターのダッシュボードが変わるだけではありません。Microsoft Graphのreports/userInsights/*ベータエンドポイントに依存したPower BIや社内レポートも影響します。2026年8月31日より前に、Log AnalyticsやGraphのサインイン・監査ログAPIへ移行してください。(Microsoft Learn)
SMS MFAを有効化して満足してしまう
SMS MFAは、サブスクリプション、地域、通信事業者、テレフォニー不正、CAPTCHA、コストの影響を受けます。サインインできないユーザーの代替手段、サポート本人確認、MFA再登録手順を先に作っておくべきです。
Azure AD B2Cのカスタムポリシーをそのまま移せると思い込む
Azure AD B2CのCustom Policy（IEF）で作り込んだロジックは、External IDで完全に1対1対応するとは限りません。Microsoft Learnでも、カスタムポリシーロジックはカスタム認証拡張で再作成が必要で、完全な同等性は保証されないと説明されています。(Microsoft Learn)
まず取り組むべき次のアクション
Microsoft Entra External IDの外部テナントを検討している管理者は、最初にユーザーを「社員」「社外ゲスト」「顧客ユーザー」「管理者」に分類してください。そのうえで、社内リソースへの共同作業なのか、顧客向けアプリのログイン基盤なのかを切り分けます。
すでに外部テナントを使っている場合は、次の4点を優先して確認しましょう。
- User Insights、Power BI、Graph APIレポートが2026年8月31日以降も継続できるか
- アプリのAuthority URL、Issuer検証、Redirect URI、ログアウト設定が外部テナント向けになっているか
- MFA、SMS、Passkey、条件付きアクセス、緊急アクセスアカウントが本番運用に耐えるか
- Azure AD B2Cや旧IdPからの移行で、アプリ単位の切り替え計画と切り戻し手順があるか
外部テナントは、顧客向けID基盤をMicrosoft Entraの標準モデルに近づけられる有力な選択肢です。ただし、従業員テナントと同じ感覚で設計すると、機能差、課金、ログ、認証フロー、移行方式でつまずきます。まずは小さなアプリで外部テナントの認証、MFA、ログ、トークン、監視を検証し、その結果をもとに本番展開計画へ落とし込むのが安全です。
コメント