MENU

GCC HighでMicrosoft 365グループをGraph APIで作成する方法｜graph.microsoft.us対応

Microsoft 365

GCC High（米国政府向け Microsoft 365）でも、API から Microsoft 365 グループを作成できます。ポイントは「Graph は使えるが、商用クラウドとは別の認証先とエンドポイントを使う」こと。graph.microsoft.us と login.microsoftonline.us 前提で、失敗しない実装手順を整理します。

目次

GCC High で Microsoft 365 グループを API 作成できるのか

結論から言うと、GCC High 環境でも Microsoft Graph API を使って Microsoft 365 グループ（Unified group） を作成できます。代表的な方法は、Microsoft Graph の POST /groups を呼び出すだけです。Graph の「グループ作成」API 自体は、グローバル（商用）だけでなく US Government（L4 / L5）などのナショナルクラウドでも提供されています。

ただし「API がある＝商用と同じ設定で動く」ではありません。GCC High は Microsoft Cloud for US Government の一部で、認証基盤（Microsoft Entra ID）も Graph のサービスルートもグローバルとは別系統です。ここを取り違えると、トークンが取れても API が 401 になったり、逆にトークン取得で詰まったりします。

商用クラウドとの最大の違いは「エンドポイント」と「認証先」

GCC High での実装が難しく感じる最大の理由は、普段の graph.microsoft.com・login.microsoftonline.com をそのまま使えないことです。GCC High（US Gov L4）では、Azure ポータル、トークン発行元、Graph それぞれに 政府クラウド用 の URL が用意されています。

用途商用クラウド（Global）GCC High（US Gov L4）補足
アプリ登録ポータルhttps://portal.azure.comhttps://portal.azure.us別ポータルに別登録が必要
トークン取得（認証先）https://login.microsoftonline.comhttps://login.microsoftonline.us「同じ Client ID」でもクラウドが違うと通用しない
Microsoft Graph ルートhttps://graph.microsoft.comhttps://graph.microsoft.us呼び出し先を切り替える
Microsoft Graph Explorer利用可利用不可Postman / curl / SDK で検証する

なお、同じ “米国政府クラウド” でも GCC High（L4） と DoD（L5） は Graph のルートが異なります。GCC High は graph.microsoft.us、DoD は dod-graph.microsoft.us です。自組織の契約プランがどちらかを最初に確認しておくと、環境違いのハマりを避けられます。

さらに重要なのが、クラウド間でアクセストークンは互換ではない という点です。たとえばグローバルで取得したトークンを GCC High の Graph（graph.microsoft.us）に投げても通りません。逆も同様です。「トークンは取れるのに API が通らない」事故の多くはここが原因です。

実装の全体像

GCC High で Microsoft 365 グループを API 作成する流れを、運用に耐える形でまとめると次の通りです。

  • Azure Government 側（portal.azure.us）でアプリを登録する
  • Graph の権限（最小権限）を設計し、管理者同意（Admin consent）まで完了させる
  • login.microsoftonline.us からアクセストークンを取得する
  • graph.microsoft.us/v1.0 に対して POST /groups を実行する
  • 作成後の反映遅延・所有者設定・SharePoint/Teams 連携を見越して検証する

ここからは「なぜそれが必要か」「何でつまずくか」を、実例ベースで掘り下げます。

アプリ登録は Azure Government 側で行う

GCC High はナショナルクラウドのため、アプリ登録もグローバルとは別枠です。アプリ登録は portal.azure.us から実施し、そのクラウドに属する Entra ID のエンドポイント（login.microsoftonline.us）でトークンを取得します。

「既に商用クラウドに同名のアプリがあるから流用したい」と考えがちですが、クラウドが違うと登録もトークンも別物になります。開発環境（商用）→本番（GCC High）へ展開する場合は、アプリ登録を“移植”するつもりで、設定項目を棚卸ししておくとスムーズです。

項目実務でのポイントありがちな失敗
テナントGCC High のテナント（.us 側）で作る商用テナントに登録してしまい、トークンの発行元がズレる
認証方式自動化はクライアント資格情報（アプリのみ）／対話は委任運用を想定せず、後から方式変更で権限設計が崩れる
秘密情報長期運用なら証明書を推奨（ローテーション設計）短い有効期限のシークレットで運用が止まる
リダイレクト URI委任フローでは必須。自動化のみなら不要な場合が多い委任フローなのに URI を入れていない

権限設計の要点：委任とアプリのみ、どちらで作るか

