この記事について
この記事は、生成AIを活用した自動生成フローで作成しています。Microsoft Graphのapp-only認証とスロットリング公式資料を確認し、旧記事の性能値と危険な並列化前提を修正しました。検証ステータス：✅ Microsoft公式仕様確認済み
Microsoft Graph PowerShell SDKを使わず、Invoke-RestMethodでREST APIを直接呼ぶことは可能です。重要なのは「SDKを外せば速くなる」と決めつけることではなく、認証、ページング、スロットリング、失敗時の再開を自分で実装する点です。
app-only認証の基本
クライアント資格情報フローでは、トークンエンドポイントへclient_id、client_secret、grant_type=client_credentialsを送り、Microsoft Graph用のscopeにはhttps://graph.microsoft.com/.defaultを指定します。アプリには事前に必要なApplication permissionと管理者同意が必要です。
ユーザー一覧は@odata.nextLinkを最後までたどる
$headers = @{ Authorization = "Bearer $AccessToken" }
$url = 'https://graph.microsoft.com/v1.0/users?$select=id,displayName,userPrincipalName&$top=999'
$users = @()
do {
$r = Invoke-RestMethod -Method Get -Uri $url -Headers $headers
$users += $r.value
$url = $r.'@odata.nextLink'
} while ($url)
$users$topを指定しても全件が一度に返るとは限りません。レスポンスに@odata.nextLinkがある間は、そのURLをそのまま使って次ページを取得します。
並列化より先に429へ対応する
Microsoft Graphは過剰な呼び出しに対してHTTP 429を返します。公式ガイダンスでは、レスポンスのRetry-Afterを待って再試行することが基本です。固定10秒待機より、サービスが返す待機時間を優先します。
ユーザーごとにlicenseDetailsを並列取得する設計は、テナント規模やAPI負荷によっては逆に429を増やします。まず必要な属性を$selectでまとめて取得できないか検討し、追加APIが必要な場合だけ並列度を小さく始めます。
SDKなし運用で増える責任
- アクセストークンの取得と更新
- ページング
- 429・5xxの再試行
- 権限設計
- エラー詳細と失敗対象の保存
SDKの有無は目的ではありません。軽量な単機能スクリプトにはREST直呼びが向き、認証・再試行・型付きコマンドレットを含む保守性を重視するなら公式SDKも比較対象です。
公式情報
この記事の更新履歴
- 2026-09-14 追加：app-only認証、@odata.nextLink、Retry-Afterを使う実装ポイントを追加。
- 2026-09-14 変更：「SDK不要=高速」という構成から、REST直呼びの運用責任を含む実務記事へ変更。
- 2026-09-14 削除：内部執筆指示、本文H1、根拠のない60〜70%高速化・規模別性能断定を削除。
