Microsoft Entra External ID（外部テナント／CIAM）でグループを作成しようとすると、「動的グループ（Dynamic membership）」がグレーアウトして選べず困ることがあります。本記事では、それが設定漏れではなく仕様である点を整理しつつ、外部ユーザーを属性で自動振り分けしたい場合に現実的に取り得る代替策を、運用目線で具体的にまとめます。
結論：Entra ID 外部テナント（External ID / CIAM テナント）では動的グループはサポートされていない
2025年12月時点で、Microsoft Entra External ID の外部テナント（external tenant）では、グループ作成時の「Membership type（メンバーシップの種類）」でDynamic（動的）を選択することはできません。ポータル上でグレーアウトしているのは、権限不足や設定ミスではなく、外部テナント側の仕様（未サポート）です。
| 確認したいポイント | 答え | 補足 |
|---|---|---|
| 外部テナントで動的グループは使える？ | 使えない（未サポート） | ポータルでグレーアウトは仕様 |
| 設定漏れ（権限・ライセンス）で直る？ | 直らない | Workforce テナントなら別 |
| 要望はどこに出す？ | Microsoft のフィードバック窓口 | CIAM 関連カテゴリで投稿 |
この制約は、外部ユーザー（フェデレーション ID／ローカル ID）を「国/地域」「契約プラン」「組織種別」などの属性で自動的にグループへ振り分けたいユースケースに、そのまま影響します。
まず整理：「External ID」は2つの場所に登場する（ここが混乱の元）
“External ID” という言葉は、Microsoft Learn や管理画面上で頻繁に出てきますが、実務では「どのテナント構成の話か」で挙動が大きく変わります。
特に重要なのは、Microsoft Entra のテナントにはWorkforce（通常の社内向け）とExternal（外部向け／CIAM）の2構成がある点です。External ID は、その両方の文脈に登場します。
| 比較軸 | Workforce テナント | External テナント（CIAM／外部テナント） |
|---|---|---|
| 主な用途 | 社員・社内アプリ・Microsoft 365 等 | 顧客/消費者/外部利用者向けアプリの認証基盤 |
| External ID の位置づけ | B2B コラボ（ゲスト招待・セルフサインアップ等） | CIAM（サインアップ/サインイン、属性収集、ブランド等） |
| 動的グループ | 利用可能（条件あり） | 利用不可（グレーアウト） |
| SSO 対象 | Microsoft を含む各種アプリに広く対応 | 外部テナント内に登録したアプリ中心（Microsoft SaaS への SSO は前提外） |
つまり、あなたが見ている「External ID」の画面が外部テナント（external tenant）であれば、動的グループがグレーアウトしていても不思議ではありません。
「External ID の動的グループ」という記事が見つかるのに、外部テナントで使えない理由
検索すると「Microsoft Entra External ID で動的グループを作る」趣旨の Microsoft Learn 記事がヒットし、余計に混乱します。
ここでポイントになるのが、その記事が“B2B collaboration（B2B コラボ）”の話であり、適用先がWorkforce テナントになっているケースがあることです。たとえば、External ID のページ配下に「B2B コラボ向けの動的グループ」記事が存在しますが、記事内の適用先が Workfoce になっていることが明記されています。
| よくある誤解 | 実際 | どう確認する？ |
|---|---|---|
| 「External ID の記事にある＝外部テナントでも使える」 | 記事が B2B コラボ（Workforce）向けの場合がある | 記事の “Applies to”／対象テナント表記を見る |
| 「P1/P2 を買えば外部テナントでも動的になる」 | 外部テナント側で動的グループ自体が未サポート | Q&A/仕様情報、外部テナント機能比較を確認 |
この“情報の配置”がややこしいため、現場では「設定ミス？」「どこかのスイッチが足りない？」となりやすいです。
外部テナントで動的グループがないと何が困る？ユースケース別の影響
動的グループが真に必要かどうかは、「グループを何に使っているか」で変わります。外部テナントでボトルネックになりやすいのは、次のようなパターンです。
| やりたいこと | 動的グループがある場合 | 外部テナント（動的なし）で起きること |
|---|---|---|
| 契約プラン（free/premium）で自動振り分け | 属性ルールで自動追加/削除 | 自動振り分けは標準機能だけでは不可。同期処理が必要 |
| 国/地域ごとのアクセス制御 | country/region で動的分岐 | グループ分岐は作れないので、クレーム/属性ベースへ寄せる判断が増える |
| “取引先Aのユーザーだけ”に機能を開放 | 会社属性やドメインで動的グループ | 招待/サインアップ後の分類処理を別途用意する必要 |
| 管理者が条件を変えながら運用したい | ポータルでルール更新→自動反映 | スクリプトや外部DB側のロジック変更が必要（運用負担増） |
代替策の全体像：動的グループで“実現したかったこと”を分解して選ぶ
動的グループが使えない以上、重要なのは「動的グループそのものを再現する」ことではなく、目的（アクセス制御・セグメント・権限付与）を別手段で満たすことです。
外部テナントの機能は段階的に提供されており、グループやアプリロールの対応範囲も明示されています。まずは外部テナントで何が “できる/できない” を前提として設計を組み替えるのが近道です。
| 目的 | おすすめ代替 | 強み | 弱み |
|---|---|---|---|
| ユーザーを条件で“区分”したい | カスタム属性＋アプリ側 ABAC | グループ依存を減らせる、柔軟 | アプリ実装/設計が必要 |
| 管理画面から“権限”として運用したい | アプリロール（App roles） | トークンに roles が載りやすい | 割当自動化は別途必要 |
| どうしても“グループ”で揃えたい | Graph/PowerShell で定期同期 | 既存のグループ運用思想を維持 | 運用・保守コストが上がる |
| 外部システムで会員ランク等が確定している | 会員DB/CRM 主導で Entra を更新 | 真実の所在（SSOT）が明確 | 連携設計が必要 |
代替策1：Microsoft Graph / PowerShell で“疑似動的グループ”を作る（同期ジョブ方式）
外部テナントで最も取り組みやすいのは、ユーザー属性を読み取り、条件に合うユーザーをグループに追加/削除する同期処理を自作する方法です。結果として「手作りの動的グループ」に近い挙動になります。
構成パターン（現実的に運用しやすいもの）
| 実行基盤 | 向いている規模 | メリット | 注意点 |
|---|---|---|---|
| Azure Automation（PowerShell） | 小〜中 | スケジュールが簡単、運用が分かりやすい | 実行時間・モジュール管理、秘密情報管理の設計が必須 |
| Azure Functions（Graph API） | 中〜大 | 実装自由度が高く、拡張しやすい | 例外処理・リトライ・監視を最初から作り込む必要 |
| Logic Apps（HTTP/Graph） | 小〜中 | ローコードで作れる、可視化しやすい | 複雑な判定ロジックは辛い、コストが読みづらい場合がある |
| CI/CD（GitHub Actions / Azure DevOps） | 中 | コード管理と監査がしやすい | 実行環境・権限・IP 制限などを丁寧に設計する必要 |
同期ジョブ設計で失敗しないための実装ポイント
- 差分で回す：毎回全ユーザーを走査すると、ユーザー数増加で詰みます（フィルター、更新日時、差分取得の活用）。
- 冪等（idempotent）：同じ入力なら同じ結果になるようにし、二重追加・二重削除を避けます。
- “追加”と“削除”をセット：追加だけだと条件変更に追随できず、グループが肥大化します。
- ログは「誰を、なぜ、どうした」を残す：後日問い合わせが来たとき、証跡がないと運用が破綻します。
- Graph のスロットリング前提：リトライ（指数バックオフ）と分割実行を前提に設計します。
サンプル：PowerShell（Microsoft Graph SDK）で属性条件に応じてグループ同期する骨組み
以下は考え方を掴むための最小骨格です（そのまま本番投入するのではなく、監査ログ・リトライ・例外処理・秘密情報管理を足してください）。
<#
前提：
- アプリ登録（証明書 or シークレット）で Graph に接続
- 対象：外部テナント内のユーザー属性（例：customAttribute / country 等）
- 目的：条件に合うユーザーをグループに追加、外れたユーザーを削除
#>
Import-Module Microsoft.Graph.Authentication
Import-Module Microsoft.Graph.Users
Import-Module Microsoft.Graph.Groups
$TenantId = "<YOUR_TENANT_ID>"
$ClientId = "<YOUR_APP_CLIENT_ID>"
$GroupId = "<TARGET_GROUP_OBJECT_ID>"
# 例：条件（国=JP かつ カスタム属性 plan=premium）
# ※外部テナントの属性設計に合わせて Filter を調整してください
$Filter = "(country eq 'JP') and (extension_<APPID>_plan eq 'premium')"
# 接続（例：証明書を使う想定。環境に合わせて変更）
Connect-MgGraph -TenantId $TenantId -ClientId $ClientId -CertificateThumbprint "<THUMBPRINT>"
# 1) 条件に合うユーザー一覧（ID のみ取得するなど軽量化推奨）
$targetUsers = Get-MgUser -Filter $Filter -All -Property "id" | Select-Object -ExpandProperty Id
# 2) 現在のグループメンバー一覧
$currentMembers = Get-MgGroupMember -GroupId $GroupId -All | ForEach-Object { $_.Id }
# 3) 追加対象（target - current）
$toAdd = $targetUsers | Where-Object { $_ -notin $currentMembers }
# 4) 削除対象（current - target）
$toRemove = $currentMembers | Where-Object { $_ -notin $targetUsers }
# 追加
foreach ($userId in $toAdd) {
New-MgGroupMemberByRef -GroupId $GroupId -BodyParameter @{
"@odata.id" = "https://graph.microsoft.com/v1.0/directoryObjects/$userId"
}
}
# 削除
foreach ($userId in $toRemove) {
Remove-MgGroupMemberByRef -GroupId $GroupId -DirectoryObjectId $userId
}
Disconnect-MgGraphポイントは「まず条件に合うユーザー集合を作る」→「現メンバー集合と差分を取る」→「追加と削除を両方やる」です。これが“疑似動的グループ”の基本形になります。
運用でハマりがちな注意点
| 落とし穴 | 起きる問題 | 回避策 |
|---|---|---|
| 属性がそもそも揃っていない | 条件評価ができず分類が破綻する | サインアップ時に必須収集、または外部DBで SSOT を確立 |
| 全件走査で回してしまう | ユーザー増で処理が終わらない／API 制限にかかる | 差分・分割・キューイングで設計する |
| 削除をしない（追加だけ） | 条件変更に追随できない | 必ず “remove” まで実装する |
| 監査ログを残さない | 問い合わせ時に説明不能 | ユーザーID、理由、実行ID、実行者（アプリ）を保存 |
代替策2：プロビジョニング元（会員DB/CRM）を正として、Entra は“結果”だけ持つ
外部ユーザーの属性（プラン、地域、取引先区分など）が既に会員管理システムやCRMで決まっている場合、Entra 側に“判定ロジック”を置こうとすると二重管理になりやすいです。
その場合は、割り切って会員DB/CRM を SSOT（Single Source of Truth）として扱い、Entra には「グループ所属」または「トークンに載せる属性」を同期する設計が現実的です。
| 設計の考え方 | メリット | デメリット |
|---|---|---|
| 区分判定は会員DB/CRMで確定し、Entra は参照・反映先 | 真実が一つになる／監査・説明がしやすい | 連携の実装と障害時のリカバリ設計が必要 |
| Entra には “アクセス判断に必要な最小データ” だけ置く | 個人情報や業務データの置き場が整理できる | 「Entra だけ見れば完結」にはならない |
代替策3：グループではなく「クレーム／属性ベース（ABAC）」でアクセス制御する
外部テナント（CIAM）でよくある最適解は、そもそもグループを主役にしないことです。外部テナントはアプリのサインアップ/サインイン体験や属性収集、拡張ロジック（カスタム認証拡張）などを軸に設計するため、アプリ側の認可はトークンに含めた属性（クレーム）で判断する方がスケールしやすい場面が多いです。
外部テナントで取りやすい ABAC パターン
| パターン | 概要 | 向いているケース |
|---|---|---|
| カスタム属性をユーザーに保持 | サインアップ時に plan/region 等を収集・保持し、アプリで参照 | 区分が単純、会員DBと同期できる |
| トークン発行時に外部システムからクレーム付与 | 認証拡張で外部APIを呼び、最新の会員状態をクレーム化 | 会員状態が頻繁に変わる、即時性が必要 |
| 認可をアプリ側の権限サービスへ分離 | Entra は認証、権限は別サービス（Policy/Entitlement）で評価 | 複数アプリで共通認可を使う、将来拡張が大きい |
グループは「人を束ねる」には便利ですが、外部ユーザー向けの区分が細かくなり始めると、グループ数や運用ルールが膨張しがちです。外部テナントでは、最初から ABAC 寄りに設計しておくと、後で楽になります。
代替策4：アプリロール（App roles）を“役割”として配る（RBAC 目的なら特に有効）
「premium ユーザーはこの API を叩ける」「partner 管理者は管理画面に入れる」など、役割（ロール）で認可したいなら、動的グループの代わりにアプリロール（App roles）を使う発想が有効です。
外部テナントでは、グループやアプリロールの対応状況が整理されており、「グループへアプリロールを割り当てる」「グループクレームを扱う」といった操作が Graph 経由になる場面がある点も押さえておくと設計ミスを減らせます。
| 比較 | グループ（Assigned） | アプリロール | クレーム（属性） |
|---|---|---|---|
| 主用途 | ユーザー束ね・割当 | 役割（権限）表現 | 条件判断（プラン/地域/状態） |
| 運用の分かりやすさ | 高い | 高い（役割が明確） | 中（設計次第） |
| 自動化のしやすさ | 同期処理が必要 | 同期処理が必要 | 属性同期 or 発行時付与で柔軟 |
| 外部テナントでの相性 | 動的不可のため工夫が必要 | RBAC 目的なら強い | CIAM らしい設計に寄せやすい |
「動的がグレーアウト」現象の切り分けチェックリスト（外部テナント以外の原因も一応潰す）
今回の主題は「外部テナントでは未サポート」ですが、別の原因でグレーアウトするケースもあります。念のため、切り分け観点を表にまとめます。
| チェック項目 | 見る場所 | 外部テナントの場合 | Workforce テナントの場合 |
|---|---|---|---|
| テナント構成（Workforce / External） | テナント情報・ドキュメントの対象表記 | External なら Dynamic は基本選べない | Workforce なら Dynamic を使える可能性 |
| ライセンス要件（P1/P2 等） | ライセンス・機能要件 | そもそも機能未サポートのため改善しない | 要件を満たさないと Dynamic が出ないことがある |
| 管理者ロール | Entra 管理センターの権限 | 権限を上げても Dynamic は出ない | 権限不足で作れないことがある |
動的グループ自体の一般要件（ライセンス要件など）を確認したい場合は、動的メンバーシップの要件説明を合わせて読むと整理が早いです。
どうしても「ポータルで条件を編集できる動的グループ」が必要な場合の考え方
要件によっては、外部テナント採用自体を見直した方が安い場合があります。例えば「相手は顧客ではなく取引先担当者（=B2B）」であり、Microsoft 365 や社内リソースへのアクセスが主目的なら、Workforce テナントの B2B コラボで十分なことがあります。その場合、動的グループを含む “Workforce 側の運用” に寄せられる可能性があります。
| 状況 | 向いている選択 | 理由 |
|---|---|---|
| 相手が取引先の業務ユーザー中心 | Workforce テナント（B2B） | ゲスト運用＋グループ運用がしやすい |
| 相手が顧客・消費者中心（大量） | 外部テナント（CIAM） | サインアップ体験・ブランド・属性収集など CIAM に最適化 |
| 両方いる（B2B と B2C が混在） | 用途ごとに分ける（テナント/アプリ境界を設計） | 後から権限モデルが破綻しにくい |
機能要望を通しやすくするフィードバック投稿のコツ
動的グループが“導入のボトルネック”になるケースは多く、Microsoft 側もフィードバック投稿を案内しています。投稿する際は、単に「欲しい」ではなく、なぜ必要で、ないと何が破綻し、どの代替が高コストなのかを具体的に書くと、議論に乗りやすくなります。
- 対象ユーザー種別（ローカル／フェデレーション／招待）
- 判定に使いたい属性（例：国/地域、契約プラン、組織種別）
- ユーザー数と増加見込み（例：MAU、登録総数）
- “動的グループがないと困る”具体的業務（例：API 認可、機能フラグ、運用工数）
- 回避策のコスト（ジョブ運用、監査、障害対応の工数）
まとめ：外部テナントの制約を前提に、最小コストで“同じ目的”を満たす
Entra ID の外部テナント（External ID / CIAM）で動的グループがグレーアウトするのは、設定ミスではなく仕様です。動的グループに頼った設計をそのまま持ち込むと詰みやすいので、まず「何のためにグループが必要か」を分解し、同期ジョブ・アプリロール・クレーム（ABAC）のどれで目的を満たすかを選ぶのが現実解です。
特に「外部ユーザーを属性で自動振り分けしたい」要件は、外部テナントではカスタム属性＋トークン（クレーム）設計の方がスケールしやすいケースが多いので、最初に検討しておくと後戻りが減ります。
参考リンク（公式・一次情報）
コメント