Entra 登録済みからハイブリッド参加へ切り替える完全ガイド｜Azure AD Hybrid Join 手順と dsregcmd 解説

Entra 登録済みデバイスを Entra ハイブリッド参加へ切り替える｜Azure AD Registered から Hybrid Azure AD Joined への実践ガイド

対象：Windows 10/11 を運用中の情シス／IT 管理者。Microsoft Entra ID（旧 Azure AD）で「Entra 登録（Azure AD Registered）」の端末を、後から構成した「Entra ハイブリッド参加（Azure AD Hybrid Joined）」に切り替えたい方。

質問概要

すでに 「Entra 登録（Azure AD Registered）」 になっている Windows デバイスを、あとから構成した 「Entra ハイブリッド参加（Azure AD Hybrid Joined）」 に変更したい。
具体的な手順と、Active Sync でメール同期している端末が自動でハイブリッド参加するのかを知りたい。

解決策まとめ（最短ルート）

手順	内容	補足
1. 既存登録の解除	デバイス側：設定 → アカウント → 職場または学校へのアクセスで対象アカウントを選び [切断]。管理者側：Entra 管理センター → [デバイス] で当該端末を選択し [登録解除]。	これで「Entra 登録」を一旦クリーンにする。
2. ハイブリッド参加の前提確認	端末がオンプレミス AD にドメイン参加済み。 Azure AD Connect で「ハイブリッド Azure AD 参加」を有効化し、SCP（Service Connection Point）が AD に作成済み。 Windows 10 1607 以降（推奨：20H2 以降／Windows 11）。	ドメイン未参加 PC はハイブリッド参加できない。
3. ハイブリッド参加をトリガー	端末を再起動しドメイン資格情報でサインイン → Automatic‑Device‑Join タスク（または `dsregcmd /join`）が自動実行。	急ぐ場合は管理者権限で `dsregcmd /debug /join` を実行。
4. MDM／Intune ポリシー再適用	ハイブリッド参加後、Intune 自動登録（GPO または MDM スコープ）が適用されているか確認。	`dsregcmd /status` の Device State を確認すると安心。
5. よくある質問	Active Sync 端末は自動でハイブリッド参加するか？ → しない。判定に影響するのはドメイン参加と Azure AD Connect の構成であり、メール同期の有無は無関係。	切断時に OneDrive for Business などは再サインインが必要になる点に注意。

用語の整理（誤解しやすいポイント）

状態	主なトリガー	要件	特徴
Entra 登録（Azure AD Registered）	ユーザーが「職場または学校アカウント」を追加	個人所有やワークグループ PC でも可	ユーザー単位の登録（Workplace Join）。デバイス制御や SSO 範囲は限定的。
Entra 参加（Azure AD Joined）	Out-of-Box Experience、Autopilot 等で Azure AD に直接参加	オンプレ AD は不要	クラウドのみでのモダン管理を想定。
Entra ハイブリッド参加（Hybrid Azure AD Joined）	オンプレ AD ドメイン参加済み端末が自動でクラウドにも参加	AD DS、Azure AD Connect、SCP、インターネット接続	オンプレ資産とクラウドのメリットを両取り。条件付きアクセスや SSO が強化。

実行前チェックリスト（失敗の大半はここで防げる）

ドメイン参加：システムの詳細設定 → コンピューター名 → 変更 で既に AD ドメイン参加になっているか。
Azure AD Connect：構成ウィザードで「ハイブリッド Azure AD 参加」を有効化済みか。
※ Windows 10/11 のハイブリッド参加は、AD コンピュータ OU の同期そのものは必須ではないが、SCP の作成と関連サービスの正しい構成が不可欠。
SCP（Service Connection Point）：AD の構成パーティションに作成されているか。
ネットワーク：DC とインターネットの両方に到達可能か（VPN／プロキシの影響を受けやすい）。
時刻同期：Kerberos 認証ずれ防止。NTP による正しい時刻。
Intune 自動登録：GPO「既定の Azure AD 資格情報を使用した自動 MDM 登録」を有効化、または Entra 側の MDM スコープが適切か。
端末名の最終確定：ドメイン参加後のリネームは可能だが、切替フェーズ中は変更を避けるのが無難。
影響把握：OneDrive/Office アプリ、ブラウザプロファイル等は再サインインが必要になる場合がある。

手順詳細：Registered → Hybrid に「安全に」切り替える

ステップ A：既存の Entra 登録（Workplace Join）を外す

対象 PC のローカル管理者権限（またはサポートアカウント）でサインイン。
設定 → アカウント → 職場または学校へのアクセス を開き、組織アカウントを選択して [切断] を実行。
必要に応じて Office アプリや OneDrive を一旦サインアウト。ローカルの作業ファイルは事前に保存。
管理者は Entra 管理センターの デバイス から当該「登録済み（Registered）」オブジェクトを選択し、登録解除。
※ 同一端末に「Registered」と「Hybrid」の重複オブジェクトが残って後のポリシー適用を混乱させないための整備です。

