Windows 10 から Windows 11 Enterprise へアップグレードした端末を Intune に登録した際に「The device is assigned to another tenant（デバイスが別のテナントに割り当てられています）」と表示されるケースは、買い替え・再利用・中古調達・クロステナント移行など実務で頻出します。本記事では発生理由の仕組みから、管理者センター側の削除、端末側のクリーンアップ、Microsoft サポートへの依頼まで、現場でそのまま使える手順・確認ポイント・チェックリストをまとめて体系的に解説します。
問題の全体像とエラーの意味
Intune 登録時のエラー 「The device is assigned to another tenant」 は、対象 PC の識別情報（シリアル番号やハードウェア ハッシュ）が、別の Microsoft Entra ID（旧 Azure AD）テナントの管理資産として記録されているときに表示されます。具体的には次のいずれか、あるいは複数のレコードが残存していることが原因です。
- Autopilot デバイス レコード（ハードウェア ハッシュ/シリアルが紐づく）
- Intune デバイス レコード（MDM 管理オブジェクト）
- Entra ID（旧 Azure AD）デバイス オブジェクト（Azure AD Joined/Registered 状態）
これらが同一または別テナントに存在すると、新しいテナントでの登録（Azure AD 参加や MDM 自動登録、Autopilot プロビジョニング）がブロックされ、エラーが返されます。
想定ユースケースと本記事で扱う対象
- Windows 10 → Windows 11 Enterprise にアップグレードした 社内ノート PC を 新テナントの Intune に登録したい
- 中古/リース返却品/キッティング済み機の再利用で、元の持ち主のテナントに残骸がある可能性が高い
- Autopilot 運用中の企業で、誤ったテナントへインポートしてしまった、あるいは クロステナント移行を行った
以降、管理センター側のクリーンアップ → 端末側クリーンアップ → 再登録の順に、実務で迷いやすいポイントと確認方法を詳説します。
結論：最短で解決するための対処フロー
急ぎの現場対応では、まず以下の意思決定フローに従うと作業が短縮できます。
| 状況 | 確認方法 | 対処 | 再試行 |
|---|---|---|---|
| 自社テナントに当該デバイスのレコードがある | Intune 管理センター > デバイス/Windows 登録/Autopilot | 該当レコードを削除（Autopilot/Intune/Azure AD） | 数分待機後、端末を再起動して登録 |
| 自社には無いがエラーが続く（他テナントに残存） | インポート試行やシリアル照合で推測 | Microsoft サポートへ解除依頼（所有証明を用意） | サポート側削除完了後に再登録 |
| 端末側に旧組織アカウント/登録情報が残る | 設定 > アカウント > 職場または学校へのアクセス / dsregcmd | 切断・dsregcmd /leave・再起動 | 正しいアカウントで登録 |
原因の仕組みを理解する（なぜ別テナント扱いになるのか）
Intune/Autopilot はハードウェア識別子（シリアル番号、TPM 証明、ハードウェア ハッシュ）をキーに、どのテナントで管理されるデバイスかを判断します。PC が一度でも他社や旧テナントに登録されていると、クラウド上の所有権情報が残り続け、別テナントでの新規登録や Autopilot プロファイル適用が拒否されます。
デバイスの「所有権」は、Autopilot レコードとMDM（Intune）/Entra ID のデバイス オブジェクトが連動しながら成立します。片方だけ消しても、もう片方が残っていればブロックは続く点に注意が必要です。
同一テナント内に残るレコードの削除手順
まずは自社テナントに残るレコードを徹底的に洗い出します。以下の順で削除するのが実務的です。
- Autopilot デバイス レコードの削除
Intune 管理センター → デバイス → Windows → Windows 登録 → Windows Autopilot デバイス（またはデバイス）で、シリアル番号/ハードウェア IDで検索し該当レコードを削除します。 - Intune デバイス（MDM）レコードの削除
Intune 管理センター → デバイス → すべてのデバイス から該当 PC を開き、削除を実行します（Retire だけでは不十分な場合があります）。 - Entra ID（旧 Azure AD）デバイスの削除
Microsoft Entra 管理センター → デバイス → すべてのデバイス で該当オブジェクトを削除します。
削除後は反映にラグが生じることがあるため、端末の再起動を含めて数分～十数分程度あけてから再登録を試します。
別テナントにレコードが残っている場合の対処（サポート依頼）
自社側にレコードが見つからないにもかかわらずエラーが続く場合、他社・旧テナント側に所有権レコードが残存している可能性が高いです。組織の管理者は、Microsoft 365 管理センターからサポート チケットを発行し、該当デバイスのテナント紐付け解除（デバイス オブジェクト削除）を依頼します。必要な準備は以下です。
- デバイス所有証明（シリアル番号が記載された請求書・納品書・資産台帳・ベンダー証明書など）
- 該当デバイスの シリアル番号、ハードウェア ハッシュ（可能なら）、購入日・ベンダー情報
- エラー画面のスクリーンショットや発生日時、登録手順のログ（後述の MDMDiag など）
依頼時に活用できるテンプレートを用意しました。
【件名】Intune/Autopilot: 「The device is assigned to another tenant」の解除依頼
【対象デバイス】メーカー/型番/シリアル番号
【事象】Windows 11 Enterprise 端末を自社テナントに登録しようとすると、
「The device is assigned to another tenant」エラーでブロックされる
【希望対応】旧テナント側に残っている当該デバイスのレコード削除（テナント紐付け解除）
【所有証明】請求書/納品書の写し（シリアル番号記載）、資産管理台帳の写し 等
【補足】発生日時、登録手順、関連ログ（MDMDiagReport 他）端末側で行うクリーンアップ（再登録前の下準備）
クラウド側のレコード整理と並行して、端末内の残存登録情報をリセットします。管理者権限のあるローカル/ドメイン アカウントで実行してください。
- 旧ワークアカウントを切断
設定 → アカウント → 職場または学校へのアクセス で、古い組織アカウントが表示されていれば 切断 します。 - dsregcmd で Azure AD 登録を解除
管理者 PowerShell を開き、以下を順に実行します。dsregcmd /status dsregcmd /leave実行後、端末を再起動します。 - （Autopilot 運用時）不整合を解消
Autopilot を利用している場合は、Windows 登録 > Windows Autopilot デバイス から、該当シリアルを削除するか、正しいテナントで再インポートします。
dsregcmd /status の読み取りポイント
| 項目 | 期待値 | 意味/解釈 |
|---|---|---|
| AzureAdJoined | YES（参加済）/ NO（未参加） | Azure AD 参加状態（企業所有想定なら YES が望ましい） |
| WorkplaceJoined | YES/NO | 個人所有（登録）かどうかの目安（BYOD では YES になりがち） |
| Device State > MdmUrl | Intune の MDM URL 表示 | MDM に登録されていれば URL が表示される。空なら未登録。 |
| NgcSet | YES/NO | Windows Hello for Business の有無（再登録で再プロビジョニングされる） |
再登録の標準手順（Azure AD 参加 & MDM 自動登録）
- 端末を再起動。
- 設定 → アカウント → 職場または学校へのアクセス → 接続 をクリック。
- 正しい会社アカウントでサインイン（多要素認証が有効な場合は指示に従う）。
- 組織のポリシーに従って MDM 自動登録が実行されることを確認。
- 必要に応じて Microsoft 会社ポータル アプリを起動し、デバイスをセットアップから管理プロファイルを適用。
この時点で Intune 管理センターの デバイス に当該端末が現れ、構成プロファイル・セキュリティベースライン・アプリ配布が順次適用されていきます。
Autopilot を利用する場合の補足（プロファイルとインポート）
- ハードウェア ハッシュの取得
管理者 PowerShell（インターネット接続必要）で、以下のいずれかを実行します。# スクリプトの入手（初回のみ） Install-Script -Name Get-WindowsAutopilotInfo -Force # CSV に出力 Get-WindowsAutopilotInfo -OutputFile AutopilotHWID.csv # 可能ならオンライン登録 # Get-WindowsAutopilotInfo -Online - Autopilot デバイスのインポートと割り当て
Windows 登録 → Windows Autopilot デバイスで CSV をインポートし、デプロイ プロファイルとグループ タグを割り当てます。
反映にはタイムラグがあるため、OOBE でのセットアップはプロファイルの状態が 割り当て済み になってから実施します。
リセット/初期化の違い（目的別の使い分け）
| 手段 | 主目的 | ユーザーデータ | 注意点 |
|---|---|---|---|
| Wipe（完全消去） | 譲渡/廃棄/再配布前の初期化 | 削除 | BitLocker 回復キーの管理を確認 |
| Autopilot Reset | 企業所有端末の再プロビジョニング | 削除 | Autopilot プロファイルが前提。適用後は即運用可。 |
| Fresh Start | 不要アプリ除去とクリーン化 | 保持/削除 混在 | OEM アプリが消えるため事前検証が必要 |
| ローカルからの「この PC を初期状態に戻す」 | 緊急時の復旧 | 選択可 | ネットワーク要件/ドライバの再適用に注意 |
確認・防止のチェックリスト（再発を避ける）
- 日時と時刻が NTP と同期している（時刻ずれは認証失敗の温床）。
- Intune ライセンスがユーザーに割り当て済み。
- Entra ID の モビリティ（MDM と MAM）で MDM ユーザー スコープに対象ユーザー/グループが含まれている。
- Windows エディションが Pro/Enterprise/Educationのいずれか（Home は Azure AD 参加/Autopilot 対象外）。
- ネットワーク/プロキシで MDM/Autopilot 関連のエンドポイントへ疎通可能。
- Intune の デバイス クリーンアップ ルール（非アクティブ日数）を適切に設定。
- 端末交換（マザーボード交換等）でハードウェア ハッシュが変化した場合は再インポート。
- 退役・譲渡時は Autopilot/Intune/Azure AD の各レコードを忘れず削除。
現場で役立つ診断コマンドとログ
症状切り分けの精度を上げるため、次の情報をセットで取得するとサポートとのやり取りがスムーズです。
| 目的 | コマンド/操作 | 補足 |
|---|---|---|
| シリアルの確認 | wmic bios get serialnumber | Autopilot/納品書の照合に必須 |
| UUID の確認 | wmic csproduct get uuid | 追加識別子として有用 |
| 登録状態の確認 | dsregcmd /status | AzureAdJoined/MdmUrl などを確認 |
| MDM 診断の収集 | mdmdiagnosticstool.exe -area Autopilot;DeviceEnrollment;DeviceProvisioning -cab c:\temp\MDMDiag.cab | サポート提出用（パスは環境に合わせて変更） |
よくある落とし穴と回避策
- Autopilot だけ削除して満足……Intune デバイスや Entra ID デバイスが残れば再発します。三者すべてをチェック。
- Retire（リタイア）＝完全削除と誤解……削除（Delete）まで実施する。
- 旧アカウントの残骸……職場または学校へのアクセスで確実に切断し、
dsregcmd /leaveまで行う。 - Home エディションでの登録失敗……Azure AD 参加/Autopilot は不可。Pro 以上へアップグレード。
- ネットワーク制限……プロキシ/SSL インスペクションで MDM 通信が破断。例外設定を準備。
ケーススタディ：状況別の具体的対応
ケース A：中古で購入した PC を自社で使いたい
- シリアル番号を取得し、まず自社テナント側で Autopilot/Intune/Azure AD にレコードがないことを確認。
- 登録時に当該エラーが出た場合は、Microsoft サポートへ解除依頼。所有証明として購入証跡（販売店の納品書など）を添付。
- 解除完了後、端末側で 切断 & dsregcmd /leave & 再起動 を行い、再登録。
ケース B：クロステナント移行で旧テナントの Autopilot が残っている
- 旧テナントの管理者が Autopilot/Intune/Azure AD の該当デバイスを完全削除。
- 新テナントでハードウェア ハッシュを再インポートし、プロファイルを割り当て。
- OOBE からセットアップ、または Autopilot Reset → OOBE。
ケース C：マザーボード交換後にエラーが出る
- ハードウェア ハッシュが変化している可能性が高い。新しいハッシュを採取して 再インポート。
- 旧ハッシュの Autopilot レコードが残っていれば削除。
- Intune/Entra ID のオブジェクト整合性も確認。
安全運用のベストプラクティス（再発防止の型）
- 資産台帳にシリアル・購入証跡・グループタグを紐付け、廃棄/譲渡/移管のチェックリスト化。
- 退役フローに Autopilot/Intune/Azure AD の削除を必ず含める。
- グループベース割り当てと デプロイ プロファイルの命名規則を統一し、誤テナント/誤環境へのインポートを防ぐ。
- ネットワーク側で Microsoft クラウドへの必須通信を事前にホワイトリスト化。
- 四半期ごとに 未使用デバイスのクリーンアップを実施（自動ルール＋運用チェック）。
FAQ
Q. 「デバイスが別のテナントに…」はクライアント側だけで解消できますか？
A. 別テナントに Autopilot レコード/MDM レコードが残っている場合、クライアント単独では解決できません。所有証明を準備し、Microsoft サポート経由で旧テナント側の削除が必要です。
Q. 会社ポータルからの登録と設定アプリからの接続、どちらが良い？
A. 企業所有端末は Azure AD 参加＋MDM 自動登録が推奨です。BYOD は会社ポータルによる デバイス登録（Azure AD 登録）が一般的です。
Q. Hybrid Azure AD Join 環境でも発生しますか？
A. はい。オンプレ AD 連携に関わらず、クラウド側の所有権レコードが優先されます。残存レコードの削除が必要です。
Q. エラー解消後に何を確認すべき？
A. Intune デバイスに表示され、構成プロファイル/アプリが配布されること、dsregcmd /status の MdmUrl が入ること、AzureAdJoined が期待値になっていることを確認します。
この記事の要点（まとめ）
- エラーの本質：デバイス識別子が 別テナントの所有としてクラウドに残っている。
- 最短解：自社側で Autopilot/Intune/Azure AD の三種類のレコードを削除 → 端末側 切断 & dsregcmd /leave & 再起動 → 正しいアカウントで再登録。
- 他テナント残存：Microsoft サポートに所有証明を添えて解除依頼。
- 再発防止：退役フローの定型化、クリーンアップ ルール、資産台帳整備、ネットワーク例外化。
以上の手順とチェックを踏むことで、Windows 11 Enterprise 端末の Intune 登録で発生する「The device is assigned to another tenant」問題を、再発なく安全に解消できます。
付録：原因別の対処早見表
| 症状 | 主な原因 | 確認箇所 | 対処 |
|---|---|---|---|
| エラーが即時表示 | Autopilot レコードが他テナントに残存 | 自社に見当たらない場合は他テナントを疑う | 所有証明を添えてサポート経由で解除依頼 |
| 登録できるが Intune に出ない | MDM スコープ/ライセンスの未設定 | Entra > モビリティ（MDM/MAM） | 対象ユーザー/グループにスコープとライセンスを付与 |
| 会社ポータルでのセットアップが止まる | ネットワーク/プロキシ制限 | MDM/Autopilot 関連通信 | SSL インスペクション例外・認証プロキシの回避 |
| 再登録後も旧設定が出る | 端末側に旧登録情報が残存 | dsregcmd /status | /leave 実行と再起動、必要に応じてリセット |
付録：運用テンプレート（オフボーディング）
【退役チェックリスト（Windows/Intune）】
□ Intune デバイス：削除
□ Autopilot デバイス：削除
□ Entra ID デバイス：削除
□ BitLocker 回復キー：保管/破棄ポリシーに従い処理
□ 端末：Wipe または Autopilot Reset 実行
□ 資産台帳：シリアル・購入証跡・削除日時を更新
コメント