Microsoft Entra IDへのスムーズな移行の実行

By Mirko Peters · 2026-08-22

なぜ今、Microsoft Entra IDへ移行するのか？組織では、アクセス管理を簡素化するために、分散したIDシステムから離れる動きが強まっています。Microsoft Entra IDへの移行は…

Automatically translated with AI from the original post. Read the English original

なぜ今、Microsoft Entra IDへ移行するのか

組織では、アクセス管理を簡素化するために、分散したIDシステムから離れる動きが強まっています。Microsoft Entra ID（旧 Azure Active Directory）への移行により、クラウドとオンプレミスの両方のリソースに対する認証を一元化する、汎用的なIDプラットフォームを利用できます。ヘッダーベース認証に依存するSiteMinderのような従来型のプロバイダーとは異なり、Entra IDはSAML、OpenID Connect、OAuthといった最新のプロトコルをサポートし、ハイブリッドな働き方の環境を保護します。

IDスタックを統合すると、古いオンプレミスシステムではネイティブに対応しにくい、フィッシング耐性のあるセキュリティ対策を導入できます。移行により、チームは自動化されたガバナンス機能も活用できます。これには、Privileged Identity Managementによる時間ベースのアクセスや、効率化されたライフサイクル管理が含まれます。さらに、このプラットフォームはFIDO2キーやMicrosoft Authenticatorアプリといったパスワードレスのサインイン方法にも対応しており、資格情報の盗難リスクを大幅に減らします。

M365 FM Podcastでは、こうした移行を定期的に取り上げており、アーキテクトがActive Directory フェデレーション サービスから、クラウドネイティブな認証への移行を進める際の助けになっています。2025年のマルチクラウド調査によると、現在では企業の75%が2つ以上のIDプロバイダーを管理しています。単一のコントロールプレーンに統一することで、技術的負債が減り、全体的なゼロトラスト態勢も改善します。

同期の前に依存関係を洗い出す

同期を開始する前に、現在のオンプレミスの依存関係を徹底的に監査する必要があります。ここには、DNS、グループ ポリシー オブジェクト、KerberosやNTLMに依存している可能性のあるレガシーアプリケーションといった重要なサービスの棚卸しが含まれます。SMTPリレー、RADIUSサーバー、プリンターの認証設定などのインフラコンポーネントも見落とさないでください。これらはリフトアンドシフトの際に動作しなくなることがよくあります。M365 FM Podcastのような情報源では最新プロトコルへの移行が強調されていますが、多くの組織では依然として、特定の接続経路を必要とするレガシーワークロードを運用しています。

目標とする状態を定義する

クラウド専用モデルとハイブリッドIDの構成のどちらを目指すのかを、早い段階で決めてください。ハイブリッドIDモデルでは、必要なオンプレミスのコンポーネントを残しつつ、ユーザーとグループのオブジェクトを同期できます。一方、クラウド専用モデルでは AD FS が完全になくなるため、管理の手間を減らせます。ハイブリッドコンポーネントを維持する場合は、Microsoft Defender for Identityを使用して、残りのオンプレミスインフラの脆弱性を先回りして特定し、侵害されたIDを管理してください。

• LDAPやKerberosを含むレガシー認証プロトコルを監査します。これらには、クラウドに直接対応する機能がないことが多いためです。
• 古くなったアカウントを整理し、UPNの不一致を解消して、同期エラーを防ぎます。
• 可能な場合はネストされたグループをフラット化してください。これらはクラウドで複雑で意図しないアクセス許可の構造を生む可能性があります。
• サードパーティのMDMソリューションや、エアギャップ型のネットワーク要件によって、AD FSを予定より長く維持する必要があるかどうかを確認してください。

クラウドネイティブな ID モデルへの移行は、既存環境の包括的な監査から始まります。現状を把握したら、Microsoft Entra Connect を使用してハイブリッド ID の基盤を実装し、ディレクトリを同期します。次の重要なステップは、AD FS からの移行です。Password Hash Sync または Pass-Through Authentication といったクラウドネイティブな認証方式に切り替えるとともに、AD FS Application Migration Wizard を活用して、証明書利用者信頼アプリを Microsoft Entra ID 向けに再構成します。この全工程を通じて、セキュリティツールでインフラストラクチャを保護してください。最後に、アプリケーションとユーザーの移行がすべて完了したら、従来のオンプレミスのドメインコントローラーを計画的に廃止できます。

スタged ロールアウトでクラウド認証をテストする

