Microsoft Entra ID（旧Azure AD）の動的メンバーシップグループで部署や役職ごとにTeamsとSharePointの権限を配り、年1回の内部監査でアクセス権の棚卸し証跡を求められている。数千人規模の企業でID基盤を預かる情報システム部門には、2026年11月3日という期限がある。Microsoftはこの日、動的グループのルールで使える memberOf 演算子を廃止する[1]。
memberOf は、別のグループに所属していることを条件に、そのメンバーを自動で別グループへ入れる書き方だ。影響はグループだけにとどまらず、動的管理単位とエンタイトルメント管理の自動割り当てポリシーの3機能に及ぶ[1]。
やっかいなのは、これがエラーで止まる変更ではないことだ。廃止後、これらの構成は更新を停止し、最後の既知の状態のまま残る[1]。グループは消えず、メンバーも入ったままなので、監視にもヘルプデスクにも何も上がらない。ずれは静かに溜まり、監査で初めて露見する。この記事では、凍結が具体的にどこへ効くかを4つに分解し、11月3日までに何を洗い出して何へ移すかの判断材料を整理する。
予備知識
- 動的メンバーシップグループ: ユーザーやデバイスの属性を条件式で書くと、一致する対象を自動でメンバーにしてくれるEntra IDのグループ。手作業での追加削除が要らない。
- memberOf演算子: 「別のグループのメンバーであること」を条件に書けるルール構文。グループを入れ子のように束ねられる。
- 動的管理単位: 管理者の権限が及ぶ対象範囲を、条件式で自動的に絞り込む仕組み。支社単位の管理委任などに使う。
- エンタイトルメント管理の自動割り当てポリシー: 条件に一致した人へ、アプリやサイトの権限一式（アクセスパッケージ）を自動で配る仕組み。
動的グループと条件付きアクセスが管理画面上でどうつながっているかを実機ベースで確認でき、棚卸し対象の見落としを減らせる
memberOf演算子は何を自動化していたのか、廃止はいつか
memberOf演算子は、別グループへの所属を条件に動的グループのメンバーを決める書き方で、2026年11月3日に廃止される[1]。
公式ドキュメントに載っている書式は user.memberof -any (group.objectId -in ['groupId']) と device.memberof -any (group.objectId -in ['groupId']) の2つだ[1]。前者はユーザー、後者はデバイスを対象にする。既存のグループIDを条件に書けるため、部門グループをいくつか束ねて本部グループを作る、拠点ごとのデバイスグループをまとめて配布リングを作る、といった階層構造を属性ではなくグループで表現できた。
この書きやすさが採用理由になっていた組織は多い。人事システムから同期される属性が部署コードしかない場合でも、既存グループを部品として組み合わせれば、実態に近い括りが作れるからだ。一方でMicrosoftの公式ドキュメントは、memberOfをプレビュー段階の機能として扱い、制限がある旨を継続して注意喚起していた。本番の権限配布をプレビュー機能に乗せていた構成が、期限付きで整理を迫られる形になる。
ここで先に押さえておきたい制限が1つある。公式ドキュメントは、子グループが削除された場合やメンバーが子グループから外れた場合、memberOf動的グループのメンバーシップは自動更新されず、対象の利用者やデバイスはルールを変更するまでメンバーのまま残ると明記している[1]。つまり「退職者や異動者が残る」という症状は、廃止によって新たに生じる問題ではなく、プレビュー段階から存在していた。実際、参照グループの一部が既に存在しないのにルールは残りのグループで動き続け、Entra IDは無効な部分について何も示さなかった、という運用報告もある[2]。廃止はこのずれを止める話ではなく、更新そのものを止める話になる。
期限は3機能に共通で2026年11月3日である[1]。運用担当が分かれていても、対象の洗い出しは1本の期限に向けてまとめたほうが漏れが出ない。
入社から異動・退職までのライフサイクルとして権限を捉え直せるので、自動化が止まったときにどこがずれるかを構造で説明できる
停止ではなく凍結、エラーが出ないまま権限がずれていく
廃止後のルールは失敗を返さない。更新を停止し、最後の既知の状態のまま残る[1]。この挙動が、検知を難しくする最大の要因になる。
グループは削除されず、メンバーも消えず、設定画面を開けばルールも残っている。変わるのは、条件に一致するかどうかの再評価が走らなくなる点だけだ。障害通知は飛ばず、実態との差だけが日々広がっていく。
公式ドキュメントは、この状態が古い権限と統制の穴を生むと明記している。挙げられているのは、Teams・SharePointの古いアクセス、条件付きアクセスのターゲティング、グループベースライセンス、アクセスパッケージの割り当ての4つだ[1]。
退職者や異動者がTeamsのチームとSharePointサイトに残る。条件付きアクセスの適用対象グループが更新されず、多要素認証やデバイス準拠の要求が本来かかるべき人にかからない。ライセンスは付いたままか、新入社員に付かないまま放置される。アクセスパッケージの自動割り当ては新規の付与が止まり、申請運用へ静かに逆戻りする。
4つのうち3つは、セキュリティか統制に直結する。ライセンスだけは請求額として月次で表に出るため、気づける可能性がある。残り3つは、次のアクセス権棚卸しまで誰の目にも触れない。
複合機のスキャン送信連携や会議室予約システムなど、Exchange Web Services（EWS、旧来のメール連携API）経由でメール機能を呼び出す社内システムを何年も運用してきた、数千人規模の企業の情報システム部門にとって、2026[…]
棚卸しと移行の選択肢、他の演算子か割り当て済みメンバーシップか
対応は2択だ。11月3日までにmemberOfを使った構成を洗い出し、サポートされる他のルール演算子へ移行するか、割り当て済みメンバーシップへ変換する[1]。
前者は自動化を維持できるが、memberOfで表現していた階層構造を属性の条件式で書き直す必要がある。部署コードや役職コードといった属性が人事システムから正しく同期されているかが前提になり、属性が足りない場合は同期定義の見直しから始まる。後者は確実に動くが、メンバーの追加削除が手作業に戻る。
| 移行先 | 自動更新 | 前提条件 | 向くケース | 監査での説明 |
|---|---|---|---|---|
| 他のルール演算子へ書き換え | 維持される | 部署・役職などの属性が正しく同期されている | 属性で表現できる部門単位・拠点単位のグループ | ルール定義そのものが統制の証跡になる |
| 割り当て済みメンバーシップへ変換 | 停止する | 追加削除の運用手順と承認フローの整備 | 属性で表現できない横断組織・プロジェクト単位 | 承認記録と棚卸し記録の両方が必要になる |
現実には併用になる。属性で素直に書けるグループは演算子の書き換えで残し、部門をまたぐ委員会やプロジェクトのように属性へ落ちない括りは割り当て済みへ倒す。この切り分けを先に決めておくと、洗い出した対象を1件ずつ判断せずに済む。
切り替え前後でメンバー一覧を取得し、差分を突き合わせる工程は省かないほうがいい。凍結の性質上、移行に失敗してもエラーは出ないため、差分の確認だけが唯一の検証手段になる。
数千人規模でAzure MonitorとDatadogを併用し、年次のコスト監査で監視ツール契約の妥当性を問われる企業のITインフラ担当者は、今回の発表を無視できない。対象はマイクロソフトのAzure Monitor、具体的にはSLI（サ[…]
4月・10月の人事異動と内部統制監査が重なる日本企業固有の事情
日本企業では、11月3日という期限が10月の異動直後に来る点が固有のリスクになる。しかも2026年11月3日は火曜日の文化の日で、多くの企業は休業日にあたる。実務上の最終営業日は10月30日（金）と見ておくのが安全で、10月の異動対応と移行作業を同じ月に収める必要がある。
異動が通年で分散する企業では、凍結の影響も少しずつ現れる。日本の多くの企業は4月と10月に異動が集中するため、10月異動で組み替えたばかりのグループ構成が、そのまま更新停止に入る。11月以降の中途採用や年度末の組織変更は、動的グループへ一切反映されない。年度末の監査で対象期間全体を見たとき、10月以降だけ棚卸し証跡と実態が合わないという形で表面化する。
もう一点は体制の違いだ。ID基盤の設定変更をSIerの保守契約の範囲でしか触れない企業では、変更依頼から見積、稟議、作業窓の確保までにひと月以上かかる。9月に着手して10月の異動対応と重ねるのが現実的な線になる。
| 論点 | 通年で異動が分散する企業 | 4月・10月に異動が集中する日本企業 |
|---|---|---|
| 凍結の現れ方 | 少しずつ、広く | 10月異動分が丸ごと固定される |
| 気づく契機 | 個別の権限トラブル | 年度末の内部統制監査 |
| 作業に必要な期間 | 数週間 | 稟議と作業窓の確保で1〜2か月 |
| 求められる証跡 | 変更履歴 | 棚卸し結果と承認記録の両方 |
IT部門の判断は、10月の異動対応と移行作業を同じ変更として設計し、切り替え後のメンバー差分を棚卸し証跡としてそのまま残すこと。決裁側の判断は、この作業を機能追加ではなく期限のある統制維持として扱い、9月着手を前提に予算と作業窓を確保することだ。
よくある質問（FAQ）
Q. 11月3日を過ぎると、グループやメンバーは消えるのか。
消えない。グループもメンバーも残り、ルール定義も画面上に表示され続ける。止まるのは条件の再評価だけで、以後は最後の既知の状態のまま固定される[1]。
Q. 廃止されたことに気づくためのエラーやアラートは出るのか。
公式ドキュメントに記載があるのは、更新が停止して最後の状態のまま残るという挙動だけだ[1]。障害として通知される前提では考えず、期限前の洗い出しで対象を把握しておく必要がある。
Q. 影響を受ける構成をどう探せばよいか。
動的メンバーシップグループ、動的管理単位、エンタイトルメント管理の自動割り当てポリシーの3機能について、ルール文字列に memberOf を含むものを抽出する[1]。管理単位と自動割り当てポリシーはグループより管理者の目に触れにくいため、見落としやすい。なお、この廃止はMicrosoft 365管理センターのメッセージセンターでも告知されており、告知番号は MC1448379 である[2]。自テナントでの裏取りはこの番号で引ける。
まとめ
この変更の本質は、機能が失われることではなく、失われたことが分からない状態が続くことにある。エラーが出ず、ユーザーからの問い合わせもなく、グループは正常に見える。実態とのずれだけが積み上がり、年度末の監査で古いアクセスとして現れる。
IT部門担当者の次の一手は、3機能を対象にしたルール文字列の全件抽出だ。件数が分からなければ、移行方式の切り分けも工数見積もりも始まらない。抽出した対象を、属性で書けるものと書けないものに分けるところまでを最初の作業単位にすると進めやすい。
決裁側の判断材料は3点に絞られる。費用は既存グループの設定変更が中心で新規調達を伴わないこと、リスクは検知できないアクセス残存として内部統制の指摘に直結すること、時期は10月の異動対応と重ねられる9月着手が現実的な最終ラインであること。11月3日を越えてから気づく場合、影響は10月以降の全異動に遡る。