Microsoft 365 グループ作成は、ユーザーの権限で動かす「委任（Delegated）」でも、サービスとして動かす「アプリケーション（App-only）」でも実装できます。どちらが正しい、ではなく 運用モデルに合う方を選ぶ のが重要です。

観点委任（ユーザー操作）アプリのみ（自動化・バックエンド）
向いている用途ポータル代替、管理者が手動実行するツール申請→自動払い出し、定型プロビジョニング
メリットユーザーの権限・監査ログと整合しやすい無人運用でき、作成品質をテンプレ化しやすい
注意点ユーザーにグループ作成権限がないと 403 になりやすい所有者を付けないと“匿名グループ”になり運用不能になり得る

Graph の「グループ作成」APIで要求される権限は、委任なら Group.ReadWrite.All（より強い権限として Directory.ReadWrite.All）、アプリのみなら Group.Create（より強い権限として Directory.ReadWrite.All や Group.ReadWrite.All）が整理されています。最小権限の観点では、まず Group.Create / Group.ReadWrite.All を軸に検討するのが現実的です。

また、アプリのみ（クライアント資格情報）で Group.Create を使う場合、所有者（owners）を付けずに作るとグループが編集できなくなる 可能性がある点は要注意です。さらに Microsoft 365 グループでは、アプリのみで所有者なしだと 関連する SharePoint Online サイトが自動作成されない ケースがある、と明記されています。プロビジョニング用途では「作れて終わり」ではなく「使える状態に整う」ことがゴールなので、作成時点で owners を必ず指定する設計が安全です。

所有者やメンバーを作成時に付与するなら、追加で “参照権限” が必要になります。たとえば users を owners/members として指定するには、アプリに User.Read.All 以上が必要、と整理されています。権限は増やせば動きますが、GCC High は監査・セキュリティレビューも厳しくなりやすいので、「最小権限＋必要な参照権限」 で設計しておくと後が楽です。

トークン取得：login.microsoftonline.us と scope の落とし穴

GCC High のトークン発行元は https://login.microsoftonline.us です。ここを login.microsoftonline.com のまま実装してしまうと、認証フローそのものが通りません。

もう一つの落とし穴が scope（または resource）に含める Graph ドメインです。Graph SDK のドキュメントでも、国別クラウドでは https://graph.microsoft.us/.default のように Graph ルートに合わせたスコープ を使う必要がある、と明記されています。つまり “.default は同じでもドメインが違う” ということです。

クライアント資格情報（アプリのみ）の例

自動化でよく使うクライアント資格情報フローの例です。Tenant ID、Client ID、Client Secret（または証明書）を使ってトークンを取得し、そのトークンで Graph を呼びます。

POST https://login.microsoftonline.us/{tenant-id}/oauth2/v2.0/token
Content-Type: application/x-www-form-urlencoded

client_id={client-id}
&scope=https%3A%2F%2Fgraph.microsoft.us%2F.default
&client_secret={client-secret}
&grant_type=client_credentials

このとき発行されたアクセストークンの aud（対象）が https://graph.microsoft.us になっているか、JWT をデコードして確認するとトラブルが減ります。「aud が graph.microsoft.com のまま」なら、scope の指定や取得先が間違っています。

委任（ユーザーサインイン）の例

ユーザーの操作に基づいてグループを作成する場合は、認可コードフローなどの委任フローを使います。ベース URL は同じく login.microsoftonline.us で、取得したアクセストークンで graph.microsoft.us にアクセスします。委任フローは条件付きアクセスや MFA の影響も受けるため、業務運用の要件（誰が、どこから実行するか）と合わせて設計するのがコツです。

Microsoft Graph で Microsoft 365 グループを作成する

実際の作成はシンプルで、POST https://graph.microsoft.us/v1.0/groups に JSON を投げます。ボディは Microsoft Graph の group リソースで、Microsoft 365 グループ（Unified）を作るなら groupTypes に Unified を入れます。

最小構成のリクエスト例

POST https://graph.microsoft.us/v1.0/groups
Content-Type: application/json
Authorization: Bearer {access-token}

{
"displayName": "GCC High Project Alpha",
"description": "GCC High 環境での検証用グループ",
"groupTypes": ["Unified"],
"mailEnabled": true,
"mailNickname": "gcchigh-project-alpha",
"securityEnabled": false,
"visibility": "Private"
}

displayName、mailEnabled、mailNickname、securityEnabled は必須です。特に mailNickname は「ASCII の範囲で、使えない記号がある」など制約が明確なので、命名規則に “使える文字だけ” を落とし込むのが安全です（日本語やスペースを入れない運用が無難です）。

必須・頻出プロパティの早見表

