この記事について
この記事は、生成AIを活用した自動生成フローで作成しています。Microsoft Graphの認証・スロットリング公式資料を確認し、旧記事の性能値と「SDKなしなら高速」という単純化を修正しました。検証ステータス：✅ Microsoft Graph公式仕様確認済み
Microsoft GraphはHTTP APIなので、PowerShellのInvoke-RestMethodから直接呼べます。公式SDKを使わない構成は軽量ですが、その代わりにページング、再試行、認証、エラー処理を自分で実装する必要があります。
REST直呼びが向くケース
- 呼ぶAPIが少なく、処理内容が固定されている。
- 実行環境へ追加モジュールを入れたくない。
- HTTP要求とレスポンスを自分で制御したい。
多数のGraph機能を横断するツールや、認証・型・再試行をまとめて扱いたい場合は、公式SDKの方が保守しやすいこともあります。
共通処理を関数へまとめる
function Invoke-GraphGet {
param(
[string]$Uri,
[string]$AccessToken
)
$headers = @{ Authorization = "Bearer $AccessToken" }
Invoke-RestMethod -Method Get -Uri $Uri -Headers $headers -ErrorAction Stop
}実運用ではこの共通関数へ、429時の待機、5xx時の限定的な再試行、ログ、タイムアウトなどを追加します。
ページングを忘れない
一覧APIではレスポンスの@odata.nextLinkを最後までたどる必要があります。$topを大きくしただけで全件取得できるとは限りません。
429ではRetry-Afterを使う
Microsoft Graphの公式ガイダンスでは、HTTP 429が返った場合はRetry-Afterヘッダーに従って待機し、再試行します。高い並列度で429を増やすより、必要なAPI呼び出し自体を減らせないか先に確認します。
性能は環境ごとに測る
SDKの読み込み時間、ネットワーク遅延、Graph側の応答、テナント規模などで結果は変わります。「3.5倍〜5倍高速」などの固定値は一般化できません。Measure-Commandで自分の処理を測り、成功率と429件数も合わせて比較します。
公式情報
この記事の更新履歴
- 2026-09-14 追加：REST直呼びが向く条件、共通関数、ページングとRetry-Afterを追加。
- 2026-09-14 変更：SDK排除を目的化せず、保守性との比較を含む構成へ変更。
- 2026-09-14 削除：内部執筆指示、本文H1、3.5〜5倍高速化やメモリ削減の未検証値を削除。