Active Directory Federation Services(AD FS)からクラウドネイティブな認証へ移行するには、信頼性の高い検証戦略が欠かせません。Staged Rollout はこの移行の橋渡しとなる機能で、既存のフェデレーション基盤をフォールバック用に残したまま、ユーザーグループを段階的にクラウドベースの検証へ移行できます。影響を小規模なユーザー集団に限定できるため、リスクを抑えられます。

パイロットフェーズの構成

作業を始める前に、同期方式を確認してください。アクティブな AD FS 環境と並行して、Password Hash Synchronization または Pass-through Authentication を構成しておく必要があります。クラウド ID の同期が完了したら、Microsoft Entra 管理センターに移動し、特定のセキュリティグループに対してこの機能を有効にします。パフォーマンスの低下やユーザー エクスペリエンスのタイムアウトを防ぐため、最初のパイロットグループは 200 ユーザー以内に制限してください。

• ロールアウト全体を通じて、フェデレーション ID プロバイダーをオンラインのまま維持し、確実にフォールバックできるようにしてください。
• 認証のパターンと移行状況は、Entra 管理センターで監視してください。
• スタged ロールアウトは一時的な仕組みであり、長期的な構成ではないことを忘れないでください。テストが終わったら、ドメインの完全な切り替えに備えてください。

フェデレーション ドメインをマネージドに変換する

フェデレーション モデルからマネージド認証への移行は大きな節目であり、環境を単純化するとともに、AD FS のようなレガシーなインフラへの依存を取り除けます。この切り替えを始める前に、同期戦略が堅牢であることを確認してください。M365 FM Podcast でも繰り返し強調されていますが、切り替え前に同期状態を検証しなかった組織は、広範囲にわたるユーザーのロックアウトに陥るリスクがあります。

Entra ID でフェデレーション ドメインをマネージド ドメインに変換するための必須手順は何でしょうか？ フェデレーション ドメインをマネージドに変換するには、まず Password Hash Synchronization(PHS)または Pass-through Authentication(PTA)が完全に構成され、検証されていることを確認する必要があります。

1. Connect-MgGraph -Scopes "Domain.ReadWrite.All" コマンドを使用して、Microsoft Graph PowerShell SDK に接続します。
2. ドメイン設定の変更には必須の権限となるため、ドメイン名管理者またはグローバル管理者のロールが割り当てられていることを確認してください。
3. Update-MgDomain -DomainId <your-domain.com> -AuthenticationType "Managed" を実行して、変換プロセスを開始します。
4. Microsoft Entra 管理センターでドメインの状態が更新されたことを確認し、パイロットユーザーグループで直ちにテストを実施して、クラウドに対する認証が正常に行われることを確認してください。

ドメインの変換処理が反映されるまで、最大60分かかる場合があることにご注意ください。この期間中、既存のブラウザーセッションは通常そのまま有効ですが、新しい認証要求からは管理されたフローが使用されるようになります。問題が発生した場合は、細かな検証のために段階的ロールアウト(Staged Rollout)を引き続き活用することをお勧めします。

移行で起こりがちな落とし穴を想定する

Entra ID への移行において、クラウド アーキテクトはどのような課題を想定しておくべきでしょうか。最も大きなリスクは、移行を単なるプラットフォームの入れ替えとして扱い、エンドポイント管理全体を再設計する必要があることを見落としたときに生じます。議論はユーザー アカウントに集中しがちですが、環境は RADIUS によるネットワーク アクセス、メッセージング用の SMTP リレー、レガシーなプリンターの認証など、深く根付いたプロトコルに依存しています。これらは計画なしにクラウドへ移すことはできません。

同期を開始する前に依存関係の包括的な棚卸しを行わないことは、移行途中のダウンタイムを招く主な原因です。ワークフローを洗い出す際には、恒久的なハイブリッド構成とクラウド専用モデルのどちらを採用するかを決める必要があります。終わりの見えない、管理されていない中間状態にとどまると、セキュリティ上の欠陥や運用上の摩擦が生じやすくなります。多くの場合、移行の早い段階で最終的な目標状態を明確にしておくことで、二重環境の管理の複雑さを抑えられることがわかっています。

技術的負債は、古いアカウント、深くネストされたグループ構造、新しい環境へそのまま持ち越されて汚染する UPN の不一致といった形で現れることがよくあります。古いデータをそのまま移行するのではなく、Active Directory の属性をクリーンアップして、Microsoft Entra ID への円滑な移行を確保してください。こうした課題に取り組む場合は、Microsoft Entra アプリケーション移行のドキュメントが、アプリの分類について体系的な手順を示しています。複雑なレガシー依存関係に取りかかる前に、単純な統合を優先的に処理するのに役立ちます。

