Microsoft Entra IDのMFA強制適用でPowerShell・Graph SDK自動化は止まる？影響範囲と対策

Microsoft Entra ID（旧 Azure AD）で進む「MFA 強制適用」により、Azure PowerShell/CLI や Microsoft Graph SDK、Exchange Online PowerShell を使った運用・自動化が止まるのでは…と不安な方は多いはずです。この記事では、影響が出る“対象範囲”をアプリケーション ID（AppId）単位で整理し、日常運用のスクリプトを止めないための現実的な移行ポイントをまとめます。

Microsoft の「MFA 強制適用」は“全ログイン一律”ではない

まず前提として、Microsoft が段階的に進めている「mandatory MFA（必須 MFA）」は、すべてのサインインを一律に縛る仕組みではありません。Microsoft が指定した特定の管理ポータルやクライアント（アプリ）に対して、対象操作を行うときに MFA を要求するという設計です。

この“対象が限定される”という点を理解すると、次のような判断がしやすくなります。

自社のスクリプトが、対象アプリ（AppId）でサインインしているのか？
対象アプリでも「読み取り（Read）」だけなのか、「作成・更新・削除（CUD）」をしているのか？
ユーザーアカウントでの自動実行（疑似サービスアカウント）になっていないか？

強制 MFA のフェーズと、影響が出る“アプリ”の全体像

Microsoft Learn で公開されている内容を、運用目線で要点化すると次のとおりです。

フェーズ	対象	いつから	MFA が必要になる操作	運用への典型的な影響
Phase 1	Azure portal / Entra admin center / Intune admin center / Microsoft 365 admin center	2024年10月〜（M365 管理センターは 2025年2月〜）	ポータルでの CRUD（作成/読み取り/更新/削除）	人が管理ポータルに入る運用で MFA が必須化（例外除外が効かなくなるケースがある）
Phase 2	Azure CLI / Azure PowerShell / Azure mobile app / IaC / REST（Control Plane）/ Azure SDK	2025年10月1日〜（段階展開）	Create / Update / Delete（Read は対象外）	ユーザー資格情報で回している自動化が、CUD 操作時に止まる可能性

Phase 2 は「Azure Resource Manager（管理プレーン）」側での強制が主題であり、自動化に影響が出やすいフェーズです。Microsoft は、ユーザーアカウントを“サービスアカウント代わり”に使う運用は避け、ワークロード ID（マネージド ID / サービスプリンシパル等）へ移行することを推奨しています。

対象 AppId（アプリケーション ID）一覧を先に押さえる

影響判定の最短ルートは、サインインに使っている AppId が対象かどうかを見ることです。Microsoft Learn に掲載されている、代表的な対象 AppId は次のとおりです。

用途	アプリ名	AppId	強制開始	ポイント
管理ポータル	Azure portal / Entra admin center / Intune admin center	c44b4083-3bb0-49c1-b47d-974e53cbdf3c	2024年後半〜	人の管理操作が中心（Phase 1）
CLI	Azure CLI	04b07795-8ddb-461a-bbee-02f9e1bf7b46	2025年10月1日〜	CUD 操作で MFA 必須（Phase 2）
PowerShell	Azure PowerShell	1950a258-227b-4e31-a9cf-717495945fc2	2025年10月1日〜	CUD 操作で MFA 必須（Phase 2）
モバイル	Azure mobile app	0c1307d4-29d6-4389-a11c-5cbe7f65d7fa	2025年10月1日〜	管理プレーン操作が対象
IaC	Infrastructure as Code	（Azure CLI / PowerShell を使用）	2025年10月1日〜	背後で CLI/PowerShell を使うと同様に影響
SDK	Azure SDK	N/A	2025年10月1日〜	管理プレーン（ARM）操作が対象

ここで重要なのは、この表に載っていない PowerShell モジュールや API が“自動的に巻き込まれる”わけではないという点です（もちろん、各サービス側の条件付きアクセスや運用ポリシーで MFA を求めることは別問題です）。

結論：Exchange Online PowerShell / Power BI PowerShell は「今回の mandatory MFA」の直撃対象ではない

