この記事について
この記事は、生成AIを活用した自動生成フローで作成しています。Microsoft identity platformとMicrosoft Graphの公式資料を確認し、旧記事の固定パスワード例、根拠のない処理時間、並列化優先の設計を修正しました。検証ステータス：✅ Microsoft公式仕様確認済み
Microsoft GraphをPowerShellから大量処理するとき、最初に考えるべきことは「何件同時に投げるか」ではありません。認証、最小権限、再試行、重複実行時の扱いを決めてから並列化します。
アプリ認証は秘密値をコードへ残さない
Client Credentials Flowでは、管理者がアプリケーションへApplication permissionを付与し、アプリ自身の資格情報でトークンを取得します。共有シークレットでも実装できますが、長期運用では証明書やフェデレーション資格情報を優先できるか検討します。
$tokenUri = "https://login.microsoftonline.com/$TenantId/oauth2/v2.0/token"
$body = @{
client_id = $ClientId
scope = "https://graph.microsoft.com/.default"
client_secret = $ClientSecret
grant_type = "client_credentials"
}
$token = (Invoke-RestMethod -Method Post -Uri $tokenUri -Body $body).access_tokenこの例はプロトコル構造を示すためのものです。実運用ではClientSecretをソースへ直書きしません。
429は失敗ではなく制御信号として扱う
Microsoft Graphは要求量が多いと429 Too Many Requestsを返します。公式ガイダンスでは、レスポンスのRetry-Afterを待って再試行することが基本です。値がない場合は指数バックオフを使います。
ユーザー作成は冪等性を先に決める
大量作成では二重実行が現実的に起こります。CSVの各行へ一意キーを持たせ、作成前にUPNなどで既存状態を確認し、「存在するなら更新・スキップ・エラー」のどれにするかを明示します。
- dry-runで対象件数を確認する。
- 1件ごとに成功・失敗・request-idを記録する。
- 固定の初期パスワードを全員へ配布しない。
- 429/5xxだけを上限付きで再試行する。
- 並列度は実測で調整する。
「100件30秒」のような固定値は置かない
Graphの処理時間はテナント、API、ネットワーク、スロットリング、後続プロビジョニングで変わります。性能記事では、件数、並列度、429件数、再試行回数、総時間を実測値として残します。
公式情報
この記事の更新履歴
- 2026-09-14 追加：Retry-After、冪等性、証明書/フェデレーション資格情報の検討観点を追加。
- 2026-09-14 変更：並列化中心の説明から、認証・再試行・重複防止を先に設計する構成へ変更。
- 2026-09-14 削除：内部style_prompt、本文H1、固定TemporaryPass、根拠のない100件30秒という性能値を削除。
