Microsoft は 2026 年 5 月 12 日に Microsoft Graph PowerShell SDK V2.37 をリリースした。しかしその裏では、SDK の生成パイプラインを支える中核ツール「AutoRest」の廃止予告が静かに掲示されており、M365 自動化に取り組む管理者・エンジニアに不安が広がっている。

Microsoft Graph PowerShell SDK V2.37 の概要

V2.37 は 5 月 12 日のリリース以降、現時点では安定して動作しているとの報告が多い。ただし、いきなり本番環境へ展開するのは禁物だ。まずワークステーション環境で主要スクリプトをテストしてから段階的に展開するのがベストプラクティスとなる。

特に Azure Automation のランタイム環境を利用している場合は注意が必要だ。SDK モジュール間には Microsoft.Graph.Authentication モジュールへの依存関係があるため、同一のランタイム環境内に異なるバージョンのモジュールを混在させることはできない。たとえば、Microsoft.Graph.Authentication が V2.36.1 の環境に Microsoft.Graph.User.Actions の V2.37 だけをインストールしようとしてもエラーになる。すべてのモジュールを同一バージョンに統一することが前提となる。

ダウンロード数が示す普及の加速

前バージョンの SDK V2.36.1 のダウンロード数は 104 万回超を記録した。旧来の AzureAD モジュールおよび MSOnline モジュールの廃止に伴い、代替手段として SDK への移行が本格化した結果だ。SDK をベースとした Entra モジュール(v1.2.0)もさらに約 30 万ダウンロードを積み上げており、Microsoft の認証・認可系 PowerShell エコシステムが SDK 中心へと集約されつつあることがよくわかる。

AutoRest 廃止問題——自作自演の混乱

2026 年 2 月 27 日、Microsoft は GitHub リポジトリ上で AutoRest の廃止予告を静かに掲示した。廃止予定日は 2026 年 7 月 1 日だ。

AutoRest は、Microsoft Graph PowerShell SDK の生成パイプラインにおいて中核的な役割を担っている。Graph API の OpenAPI ドキュメントを読み込み、REST 呼び出しのひな型・パラメーター・プロパティ・コマンドレットのアウトラインを自動生成するのが AutoRest の役割だ。その出力をさらに PowerShell 専用の処理で変換することで、最終的なコマンドレットとモジュールが完成する。

問題の核心は、現時点でこのパイプラインにおける AutoRest の代替手段が存在しないことだ。Microsoft は代替として TypeSpec を提案しているが、PowerShell ユーザーへのサポートが追いついておらず、現実的な移行先とは言えない状況だ。

「廃止 ≠ 即停止」だが不安は残る

「廃止」は 7 月 1 日に AutoRest が突然動かなくなるという意味ではない。ツールそのものはメンテナンスモードで動き続ける見通しだ。しかし「メンテナンス状態に入った」という事実は、CIO・CTO のリスク判断に直結する。本番環境に組み込んでいるツールが廃止予告を受けただけで、多くの企業では使用継続の可否を再審査するプロセスが走る。

本質的な問題は、Microsoft が自社の SDK 生成パイプラインに使用しているツールを、代替手段を用意しないまま廃止予告したことだ。PowerShell コミュニティへの十分な配慮なく、GitHub リポジトリにひっそりと掲示するというアプローチは、以前の AzureAD / MSOnline 廃止騒動を経た今となっては余計に惜しい対応に映る。

実務への影響——日本の M365 管理者が取るべき行動

短期対応(今すぐ確認すべきこと)

  • SDK のバージョン管理を再確認する: Azure Automation のランタイム環境を使用している場合、Microsoft.Graph.Authentication を含む全モジュールのバージョンが一致しているか確認する
  • V2.37 のテストを先行実施する: 本番展開の前に開発・テスト環境で主要スクリプトを検証する
  • AutoRest への依存有無を棚卸しする: 自組織で Graph API 関連の SDK やツールを内製開発している場合、AutoRest を直接利用しているコードや CI/CD パイプラインがないか確認する

中長期視点

  • Microsoft が公式の代替ソリューションを提示するまでは、既存の SDK を使い続けることが現実的な選択肢だ
  • AutoRest が廃止されても SDK 自体がすぐに使えなくなるわけではないため、過度に慌てる必要はない
  • ただし、7 月以降の Microsoft の公式アナウンスを注視し続けることは必須だ

筆者の見解

M365 の自動化・管理に携わるエンジニアにとって、PowerShell SDK は今や欠かせないインフラだ。SDK のダウンロード数が 100 万回を超えたという数字は、日本を含む世界中の M365 管理者が SDK への移行を粛々と進めていることを裏付けている。

その一方で、今回の AutoRest 廃止問題は、技術的な中身以上に Microsoft のコミュニティとのコミュニケーション姿勢を問い直す出来事として印象に残った。旧 AzureAD / MSOnline の廃止を巡る混乱を経験した後だからこそ、重要インフラに関わるツールの廃止予告はもっと丁寧に扱ってほしかった。GitHub リポジトリにひっそり書き込む形ではなく、ブログや Tech Community での正式なアナウンスとロードマップの提示があれば、コミュニティの不安は大幅に小さかったはずだ。

Microsoft には PowerShell SDK を中長期的に支え続ける意志があるはずだ。それを証明するためにも、AutoRest の後継をどう扱うかについての明確なロードマップを早期に示すことを期待したい。正面から向き合える力のある企業なのだから、この程度の課題は整理できるはずだと信じている。

なお、「Automating Microsoft 365 with PowerShell」eBook は第 24 版(2026 年 6 月版)が公開されており、Gumroad.com から EPUB・PDF 形式でダウンロード可能だ。


出典: この記事は Automating Microsoft 365 with PowerShell June 2026 Update の内容をもとに、筆者の見解を加えて独自に執筆したものです。