プロパティ意味Microsoft 365 グループの典型値補足
groupTypesグループ種別・メンバーシップ[“Unified”]Dynamic を使う場合は “DynamicMembership” を追加
mailEnabledメール機能を有効にするtrueMicrosoft 365 グループは基本 true
mailNicknameメールエイリアス（ユニーク）英数字＋ハイフンなど禁止文字があるため運用ルール化が必須
securityEnabledセキュリティグループとしての有効化falseセキュリティグループなら true
visibility公開範囲Private / Public要件に合わせてテンプレ化しておくとブレない

所有者・メンバーを作成時に付ける（推奨）

プロビジョニング用途なら、作成と同時に owners/members を付けて “使える状態” を作るのが鉄板です。Teams 連携まで見据える場合も、まず Microsoft 365 グループを作り、所有者とメンバーを揃えた上で Team 化する流れが推奨されています。

POST https://graph.microsoft.us/v1.0/groups
Content-Type: application/json
Authorization: Bearer {access-token}

{
  "displayName": "GCC High Team Ready Group",
  "description": "Owners/Members 付きで作成",
  "groupTypes": ["Unified"],
  "mailEnabled": true,
  "mailNickname": "gcchigh-team-ready",
  "securityEnabled": false,
  "visibility": "Private",
  "[email protected]": [
    "https://graph.microsoft.us/v1.0/users/{owner-user-id-1}",
    "https://graph.microsoft.us/v1.0/users/{owner-user-id-2}"
  ],
  "[email protected]": [
    "https://graph.microsoft.us/v1.0/users/{member-user-id-1}",
    "https://graph.microsoft.us/v1.0/users/{member-user-id-2}"
  ]
}

作成時に追加できる owners/members などの関連付けには上限（最大 20 関係）があります。大量のメンバー追加は作成後に分割して投入する設計にしておくと、失敗時の切り分けも簡単です。

作成前に “重複” をチェックして、二重作成を防ぐ

実運用では、同じ申請が複数回流れたり、リトライ処理で二重に作られたりする事故が起きがちです。対策としては、mailNickname をキーにして事前チェックを入れるのが扱いやすいです（組織の命名規則が安定している前提）。

GET https://graph.microsoft.us/v1.0/groups?$filter=mailNickname eq 'gcchigh-team-ready'&$select=id,displayName,mailNickname

既に存在する場合は作成をスキップし、必要なら owners/members の整合だけ取る──という “冪等” 設計にしておくと、運用が一気に安定します。

作成後に起きやすい “反映遅延” を前提にする

Microsoft 365 のプロビジョニングは非同期要素が多く、「API の 201 が返った＝全サービスに即時反映」ではありません。たとえば Teams を作る場合、グループ作成後に最大 15 分程度待ってから Team 作成を実行する、というガイダンスがあります。スクリプトで連続実行する場合は 待ち や リトライ を最初から組み込むと、運用が安定します。

また、所有者やメンバーの変更が Teams 側へ同期されるまで時間がかかる場合がある点も、運用上の注意事項です。現場では「作成直後に Teams に出てこない」問い合わせが起きやすいので、説明用の運用ルール（反映時間の目安、確認手順）を用意しておくのがおすすめです。

ネットワーク制限がある環境での確認ポイント

GCC High ではインターネット接続を厳格に制御している組織も多く、Graph 実装そのものより ネットワーク疎通 が原因で止まるケースがあります。Microsoft は GCC High プラン向けに到達が必要なエンドポイント一覧を公開しており、そこには Graph（graph.microsoft.us）や認証（login.microsoftonline.us）、SharePoint（*.sharepoint.us）などが含まれます。

用途代表的な FQDN（例）コメント
Graph APIgraph.microsoft.usAPI 呼び出し先。プロキシでブロックされると 502/timeout になりやすい
認証・トークンlogin.microsoftonline.usここが通らないとトークンが取れない
SharePoint / OneDrive*.sharepoint.usグループに紐づくサイト/ドキュメント連携で必要
Exchange（Outlook）outlook.office365.usグループのメール/予定表連携に影響
Teamsgov.teams.microsoft.usTeams まで含めた自動化の場合に確認

さらに最近は、Microsoft 365 の統合ドメインとして *.usgovcloud.microsoft 系のドメインが “必須” として案内されるケースもあります。ゼロトラストや厳格な許可リスト運用の場合は、Graph 実装担当だけでなくネットワーク担当とも早めに合意しておくと、後戻りが減ります。

よくあるエラーと原因の切り分け

