記事公開日
【Microsoft Entra】Azure必須MFAで止まる自動化とサービスアカウント移行
この記事のポイント
Azureの必須MFAは、2025年10月1日からPhase 2（Azure CLI・PowerShell・IaC・REST API）の強制が始まっており、延期できる最終期限（2026年7月1日）も過ぎました。もう先延ばしはできません。ユーザーIDで動かしているスクリプトやIaCは、リソースの作成・更新・削除を行おうとした時点で認証エラーになり、無人実行のまま止まります。本記事では、止まった／これから止まる「ユーザー型サービスアカウント」を棚卸しし、ワークロードIDへ移行する設計を整理します。
- 対象はユーザーID、ワークロードIDは対象外：
必須MFAはユーザーアカウントに適用され、サービスプリンシパルやマネージドIDは影響を受けません。ユーザーIDで動く自動化だけが壊れます。 - Phase 2は management.azure.com宛の書き込み操作が対象：
Create/Update/Delete操作にMFAが必要。読み取りは対象外。ROPC（パスワード直渡し）は非互換で失敗します。 - 緊急アクセスアカウントも対象 ― passkeyや証明書で満たす：
break-glassも例外ではありません。FIDO2パスキーや証明書ベース認証でMFA要件を満たす構成にします。
こんにちは！DXソリューション営業本部の大和矢です。
「夜間バッチが、ある朝から急に認証エラーで止まった」
―― その原因、Azureの必須MFAかもしれません。
Microsoftは、Azureへのアクセスに多要素認証（MFA）を必須化する取り組みを段階的に進めています。
そしてPhase 2（Azure CLI・PowerShell・IaC・REST API）の強制は、2025年10月1日から始まっています。
強制を延期できる最終期限（2026年7月1日）も過ぎ、今はすべてのテナントで有効になっています。
ここで地雷になるのが、ユーザーIDで動かしている自動化です。
本記事では、止まった／これから止まる対象を特定し、ワークロードIDへ移行する設計を整理します（2026年7月時点の情報です）。
本記事は、Microsoft Entra ID Governanceシリーズの一環です。
同じ「昨日まで動いていた連携が、朝から急に止まる」という観点では、クライアントシークレットの失効を扱った次の記事もあわせてどうぞ。
何が・いつから・何に強制されるのか
まず、必須MFAの対象と時期を正確に押さえます。
強制は2段階（Phase 1／Phase 2）で進んでいます（Azureと管理ポータルの必須MFA）。
| フェーズ | 開始 | 対象 |
|---|---|---|
| Phase 1 | 2024年10月〜（M365管理センターは2025年2月〜） | Azureポータル、Microsoft Entra管理センター、Intune管理センター、Microsoft 365管理センター |
| Phase 2 | 2025年10月1日〜 | Azure CLI、Azure PowerShell、Azureモバイルアプリ、IaCツール、REST APIエンドポイント（Create/Update/Delete操作） |
Phase 2で押さえるべき要点は3つです。
- 対象は「書き込み操作」だけ：
Azure Resource Manager宛（https://management.azure.com）のCreate/Update/Delete操作にMFAが必要です。読み取り（Read）操作は対象外です。 - Microsoft Graph APIは一般に対象外：
あくまで management.azure.com 宛のリクエストが対象で、Graph APIは対象になりません。 - ROPCはMFAと非互換：
OAuth 2.0のROPC（Resource Owner Password Credentials＝リソース所有者パスワード認証。ユーザー名とパスワードを直接渡すフロー）は、有効化後は例外を投げて失敗します（ROPCからの移行方法）。
壊れるのは「ユーザーIDで動く自動化」だけ
ここが最も重要な切り分けです。
必須MFAが適用されるのはユーザーアカウントであり、ワークロードID（サービスプリンシパル／マネージドID）は影響を受けません（公式ドキュメントに明記）。
つまり、地雷を踏むのは「本来ユーザー向けのアカウントを、サービスアカウント代わりに使って自動化している」ケースです。
たとえば、ユーザー名とパスワードで az login しているスクリプトや、AZURE_USERNAME／AZURE_PASSWORD環境変数を使うIaCなどが、これに該当します。
壊れ方は、認証の方式によって2通りに分かれます。
1つ目はROPC（パスワード直渡し。az login -u ... -p ... やAZURE_USERNAME／AZURE_PASSWORD）で、そもそもMFAと非互換なため、サインインの時点で例外を投げて止まります。
2つ目は、それ以外の方式でセッションやトークンが確立できているケースです。この場合サインインは通りますが、リソースの作成・更新・削除を行おうとした時点でMFAチャレンジが返り、無人実行では応答できずに失敗します（読み取りは通ります）。
いずれにせよ、人が対話的に実行すればMFAを求められて突破できるため、問題になるのは無人で回している自動化です。
緊急アクセス（break-glass）も例外ではない：
緊急アクセスアカウント（break-glassアカウント）とは、MFA基盤や条件付きアクセス、フェデレーションなどの通常の認証手段が障害で使えなくなったときに、テナントへサインインしてアクセスを回復するための、高い権限を持つ予備の管理者アカウントです。
普段は使わず厳重に保管しておく「最後の切り札」で、締め出し（ロックアウト）を防ぐために用意します。
意外な落とし穴ですが、この緊急アクセスアカウントも、enforcement後はMFAでのサインインが必要です。
そのため、break-glassはFIDO2パスキーまたは証明書ベース認証で構成しておきます。どちらもMFA要件を満たします。
「条件付きアクセスから除外しているから大丈夫」ではなく、システム強制側でMFAが要る点に注意してください。
だからこそ、無人実行は「ユーザーでサインインしない」＝ワークロードIDへ寄せるのが、唯一の筋のいい解になります（→ 後述の移行設計）。
影響範囲を特定する ― サービスアカウントの棚卸し
対策の第一歩は、「ユーザーIDで動いている自動化」を洗い出すことです。
公式は、MFAの準備状況を確認する手順（How to verify users are set up for mandatory MFA）を案内しており、これを使ってサービスアカウント代わりに使われているユーザーアカウントを特定できます（必須MFAの準備確認）。
条件付きアクセスを使うには Microsoft Entra ID P1 または P2 ライセンスが必要で、無料版のテナントでは利用できません（その場合はセキュリティの既定値を使います）。
ただし、条件付きアクセスが使えなくても影響を事前に把握する手段はあります。Azure Policy なら、ライセンスに関係なくMFAを自己適用できるからです。
まず監査（Audit効果）モードでMFA強制の影響を可視化し、準備が整ったら強制（Deny効果）モードに切り替える、という段階導入が可能です（チュートリアル: Azure Policy による MFA の適用）。
Microsoftも強制時に同じAzure Policyを展開するため、先回りで自テナントに適用しておけば、強制日に追加の影響が出ません。
サインインログで、ROPCフロー（パスワード直渡し）を使っているアプリや、ユーザーIDによる非対話的サインインを探すのも有効です。
「誰のIDで、どのスクリプトが、何の操作をしているか」を棚卸しし、移行対象のリストを作ります。
移行設計 ― ワークロードIDへ寄せる
洗い出したユーザー型サービスアカウントは、ワークロードID（マネージドID／サービスプリンシパル）へ移行します。
そもそも自動化にユーザーIDを使うことは推奨されていません（セキュアなサービスアカウント）。
- Azure上で動く処理：
マネージドIDへ。資格情報の管理が不要で、最も安全です。 - Azure外で動く処理：
サービスプリンシパルへ。可能ならクライアントシークレットではなくフェデレーション資格情報や証明書を使います。
移行後のガバナンスも一緒に設計する：
ユーザー型サービスアカウントに条件付きアクセスを当てていた場合、移行後はワークロードID向け条件付きアクセスで同等の制御をかけられます（要 Workload Identities Premium ライセンス）。
ユーザーライセンスを回収し、ワークロードIDライセンスへ振り替える、という設計が現実的です。
「MFAで止まったから慌てて移行」ではなく、移行を機にIDの整理とガバナンス強化までやり切るのがおすすめです。
よくある質問（FAQ）
Q. サービスプリンシパルやマネージドIDもMFAが必要になりますか？
いいえ。必須MFAはユーザーアカウントに適用され、ワークロードID（サービスプリンシパル・マネージドID）はPhase 1・Phase 2のいずれの影響も受けません。
影響を受けるのは、ユーザーアカウントをサービスアカウント代わりに使って自動化しているケースです。これらはワークロードIDへ移行することが推奨されています。
Q. Phase 2では具体的に何にMFAが必要ですか？
2025年10月1日から、Azure CLI・Azure PowerShell・Azureモバイルアプリ・IaCツール・REST APIエンドポイントでのCreate/Update/Delete操作にMFAが必要です。
読み取り（Read）操作は対象外です。対象は https://management.azure.com 宛のリクエストで、Microsoft Graph APIは一般に対象外です。
Q. 条件付きアクセスのライセンスがなくても影響を確認できますか？
はい。Azure Policyを使えば、条件付きアクセスがなくてもMFA強制の影響を把握できます。
まず監査（Audit）モードで影響を可視化し、準備が整ったら強制（Enforcement）モードに切り替えられます。
Microsoftも強制時に同じポリシーを展開するため、先回りで自テナントに適用しておくと、強制日に追加の影響が出ません。
Q. 緊急アクセス（break-glass）アカウントはどうなりますか？
緊急アクセスアカウントも、強制後はMFAでのサインインが必要です。
条件付きアクセスから除外していても、システム強制側でMFAが要ります。
そのため、FIDO2パスキーまたは証明書ベース認証で構成し、MFA要件を満たすようにしておくことが推奨されています。
まとめ：ユーザーIDで自動化しない、を原則にする
今回は、すでに強制が始まっているAzure必須MFA Phase 2に対して、止まった／これから止まる自動化の棚卸しと移行を整理しました。
学びは3つです。
- 対象はユーザーID、ワークロードIDは対象外：
Phase 2（2025年10月1日〜）はmanagement.azure.com宛の書き込み操作が対象。壊れるのはユーザーIDで動く自動化だけです。 - まず棚卸し ― Azure Policyで影響可視化：
ユーザー型サービスアカウントを特定し、Azure Policyの監査モードで影響を事前把握します。 - ワークロードIDへ移行し、ガバナンスも整える：
マネージドID／サービスプリンシパルへ寄せ、必要ならワークロードID向け条件付きアクセスで制御します。
「ユーザーIDで自動化しない」は、MFA対応のためだけでなく、ID統制の基本原則です。
今回の必須MFAは、その原則に組織を合わせ直す良い機会でもあります。
まずは az login をユーザー名／パスワードで行っている処理がないか、棚卸ししてみてはいかがでしょうか。
どの自動化を、どのワークロードIDに、どの順で移すかという移行計画が、次の難所になります。
ここまでお読みいただき、ありがとうございました。
なお、本記事は Microsoft Entra ID のガバナンス・ID統制に関する内容でした。関連するテーマは、QESブログの「Microsoft Entra ID Governance」カテゴリでもまとめて発信していますので、あわせてご覧いただけますと幸いです。
QUICK E-Solutionsでは、AIを活用した業務効率化や、Microsoft Entra IDをはじめとした高度なセキュリティシステムの導入・設計をお手伝いしております。
それ以外でも様々なアプリケーションの開発・導入を行っております。提供するサービス・ソリューションにつきましては こちら に掲載しております。
システム開発・構築でお困りの問題や弊社が提供するサービス・ソリューションにご興味を抱かれましたら、ぜひ一度 お問い合わせ ください。
※このブログで参照されている、Microsoft、Microsoft Entra ID、Microsoft Azure、Azure CLI、Azure PowerShell、Azure Resource Manager、Microsoft Intune、Microsoft 365、Microsoft Graphは、米国Microsoft Corporationの米国およびその他の国における商標または登録商標です。
