「Teams にオンプレ AD のセキュリティ グループを入れたのに、人事異動が反映されない……」という相談は本当によくあります。実はこれは設定ミスではなくTeams と Microsoft 365 グループの仕様によるものです。この記事では、その仕組みをわかりやすく整理しながら、現実的な対処パターンと運用設計のポイントを具体的に解説します。
Teams に Active Directory セキュリティ グループを入れても同期されない理由
前提整理：Teams と Microsoft 365 グループ、AD の関係
まずは用語の整理から始めます。
- オンプレ AD セキュリティ グループ オンプレミスの Active Directory 上のグループ。多くの企業でファイルサーバー権限などに利用。
- Microsoft Entra ID（旧 Azure AD）のグループ AD Connect などでオンプレ AD から同期されるクラウド側のグループ。クラウドネイティブなグループもここに存在。
- Microsoft 365 グループ Teams、共有メールボックス、Planner、SharePoint サイトなどの「チームワーク」の土台となるグループ。
- Teams のチーム 実体としては 1 つの Microsoft 365 グループ を参照しており、メンバー／所有者も基本的にこのグループと連動。
つまり、
- Teams のメンバー = 裏側の Microsoft 365 グループのメンバー
- オンプレ AD のセキュリティ グループを Teams に追加する = Microsoft 365 グループに「グループを入れ子にする」試み
という構図になります。
実際に起きていること：「一度きりの展開」
Microsoft の Q&A や公式ブログでも明言されていますが、セキュリティ グループや配布リストをチームにメンバーとして追加すると、その時点で一度だけメンバーが展開されるだけです。以後、元グループのメンバー変更はチームに同期されません。
イメージとしては次のような動きです。
- Teams でメンバー追加の画面から「AD セキュリティ グループ A」を追加する。
- Teams（正確には Microsoft 365 グループ）が、その瞬間の「グループ A のメンバー一覧」を取得して、個々のユーザーとしてメンバーに追加する。
- 実際のメンバー一覧には「グループ A」という行は残らず、展開されたユーザーだけが並ぶ。
- 後日、オンプレ AD で「グループ A」のメンバーを増減しても、Teams 側は一切再計算しない。
このため、次のような状況が頻発します。
- 新入社員をグループ A に追加したのに、Teams のメンバーに現れない。
- 退職者をグループ A から削除したのに、Teams には残ったまま。
なぜ同期してくれないのか（仕様上の制約）
背景には、Microsoft 365 グループがネストされたグループ構造を正式にはサポートしていないという事情があります。Microsoft 365 グループや Teams は「直接メンバーになっているユーザー」を前提に設計されており、「グループの中のグループを逐次読み解いて展開する」処理は行われません。
また、Teams 側でリアルタイムにオンプレ AD グループと同期し続ける仕組みも提供されていないため、「一度きりの展開」+「その後は各自で管理」という現在の仕様になっています。
したがって、
- 「AD グループを Teams に設定しておけば、人が増減しても勝手に同期されるはず」
という期待は現行仕様では実現しません。このギャップをどう埋めるかが、本記事のテーマです。
恒常的に最新のメンバー状態を保つための 4 つのアプローチ
結論として、現実的な解決策は次の 4 パターンです。
| アプローチ | 概要 | 自動同期度 | 必要ライセンス | 実装難易度 |
|---|---|---|---|---|
| 動的メンバーシップ（属性ベース） | 部署などのユーザー属性で Microsoft 365 グループを自動更新 | 高 | Entra ID P1 以上 | 中 |
| PowerShell / Graph による定期同期 | スクリプトで AD グループと Teams のメンバー差分を同期 | 中 | 特別な追加ライセンス不要（要管理者権限） | 中〜高 |
| memberOf 動的ルール（プレビュー） | Entra の動的グループで「グループのメンバーをまとめて取り込む」 | 高 | Entra ID P1 以上 | 中（ただしプレビュー前提） |
| SharePoint のみ AD グループに割り当て | Teams は個別追加、ドキュメント閲覧だけ AD グループで制御 | 中 | 追加ライセンス不要 | 低 |
以下で順番に詳しく見ていきます。
Microsoft 365 グループの動的メンバーシップを使う（最優先候補）
動的メンバーシップとは
Microsoft Entra ID の動的グループ機能を使うと、ユーザーの属性（部署、役職、勤務地、雇用形態など）を条件にして、グループのメンバーを自動更新できます。Microsoft 365 グループにもこの動的メンバーシップを設定できるため、Teams のメンバーも自動的に更新されます。
典型的なルール例：
(user.department -eq "Sales") or (user.country -eq "JP")
このルールを Microsoft 365 グループに設定すると、
- 部署が「Sales」のユーザー
- または国コード（country）が「JP」のユーザー
が自動的にグループ メンバーになり、Teams にも反映されます。
実装ステップ（概要）
管理者ビューでの実装フローは以下のようになります。
- Microsoft Entra 管理センターに管理者アカウントでサインイン。
- [ID] > [グループ] から対象の Microsoft 365 グループ（既存 Team の裏側グループ）を開く。
- [プロパティ] で メンバーシップの種類 を 「動的ユーザー」 に変更。
- [動的メンバーシップルール] を開き、条件式を設定。
- 保存すると、しばらくしてメンバーが自動的に再計算される。
動的グループの更新は通常数分〜数時間で反映されますが、条件やテナントの規模によっては 24 時間程度かかるケースもあります。
ライセンス要件
動的グループ機能は Microsoft Entra ID P1 以上が必要です。厳密には、「動的グループに属する一意のユーザー数分の P1 ライセンス」が必要とされています。
たとえば、動的グループのメンバーとなり得るユーザーが 500 名なら、少なくとも 500 ユーザー分の P1 ライセンスを用意する必要があります。
どんな組織に向いているか
- 人事システムの情報が Entra ID にきちんと流れている組織
- 部署や拠点などの属性が比較的安定しており、テキスト表記がバラバラでない
- 高頻度で Teams メンバーが変わる大規模組織（数百〜数千人）
運用のコツ：属性設計を“ちゃんと”やる
動的メンバーシップを採用する場合、最も重要なのは次の 2 点です。
- 部署・拠点・雇用区分などの属性値を正規化する 例：「営業部」「営業本部」「営業 1 部」などバラバラに付与してしまうと、動的ルールが複雑になりミスの温床になります。
- 属性の責任者を決める 人事システム・ID 管理チーム・IT 部門のどこが属性マスタの責任を持つかを明確にしておきましょう。
| 項目 | うまくいくパターン | トラブルになりがちなパターン |
|---|---|---|
| department 属性 | 「Sales」「Marketing」など英語コードで統一 | 「営業部」「営業本部」「営業」「Sales」が混在 |
| office / country 属性 | 「Tokyo」「Osaka」「JP」など事前に定義 | 人によって「東京」「tokyo」「本社」など表記揺れ |
| 責任範囲 | 人事 or ID 管理チームが一元管理 | 各部門任せで誰も全体を把握していない |
PowerShell / Microsoft Graph で定期同期する（疑似的な自動同期）
考え方：AD グループを“真実のソース”にする
「AD グループ設計はもう出来上がっていて、人事異動の運用もすべて AD 上で完結している」という組織では、AD セキュリティ グループを真実のソースとみなし、定期的に Teams 側を同期するアプローチが現実的です。
基本パターンは以下のとおりです。
- オンプレ AD セキュリティ グループ（例：GRP_Sales）を 1 つ決める。
- 対応する Teams（裏の Microsoft 365 グループ）を 1 つ決める。
- スクリプトで次を行う：
- AD グループのメンバー一覧を取得
- Teams（Microsoft 365 グループ）のメンバー一覧を取得
- 差分を比較し、必要に応じて追加・削除
- このスクリプトをタスク スケジューラや Azure Automation などで定期実行する。
Microsoft の公式ブログでも、PowerShell によるセキュリティ グループと Office 365 グループの同期スクリプト例が紹介されています。
実装イメージ（簡略 PowerShell サンプル）
実際のスクリプトは組織ごとに調整が必要ですが、イメージとしては以下のような流れです。
# 1. 必要なモジュールをインポート
Import-Module Microsoft.Graph.Users
Import-Module Microsoft.Graph.Groups
Import-Module MicrosoftTeams
# 2. 管理者としてサインイン
Connect-MgGraph -Scopes "Group.ReadWrite.All","User.Read.All"
Connect-MicrosoftTeams
# 3. 対象の AD グループと M365 グループを特定
$adGroupSam = "GRP_Sales"
$m365GroupId = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" # Teams の裏グループ ID
# 4. AD グループメンバーを取得（オンプレなら別途コネクタや RSAT など）
$adMembers = Get-ADGroupMember -Identity $adGroupSam -Recursive | Where-Object {$_.objectClass -eq "user"}
# 5. M365 グループメンバーを取得
$m365Members = Get-MgGroupMember -GroupId $m365GroupId -All
# 6. 差分を計算して追加・削除（概略）
# - AD にいるが M365 にいないユーザー → 追加対象
# - M365 にいるが AD にいないユーザー → 削除対象
実際には、ユーザーを GUID ベースで突き合わせたり、ゲスト ユーザーを除外したり、対象外の管理者アカウントをフィルタリングしたり…といった処理が必要です。
運用で押さえておきたいポイント
- 監査ログを必ず残す 「いつ」「誰が」「どのチームから追加／削除されたか」を CSV ログなどで残しておくと、万が一のトラブル時に追跡できます。
- 失敗時の通知 スクリプトのエラー時にメール通知や Teams 通知を飛ばしておくと、「気づいたら 1 週間同期されていなかった」という事態を防げます。
- 手動リカバリ手順を文書化 バグや一時的な API 障害などで同期が壊れた場合に、どの手順でリカバリするかを事前に決めておきましょう。
- 頻度の目安 多くの企業では「1 日 1 回（深夜）」か「1 日 2 回（始業前 + 深夜）」程度で十分なケースが多いです。
どんな組織に向いているか
- 既にオンプレ AD グループがしっかり設計されており、それを活かしたい。
- Entra ID P1 ライセンスを広く配布するのが難しい。
- PowerShell/Graph を扱える IT 管理者がいる。
memberOf 動的ルールを活用した「疑似ネスト」（プレビュー機能）
memberOf 動的ルールとは
memberOf 動的ルールは、Microsoft Entra ID の動的グループ機能の拡張で、別のグループのメンバーを丸ごと取り込んで動的グループを作成できるプレビュー機能です。
ポイントは次のとおりです。
- 対象：セキュリティ グループ、Microsoft 365 グループ、オンプレ AD から同期されたグループ など
- ルール：
memberOf属性を使って、指定したグループのメンバーを抽出 - Teams を含むアプリからは「普通の動的グループ」として見える
この機能を使うと、実際にはネストされているグループ構造を、動的な「フラットなメンバーシップ」に変換することが可能になります。
構成イメージ：オンプレ AD → Entra グループ → 動的 M365 グループ → Teams
- オンプレ AD にセキュリティ グループ GRP_Sales_OnPrem が存在。
- Azure AD Connect などで、Entra ID に同期されたセキュリティ グループ GRP_Sales_Cloud ができる。
- Entra ID で新しい 動的 Microsoft 365 グループ を作成し、メンバーシップを Dynamic User に設定。
- 動的ルールとして memberOf を使用し、「GRP_Sales_Cloud のメンバーをすべて取り込む」ルールを設定。
- この動的 Microsoft 365 グループをベースに Teams のチームを作成する、または既存チームの裏グループとして利用。
こうすることで、オンプレ AD グループのメンバー変更が Entra ID に同期され、その結果として Teams のメンバーも自動更新される形になります。
注意点（現時点ではプレビュー機能）
memberOf 動的ルールは 2024 年時点で「プレビュー」と位置づけられており、いくつか制約や注意点があります。
- 本番環境利用の可否は組織ポリシーに依存（プレビューを本番で使わないという方針も多い）。
- memberOf と他の属性条件を組み合わせることに制限がある。
- memberOf を使った動的グループ同士でのネスト（入れ子）は基本的に非推奨／制限あり。
- 動的グループの数やルールの複雑さには上限がある。
導入する場合は、まずは 限定された部門や検証テナントでパイロット運用し、本番への横展開は慎重に判断することをおすすめします。
どんな組織に向いているか
- Entra ID P1 を既に広く導入している。
- オンプレ AD グループを活かしつつ、Teams 側は自動化したい。
- プレビュー機能のリスクを理解した上で、一定の検証・モニタリングを行える体制がある。
限定的代替策：SharePoint サイトのみセキュリティ グループで共有
「会話は Teams、閲覧権限は SharePoint で」の割り切り
「Teams のメンバーは頻繁には変えないが、ドキュメントだけ AD グループで権限を管理したい」というケースでは、次のような割り切りも選択肢になります。
- Teams のメンバーはユーザー単位（または動的メンバーシップ）で管理する。
- Teams に紐づく SharePoint サイトのライブラリに対し、オンプレ AD セキュリティ グループ（またはクラウド側に同期されたグループ）に読み取り／編集権限を付与する。
この方法だと、
- Teams のチャット／チャネルの会話／Planner／カレンダーなどには AD グループは効かない。
- しかし、ドキュメント ライブラリの参照・編集権限は AD グループだけで管理できる。
つまり、「会話に参加できるメンバー」と「ドキュメントを閲覧できるユーザー」の範囲を意図的に分けることができます。「閲覧専用の部署」「監査部門」など、会話への参加は不要だが資料だけ見たい、というユースケースに向いています。
どの方法を選ぶべきか：ユースケース別おすすめパターン
| 要件 / 状況 | おすすめアプローチ | 理由 |
|---|---|---|
| 部署単位でチームを作り、人事異動に合わせて自動更新したい | 動的メンバーシップ（属性ベース） | 部署や勤務地などの属性に紐づくため、人事異動がシステム属性に反映されれば自動で Teams も更新される。 |
| 既にオンプレ AD グループがきれいに設計されている | PowerShell / Graph による定期同期 | 既存グループを「真実のソース」にできるため、設計を活かしつつ Teams だけ自動追随させられる。 |
| Entra ID P1 を導入済みで、新機能も積極的に試せる | memberOf 動的ルール + 動的 M365 グループ | 「グループのメンバーを動的に展開」できるため、実質的なネストの問題を解消できる。 |
| 会話への参加メンバーは狭く、文書は広く見せたい | Teams メンバーは個人 / 動的、SharePoint は AD グループ | Teams の会話はクローズに保ちつつ、資料は AD グループで簡単に権限管理できる。 |
運用設計の実践ポイント
Teams の「チーム設計」と「権限設計」を分けて考える
よくある失敗は、「AD グループ設計」と「Teams のチーム構造」を 1 対 1 で対応させようとすることです。おすすめは、次のように考え方を分離することです。
- Teams 側：コラボレーション単位（“誰と何を話すか”）
- プロジェクトごと
- 部門ごと
- 社内コミュニティごと
- AD / Entra 側：権限と属性のマスタ（“誰が何者か”）
- 部署、拠点、職位
- システム利用権限
- 外部委託・派遣・パートナー区分
この 2 層構造を意識したうえで、
- Teams のメンバー管理は動的グループ or 定期同期。
- 権限の真実のソースは AD / Entra の属性・グループ。
という役割分担にしておくと、長期的に運用しやすくなります。
オーナー（チーム所有者）の権限と責任を明確にする
どの方式を採用しても、最終的には各チームのオーナーがメンバー構成をチェックすることになります。そこで、次のようなルールを事前に決めておくと安心です。
- オーナーは、月 1 回程度はメンバー一覧を見直す（特に外部ゲスト）。
- 「このチームのメンバーは誰が決めるのか」をチームの説明欄に明記しておく。
- 自動同期が入っているチームでは、オーナーが手動でメンバーをいじらないルールにする。
ゲスト ユーザーの扱いに注意
動的メンバーシップや定期同期は、基本的に 社内ユーザー を対象として設計されます。外部ゲストの扱いは次のように切り分けるとわかりやすくなります。
- ゲストは原則として Teams オーナーが個別招待・個別管理する。
- 同期スクリプトでは「ゲストを一切触らない（削除しない）」ようにする。
- 外部委託など長期ゲストは、Entra 上で属性や専用グループを使って管理する検討もあり。
よくあるトラブルと確認ポイント
「動的にしたはずなのにメンバーが変わらない」場合
動的メンバーシップを設定したのに期待通り動かない場合、次をチェックしてみてください。
- Microsoft 365 グループのメンバーシップの種類が本当に 「動的ユーザー」になっているか。
- ルールの属性名や値に誤りがないか（例：department ≠ “Sales” のつもりが “Sale” と誤記）。
- 属性自体が Entra ID に正しく同期されているか（オンプレ AD 側で空欄になっていないか）。
- 反映待ち時間（数時間〜最大 24 時間程度）を充分に待ったか。
「同期スクリプトを入れたらメンバーが消えた」場合
定期同期スクリプトでは差分ロジックの誤りから「意図しない大量削除」を起こすリスクがあります。次のような安全策を入れておくと良いでしょう。
- 最初は「削除しないモード（追加だけ）」で数日〜数週間運用してみる。
- 削除対象が一定数（例：全体の 20% 以上）を超える場合は処理を中断するガードを入れる。
- 削除処理前後のメンバー一覧を CSV にエクスポートしておき、ロールバックできるようにする。
まとめ：AD グループをそのまま“入れ子”に使うのは諦めて、設計を選び直す
最後に、本記事のポイントを整理します。
- オンプレ AD のセキュリティ グループを Teams（= Microsoft 365 グループ）のメンバーとして追加しても、同期されるのは最初の一回だけです。
- 以降の AD 側のメンバー増減は自動反映されません。これは仕様であり、「ネストされたグループを継続的に展開しない」という Microsoft 365 グループの設計によるものです。
- 恒常的に最新メンバー状態を保つには、次のいずれか・または組み合わせを選ぶ必要があります。
- 動的メンバーシップ（属性ベース）：Entra ID P1 前提だが最もシンプルで再現性が高い。
- PowerShell / Graph による定期同期：既存の AD グループ設計を最大限活かせる。
- memberOf 動的ルール：プレビュー機能だが、擬似的にネスト問題を解決できる。
- SharePoint のみを AD グループで共有：閲覧専用シナリオ向けの割り切り案。
- どのアプローチを取るにしても、
- ユーザー属性の正規化
- 「真実のソース」をどこに置くかの設計
- チーム オーナーの役割定義
「AD グループをそのまま Teams に入れておけば何とかなるだろう」という感覚から一歩踏み出し、動的メンバーシップや自動同期スクリプトを前提とした設計に切り替えることで、日々のメンテナンス負荷とヒューマンエラーを大幅に減らすことができます。これから Teams／Microsoft 365 の導入や再設計を行うタイミングであれば、ぜひ今回の 4 パターンをベースに、自組織に最適なモデルを検討してみてください。
コメント