JAEN
tech#entra-id#external-id#ciam#azure#authentication#b2c

Microsoft Entra External ID 入門（2026年版）— 社内向け Entra ID との違い・構成・アプリ実装

公開 👁 —
Microsoft Entra External ID 入門（2026年版）— 社内向け Entra ID との違い・構成・アプリ実装

この記事を書こうと思ったきっかけ

Azure を使っていると、いつのまにか Entra ID テナントが前提になっています。Azure サブスクリプションはテナントに紐づくし、Microsoft 365 も同じテナントの上に乗る。そのため社内システムを作るときは、「認証は Entra ID でいいよね」で自然に話が終わります。

ところが、社外の一般ユーザー向けサービスを作ろうとした瞬間に話が変わります。

ここで出てくるのが Azure AD B2C や Microsoft Entra External ID です。ただ、この 2 つの関係が分かりにくい。名前も似ているし、B2C は今後どうなるのかも気になります。

この記事では、「社内向けの Entra ID」と「外部ユーザー向けの External ID」の違いを出発点に、External ID の利用目的・構成方法・アプリケーションからの使い方を、公式ドキュメントの記述をもとに整理します。

目次

まず整理: Entra ID テナントは「社内の入れ物」

最初に、いつも使っている Entra ID の立ち位置を確認しておきます。

公式ドキュメントによると、すべての Azure サブスクリプションは、1 つの Entra ID テナントと信頼関係を持ちます。サブスクリプションはこのテナント（ディレクトリ）を使って、セキュリティプリンシパルやデバイスの認証・認可を行います。

ここで押さえておきたいのが、次の非対称な関係です。

Azure サブスクリプションと Microsoft 365 が同じ workforce テナントを信頼している関係図Azure サブスクリプションリソースと Azure RBAC のスコープMicrosoft 365 / Intuneサービスとライセンス信頼信頼workforce テナント（Entra ID）社員アカウント・グループ・社内アプリ1 つのサブスクリプションが信頼できるディレクトリは 1 つだけ
図1: Azure も Microsoft 365 も、同じ workforce テナントを信頼している

役割分担も明確に分かれています。

対象役割
サブスクリプションAzure リソースと Azure ロール割り当ての「スコープ」
テナントサインインに使う ID を保持する「ディレクトリ」
Azure ロールサブスクリプション内の Azure リソースへのアクセス制御
Entra ID ロールユーザー・グループ・ドメインなどディレクトリ資源へのアクセス制御

そして Microsoft 365 や Intune も、同じように Entra ID テナントの上に乗ります。公式ドキュメントでは、この社員・社内業務アプリ・組織のリソースを管理するテナント構成を workforce テナントと呼んでいます。Azure・Intune・Microsoft 365 などのサブスクリプションにサインアップしたときに自動作成される、いわゆる「普通のテナント」がこれです。

つまり、Azure も M365 も社内アプリも、同じ workforce テナントに集約されているのが一般的な姿です。社内向けアプリの認証を Entra ID で済ませられるのは、この構造のおかげです。

外部ユーザーの受け入れ方は 2 通りある

では、社外のユーザーはどう扱うのか。ここで Microsoft Entra External ID が登場します。

External ID は「1 つの機能」というより、組織外の人を扱うためのソリューション群です。そして重要なのは、どちらのテナント構成で使うかによって、想定シナリオがはっきり分かれるという点です。

社員・取引先・一般顧客それぞれのテナント構成を比較した図社員workforce テナント内部メンバーとして管理社内アプリ・M365追加のテナントは不要取引先・パートナーworkforce テナントゲストとして招待自社アプリを共有B2B コラボレーション一般消費者・法人顧客external テナントセルフサービス登録自社アプリのみExternal ID（CIAM）外部ユーザーは「自テナントに招く」か「別テナントで受ける」かの 2 通り
図2: 相手が誰かによって、使うテナント構成が変わる
観点workforce テナントの External IDexternal テナントの External ID
主なシナリオ社員が社外のビジネスパートナーと共同作業する自社アプリを一般消費者・法人顧客へ公開する
想定ユーザー取引先、パートナー、ベンダー自社アプリのコンシューマー・顧客
ユーザー管理社員と同じテナント内にゲストとして管理顧客向けに作成した別テナントで管理
代表機能B2B コラボレーションセルフサービスのサインアップ／サインイン
SSO の範囲Microsoft 365 を含む Entra ID 連携アプリその外部テナントに登録したアプリのみ
既定のブランドMicrosoft デザインをベースにカスタマイズMicrosoft ブランドを含まない中立デザイン