質問で挙がっている、非対話型（自動実行）で使われがちな PowerShell モジュールのうち、少なくともAzure の mandatory MFA（Phase 1/2）で明示されている対象 AppId 群に、Exchange Online PowerShell のエンドポイントは含まれていません。つまり「Azure の必須 MFA」が始まるからといって、Exchange Online PowerShell が一斉に動かなくなる、という話ではありません。

ただし注意点があります。

自社の条件付きアクセス（Conditional Access）で、Exchange Online や Graph への接続に MFA を要求している場合は、当然そちらの影響を受けます。
そもそも運用の健全性として、ユーザーの ID/パスワードで回す自動化は破綻しやすい（MFA だけでなく、失効・ロック・パスワード更新・サインインリスク等で止まる）ため、早めに“ワークロード ID”へ寄せるのが安全です。

よくある運用パターン別：影響の有無と推奨対応

運用・自動化の例	使っているもの	mandatory MFA の直撃	止まりやすいポイント	推奨の着地点
Azure リソースを PowerShell で作成/更新/削除	Az モジュール（Azure PowerShell）	高い	ユーザーでサインインして CUD 操作を実行	マネージド ID / サービスプリンシパル（証明書）へ移行
Azure を az コマンドで操作（CI/CD、バッチ）	Azure CLI	高い	ユーザーでサインインして CUD 操作を実行	OIDC（Workload Identity Federation）や SP へ移行
Exchange Online の設定取得・変更（定期ジョブ）	Exchange Online PowerShell	低い（今回の対象外）	ユーザー委任での自動実行、対話ログイン前提	アプリ専用（証明書）/ マネージド ID の app-only 接続
Microsoft 365/Entra の管理（ユーザー/グループ/CA 等）	Microsoft Graph SDK / Graph PowerShell	低〜中（使い方次第）	委任（Delegated）で自動実行、ROPC（ユーザー名/パスワード）	アプリ権限（証明書）/ マネージド ID、または対話運用に切り分け
Power BI の取得・更新（レポート運用）	Power BI PowerShell 等	低い（今回の対象外）	ユーザーでのサインイン自動化	可能ならサービスプリンシパル等の非ユーザー認証へ

Azure PowerShell/CLI を“ユーザーで回している”自動化が最も危ない

Phase 2（2025年10月1日〜）では、Azure CLI/Azure PowerShell 等で作成・更新・削除（CUD）を行うときに MFA を要求する動きが明確化されています。読み取り（Read）操作は対象外とされていますが、運用スクリプトは Read だけで完結しないことが多いため、結果として影響を受けがちです。

さらに Azure PowerShell の自動化観点では、Microsoft Learn のガイダンスとしてユーザー ID でのサインインに MFA 要件が入る旨が明記されており、従来の「ユーザー名＋パスワード」系の非対話サインインは継続困難になります。

今すぐ見直したい“危険な実装”

Azure PowerShell：Connect-AzAccount -Credential のようなユーザー資格情報依存
Azure CLI：共有のユーザーで az login してトークンをキャッシュし、バッチがそれを使う
IaC：Terraform/Bicep 実行環境が、背後で上記ユーザーサインインに依存している

推奨される“止まりにくい実装”

mandatory MFA の文脈でも、Microsoft は「ユーザーをサービスアカウントにしない」方向を明確に示しています。自動化は次のいずれかに寄せるのが現実解です。

マネージド ID（Azure 上の実行基盤なら最優先）
サービスプリンシパル（証明書）（秘密情報を極力短命にしやすい）
Workload Identity Federation（OIDC）（CI/CD で“シークレット無し”を狙える）

なお、ワークロード ID（マネージド ID / サービスプリンシパル）は mandatory MFA の影響を受けない、と整理されています。

Exchange Online PowerShell の非対話運用は「app-only」を軸に作り直す

Exchange Online PowerShell は、無人実行向けにアプリ専用（証明書ベース）＝ app-only 認証を公式にサポートしています。これにより、ユーザーの MFA 状態やパスワード変更に引きずられない構成にできます。

実務上は、次のような移行方針にすると破綻しにくいです。

“人が実行する運用”は委任（Delegated）で OK（必要に応じて MFA）
“ジョブ/バッチが実行する運用”は app-only（証明書/マネージド ID）へ統一

例（イメージ）：証明書を使った app-only 接続の形に寄せる

