動的グループを活用したメーリングリストの作成 ― 入退社時の手動メンテナンスをゼロにする方法
「新入社員をメーリングリストに追加し忘れて、重要なお知らせが届いていなかった」「退職者がメーリングリストに残ったままだった」——メーリングリストの手動メンテナンスは、入退社・異動のたびに発生する地味で漏れやすい作業です。
動的グループを使えば、ユーザーの属性（部署、役職、勤務地など）に基づいてメンバーが自動的に追加・削除され、手動メンテナンスがゼロになります。
動的グループの2つの種類
Microsoft 365環境には、用途の異なる2種類の動的グループがあります。
1. Entra IDの動的グループ（動的メンバーシップ）
用途： セキュリティグループ、Microsoft 365グループのメンバーを属性ベースで自動管理。条件付きアクセスポリシーの適用対象、Intuneのデバイスグループ、ライセンスの自動割り当てなどに使用。
必要なライセンス： Entra ID P1以上（Business Premiumに含まれる）
メンバーシップルールの例：
部署が「営業部」のユーザーを自動追加：
(user.department -eq "営業部")東京オフィスの正社員のみ：
(user.officeLocation -eq "東京") -and (user.employeeType -eq "正社員")2. Exchange Onlineの動的配布グループ
用途： メール配信専用のグループ。メールの宛先として使えるが、SharePointやTeamsのアクセス制御には使えない。
必要なライセンス： Exchange Onlineのすべてのプランに含まれる（追加費用不要）
フィルタの例：
部署が「営業部」のユーザーにメール配信：
Department -eq '営業部'どちらを使うべきか
| 用途 | Entra ID動的グループ | 動的配布グループ |
|---|---|---|
| メール配信 | ○（M365グループの場合） | ○ |
| SharePointのアクセス制御 | ○ | × |
| Teamsのチームメンバー | ○ | × |
| 条件付きアクセスの適用 | ○ | × |
| Intuneのデバイスグループ | ○ | × |
| ライセンスの自動割り当て | ○ | × |
| 必要ライセンス | Entra ID P1 | なし（Exchange標準） |
メール配信だけが目的なら動的配布グループ、セキュリティやアクセス制御にも使うならEntra ID動的グループを選択してください。
実践例1：部署別メーリングリスト
要件： 営業部の全員にメールを配信するリスト。入退社・異動で自動更新。
Entra IDの動的グループで作成する場合：
- Entra管理センター → グループ → 新しいグループ
- グループの種類：「Microsoft 365」（メール配信にも使う場合）または「セキュリティ」
- メンバーシップの種類：「動的ユーザー」
- ルール：
(user.department -eq "営業部") - メールアドレス：sales-all@contoso.co.jp
これで、Entra IDのユーザー属性で「部署＝営業部」が設定されているユーザーが自動的にグループメンバーになります。
前提条件： ユーザーのdepartment属性が正確に設定されていること。属性が空白やバラバラの表記（「営業部」「営業」「Sales」が混在）だと動的グループは機能しません。
実践例2：全社員メーリングリスト（役員除く）
(user.employeeType -eq "正社員") -and (user.department -ne "役員")役員には別途「役員メーリングリスト」を作成。
実践例3：特定の拠点の社員
(user.officeLocation -eq "大阪") -or (user.officeLocation -eq "京都")動的グループの注意点
属性データの品質が前提
動的グループはユーザー属性に依存します。属性データが不正確（部署名の表記揺れ、未入力など）だと、意図しないメンバーが追加されたり、必要なメンバーが漏れたりします。
対策： 動的グループを導入する前に、全ユーザーの属性（部署、役職、勤務地、雇用形態）を棚卸しし、表記を統一してください。入退社フローでは、ユーザー作成時に必ず属性を正確に設定するルールを設けます。
メンバーシップの反映タイムラグ
動的グループのメンバーシップは即時反映ではなく、Entra IDのバックグラウンド処理で更新されます。通常は数分〜数十分で反映されますが、大量のユーザー変更が同時に発生した場合は最大24時間かかる場合があります。
グループネストの制約
動的グループを別のグループのメンバーとして入れ子（ネスト）にすることは可能ですが、動的グループ自体のメンバーシップルールに「別のグループのメンバーであること」を条件にすることはできません。
動的グループの上限
1テナントあたりの動的グループの作成上限は5,000個です（2026年時点）。中小企業であれば十分な数です。
静的グループから動的グループへの移行
既存の静的メーリングリスト（手動管理）を動的グループに移行する場合の手順：
Step 1： 既存グループのメンバー一覧と、動的ルールで算出されるメンバー一覧を比較し、差異を確認。
Step 2： 差異の原因（属性の未設定、表記揺れ）を修正。
Step 3： テスト用の動的グループを作成し、メンバーが正しく算出されることを確認。
Step 4： 既存の静的グループを動的グループに切り替え（または新しい動的グループに置き換え）。
Power Automateとの連携
動的グループのメンバー変更をトリガーにしてPower Automateのフローを実行する直接的な方法はありませんが、以下のような連携が可能です。
- 動的グループのメンバーに変更があった場合、定期スケジュール（日次）でメンバー一覧を取得し、前回との差分をTeamsに通知。
- 新しいメンバーが追加されたら、ウェルカムメールを自動送信。
まとめ
動的グループは「入退社・異動のたびにメーリングリストを手動で更新する」作業を完全に自動化する仕組みです。前提として属性データの品質が重要なので、まずユーザー属性の棚卸しと統一から始めてください。
情シス365では、Entra IDのグループ設計、動的グループの構築、属性データの整備を支援しています。お気軽にご相談ください。