Azure AD Connect で同期しているユーザーは、Microsoft 365 の「My account」や Entra 管理センターでメールが表示されても編集できないことがあります。本記事では、UPNと主SMTPの違い、変更すべきAD属性、同期反映の手順、リネーム後に残りがちな古いアドレスの整理方法をまとめます。
よくある症状：「見えるのに編集できない」メインのメールアドレス
オンプレミス Active Directory（以下オンプレ AD）と Microsoft Entra ID（旧 Azure AD。以下 Entra ID）を Azure AD Connect（Entra Connect）で同期している環境では、ユーザーのプロファイルや Microsoft 365 側の画面でメールアドレスが表示されているのに、編集ができないケースがよく起きます。
典型例として、共有用途のユーザー（例：support）に対して、過去に使っていたアドレス（例：mike@...）が「メインのメール」として見え続ける、といった現象です。
- Microsoft 365 側（My account / Personal info）ではメールが見えるが編集できない
- Entra 管理センターのユーザー Profile では Alternate email（代替メール）しか変えられない
- オンプレ AD 側（ADUC の「E-mail」欄）が空で、どこを変えればよいか分からない
- 以前
mikeというアカウント名だったものをsupportにリネームした可能性がある
この症状で混乱が起きる最大の理由は、「画面に出ている“メール”が、どの属性（どの目的のメール）なのかが分かりづらい」ことと、「同期ユーザーはクラウド側の一部項目が読み取り専用になる」ことの2点です。
まず押さえる：同期ユーザーは“クラウド側で直せない項目”がある
Azure AD Connect で同期しているユーザーは、一般にオンプレ AD が正（ソース・オブ・オーソリティ）になります。そのため、Microsoft 365 や Entra ID の画面で該当項目が表示されていても、同期元がオンプレ側である項目はクラウド側で編集できません。
ここで重要なのは「編集できない＝権限がない」ではなく、編集できない＝別の場所（オンプレ AD など）で管理されている可能性が高い、という視点です。
最重要：変えたいのは“どのメール”か（UPN / 主SMTP / 連絡先メール / 代替メール）
「メールアドレスを変えたい」と言っても、実務上は少なくとも次の4種類に分解して考える必要があります。ここを取り違えると、いくら属性を変更しても「画面が変わらない」「送受信が変わらない」になりがちです。
| 変えたいもの | 主に影響する場面 | 代表的な同期元 | オンプレ側で触ることが多い属性 | よくある勘違い |
|---|---|---|---|---|
| サインイン名（UPN） | Microsoft 365 へのログイン、デバイスサインイン | オンプレ AD | userPrincipalName | UPNを変えればメール送受信も変わると思い込む |
| 主SMTP（送受信の“メイン”アドレス） | Outlook/Exchange の送信元・受信先 | オンプレ Exchange / もしくはオンプレ AD | proxyAddresses（SMTP: が主）/ mail | ADUCの「E-mail」が空だから主SMTPも空だと思い込む |
| 連絡先として表示されるメール（プロファイルの Mail） | Entra ID ユーザープロファイル、連絡先情報 | オンプレ AD | mail | mail と proxyAddresses が常に一致していると思い込む |
| 代替メール（Alternate email） | パスワードリセット通知など（用途は組織設定次第） | クラウド側でも変更できる場合がある | （ケースによる） | Alternate email を変えれば“メインのメール表示”が変わると思い込む |
今回のように「My account / Personal info に出ているが編集できない」「Entra の Profile で Alternate email しか変えられない」という状況は、主SMTP（proxyAddresses）や mail 属性がオンプレ側で管理されているパターンが濃厚です。
現場で使える見分け方：いま表示されている値は何の値か
まずは「どの画面の、どのラベルに、何が出ているか」を切り分けます。ここが曖昧だと、対処がブレます。
| 確認場所 | 見る項目 | 読み取りのポイント |
|---|---|---|
| Entra 管理センター（ユーザー詳細） | User principal name / Mail / Proxy addresses / On-premises sync | 「On-premises sync」が有効なら多くの項目がオンプレ起点。Mail と Proxy addresses を分けて見る |
| Microsoft 365「My account」 | Personal info の Email / Contact | 同期ユーザーだと編集不可のことが多い。ここは“結果表示”と割り切る |
| オンプレ AD（ADUC） | 「Account」タブの UPN、（あるなら）「General」タブの E-mail | E-mail欄は mail 属性。空でも proxyAddresses に SMTP が入っていることがある |
| オンプレ AD（Attribute Editor） | userPrincipalName / mail / proxyAddresses / mailNickname | 真犯人はここにいることが多い。ADUCで「高度な機能」を有効化して確認 |
| Exchange（オンライン/オンプレ） | メールボックスの Primary SMTP / Email addresses | 主SMTPは送受信の挙動に直結。共有メールボックスかユーザーかも確認 |
ポイント：ADUC の「E-mail」が空でも安心できません。主SMTPが proxyAddresses に残っていると、クラウド側には「メールがある」ように見え続けます。
ADUCで Attribute Editor を表示する手順（見落としがち）
- オンプレ AD の「Active Directory ユーザーとコンピューター（ADUC）」を開く
- メニューの「表示」から「高度な機能」を有効化する
- 対象ユーザーのプロパティを開き、「属性エディター（Attribute Editor）」タブで属性を確認する
対処の基本戦略：クラウドで直せないなら“オンプレ側の正しい属性”を直す
結論から言うと、同期ユーザーの「メインのメール表示」を直すときの作業は、ほぼ次のいずれか（または両方）になります。
- サインイン名の問題なら：オンプレ AD の
userPrincipalNameを直す - 送受信のメイン（主SMTP）の問題なら：オンプレ AD の
proxyAddresses（およびmail）を直す
ただし、オンプレ Exchange / ハイブリッドがあるかどうかで「どこから直すのが正攻法か」が変わります。ここを飛ばすと、あとで別の仕組みに上書きされて「元に戻った」ように見えることがあります。
対処パターン：UPN（サインイン名）を直したい場合
「ログイン名として表示されるアドレスが古い」「サインインに使う名前を support@… にしたい」なら、主に UPN の話です。UPN はオンプレ AD のユーザー アカウントに紐づく属性で、Azure AD Connect により同期されます。
手順の目安
- 新しい UPN のドメイン（例：
example.com）が Microsoft 365 側で利用可能（検証済みドメイン）であることを確認する - オンプレ AD で対象ユーザーの UPN を変更する
- Azure AD Connect の同期で反映させる（差分同期）
- サインイン動作（新UPNでログインできるか）を確認する
PowerShell 例（確認）
オンプレ AD の PowerShell（ActiveDirectory モジュール）で確認します。
Get-ADUser -Identity support -Properties userPrincipalName |
Select-Object SamAccountName,UserPrincipalNamePowerShell 例（変更）
Set-ADUser -Identity support -UserPrincipalName "[email protected]"注意：UPNを変えても、主SMTP（送受信アドレス）が自動的に変わるとは限りません。ログイン名とメールアドレスを同じにしたい場合は、次の「主SMTP」側も合わせて設計・変更するのが安全です。
対処パターン：主SMTP（送受信のメイン）を直したい場合
「Outlookで送信元が mike@… のまま」「受信側に見えるメインが古い」「Exchange上の Primary SMTP を変えたい」なら、主SMTPの話です。
主SMTP は多くの環境で proxyAddresses の中の SMTP:（大文字） が担います。別名（エイリアス）は smtp:（小文字）で複数持てます。
まず確認したい：オンプレ Exchange / ハイブリッドの有無
| 環境 | 推奨されやすい変更ルート | 理由 |
|---|---|---|
| オンプレ Exchange が存在（ハイブリッド含む） | オンプレ Exchange の管理ツール（EAC/PowerShell）で変更 | Exchange が受信者属性を管理し、AD直編集だと上書きや整合性崩れが起きやすい |
| オンプレ Exchange は無いが Azure AD Connect で同期している | オンプレ AD 属性（proxyAddresses / mail）を慎重に編集 | クラウド側が編集不可になりがち。ADが正である限りオンプレ側で整える必要がある |
オンプレ Exchange / ハイブリッドがある場合の考え方
この場合、メールアドレス（Primary SMTP）を変える作業は、可能な限り Exchange の管理経路で行うのが安全です。特に以下のような “うっかり消すと痛い” アドレスが混ざることがあるためです。
- X500：過去の Exchange 識別子。消すと返信や過去メール参照で NDR につながることがある
- SIP：Teams/Skype 系のアドレスとして残っている場合がある
- 複数のエイリアス：業務で使っている別名が紛れていることがある
共有用途アカウント（support）については、実態が「ユーザー」なのか「共有メールボックス」なのかも重要です。共有メールボックスなら、運用としては共有メールボックス化してアクセス権で利用させた方が、監査・セキュリティ・運用事故の面で安定します（ただし要件次第です）。
オンプレ Exchange が無い場合：AD 属性で主SMTPを直す実務手順
オンプレ Exchange が無い／管理経路が無い場合でも、主SMTPの整合性を取るには、少なくとも次を意識します。
proxyAddressesに新しい主SMTPをSMTP:（大文字）で設定する- 旧アドレスを残すなら
smtp:（小文字）にしてエイリアス化する - 可能なら
mailも新しいアドレスに合わせる（プロファイル表示の整合性） - 既存の
proxyAddressesを上書きで消さない（必要な値まで消しがち）
PowerShell 例：現在の値を確認する
Get-ADUser -Identity support -Properties mail,proxyAddresses,mailNickname,userPrincipalName |
Select-Object SamAccountName,userPrincipalName,mail,mailNickname,proxyAddressesPowerShell 例：主SMTPを入れ替える（既存を守りながら）
例として、現在の主SMTPが [email protected] で、新しい主SMTPを [email protected] にしたいケースです。
# 取得
$user = Get-ADUser -Identity support -Properties mail,proxyAddresses
$proxies = @($user.proxyAddresses)
# 旧主SMTPの候補（環境に合わせて調整）
$oldPrimary = $proxies | Where-Object { $_ -cmatch '^SMTP:' } | Select-Object -First 1
# 新主SMTP（大文字SMTPが主）
$newPrimary = 'SMTP:[email protected]'
# 既に同じ値があれば除外してから追加
$proxies = $proxies | Where-Object { $_ -cnotmatch '^SMTP:[email protected]$' -and $_ -cnotmatch '^smtp:[email protected]$' }
# 既存の主SMTPがあれば小文字に落としてエイリアスにする（残す運用の場合）
if ($oldPrimary) {
$proxies = $proxies | Where-Object { $_ -ne $oldPrimary }
$proxies += ('smtp:' + $oldPrimary.Substring(5)) # "SMTP:" を "smtp:" に
}
# 新主SMTPを追加（主は先頭でなくてもよいが、読みやすく先頭に置く運用が多い）
$proxies = ,$newPrimary + $proxies
# mail も合わせる（表示整合性のため）
Set-ADUser -Identity support -Replace @{
mail = '[email protected]'
proxyAddresses = $proxies
}補足：旧アドレスを“消す”のではなく“エイリアスとして残す”のが安全なことが多いです。過去の取引先が旧アドレスに送ってくる可能性や、システム通知の送信元/送付先に旧アドレスが埋まっている可能性があるためです。
「ADUCのE-mail欄が空」のままでもいい？
目的次第ですが、プロファイル表示の整合性やアドレス帳検索の体験を考えると、proxyAddresses だけでなく mail も合わせておく方が“あとで困りにくい”です。逆に、何らかのポリシーで mail を使わない運用なら、表示が期待通りにならない可能性がある点を前提に、運用基準を決めておくのがよいです。
同期を反映させる：待つ／手動同期／どこで確認するか
オンプレ側を直しても、クラウド側はすぐには変わりません。反映の考え方は次の通りです。
| 手段 | 概要 | 向いている状況 | 注意点 |
|---|---|---|---|
| 通常の同期待ち | Azure AD Connect の定期同期で反映 | 急ぎでない変更 | 反映までの体感がバラつくことがある |
| 差分同期（Delta） | 変更分だけ同期して反映を早める | 今回のような属性修正 | Connectサーバーで操作する必要がある |
| フル同期（Initial/Full） | 全体を再評価 | フィルター変更や大規模変更の後 | 影響が大きいので安易に実施しない |
Azure AD Connect サーバー上で差分同期を回す代表的なコマンド例は次の通りです（実行権限や環境により差があります）。
Start-ADSyncSyncCycle -PolicyType Delta反映確認は「My account の表示」だけに頼らず、Entra 管理センターで該当ユーザーの Mail や Proxy addresses を見て、目的の値に変わっているかを確認するのが近道です。
それでも直らないときに多い原因（実務で刺さるポイント）
「オンプレ側を変えたはずなのに、表示が変わらない」「変わったり戻ったりする」場合、次のどれかに当たっていることが多いです。
主SMTPが実は proxyAddresses の大文字SMTPで古いまま
ADUC の E-mail が空でも、proxyAddresses に SMTP:mike@... が残っていると、主SMTPが古いまま扱われます。まずは proxyAddresses の中に “大文字SMTPが1つだけ” になっているかを見てください。
UPNだけ直して「メールも直ったはず」と思い込んでいる
UPN（ログイン名）と主SMTP（メール送受信）は別物です。UPNだけ変更しても送受信アドレスは変わらない構成が一般的です。
Exchange（または受信者管理の仕組み）が後から上書きしている
オンプレ Exchange が残っている環境では、AD属性直編集が後から Exchange 側の処理で上書きされることがあります。「直した直後は反映されたのに、翌日戻った」などはこの匂いがします。受信者属性は Exchange 管理ツール経路で変更できないかを検討してください。
同期スコープや属性フィルターで、そもそも同期されていない
Azure AD Connect で属性を同期しない設定（カスタム同期ルール、フィルター）が入っていると、オンプレで直してもクラウドへ出ません。特に検証環境を経ずにルール変更した組織では、標準と違う動きが起きます。
アドレスの重複（同じSMTPを別オブジェクトが持っている）
新しいアドレス（例：support@...）を、すでに別ユーザー・別メールボックス・別グループが持っていると、同期/受信者側で衝突して反映されないことがあります。変更前に “そのSMTPがどこにも使われていないか” を検索する癖を付けると事故が減ります。
| 症状 | 疑うポイント | 現場での対処ヒント |
|---|---|---|
| My account だけ変わらない | 表示更新のタイミング差 / キャッシュ | Entra側の値を先に確認し、表示は後追いで見る |
| 送信元が古いまま | 主SMTPが変わっていない | proxyAddressesの大文字SMTPがどれか確認 |
| 変えたのに戻る | Exchange/別仕組みの上書き | 受信者属性はExchange管理経路で統一する |
| 同期エラーが出る | SMTPの重複・衝突 | 同名アドレスの保有オブジェクトを洗い出す |
リネーム（mike → support）が絡むときの整理
ユーザー名（sAMAccountName や表示名）を変えても、メール関連属性は自動では整理されません。よくあるのが次の状態です。
- アカウントは
supportになったが、proxyAddressesにSMTP:mike@...が残っている - UPN は
support@...に変えたが、主SMTPは古いまま - 逆に、主SMTPは
support@...にしたが、mailが古いままでプロファイル表示がちぐはぐ
リネーム後は次の“整合性チェック”を一度やっておくと、後々の問い合わせが減ります。
| チェック項目 | 目標（おすすめ） | 備考 |
|---|---|---|
| UPN（userPrincipalName） | ログインで使う名前が意図通り | ログイン手順や端末サインインに影響 |
| 主SMTP（proxyAddresses の SMTP:） | 送受信のメインが意図通り | 最重要。大文字SMTPは1つにする |
| mail 属性 | プロファイル/連絡先として自然 | 表示の整合性目的で合わせることが多い |
| 旧アドレスの扱い | 必要なら smtp: で残す | いきなり削除すると外部からのメールが不達になる |
スレッドの結論：Microsoft Q&A での扱いと相談先（確定した回答）
今回提示されているスレッド内の“確定した結論”は、技術的な属性の特定ではなく、相談先の案内です。
- Microsoft Q&A では Office 365（O365）の個別製品サポートが対象外になりやすい
- そのため Office 365 系の内容は、Microsoft Tech Community の Office 365 系フォーラムへ投稿して相談してほしい、という誘導が回答になっている
つまり、スレッドとしては「どの属性を変えるべきか」を掘り下げる前に、扱う場所が違うという整理で終わっています。テナント固有の事情（ハイブリッド構成、同期ルール、Exchange受信者管理の有無、過去の移行履歴）が絡むテーマなので、コミュニティでも「環境情報が揃わないと断定できない」ことが多い分野です。
相談・切り分けを早めるための情報テンプレ
投稿や社内エスカレーションの際は、次を埋めると往復が減ります。
| 項目 | 例 | なぜ必要か |
|---|---|---|
| 対象オブジェクトの種別 | ユーザー / 共有メールボックス / 連絡先 / グループ | 管理経路（Exchange/AD/クラウド）が変わる |
| 同期の有無 | On-premises sync enabled: Yes/No | クラウド側で編集できる/できないが分かれる |
| 変えたい“メール”の種類 | UPN / 主SMTP / mail / 代替メール | 変更すべき属性が変わる |
| オンプレ Exchange の有無 | ハイブリッド有/無 | AD直編集が上書きされる可能性がある |
| 現在の属性値 | mail, proxyAddresses, UPN の実値 | 「どこに古い値が残っているか」を特定できる |
運用の落とし穴と、再発防止の小技
最後に、同じ手戻りを繰り返さないための実務ポイントをまとめます。
共有用途の“ユーザー”は、可能なら共有メールボックスに寄せる
共有用途アカウント（support）を「ユーザーとしてサインイン」させる運用は、パスワード共有・監査・多要素認証・退職者引き継ぎなどで揉めやすいです。要件が許すなら、共有メールボックス＋権限付与（送信許可/フルアクセス）に寄せると、運用事故を減らしやすくなります。
UPNと主SMTPを“同じにする/しない”を組織標準にする
UPNと主SMTPを一致させる運用は分かりやすい反面、ドメイン移行やブランド変更のときに影響範囲が広がります。一致させるなら、変更手順（UPN→主SMTP→エイリアス→同期→影響確認）を標準化しておくと安全です。
proxyAddresses を触るときは「消さない」「上書きしない」
proxyAddresses はマルチバリュー属性です。GUIでうっかり全部消すと、SIPやX500など“用途が見えないけど必要”な値まで消しやすい領域です。必ず現状をバックアップ（コピー）し、差分で編集する運用にすると事故が激減します。
「My account で見える＝そこが正」ではない
My account の個人情報は、同期環境では結果の表示であって、変更点検の一次ソースにはなりにくいです。属性ベースの問題は、Entra 側のプロパティ（Mail/Proxy addresses/UPN）と、オンプレ AD の属性を対で見るのが最短です。
「メインのメールが古いまま」「表示されるが編集できない」という問題は、原因が一つに見えても、実際には “どのメールのことか” と “どこが正か（オンプレ起点かクラウド起点か）” の2軸で整理すると一気に解けます。まずは Mail / proxyAddresses / UPN を並べて見て、どこに古い値が残っているかを特定してから、環境（Exchange有無）に合った正攻法で直していきましょう。
コメント