ステップ B：ハイブリッド参加の前提を満たしているかを再点検

オンプレ AD 参加済みかを システムのプロパティ で確認（ドメインが表示）。
Azure AD Connect のハイブリッド参加構成が完了していること。
ウィザードでテナントを選び、Windows 10 以降を対象に有効化していれば OK。
AD の構成パーティションに SCP が作成されていること（SCP はクライアントが自テナントを自動検出する指標）。
プロキシ経由の場合、システム（WinHTTP） と ユーザー（WinINET） の両方のプロキシ設定が要求を妨げていないかを確認。

ステップ C：ハイブリッド参加のトリガーを実行

端末を再起動し、ドメインユーザーでサインイン。
サインイン後、タスクスケジューラ → Microsoft → Windows → Workplace Join にある Automatic‑Device‑Join が自動実行される。
早く結果を得たい場合は、管理者の PowerShell で次を手動実行： dsregcmd /debug /join

ステップ D：MDM（Intune）自動登録の確認

ハイブリッド参加が成功しても、MDM の自動登録設定が不完全だと管理に乗りません。以下を確認します。

GPO：コンピューターの構成 → 管理用テンプレート → Windows コンポーネント → MDM → 「既定の Azure AD 資格情報を使用した自動 MDM 登録」 を有効。
モードは ユーザー資格情報 か デバイス資格情報 を選択。ハイブリッドではデバイス主体の登録が安定する傾向。
Entra 側の MDM スコープ：Intune を既定の MDM とし、対象ユーザー（または全員）に適用。
必要に応じて 共同管理（Co‑Management） や 移行ポリシー の順序を調整。

状態確認：dsregcmd の見方（合格判定の基準）

管理者 PowerShell を開き、次を実行します。

dsregcmd /status

Device State セクションで以下を確認します。

AzureAdJoined = YES
DomainJoined = YES

上記 2 つが同時に YES であれば、ハイブリッド Azure AD 参加が成立しています。ユーザー側の User State には AzureAdPrt = YES（Primary Refresh Token）が出ていれば SSO も良好です。

よくある質問（FAQ）

Active Sync でメール同期している端末は自動でハイブリッド参加しますか？

しません。ハイブリッド参加は 端末がドメイン参加していること と Azure AD Connect によるハイブリッド参加の構成 により判定されます。メール同期（Active Sync）の有無は関係ありません。
Windows クライアントで職場アカウントを追加すると「Entra 登録（Registered）」は起こり得ますが、これは ユーザー主体の Workplace Join であり、ハイブリッド参加とは別物です。

移行時の注意点（現場でつまずきやすい落とし穴）

重複オブジェクト：Registered を残したまま Hybrid にすると、同じ端末に 2 つのデバイスレコードが並ぶことがあります。管理や条件付きアクセスの判定混乱を避けるため、旧 Registered を整理しましょう。
プロキシ／SSL 検査：デバイス登録の通信をプロキシや SSL インスペクションが妨げると失敗します。トラブル時は一時的にオフバイパスで検証。
時刻ずれ：Kerberos の制限で誤差が大きいと参加に失敗。NTP 同期を徹底。
VPN 頼みの端末：サインイン時にドメイン DC とインターネットの両方に到達できるよう、Pre‑logon/Device トンネルの設計を見直す。
端末名の変更：切替直前の改名は避ける。必要ならドメイン参加前か、安定稼働後に実施。
GPO 優先順位：MDM 自動登録 GPO が適用されない OU／フィルターになっていないか確認。

トラブルシューティング（診断の型）

1）ログで裏取りする

イベントビューア → アプリケーションとサービスログ → Microsoft → Windows → User Device Registration（Admin/Operational）でエラーを確認。
PowerShell 例： Get-WinEvent -LogName "Microsoft-Windows-User Device Registration/Admin" -MaxEvents 50 | Select-Object TimeCreated, Id, LevelDisplayName, Message

2）ネットワークの基本を抑える

プロキシを通す場合、WinHTTP と WinINET の両系統で必要な例外があるかを確認。
社外ネットワークでも再現するかを試し、社内要因（TLS 中継・証明書・DPI）を切り分け。

3）よく見るエラーの代表例（傾向と対策）

