Microsoft 365のディレクトリ同期でオンプレミスADのUPNが [email protected] のような非ルーティング可能ドメインのままだと、Microsoft 365側で想定どおりのサインイン名にならない可能性があります。結論から言うと、同期前にMicrosoft Entra IDで検証済みの会社ドメインへUPNをそろえることが重要です。2026年4月23日の公式ドキュメントソース更新は、本文手順の大幅変更ではなく、IDモデル関連コンテンツとして分類し直すメタデータ更新が中心です。運用担当者は「新機能対応」ではなく、「既存のディレクトリ同期設計を改めて点検するタイミング」と捉えるのが実務的です。(Microsoft Learn)
Microsoft 365の最新動向: 非ルーティング可能ドメイン対応で何が変わったか
Microsoft公式ドキュメント「Prepare a nonroutable domain for directory synchronization」は、オンプレミスのActive Directory Domain Services（AD DS）をMicrosoft 365へ同期する前に、.local などの非ルーティング可能ドメインをどう扱うべきかを説明する管理者向け記事です。
2026年4月23日のGitHub上の公式ドキュメントソース更新では、対象ページに identity-models という ms.custom メタデータが追加されています。つまり、記事の位置付けがMicrosoft 365の「IDモデル」「ハイブリッドID」「ユーザーアカウント管理」の文脈により明確に整理された更新と見てよいでしょう。一方、Microsoft Learn上の対象ページでは、ページ下部の最終更新日は2024年10月7日と表示されています。本文手順そのものが2026年4月に大きく書き換えられた、というよりも、ドキュメント体系上の整理が入った更新です。(GitHub)
| 確認項目 | 2026年4月更新の見方 | 管理者が取るべき対応 |
|---|---|---|
| 対象記事の本文 | 手順の大幅変更ではない | 既存手順を前提に環境を点検する |
| メタデータ | identity-models が追加 | IDモデル設計の一部として扱う |
| 実務上の重要点 | .local UPNの扱いは引き続き重要 | 同期前に検証済みドメインへUPNを変更する |
| 読者への影響 | 管理者・IT部門向けの運用判断が中心 | ユーザー通知とサインイン名変更の計画が必要 |
非ルーティング可能ドメインとは何か
非ルーティング可能ドメインとは、インターネット上で通常の組織ドメインとして検証・利用できない内部向けドメイン名のことです。代表例は contoso.local のような .local ドメインです。
Microsoft 365でオンプレミスディレクトリを同期する場合、Microsoft Entra IDには検証済みドメインが必要です。公式ドキュメントでは、[email protected] のような非ルーティング可能ドメインを含むUPNは、[email protected] のような .onmicrosoft.com ドメインへ同期される例が示されています。Microsoftは、AD DSで .local を使っている場合、Microsoft 365で検証済みのドメイン、たとえば contoso.com のような形式へ変更することを推奨しています。(Microsoft Learn)
ここで重要なのは、問題が「メール送受信だけ」ではない点です。UPNはMicrosoft 365のサインインIDとして扱われるため、メールアドレス、サインイン名、オンプレミスADのユーザー名がずれると、管理者にも利用者にも混乱が起きます。
なぜ .local のまま同期すると問題になるのか
Microsoft Entra Connectは、AD DSのユーザー情報をMicrosoft Entraテナントへ同期します。ただし、Microsoft 365側に同期できるドメインは、基本的にMicrosoft 365で検証済みの有効なインターネットドメインです。内部AD DSが contoso.local だけで構成されている場合、そのドメインはMicrosoft 365テナントの検証済みドメインと一致しません。公式ドキュメントでは、この問題への対応として、オンプレミスAD DSのプライマリドメインを変更する方法、またはUPNサフィックスを追加する方法が示されています。(Microsoft Learn)
実務では、次のようなトラブルにつながりやすくなります。
- ユーザーのサインイン名がメールアドレスと違い、問い合わせが増える
- Teams、Exchange Online、SharePoint、OneDriveなどの利用開始時に認証で迷う
- SSOや条件付きアクセスの設計時に、ユーザー識別子の整理が必要になる
- 既に同期済みのユーザーで、Microsoft 365側UPNとAD DS側UPNの不一致が残る
- 海外拠点や買収企業のADを統合する際、命名ルールがばらつく
特にビジネスユーザーにとっては、「パスワードが変わったか」よりも「どのIDでサインインすればよいか」が混乱の原因になります。IT部門は、UPN変更を単なる属性変更ではなく、ユーザー体験に直結する変更として扱うべきです。
実務では「UPNサフィックス追加」が第一候補になりやすい
公式ドキュメントでは、非ルーティング可能ドメインへの対処方法として「プライマリドメインの変更」と「UPNサフィックスの追加」が示されています。プライマリドメインの変更は影響範囲が大きいため、多くの環境では、検証済みドメインに対応するUPNサフィックスをAD DSへ追加し、既存ユーザーのUPNを更新する方法が現実的です。(Microsoft Learn)
| 対応方法 | 向いているケース | 注意点 |
|---|---|---|
| AD DSのプライマリドメインを変更する | 新規構築に近い環境、AD全体の再設計を行う場合 | 影響範囲が大きく、既存アプリや認証連携の検証が必要 |
| 代替UPNサフィックスを追加する | 既存ADを維持しつつMicrosoft 365へ同期したい場合 | ユーザーごとのUPN更新、通知、同期確認が必要 |
.local のまま進める | 検証用途など限定的な環境 | 本番利用ではサインイン名の不一致や運用混乱が起きやすい |
多くの企業では、contoso.local という内部ADドメインはそのまま維持し、ユーザーのUPNだけを [email protected] に変更します。これにより、オンプレミスADの構造を大きく変えずに、Microsoft 365のサインイン名を会社の正式ドメインへ寄せられます。
作業前に確認すべきチェックポイント
UPNサフィックスの変更は、PowerShellで一括実行できます。ただし、いきなり全ユーザーへ適用すると、サインイン障害や問い合わせ増加につながります。まずは次の項目を確認してください。
| 確認項目 | 具体的に見るポイント |
|---|---|
| Microsoft 365側の検証済みドメイン | contoso.com など、実際に使うドメインがテナントで検証済みか |
| 現在のUPN | [email protected] のユーザーが何人いるか |
| メールアドレスとの一致 | UPNとプライマリSMTPアドレスをそろえる方針にするか |
| 重複属性 | userPrincipalName や proxyAddresses に重複がないか |
| 対象外アカウント | サービスアカウント、管理者アカウント、検証用アカウントをどう扱うか |
| 連携システム | SSO、VPN、業務アプリ、MFA、条件付きアクセスへの影響 |
| ユーザー通知 | 新しいサインインID、変更日、問い合わせ先を事前に案内するか |
Microsoftの同期準備ドキュメントでも、ディレクトリ同期前に重複した proxyAddresses や userPrincipalName の削除、無効なUPNの修正、属性値の整理が重要だと説明されています。また、UPNはインターネット形式のサインイン名である必要があり、ローカルまたは内部ドメインは使えないと明記されています。(Microsoft Learn)
UPNサフィックスを追加して既存ユーザーを更新する流れ
公式ドキュメントの手順では、まずAD DS側で新しいUPNサフィックスを登録し、その後ユーザーごとにUPNサフィックスを変更します。少人数ならGUIで対応できますが、ユーザー数が多い場合はPowerShellでの一括変更が現実的です。(Microsoft Learn)
検証済みドメインを決める
最初に、Microsoft 365で使う正式なドメインを決めます。たとえば、オンプレミスADが contoso.local、会社のメールドメインが contoso.com なら、UPNの変更先は原則として contoso.com です。
この段階で、次のような命名ルールを決めておくと後工程が安定します。
| 項目 | 例 |
|---|---|
| 旧UPN | [email protected] |
| 新UPN | [email protected] |
| 例外 | 退職予定者、共有アカウント、サービスアカウント |
| パイロット対象 | IT部門、情シス、少数の一般ユーザー |
AD DSに代替UPNサフィックスを追加する
AD DSドメインコントローラーで、Active Directory Domains and Trusts を開きます。Server Managerから開くか、Domain.msc を実行します。Active Directory Domains and Trusts のプロパティを開き、UPN Suffixes タブで新しいUPNサフィックスを追加します。たとえば contoso.com を追加します。(Microsoft Learn)
この作業では、ADドメイン名そのものを変更しているわけではありません。ユーザーアカウントで選択できるUPNの右側、つまり @ 以降の候補を増やしていると理解すると分かりやすいです。
少人数ならGUIでUPNを変更する
少数のユーザーであれば、Active Directory Users and Computers を開き、対象ユーザーのプロパティから Account タブを選びます。UPNサフィックスのドロップダウンで新しいサフィックスを選択し、保存します。公式手順では、全ユーザーに対してこの変更を行う流れが説明されています。(Microsoft Learn)
パイロット段階ではGUI変更が向いています。変更後、対象ユーザーがMicrosoft 365へ想定どおりサインインできるか、TeamsやOutlookの再認証が必要か、MFAプロンプトに問題がないかを確認します。
多数のユーザーはPowerShellで一括変更する
ユーザー数が多い場合は、PowerShellで対象ユーザーを抽出して更新します。公式ドキュメントでは、Get-ADUser と Set-ADUser を使い、contoso.local を contoso.com に置き換える例が示されています。(Microsoft Learn)
本番反映前に、まず変更予定の一覧をCSVに出力して確認します。
Import-Module ActiveDirectory
$OldSuffix = "@contoso.local"
$NewSuffix = "@contoso.com"
Get-ADUser -Filter "UserPrincipalName -like '*contoso.local'" -Properties UserPrincipalName |
Select-Object SamAccountName,UserPrincipalName,
@{Name="NewUserPrincipalName";Expression={$_.UserPrincipalName.Replace($OldSuffix,$NewSuffix)}} |
Export-Csv ".\upn-change-plan.csv" -NoTypeInformation -Encoding UTF8CSVで対象者に誤りがないことを確認したら、パイロットOUや少数ユーザーから適用します。
Import-Module ActiveDirectory
$Users = Get-ADUser -Filter "UserPrincipalName -like '*contoso.local'" -Properties UserPrincipalName -ResultSetSize $null
foreach ($User in $Users) {
$NewUpn = $User.UserPrincipalName.Replace("@contoso.local","@contoso.com")
Set-ADUser -Identity $User.DistinguishedName -UserPrincipalName $NewUpn
}一括変更では、対象外にすべきアカウントを先に除外することが重要です。特に、サービスアカウント、同期用アカウント、緊急用の管理者アカウント、外部連携に使っているアカウントは、通常ユーザーと同じルールで変更してよいかを事前に確認してください。
既に同期済みの場合に注意すべきこと
すでにMicrosoft 365へ同期している環境では、UPNの変更がすぐに期待どおり反映されるとは限りません。Microsoftの同期準備ドキュメントでは、ユーザーがドメイン検証前にライセンスを割り当てられていた場合などに、Microsoft 365側UPNとAD DS側UPNが一致しない状態が発生し得ることが説明されています。また、AD DS側のUPN変更をMicrosoft Entra IDへ同期させる場合、変更前にMicrosoft 365ライセンスの扱いを確認すべきケースにも触れられています。(Microsoft Learn)
実務では、既存同期済みユーザーに対して次の順序で確認すると安全です。
| 順序 | 確認内容 |
|---|---|
| 変更前 | Microsoft 365側のUPN、メールアドレス、ライセンス状態を確認 |
| 変更時 | AD DS側でUPNを変更し、同期対象に含まれているか確認 |
| 同期後 | Microsoft Entra管理センターやMicrosoft 365管理センターで新UPNを確認 |
| ユーザー確認 | Outlook、Teams、OneDrive、ブラウザサインインを確認 |
| 事後対応 | 古い資格情報のキャッシュ、端末側の再サインインを案内 |
ライセンスやメールボックスを持つユーザーは影響が大きいため、全社一括ではなく、部門単位・拠点単位・テストユーザー単位で段階的に進めるのが現実的です。
ユーザーへ伝えるべき内容
UPN変更は管理者視点では属性変更ですが、利用者視点では「サインインIDの変更」です。案内が不足すると、変更翌日に問い合わせが集中します。
通知文には、少なくとも次の内容を含めてください。
| 通知項目 | 記載例 |
|---|---|
| 変更内容 | Microsoft 365へのサインインIDが変わります |
| 旧ID | [email protected] |
| 新ID | [email protected] |
| パスワード | 通常は現在のパスワードを使用します |
| 影響範囲 | Outlook、Teams、OneDrive、SharePointなどで再サインインが必要になる場合があります |
| 変更日時 | 〇月〇日 18:00以降 |
| 問い合わせ先 | 社内ヘルプデスク、ITサポート窓口 |
ユーザーには「メールアドレスが変わる」と誤解されやすいため、UPNとメールアドレスの関係を社内方針に合わせて説明します。UPNとメールアドレスを同じにするなら、「今後はメールアドレスと同じIDでサインインできます」と伝えると理解されやすくなります。
失敗しやすいポイント
.onmicrosoft.com へ同期された後で気づく
非ルーティング可能ドメインのまま同期すると、想定した会社ドメインではなく .onmicrosoft.com 側のUPNでユーザーが作成・同期される場合があります。後から直せますが、ユーザー通知、ライセンス、アプリ認証、端末キャッシュの対応が増えます。同期前に直す方が、圧倒的に運用負荷は低くなります。
UPNとメールアドレスの違いを放置する
UPNとメールアドレスは同じものではありません。ただし、Microsoft 365のサインイン体験ではメールアドレス形式のUPNが使われるため、両者が異なるとユーザーが混乱しやすくなります。特別な理由がない限り、UPNは業務で使うメールアドレスに近い形式へそろえる方が、ヘルプデスク対応を減らせます。
PowerShellで全ユーザーを一気に変更する
PowerShellの一括変更は便利ですが、ミスも一括で反映されます。事前CSV出力、パイロット適用、対象外アカウントの除外、変更後ログの保存を必ず行ってください。特に海外拠点やグループ会社を含むテナントでは、ドメインサフィックスが複数存在することがあります。
サービスアカウントや管理者アカウントを通常ユーザーと同じ扱いにする
サービスアカウントのUPNを変えると、連携アプリやスクリプトの認証に影響する可能性があります。管理者アカウントも、緊急時に使うクラウド専用アカウントとオンプレミス同期アカウントを分けて管理する必要があります。通常ユーザーのUPN変更リストとは別に棚卸ししてください。
管理者が今すぐ行うべきこと
今回の2026年4月更新は、手順変更のニュースとして読むよりも、Microsoft 365のID管理における「UPN設計の基本を再確認する更新」として捉えるべきです。特に、オンプレミスADに .local を使っている組織、これからMicrosoft Entra Connectで同期する組織、M&Aや拠点統合で複数ADを扱う組織は、同期前のUPN確認が欠かせません。
まずは次の3点から始めてください。
- AD DS内に
@contoso.localなどの非ルーティング可能UPNが残っていないか確認する - Microsoft 365で検証済みの会社ドメインに合わせたUPNサフィックスを設計する
- パイロットユーザーでUPN変更、同期、Microsoft 365サインインを検証する
非ルーティング可能ドメインの対応は、派手な新機能ではありません。しかし、ここを曖昧にしたままMicrosoft 365へ同期すると、サインイン、SSO、ライセンス管理、ユーザー問い合わせのすべてに影響します。ディレクトリ同期を始める前に、UPNを「Microsoft 365で使えるID」として整えることが、安定したハイブリッドID運用の第一歩です。
コメント