Entra IDのmemberOf廃止は11月3日｜動的グループの対策と置き換え手順

こんにちは。風読珈琲店のカエデです。

Microsoft Entra ID（旧Azure AD）の動的グループで使える「memberOf」演算子が、正式リリースされないまま廃止されることになりました。期限は2026年11月3日。この日以降、memberOfを使ったルールは更新が止まります。

怖いのは、エラーになって気づけるのではなく、グループのメンバーが「その時点の状態のまま固まる」ことです。退職者や異動者が残ったままになり、気づかないうちに権限が残ってしまう可能性があります。この記事では、廃止の中身・影響範囲・使用箇所の洗い出し方・置き換え方を、期限までの作業手順としてまとめます。

memberOf演算子の廃止とは？
1. どんな影響が出る？
まずはmemberOfの使用箇所を洗い出す
置き換え方は5パターン
安全に切り替える手順
1. 特に注意したいポイント
まとめ

memberOf演算子の廃止とは？

期限を示すカレンダー — Photo by Leeloo The First on Pexels

memberOfは、動的メンバーシップルールの中で「別のグループに所属しているかどうか」を条件にできる演算子です。たとえば次のように書くと、2つのグループのどちらかに所属するユーザーを自動で集めるグループが作れます。

user.memberof -any (group.objectId -in ["<グループAのID>", "<グループBのID>"])

便利な機能でしたが、プレビューのまま4年以上が過ぎ、Microsoftは正式リリースではなく廃止を選びました。主なポイントは次のとおりです。

廃止日：2026年11月3日
対象：動的グループ、動的管理単位（Administrative Units）、エンタイトルメント管理の自動割り当てポリシーのうち、memberOfを使っているもの
廃止後の挙動：ルールの評価が止まり、メンバーシップは最後の状態のまま固定される（追加も削除もされない）
廃止の理由：memberOfのルールが1つでもあると、テナント全体の動的メンバーシップ処理が遅くなることがあり、本番環境での利用に向かないため

「1つでもあるとテナント全体に影響する」というのが今回のポイントです。自分の担当範囲で使っていなくても、テナントのどこかに残っていれば全体の処理に影響するので、テナント単位での棚卸しが必要になります。

どんな影響が出る？

固定されたグループが何に割り当てられているかによって、影響の大きさが変わります。

条件付きアクセスの対象・除外：新しいメンバーにポリシーが適用されない、除外されるべき人が除外されない
ライセンスの割り当て：新入社員にライセンスが付かない、退職者のライセンスが外れない
アプリやTeams・SharePointのアクセス権：異動前の部署のデータにアクセスし続けられる
Intuneのポリシー配布：新しい端末やユーザーに構成プロファイルが届かない

会社の端末を管理するIntuneについては、管理画面の変更点を下記記事でもまとめています。

Intune新デバイスページの便利な点・不便な点まとめ【2026年9月変更】

2026年9月28日の週からIntune管理センターの新しいデバイスページが標準になり、旧画面には戻せなくなりました。タブ構成の変化、操作状況の一元表示など便利になった点と、手順書の作り直しや操作位置の変化など不便になった点、移行時のチェックポイントを整理します。

まずはmemberOfの使用箇所を洗い出す

コマンドを入力するノートPC — Photo by Kevin Ku on Pexels

最初の作業は棚卸しです。Microsoft Graph PowerShellを使うと、memberOfを含むルールを一覧で出せます。

Connect-MgGraph -Scopes "Group.Read.All","AdministrativeUnit.Read.All"

