オンプレミスActive DirectoryとEntra ID（旧 Azure AD）を連携するハイブリッドAD環境では、携帯番号（Mobile属性）だけが同期されず、Microsoft 365 管理センターやExchange Onlineに古い番号が残り続けることがあります。本記事では原因の切り分けと、実際に解消した再同期手順を具体的に解説します。
ハイブリッドADで「携帯番号（Mobile）」が同期されない症状とは
ハイブリッド構成（オンプレAD＋Entra ID＋Entra Connect）へ移行後、次のような現象が起きることがあります。
- オンプレADのユーザー属性「Mobile（携帯）」を更新しても、Entra IDに反映されない
- Microsoft 365 管理センター（admin.microsoft.com）でも携帯番号が古いまま
- Exchange Online（連絡先情報）でも古い番号のまま
- 管理センター／Entraポータル／Exchange Online側から編集しようとしても、グレーアウト・エラー・保存できない
- 「ハイブリッド化前にクラウド側で設定していた番号」が残り、オンプレADの値で上書きできないように見える
結論から言うと、ハイブリッド環境では“正（マスター）”の所在地と属性の流れ（同期ルール）を押さえた上で、クラウド側に残る値の扱いをリセットする必要があるケースがあります。
まず押さえる：ハイブリッド構成での属性管理の基本
ハイブリッドAD運用の原則は次の通りです。
- ユーザー属性の正はオンプレAD側（特に電話番号や部署など、ディレクトリ属性）
- Entra Connect（旧 Azure AD Connect）がオンプレ→クラウドへ同期する
- 同期対象ユーザーは、クラウド側（M365管理センター／Entra ID）で編集できない属性が出る（ソースがオンプレのため）
ただし、移行前にクラウドのみで運用していて、Microsoft 365 管理センター等で直接入力していた属性は、移行後に「残り方」が問題になることがあります。特定の属性・特定の状態では、オンプレからの更新が期待通りに入らず、クラウド値が残留して見えることがあります。
どこに何が表示されるのか（整理表）
| 確認先 | 表示される主な項目 | ハイブリッド時の編集可否（一般的傾向） | ポイント |
|---|---|---|---|
| オンプレAD（ADUC / PowerShell） | mobile（Mobile）、telephoneNumber など | 編集可（ここが原則の更新元） | まず“ここが正しいか”を確認 |
| Entra ID（ユーザー属性） | mobilePhone、businessPhones など | 同期ユーザーは編集不可になりやすい | 同期ルールに従って反映されるはず |
| Microsoft 365 管理センター | 連絡先情報（携帯、電話 等） | 同期ユーザーは編集制限が出やすい | 表示はEntra/Exchange由来のことが多い |
| Exchange Online | 連絡先情報（MobilePhone 等） | 同期ユーザーは“オンプレで管理”扱いになりがち | 反映にタイムラグが出る場合あり |
よく混同される：「ユーザー属性の携帯番号」と「認証（MFA）の電話番号」は別物
携帯番号の話でトラブルが長引く原因の一つが、電話番号の種類が複数ある点です。検索キーワードでも「携帯番号 同期」だけだと混ざりやすいので、ここで整理します。
| 種類 | 代表的な場所 | 用途 | 同期の考え方 |
|---|---|---|---|
| 連絡先情報の携帯番号（Mobile属性） | オンプレAD mobile / Entra ID mobilePhone | プロフィール、アドレス帳、連絡先 | オンプレが正 → Entra Connectで同期 |
| MFA/認証方法の電話番号 | Entra ID「認証方法」 | 多要素認証、SMS、電話 | 別管理。属性同期とは別の世界 |
今回のテーマは「連絡先情報としての携帯番号（Mobile）」です。MFAの電話番号を直しても、プロフィールの携帯番号が直らない（または逆）ということが起きるので、切り分けの段階で混同しないようにします。
原因の切り分け：同期されないときに最初に見るべきポイント
いきなり“強制的に直す”前に、まずは次のチェックで状況を短時間で確定させるのが安全です。
チェックリスト（最短ルート）
| チェック項目 | 確認方法（例） | 想定される問題 | 対処の方向性 |
|---|---|---|---|
| オンプレADの属性が正しいか | ADUC / Get-ADUser -Properties mobile | そもそも値が違う・空 | オンプレで修正して同期 |
| 対象ユーザーが同期ユーザーか | Entraで「オンプレ同期」表示 / onPremisesSyncEnabled | 実はクラウドのみ・別オブジェクト | アカウント突合（ImmutableId等）確認 |
| Entra Connectの同期範囲に入っているか | OUフィルタ、グループフィルタ | 対象外のOUにいる | スコープ調整、配置見直し |
| 同期エラー／エクスポート失敗がないか | Synchronization Service Manager | Export errors / join問題 | エラー解消後に再同期 |
| 属性マッピングが想定通りか | 同期ルール（Sync Rules Editor） | mobileを同期していない | ルール修正（影響範囲に注意） |
オンプレAD側の確認コマンド例
まず、オンプレADの「mobile（Mobile）」が本当に正しい値になっているかを確認します。
Get-ADUser -Identity user01 -Properties mobile,telephoneNumber |
Select-Object SamAccountName,mobile,telephoneNumber更新する場合の例です（値の整形も含め、運用ルールを決めておくと後々楽です）。
Set-ADUser -Identity user01 -MobilePhone "090-1234-5678"なお、電話番号の表記ゆれ（ハイフン有無、国番号 +81 など）は、表示や検索性に影響することがあるため、組織として表記ルールを決めておくのがおすすめです。
Entra ID側の状態確認（Graph PowerShell例）
同期ユーザーかどうか、そして現在のmobilePhoneが何になっているかを確認します。
Connect-MgGraph -Scopes "User.Read.All"
Get-MgUser -UserId "[email protected]" -Property Id,DisplayName,MobilePhone,OnPremisesSyncEnabled,OnPremisesImmutableId |
Format-Listなぜ「ハイブリッド化前にクラウドで設定した番号」が残るのか（考え方）
この現象は「クラウド値が“優先される”」というより、実務的には次のどれか（または複合）で説明できることが多いです。
- 同期ルール上、その属性がオンプレから流れていない（想定と違う属性を編集している／同期ルールがカスタムで外れている）
- オブジェクト側の状態が“更新されない”（同期対象外、エクスポートエラー、競合）
- 移行時にクラウド側に存在していた値が残留し、見た目上「上書きされない」（実際は同期が通っていない）
- 管理画面ごとの反映タイミング差（Entraには入ったがM365/EXOに出るまで遅い等）
特に「特定ユーザーだけ」「移行前にクラウドで編集していた」「ハイブリッド後は編集不可」という条件が揃う場合、“クラウド側の値が残っているのではなく、オンプレ→クラウドへの更新が成立していない”可能性を疑うのが合理的です。
その上で、現場でよく取られる対処が次の2系統です。
- クラウド側の該当値を一度クリアし、オンプレから改めて同期させる
- オブジェクトを一度“同期対象外”にしてから戻し、再登録に近い動きを起こして属性の再流し込みを狙う
対処法：クラウド側の値をクリアしてから同期する（基本アプローチ）
ハイブリッド運用では「オンプレが正」です。したがって、オンプレ側の値を正しい状態にした上で、クラウド側の残留値をクリアし、再同期させる流れが基本になります。
手順の全体像
- Graphでクラウド側の MobilePhone を null（空）にする
- オンプレADの Mobile を正しい値にする（既に正しいなら再確認のみ）
- Entra Connectの同期（DeltaまたはInitial）を実行する
- Entra / M365 / Exchange Online 側で反映を確認する
Graph PowerShellでMobilePhoneをクリアする例
Connect-MgGraph -Scopes "User.ReadWrite.All"
Update-MgUser -UserId "[email protected]" -MobilePhone $null同期を走らせる例
Entra Connectサーバー上で実行します。
Start-ADSyncSyncCycle -PolicyType Delta反映に時間差がある場合は、状況に応じて Initial（フル同期）を検討します。
Start-ADSyncSyncCycle -PolicyType Initialうまくいかない場合に出やすいエラーと見直しポイント
環境によっては、Graph更新で次のようなエラーが出ることがあります。
Resource does not exist or one of its queried reference-property objects are not present
このメッセージは一見“MobilePhoneがない”ように見えますが、実務上は次の見直しが効果的です。
- UserIdの指定が正しいか（UPNが変わっている、別オブジェクトを見ている）
- テナントを取り違えていないか（複数テナント運用時）
- 権限（Scopes）が不足していないか（User.ReadWrite.All など）
- 対象が同期ユーザーで、属性がオンプレ管理扱いになっていないか（編集不可属性の可能性）
Graphでのクリアが通らない場合でも、次に紹介する「同期対象外→戻す」方式で解消するケースがあります。
対処法：同期対象外OUへ一時退避→戻して再同期（実際に解消した手順）
ここからが、現場で「最終的にうまくいった」と報告されることがある手順です。ポイントはユーザーオブジェクトをいったん同期スコープ外に出し、再度スコープ内に戻すことで、属性の再流し込みを促す点にあります。
実施前に必ず理解しておきたい注意点
この方法は環境によってはクラウド側でユーザーが一時的に削除（ソフト削除）扱いになる可能性があります。短時間で戻せば復旧するケースが多い一方で、影響ゼロとは限りません。
| 想定される影響 | 起きやすい状況 | リスク低減策 |
|---|---|---|
| ユーザーが一時的にサインインできない | 同期対象外になった瞬間にクラウド側が削除扱い | 業務時間外に実施、短時間で戻す |
| ライセンスやサービスアクセスの揺れ | 削除/復元で割当が変化する環境 | 影響が少ないユーザーで事前検証 |
| Exchange/Teams等の表示遅延 | バックエンド反映にタイムラグ | 反映時間を見込む、監視手順を用意 |
| 監査・運用上の混乱 | 変更履歴が追えない | 手順書化、実施記録、関係者連携 |
上記を踏まえた上で、「携帯番号が同期されない」という局所問題を短時間でリセットするための実務的な復旧策として実施されることがあります。
手順（Accepted Answerとして採用された流れ）
- 問題のユーザーを特定（携帯番号が更新されないユーザー）
- ユーザーを“同期対象外”のOUへ一時移動
Entra Connect（Azure AD Connect）の同期スコープから除外されているOUへ移します。 - Delta Sync（増分同期）を実行
Start-ADSyncSyncCycle -PolicyType Delta- クラウド側の状態反映を待機
短時間（例：1分程度）で反映されることもあれば、管理画面の表示に時間差が出ることもあります。 - ユーザーを元の“同期対象OU”へ戻す
- もう一度 Delta Sync を実行
Start-ADSyncSyncCycle -PolicyType Deltaこの一連の操作で、クラウド側に残っていた古い携帯番号の扱いがリセットされ、オンプレADのMobile属性がEntra IDへ正しく流れるようになった、という報告があります。
なぜOU移動で直ることがあるのか（イメージ）
OU移動による“同期対象外→対象内”の切り替えは、同期エンジン上は次のような動きになりやすいです。
- 同期対象外に移動：Entra Connectから見て「このオブジェクトは管理対象外になった」
- 同期（Delta）：クラウド側では削除（または削除準備）に近い処理が走る
- 同期対象に戻す：再び「管理対象として登場」
- 同期（Delta）：属性が改めて流れ、結果として“古い値の残留”が解消する
実際にはテナント設定や同期構成（フィルタ、ルール、ソフト削除保持など）で挙動が変わるため、最初から本番ユーザーで無計画に行うのは避けるのが安全です。まずは影響の少ないユーザー、あるいは検証環境で再現性を確認してから手順書化すると、運用トラブルを大きく減らせます。
確認手順：反映されたかを確実に見届ける
「管理画面で見たら直っていない」に見えても、バックエンドでは更新済みで、UIのキャッシュや反映遅延が原因ということもあります。複数の観点で確認すると確実です。
Entra ID（Graph）で確認
Connect-MgGraph -Scopes "User.Read.All"
Get-MgUser -UserId "[email protected]" -Property DisplayName,MobilePhone |
Format-ListMicrosoft 365 管理センターで確認
- ユーザーの連絡先情報（携帯電話）が更新されているか
- 同期ユーザーの場合、編集欄がグレーアウトでも値が最新か
Exchange Online で確認（例）
Exchange Online PowerShellで参照します（環境によりコマンドレットや見えるプロパティは異なることがあります）。
Get-User -Identity "[email protected]" | Format-List MobilePhone,Phone表示遅延が疑われる場合は、数十分単位で再確認する、またはEntra ID側（Graph）を一次情報として追うと判断しやすいです。
それでも直らないときに追加で試せること
OU移動でも改善しない場合は、単に「クラウド値の残留」ではなく、同期ルール・オブジェクト突合・エクスポートエラーが根本原因になっている可能性が高まります。ここから先は“環境固有”の色が濃くなるため、手順は慎重に進めてください。
同期状態（スケジューラ）を確認
Get-ADSyncScheduler同期サービス（Synchronization Service Manager）でエラー確認
- Export Errors が出ていないか
- 該当ユーザーのコネクタスペースに更新が入っているか
- Metaverseへの流れ込み（attribute flow）が止まっていないか
属性の“どれを変えているか”を再確認
現場で多いのが「GUIの見た目はMobileを変えているつもりだが、実際に同期している属性が別」というケースです。次の観点で見直します。
- オンプレADのどの属性を更新しているか（mobile / telephoneNumber など）
- Entra Connectの同期ルールで、どの属性がEntraのmobilePhoneへ流れているか
- 過去にカスタム同期（ルール変更）を行っていないか
再発防止：携帯番号（Mobile）を安定同期させる運用のコツ
同じトラブルを繰り返さないための運用ポイントをまとめます。
運用ルールを明文化する
- 携帯番号（連絡先）はオンプレADで更新する
- クラウド側（M365管理センター／Entraポータル／Exchange Online）で触らない
- 更新担当（情シス、HR、各部門）と更新フローを決める
表記ルールを決めてデータ品質を上げる
- 例：国内番号は「090-1234-5678」形式で統一、国際表記は「+81…」に統一など
- ハイフン有無・全角半角を揃えるだけで、検索性・再利用性が大きく向上
更新確認の“標準手順”を作る
「Entra ID（Graph）→ M365管理センター → Exchange Online」の順に確認するなど、チームで同じ見方をすると切り分けが速くなります。
| 段階 | 見る場所 | 判断 |
|---|---|---|
| 一次情報 | オンプレAD（Get-ADUser） | ここが正しくないと始まらない |
| 同期確認 | Entra ID（GraphでmobilePhone） | 同期が通っているかの核心 |
| 利用側確認 | M365管理センター / Exchange Online | 表示遅延も踏まえて確認 |
まとめ：携帯番号が同期されないときの最短解決ルート
- ハイブリッドADでは、携帯番号（Mobile）の正はオンプレAD
- 移行前にクラウドで設定した値が残って見える場合、まずは同期が通っているかを確認する
- 基本策はクラウド値をクリア → オンプレを正 → 再同期
- それでも詰まる場合、実務上は同期対象外OUへ退避 → Delta Sync → 戻す → Delta Syncで解消するケースがある
- ただしOU移動は影響が出る可能性があるため、事前検証と手順書化が重要
携帯番号（Mobile属性）は小さな項目に見えても、アドレス帳・連絡先・運用連絡など、日常業務の“困るポイント”に直結します。原因の切り分けと、環境に合った復旧手順を整備して、ハイブリッドADの属性同期を安定させましょう。
コメント