Connect-ExchangeOnline -AppId <アプリID> -CertificateThumbprint <拇印> -Organization <tenant.onmicrosoft.com>

Azure 上での実行基盤を使っている場合、マネージド ID を使った接続も選択肢になります（公式ドキュメントでも触れられています）。

Microsoft Graph SDK / Graph PowerShell と mandatory MFA の関係を“誤解しない”

Graph で委任権限（ユーザーとしてのアクセス）を使うと MFA は必須になる？

結論から言うと、「Graph を委任権限で使う＝ mandatory MFA の対象になる」ではありません。mandatory MFA は、あくまで Microsoft が指定したアプリ（AppId）で Azure 管理プレーン等の操作をする場合に強制されます。

ただし、委任（Delegated）は“ユーザーサインイン”そのものなので、次の条件では MFA が求められます。

自社の Conditional Access で Graph/関連クラウドアプリに MFA を要求している
サインインリスク、デバイス準拠、場所制限などによりステップアップ認証が発生する
対象が管理ポータル（Phase 1）や Azure 管理操作（Phase 2）に該当する

Graph SDK は Azure SDK を経由して認証するが、どこまで影響する？

ここは混同が起きやすいポイントです。Microsoft Learn の Phase 2 対象に「Azure SDK」が含まれていますが、これは主にAzure の管理プレーン（ARM）を SDK 経由で操作する文脈です。

一方で、Microsoft Graph SDK は Microsoft Graph（Entra/365 の API）を叩くための SDKであり、Azure リソース（ARM）を作る・消す操作とは別系統です。Graph SDK を使って Entra のユーザー/グループ等を操作しているだけなら、Phase 2 の「Azure 管理プレーン強制 MFA」の直撃を受ける、という整理にはなりません。

Graph PowerShell の“既定のクライアント AppId”は何か

Microsoft Graph PowerShell（いわゆる Graph SDK/Graph PowerShell）をそのまま使う場合、サインインログ上は「Microsoft Graph Command Line Tools」として見えることが多く、代表的な AppId は 14d82eec-204b-4c2f-b7e8-296a70dab67e です。

この AppId は、先ほどの mandatory MFA 対象（Azure CLI/PowerShell 等）とは別です。つまり「Graph PowerShell を使っているから mandatory MFA の第一波/第二波で即死する」という単純な話ではありません。

ただし Graph/各種 SDK で“ROPC（ユーザー名＋パスワード）”を使っているなら要注意

mandatory MFA の準備として押さえておきたいのが、ROPC（Resource Owner Password Credentials）＝ユーザー名とパスワードでトークンを取る方式は MFA と両立しない、という点です。Microsoft Learn でも、ROPC の非互換や、Azure Identity ライブラリの UsernamePasswordCredential 等で影響が出ることが明記されています。

現場で“気づかないまま混入”しやすいのは次のようなケースです。

CI/CD で AZURE_USERNAME / AZURE_PASSWORD を環境変数に入れて DefaultAzureCredential に拾わせている
古いサンプルを流用して UsernamePasswordCredential で Graph に接続している
「サービスアカウントの ID/パスワード」を共有し、トークン取得だけ自動化している

このタイプは、mandatory MFA に限らず、条件付きアクセス強化やアカウント保護の流れの中でいずれ止まる運用です。Graph に限っても、無人実行はアプリ権限＋証明書（またはマネージド ID）に寄せるのが長期的に安定します。

日常運用・ジョブが止まるかどうかを“確実に”見分ける手順

サインインログで AppId を棚卸しする

机上の判断より確実なのは、Microsoft Entra ID のサインインログで実態を見ることです。mandatory MFA の文脈でも、サインインログに「どのアプリが MFA を要求したか」が出る旨が示されています。

棚卸しのコツは次のとおりです。

自動化に使っているアカウント（ジョブ用ユーザー、RPA 用ユーザー等）でフィルタ
アプリケーション（AppId/アプリ名）で集計
該当 AppId（Azure CLI / Azure PowerShell など）が出ているか確認
失敗ログがある場合、エラーが「claims challenge」「MFA required」系か確認

スクリプト側で“危険ワード”を機械的に検出する

特に PowerShell/CI の資産が多い組織では、次のキーワードをリポジトリ横断で検索するだけでも、危ない箇所が炙り出せます。

