Manage Groups in Microsoft Graph – Microsoft Graph v1.0 を見て、「既存のグループ管理スクリプトを直す必要があるのか」「管理者はどこを確認すべきか」と迷った場合、最初に押さえるべき結論は次のとおりです。今回の公式情報は、Microsoft Graph のグループ管理を丸ごと置き換えるような破壊的変更というより、管理できるグループ種別、所有者なしグループ対策、動的メンバーシップ、ライセンス、ゲスト権限、API実装時の注意点を整理した内容です。特に管理者と開発者は、「どのグループが Graph で更新できるのか」「所有者をどう維持するのか」「アプリ権限と管理者ロールが過剰になっていないか」を早めに確認する必要があります。Microsoft Graph のグループは、ユーザー、デバイス、アプリケーションなどをまとめてリソースアクセスを管理するためのコンテナーであり、グループ関連操作には管理者の同意が必要です。(Microsoft Learn)
Microsoft Learn の英語版では該当ページの最終更新日が 2026年5月12日と表示されています。日本時間での確認や社内周知では 2026年5月13日の情報として扱われる場合があるため、本記事では 2026年5月13日時点で確認すべき公式情報として整理します。(Microsoft Learn)
まず押さえる結論：移行よりも「管理対象の切り分け」が重要
今回の Manage Groups in Microsoft Graph の内容で最も重要なのは、「Microsoft Graph でグループを管理できる」と一括りに考えないことです。Microsoft Graph groups API で作成・更新などの管理対象になるのは主に Microsoft 365 グループとセキュリティ グループです。一方、メールが有効なセキュリティ グループと配布グループは読み取り専用として扱われ、動的配布グループは Microsoft Graph ではサポートされません。(Microsoft Learn)
つまり、既存の管理画面やバッチ処理を Microsoft Graph に寄せる場合は、最初にグループの棚卸しが必要です。displayName だけで判断せず、groupTypes、mailEnabled、securityEnabled を見て、Graph で更新できる対象かどうかを分類します。
GET /v1.0/groups?$select=id,displayName,groupTypes,mailEnabled,securityEnabledこの確認を省くと、配布グループやメール有効セキュリティ グループに対して更新処理を実行し、アプリ側でエラー処理や例外対応が増える原因になります。
変更点として読むべきポイント
公式情報の読みどころは、新しいエンドポイントが1つ追加されたかどうかだけではありません。グループを実務で安全に管理するために、所有権、メンバーシップ、ライセンス、検索制限、外部データストアのプロパティまで含めて確認すべき点が整理されています。
特に注目すべき点は、所有者なしグループに対応する ownerlessGroupPolicy です。このリソースは、唯一の所有者を失った Microsoft 365 グループに対して、アクティブなメンバーへ所有権を引き受ける通知を送るためのポリシーを表します。通知期間、通知対象メンバー数、所有者候補の条件を設定できます。(Microsoft Learn)
また、ドキュメント履歴上でも ownerlessGroupPolicy の v1.0 API、リソース、権限定義が追加・更新されたことが確認できます。管理者にとっては、単なるAPI追加ではなく、「所有者がいないグループを放置しない運用」を Microsoft Graph から扱いやすくなった点が実務上のポイントです。(GitHub)
影響を受ける対象者
| 対象者 | 影響 | すぐ確認すべきこと |
|---|---|---|
| Microsoft 365 管理者 | Microsoft 365 グループ、Teams、SharePoint、Planner などの共同作業基盤に影響 | 所有者が1人以下のグループ、期限切れポリシー、ゲスト利用の有無 |
| Microsoft Entra ID 管理者 | セキュリティ グループ、動的メンバーシップ、ロール割り当てに影響 | グループ種別、管理者ロール、P1ライセンス、属性ベースのルール |
| Microsoft Graph 開発者 | /groups API の作成・取得・更新・削除、権限設計に影響 | Group.Create、Group.ReadWrite.All、$select、所有者指定の有無 |
| セキュリティ担当者 | 過剰権限、所有者不在、属性改ざんによる不正なグループ参加がリスク | 最小権限、動的ルールに使う属性の書き込み権限、監査ログ |
| ヘルプデスク・運用担当 | ゲストユーザーの検索制限やグループ所有者不在による問い合わせが増える可能性 | ゲストの検索仕様、所有者追加手順、エスカレーション先 |
Microsoft Graph で管理できるグループとできないグループ
Microsoft Graph のグループ種別は、名称ではなくプロパティの組み合わせで判定します。公式情報では、groupTypes、mailEnabled、securityEnabled が主な判定材料として示されています。(Microsoft Learn)
| グループ種別 | 判定に使う主なプロパティ | Microsoft Graph groups API での管理 | 実務での使いどころ |
|---|---|---|---|
| Microsoft 365 グループ | groupTypes: ["Unified"]、mailEnabled: true | 可能 | Outlook、SharePoint、Teams、Planner などの共同作業 |
| セキュリティ グループ | groupTypes: []、mailEnabled: false、securityEnabled: true | 可能 | アプリ、リソース、条件付きアクセス、ライセンス割り当て |
| メールが有効なセキュリティ グループ | groupTypes: []、mailEnabled: true、securityEnabled: true | 読み取り専用 | メール配信とアクセス制御の両方を担う既存運用 |
| 配布グループ | groupTypes: []、mailEnabled: true、securityEnabled: false | 読み取り専用 | メール配信リスト |
| 動的配布グループ | 対象外 | サポートされない | Exchange 側の配布リスト運用 |
この表から分かるように、Graph 移行で失敗しやすいのは「メールが使えるグループだから Microsoft 365 グループだろう」と判断するケースです。メールが有効でも、groupTypes に Unified がなければ Microsoft 365 グループではない可能性があります。
管理者が確認すべき設定
管理者同意と最小権限を見直す
Microsoft Graph のグループ関連操作には管理者同意が必要です。さらに、実際にグループを管理するユーザーには、Microsoft Graph の権限だけでなく、対応する Microsoft Entra ロールも必要です。公式情報では、グループ管理者が主要なロールとして示され、最小特権ロールとして Directory Writers、Groups Administrator、User Administrator が挙げられています。(Microsoft Learn)
開発者がアプリ権限を申請する場合も、最初から Directory.ReadWrite.All を要求するのは避けるべきです。たとえば、グループ作成ではアプリケーション権限の最小特権として Group.Create が示されています。所有者やメンバーとしてユーザーを指定する場合は、対象オブジェクトを読み取るための追加権限が必要になる点にも注意が必要です。(Microsoft Learn)
所有者なしグループを放置しない
グループは1人以上の所有者を持つことができ、公式情報では継続性確保のために少なくとも2人の所有者を割り当てることが推奨されています。所有者が1人だけのグループは、退職、異動、アカウント削除によって一気に管理不能に近い状態になります。(Microsoft Learn)
ownerlessGroupPolicy を使うと、所有者なしグループのアクティブなメンバーに通知を送り、所有権の引き受けを促す運用を構成できます。ただし、APIで作成または更新する場合は注意が必要です。PATCH /policies/ownerlessGroupPolicy は、ポリシーを有効化または構成変更する際に必要プロパティをまとめて指定する必要があり、管理ポータルのように多くの既定値を自動適用しません。また、isEnabled を false にすると他のポリシーパラメーターの値がクリアされます。(Microsoft Learn)
| 確認項目 | 判断基準 | 取るべき対応 |
|---|---|---|
| 所有者が0人のグループ | 誰も管理できない状態になりやすい | ownerlessGroupPolicy や管理者による所有者追加を検討 |
| 所有者が1人のグループ | 退職・異動で所有者なしになるリスクが高い | 原則2人以上の所有者にする |
| 通知対象を全グループにするか | enabledGroupIds が空の場合、全グループ対象になる | 段階展開では対象グループIDを明示 |
| 通知メンバー数 | maxMembersToNotify は 0〜90 | 大規模グループでは通知対象を絞る |
| 通知期間 | notificationDurationInWeeks は 1〜7 | 社内承認フローに合う期間を設定 |
動的メンバーシップは便利だが、属性管理まで含めて設計する
動的メンバーシップは、ユーザーやデバイスの属性に基づいてグループ参加を自動化する仕組みです。たとえば、user.department -eq "Marketing" のようなルールで、部門が Marketing のユーザーを自動的に追加できます。Microsoft Graph の概要では、動的グループのメンバーにできるのはユーザーとデバイスのみで、動的メンバーシップには一意のユーザーごとに Microsoft Entra ID P1 ライセンスが必要とされています。(Microsoft Learn)
ただし、動的メンバーシップをアクセス制御に使う場合は、ルールに使う属性の書き込み権限を必ず確認してください。Microsoft Entra の公式情報では、動的グループのルールに使う属性を誰が変更できるかによって、そのグループのセキュリティが左右されると説明されています。オンプレミス Active Directory から同期される属性や、ユーザー自身が変更できる属性を条件に使うと、意図しないアクセス付与につながる可能性があります。(Microsoft Learn)
実務では、次のように使い分けると安全です。
| 用途 | 向いているルール例 | 注意点 |
|---|---|---|
| 部門別の情報共有 | user.department -eq "Sales" | 部門属性の更新元と承認フローを確認 |
| デバイス管理 | デバイス属性を条件にしたルール | Microsoft 365 グループではデバイスをメンバーにできない |
| ライセンス配布 | ユーザー種別や所属を条件にしたルール | ライセンス数と除外条件を事前確認 |
| 条件付きアクセス | セキュリティ上信頼できる属性のみ使用 | ユーザー自己変更可能な属性は避ける |
グループベースライセンスは securityEnabled を確認する
グループベースライセンスは、Microsoft Entra グループにライセンスを割り当て、メンバーに自動継承させる仕組みです。メンバーが追加されるとライセンスが付与され、グループから外れるとライセンスも削除されます。ただし、この機能はセキュリティ グループと、securityEnabled が true の Microsoft 365 グループでのみ利用できます。(Microsoft Learn)
ライセンス運用でよくある失敗は、コラボレーション用の Microsoft 365 グループにそのままライセンスを割り当てようとすることです。事前に securityEnabled を確認し、ライセンス配布専用のセキュリティ グループを使うか、既存グループを使うかを判断してください。
GET /v1.0/groups?$select=id,displayName,groupTypes,securityEnabled,assignedLicensesゲストユーザー前提のアプリは検索仕様を確認する
組織内のメンバーや管理者は /groups リソースを使ってグループ検索できますが、ゲストは複数結果を返す /groups クエリを実行できません。権限があれば特定グループのプロファイルを参照できる場合はありますが、ゲストがディレクトリ全体を検索するような実装は期待通りに動かない可能性があります。(Microsoft Learn)
外部パートナー向けポータルやB2Bゲストを使うアプリでは、グループ名検索に頼らず、アプリ側で許可済みのグループIDを保持する、または /groups/{id}/members のようなナビゲーションプロパティを適切な権限で使う設計にしましょう。
開発者が見直すべき実装ポイント
グループ作成時は所有者を必ず指定する
POST /groups で Microsoft 365 グループやセキュリティ グループを作成できます。ただし、アプリケーション権限 Group.Create で所有者を指定せずに作成すると、匿名のグループとして作成され、変更できない状態になる可能性があります。さらに、アプリオンリーで Microsoft 365 グループを所有者なしで作ると、関連する SharePoint Online サイトが自動作成されない場合があります。(Microsoft Learn)
最低限、作成処理では次の項目を確認してください。
| 項目 | 確認内容 |
|---|---|
displayName | 表示名。最大長や命名規則に注意 |
mailEnabled | メール有効グループかどうか |
mailNickname | メールエイリアス。使用できない文字に注意 |
securityEnabled | セキュリティ有効グループかどうか |
| owners | アプリオンリー作成では特に必須レベルで指定 |
| members | 初期メンバーを入れる場合は読み取り権限も確認 |
また、Teams は Microsoft 365 グループを基盤にしますが、POST /groups だけで Teams のチームを作成できるわけではありません。グループ作成、Teams有効化、SharePointやPlannerの準備は同一処理として雑にまとめず、段階ごとに成否を確認する設計が安全です。(Microsoft Learn)
一覧取得では $select とページングを前提にする
グループ一覧取得では、すべてのプロパティが既定で返るわけではありません。Microsoft Graph の group resource type では、作成、取得、一覧取得の各操作で、パフォーマンス上の理由からよく使われる一部プロパティのみが既定で返され、既定で返らないプロパティは $select で指定する必要があると説明されています。(Microsoft Learn)
また、GET /groups は $count、$filter、$orderby、$search、$select、$top などをサポートしますが、$skip はサポートされません。既定ページサイズは100、最大ページサイズは999です。新しく作成・更新・削除したグループはレプリケーション遅延によりすぐ結果へ反映されない場合があるため、作成直後の確認処理にはリトライを組み込む必要があります。(Microsoft Learn)
GET /v1.0/groups?$select=id,displayName,mailEnabled,securityEnabled,groupTypes,membershipRule,membershipRuleProcessingState$search や高度なフィルターを使う場合は、ConsistencyLevel: eventual と $count が必要になるケースがあります。検索や棚卸しツールを作る場合は、単純なサンプルコードを本番に貼り付けるのではなく、ヘッダー、ページング、レプリケーション遅延、再試行を含めて設計してください。
Exchange 側に保存されるプロパティは同じリクエストに混ぜない
グループの多くのデータは Microsoft Entra ID に保存されますが、autoSubscribeNewMembers や allowExternalSenders など一部のプロパティは Microsoft Exchange 側に保存されます。これらのプロパティは、他のグループプロパティと同じ作成または更新リクエスト本文に含めることができません。また、メインデータストア外のプロパティは変更追跡の対象外で、delta query の応答にも現れません。(Microsoft Learn)
実装上は、グループ作成直後にすべての設定を1回の POST /groups で完了させようとしないことが重要です。まずグループを作成し、作成完了を確認した後に、必要なプロパティを別リクエストで更新する構成にしてください。
移行・展開前のチェックリスト
Microsoft Graph でグループ管理を拡張する前に、次の順番で確認すると手戻りを減らせます。
| 順番 | 作業 | 目的 |
|---|---|---|
| 1 | 既存グループを groupTypes、mailEnabled、securityEnabled で分類する | Graph で更新できる対象と読み取り専用対象を分ける |
| 2 | 所有者が0人または1人のグループを抽出する | 所有者なしグループ化を防ぐ |
| 3 | アプリ登録の Microsoft Graph 権限を確認する | Directory.ReadWrite.All などの過剰権限を避ける |
| 4 | 動的メンバーシップのルールと属性更新元を確認する | 属性改ざんや誤付与を防ぐ |
| 5 | ライセンス割り当て対象の securityEnabled を確認する | グループベースライセンスの失敗を防ぐ |
| 6 | ゲストユーザーを含むアプリの検索仕様を確認する | /groups 検索制限による不具合を防ぐ |
| 7 | 開発・検証テナントで作成、更新、削除、復元、通知を試す | 本番展開前に例外パターンを洗い出す |
失敗しやすいポイントと対策
| 失敗例 | 原因 | 対策 |
|---|---|---|
| 配布グループを Graph で更新しようとして失敗する | 配布グループは Graph groups API では読み取り専用 | 種別を判定し、更新対象から除外する |
| アプリオンリーで作成したグループが管理しにくい | 所有者を指定せず匿名グループ化する可能性 | 作成時に owners を必ず指定する |
| 動的グループに想定外のユーザーが入る | ルールに使う属性が不適切、または更新権限が広い | 属性の更新元と書き込み権限を監査する |
ownerlessGroupPolicy の設定が消える | isEnabled: false で他パラメーターがクリアされる | 無効化前に現在設定を退避し、再有効化時に全項目を指定する |
| 作成直後のグループが検索結果に出ない | レプリケーション遅延 | 即時反映を前提にせず、リトライと待機を入れる |
| delta query で一部変更を検知できない | Exchange 側に保存されるプロパティは変更追跡対象外 | 対象プロパティは別の取得・監査方法を用意する |
まず実行すべき次のアクション
最初に行うべきことは、新しいAPIを試すことではなく、現状のグループ管理を可視化することです。/groups でグループ種別を棚卸しし、Graph で管理できる対象と読み取り専用対象を分けてください。次に、所有者が0人または1人の Microsoft 365 グループを抽出し、2人以上の所有者を持つ状態へ整えます。そのうえで、ownerlessGroupPolicy、動的メンバーシップ、グループベースライセンス、アプリ権限を段階的に見直すのが安全です。
Manage Groups in Microsoft Graph – Microsoft Graph v1.0 の公式情報は、単に「グループAPIの使い方」を説明するものではありません。Microsoft Entra ID、Microsoft 365、Teams、SharePoint、Exchange にまたがるグループ運用を、Graph API からどこまで自動化でき、どこで管理者判断が必要になるかを整理するための基準です。管理者は所有者・ライセンス・動的ルールを、開発者は権限・種別判定・ページング・プロパティ更新の分離を確認し、まずは検証環境で現在の運用に当てはめてください。
コメント