ポイントは 2 つあります。

1 つ目は、取引先との共同作業なら、新しいテナントは要らないということ。既存の workforce テナントで B2B コラボレーションを使い、ゲストとして招待すれば済みます。この方式は次の章で詳しく見ます。

2 つ目は、一般消費者や法人顧客に自社アプリを公開するなら、external 構成の新しいテナントを作るということです。公式ドキュメントでも、External ID を顧客向けアプリに使う場合、最初に作るべきリソースが external 構成のテナントだと明記されています。このテナントは workforce テナントとは明確に分離された別物です。

もう 1 つ実務的に効いてくる違いとして、外部テナントのユーザーは既定の権限が制限されている点があります。顧客がサインアップして作られるユーザーは、社員アカウントと同じ感覚のディレクトリ権限を持ちません。

⚠️ 外部テナントでは、Microsoft 365 など Microsoft の SaaS への SSO はサポートされません。あくまで「自社アプリ向けの認証基盤」であり、社内向けテナントの代わりにはならない、と理解しておくのが安全です。

B2B コラボレーション: 自社テナントにゲストを招く

外部テナントの話に入る前に、もう一方の選択肢を押さえておきます。実務では、こちらで足りるケースがかなり多いからです。

B2B コラボレーションは、自社の workforce テナントに社外の人をゲストとして招き、自社のアプリやサービスを使ってもらう仕組みです。公式ドキュメントでも、自社データの管理を保ちながら、アプリやサービスを社外のゲストと共有できる機能として説明されています。相手が Microsoft Entra ID を持っていなくても、情報システム部門がなくても利用できます。

招待から利用までの流れ

B2B コラボレーションで社外ユーザーを招待し自社アプリを使ってもらうまでの流れ招待招待メールか直接リンク引き換え自分の資格情報でゲスト作成UserType = Guestアプリ利用自社アプリ・M365招待は期限切れしない。初回の引き換え時にプライバシー条項への同意が求められる条件付きアクセスなどのポリシーは、招待した側のテナントで評価される
図3: B2B コラボレーションは「招待して、引き換えてもらう」だけで始められる

流れを分解すると次のようになります。

  1. 招待する: 管理者が Entra 管理センターからゲストを招待します。ディレクトリ、グループ、アプリのいずれかに対して招待でき、招待した時点でユーザーは Guest の種類で Entra ID に追加されます
  2. 引き換えてもらう: ゲストは招待メールの引き換え URL か、共有アプリへの直接リンクからアクセスします。招待は期限切れしません
  3. 同意する: 初回の引き換え時に、プライバシー条項と利用規約への同意が求められます。同意状態は PendingAcceptance から Accepted へ変わります
  4. アプリを使ってもらう: ゲストは自分の資格情報のまま、共有されたアプリにサインインします

ユーザーオブジェクトは自社ディレクトリに作られ、UPN に #EXT# 識別子が含まれるのが特徴です。

ゲストに使わせられるもの

ここが今回の主題に直結する部分です。B2B コラボレーションでは、Microsoft のアプリだけでなく、自社のアプリも共有できます。公式ドキュメントの比較表でも、External ID が提供するアクセス先として「Microsoft アプリケーション、または SaaS アプリやカスタム開発アプリを含む自社アプリケーション」と明記されています。

つまり、次のようなケースは B2B コラボレーションの守備範囲です。

招待したゲストのサインイン方法

ゲストは「自分が普段使っている ID」でサインインできます。利用できる ID プロバイダーは次のとおりです。

複数の方法が使える場合にどれを優先するかは、クロステナントアクセス設定の「引き換え順序」で調整できます。また、どのテナントの相手と B2B コラボレーションできるかも、クロステナントアクセス設定で制御します。

管理と課金の考え方

外部テナントとの使い分け

判断軸B2B コラボレーション外部テナント
相手取引先・パートナー・委託先一般消費者・法人顧客
想定人数数人〜数千人規模大規模・不特定多数
相手の ID会社のアカウントを持つことが多いメールやソーシャル ID が中心
管理場所既存の workforce テナント新規の external テナント
Microsoft 365 の共有できるできない
サインイン画面Microsoft デザインが基本中立デザイン。自社ブランドへ変更可
始めやすさテナント追加が不要ですぐ始められるテナント設計から必要