カテゴリ	検索キーワード例	疑うべきこと
Azure PowerShell	Connect-AzAccount -Credential / UsernamePassword / AcquireTokenByUsernamePassword	ユーザー資格情報依存、ROPC 混入
Azure CLI	az login / az account set / ~/.azure	共有ユーザーのトークンキャッシュ運用
Azure Identity	AZURE_USERNAME / AZURE_PASSWORD / UsernamePasswordCredential	ROPC 依存（MFA と両立不可）
Graph/Exchange	Connect-MgGraph / Connect-ExchangeOnline	無人実行なのに委任で接続していないか

クライアントのバージョンも地味に重要

mandatory MFA（特に Phase 2）は、claims challenge（追加要求）を正しく処理できるクライアントでないと、MFA 促しが出ずに“エラーだけ返って止まる”ことがあります。Microsoft Learn では互換性の観点から、Azure CLI と Azure PowerShell の推奨バージョンが示されています。

運用上は、まず「実行環境に入っている Azure CLI / Az モジュールのバージョン把握」を最初のチェック項目にしておくと事故が減ります。

「Azure PowerShell を認証に使っていないのに影響する？」への答え

自動化スクリプトが、

Azure CLI（AppId: 04b07795-…）
Azure PowerShell（AppId: 1950a258-…）
Azure 管理プレーン（ARM）を叩く REST / IaC / Azure SDK

に該当しないのであれば、Azure の mandatory MFA（Phase 2）で“直接”止まる可能性は低い、という整理になります。

ただし現場あるあるとして、表向きは「Exchange の設定を取ってるだけ」に見えても、裏で次のような処理が紛れ込んでいることがあります。

Azure Automation から Key Vault を読んでいる（Azure 管理プレーン）
スクリプトの一部が az コマンドを呼び出している
Graph で Entra の設定を変えた後に、Azure リソース側も更新している

よって、“使っていないつもり”でも、棚卸し（ログ＋コード検索）はやっておくのが安全です。

準備が間に合わない場合の現実的な落としどころ

大規模環境だと、ワークロード ID への移行や CI/CD の認証方式変更が 1〜2か月で終わらないこともあります。その場合、Microsoft はPhase 2 の強制適用開始日をテナント単位で延期できる旨を案内しています（最長で 2026年7月1日まで延期できる、とされています）。

ただし、延期は“解決”ではなく“猶予”です。延期するほど、ユーザー資格情報での自動化が将来一気に破綻します。延期期間中に、次の順で片付けていくのが現実的です。

Azure 管理プレーンの CUD を行う自動化（影響大）を最優先でワークロード ID 化
共有ユーザーの廃止（棚卸ししないと永久に残ります）
Exchange/Graph の無人実行を app-only/マネージド ID へ寄せる
最後に、運用者の対話操作（人がやる作業）の導線を整える

まとめ：判断軸は「どの AppId で、何の操作をしているか」

mandatory MFA は、Microsoft が明示した特定アプリ（AppId）を中心に段階導入される。
Phase 2（2025年10月1日〜）は Azure CLI/Azure PowerShell などが対象で、Create/Update/Delete 操作に MFA が必要。
Exchange Online PowerShell や Power BI PowerShell は、少なくとも Azure mandatory MFA の対象 AppId には含まれず、直撃対象ではない。重要なのは“自社 CA ポリシー”と“無人実行の認証方式”。
Graph SDK/Graph PowerShell は、既定 AppId（例：14d82eec-…）が Azure CLI/PowerShell と別である点を理解しつつ、ROPC（ユーザー名/パスワード）依存を排除する。
自動化はユーザーではなくワークロード ID（マネージド ID / サービスプリンシパル）に移行するのが、最も確実な“止めない対策”。

参考（公式ドキュメント）

Microsoft Learn：Plan for mandatory Microsoft Entra multifactor authentication (MFA)
Azure Blog：Azure mandatory multifactor authentication: Phase 2 starting in October 2025
Microsoft Learn：Sign in to Azure PowerShell non-interactively for automation scenarios（MFA 影響の記載）
Microsoft Learn：App-only authentication in Exchange Online PowerShell（無人実行向け）
Microsoft Learn：Verify first-party Microsoft applications in sign-in reports（Graph PowerShell の AppId 含む）

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。