# 動的グループ
Get-MgGroup -All -Filter "groupTypes/any(c:c eq 'DynamicMembership')" `
  -Property Id,DisplayName,MembershipRule |
  Where-Object { $_.MembershipRule -match 'memberof' } |
  Select-Object DisplayName, Id, MembershipRule

# 動的管理単位
Get-MgDirectoryAdministrativeUnit -All -Property Id,DisplayName,MembershipRule |
  Where-Object { $_.MembershipRule -match 'memberof' } |
  Select-Object DisplayName, Id, MembershipRule

洗い出したら、グループごとに次の情報を表にしておくと、優先順位を付けやすくなります。

参照しているグループ：memberOfの中で指定している元グループのIDと名前
割り当て先：条件付きアクセス、ライセンス、アプリ、Intuneなど
条件の種類：「所属している人を含める」のか、「NOTで除外する」のか
担当者：そのグループを作った人・管理している人

エンタイトルメント管理（アクセスパッケージ）の自動割り当てポリシーは上記のコマンドでは出てこないので、Entra管理センターかGraph APIで別途確認してください。

置き換え方は5パターン

memberOfの代わりになる方法は、元のグループが「どう決まっているか」によって選びます。

代替手段	向いているケース
ユーザー属性で直接ルールを書く	元のグループが部署・役職・会社名などの属性で決まっている（第一候補）
識別用の属性を付与する	所属を属性に変換できる。人事システム連携や、オンプレADのextensionAttributeから同期
静的なグループの入れ子（ネスト）	割り当て先が入れ子グループに対応している
自動化で静的グループに同期	属性で表せない複雑な組み合わせ（Azure Automation／Logic Apps＋Graph）
アクセスパッケージ／ライフサイクルワークフロー	申請・承認制にしたい、入社・異動・退職のタイミングで管理したい

① ユーザー属性で直接ルールを書く（第一候補）

元のグループ自体が動的グループで、department（部署）などの属性で決まっているなら、その条件を新しいルールにそのまま書けばOKです。

# 変更前
user.memberof -any (group.objectId -in ["<営業部グループのID>", "<企画部グループのID>"])

# 変更後
(user.department -eq "営業部") or (user.department -eq "企画部")

一番シンプルで処理も軽いので、まずはこの書き換えができないかを検討します。

② 識別用の属性を付与する

元のグループが手作業で管理する静的グループの場合は、所属を表す値を属性に持たせます。extensionAttribute1〜15（オンプレADから同期）や、カスタムセキュリティ属性・ディレクトリ拡張属性が使えます。

user.extensionAttribute5 -eq "PROJECT-X"

属性を誰が・いつ設定するのかという運用ルールもあわせて決めておかないと、新しいメンバーに属性が付かずに漏れが出ます。

③〜⑤ 入れ子・自動化・アクセスパッケージ

入れ子グループ：ライセンス割り当てなど、入れ子グループに対応していない機能もあるので、割り当て先ごとに対応状況を確認する
自動化で同期：元のグループのメンバーを定期的に静的グループへコピーする。実行間隔の分だけ反映が遅れること、スクリプトが止まったときの監視が必要なことに注意
アクセスパッケージ／ライフサイクルワークフロー：「自動で集める」から「申請・承認で付与し、期限で外す」へ考え方を変える方法。権限の棚卸しも一緒にできる

安全に切り替える手順

オフィスで打ち合わせをするチーム — Photo by RDNE Stock project on Pexels

いきなり既存のルールを書き換えると、条件のミスでメンバーが一気に外れることがあります。並行運用で差分を確認してから切り替えるのが安全です。

1. 新しいルールでテスト用グループを作る：既存のグループには触らない
2. 新旧のメンバーを比較する：下のコマンドで差分を確認する
3. 差分がなくなったら切り替える：既存グループのルールを書き換えれば、グループIDが変わらないので割り当て先の設定変更が不要
4. テスト用グループを削除する

$old = Get-MgGroupMember -GroupId "<既存グループID>" -All | Select-Object -ExpandProperty Id
$new = Get-MgGroupMember -GroupId "<テスト用グループID>" -All | Select-Object -ExpandProperty Id
Compare-Object $old $new

動的グループのルール編集画面にある「ルールの検証（Validate Rules）」を使うと、特定のユーザーが条件に合うかを保存前に確認できます。

特に注意したいポイント

NOT条件の除外グループ：「memberOfでないユーザー」のような除外ルールは、置き換えに漏れがあると除外が効かずに対象者が広がる。条件付きアクセスやライセンスに関わるものから優先して直す
期限後は気づきにくい：11月3日を過ぎてもグループはエラーにならず、見た目は今までどおり。期限前に全件を移行するか、ルールを削除しておく
ルールの処理時間：ルールを変更してから反映されるまで時間がかかることがある。業務時間外に切り替え、翌日に結果を確認する

社内の情報管理まわりでは、最近の情報漏えいの事例も下記記事でまとめています。