GCC High の Graph 実装で遭遇しやすいエラーを、原因と対策で整理します。特に「間違ったクラウドのエンドポイントを混ぜている」ケースが多いので、まずは URL とトークンの発行元を疑うのが近道です。

症状代表的な原因対策
401 / InvalidAuthenticationTokenaud が graph.microsoft.com など別クラウドtoken 取得先を login.microsoftonline.us に、scope を graph.microsoft.us に合わせる
403 / Insufficient privilegesGroup.Create 等の権限不足、管理者同意未実施最小権限を再確認し、Admin consent まで完了させる
400 / Bad RequestmailNickname の文字制約違反、既に重複命名規則を ASCII のみ＋禁止文字なしに統一し、重複チェックを入れる
201 は返るが SharePoint サイトができないアプリのみ＋owners 未指定で “匿名グループ” になっている作成時に owners を必ず指定（最低 2 名推奨）
Teams 化が失敗する / 反映が遅いグループ作成直後でプロビジョニングが未完了待機＋リトライを組み込む（最大 15 分目安）

Graph SDK / PowerShell での実装をラクにするコツ

REST を直接叩くのが最小構成ですが、運用で重要なのは「環境差分を吸収できること」です。Graph SDK や Microsoft Graph PowerShell を使うと、国別クラウドのエンドポイント切り替えをパラメータ化しやすくなります。

Microsoft Graph SDK のベース URL を US Gov L4 に合わせる

Graph SDK では、認証プロバイダーを政府クラウドの Authority（login.microsoftonline.us）に向け、Graph クライアントのベース URL を https://graph.microsoft.us に切り替えます。さらに .default のドメインも graph.microsoft.us に合わせる必要があります。

Microsoft Graph PowerShell の例

Connect-MgGraph -Environment USGov -TenantId "{tenant-id}" -ClientId "{client-id}" -Scopes "https://graph.microsoft.us/.default"

$params = @{
displayName     = "GCC High PS Group"
description     = "PowerShell から作成"
groupTypes      = @("Unified")
mailEnabled     = $true
mailNickname    = "gcchigh-ps-group"
securityEnabled = $false
}

New-MgGroup -BodyParameter $params

PowerShell は検証にも運用にも使いやすいので、「まずは疎通確認・権限確認を PowerShell で行い、OK になったらアプリ実装へ落とし込む」流れにすると、失敗コストを減らせます。

PnP PowerShell / CSOM はいつ選ぶべきか

「グループを作りたいだけ」なら Graph API が最短です。一方で、実務ではグループ作成の後に SharePoint サイトの細かい設定（サイトデザイン、リスト、権限、ナビゲーション、テンプレート適用）まで一気に自動化したくなります。この領域では PnP PowerShell が強力です。

PnP PowerShell は GCC や国別クラウド向けの接続方法も整理されており、Connect-PnPOnline の -AzureEnvironment で USGovernmentHigh を指定して接続できる、と案内されています。SharePoint 側の作業が主目的なら、PnP を組み合わせる価値があります。

ただし CSOM（Client-Side Object Model）は、用途によっては情報が断片的になりがちで、第三者サイトの断片コードに頼ると “GCC High で動くか／要件に適合するか” の判断が難しくなります。CSOM を採用するなら、まず Graph で目的を満たせない理由（不足 API、運用要件、権限分離など）を明確にし、そのうえで公式ドキュメントと照合しながら進めるのが安全です。

運用で効く実践テクニック

最後に、単に “作れる” から一歩進めて、GCC High の現場でトラブルを減らすためのコツをまとめます。

  • 命名規則を mailNickname 目線で決める：mailNickname の制約に合う文字だけを許可し、重複チェック（既存検索）を必ず入れる
  • 所有者は最初から複数人：運用上の属人化を防ぎ、Teams 化やサイト管理の詰まりを避ける
  • アプリのみの場合は owners を必須にする：匿名グループ化や SharePoint サイト未作成を避ける
  • 待機とリトライを設計に組み込む：反映遅延がある前提で、段階ごとに状態確認（GET）を挟む
  • ネットワーク許可リストを先に握る：認証・Graph・SharePoint の FQDN を早期に合意する
  • 検証は PowerShell→アプリ実装の順：権限・エンドポイントの差分を短時間で切り分けられる

GCC High はコンプライアンス要件が強い分、環境差分による “思い込みのバグ” が起きやすい領域です。だからこそ、エンドポイント（graph.microsoft.us / login.microsoftonline.us）を最初に固定し、最小権限で段階的に作り込むのが、結果的に最短ルートになります。

Microsoft 365
Microsoft Graph Microsoft 365 グループ GCC High Azure Government

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次