Microsoft Entra External ID の「External テナント（顧客向け）」で、他社の Microsoft Entra ID テナント利用者にサインインしてもらいたい――ところが、ワークフォース テナント同士のように“何もしなくても連携できる”わけではなく、設計でつまずくことがあります。この記事では、OIDC で直結できない理由と、現実的な連携パターンを整理します。
まず整理：External テナントとワークフォース テナントは「用途が別物」
同じ Microsoft Entra のテナントでも、ワークフォース テナントとExternal テナント（External ID：顧客向け）は前提が違います。ワークフォースは「社員・協業（B2B）」が主戦場、External は「顧客/消費者・取引先向けアプリの CIAM」が主戦場です。
| 観点 | ワークフォース テナント | External テナント（顧客向け） |
|---|---|---|
| 主目的 | 社員の業務利用、社内アプリ、B2B コラボレーション | 顧客/消費者/取引先向けアプリの CIAM（External ID 専用） |
| 外部ユーザーの基本アプローチ | B2B 招待・自己サインアップ（ゲスト）でコラボ | ユーザー フロー（サインアップ/サインイン）を中心に設計 |
| 他テナントとの“組み込み連携” | Microsoft Entra テナント同士の B2B が前提で整備されている | 「顧客サインイン」中心。B2B と同等の自動連携は前提外になりやすい |
| クロステナント機能 | cross-tenant access / B2B Direct Connect / cross-tenant sync などを設計に組み込みやすい | cross-tenant sync は利用不可（ワークフォースとの差分として明記） |
External テナントで「ワークフォース同士でできること」をそのまま期待するとズレが出ます。まずは“External は CIAM、ワークフォースは B2B/業務”と割り切って設計するのが近道です。
結論：External テナントから「別の Entra テナント」を OIDC IdP にして直結はできない
External テナントでカスタム OIDC（OpenID Connect）フェデレーションを設定しても、他の Microsoft Entra テナントを外部 IdP として登録することはサポートされません。ドキュメント上も「microsoftonline.com を含む issuer は受け付けない」旨が明記されています。
つまり、External テナントで「相手の Entra テナントを OIDC IdP にしてサインインさせる」という構成は、管理者が OIDC 連携を“明示的に”作る形では成立しません。代わりに、External テナントの OIDC はソーシャルログインや一般的な外部 OIDC IdPを接続する用途に寄っています。
実務上ここで重要なのは、制約を“回避する裏技”よりも、要件に合う連携方式へ設計を寄せることです。次章で、External テナントで現実的に採れる選択肢を具体化します。
External テナントで「他の Entra テナント利用者」と連携する現実解
パターンA：ゲスト招待（B2B 招待）で “ユーザー単位” に受け入れる
External テナント側に相手ユーザーを招待（Invite）して、External テナント内に UserType=Guest 相当のユーザーとして存在させるやり方です。相手が Microsoft Entra テナントのユーザーであれば、サインインは相手のホーム テナントの資格情報で進むのが基本線になります。
ただし External テナントでは「招待」自体がプレビューの扱いを含むことがあり、運用設計（対象者の範囲・ロール付与・管理フロー）を先に決めておくのが安全です。
| 項目 | 向いている | 向いていない |
|---|---|---|
| 対象ユーザー数 | 少〜中規模（取引先担当者、委託先、運用管理者など） | 大量（数万〜数百万の顧客） |
| ライフサイクル管理 | 人手・申請で運用できる | 自動プロビジョニング/退職連動を必須とする |
| 要件の中心 | 「特定の外部ユーザーに権限付与して使わせたい」 | 「企業間連携を常時・無人で回したい」 |
設計のコツは、招待を“ログイン手段”として考えるのではなく、External テナント側にユーザーオブジェクトを作って権限管理するための入口として扱うことです。外部ユーザーが何人増えるか、誰が招待を承認するか、退職/契約終了時にどう消すか（棚卸しをどう回すか）までセットで決めると、後戻りが減ります。
パターンB：SAML / WS-Fed のダイレクト フェデレーションで “ドメイン単位” に連携する
External テナントは、SAML / WS-Fed の IdP フェデレーション（ダイレクト フェデレーション）をサポートします。相手組織が AD FS やサードパーティ IdP を持っている、または SAML/WS-Fed を公開できるなら、ドメイン単位で「そのドメインのユーザーは相手 IdP へリダイレクトして認証する」構成が取れます。
External テナント側のメリットは、ユーザー体験として「自組織の認証でそのまま入れる」に寄せやすい点です。一方で、SAML/WS-Fed はパートナー側の準備（メタデータ、証明書、クレーム）が必要で、運用も OIDC より“重め”になりやすいのが現実です。
External テナントでの SAML/WS-Fed 連携で押さえるべき具体値（パートナーとのすり合わせで揉めやすい点）を、あえて表に落とします。
| 論点 | External テナント側で重要なポイント | パートナーに依頼/確認すること |
|---|---|---|
| コールバック/ACS URL | External テナントは ciamlogin.com 系のエンドポイントを前提にする | IdP 側に External テナント用の ACS を登録してもらう |
| 必要クレーム | メールアドレス等、External ID が期待するクレームを満たす | emailaddress 等の必須クレームを送るよう設定してもらう |
| 証明書運用 | メタデータ URL で自動更新できるか、手動更新が必要か | 証明書ローテーション手順・連絡経路を確立する |
| ドメイン（検証/未検証） | 検証済みドメインかどうかで挙動・制約が出る | ドメイン所有の状況、DNS 更新可否を確認する |
特に「External テナント」と「ワークフォース テナント」で、SAML/WS-Fed の前提となる URL が異なる点は重要です。External テナント向けの値が表に載っているため、パートナーの IdP 担当者に共有する際はここを根拠にすり合わせると早いです。
また、SAML/WS-Fed フェデレーションは External/Workforce の両方で提供されますが、External テナントでは「リデンプション順序（どの IdP を先に使うか）を変更できない」など、細かな差分がある点にも注意が必要です。
パターンC：目的が “企業間コラボ” なら、External ではなくワークフォースで組む
もし要件が次のようなものなら、External テナントで無理に成立させるより、ワークフォース テナントで B2B 前提の設計に寄せた方が、機能・運用の両面で破綻しにくいです。
- テナント間で「信頼関係」を結び、条件付きアクセス（MFA/デバイス）も含めて統制したい
- Teams の共有チャネル（Shared channels）前提で “B2B Direct Connect” を使いたい
- 大量ユーザーを「招待メール・承諾」なしで自動作成/削除したい（cross-tenant sync）
これらは、設計思想としてワークフォース テナント側の機能（cross-tenant access / B2B direct connect / cross-tenant sync など）に寄っています。実際、cross-tenant access と B2B direct connect はワークフォース テナント適用であることが明示されています。
External テナントで cross-tenant sync / B2B Direct Connect が“前提にならない”理由
質問で挙がりやすいのが「External テナントでも cross-tenant sync できる？」「B2B Direct Connect（cross-tenant access の一部）は？」です。結論から言うと、External テナント（顧客向け）では、cross-tenant sync は利用できないことが公式の機能比較に明記されています。
また、B2B Direct Connect はワークフォース テナント適用として整理されており、External テナントで“Teams 共有チャネル連携を前提に”同じ設計を持ち込むのは難しくなります。
この違いを設計に落とすと、External テナントでは次のどちらか（または併用）が現実解になります。
- ユーザーを招待して External テナント側に作り、権限付与でコントロールする（ただし自動同期ではない）
- 外部 IdP（OIDC / SAML/WS-Fed）でフェデレーションし、アプリのサインイン体験を組む
「企業間を無人でつなぐ」発想（同期・相互信頼）よりも、External テナントでは「顧客/外部ユーザーがアプリに入れる」発想（フェデレーション・サインインフロー）を中心に据えるのが、結果的に最短ルートです。
同じドメインに “組み込みの Entra 連携” と “カスタム SAML/WS-Fed” を両方置いたら、どっちが使われる？
ここは運用で事故が起きやすいポイントです。結論としては、同一ドメインに対して複数のフェデレーション方式を同時に有効化して共存させる、という動きにはなりません。Microsoft のモデレーター回答でも「SAML/WS-Fed のダイレクト フェデレーションを構成したなら、それが優先され、組み込み側は使われない」と整理されています。
もう少し実務向けに言い換えると、次のようなイメージです。
| 状態 | そのドメインのサインインで起きやすいこと | 設計上の示唆 |
|---|---|---|
| カスタム SAML/WS-Fed を設定していない | Microsoft Entra の既定の動作（組み込みのテナント間挙動）に従う | まずは標準動作で運用できるか検討する |
| カスタム SAML/WS-Fed を設定した | そのドメインは SAML/WS-Fed 側で認証が進む（組み込み側は実質使われない） | そのドメインは「SAML で行く」と腹を括る。戻すなら設定削除 |
“組み込みのフェデレーションをオン/オフするスイッチが見当たらない”という疑問は自然ですが、運用上は「カスタムを入れたらそちらが優先」という形で暗黙に切り替わる、と理解しておくとトラブルが減ります。
なお、ワークフォース テナントの文脈では「招待リデンプション時の IdP 優先度（redemption order）を変更して、どちらを先に使うか調整できる」方向の説明もあります。一方で External テナントでは、その並べ替え自体が未サポートとされています。ここが“同じ Entra でも挙動が違って見える”最大の理由になりがちです。
設計の実務ポイント：External テナントで失敗しないためのチェックリスト
要件を「コラボ」なのか「顧客サインイン」なのかで分ける
- Teams 共有チャネル、相互信頼、テナント間の統制が中心 → ワークフォースで B2B 設計を検討
- 自社アプリに外部ユーザーが入れることが中心 → External テナントで OIDC/SAML を軸に設計
OIDC は “Entra を IdP にできない” 前提で、IdP 戦略を決める
- 「取引先が Entra だから OIDC で簡単に…」は成立しない（issuer 制約）
- 取引先が OIDC を提供できるなら、その OIDC が “Entra ではない IdP” になっているか確認
- 企業アカウントをどうしても受けたいなら、SAML/WS-Fed を提示できるかを交渉材料にする
SAML/WS-Fed は “技術” より “運用合意” が難所
- 証明書更新の連絡経路・更新タイミング（深夜切替の可否）
- 必須クレーム（email 等）が出せない組織が一定数ある
- ドメイン単位で切り替わるため「同じ会社の一部ユーザーだけ例外」は作りにくい
招待運用は「棚卸し」を最初から組み込む
- 誰が招待してよいか（ロール/承認フロー）
- 期限・契約終了時の削除（定期レビュー）
- アプリ割り当て/グループ付与の最小化（過剰権限を避ける）
よくある質問
OIDC で Entra テナントを IdP にできないなら、External テナントは B2B を想定していない？
External テナントは、第一に「顧客向けアプリの CIAM」を目的に設計されます。そのため、ワークフォースで中心となるクロステナント同期などは前提になりません。一方で、招待や SAML/WS-Fed といった“限定的な協業”の道は残されています。
相手が「Entra しかない」場合、SAML 連携は現実的？
相手が Entra のみでも、相手組織が AD FS や別 IdP を持っている、または SAML/WS-Fed を成立させられる体制があるなら検討余地があります。ただし、相手の運用負担が増えるため、契約・セキュリティ要件（監査、証明書更新、責任分界）まで含めて合意できるかがカギです。
同一ドメインで、標準の挙動とカスタム SAML を“使い分け”できる？
ドメイン単位で効く設計になるため、“同じドメインの中で一部ユーザーだけ別経路”のような使い分けは基本的に難しくなります。ドメインを分ける（別メールドメインを用意する）か、連携方式自体を見直す方が現実的です。
まとめ：External テナントでの「他テナント連携」は、発想を切り替えると設計が安定する
External テナントは、ワークフォース テナントの延長として見ると「できないこと」が目立ちます。しかし、CIAM として見ると、やるべきことは明確です。
- External テナント → 他の Entra テナントを OIDC IdP として登録は不可（issuer 制約が明記）
- cross-tenant sync は External テナントで利用不可（機能比較で明記）
- 協業の現実解は、招待かSAML/WS-Fed（パートナー側が対応できる場合）
- 同一ドメインで複数方式は共存しない。カスタム SAML/WS-Fed を入れたらそちらが優先し、戻すなら設定削除
「誰に」「どのアプリを」「どの運用負担で」使わせたいのかを先に確定し、External テナントは“顧客サインインの器”として、ワークフォース テナントは“企業間コラボの器”として使い分ける――この整理ができると、設計判断が一気にブレなくなります。
コメント