AD FS アプリケーション移行ウィザードとツールを活用する

レガシーアプリケーションを Active Directory フェデレーション サービス (AD FS) から移す作業は、ID の近代化プロジェクトの中でも最も手強い部分に感じられることが多いでしょう。これを簡素化するために、AD FS アプリケーション移行ウィザードは、証明書利用者 (relying party) アプリケーションの検出、評価、構成を行う専用ツールとして機能します。自動化を利用することで、アーキテクトは既存の構成をスキャンし、移行の対象となるかどうかのレポートを取得できます。すぐに移行できるサービスと、技術的な障壁があるサービスを明確に把握できます。

この移行に取り組む際は、体系的な移行ライフサイクルに従ってください。まず検出とスコープ設定を使い、開発中のものも含めてすべてのアプリケーションを一覧化します。次に分類フェーズでは、複数の ID プロバイダーに対応している、ギャラリーにある単純な SaaS アプリケーションから着手し、その後で複雑なレガシーのカスタムアプリに移ります。完全なモダナイズが難しい Web アプリケーションについては、Microsoft Entra アプリケーション プロキシと Secure Hybrid Access (SHA) を使うことで、従来の VPN を使わずに安全なリモートアクセスを提供し、そのギャップを埋めることができます。

クラウド認証方式を選択する: PHS、PTA、CBA

適切な認証方式を選ぶことで、セキュリティ態勢とユーザー エクスペリエンスが決まります。Microsoft は、多くの組織にとって パスワード ハッシュ同期 (PHS) を第一の選択肢として推奨しています。パスワードのハッシュをクラウドに同期すると、漏えいした資格情報の検出や ID Protection といった重要なセキュリティ機能が使えるようになります。同時に、FIDO2 キーのようなモダンなパスワードレス サインイン方式への移行も可能になります。

規制上の要件でパスワードハッシュをクラウドに保存できない環境では、パススルー認証（PTA）が有効な代替手段になります。この方式では、ユーザー資格情報をオンプレミスの Active Directory に直接照合します。PTA を展開する場合は、軽量の認証エージェントを複数インストールして高可用性を確保してください。これらのサーバーは、クラウドへのサインインを処理する主要な関門になるためです。

EO 14028 で示されているような、厳格なフィッシング耐性の要件を満たす必要がある場合は、Microsoft Entra 証明書ベース認証（CBA）への移行を検討してください。この方式では、ユーザーがスマート カードや証明書を使って認証できます。オンプレミスのフェデレーション サーバーに依存しない、信頼性の高い本人確認を実現できます。

移行期間中もユーザー体験をスムーズに保つため、選択した方式と合わせてシームレス SSO を実装してください。組織で macOS や iOS デバイスを利用している場合は、Apple デバイス向けの Microsoft Enterprise SSO プラグインを展開することをお勧めします。これにより、認証プロンプトが繰り返し表示されることなく、円滑で持続的なサインインが可能になります。私たちの経験では、これらの方式と堅牢な条件付きアクセス ポリシーを組み合わせることが、企業のセキュリティとエンド ユーザーの生産性の最良のバランスを実現します。

AD FS の廃止を計画する

レガシーのフェデレーション基盤の廃止は、最新の ID 体制を実現するための最後のステップです。恒久的な措置を取る前に、AD FS ファームに依存している残存トラフィックがないことを確認してください。すべての認証要求が Microsoft Entra ID に正常に移行したことを確認するには、Connect Health の使用状況分析レポートを使用します。

クラウドで管理された認証が安定しており、フェデレーション サーバーにアクセスしているユーザーがいないことを確認できたら、環境全体の包括的なバックアップを取得してください。最終的なクリーンアップ中に接続を復元する必要が生じた場合に備えた、欠かせない安全対策です。

1. ローカル ロード バランサーからすべてのエントリを削除し、受信トラフィックを停止します。
2. フェデレーション サービスに関連付けられた DNS レコードを更新または削除し、要求をリダイレクトします。
3. Web Application Proxy と AD FS のサーバー ロールを順番にアンインストールします。
4. ADSI エディターで証明書コンテナーをクリアし、残存する構成データを削除して、環境を完全にクリーンアップします。

これらのレガシー コンポーネントを削除すると、攻撃対象領域と管理の負担が減ります。これらのレイヤーを順に取り除くことで、クラウドネイティブな ID モデルへの移行が確実なものになります。

