2026年5月に公開された「Sponsor group type requirements for agent identities」は、Microsoft 365 / TeamsでエージェントIDを運用している組織にとって、スポンサーに指定できるグループ種別が変わる重要な告知です。結論から言うと、Entra Agent IDのGA移行に伴い、エージェントID、エージェントブループリント、エージェントブループリントプリンシパルのスポンサーとして新規に指定できるグループは、動的メンバーシップグループまたはMicrosoft 365グループに限定されます。固定メンバーシップのセキュリティグループやロール割り当て可能グループをスポンサーにしているプロビジョニング処理は、次回作成・更新時に失敗する可能性があります。(Microsoft for Developers)
一方で、すでに設定済みのサポート外グループスポンサーは継続して機能し、Microsoftは「既存設定について顧客側の対応は不要」と説明しています。ただし、これは「今後も同じ設定で新規作成できる」という意味ではありません。この記事では、Microsoft 365 / Teams管理者、ID管理担当者、エージェント開発者が確認すべき変更点、影響範囲、移行判断、設定確認の実務ポイントを整理します。(Microsoft for Developers)
Sponsor group type requirements for agent identitiesで何が変わるのか
今回の変更は、Microsoft Entra Agent IDが一般提供、つまりGAへ移行する過程で導入されるものです。対象となるのは、エージェントに対する「スポンサー」をグループで指定するケースです。
スポンサーとは、エージェントの技術管理者ではなく、そのエージェントの目的・継続要否・ライフサイクルに責任を持つ業務上の責任者を表す関係です。Microsoft Learnでは、スポンサーはエージェントのビジネス上の説明責任を担い、アクセスレビュー、保持、無効化などの判断に関わる存在として説明されています。(Microsoft Learn)
今回のポイントは、スポンサーそのものが廃止されるわけではなく、スポンサーに指定できるグループの種類が絞り込まれる点です。
| 項目 | 変更後の扱い |
|---|---|
| 個別ユーザーをスポンサーに指定 | 引き続きサポート |
| 動的メンバーシップグループ | 新規スポンサーとして利用可能 |
| Microsoft 365グループ | 新規スポンサーとして利用可能 |
| 固定メンバーシップのセキュリティグループ | 新規スポンサーとしては不可 |
| ロール割り当て可能グループ | GAでは新規スポンサーとして不可 |
| 既存のサポート外グループスポンサー | 継続して機能 |
Microsoft公式ブログでは、パブリックプレビュー中はロール割り当て可能グループもサポートされていたものの、GAリリースには含まれないと説明されています。新規のスポンサー割り当てでサポート外のグループを指定すると拒否されるため、特に自動作成スクリプトや申請ワークフローを持つ組織は事前確認が必要です。(Microsoft for Developers)
なぜスポンサーに指定できるグループ種別が制限されるのか
理由は、スポンサー情報を高速かつ安定して解決するためです。
エージェントIDでは、管理者や自動化処理が次のような問いに答えられる必要があります。
- このエージェントの責任者は誰か
- このユーザーまたはグループが責任を持つエージェントはどれか
- アクセスレビューやライフサイクル判断の対象者は誰か
- インシデント時に業務上の判断を仰ぐ相手は誰か
Microsoftは、スポンサー関係を重要な属性付けの仕組みと位置付けています。エージェントIDの利用が増えると、スポンサー解決の処理も増えるため、サポート対象のグループ種別を絞ることで、応答速度と予測可能性を確保する狙いがあります。(Microsoft for Developers)
実務上は、これは単なる仕様変更ではありません。AIエージェントやTeams連携エージェントが増えるほど、「誰が責任を持つのか」を曖昧にしない設計が重要になります。スポンサーをアクセス権限管理のついでに設定するのではなく、業務責任を表す専用の管理項目として扱うことが求められます。
対象になるオブジェクトと影響範囲
今回の変更は、主にMicrosoft Entra Agent IDの管理関係に関わります。Microsoft公式ブログでは、対象として以下が挙げられています。(Microsoft for Developers)
| 対象 | 影響 |
|---|---|
| agent identities | グループスポンサーの新規指定で制限を受ける |
| agent blueprints | グループスポンサーの新規指定で制限を受ける |
| agent blueprint principals | グループスポンサーの新規指定で制限を受ける |
| 個別ユーザーのスポンサー指定 | 変更なし |
| 既存のサポート外グループスポンサー | 継続して機能 |
特に注意したいのは、既存設定は動くが、新規設定や次回プロビジョニングは拒否される可能性があるという点です。
たとえば、次のような運用は影響を受けやすくなります。
- エージェント作成時に固定メンバーシップのセキュリティグループをスポンサーとして自動指定している
- Microsoft Entraロール管理用のロール割り当て可能グループを、そのままスポンサーにも使っている
- Teamsごとの管理者グループやセキュリティグループを、エージェント責任者グループとして流用している
- IaC、PowerShell、Microsoft Graph、内製ポータルなどでスポンサー設定を自動化している
- パブリックプレビュー時の仕様を前提に設計したエージェント管理台帳を使っている
「既存のスポンサーは残る」と聞くと緊急度が低く見えますが、実際には新規展開・再作成・テンプレート更新・移行時に問題が出やすい変更です。特にTeams向けエージェントを部門やプロジェクト単位で増やしている組織では、次回の作成サイクル前に確認しておくべきです。
許可されるグループと許可されないグループの見分け方
Microsoft Learnでは、Agent IDのスポンサーに指定できるグループとして、動的メンバーシップグループと割り当て済みメンバーシップのMicrosoft 365グループが挙げられています。一方、ロール割り当て可能グループと割り当て済みメンバーシップのセキュリティグループは許可されません。(Microsoft Learn)
実務では、グループ名だけで判断しないことが重要です。名前に「M365」「Security」「Admin」と入っていても、実際の種別やプロパティが一致しているとは限りません。
| 確認項目 | 判断の目安 |
|---|---|
| Microsoft 365グループか | groupTypes に Unified が含まれる |
| 動的メンバーシップか | groupTypes に DynamicMembership が含まれる |
| ロール割り当て可能か | isAssignableToRole が true |
| 固定セキュリティグループか | groupTypes が空で、securityEnabled が true のケースが多い |
| Teamsに紐づくグループか | 多くの場合Microsoft 365グループだが、ロール割り当て可能設定なども確認する |
Microsoft Graphのグループ情報では、動的メンバーシップは DynamicMembership、Microsoft 365グループは Unified として表されます。動的メンバーシップは、ユーザーやデバイスの属性に基づいてメンバーを自動追加・削除する仕組みです。(Microsoft Learn)
確認用の例は次のとおりです。
Connect-MgGraph -Scopes "Group.Read.All","Directory.Read.All"
$groupId = "<確認したいグループID>"
Get-MgGroup `
-GroupId $groupId `
-Property "id,displayName,groupTypes,mailEnabled,securityEnabled,isAssignableToRole,membershipRule,membershipRuleProcessingState" |
Select-Object `
Id,
DisplayName,
GroupTypes,
MailEnabled,
SecurityEnabled,
IsAssignableToRole,
MembershipRule,
MembershipRuleProcessingState結果を確認するときは、次の順で判断すると迷いにくくなります。
| 条件 | スポンサー指定の判断 |
|---|---|
IsAssignableToRole が true | 新規スポンサーには使わない |
GroupTypes に DynamicMembership が含まれる | 原則として利用候補 |
GroupTypes に Unified が含まれる | Microsoft 365グループとして利用候補 |
GroupTypes が空で SecurityEnabled が true | 固定セキュリティグループの可能性が高く、移行対象 |
| 判断できない | Entra管理センターまたはMicrosoft Graphで詳細確認 |
ポイントは、ロール管理用のグループと、エージェントの業務責任を表すスポンサーグループを分けることです。ロール割り当て可能グループは、Microsoft Entraロールをグループに割り当てるための仕組みであり、作成時に isAssignableToRole を設定します。Microsoftは、ロール割り当て可能グループについて特別な制約を設けており、動的メンバーシップにはできないと説明しています。(Microsoft Learn)
Teams管理者が特に注意すべきポイント
Microsoft Teamsでは、チームがMicrosoft 365グループに紐づいていることが多いため、「Teamsの所有者グループをスポンサーにすればよい」と考えがちです。しかし、スポンサーはチームのメンバー管理とは役割が異なります。
Teamsの動的メンバーシップでは、Microsoft Entra IDのユーザー属性に基づいてチームメンバーを自動的に追加・削除できます。Microsoft Learnでは、動的メンバーシップの変更がMicrosoft 365グループに反映された後、Teamsに反映されるまで数分から最大2時間かかる場合があると説明されています。(Microsoft Learn)
Teams連携で気を付けたいのは、次の3点です。
| よくある運用 | 注意点 |
|---|---|
| チーム全体をスポンサーにする | メンバーが多すぎると、責任者が曖昧になる |
| Teams所有者をスポンサーにする | Teams所有者とエージェントの業務責任者が一致するとは限らない |
| 動的Teamsをスポンサーにする | 属性変更によりスポンサー対象者が自動で変わるため、ルール設計が重要 |
| 管理者用セキュリティグループを流用する | 固定セキュリティグループやロール割り当て可能グループは新規スポンサーに使えない可能性が高い |
おすすめは、Teamsのチーム構成をそのまま使うのではなく、エージェントの責任単位に合わせてスポンサーグループを設計することです。
たとえば、営業部門向けのTeamsエージェントであれば、全営業メンバーではなく「営業AIエージェント責任者」などのMicrosoft 365グループを作成します。人事異動に合わせて自動更新したい場合は、部門・役職・勤務地などの属性を使った動的メンバーシップグループを検討します。
移行が必要かを判断するチェックリスト
今回の変更で全員がすぐに設定変更する必要はありません。まずは、現在のスポンサー設定と今後の作成フローを分けて確認します。
| 確認項目 | 対応の要否 |
|---|---|
| 既存のスポンサーに固定セキュリティグループがある | 既存は継続するが、将来の再作成・更新に備えて移行計画を作る |
| 既存のスポンサーにロール割り当て可能グループがある | GA後の新規指定では使わない前提で代替グループを用意する |
| 新規エージェント作成時にスポンサーを自動設定している | 自動化処理のバリデーションを必ず見直す |
| App-onlyでエージェントを作成している | 作成サービスがサポート対象のスポンサーを明示的に設定できるか確認する |
| 個別ユーザーのみをスポンサーにしている | 仕様変更の直接影響は小さいが、退職・異動時の引き継ぎを確認する |
| Teams単位でスポンサーを設計している | チームメンバーではなく責任者単位で再設計する |
Microsoft Learnでは、エージェントIDまたはエージェントブループリントの作成時にスポンサーが必要であること、App-onlyの作成要求では作成サービスが1人以上のユーザーまたはサポート対象グループをスポンサーとして設定する必要があることが説明されています。(Microsoft Learn)
つまり、自動化している環境では「画面でエラーが出たら直す」では遅い場合があります。作成APIやワークフローの中で、サポート外グループを指定しないように事前チェックを入れるべきです。
移行先グループの選び方
移行先は、単に「許可されているグループ」にするだけでは不十分です。スポンサーは業務責任を表すため、メンバーが多すぎても、少なすぎても運用が崩れます。
固定の責任者チームならMicrosoft 365グループ
責任者が明確で、メンバーの追加・削除を承認ベースで管理したい場合は、Microsoft 365グループが扱いやすい選択肢です。
向いているケースは次のとおりです。
- 特定のプロダクトチームがエージェントを管理する
- Teamsの所有者とは別に、少人数の責任者グループを作りたい
- メンバー変更を人手で確認したい
- 動的ルールに使える属性が整備されていない
例として、営業支援エージェントなら「M365G-Sales-Agent-Sponsors」のようなグループを作り、営業企画責任者、システム担当、業務オーナーをメンバーにします。
組織属性に連動させるなら動的メンバーシップグループ
部門、職種、拠点、雇用区分などに応じて責任者が自動的に変わる場合は、動的メンバーシップグループが向いています。
ただし、動的グループはルール設計を誤ると、意図しない人がスポンサーになります。Microsoft Learnでは、動的メンバーシップルールに使う属性について、誰がその属性を書き換えられるかを確認する重要性が説明されています。特にアクセス制御や機密リソースに関わるグループでは、属性の書き込み権限が弱いとセキュリティ上のリスクになります。(Microsoft Learn)
避けたい例は、ユーザー自身が変更できる属性を使ってスポンサーグループを構成することです。
悪い例:
user.jobTitle -contains "AI"このようなルールは、属性の運用が曖昧だと意図しないメンバーを含む可能性があります。
より現実的なのは、HRシステムやオンプレミスActive Directoryから厳格に同期される属性を使う設計です。
例:
user.department -eq "Sales Operations"ただし、この場合も「departmentを書き換えられる管理者は誰か」「退職・異動時にいつ反映されるか」「例外メンバーをどう扱うか」を確認してから使うべきです。
ロール割り当て可能グループは分離する
ロール割り当て可能グループは、管理者ロールの付与や特権アクセス管理に使うためのグループです。Microsoft Entraロールをグループに割り当てることで、管理者権限の付与を効率化できますが、スポンサーの役割とは目的が異なります。(Microsoft Learn)
「この管理者グループがエージェントを管理しているから、スポンサーにもする」という設計は、今回の変更を機に見直すべきです。
推奨される分け方は次のとおりです。
| 用途 | グループ例 |
|---|---|
| 特権管理 | Role-App-Admins |
| 技術運用 | M365G-Agent-Technical-Owners |
| 業務責任 | M365G-Agent-Business-Sponsors |
| 自動メンバー管理 | Dynamic-Agent-Sponsors-SalesOps |
技術管理者、特権管理者、業務スポンサーを分けることで、インシデント時の判断、アクセスレビュー、監査対応がしやすくなります。
実務での確認・移行手順
対応は、いきなりグループを作り替えるのではなく、現在の状態を棚卸ししてから進めます。
| 手順 | 作業内容 | 失敗しやすいポイント |
|---|---|---|
| 現状把握 | エージェントID、ブループリント、スポンサー設定を一覧化する | 既存設定だけを見て、自動作成フローを確認しない |
| グループ分類 | スポンサーに使っているグループの種別を確認する | グループ名だけで判断する |
| 影響判定 | 新規作成・再作成・更新で拒否される可能性を洗い出す | 「既存は動く」ため影響なしと誤解する |
| 移行先設計 | Microsoft 365グループまたは動的メンバーシップグループを選ぶ | Teamsメンバー全員をスポンサーにして責任が曖昧になる |
| 自動化修正 | Graph、PowerShell、内製ポータルのスポンサー指定を更新する | 旧グループIDがテンプレートに残る |
| テスト | 検証環境で新規作成・更新・無効化を確認する | 作成成功だけ見て、レビューや削除判断の動線を確認しない |
| 運用反映 | 台帳、命名規則、申請フォーム、監査手順を更新する | グループ変更後の責任者引き継ぎが抜ける |
実務では、まず「次回のプロビジョニングサイクルで使われるスポンサーグループ」を確認してください。Microsoft公式ブログでも、固定メンバーシップのセキュリティグループやロール割り当て可能グループをスポンサーに割り当てるワークフローがある場合は、次回のプロビジョニングサイクル前に動的メンバーシップグループまたはMicrosoft 365グループへ移行するよう案内されています。(Microsoft for Developers)
Agent identity sponsorsとagent user account sponsorsを混同しない
今回の変更で混乱しやすいのが、Agent IDのスポンサーと、エージェントに紐づくユーザーアカウントのスポンサーです。
Microsoft Learnでは、エージェントID、ブループリント、ブループリントプリンシパルのスポンサーと、エージェントのユーザーアカウントスポンサーには違いがあると説明されています。Agent identity側のスポンサーは、ユーザーと一部のグループに限定され、ロール割り当て可能グループはサポートされません。一方、エージェントのユーザーアカウントスポンサーは通常のユーザースポンサーに近い扱いです。(Microsoft Learn)
この違いを理解しないまま設定すると、次のような問題が起きます。
- ユーザーアカウント側では使えるグループを、Agent ID側にも使えると思い込む
- アクセスパッケージ申請の承認者と、エージェント停止判断の責任者がずれる
- 監査時に「誰が業務上の責任者か」を説明できない
- エージェントID側の必須スポンサー設定が抜ける
エージェントがAgent IDオブジェクトとユーザーアカウントの両方で表現される場合は、同じユーザーまたはグループを両方に設定できるかを確認しつつ、制約の厳しいAgent ID側を基準に設計するのが安全です。
変更対応でやってはいけないこと
今回の対応で避けたいのは、単にエラーを回避するためだけにスポンサーグループを置き換えることです。
責任者が多すぎるグループを使う
Teamsの全メンバーや部門全員をスポンサーにすると、実際には誰も責任を持たない状態になりがちです。スポンサーは「関係者」ではなく「判断できる人」に絞るべきです。
ロール管理グループを流用する
特権管理者グループは、権限付与のためのグループです。スポンサーは、業務上の責任やライフサイクル判断のための関係です。目的が違うため、同じグループで兼用すると監査やインシデント対応が複雑になります。
動的グループの属性管理を確認しない
動的メンバーシップグループは便利ですが、ルールに使う属性の信頼性が低いと、スポンサーが意図せず変わります。特に、ユーザー自身や広範な管理者が変更できる属性を使う場合は注意が必要です。
既存設定を理由に自動化を放置する
既存スポンサーが継続して機能することと、今後の新規スポンサー指定が成功することは別です。テンプレート、スクリプト、申請フォーム、内製ポータルに古いグループIDが残っていないか確認してください。
まず何をすべきか
Microsoft 365 / Teams環境でエージェントIDを使っている場合、最初に行うべきことは、スポンサーに指定しているグループの棚卸しです。
優先順位は次のとおりです。
- 新規エージェント作成やブループリント作成の自動化処理を確認する
- スポンサーに使っているグループの
groupTypesとisAssignableToRoleを確認する - 固定セキュリティグループやロール割り当て可能グループを使っている場合は、代替のMicrosoft 365グループまたは動的メンバーシップグループを設計する
- 作成フローに「サポート対象グループのみ許可する」チェックを追加する
- Teams連携エージェントでは、チームメンバーではなく業務責任者をスポンサーにする
今回の「Sponsor group type requirements for agent identities」は、単なるグループ種別の制限ではなく、AIエージェント時代の責任分界を明確にするための変更です。既存設定がすぐ壊れる可能性は低いものの、新規作成や次回更新でつまずかないよう、スポンサーグループの設計を早めに見直しておくことが重要です。
コメント