迷ったときの目安はシンプルです。「相手は仕事の関係者か、それとも自社サービスのお客様か」。前者なら B2B コラボレーション、後者なら外部テナントを検討する、という順で考えると外しにくくなります。

Azure AD B2C と External ID の関係

ここが一番聞かれるところだと思います。2026 年 7 月時点の公式ドキュメントの記述を整理します。

新規購入は終了、既存利用は継続

あわせて、Azure AD External Identities P2 は Azure AD B2C テナントで提供終了となっており、P2 専用機能は利用できません。P2 テナントは 2026 年 3 月末までに順次 P1 へ切り替えられ、P1 価格で課金されます。なお、この P2 提供終了と B2C の新規販売終了は別々の事項として説明されています。

これから作るなら External ID

つまり、状況はこう整理できます。

公式ドキュメントでも、B2C から External ID への移行ガイダンスが用意されています。また、B2C のカスタムポリシーについては「構築と管理が難しすぎる」というフィードバックを受けて、新しい External ID プラットフォームではカスタムポリシーを不要にする方向で簡素化を進めていること、既存カスタムポリシーの移行パスを提供予定であることが述べられています。

💡 なお、名称の変遷で混乱しやすいのですが、従来の Azure AD B2B コラボレーションも現在は External ID の一部（External ID B2B コラボレーション）として位置づけられています。管理場所は workforce テナント内の Entra 管理センターのままです。

External ID は何のために使うのか

ここまでを踏まえると、External ID の外部テナントを選ぶ目的は次のように整理できます。

逆に、次のケースでは外部テナントは適しません。

構成方法 1: 外部テナントを作る

ここからは、外部テナントを使う前提で進めます。全体の流れは次の 5 ステップです。

外部テナントの作成からアプリ実装までの 5 ステップの図① テナント作成② サインイン方法を設定③ ユーザーフロー作成④ アプリ登録⑤ MSAL で実装場所（国／地域）は作成時に決まり、後から変更できない
図4: 外部テナントを使うときの全体の流れ

外部テナントの作成手順は、公式ドキュメントで次のように案内されています。

前提条件

作成手順

  1. Microsoft Entra 管理センター（entra.microsoft.com）にサインインする
  2. Entra ID > 概要 > テナントの管理へ移動する
  3. 作成を選ぶ
  4. テナントの種類で External を選び、続行する
  5. 初回であれば、Azure サブスクリプション不要の 30 日間試用テナントも選択できる
  6. 基本タブで、テナント名・ドメイン名・国／地域を入力する
  7. サブスクリプションタブで、サブスクリプションとリソースグループを選ぶ
  8. 確認と作成で作成する

いくつか、後から変更できない・つまずきやすいポイントがあります。

作成後は、Entra 管理センターの Directories + subscriptions から対象ディレクトリへ切り替え、テナント概要でテナント名・テナント ID・プライマリドメインを確認できます。これらの値は、後のアプリ実装でそのまま使います。

構成方法 2: サインイン方法とユーザーフロー

外部テナントができたら、次は「顧客がどうサインアップ／サインインするか」を決めます。ここで使うのがユーザーフローです。

ユーザーフローでは、次のような要素を設定します。

選べるサインイン方法

ローカルアカウント

OTP を選ぶと、ユーザーはサインインのたびにメールで届く一時コードを入力します。パスワードを保存しない運用にできるのが利点です。

フェデレーション

ソーシャル ID などにフェデレーションする場合、既定ではユーザーはまず Microsoft のサインインページを見てから ID プロバイダーを選びます。サインイン URL に domain_hint パラメーターを付けると、対象プロバイダーのページへ直接飛ばせます（例: domain_hint=google）。

運用上の注意点

実際に運用を始めると効いてくる仕様が 3 つあります。

  1. サインイン方法の変更は、新規ユーザーにしか影響しません。既存ユーザーは、最初にサインアップした方法を使い続けます。たとえば「メール + パスワード」から「メール + OTP」へ変更しても、既存ユーザーは引き続きパスワードを求められます
  2. SMS は第 1 要素認証やセルフサービスパスワードリセットには使えません。外部テナントでは、SMS は第 2 要素の検証として、追加コストで利用できます
  3. フェデレーションはブラウザ委任認証でのみ利用可能です。後述のネイティブ認証は、ローカルアカウント（メール + OTP、メール + パスワード）のみをサポートします