症状	背景の傾向	対処のヒント
「デバイスが既に存在」系のエラー	過去の Registered/Hybrid オブジェクトが残骸として残っている	古いデバイスオブジェクトをクリーンアップして再試行（`dsregcmd /leave` は Azure AD 参加解除用。Registered は「職場または学校へのアクセス」から切断）。
「ネットワークに到達不可」	プロキシ／SSL 検査／ファイアウォール	一時的にバイパス。証明書チェーンと TLS 1.2+ を確認。
「認証に失敗」	時刻ずれ、ドメイン資格情報キャッシュ不整合	時刻同期、nltest /sc_verify:<ドメイン> で信頼確認、再サインイン。

一括切替の運用テンプレート（スクリプト例）

現場では「Registered の切断」「Hybrid 参加のトリガー」「結果収集」を段階的に回すと安定します。以下は管理者が リモートで合否だけ集計 するイメージです。

# 例：複数端末の Hybrid 参加ステータスを一覧化（PowerShell Remoting 前提）
$computers = @("PC001","PC002","PC003")
$result = foreach($c in $computers){
  try{
    $status = Invoke-Command -ComputerName $c -ScriptBlock { dsregcmd /status } -ErrorAction Stop
    [pscustomobject]@{
      Computer = $c
      AzureAdJoined = ($status -match "AzureAdJoined\s*:\s*YES") -as [bool]
      DomainJoined  = ($status -match "DomainJoined\s*:\s*YES") -as [bool]
      AzureAdPrt    = ($status -match "AzureAdPrt\s*:\s*YES") -as [bool]
    }
  }catch{
    [pscustomobject]@{
      Computer = $c
      AzureAdJoined = $null
      DomainJoined  = $null
      AzureAdPrt    = $null
    }
  }
}
$result | Format-Table -Auto

Registered の「切断」自体はユーザー操作が最も安全です。どうしても遠隔で進める場合は、ヘルプデスクが電話・リモート支援で誘導しつつ、上記のように 結果だけを可視化 すると現実的です。

ガバナンス／セキュリティ的な観点

条件付きアクセス：登録済み（Registered）だと デバイス準拠性 ベースのルール適用が限定的。ハイブリッド参加で 準拠性＋デバイス ID による制御が取りやすくなる。
棚卸し：重複オブジェクトの放置は監査やライセンス見積もりを歪めるため、切替後に定期的なクリーンアップ運用を用意。
キーと復旧：BitLocker キー保管先（オンプレ AD / Entra / Intune）を確認。切替の前後で保管先が変わる場合は周知。

構成のベストプラクティス（現場の学び）

最初に 1 台のパイロット：境界条件（VPN、プロキシ、GPO、OU、SCP）が正しく効いているかを実機で検証。
Registered を計画的にクリーンアップ：Hybrid が確認できたら旧 Registered を削除。既存ユーザーの職場アカウント接続は必要最小限だけ再構成。
MDM 自動登録の二重化を避ける：GPO と MDM スコープの両面で「取りこぼし無し／二重登録無し」を設計。
ログとコマンドを標準装備：dsregcmd /status と User Device Registration ログを見れば、ほぼ原因に辿り着ける体制に。

ケース別：こうすれば早い

ケース	推奨アプローチ	ポイント
新規にハイブリッド参加を構成した直後	Registered を切断 → 再起動＆ドメインサインイン → 自動参加	SCP・AADC の構成が正しければスムーズ。
VPN 常時接続のテレワーカー	再起動時にデバイストンネルで DC に到達可能にする	サインイン前からドメイン疎通できる設計が鍵。
プロキシが厳しい拠点	一時的に検証用の直回線／例外ルールを用意	原因切り分けを最短化。

よく使うコマンド集

# 参加ステータスの確認
dsregcmd /status

# 参加の即時トリガー（詳細ログ出力）

dsregcmd /debug /join

# Azure AD 参加の離脱（※Registered の切断は「職場または学校へのアクセス」から）

dsregcmd /leave

# ドメイン信頼の確認（トラブル時）

nltest /sc_verify:<ドメイン名>

# WinHTTP プロキシ設定の確認

netsh winhttp show proxy

運用の締め：何をもって「完了」とするか

当該端末の dsregcmd /status で AzureAdJoined = YES かつ DomainJoined = YES を確認。
Entra の該当デバイスが ハイブリッド参加 として表示され、準拠性 と ポリシー が期待通りに適用。
旧 Registered オブジェクトの整理が完了し、重複が解消。

まとめ

「一度 Registered を外して、ドメインの自動登録に任せる」のが最もシンプルかつ安全な切替手順です。前提（ドメイン参加、Azure AD Connect、SCP、ネットワーク、時刻、MDM 自動登録）が揃っていれば、Automatic‑Device‑Join タスクか dsregcmd /join によりスムーズにハイブリッド参加へ移行できます。Active Sync のメール同期有無は判定に影響しないため、ドメイン参加と AADC 構成 に集中して整備しましょう。トラブル時は dsregcmd /status とイベントログを頼りに、ネットワーク・認証・残骸オブジェクトの 3 方向から切り分けるのが近道です。

