― B2B collaboration / B2B direct connect ―
はじめに
本記事は Microsoft Entra External ID 初学者〜一度触ったことはあるが整理しきれていない人 を主な対象として、実務で混乱しやすいポイントに絞ってまとめています。
本記事の対象範囲：B2B ※B2C：CIAM（Customer Identity and Access Management）に関しては触れていません。
直近、Microsoft Entra External ID について問い合わせを受けました。正直なところ、自分でも理解があいまいな部分が多く、そのまま回答するのは危険だと感じたため、いちど腰を据えて調べ直すことにしました。
特に混乱しやすかったのが、
- B2B collaboration と B2B direct connect の違い
- 「招待されたユーザーは、結局“誰の ID”として扱われているのか？」
という点です。
本記事は、公式ドキュメントと実際の問い合わせ対応・検証をベースに、
分からなかったので自分なりに整理してみたというスタンスでまとめたメモになります。
社内向けに整理した内容ですが、同じところで悩む人は多そうなので、こちらにも投稿いたしました。
Entra External ID とは何か（あらためて）
Microsoft Entra External ID は、自組織外のユーザー（取引先、パートナー、委託先、顧客など）を安全に受け入れるための仕組みの総称です。
その中で、社内システムや Microsoft 365 / SaaS などに外部ユーザーをアクセスさせる際によく登場する方式が、以下の 2 つです。
- B2B collaboration
- B2B direct connect
名前は似ていますが、
- ユーザーオブジェクトをどこに持つのか
- どこで認証され、どこで制御されるのか
という点が大きく異なり、ここを誤解すると設計や説明で詰まりがちです。
B2B collaboration：一番よく使われる方式
B2B collaboration は、
外部ユーザーを「ゲスト」として自テナントに招待し、Entra ID 上にユーザーオブジェクトを作成して管理する方式
です。Microsoft 365 を触ったことがある人であれば、最も見覚えのあるパターンだと思います。
調べて分かったポイント
- 招待された外部ユーザーは 自テナント内に Guest ユーザーとして作成される
- 認証自体は、相手側の ID プロバイダーで行われる
- 相手の Entra ID
または、 - Microsoft アカウント
- Google アカウント
- Facebook アカウント
などの外部 ID プロバイダー
- 相手の Entra ID
- グループ割り当て、アプリ割り当て、アクセスレビューなど、
社内ユーザーと近い感覚でガバナンスをかけられる
図で整理すると（B2B collaboration）
※ここでは以下のような構成図を前提にしています。
- 自テナント側に Guest ユーザーオブジェクトが存在
- 認証は外部ユーザーの Entra ID のホームテナント または 外部 ID プロバイダー で実施
- 認可・権限付与は リソースを持つ自テナント側 で実施
B2B collaboration では、外部ユーザーは招待先テナントに Guest ユーザーオブジェクト として作成される。
一方で、ユーザーの認証は元のホームテナント（Entra ID や Google アカウント等の外部 ID プロバイダー）で行われ、アプリやリソースへのアクセス可否（認可・権限付与）は招待先テナント側で制御される。
「ユーザーは自テナントに存在するが、認証は相手側」という構造を意識すると、挙動が理解しやすくなりました。
「外部ユーザーを業務アプリや M365 に広く使わせたい」場合は、まずこの方式が第一候補になります。
B2B direct connect：思っていたより用途が限定的
一方で、B2B direct connect は少し毛色が違います。
外部テナントと相互に信頼関係を結び、ゲストユーザーを作らずに接続する方式
という理解になります。
調べて気づいた点
- 自テナントに Guest ユーザーは作成されない
- 相手が Microsoft Entra ID テナントを持っていることが前提
- 現時点での主な利用シナリオは Microsoft Teams の Shared Channels
- 既定では direct connect はブロックされており、明示的な許可設定が必要
図で整理すると（B2B direct connect）
※ここでは以下のような構成図を前提にしています。
- ユーザーは 終始ホームテナントの資格情報のまま
- 自テナント側には Guest ユーザーオブジェクトは存在しない
- テナント間の クロステナントアクセス設定（相互許可） により接続
B2B direct connect では、ユーザーは自分のホームテナントに留まったままリソースにアクセスする。招待側テナントには Guest ユーザーは作成されず、テナント間の信頼関係（クロステナントアクセス設定）によってアクセスが成立する。
「ゲストを作らない＝管理が楽」という単純な話ではなく、 利用できるリソースやシナリオがかなり限定されている、という点は今回調べて一番の学びでした。
簡単に整理（向いている / 向いていない）
| 観点 | B2B collaboration | B2B direct connect |
|---|---|---|
| 主な用途 | 業務アプリ / M365 / SaaS 利用 | Teams Shared Channels |
| Guest ユーザー | 作成される | 作成されない |
| ガバナンス | かけやすい | 限定的 |
| 利用シナリオ | 汎用 | 非常に限定的 |
| 選定の基本 | 原則こちら | 明確な理由がある場合のみ |
よくある勘違い３つ
勘違い① direct connect は B2B collaboration の上位互換
→ 違います。
direct connect は Teams Shared Channels 向けの仕組みであり、業務アプリ全般に使えるものではありません。
勘違い② Guest ユーザーを作らない＝管理が不要
→ むしろ設計と合意が重要です。
クロステナントアクセス設定や相互許可が前提となります。
勘違い③ 招待ユーザーは単なるメールアドレス情報
→ 実体は ID を持ったユーザーです。
B2B collaboration では Guest ユーザーとして明確に管理対象になります。
設計・監査観点での個人的な整理
-
原則
- 外部に業務アプリ / M365 を使わせる → B2B collaboration
-
例外的に
- Teams Shared Channels 中心 → B2B direct connect
おわりに
Entra External ID は用語も多く、とっつきにくい印象がありましたが、
- ユーザーはどこに存在するのか
- 誰が認証し、誰が認可するのか
という軸で整理すると、かなり腹落ちしました。
本記事が、同じところで悩んでいる方の参考になれば幸いです。
参考リンク（Microsoft Learn）
- https://learn.microsoft.com/entra/external-id/
- https://learn.microsoft.com/ja-jp/entra/external-id/what-is-b2b
- https://learn.microsoft.com/entra/external-id/b2b-direct-connect-overview
- https://learn.microsoft.com/entra/external-id/cross-tenant-access-settings-b2b-collaboration
- https://learn.microsoft.com/entra/external-id/cross-tenant-access-settings-b2b-direct-connect