期限前に認証ポリシーを移行する

Microsoft は、より細かく一元的な管理を実現するため、従来の ID 制御を統合された 認証方法ポリシーに集約しています。この変更により、個別に管理されていた従来の MFA および SSPR の画面が、Microsoft Entra 管理センターの単一で合理化されたポリシー エンジンに置き換えられます。2025 年 9 月 30 日の期限までに、すべての組織がこの移行を完了する必要があります。期限後は、従来の管理ポータルで認証設定の構成やトラブルシューティングができなくなります。

作業を始めるには、Entra ポータルで [保護] > [認証方法] > [ポリシー] に移動します。組み込みの移行ウィザードを使用して現在の環境を監査し、既存の従来の設定と新しいフレームワークの間で競合する項目を特定してください。移行の状態を 'Migration in progress' に設定することは、推奨されるベスト プラクティスです。これにより、既存のユーザーに対して従来の設定を有効に保ったまま、新しいポリシーをテストできます。

• FIDO2 セキュリティ キー、一時アクセス パス（TAP）、証明書ベース認証などの高度な認証方法は、新しいポリシーでのみ管理されます。
• 移行プロセスは元に戻せるため、テスト期間中にレガシーな動作を復元する必要がある場合は、状態を切り替えることができます。
• 自動化ツールはテナント全体の設定を移行しますが、グループ固有の構成が正しく複製されているかを確認するため、手動によるレビューが必要です。
• この統一されたポリシーに移行することで、フィッシング耐性のある MFA などの最新のセキュリティ基準とより適切に整合させられます。

ほかの ID 移行と同様に、ユーザーの登録への影響に注意してください。現在ユーザーが利用している認証方法を無効にすると、社内リソースにアクセスする前に再登録が必要になる場合があります。統一された、より安全な認証体制への移行を進める間も業務が中断されないよう、Microsoft Entra 管理センターでサインインログを監視してください。

条件付きアクセスと監視による保護

クラウドネイティブなセキュリティへの移行では、ユーザーがロックアウトされないよう慎重な検証が必要です。新しいセキュリティ基準を適用する前に、必ず 条件付きアクセスのポリシーをレポート専用モードでテストしてください。Microsoft Entra 管理センターの「What If」ツールを使うと、場所、デバイスの状態、アプリケーションの機密性に基づいて、特定のポリシーがユーザーのアクセスにどう影響するかをシミュレーションできます。この事前の確認により、セキュリティルールが効果的かつ業務を妨げないものになります。

テストに加えて、ロックアウトのしきい値も更新する必要があります。移行中は、Microsoft Entra ID でスマート ロックアウトを構成し、ブルートフォース攻撃への即時の軽減策として、オンプレミスの Active Directory の設定よりも短い間隔を設定してください。移行期間中の可視性を保つため、Hybrid Auth ブックを利用して認証の流れを監視し、異常を特定してください。移行後 1 〜 2 週間はこれらのサインインログを注意深く追跡し、ユーザーが正常に認証できていることを確認するとともに、問題が発生した場合にすばやくロールバックできるようにしてください。

長期的な保護には、現在一般提供されている Microsoft Entra Backup and Recovery を活用してください。この機能は、ユーザー、グループ、新たに構成した条件付きアクセスポリシーを含む重要なディレクトリオブジェクトを自動的にバックアップします。これらの組み込みツールを使用すると、誤操作や悪意のある変更が発生した場合に、テナントを既知の正常な状態に復元するのに役立ちます。

Microsoft Entra ID のドキュメントとリソースを使いこなす

Microsoft Entra ID を習得するための最新のドキュメントやリソースはどこで見つけられますか？Microsoft Entra ID を習得するための主な情報源は、公式の Microsoft Learn ポータルです。ここでは、ID の基本概念から高度なガバナンス、条件付きアクセスのポリシーまでを網羅した、体系的な学習パスが提供されています。

日常の管理や技術的な詳細を深く学ぶには、Entra ID のドキュメントが、アプリの統合、ハイブリッド ID、セキュリティ監視に関する包括的なガイドを提供しています。インストラクターによる研修を希望する場合は、Microsoft Virtual Training Days をチェックしてください。認定試験の準備に役立つ、無料のリアルタイム セッションが用意されています。

さらに、急速な製品アップデートに追随するためには、Entra ドキュメント内の「What's New（新機能）」セクションを定期的に確認することが重要です。

PIM と ID ライフサイクル管理によるアクセスのガバナンス

