2026年4月30日のMicrosoft Entra公式ドキュメント更新「Update deprecated AzureAD PowerShell references」は、新機能の追加ではなく、非推奨となったAzureAD PowerShell参照をMicrosoft Graph PowerShellへ寄せるための更新です。結論として、管理者がまず確認すべきなのは、Microsoft Entraの仕様変更そのものではなく、社内手順書・自動化スクリプト・監査資料に古いAzureAD PowerShellコマンドが残っていないかです。
特に影響を受けやすいのは、Security Defaultsの有効化時にトークンを失効させる運用、Application ProxyとPingAccessを使ったヘッダーベース認証の構成、そしてAzureAD / AzureADPreview / MSOnlineモジュールに依存した既存スクリプトです。今回の更新を「ドキュメントの軽微な修正」と見なすのではなく、Microsoft Graph PowerShell移行の確認ポイントとして扱うべきです。(GitHub)
Microsoft Entraの公式ドキュメント更新で何が変わったか
今回のMicrosoftDocs/entra-docsのコミットでは、Microsoft Entra関連ドキュメント内に残っていた非推奨のAzureAD PowerShell参照が更新されました。変更対象は2つのドキュメントで、差分としては3行追加・1行削除の小さな更新です。ただし、対象になっている内容は管理運用に直結します。(GitHub)
| 変更対象 | 変更内容 | 管理者が確認すべき点 |
|---|---|---|
security-defaults.md | Revoke-AzureADUserAllRefreshToken が Revoke-MgUserSignInSession に置き換えられた | Security Defaults有効化時、MFA再登録や再認証を促す手順で古いcmdletを使っていないか |
application-proxy-ping-access-publishing-guide.md | New-AzureADPolicy / Add-AzureADServicePrincipalPolicy のサンプル前に、Azure AD PowerShell非推奨の注意書きが追加された | PingAccess連携やクレームマッピングの手順を、そのまま新規運用に流用していないか |
重要なのは、1つ目の変更では古いcmdletが明確にMicrosoft Graph PowerShell SDKのcmdletへ置き換えられている一方、2つ目の変更では既存サンプルが残されたまま注意書きが追加されている点です。後者は「このサンプルを見ればそのまま使ってよい」という意味ではありません。Microsoft側のコミット説明でも、インラインでMicrosoft Graphへ変換するには例の再構成が必要なため、移行ガイダンスへ誘導する注意書きを追加したと説明されています。(GitHub)
Security Defaultsで確認すべきポイント
Security Defaultsのドキュメントでは、セキュリティの既定値を有効化する一環として、既存トークンを失効させ、ユーザーにMFA登録と再認証を求める手順が説明されています。現在の公式ドキュメントでは、この処理に Revoke-MgUserSignInSession を使う記載になっています。(Microsoft Learn)
旧コマンドを使った手順書を更新する
まず確認すべきなのは、社内ナレッジ、運用Runbook、インシデント対応手順、構築チェックリストに次のような記載が残っていないかです。
Revoke-AzureADUserAllRefreshTokenこれが残っている場合、Microsoft Graph PowerShell SDKの次のcmdletを前提に手順を見直します。
Import-Module Microsoft.Graph.Users.Actions
Connect-MgGraph -Scopes "User.RevokeSessions.All"
Revoke-MgUserSignInSession -UserId "[email protected]"Revoke-MgUserSignInSession は、対象ユーザーの更新トークンやブラウザーのセッションCookieを無効化し、ユーザーに再サインインを求めるためのcmdletです。実行には、少なくとも User.RevokeSessions.All などの権限が関係します。過剰な Directory.ReadWrite.All を安易に付与するのではなく、まず最小権限で足りるかを確認してください。(Microsoft Learn)
「即時にすべてのアプリからログアウト」と誤解しない
トークン失効の運用でよくある失敗は、Revoke-MgUserSignInSession を実行すれば、すべてのアプリケーションセッションが即座に終了すると考えてしまうことです。
Microsoft Entra IDが直接制御できるのは、Entra IDが発行するトークンです。一方、アプリケーションが独自に発行したセッショントークンは、そのアプリケーション側の認可ポリシーやセッション管理に依存します。Microsoftの緊急アクセス取り消しドキュメントでも、アプリケーションが発行したセッショントークンはMicrosoft Entra IDから直接失効できないと説明されています。(Microsoft Learn)
| 確認項目 | 実務上の判断基準 |
|---|---|
| Microsoft Entra IDの更新トークン | Revoke-MgUserSignInSession の対象。再サインインを促す目的で使う |
| アプリ独自のセッション | アプリ側のログアウト、セッション期限、プロビジョニング解除も確認する |
| SaaSや業務アプリ | Entra ID連携だけでなく、アプリ側のユーザー無効化や権限削除まで手順化する |
| インシデント対応 | 「パスワード変更」「アカウント無効化」「トークン失効」「端末無効化」を分けて記録する |
セキュリティ管理者は、トークン失効コマンドを置き換えるだけでなく、「どこまでアクセス遮断できたか」を確認する運用に変える必要があります。
Application ProxyとPingAccessのサンプルで注意すべき点
もう1つの更新対象は、Microsoft Entra Application ProxyとPingAccessを使ったヘッダーベース認証のドキュメントです。該当箇所では、カスタムクレームを扱うためのポリシー定義と割り当てに New-AzureADPolicy と Add-AzureADServicePrincipalPolicy を使うサンプルが掲載されています。今回の更新では、このサンプルの前にAzure AD PowerShell非推奨の注意書きが追加されました。(Microsoft Learn)
この変更は、Application ProxyやPingAccessの機能が変わったというより、古いPowerShellサンプルを読むときの前提が変わったと捉えるべきです。
サンプルをそのまま新規標準にしない
企業の現場では、公式ドキュメントに載っているサンプルをコピーして、構築手順書やIaC周辺の補助スクリプトに組み込むことがあります。しかし、今回のように非推奨注意書きが追加されたサンプルは、そのまま新規標準として採用すべきではありません。
特に次のケースでは、レビューを必須にしてください。
| ケース | 推奨される対応 |
|---|---|
| 新規にApplication ProxyとPingAccessを構成する | AzureAD PowerShell前提の手順ではなく、Microsoft Graph PowerShellまたはMicrosoft Graph APIで実装できるか検証する |
既存手順書に New-AzureADPolicy が残っている | 実行頻度、影響範囲、代替手段を整理し、移行タスクとして管理する |
| 監査証跡にAzureAD PowerShellの利用が残っている | 「非推奨モジュールを継続利用している理由」と「移行予定日」を記録する |
| 外部ベンダーが構築・保守している | ベンダーにMicrosoft Graph対応状況と保守対象モジュールを確認する |
この種のサンプルは、検証環境で過去構成を理解するためには役立ちます。一方で、本番環境の新規構築や長期運用では、非推奨モジュールへの依存を増やさない判断が重要です。
AzureAD PowerShell移行が必要な理由
AzureAD PowerShellとAzureADPreview PowerShellは、2025年10月中旬から停止が始まるとMicrosoftから案内されています。また、2025年9月には一時的な停止テストも予定されていました。Microsoftは、これらのモジュールを使うスクリプトをMicrosoft Graph PowerShell SDKまたはMicrosoft Entra PowerShellへ移行するよう求めています。(TECHCOMMUNITY.MICROSOFT.COM)
ただし、移行は単純なコマンド名の置き換えではありません。Microsoft Graph PowerShellの移行ドキュメントでも、Azure AD PowerShellのスクリプトはMicrosoft Graph PowerShellで自動的に動くわけではなく、モジュール名、パラメーター、権限、戻り値などの違いを確認する必要があると説明されています。(Microsoft Learn)
Microsoft Graph PowerShellとMicrosoft Entra PowerShellの使い分け
移行先としては、主にMicrosoft Graph PowerShell SDKとMicrosoft Entra PowerShellが候補になります。
Microsoft Graph PowerShell SDKは、Microsoft Graph APIをPowerShellから扱うための標準的な選択肢です。今回の Revoke-MgUserSignInSession のように、公式ドキュメントで具体的なGraph PowerShell cmdletが示されている場合は、まずそのcmdletを基準に確認します。
一方、Microsoft Entra PowerShellはMicrosoft Graph PowerShell SDKの上に構築され、Microsoft Entraリソースを管理・自動化するためのモジュールです。公式ドキュメントでは、Azure AD PowerShellからの移行を支援する互換性オプションがあることも説明されています。(Microsoft Learn)
| 移行先 | 向いているケース | 注意点 |
|---|---|---|
| Microsoft Graph PowerShell SDK | Graph APIベースで標準化したい、権限を細かく設計したい | 旧AzureAD cmdletとのパラメーター差分を確認する必要がある |
| Microsoft Entra PowerShell | AzureAD PowerShellからの移行負荷を抑えたい | 互換性だけに頼らず、長期運用ではGraphの権限設計も確認する |
| Microsoft Graph API | アプリケーションや自動化基盤から直接呼び出したい | アプリ登録、証明書、アプリケーション権限、監査設計が必要 |
既存環境で実施すべき確認手順
今回の更新を受けて、security admins、compliance teams、enterprise IT readersが実施すべき確認は次の流れです。
既存スクリプトを棚卸しする
まずは、リポジトリ、共有フォルダー、運用端末、CI/CD、タスクスケジューラーに残っているPowerShellスクリプトを検索します。対象は .ps1 だけでなく、.psm1、.psd1、Markdown化された手順書、チケットテンプレートも含めます。
Get-ChildItem -Path . -Recurse -Include *.ps1,*.psm1,*.psd1,*.md |
Select-String -Pattern 'AzureAD|AzureADPreview|MSOnline|Revoke-AzureADUserAllRefreshToken|New-AzureADPolicy|Add-AzureADServicePrincipalPolicy' |
Select-Object Path, LineNumber, Line検索結果は、単に「見つかった数」ではなく、次の観点で分類します。
| 分類 | 判断基準 |
|---|---|
| 即時対応 | 認証、トークン失効、アカウント無効化、条件付きアクセス、アプリ権限に関わる |
| 計画対応 | レポート取得、棚卸し、定期監査など、停止しても即時影響が限定的 |
| 廃止候補 | 実行実績がない、担当者不明、過去の移行時だけ使った |
| ベンダー確認 | 自社で修正できない、パッケージ製品や外部運用に含まれる |
Microsoft Entra側の利用状況も確認する
スクリプト検索だけでは、実際にどのモジュールが使われているかを把握しきれません。Microsoftは、AzureAD PowerShell利用の把握方法として、Microsoft Entra Recommendationsとサインインログを挙げています。サインインログでは、アプリケーション名「Azure Active Directory PowerShell」で検索することで、非推奨モジュールによるサインイン要求を確認できます。(TECHCOMMUNITY.MICROSOFT.COM)
確認時は、次の情報を記録しておくと移行計画を立てやすくなります。
| 記録項目 | 使い道 |
|---|---|
| 実行ユーザーまたはサービスアカウント | 所有者特定、権限見直し |
| 実行日時と頻度 | 移行優先度の判断 |
| 実行元IPや端末 | 自動化基盤、運用端末、外部委託先の切り分け |
| 対象操作 | ユーザー管理、アプリ管理、ポリシー管理などの分類 |
| 代替候補 | Microsoft Graph PowerShell、Microsoft Entra PowerShell、Graph API |
権限と同意の設計をやり直す
AzureAD PowerShell時代の運用では、広い管理者権限を持つアカウントでスクリプトを実行しているケースが少なくありません。Microsoft Graph PowerShellへ移行する際は、cmdletの置き換えだけでなく、権限の同意設計も見直します。
たとえば、Revoke-MgUserSignInSession では User.RevokeSessions.All が最小権限側の候補として示されています。最初から Directory.ReadWrite.All のような強い権限を付けると、監査や最小権限の観点で説明しづらくなります。(Microsoft Learn)
実務では、次のように分けて設計すると安全です。
| 用途 | 推奨される考え方 |
|---|---|
| 手動運用 | 管理者の職務に必要な委任権限だけを付与する |
| 自動化 | 専用アプリ登録やマネージドIDを使い、用途ごとに権限を分ける |
| 緊急対応 | 実行手順、承認、証跡、対象範囲を事前に決める |
| 監査 | 誰が、いつ、どのスコープで、何を実行したかを残す |
コンプライアンス担当者が見るべきポイント
今回の更新は、単なるコマンド変更ではなく、監査上の説明にも関わります。非推奨モジュールを使い続けている場合、「なぜ使っているのか」「いつまでに移行するのか」「代替手段は検証済みか」を説明できる状態にしておく必要があります。
特に確認すべき証跡は次のとおりです。
| 証跡 | 確認内容 |
|---|---|
| 変更管理記録 | AzureAD PowerShellからGraph PowerShellへの移行が変更管理プロセスに載っているか |
| 権限レビュー | Graphの同意スコープが業務目的に対して過剰でないか |
| 実行ログ | トークン失効やユーザー無効化などの重要操作が記録されているか |
| 例外管理 | 移行できないスクリプトに期限付きの例外承認があるか |
| 手順書 | 公式ドキュメント更新後の表記に追随しているか |
監査で問題になりやすいのは、「古いコマンドを使った」こと自体よりも、非推奨であることを把握していながら、リスク評価や移行計画が記録されていない状態です。
Azure AD Graph APIの廃止と混同しない
AzureAD PowerShellの移行とAzure AD Graph APIの廃止は関連していますが、同じ話ではありません。
Azure AD Graph APIについては、Microsoftが2025年7月1日に完全廃止され、Azure AD Graph APIリクエストは機能しなくなると案内しています。アプリケーションやサービスプリンシパルが https://graph.windows.net/ に依存している場合は、PowerShellスクリプトとは別にMicrosoft Graph APIへの移行が必要です。(TECHCOMMUNITY.MICROSOFT.COM)
したがって、確認は2系統で進めるのが安全です。
| 対象 | 主な確認方法 |
|---|---|
| AzureAD PowerShell / MSOnline | スクリプト検索、サインインログ、Microsoft Entra Recommendations |
| Azure AD Graph API | アプリ登録、サービスプリンシパル、ネットワークログ、Graph API移行レポート |
PowerShell移行だけを完了しても、アプリケーション側にAzure AD Graph API依存が残っていれば、別の障害要因になります。逆に、アプリ側のGraph移行が完了していても、運用スクリプトがAzureAD PowerShellに依存していれば、管理作業が止まる可能性があります。
今回の更新後に取るべき次の行動
今回のMicrosoft Entra公式ドキュメント更新で最初にやるべきことは、公式ページの変更内容を読むことではなく、自社環境で古い参照がどこに残っているかを洗い出すことです。
まず、Security Defaultsや緊急アクセス取り消しの手順に Revoke-AzureADUserAllRefreshToken が残っていないか確認してください。次に、Application ProxyとPingAccessの構成手順で New-AzureADPolicy や Add-AzureADServicePrincipalPolicy を前提にしていないかを確認します。そのうえで、Microsoft Entra Recommendationsとサインインログを使い、実際にAzureAD PowerShellが使われている箇所を特定します。
最後に、移行は「cmdlet名の置き換え」ではなく、「権限設計」「実行証跡」「アプリ側セッション管理」「ベンダー確認」まで含めて進めることが重要です。今回の更新は小さな差分ですが、Microsoft Entra運用をGraphベースへ移行できているかを点検するよいタイミングです。
コメント