Microsoft 365 マルチジオ環境で、Power Automate から Microsoft Graph API を使って特定リージョン（例：AUS）にグループを作成しようとすると、preferredDataLocation 指定だけが弾かれて詰まることがあります。原因は「作れる権限」と「データ配置先を変える権限」が別物だからです。この記事では、権限要件の整理と現場での解決手順をまとめます。
症状：preferredDataLocation を付けると 403 で拒否される
Power Automate のフローから Graph API（POST /groups）を呼び出してグループを作成する際、リクエストボディに preferredDataLocation を含めると次のエラーで失敗し、外すとグループ自体は作成されるものの「既定のリージョン」に作られてしまう、というパターンです。
代表的なエラー
The requesting principal is not authorized to set group preferred data location.
| やりたいこと | 結果 | よくある勘違い |
|---|---|---|
preferredDataLocation: "AUS" を指定して作成 | 403 で拒否される | 「グループ管理者/Teams 管理者ならいけるはず」 |
preferredDataLocation を外して作成 | 作成は成功するが既定のジオに寄る | 「あとから簡単に移せるはず」 |
まず重要：対象は「Microsoft 365 グループ」か「セキュリティグループ」か
Graph の /groups は「Microsoft Entra グループ / Microsoft 365 グループ / セキュリティグループ」をまとめて扱います。ただし、preferredDataLocation は“Microsoft 365 グループのデータ配置（PDL）”として説明されており、Teams や SharePoint サイト、グループメールボックスなど「データが生まれるグループ」に関係します。
| 種類 | Graph の典型設定 | 主な用途 | preferredDataLocation の意味 |
|---|---|---|---|
| Microsoft 365 グループ（Unified） | groupTypes:["Unified"] / mailEnabled:true | Teams、SharePoint、Outlook グループなど | メールボックス/サイト等の配置ジオに影響する |
| セキュリティグループ | groupTypes:[] / securityEnabled:true / mailEnabled:false | アクセス制御（権限付与） | “データ配置”の概念が薄く、狙いがズレやすい |
今回のように「外すと Office 365（Microsoft 365）グループとして作成されるが、場所が既定になる」という挙動は、Unified グループ作成の文脈で起きる典型例です。
preferredDataLocation（PDL）とは：マルチジオで“どこにデータを置くか”を決めるキー
Multi-Geo を使うと、ユーザーやグループの Microsoft 365 データを、組織の地域要件に合わせて複数の地理ロケーション（ジオ）に分散できます。ユーザー側では preferredDataLocation 属性を設定し、メールボックスや OneDrive などの「データの居場所」を決めるのが基本です。
Microsoft 365 グループについても同様で、ユーザーがグループを作成した場合、グループの PDL は基本的に「作成者の PDL を継承」します。Graph の作成 API でも、レスポンス例として “preferredDataLocation は作成者から継承される” 旨が明記されています。
| 挙動 | 何が起きるか | 現場での影響 |
|---|---|---|
preferredDataLocation を省略 | 作成者の PDL（または既定）を継承 | サービスアカウントの PDL が既定だと、狙ったジオに寄らない |
preferredDataLocation を明示 | 指定ジオでの配置を狙う | ただし権限が足りないと 403 で拒否される |
また、Microsoft 365 の手順としても「グループの PDL はユーザーから自動設定される」「グローバル/SharePoint/Exchange 管理者は任意の Geography を選べる」「指定 PDL で作るとグループメールボックスと SharePoint サイトがその PDL にプロビジョニングされる」とされています。
エラー原因：データレジデンシ（配置先）を変える操作は“高権限”として扱われる
ポイントはここです。グループを“作成する権限”と、グループの“データ配置先（PDL）を指定する権限”は別物として扱われます。
Microsoft Graph の group リソース定義では、preferredDataLocation を設定するために次の要件が示されています。
- 呼び出しアプリに Directory.ReadWrite.All が付与されていること
- さらに（委任シナリオでは）呼び出しユーザーが、User Account Administrator / Directory Writer / Exchange Administrator / SharePoint Administrator のいずれかの Entra ロールを持つこと
つまり、Groups Administrator や Teams Administrator といった“ワークロード寄り”の権限だけでは、preferredDataLocation の設定を許可しない設計になっています。実際に Power Automate からの作成で同エラーに遭遇した事例では、「SharePoint/Groups/Teams 管理者ロールを持っていても PDL 設定は許可されない」ため、追加のロールが必要と案内されています。
最短で整理：あなたの呼び出しは“委任”か“アプリ（アプリケーション権限）”か
Power Automate から Graph を叩くとき、同じ「サービスアカウントで動かしているつもり」でも、実際のトークンがどちらかで要求が変わります。
| 方式 | トークンの主体 | 特徴 | 今回ハマりやすい点 |
|---|---|---|---|
| 委任（Delegated） | サインインしたユーザー（サービスアカウント等） | “ユーザーとして” Graph を呼ぶ | ユーザー側の Entra ロール要件を満たしているかが効く |
| アプリ（Application / Client Credentials） | アプリ（サービスプリンシパル） | “アプリとして” Graph を呼ぶ（非対話） | ユーザーに付けたロールは効かない。アプリ側の権限・ロールが焦点になる |
「サービスアカウントに SharePoint 管理者を付けたのに直らない」場合、呼び出しの主体がそのユーザーではなく、別のアプリ（またはコネクタ）が発行したトークンになっている可能性があります。ここを切り分けるだけで、解決までの道筋がほぼ決まります。
必要な権限セットを“表で”押さえる
最低限ここだけ把握しておくと、関係者（グローバル管理者、セキュリティ担当）に説明しやすくなります。
| 項目 | 必要になるもの | 根拠 | 補足 |
|---|---|---|---|
| グループ作成（/groups） | 委任：Group.ReadWrite.All（または上位の Directory.ReadWrite.All）アプリ： Group.Create（または Directory.ReadWrite.All / Group.ReadWrite.All） | Graph の Create group 権限表 | “作れる”だけならここで足りることが多い |
| preferredDataLocation の設定 | Directory.ReadWrite.All ＋（委任の場合）指定ロール（SharePoint Administrator など） | group リソースの要件 | これが満たせず 403 になりやすい |
| “サービスアカウントで実行しているのにダメ”な場合の追加手当 | Global Administrator 付与 または Directory Writers と PreferredDataLocation Writer の割り当て | Microsoft Q&A の案内 | Power Automate の実行主体（プリンシパル）に対して付与するのがポイント |
解決策：委任（サービスアカウントでサインインして呼ぶ）で通す
「Power Automate の接続（コネクション）としてサービスアカウントを使い、そのユーザーの委任トークンで Graph を呼ぶ」運用であれば、まずは Graph が求める条件に合わせて組み立てます。
手順の考え方
- アプリ側：Directory.ReadWrite.All を含む委任権限を付け、管理者同意（Admin consent）まで完了させる
- ユーザー側：サービスアカウントに SharePoint Administrator（または Exchange Administrator / Directory Writer / User Account Administrator） を割り当てる
- フロー側：実際に Graph を叩いている接続が、そのサービスアカウントであることを確認する
運用メモ（詰まりどころ）
- PIM を使っている場合：ロールが「割り当て済み」でも「有効化（Activate）」されていないと、実行時に権限不足になり得ます（運用に合わせて、実行前に有効化する手順を決めておくのが安全）。
- 委任権限の同意が抜けている場合：フローの実行者にはロールがあっても、アプリのスコープが足りず弾かれます。Graph の仕様では
preferredDataLocation設定にDirectory.ReadWrite.Allが必要です。
解決策：クライアントID/シークレット（アプリ登録）でアプリとして呼ぶ
非対話で確実に動かしたい場合、アプリ登録（Client Credentials）で Graph を呼ぶ構成がよく選ばれます。この場合は“サービスアカウントのロール”ではなく、“アプリ（サービスプリンシパル）の権限”が主役になります。
アプリ登録側の権限（アプリケーション権限）の目安
Microsoft Q&A の案内では、次の Graph 権限をアプリに付与（Delegated/Application いずれでも）し、管理者同意を実施する必要があるとされています。
Group.ReadWrite.AllDirectory.ReadWrite.AllUser.ReadWrite.All
なお、Create group API 自体の権限表としては、アプリケーション権限では Group.Create が最小権限として挙げられ、上位権限として Directory.ReadWrite.All や Group.ReadWrite.All が示されています。
ロール（Directory role）の割り当て
アプリとして PDL を指定する用途では、ロール要件が絡んで拒否されることがあり、Q&A では次の対応が推奨されています。
- Global Administrator を付与する（短期での付与・作業後の剥奪を推奨）
- Global Admin が難しい場合は、Global Admin に依頼して
Directory WritersとPreferredDataLocation Writerを割り当ててもらう
このあたりは組織のセキュリティ基準で判断が分かれます。長期で Global Administrator を付けっぱなしにするより、必要な作業時間だけ有効化できる仕組み（PIM など）や、用途限定のアプリ・アカウント分離を前提に設計すると運用が安定します。
実装例：Graph API で AUS に Microsoft 365 グループを作成する
Graph の Create group は POST /groups です。Microsoft 365 グループ（Unified）で PDL を指定する場合、リクエストのイメージは次の通りです（実際の業務では命名規則や所有者設定も合わせて入れてください）。
{
"displayName": "Project-AUS-001",
"description": "AUS に配置するプロジェクト用グループ",
"groupTypes": ["Unified"],
"mailEnabled": true,
"mailNickname": "project-aus-001",
"securityEnabled": false,
"preferredDataLocation": "AUS",
"visibility": "Private"
}ポイント
groupTypesにUnifiedを入れると Microsoft 365 グループになります（Teams の土台）。preferredDataLocationは指定しない場合、作成者の PDL を継承する前提です。- PDL 指定が通るかどうかは、権限（
Directory.ReadWrite.All）とロール要件の両方が満たされているかで決まります。
作成後の確認（推奨）
フローの最後で GET /groups/{id}?$select=displayName,preferredDataLocation,groupTypes を呼び、preferredDataLocation が意図どおりになっているかをログに残すと、運用時の問い合わせが激減します。
Geo コード（AUS など）の選び方と注意点
PDL は 3 文字コードで指定します。Microsoft 365 のドキュメントでは AUS（Australia）、CAN（Canada）、DEU（Germany）など具体的なコード表が提示されています。まずは自テナントで有効な Geography と、指定したい PDL が一致しているかを確認してください。
| 例（Geography） | PDL 値 | メモ |
|---|---|---|
| Australia | AUS | 例としてよく使われる |
| Canada | CAN | North America（NAM）とは別コードなので混同注意 |
| Germany | DEU | EUR と DEU の違いを要確認 |
| United States | NAM | “US” ではない |
切り分けチェックリスト：403 が消えないときに見る場所
| チェック項目 | 見る場所 | NG のときの典型症状 | 対処の方向性 |
|---|---|---|---|
| preferredDataLocation を設定できる権限（Directory.ReadWrite.All）があるか | アプリ登録の API アクセス / コネクションのスコープ | 403 / Insufficient privileges | Directory.ReadWrite.All を付与し管理者同意 |
| 呼び出し主体は“ユーザー”か“アプリ”か | Power Automate の接続方式 | ユーザーにロール付与しても変化なし | アプリ方式ならサービスプリンシパル側の権限・ロールを見直す |
| 委任の場合：ユーザーに必要ロールがあるか | Entra ロール割り当て | preferredDataLocation だけ 403 | SharePoint/Exchange/Directory Writer 等を確認 |
| アプリ方式：Global Admin もしくは Directory Writers / PreferredDataLocation Writer が割り当てられているか | Entra 管理センター > Roles & admins | “not authorized to set group preferred data location” が継続 | Q&A 推奨のロール付与を検討 |
| PDL コードが正しいか（AUS 等） | Multi-Geo のコード表 | 400 / 値が反映されない | コード表に合わせて修正 |
運用のコツ：権限を強くしすぎないための現実解
PDL を操作する処理は「データの所在」に直結するため、組織内レビューが入りやすい領域です。Power Automate の自動化を安全に通すには、次の“落としどころ”が現場で効きます。
- 用途限定のアプリ登録に分離：グループ作成・設定以外はさせない（他の Graph 権限を足さない）。Create group の権限表を基準に最小権限から設計する。
- Global Administrator の恒久付与は避ける：必要であれば短期付与＋作業後に剥奪、またはより限定的なロールで代替する。
- フローに“監査用ログ”を残す：作成したグループ ID、displayName、preferredDataLocation、実行者（接続名）、失敗時のエラー本文を保存する（将来の障害対応が楽になります）。
代替策：GUI や Exchange PowerShell で「指定 PDL のグループ」を作る
「まずは手動でもいいから指定ジオに作りたい」「Graph の権限調整に時間がかかる」場合は、Microsoft の手順として SharePoint 管理センター（対象 Geography の管理 URL）から作成する方法や、Exchange PowerShell の New-UnifiedGroup で -MailboxRegion を指定する方法も案内されています。
- 例：AUS の SharePoint 管理センターにアクセスして作成（URL 例はドキュメントに記載）
- 例：Exchange PowerShell で
New-UnifiedGroup ... -MailboxRegion EURのように作成
ただし、これらは「自動化」ではないため、最終的に Power Automate で再現したいなら、やはり Graph 側の権限設計が本命になります。
よくある質問
preferredDataLocation を後から変更できますか？
Graph の group リソースでは preferredDataLocation は書き込み可能である一方、更新も同様に高権限が必要です（Directory.ReadWrite.All と特定ロール）。既存グループの移設は周辺サービス（SharePoint サイトやメールボックスなど）の状態にも左右されるため、運用設計としては「作成時に正しい PDL で作る」方が事故が少ないです。
サービスアカウントに SharePoint 管理者を付けたのに直りません
多くの場合「実際に Graph を呼んでいるプリンシパルがサービスアカウントではない（アプリとして呼んでいる）」のが原因です。Power Automate の接続方式を見直し、アプリ方式ならサービスプリンシパル側にロール/権限を付与する方針で再設計すると改善します。Q&A でも、PDL をセットするには Global Admin または Directory Writers / PreferredDataLocation Writer の割り当てが必要と案内されています。
AUS 以外のコードはどこで確認できますか？
Microsoft 365 のドキュメントに Geo location codes の表が掲載されています。AUS、CAN、DEU、EUR、NAM など、似たコードが混在するため“思い込み”で指定しないのが安全です。
コメント