Microsoft Entra ID Governance / My Groups のセルフサービス グループ作成で、2026年4月16日時点で押さえるべきポイントは明確です。My Groups の Microsoft 365 グループ作成体験が刷新され、利用者が作成時点でメール、セキュリティ、秘密度ラベル、外部送信者、Outlook 表示などの重要設定を意識しやすくなりました。これにより、管理者が後から修正する運用ではなく、作成時に正しい既定値と判断を促すガバナンスへ寄せやすくなります。Microsoft はこの更新を Microsoft Entra ID Governance の新機能として案内し、My Groups での Microsoft 365 グループ作成体験を一般提供として位置付けています。(TECHCOMMUNITY.MICROSOFT.COM)
ただし、この刷新だけでグループの乱立、所有者不在、不要なゲストアクセス、似た名前のグループ増殖が自動的に解決するわけではありません。Identity admins と collaboration admins が見直すべきなのは、My Groups の画面そのものよりも、誰に作成を許可するか、作成時に何を選ばせるか、作成後にどう棚卸しするかです。
Microsoft Entra ID Governance / My Groups の刷新で何が変わるのか
今回の更新は、単なる UI 改善ではありません。Microsoft のリリースノートでは、My Groups の新しい Microsoft 365 グループ作成体験により、グループ所有者が作成時から主要なグループ設定、メール設定、セキュリティ設定を構成できるようになると説明されています。対象には、利用ガイドライン、メール エイリアス、秘密度ラベル、Exchange 関連設定、メール送信者制御、グローバル アドレス一覧での表示、外部送信者の許可・ブロック、必要に応じたセキュリティ グループ機能などが含まれます。(Microsoft Learn)
従来のセルフサービス運用では、ユーザーが急いでグループを作成し、後から管理者が「名前が分かりにくい」「外部送信者を許可してよいのか不明」「Outlook に表示されて邪魔」「秘密度ラベルが未設定」といった問題を修正するケースが起こりがちでした。刷新後は、作成時の入力・選択項目が増えることで、所有者が最初から用途や公開範囲を意識しやすくなります。
| 変更点 | 管理者にとっての意味 | スプロール対策で見るべきポイント |
|---|---|---|
| メール エイリアスを作成時に意識しやすくなる | 後からエイリアス修正や重複調整をする負担を減らせる | 命名規則と禁止語を先に整備する |
| 秘密度ラベルを作成時に選ばせやすくなる | 公開範囲、ゲスト、デバイス制御をポリシー化しやすい | 「機密」「社外共有可」などの判断基準を明文化する |
| Exchange 関連設定を作成時に扱える | Welcome メール、会話購読、Outlook 表示の初期設定ミスを減らせる | Outlook に出すべきグループと出さないグループを分ける |
| メール送信者や外部送信者を制御しやすくなる | 外部からの誤送信・不要な受信経路を減らせる | 社外送信を許す条件を業務単位で決める |
| セキュリティ グループ機能を必要に応じて有効化できる | コラボレーション用途とアクセス制御用途の境界を考えやすくなる | 「Teams 用」と「権限付与用」を混在させない |
重要なのは、My Groups が「グループ作成を自由にするための入口」から、「作成者に責任ある選択をさせる入口」へ近づいた点です。特にグローバル企業では、IT 部門が各地域・各部門の小さな共同作業まで中央集権的に承認していると、業務スピードが落ちます。一方で完全放任にすると、同じ目的のグループ、所有者不在のグループ、使われない Teams や SharePoint サイトが増えます。今回の刷新は、その中間にある「統制されたセルフサービス」を設計しやすくする更新です。
そもそも My Groups のセルフサービス管理でできること
Microsoft Entra ID のセルフサービス グループ管理では、ユーザーがセキュリティ グループや Microsoft 365 グループを作成・管理できます。グループ所有者はメンバーシップ要求を承認または拒否でき、メンバー管理を委任できます。ただし、セルフサービス グループ管理はメールが有効なセキュリティ グループや配布リストには対応していません。(Microsoft Learn)
この前提を理解していないと、管理者と利用者の期待がずれます。たとえば、ユーザーが「部署の配布リストを My Groups で管理したい」と考えても、対象が配布リストであれば My Groups のセルフサービス管理とは別の管理経路になります。逆に、Teams、SharePoint、Planner、Outlook などの共同作業の土台として Microsoft 365 グループを作る場面では、My Groups の作成体験がガバナンスに直結します。
また、Microsoft Entra ID P1 または P2 ライセンスがない場合でも一部のグループ管理は可能ですが、ユーザーがグループ参加を要求したり、所有者が参加要求を承認・拒否したりするシナリオには P1 または P2 が必要です。ライセンス要件は、セルフサービスをどこまで開放するかを決める際の現実的な制約になります。(Microsoft Learn)
管理者が受ける影響は「作成権限」より「作成品質」にある
今回の更新を見て、「ユーザーがグループを作りやすくなるなら、乱立が増えるのでは」と考える管理者は少なくありません。しかし本質は、作成数そのものではなく、作られるグループの品質をどう担保するかです。
Microsoft 365 グループは、作成されるとメールボックス、予定表、SharePoint サイト、Teams など複数のコラボレーション資産に波及することがあります。そのため、1つのグループ作成ミスが、アドレス帳の見通し、外部共有、情報分類、所有者管理、監査対応に影響します。
スプロール制御で見るべき観点は、次の4つです。
| 観点 | 悪い状態 | 目指す状態 |
|---|---|---|
| 名前 | Project, Test, Sales New のように用途が曖昧 | 部門、用途、地域、プロジェクト種別が分かる |
| 所有者 | 1人だけ、または退職者のまま | 最低2人の業務所有者がいる |
| 分類 | 秘密度ラベル未設定、公開範囲が不明 | ラベルで公開範囲やゲスト可否を判断できる |
| ライフサイクル | 作成後に誰も見直さない | 有効期限、アクセスレビュー、利用状況確認がある |
Microsoft のグループ管理ベストプラクティスでも、セルフサービス管理、命名ポリシー、期限切れポリシー、秘密度ラベル、動的グループ、アクセスレビュー、複数所有者の割り当てなどが推奨事項として整理されています。(Microsoft Learn)
まず見直すべきセルフサービス作成権限
Microsoft 365 グループは、既定ではすべてのユーザーが作成できる構成が基本です。Microsoft は、ユーザーが IT の支援を待たずに共同作業を始められるため、このアプローチを推奨しています。一方、業務上の標準や統制要件がある場合は、特定の Microsoft 365 グループまたはセキュリティ グループのメンバーだけに作成を制限できます。(Microsoft Learn)
判断基準はシンプルです。
| 組織の状態 | 推奨される作成権限設計 |
|---|---|
| 小規模でIT管理者が利用者に近い | 全ユーザー作成可。ただし命名規則と有効期限を設定 |
| 部門数が多く、同名グループが増えている | 作成可ユーザーを「Group Creators」などの承認済みグループに限定 |
| 規制業界、外部共有が多い、監査要件が厳しい | 作成権限を限定し、申請・承認・アクセスレビューを組み合わせる |
| グローバル企業で地域ごとに運用が違う | 作成権限は広めにし、秘密度ラベルと利用ガイドラインで統制 |
作成を制限する場合でも、単に「禁止」するだけでは現場が別の抜け道を探します。たとえば、個人の OneDrive 共有、非公式チャット、外部 SaaS へのファイル持ち出しが増える可能性があります。おすすめは、グループ作成を許可するユーザーに短いトレーニングを実施し、完了者を作成許可グループに追加する運用です。Microsoft のドキュメントでも、ビジネス標準に合わないグループ作成が心配な場合は、トレーニング完了後に許可グループへ追加する考え方が示されています。(Microsoft Learn)
命名ポリシーと禁止語は My Groups 刷新前に整える
My Groups の作成体験が改善されても、命名ルールが曖昧ならスプロールは止まりません。Microsoft Entra ID のグループ名前付けポリシーでは、Microsoft 365 グループの名前やエイリアスに一貫した規則を適用できます。部門、地域、用途、作成者の役割などを表すプレフィックスやサフィックスを付けたり、特定の単語をグループ名やエイリアスで使えないようにしたりできます。(Microsoft Learn)
実務では、次のような命名ルールが扱いやすいです。
| 用途 | 命名例 | ポイント |
|---|---|---|
| 部門横断プロジェクト | PRJ-CRM-Renewal-JP | プロジェクトであること、対象、地域が分かる |
| 部門内コラボレーション | DEPT-Finance-Planning | 部門と用途を明確にする |
| 一時的な検証 | TMP-Copilot-Pilot-2026Q2 | 一時用途であることと期限の目安を入れる |
| 外部共有あり | EXT-PartnerA-Onboarding | 外部関係者を含む可能性を名前で示す |
禁止語には、役員名、給与、人事、法務、監査、機密プロジェクトのコード名などを含めると効果的です。ただし、禁止語の入れすぎは運用を詰まらせます。たとえば HR を禁止すると、正当な人事部門グループまで作れなくなる場合があります。禁止語は「一般ユーザーが勝手に使うと誤認・リスクが大きい言葉」に絞り、正当な用途は管理者作成または申請制にすると運用しやすくなります。
なお、名前付けポリシーのカスタム禁止単語は部分一致ではなく、完全一致で判定されます。大文字・小文字は区別されず、設定できる禁止語は最大5,000フレーズです。(Microsoft Learn)
秘密度ラベルは「ユーザーに選ばせる」だけでは足りない
今回の My Groups 刷新では、作成時に秘密度ラベルを扱いやすくなる点が大きな意味を持ちます。Microsoft 365 グループの秘密度ラベルでは、グループ作成時の一貫したセキュリティとアクセス制御を支援でき、プライバシー、ゲストアクセス、管理されていないデバイスからのアクセスなどを構成できます。(Microsoft Learn)
ただし、ラベル名が分かりにくいとユーザーは正しく選べません。たとえば「Confidential」「Highly Confidential」だけでは、日本語圏の現場では判断に迷うことがあります。以下のように、ラベル名と選択基準をセットで設計するのが実務的です。
| ラベル例 | ユーザー向け説明 | 推奨設定の考え方 |
|---|---|---|
| Public Collaboration | 社内で広く共有してよい共同作業 | プライベート必須にしない。ゲストは原則不可または限定 |
| Internal Only | 社内限定の通常業務 | プライベート推奨。ゲスト追加は不可 |
| External Collaboration | 取引先や委託先との共同作業 | ゲスト可。ただし所有者とアクセスレビューを必須化 |
| Highly Confidential | 人事、法務、経営、未公開情報 | プライベート固定、ゲスト不可、厳格なアクセス制御 |
管理者がやるべきことは、ラベルを増やすことではありません。ユーザーが迷わず選べる粒度に絞ることです。ラベルが多すぎると、作成者は意味を理解しないまま無難そうなものを選びます。結果として「ラベルは付いているが実態と合っていない」状態になり、監査やインシデント対応で役に立ちません。
有効期限ポリシーで「作りっぱなし」を防ぐ
グループのスプロール対策では、作成時の制御だけでなく、作成後のライフサイクル管理が欠かせません。Microsoft Entra ID の Microsoft 365 グループ有効期限ポリシーでは、期限が近づいたグループのうちユーザー アクティビティがあるものは自動更新されます。自動更新されない場合は所有者に更新通知が送られ、更新されないグループは削除されます。削除された Microsoft 365 グループは、30日以内であれば所有者または管理者が復元できます。(Microsoft Learn)
有効期限ポリシーを入れる際の失敗例は、全グループに一律で短すぎる期限を設定することです。たとえば180日で全グループを期限切れ対象にすると、年次業務や監査対応のように利用頻度は低いが必要なグループまで更新対応が発生します。
現実的には、次のように分けて考えるとよいでしょう。
| グループ種別 | 有効期限の考え方 |
|---|---|
| プロジェクト、検証、PoC | 180日〜365日で期限を設ける |
| 部門の常設業務 | 長めの期限、または別の棚卸し方法を組み合わせる |
| 外部ゲストを含むグループ | 有効期限よりアクセスレビューを重視する |
| 法務・監査・人事など高機密 | 自動削除より所有者確認と明示的レビューを優先する |
有効期限ポリシーは「不要なグループを消す仕組み」ですが、機密性の高いグループでは「本当に消してよいか」の判断も重要です。保持ポリシー、法的ホールド、監査要件が関わる場合は、削除よりもアクセス制御と所有者確認を優先してください。
アクセスレビューでゲストと例外を棚卸しする
My Groups で作成しやすくなったグループほど、後からアクセス権の棚卸しが必要になります。Microsoft Entra ID Governance のアクセスレビューは、グループ メンバーシップ、エンタープライズ アプリケーションへのアクセス、ロール割り当てを定期的に確認し、適切なユーザーだけが継続アクセスできるようにする機能です。(Microsoft Learn)
特に見直すべきなのは、外部ゲストを含む Microsoft 365 グループです。Microsoft Entra ID では、ゲストを含むグループをレビュー対象にしたり、Microsoft 365 グループ全体のゲスト ユーザーに対して自動かつ定期的なアクセスレビューを有効にしたりできます。(Microsoft Learn)
実務では、以下のようなレビュー設計が使いやすいです。
| 対象 | レビュー頻度 | レビュー担当者 | 判断基準 |
|---|---|---|---|
| 外部ゲストを含むプロジェクト グループ | 四半期ごと | グループ所有者 | 契約・案件が継続しているか |
| 高機密ラベルのグループ | 月次または四半期 | データ所有者、部門責任者 | 業務上の必要性が説明できるか |
| 例外的に外部送信者を許可したグループ | 四半期ごと | collaboration admin と所有者 | 受信経路がまだ必要か |
| 所有者が1人のグループ | 月次の検出後に是正 | Identity admin | 2人目の所有者を追加したか |
アクセスレビューを形だけ実施しても効果は薄いです。レビュー依頼メールを送るだけでなく、「未回答なら削除候補」「拒否なら自動削除または管理者確認」「外部ゲストは契約終了日と照合」といった後続アクションまで決めておく必要があります。
Identity admins と collaboration admins の役割分担
今回の更新は、Identity admins だけの話でも、Teams や Exchange を見る collaboration admins だけの話でもありません。Microsoft 365 グループは ID、メール、サイト、チーム、アプリ権限の接点になるため、役割分担を明確にしないと運用が曖昧になります。
| 担当 | 主な責任 | 具体的な確認項目 |
|---|---|---|
| Identity admins | 作成権限、グループ設定、アクセスレビュー、ライフサイクル | EnableGroupCreation、作成許可グループ、所有者、ゲスト、期限 |
| Collaboration admins | Teams、SharePoint、Outlook、Exchange 体験 | Outlook 表示、会話購読、外部送信者、チーム化の方針 |
| Security / Compliance admins | ラベル、外部共有、保持、監査 | 秘密度ラベル、ゲスト制御、保持ポリシー、監査ログ |
| Business owners | 用途、メンバー妥当性、継続要否 | グループの目的、参加者、外部関係者、終了タイミング |
よくある失敗は、Identity admins が「作成権限」だけを管理し、collaboration admins が「Teams の設定」だけを管理する分断です。この状態では、ユーザーから見るとグループ作成の判断基準がばらばらになります。My Groups の刷新をきっかけに、共同作業用グループの作成基準を1枚の社内ガイドにまとめると効果的です。
管理者が今すぐ確認すべきチェックリスト
2026年4月16日時点で My Groups の新しい Microsoft 365 グループ作成体験を前提にするなら、まず以下を確認してください。
| 確認項目 | 判断ポイント |
|---|---|
| My Groups で新しい作成体験が利用できるか | テナントで表示される項目を実際の一般ユーザー権限で確認する |
| 誰が Microsoft 365 グループを作成できるか | 全ユーザーか、許可グループ方式かを明文化する |
| 利用ガイドライン URL が整備されているか | 作成者が判断できる短い社内ルールを用意する |
| 命名ポリシーがあるか | 部門、用途、地域、外部共有の有無が名前で分かるか |
| 禁止語が適切か | 役員名、機密部署名、誤認されやすい語を制限する |
| 秘密度ラベルが分かりやすいか | ユーザーが業務判断で選べる説明になっているか |
| 外部送信者とゲスト追加の基準があるか | 取引先、委託先、個人メールをどう扱うかを決める |
| 所有者が2人以上いるか | 退職・異動時に管理不能にならないようにする |
| 有効期限ポリシーを使うか | 一時グループと常設グループを分けて考える |
| アクセスレビューを回しているか | 外部ゲスト、高機密、例外アクセスを定期確認する |
このチェックリストで特に優先度が高いのは、作成権限、命名ポリシー、秘密度ラベル、所有者、アクセスレビューです。ここが未整備のまま My Groups の作成体験だけが便利になると、作成数が増えたときに管理不能になりやすくなります。
おすすめの運用モデル
多くの組織では、「全員禁止」か「全員自由」かの二択にしない方がうまくいきます。おすすめは、リスク別にセルフサービス範囲を変えるモデルです。
| リスク | 例 | 作成方法 | 統制 |
|---|---|---|---|
| 低 | 社内の軽い情報共有、短期検証 | My Groups でセルフサービス作成可 | 命名規則、有効期限 |
| 中 | 部門業務、継続プロジェクト | 許可ユーザーのみ作成可 | ラベル、所有者2人、期限 |
| 高 | 外部ゲストあり、機密情報あり | 申請または承認制 | アクセスレビュー、外部共有制御、監査 |
| 例外 | 法務、人事、経営、M&A | 管理者作成 | 厳格なラベル、最小権限、定期レビュー |
このモデルなら、現場のスピードを落とさずに、危険なグループだけを強く統制できます。My Groups の刷新は、低〜中リスク領域のセルフサービス品質を高める施策として使うのが現実的です。
まとめ：My Groups の刷新は「グループを作らせる機能」ではなく「正しく作らせる仕組み」
Microsoft Entra ID Governance / My Groups の新しい Microsoft 365 グループ作成体験は、グループ作成を単に簡単にする更新ではありません。作成時にメール、ラベル、セキュリティ、外部送信者、Outlook 表示などの判断を前倒しし、グループ所有者に責任ある選択を促すための変更です。
次に取るべき行動は、My Groups の画面確認だけではありません。まず、現在の Microsoft 365 グループ作成権限を確認し、命名ポリシー、禁止語、秘密度ラベル、所有者ルール、有効期限、アクセスレビューを見直してください。そのうえで、低リスクな共同作業はセルフサービスに任せ、高リスクな外部共有や機密データは承認・レビューを組み合わせる運用に移行することが、グループ ガバナンスとスプロール制御の現実的な落としどころです。
コメント