クラウドネイティブな ID モデルへの移行では、常時有効な管理者アクセスから脱却する必要があります。Microsoft Entra ID Privileged Identity Management (PIM) は、期間ベースおよび承認ベースのロール有効化を可能にすることでこの課題に対応します。永続的なアクセス許可を付与するレガシーなシステムとは異なり、PIM はジャスト・イン・タイムのアクセスを強制するため、特権アカウントの攻撃対象領域を大幅に削減できます。

ID のライフサイクルを効果的に管理するには、多くの場合 HR 主導のプロビジョニングから始めます。Workday や SuccessFactors などのソースを統合すると、ユーザーの作成、更新、削除を自動化でき、アクセス権を従業員の実際の状態と常に同期させられます。これにより、手作業の環境で蓄積しがちな孤立アカウントのリスクがなくなります。

アクセスとコンプライアンスの自動化

継続的なリソース管理には、エンタイトルメント管理を使うと、アプリケーションやグループへのアクセス要求、割り当て、有効期限切れを自動化できます。ゼロトラストの姿勢を維持するため、管理者は定期的なアクセスレビューを実施し、アクセス許可が引き続き必要かどうかを確認する必要があります。こうしたレビューにより、機密性の高いグループやロールに、承認されたユーザーだけがアクセスできる状態を確認でき、コンプライアンスの維持に役立ちます。

• 動的グループを、オンプレミスのグループに対する自動化された信頼できるソースとして活用してください。
• クロステナントのグループ同期を活用すると、複数の環境間でグループメンバーシップの一貫性を保てます。
• チームが過剰なディレクトリ権限を持たなくても、セッションの取り消しやユーザーの無効化を行えるようにします。

外部 ID と将来に備えた計画

Microsoft がサービスの提供内容を移行していく中、外部 ID の管理には先を見越した対応が求められます。Azure AD B2C を利用している組織は、Microsoft Entra External ID への手動による移行を準備する必要があります。現時点では両プラットフォーム間にネイティブで完全に自動化された移行経路がないためです。既存のディレクトリからユーザーデータをエクスポートし、新しいテナントにインポートする必要があります。移行を支援するコミュニティサポートの移行ツールキットが GitHub で公開されていますが、初回ログイン時にスムーズに移行できるよう、ジャストインタイム（JIT）のパスワード移行を活用してください。

外部 ID の管理に加えて、コアとなる同期アーキテクチャにも注意を払う必要があります。Microsoft は Microsoft Entra Connect Sync から、クラウドネイティブな Microsoft Entra Cloud Sync への移行を進めており、公式の移行通知は 2026 年 7 月に開始される予定です。この変更により、同期ロジックがクラウドに移るため、オンプレミスの複雑さが軽減されます。

これらの更新の間も、セキュリティが最優先事項です。2026 年 6 月 1 日以降、Microsoft は、新しいオンプレミスの Active Directory ユーザーを、管理者ロールをすでに持つクラウド管理アカウントにリンクする 'ハードマッチ' 操作をブロックします。この安全策は、属性の改ざんを防ぎ、最も特権の高い ID を不正な乗っ取りから守るために設計されています。環境を将来に備えて整える際は、これらのセキュリティ制御が有効になったときにサービスが中断しないよう、既存のクロステナント接続と管理者の割り当てを今のうちに監査してください。

クラウドでシームレスな ID を実現するための道筋

ID の近代化への取り組みは、最初の検出と範囲の特定から、完全に管理されたクラウドの状態に至るまでの多段階のプロセスです。堅固なハイブリッド基盤を構築することで、従来の運用上の煩わしさから離れ、Microsoft Entra ID の機能へと移行できます。移行を成功させるには厳密な検証が欠かせません。特に、Staged Rollout を使うと、本格的な切り替えの前に、選択したユーザーグループで認証方法をテストできます。

移行後は、作業の中心がサインインログと認証方法ポリシーの構成を継続的に監視することに移ります。一貫性が欠かせないため、最終的な廃止の前に、レガシーなフェデレーションによるアクティビティが完全に停止していることを必ず確認してください。こうした変化についていくために、これらの更新に関する日々の知見はM365 FM Podcastでご確認いただけます。

技術的負債への対応を期限直前まで先送りしないでください。パスワードレスサインインや高度なセキュリティ機能を活用するために、今日から依存関係の監査を始めてください。レガシーアプリのリファクタリングやポリシーの統合を進める際も、公式ドキュメントのリソースを活用すれば、クラウドへの移行ロードマップは今まで以上に明確になります。