Microsoft Entra ID の B2B を設定したのに、あるユーザーだけ別テナントの Web サイトへゲスト招待なしで入れてしまう――。この現象は B2B Direct Connect と B2B コラボレーションの役割の違いを理解すると整理できます。原因の見分け方と、再現性のある設計手順を解説します。
結論として押さえるべきポイント
先に結論を明確にします。B2B Direct Connect だけで、任意の Web サイトや業務アプリに「テナント間 SSO」で入ることはできません。B2B Direct Connect は、現時点では主に Microsoft Teams の共有チャネル を成立させるための仕組みで、Web サイト（例： docs.company2.dev ）のような一般アプリに対して「ゲストなしでアクセス」を実現する用途には設計されていません。
別テナントの Web サイトや SaaS/自社アプリにアクセスさせたいなら、基本は Microsoft Entra の B2B コラボレーション（ゲストユーザー） を使い、リソース側テナント（Company2）に外部ユーザーのユーザーオブジェクトを持たせたうえで、アプリ側の割り当て（グループ/ロール/アプリ割り当て）を行うのが王道です。
| やりたいこと | 最適解になりやすい機能 | 補足 |
|---|---|---|
| Teams の共有チャネルに外部ユーザーを招待して共同作業したい | B2B Direct Connect | ゲストは共有チャネルに追加できないため、共有チャネルの外部参加は B2B Direct Connect が前提になりやすい |
| 別テナントの Web サイト / Enterprise アプリ / SaaS に外部ユーザーをサインインさせたい | B2B コラボレーション（ゲスト） | リソース側に外部ユーザー（ゲスト）を用意し、アプリ割り当てや条件付きアクセスで制御するのが基本 |
| 自社が提供する SaaS として多数の他社ユーザーにサインインさせたい | マルチテナント アプリ設計 | 「ゲストを大量に作る運用」を避けたい場合の設計選択肢。アプリ側の実装と同意設計が重要 |
今回の現象を整理すると何が起きているか
質問の状況を、Company1（利用者の所属テナント）と Company2（Web サイトのホスト側テナント）として整理します。
| 観測された事象 | 起きている可能性が高いこと | 切り分けのヒント |
|---|---|---|
| 質問者本人は Company2 にゲストがいないのにサイトへ入れた | 通常の B2B コラボレーション経路ではないサインイン（例：Service Provider 系） | サインインログの Cross-tenant access type が serviceProvider になっている |
| 他の Company1 ユーザーは「Company2 にアカウントが存在しない」系エラー | Company2 側アプリが「ユーザーが Company2 テナントに存在すること」を要求 | エラーが AADSTS50020 系なら「外部ユーザーとして追加が必要」が典型 |
| 動かないユーザーを Company2 にゲスト招待すると直る | B2B コラボレーションの想定どおりの動作 | ゲスト作成＋アプリ割り当てが成立したため |
| 動かないユーザーのログに Password Hash Auth / Cross-tenant access type = passthrough | ユーザーのホームテナントで通常の認証が行われ、クロステナントとして処理されている | passthrough は「ホーム IdP に認証が転送される」性質のログ値 |
ここで大事なのは、「B2B Direct Connect を設定した＝Web アプリがゲストなしで動く」ではないという点です。設定画面（クロステナントアクセス設定）が同じ領域にあるため混同しやすいのですが、機能の適用範囲が違います。
B2B Direct Connect と B2B コラボレーションを混同するとハマる理由
Microsoft Entra の「External Identities」周りは、似た用語が多く、目的が違う機能が並んでいます。まずは 何が “ユーザーオブジェクト” を作り、何が作らないか を軸に理解するとブレません。
| 項目 | B2B Direct Connect | B2B コラボレーション |
|---|---|---|
| 主用途 | Teams 共有チャネル（Teams Connect）での他社連携 | 自社テナントのアプリ/サイトを外部ユーザーに共有 |
| 外部ユーザーの扱い | 原則としてリソース側テナントにユーザーとして「存在しない」 | リソース側テナントにゲストユーザーとして作成される |
| 権限付与の単位 | 共有チャネルの範囲（チーム全体ではない） | アプリ割り当て、グループ、ロールなどで細かく制御可能 |
| アクセスできる範囲 | 共有チャネル内のリソースが中心 | Microsoft アプリ、SaaS、カスタムアプリ等（アプリ統合の範囲） |
上の表が示す通り、Web サイトのように「アプリとしてアクセス制御したい」対象は、ほぼ確実に B2B コラボレーションの領域です。B2B Direct Connect は、“ゲストを作らない代わりに、Teams の共有チャネルという枠内で完結する” と考えると理解しやすいです。
なぜ Web サイトアクセスではゲストユーザーが必要になりやすいのか
Company2 がホストする Web サイトが Microsoft Entra で認証している場合、裏側では「Enterprise アプリ（サービスプリンシパル）」や「アプリ登録」の設定によって、誰がサインインできるか が決まります。
多くの社内向け Web サイトは、セキュリティ上の理由から シングルテナント（そのテナントのユーザーだけ）として構成されています。シングルテナント構成だと、外部ユーザーがアクセスしてきた際に「そのユーザーはこのテナントに存在するのか？」がチェックされ、存在しなければ AADSTS50020 などのエラーで止まります。
ここでいう「存在する」は、ゲストユーザーとしてでもよいので Company2 テナント内にユーザーオブジェクトがあるという意味です。実際、ゲストとして招待するとアクセスできるようになるのは、この要件を満たしたからです。
| アプリ側の設計 | 外部ユーザーがゲストなしで入れる可能性 | 管理者の現実的な運用 |
|---|---|---|
| シングルテナント（社内アプリの典型） | 低い | ゲスト招待（手動/自動）＋アプリ割り当て |
| マルチテナント（SaaS 提供の典型） | あり得る | 各テナントで同意が必要、アプリ側でテナント識別や権限制御を実装 |
| 匿名/別 IdP（公開サイトの典型） | 高い | そもそも Entra テナント境界の制約に依存しない設計 |
つまり「B2B Direct Connect を設定したのに Web サイトに入れない」という見え方は、本来別レイヤーの仕組みを同一視していることから起きがちなズレです。
サインインログで差が出た理由を読み解く
質問の中で非常に有力な手掛かりが、サインインログの Cross-tenant access type の値です。このフィールドは、クロステナントのサインインが「どの種類の越境」だったかを表します。代表的な値は次の通りです。
| Cross-tenant access type | 意味 | 今回の話との関係 |
|---|---|---|
| b2bCollaboration | B2B コラボレーション（ゲスト）としての越境サインイン | Web サイトアクセスで“正攻法”になりやすい |
| b2bDirectConnect | B2B Direct Connect による越境サインイン | 主に Teams 共有チャネルで登場しやすい |
| serviceProvider | CSP などのサービスプロバイダーが顧客テナントへ越境する形のサインイン | 「質問者本人だけ入れた」理由の説明に使える |
| passthrough | 認証がユーザーのホーム IdP に転送され、資格情報の再入力を要求しない越境サインイン | 他ユーザーが通常経路で越境している可能性 |
「Password Hash Auth」と「passthrough」を同じ意味だと思わない
サインインログを見ていると、失敗したユーザー側だけに Password Hash Auth（Password Hash Authentication）という表示が出て、「これが原因では？」と疑いがちです。しかし、これは多くの場合 ホームテナント側でどの方法で一次認証したか（パスワードで認証した、など）を示すもので、クロステナントで弾かれた根本原因（リソーステナントにユーザーがいない、アプリ割り当てがない、など）とはレイヤーが違います。
一方で Cross-tenant access type = passthrough は、Microsoft の説明では「認証がユーザーのホームの ID プロバイダーに転送され、資格情報の再入力を要求しないクロステナント サインイン」を意味します。名前が似ているため、ハイブリッド環境で使う Microsoft Entra のパススルー認証（Pass-through Authentication）と混同しないよう注意が必要です。
| 用語 | 出てくる場所 | 意味 | 混同しやすいポイント |
|---|---|---|---|
| Password Hash Authentication | サインインログの認証詳細 | ホームテナントでの一次認証がパスワードハッシュで行われた | クロステナントの許可/不許可とは別レイヤー |
| Cross-tenant access type: passthrough | サインインログの越境種別 | ホーム IdP に認証が転送される越境サインイン | 「PTA を使っている/いない」と直結しない |
| Pass-through Authentication | Entra Connect / ハイブリッド認証の構成 | オンプレ AD に対してパスワード検証する方式 | ログの “passthrough” と語感が似ている |
ここで重要なのは、serviceProvider は “B2B がうまく動いた” ことを示す値ではないという点です。Microsoft の説明でも serviceProvider は CSP などが顧客テナントに対して行う越境サインインの種類として定義されています。つまり、質問者本人のアクセス経路は、一般ユーザーの B2B とは別物である可能性が高い、という整理ができます。
自分だけゲストなしでアクセスできたときに疑うこと
結論から言うと、「再現性のある運用モデル」として依存すべき挙動ではありません。なぜなら、serviceProvider 系のサインインが絡む場合、次のような “管理者・委任運用” の文脈で発生しやすいからです。
- Company1 が Company2 のテナントを、CSP / パートナー関係（委任管理）で管理している
- 質問者のアカウントだけが、パートナー管理のロールや特権を持っている
- 過去にサポートや委任操作のために特殊な経路で認証しており、そのセッションが残っている
確認のしかたはシンプルです。質問者本人のサインインログを開き、アプリ名（Resource）、クライアントアプリ、認証要件、条件付きアクセス適用状況などを、他ユーザーの失敗ログと並べて見ます。Cross-tenant access type が serviceProvider であれば、一般ユーザーに同じ挙動を期待するのは危険です。
また、失敗しているユーザーのエラーが AADSTS50020 系であれば、ほぼ「Company2 テナント側に外部ユーザーとして追加されていない」「または追加されていても、アプリ割り当てがない」といったディレクトリ要件で詰まっています。
B2B Direct Connect でできることの範囲
B2B Direct Connect は、管理者同士が相互に信頼関係を作り、ユーザーは自分のホームテナントの資格情報のまま Teams の共有チャネルに参加できる、という体験を実現します。ここが便利な点です。
一方で、B2B Direct Connect ユーザーはリソース側テナントに “ユーザーとして存在しない” ため、Web アプリの「ユーザー割り当て」や「グループベースの権限付与」「アクセスレビュー」など、ディレクトリ上のユーザーオブジェクトを前提にした統制がそのまま使えません。Teams の共有チャネルという枠で完結する設計だからこそのトレードオフです。
実務で選ぶべき対応パターン
Company2 の Web サイトを Company1 のユーザーに使わせたい場合、現実的には次のパターンに落ちます。
| パターン | 概要 | 向いているケース | 注意点 |
|---|---|---|---|
| ゲスト招待で運用 | Company2 に Company1 ユーザーをゲストとして作成し、アプリに割り当て | 人数が限定的、権限を細かく管理したい | 招待・退職時の棚卸しが必要 |
| クロステナント同期で自動化 | Company1→Company2 へ B2B ユーザーを自動プロビジョニング | 人数が多い、入退社に追随して自動化したい | 同期スコープ設計（対象ユーザー/属性/削除）が重要 |
| エンタイトルメント管理で申請制 | 外部ユーザーがアクセスパッケージを申請し、承認と期限で統制 | プロジェクト単位で増減が多い、期限を必ず切りたい | ライセンス要件や運用フロー設計が必要 |
| マルチテナント化 | アプリを「他社テナントのユーザーがサインインできる」設計に変更 | 自社が SaaS として提供する、顧客テナントが多数 | 同意、発行者検証、テナント別ポリシーなどアプリ実装の責任が増える |
パターン別の進め方
ゲスト招待で運用するときの最短手順
最も標準的で、監査・統制もしやすいのがこの方法です。
- Company2 側で Company1 のユーザーを B2B ゲストとして招待（手動、CSV、または権限委任）
- Company2 側の Enterprise アプリ（Web サイトのアプリ）で、ユーザーまたはグループを割り当てる
- 必要に応じて条件付きアクセスで MFA やアクセス場所、デバイス条件を適用する
- サインインログで b2bCollaboration になっていること、エラーが消えることを確認する
| チェック項目 | どこを見る | OK の目安 |
|---|---|---|
| 外部ユーザーが作成されている | Company2 のユーザー一覧 | UserType が Guest（または外部ユーザーとして認識） |
| アプリに割り当て済み | Enterprise アプリの「ユーザーとグループ」 | 対象ユーザー/グループが表示される |
| サインインログの越境種別 | Company2 または Company1 のサインインログ | Cross-tenant access type が b2bCollaboration で成功 |
クロステナント同期でゲスト作成を自動化する
「ユーザーを毎回招待する」のが運用負荷になる場合は、クロステナント同期が有効です。クロステナント同期は、B2B コラボレーションユーザーの作成・更新・削除を自動化し、Microsoft アプリだけでなく非 Microsoft アプリへのアクセスにも使える、と説明されています。
現場でのコツは、最初から全社員を同期しないことです。例えば「docs サイト利用者グループ」に入った人だけ同期、属性（部署/役割/雇用形態）をもとに同期スコープを決める、など “最小権限” の発想で始めると事故りにくいです。
| 設計ポイント | おすすめ | 理由 |
|---|---|---|
| 同期対象 | 利用が確実なグループのみ | 不要な外部ユーザー増加を防ぐ |
| 削除（退職） | 自動で無効化/削除まで含める | 退職者が残るリスクを低減 |
| アプリ割り当て | 同期グループをそのままアプリ割り当てに使う | ライフサイクルと権限付与を連動できる |
エンタイトルメント管理で「申請・承認・期限」をセットにする
外部ユーザーに対して「誰が、いつまで、何にアクセスできるか」を業務部門主導で回したいなら、エンタイトルメント管理のアクセスパッケージが強力です。外部ユーザーは申請でき、承認の有無、アクセスレビュー、期限（有効期限）までポリシー化できます。
プロジェクト型の共同作業（数週間〜数か月）で特に効きます。ゲストが増えても、期限で自動的に落ちる運用にできるため、棚卸しが楽になります。
マルチテナント化は「提供する側」の設計として考える
もし Company2 の Web サイトが社内サイトではなく、複数企業に提供する SaaS であるなら、アプリをマルチテナントにする設計が選択肢になります。Microsoft の説明でも、シングルテナントはホームテナント内に限定され、マルチテナントは他テナントのユーザーにも利用可能とされています。
ただしこれは「ゲスト招待を不要にする魔法」ではなく、同意（consent）やテナント識別、発行者検証などをアプリ側が引き受ける設計です。規模が小さい B2B 連携であれば、まずはゲストで堅く運用するほうが早く安全です。
クロステナントアクセス設定で管理者が見直すべき箇所
クロステナントアクセス設定は、B2B コラボレーションと B2B Direct Connect の両方に関わる “交通整理” の設定です。既定では B2B コラボレーションは有効、B2B Direct Connect はブロックされている、という初期値が示されています。
ただし、ここを許可したからといって、Web アプリが自動的にゲストなしで動くわけではありません。クロステナントアクセス設定は「越境を許す/拒む」「MFA/デバイス信頼をどう扱う」といった制御であり、アプリのアカウント要件（ユーザーがテナント内に存在するか）は別問題として残ります。
| 見直しポイント | 誤解しやすい点 | 実務上の判断基準 |
|---|---|---|
| Inbound の B2B collaboration | 「許可＝ゲスト不要」ではない | ゲスト運用するなら許可し、対象ユーザー/アプリをスコープで絞る |
| Inbound/Outbound の B2B direct connect | Web アプリには効かない | Teams 共有チャネルを使うなら相互に許可する |
| Trust settings（MFA/デバイス） | 相手テナントの MFA を信頼するかは設計 | 二重 MFA を避けたい・相手が管理できているなら信頼を検討 |
エラーが出るときのトラブルシューティング
「このリソースにアクセスするには Company2 テナントにアカウントが存在していません」系は、典型的には AADSTS50020（外部ユーザーがリソーステナントに存在しない）で説明されるパターンです。まずは “認証は通ったが、リソーステナント側のユーザー要件で弾かれている” と疑うのが近道です。
| 症状 | 原因の候補 | 対処 |
|---|---|---|
| AADSTS50020 / アカウントが存在しない | Company2 にゲストがいない、または招待未承諾 | ゲスト招待・再招待、またはクロステナント同期で作成 |
| ゲストはいるのに入れない | Enterprise アプリの割り当てがない / ユーザー割り当て必須が有効 | アプリ割り当て（グループ推奨）を実施 |
| ユーザーによって挙動が違う | セッション/アカウント選択が別テナントに固定 | InPrivate で再試行、ブラウザのプロファイル分離、完全サインアウト |
| 管理者だけ入れる | serviceProvider や特権ロールで別経路になっている | 一般ユーザー向けには B2B コラボレーションで作り直す |
再現性のある運用にするためのチェックリスト
| チェック | 目的 | おすすめの実装 |
|---|---|---|
| オンボーディング経路を一本化 | 「入れる人/入れない人」がブレない | ゲスト招待、またはクロステナント同期に統一 |
| 権限付与をグループ化 | 監査と運用を簡単にする | Company2 側で “docs-access” グループを作り、アプリ割り当て |
| 期限・棚卸しの仕組み | 外部ユーザーが残り続けるリスクを抑える | アクセスパッケージ＋期限、または定期アクセスレビュー |
| サインインログの監視軸 | 想定外の越境経路を早期に発見 | Cross-tenant access type（serviceProvider / passthrough 等）でフィルタ |
まとめ
- B2B Direct Connect は Teams 共有チャネル向けであり、任意の Web サイトのテナント間アクセスを“ゲストなし”で実現する用途には基本的に使えません。
- Web サイトに外部ユーザーをアクセスさせるなら、B2B コラボレーション（ゲスト）を前提に、Company2 テナント内にユーザーオブジェクトを持たせて権限付与します。
- 「自分だけ入れた」ケースは、サインインログの serviceProvider が示す通り、CSP 等の特殊経路である可能性が高く、一般ユーザー向けの運用モデルとしては依存しないのが安全です。
- 人数が増えるなら、クロステナント同期やエンタイトルメント管理で、作成・権限付与・期限・削除までを仕組み化すると事故を減らせます。
コメント