Microsoft GraphでM365運用を自動化する ― 一括変更はdry-run・再試行・監査を先に設計

この記事について
この記事は、生成AIを活用した自動生成フローで作成しています。Microsoft Graphのapp-only認証とスロットリング公式資料を確認し、旧記事の「数百名を数分」や60〜70%高速化といった未計測値、固定待機の例を修正しました。

検証ステータス：✅ Microsoft Graph公式仕様確認済み

Microsoft Graphを使えば、ユーザーやグループなどMicrosoft 365の管理処理を自動化できます。ただし一括変更では、処理速度より対象確認・再実行性・停止条件の方が重要です。

変更前にdry-runを作る

CSVからユーザーを作成するなら、最初の工程はPOSTではなく入力検証にします。UPN重複、必須項目、対象件数、想定テナントを確認し、実際に変更する一覧をCSVやJSONへ出力します。

$plan = Import-Csv ./users.csv | ForEach-Object {
    [pscustomobject]@{
        UserPrincipalName = $_.UserPrincipalName
        DisplayName       = $_.DisplayName
        Action            = 'Create'
        Valid             = -not [string]::IsNullOrWhiteSpace($_.UserPrincipalName)
    }
}

$plan | Export-Csv ./change-plan.csv -NoTypeInformation -Encoding utf8

429はRetry-Afterに従う

GraphがHTTP 429を返した場合、MicrosoftはレスポンスのRetry-Afterで示された時間を待って再試行するよう案内しています。固定10秒や無制限リトライではなく、最大試行回数と停止条件も設定します。

並列度はAPI負荷とセットで決める

ForEach-Object -Parallelで並列化はできますが、高いThrottleLimitが常に速いわけではありません。書き込みAPIでは特に、成功率、429件数、処理時間を測りながら小さく調整します。

変更ログを残す

• 入力データの識別子
• 実行対象
• HTTP結果
• 作成・変更後のオブジェクトID
• 失敗理由
• 再試行回数

失敗した行だけを再実行できる形にすると、100件中1件の失敗で全件をやり直す必要がありません。

公式情報

• Microsoft Graph ― Get access without a user
• Microsoft Graph throttling guidance

この記事の更新履歴

• 2026-09-14 追加：dry-run、失敗対象だけの再実行、Retry-After中心の運用設計を追加。
• 2026-09-14 変更：高速一括処理中心から、安全な変更管理中心の記事へ再構成。
• 2026-09-14 削除：内部執筆指示、本文H1、「数分で完結」、60〜70%短縮など未計測の性能値を削除。