付録：チェックポイント早見表

カテゴリ	確認内容	OK 条件
ドメイン	端末はオンプレ AD に参加済みか	コンピューター名の横にドメイン名が表示
AAD Connect	ハイブリッド参加ウィザードの完了、SCP 作成	構成ウィザードの状態が正常、SCP が AD に存在
ネットワーク	DC とインターネットへ到達できるか	VPN/プロキシ越しでも参加処理が通る
MDM	自動登録（GPO／MDM スコープ）が有効か	Hybrid 参加後、自動で Intune 管理下に入る
検証	`dsregcmd /status` の値	AzureAdJoined = YES、DomainJoined = YES

参考スニペット：SCP の有無を素早く見る（管理者向け）

# AD モジュールが使える管理端末で実行
Import-Module ActiveDirectory
$cfg = (Get-ADRootDSE).configurationNamingContext
Get-ADObject -LDAPFilter "(objectClass=serviceConnectionPoint)" -SearchBase $cfg -SearchScope Subtree -Properties keywords |
  Where-Object { $_.Keywords -match "azure|device|registration" } |
  Select-Object Name, DistinguishedName, Keywords

最後に：この記事の活かし方

まず 1 台で「Registered の切断 → 再起動 → ドメインサインイン → dsregcmd で合格判定」までを通し、チェックリストを自社の境界条件に合わせて微調整してください。うまくいった手順を、そのままヘルプデスクの手順書に落とし込めば、現場での再現性が高まります。

この記事を書いた人

佐藤健司

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

Entra 登録済みからハイブリッド参加へ切り替える完全ガイド｜Azure AD Hybrid Join 手順と dsregcmd 解説

Entra 登録済みデバイスを Entra ハイブリッド参加へ切り替える｜Azure AD Registered から Hybrid Azure AD Joined への実践ガイド

質問概要

解決策まとめ（最短ルート）

用語の整理（誤解しやすいポイント）

実行前チェックリスト（失敗の大半はここで防げる）

手順詳細：Registered → Hybrid に「安全に」切り替える

ステップ A：既存の Entra 登録（Workplace Join）を外す

ステップ B：ハイブリッド参加の前提を満たしているかを再点検

ステップ C：ハイブリッド参加のトリガーを実行

ステップ D：MDM（Intune）自動登録の確認

状態確認：dsregcmd の見方（合格判定の基準）

よくある質問（FAQ）

Active Sync でメール同期している端末は自動でハイブリッド参加しますか？

移行時の注意点（現場でつまずきやすい落とし穴）

トラブルシューティング（診断の型）

1）ログで裏取りする

2）ネットワークの基本を抑える

3）よく見るエラーの代表例（傾向と対策）

一括切替の運用テンプレート（スクリプト例）

ガバナンス／セキュリティ的な観点

構成のベストプラクティス（現場の学び）

ケース別：こうすれば早い

よく使うコマンド集

運用の締め：何をもって「完了」とするか

まとめ

付録：チェックポイント早見表

参考スニペット：SCP の有無を素早く見る（管理者向け）

最後に：この記事の活かし方

この記事を書いた人

コメント

コメントするコメントをキャンセル

Entra 登録済みからハイブリッド参加へ切り替える完全ガイド｜Azure AD Hybrid Join 手順と dsregcmd 解説

Entra 登録済みデバイスを Entra ハイブリッド参加へ切り替える｜Azure AD Registered から Hybrid Azure AD Joined への実践ガイド

質問概要

解決策まとめ（最短ルート）

用語の整理（誤解しやすいポイント）

実行前チェックリスト（失敗の大半はここで防げる）

手順詳細：Registered → Hybrid に「安全に」切り替える

ステップ A：既存の Entra 登録（Workplace Join）を外す

ステップ B：ハイブリッド参加の前提を満たしているかを再点検

ステップ C：ハイブリッド参加のトリガーを実行

ステップ D：MDM（Intune）自動登録の確認

状態確認：dsregcmd の見方（合格判定の基準）

よくある質問（FAQ）

Active Sync でメール同期している端末は自動でハイブリッド参加しますか？

移行時の注意点（現場でつまずきやすい落とし穴）

トラブルシューティング（診断の型）

1）ログで裏取りする

2）ネットワークの基本を抑える

3）よく見るエラーの代表例（傾向と対策）

一括切替の運用テンプレート（スクリプト例）

ガバナンス／セキュリティ的な観点

構成のベストプラクティス（現場の学び）

ケース別：こうすれば早い

よく使うコマンド集

運用の締め：何をもって「完了」とするか

まとめ

付録：チェックポイント早見表

参考スニペット：SCP の有無を素早く見る（管理者向け）

最後に：この記事の活かし方

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

コメントするコメントをキャンセル