アプリケーションからの利用方法

ここからは実装側の話です。まず、アプリ・外部テナント・ID プロバイダーの関係を図で押さえておきます。

自社アプリと外部テナント、ID プロバイダーの間でトークンが発行される流れの図自社アプリWeb / SPA / モバイル① 認証要求④ トークン外部テナントユーザーフローアプリ登録23ID プロバイダーメール + ワンタイムパスコードメール + パスワードGoogle / Facebook / Appleフェデレーションはブラウザ委任認証でのみ利用できる
図5: アプリは外部テナントへ認証を任せ、結果をトークンで受け取る

まず認証方式を決める

公式の計画ガイドでは、アプリ登録の前に認証方式を決めることが推奨されています。選択肢は 2 つです。

方式内容向いているケース
ブラウザ委任認証Microsoft がホストするサインインページへリダイレクトする幅広いプラットフォーム対応、システムブラウザーでの SSO、保守コストを抑えたい
ネイティブ認証アプリ内にサインイン UI を実装し、MSAL やネイティブ認証 API を直接呼ぶUI を完全に制御したい（開発とセキュリティの責任は増える）

前述のとおり、ソーシャルログインやフェデレーションが必要ならブラウザ委任認証を選ぶ必要があります。

アプリを登録する

外部テナントにアプリを登録して、Entra ID との信頼関係を作ります。設定内容は選んだ認証方式で変わります。

設定ブラウザ委任ネイティブ認証
リダイレクト URI必須（アプリのサインインコールバック）Web フォールバックとして必要な場合のみ
パブリッククライアントフロー不要有効化する

リダイレクト URI は、認証リクエストで送る値と、アプリ登録に登録した値が完全一致している必要があります。ここが食い違うと invalid_request でリダイレクト URI の不一致エラーになります。

MSAL の設定は authority が違う

実装で一番差が出るのが authority です。workforce テナントと外部テナントで形が変わります。

workforce テナントの場合は次の形です。

authority: `${cloudInstance}${tenantId}`;

外部テナントの場合は、テナント固有のサブドメインを含む ciamlogin.com を指します。

authority: `https://${tenantSubdomain}.ciamlogin.com/`;

tenantSubdomain には、プライマリドメインのサブドメイン部分を入れます。たとえばプライマリドメインが contoso.onmicrosoft.com なら contoso です。

カスタム URL ドメインでブランドを統一する

外部テナントでは、カスタム URL ドメインを使えます。これを設定すると、ユーザーは認証中も ciamlogin.com へ飛ばされず、自社ドメインに留まります。

この場合、MSAL 側は次のように設定します。clientId にはアプリケーション（クライアント）ID、authority のパスにはテナント ID を入れます。

const msalConfig = {
  auth: {
    clientId: '11112222-bbbb-3333-cccc-4444dddd5555',
    authority: 'https://login.contoso.com/aaaabbbb-0000-cccc-1111-dddd2222eeee',
    knownAuthorities: ['login.contoso.com'],
  },
};

knownAuthorities を指定しないと、MSAL が既定のホストへリダイレクトしてしまう点に注意してください。なお、カスタム URL ドメインは workforce テナントではサポートされません。外部テナント固有の機能です。

認可とトークンのカスタマイズ

アプリ側の認可については、workforce テナントと同様の仕組みが使えます。

さらに、カスタム認証拡張を使うと、トークン発行の直前に外部システムのクレームを追加できます。「認証フローに自社のビジネスロジックを差し込みたい」という要件は、ここで実現します。

料金の考え方

External ID の課金は MAU（Monthly Active Users: 月間アクティブユーザー） ベースです。暦月内に認証したユニークな外部ユーザー数で数えます。

押さえておきたい点は次のとおりです。

正しく課金し機能を利用するには、テナントを Azure サブスクリプションにリンクする必要があります。MAU が無料枠内なら請求は 0 円ですが、コスト分析には使用状況データが表示されます。

⚠️ 最新の価格は変動します。金額の判断が必要な場合は、必ず公式の価格ページで確認してください。

選定時のチェックリスト

最後に、判断に使えるポイントをまとめます。

まとめ

「社内は Entra ID、社外は External ID」と一言でまとめると簡単に聞こえますが、実際には社外の中でも「仕事の関係者」と「自社サービスのお客様」で道が分かれます。ここを最初に決めておくと、後の設計がかなり楽になるはずです。

公式情報源