Microsoft Entra IDのmemberOf演算子は、プレビュー終了に向けた見直しが必要です。Microsoftは、2026年11月3日後にmemberOfを使う動的グループ、動的管理単位、アクセスパッケージの自動割り当てポリシーが更新を停止し、最後の状態を保持すると案内しています。
「Failed to save the dynamic group」を回避するためにmemberOfを使った取り込み用グループを作り、その結果を別のグループへ同期している場合も、依存関係を見直しましょう。保存エラーの説明に加え、終了前に何を特定し、何へ置き換えるかを整理します。
2026年11月3日の期限：設定が残っていても更新は止まる
Microsoft公式のmemberOfドキュメントは、2026年11月3日より前に利用箇所を確認し、構成を削除または置換するよう案内しています。終了後の挙動は、自動削除や全員のアクセス拒否ではなく、直前の状態のまま更新されなくなるというものです。
このため、画面にグループが存在し、いまアクセスできていることだけでは移行完了と判断できません。元の条件が変わってもメンバーや割り当てが追随せず、古いアクセスが残ることが問題になります。
| 確認する対象 | 更新停止により見直しが必要なもの |
|---|---|
| 動的グループ | メンバーと、そのグループを利用するアクセス・割り当て |
| 動的管理単位 | メンバーと管理者が管理できる範囲 |
| アクセスパッケージの自動割り当てポリシー | 条件に基づくアクセスパッケージの割り当て結果 |
保存エラーの確認：memberOfに除外条件を追加していないか
memberOfを含むルールに、部署やユーザー名などの条件を追加する組み合わせはサポートされません。たとえば、次は元グループから取り込みつつ特定ユーザーを除外しようとする、サポートされない組み合わせの例です。
(user.memberof -any (group.objectId -in ['<GROUP_OBJECT_ID>']))
-and (user.userPrincipalName -ne "[email protected]")この場合、括弧や引用符を変えるだけでは、memberOfと別属性の条件を併用できるようにはなりません。ただし「Failed to save the dynamic group」というメッセージだけで、すべての保存失敗の原因をこの制限と断定することもできません。まず実際のルールにmemberOfと追加条件が含まれるかを確認します。
従来の仕様を理解するうえでは、次の点も押さえておきます。
- 取り込むのは元グループの直接メンバーであり、ネストしたグループの先のメンバーは対象になりません。
- 別の
memberOf動的グループを、さらにmemberOf動的グループの取り込み元にはできません。 memberOfはルールビルダーと検証機能に対応していません。
これらの制限を避けて保存できたとしても、プレビュー終了への対応は別に必要です。新たにmemberOfへの依存を増やす前に、属性条件や割り当てメンバーシップで要件を満たせるかを検討しましょう。
memberOfを使う二段構成も、移行対象として確認する
「対象＝元グループのメンバー－除外したいユーザー」という要件自体は、移行後も整理に使えます。ただし、取り込み元のデータをどこから得るかが重要です。
| 従来の構成 | 終了に向けて確認する点 |
|---|---|
| A：memberOfを使う取り込み用の動的グループ | Aが更新停止の対象。メンバー取得の基準を見直す |
| B：除外したいユーザーの割り当てグループ | 除外の要件と、その更新担当を確認する |
| C：AからBを差し引いた結果を同期する割り当てグループ | Cが静的でも、古くなったAを参照し続ける構成では目的を満たせない |
Cを静的グループにしていることだけでは、Aの更新停止を回避できません。同期処理が動き続けるかだけでなく、その入力が最新の対象者を表しているかを確認します。memberOfに依存したこの方式を、恒久的な本番対策として採用し続けることは勧められません。
3種類の設定を洗い出し、移行先を決める
グループ一覧だけを調べて終わらせず、管理単位とアクセスパッケージも確認します。公式資料は対象ごとに、次の検出・置換・検証方針を示しています。
| 対象 | 確認・置換・検証 |
|---|---|
| 動的グループ | 確認：Entra管理センターから一覧をエクスポートし、memberOfを含むルールを特定 置換：サポートされる属性条件・演算子へ変更、または割り当てメンバーシップへ切り替え 検証：意図したユーザー・デバイスがメンバーになっているか |
| 動的管理単位 | 確認：Microsoft Graph PowerShellでmemberOfを使う設定を調査 置換：サポートされるロジックへ変更、または割り当てメンバーシップへ切り替え 検証：メンバーと管理範囲の両方 |
| アクセスパッケージの自動割り当てポリシー | 確認：Microsoft Graph PowerShellでmemberOfを使うポリシーを調査 置換：対応する属性条件へ変更。同等条件がなければ別の割り当て方式を決定 検証：アクセスパッケージの割り当て結果 |
対象ごとの最新の方針は、公式資料の「Migrate before the preview ends」で確認できます。未検証の一括更新を実行するのではなく、対象、用途、期待するメンバーや割り当てを明確にして変更します。
属性で対象者を表せる場合
元グループの対象者が部署や勤務地などの属性で定義されているなら、memberOfを使わない条件へ組み替える方針を検討できます。元の要件に除外対象がある場合も、置き換え後にその条件を満たすか確認します。
ただし、同じ部署名を使っただけで元グループと同じ集合になるとは限りません。現在のメンバー、追加されるメンバー、外れるメンバーを比較し、属性が未設定の人や例外を含めて意図した結果になるかを確認しましょう。
属性では表せない場合
手動の判断で対象者を選んでいる場合など、同等の属性条件を用意できないときは、割り当てメンバーシップなど別の方式を決めます。その際は、今後の追加・削除を誰が、どの申請や異動情報をもとに行うかも決めておきます。
アクセスパッケージの自動割り当てで同等の属性条件がない場合も、代替機能を待つだけにせず、終了前に別の割り当て方法を計画する必要があります。
変更後に確認するチェックリスト
- 動的グループ、動的管理単位、自動割り当てポリシーの3種類を調査したか
- 下流のグループや同期処理に、memberOfへの依存が残っていないか
- 変更前に、対象に含める人と除外する人の要件を記録したか
- 変更後のメンバー、管理範囲、アクセスパッケージ割り当てを対象ごとに検証したか
- 属性変更や手動割り当てが今後発生したときの更新担当と確認方法を決めたか
移行の確認では、設定を保存できたかと、意図した対象へ正しく反映されたかを分けて記録します。不要になった設定を整理する際も、それを利用するアクセスや管理範囲を確認してから進めてください。
よくある質問
終了日にグループが自動で削除されますか？
公式の説明は、更新を停止して最後の状態を保持するというものです。自動削除される前提ではなく、古いメンバーや割り当てが残る前提で見直します。
memberOfの取り込み結果を静的グループに同期すれば、そのまま使えますか？
取り込み元がmemberOfに依存している限り、その更新停止の影響を受けます。出力先が静的でも、対象者の基準を最新に保つ仕組みを別途決める必要があります。
代替機能が出るまで待ってよいですか？
確認した公式資料では、代替ソリューションの開発方針は示されていますが、提供日は示されていません。2026年11月3日より前に既存のmemberOf依存を置き換える方針で進めてください。
公式の参照先
Microsoft Learn：Configure dynamic membership groups with the memberOf operator in the Entra Admin Center（preview）（2026年8月5日更新）。
コメント