Microsoft Entra ID（旧Azure AD）のエンタープライズ アプリで、B2BゲストがSSOするとAADST550105で弾かれる…そんなときは“アプリ割り当て”を疑うのが最短ルートです。本記事では原因の仕組み、確認ポイント、確実に直す手順をまとめます。
現象：ゲストユーザーだけSSOが失敗してAADST550105が表示される
Microsoft Entra ID（旧Azure AD）の「エンタープライズ アプリ」（Enterprise applications）に対して、社外ユーザーをB2Bゲストとして招待しているのに、SSO（SAML/OIDCなど）でサインインしようとするとエラーになり、アプリに入れない――この相談はとても多いです。特にややこしいのが、社内のメンバーユーザーや管理者アカウントでは問題なく入れるのに、ゲストだけが失敗するパターンです。
結論から言うと、ゲスト側の設定が悪いというより「テナント側（＝アプリを提供する側）のエンタープライズ アプリで、アクセス制御が想定通りに構成されていない」ことが原因になりがちです。まずは“誰がそのアプリにサインインできるのか”を決めるスイッチと、その対象ユーザーの割り当て状況を確認しましょう。
AADST550105の意味：ほぼ「ユーザーがアプリに割り当てられていない」
AADST550105 は、エンタープライズ アプリ側で「割り当てが必要（Assignment required）」が有効になっているにもかかわらず、サインインしてきたユーザー（今回ならゲスト）がそのアプリに割り当てられていない場合に発生しやすいエラーです。言い換えると、Entra ID がトークンを発行する前の段階で「このユーザーはこのアプリに入ってよい」という許可が見つからず、入口で止められている状態です。
現場では、同じ“未割り当て”系の症状が AADSTS50105 として記録されることもあります。エラー表記がどちらで出ていても、着目点は共通で「エンタープライズ アプリの割り当て」と考えるのが最短です。
| 観点 | よくある状況 | 最初に疑うポイント |
|---|---|---|
| 誰が失敗するか | ゲスト（B2B）だけ失敗、社内メンバーは成功 | ゲストがアプリに割り当てられているか |
| 設定の傾向 | アプリの「割り当てが必要」がON | [ユーザーとグループ] に対象がいるか |
| 管理者のテスト | 管理者は成功して「問題ない」と誤認 | 管理者は割り当て要件を回避できる場合がある |
原因の仕組み：Entra IDは「割り当て必須」なら割り当てを見て入口で拒否する
エンタープライズ アプリには、アプリごとに「割り当てが必要？」というプロパティがあります。これを はい にすると、そのテナント内の全ユーザーが無条件にサインインできるわけではなく、“ユーザー/グループとして割り当てられた人だけ”がサインインできるようになります。アクセス制御をシンプルに実現できる一方、割り当てを忘れると今回のようなエラーになりやすいです。
流れをかみ砕くと、SSO の前半で次のチェックが走っています。
- ユーザー（ゲスト）がアプリにアクセスし、Entra ID に認証要求が飛ぶ
- Entra ID が対象のエンタープライズ アプリ（サービス プリンシパル）を特定する
- アプリが「割り当て必須」なら、ユーザーが割り当て済みか（ユーザー直 or グループ経由）を確認する
- 割り当てが見つからない場合、トークン発行前にブロックし、AADST550105（または同系統の未割り当てエラー）になる
（イメージ）
[ユーザー] → (SSO要求) → [Entra ID]
↓
[Enterprise App]
Assignment required?
├ Yes → 割り当て確認 → NGなら拒否
└ No → 先へ（他条件は別途）つまり、今回のエラーは「SSOの設定が壊れている」よりも「アクセス権（割り当て）が無い」問題であることが多い、というのがポイントです。
最短で直す：ゲストユーザーをエンタープライズ アプリに割り当てる
対処として一番おすすめなのは、対象ゲストを該当アプリの [ユーザーとグループ] に割り当てる方法です。運用的にも「このアプリに入れる人」を明確にできます。
手順（Entra 管理センター）
- Microsoft Entra 管理センターに、必要な権限を持つアカウントでサインインします
- [Entra ID] → [エンタープライズ アプリ] → [すべてのアプリケーション] から対象アプリを開きます
- 左メニューの [ユーザーとグループ] を開き、[ユーザーまたはグループの追加] を選びます
- [ユーザーとグループ] で該当のゲストユーザー（または割り当て用グループ）を選択します
- アプリがアプリ ロールを公開している場合は [ロール] を選択し、[割り当て] で確定します
この操作は、少なくとも クラウド アプリケーション管理者（Cloud Application Administrator）相当以上のロールが求められます。アプリの所有者（サービス プリンシパルの所有者）でも割り当てが可能なケースがあります。
| やること | 画面の場所 | 目安の権限 |
|---|---|---|
| 割り当て必須のON/OFF確認 | エンタープライズ アプリ → プロパティ | アプリ管理系ロール/所有者 |
| ユーザー/グループの割り当て | エンタープライズ アプリ → ユーザーとグループ | クラウド アプリケーション管理者以上など |
| アプリ所有者の追加 | エンタープライズ アプリ → 所有者 | クラウド アプリケーション管理者以上など |
ポイントは「ゲストユーザーを“このテナント側”のエンタープライズ アプリに割り当てる」ことです。ゲストの“本籍テナント（ホームテナント）”側で何かしても、アプリが存在するテナント（リソース テナント）の割り当てが空なら状況は変わりません。
ゲストユーザー特有の確認ポイント：招待状態と表示名（#EXT#）で混乱しない
ゲスト（B2B）アカウントは、招待を送った時点でホスト側テナントにユーザーオブジェクトが作成されます。ポータル上では、UPN が メールアドレス由来の文字列 + #EXT# を含む形式で表示されることがあり、これが「ユーザーが見つからない」「別ユーザーだと思った」という混乱の原因になります。
たとえば、外部ユーザーのメールが [email protected] の場合、ホスト側テナントでは john_contoso.com#EXT#@<ホストの初期ドメイン> のような UPN になることがあります。割り当て作業の検索欄で見つからないときは、表示名だけでなくメールアドレスでも検索し、同一人物のゲストオブジェクトを選べているか確認してください。
招待が完了していない場合の見え方
招待直後〜相手が受諾するまでの間、管理センターのユーザープロファイルでは招待状態が「保留（Pending acceptance）」として表示されることがあります。割り当て自体は先に行えますが、相手が招待を受け取れていない/受諾できていない場合は、別のエラーで止まることもあるため、まずは招待の受諾状況も合わせて点検すると切り分けが早くなります。
| つまずきポイント | 起こりがちなこと | 対処のコツ |
|---|---|---|
| #EXT# 形式が分からない | 同じメールでも別ユーザーに見える | メールアドレスで検索し、ゲストオブジェクトを選ぶ |
| 招待の受諾が未完了 | 「保留」状態のままで手順が進まない | 招待メール/受諾手順を確認し、必要なら再招待を検討 |
| グループ所属が反映されない | 割り当てグループに入れたつもりが漏れている | ゲストが本当にメンバーになっているかを再確認 |
まずはここを確認：プロパティの「割り当てが必要？」と割り当て一覧
原因の9割は“割り当て必須ON × 未割り当て”の組み合わせですが、復旧を急ぐほど「見たつもりで見ていない」ポイントが増えます。次の2画面をセットで確認すると、迷いが減ります。
確認①：割り当てが必要？（Assignment required?）
- 場所：エンタープライズ アプリ → プロパティ
- 見るべき項目：割り当てが必要？ が「はい」か「いいえ」か
ここが「はい」なら、割り当てが無いユーザーは基本的に弾かれます。逆に「いいえ」なら、割り当てが無くてもサインインが進む（ただし条件付きアクセスや同意、アプリ側の制御は別）ため、今回のエラーは起きにくくなります。
また、テスト時に注意したいのが グローバル管理者は割り当て必須の影響を受けずにサインインできる という仕様です。管理者でテストすると成功してしまい、現場ユーザーだけが失敗する、という“すれ違い”が起こります。
確認②：[ユーザーとグループ] に誰がいるか
- 場所：エンタープライズ アプリ → ユーザーとグループ
- 見るべき項目：対象ゲスト（または対象グループ）が 追加されているか、ロールが必要なら 適切なロール が付いているか
「ゲストはいるはず」と思っていても、実際には 別のテナントの同名アプリ に割り当てていたり、グループ割り当てのつもりが 入れ子グループ になっていて割り当てとして評価されていない、というケースがあります。
| チェック項目 | OK例 | NG例 | 対処 |
|---|---|---|---|
| 割り当てが必要？ | 意図通り（制限したいので「はい」） | 意図せず「はい」になっている | 方針に合わせて「いいえ」も検討 |
| ユーザー割り当て | ゲストがユーザーとして割り当て済み | ゲストが割り当て一覧にいない | ユーザー/グループを追加 |
| グループ割り当て | “直接割り当てた”グループにゲストが所属 | 入れ子グループで管理している | グループを直接割り当てる |
| ロール | 必要なら適切なアプリ ロールを付与 | ロール未選択/誤ったロール | ロールを選び直して再割り当て |
よくある落とし穴：テナント（ログイン先）と割り当て先を取り違える
“別テナントにも同名/同用途のアプリがある”環境だと、割り当て作業をしたつもりでも、実際には ログインさせたいテナントとは別のテナント に割り当てていた、という事故が起きます。SSO エラーのときは、まず「どのテナントのエンタープライズ アプリに入ろうとしているか」を固定しましょう。
取り違えを防ぐチェックポイント
- 管理センター右上のアカウント表示で、対象テナントに切り替わっているか確認する
- エンタープライズ アプリの 概要 で「テナント名」「アプリケーションID / オブジェクトID」を控えておく
- サインインログで、失敗したイベントの「テナント」「アプリ名」「エラーコード」を照合する
| 症状 | ありがちな原因 | 確認方法 | 修正の方向性 |
|---|---|---|---|
| 同じユーザーでも環境によって成功/失敗が揺れる | 別テナントのアプリに割り当てている | 割り当て先のテナントを確認（テナント切替） | “ログインさせたいテナント”側で割り当て |
| 管理者は成功、一般ユーザーは失敗 | 管理者が割り当て要件を回避している | 管理者以外のテストユーザーで再現確認 | 一般ユーザー/ゲストを割り当てる |
| グループ割り当てしたのに対象が弾かれる | 入れ子グループ/ライセンス条件/所属漏れ | 割り当てグループが直接か、所属が正しいか | 直接割り当て、所属/ライセンスを見直す |
回避策として「割り当て必須」を無効化するのはアリか？
セキュリティ方針が許すなら、エンタープライズ アプリの 割り当てが必要？ を「いいえ」に戻すことで、未割り当てによるブロックは回避できます。実際に、製品ベンダーのサポート記事でも「割り当て必須をNoにする」か「ユーザーを割り当てる」の2択として案内されることがあります。
ただし、割り当て必須をOFFにすると、テナント内のユーザー（ゲストを含む）がそのアプリに対して認証を試みられる状態になります。アプリ側で利用者を別途制御している場合でも、Entra ID 側の入口で制限したい（＝ゼロトラスト的に“最初のゲート”を固くしたい）なら、割り当て必須をONのまま、割り当て運用を整える ほうが再発が減ります。
運用でおすすめ：個人割り当てより「グループ割り当て」で管理する
ユーザーが増えるほど、個別にゲストを追加していく運用は破綻しやすくなります。アクセス対象者をグループで管理し、そのグループをアプリに割り当てる形にすると、担当者が変わってもルールが保てます。
ただし、グループ割り当てには注意点があります。
- 入れ子グループは評価されない（割り当てはカスケードしない）
- グループベースの割り当てには Microsoft Entra ID P1 または P2 が必要
「割り当てたはずなのにゲストが弾かれる」場合、ここが地雷になっていることが多いです。
| 管理方法 | メリット | デメリット/注意 | 向いているケース |
|---|---|---|---|
| ユーザーを直接割り当て | 即反映しやすい、分かりやすい | 人数が増えると管理が煩雑 | 少人数/緊急対応/一時的な付与 |
| グループを割り当て | 運用がスケールする、監査しやすい | P1/P2要件、入れ子不可、所属管理が必須 | 中〜大規模、定常運用、棚卸し重視 |
切り分けを速くする：10分チェックリスト
AADST550105 が出たときに、場当たり的に設定を触ると、復旧しても原因が残りやすいです。次の順番で見ると、最短で結論に到達できます。
| 順番 | 確認すること | 見る場所 | 分かったらやること |
|---|---|---|---|
| 1 | 対象アプリのテナントは合っているか | Entra 管理センターのテナント切替/アプリ概要 | 正しいテナントで作業し直す |
| 2 | 割り当てが必要？が「はい」か | エンタープライズ アプリ → プロパティ | 「はい」なら次へ、「いいえ」なら別要因も疑う |
| 3 | ゲスト（またはグループ）が割り当て済みか | エンタープライズ アプリ → ユーザーとグループ | 未割り当てなら割り当てる |
| 4 | グループ運用なら入れ子になっていないか | 割り当てグループの構造/所属 | グループを直接割り当てる |
| 5 | ロールが必要なアプリか（ロール未設定で弾かれていないか） | 割り当て時のロール選択/アプリ側設計 | 適切なロールで再割り当て |
（補足）PowerShellで割り当てを自動化・棚卸しする
手作業の割り当ては、担当者が増えるとミスが増えます。定常運用では、PowerShell で割り当て状況を棚卸ししたり、手順をコード化して“同じ操作を同じ結果で”実行できるようにするのが効果的です。Microsoft Entra のドキュメントでも、Entra PowerShell を用いた割り当て例が案内されています。
# 例：Entra PowerShell で割り当てを扱うときの考え方（概念例）
# まずは必要なスコープで接続（組織の方針に合わせて最小権限に）
Connect-Entra -Scopes "Application.ReadWrite.All","AppRoleAssignment.ReadWrite.All"
# 以降、対象ユーザー（ゲスト）と対象アプリ（サービスプリンシパル）を特定して
# アプリ ロール割り当て（または既定ロール）を追加する、という流れになります。PowerShell を使うと「どのアプリに誰が割り当てられているか」を定期的に出力できるため、監査やアクセス棚卸しにも繋がります。まずはポータルで正しい設定を作ったうえで、次のステップとして自動化を検討すると安全です。
まとめ：AADST550105は“割り当て”を直すと解決に近い
- AADST550105 は、エンタープライズ アプリが「割り当て必須」なのに、ユーザー（ゲスト）が割り当てられていないときに発生しやすい
- 対処は、対象テナントのエンタープライズ アプリで [ユーザーとグループ] にゲスト（またはグループ）を割り当てる
- 管理者アカウントで成功しても安心しない（割り当て要件を回避できるロールがある）
- 再発防止には、グループ割り当て＋運用ルール化が効く（ただし入れ子不可/P1-P2要件に注意）
「ゲストSSOが失敗する＝外部ユーザー側の問題」と思い込まず、アプリ側の割り当て設計から点検すると、最短で復旧できます。
コメント