MENU

Entra Connect SyncのAttributeValueMustBeUnique（proxyAddresses重複）をGraph APIだけで解消する完全手順

Azure

オンプレミスのActive DirectoryからEntra ID（旧Azure AD）へ同期（Entra Connect Sync/旧AAD Connect）した際、エクスポートでAttributeValueMustBeUniqueエラーに阻まれる――その多くはproxyAddresses / mailの重複が原因です。本記事では、Exchange Onlineライセンスが無い環境でも、Microsoft Graph βエンドポイントを直接叩いて重複を解消し、同期を正常化するまでの実践的手順と、再発防止の設計ポイントを詳説します。

目次

現象の概要と背景

Entra Connect Syncでオンプレミスユーザーをクラウドへエクスポートする際、次のようなエラーが表示されることがあります。

export error: AttributeValueMustBeUnique
対象: user
属性: proxyAddresses または mail
説明: テナント内で一意であるべき値が重複しているためエクスポートできない

典型的なシナリオは、過去に作られたクラウド専用ユーザー（クラウドのみのアカウント）や、ソフト削除済みユーザー・グループ、ゲスト、あるいは組織の連絡先（orgContact）などに、同一の mail / proxyAddresses の値（例: SMTP:[email protected]）が残っているケースです。Entra ポータルのユーザー画面では proxyAddresses を編集できず、Graph PowerShellでも表示されない（空に見える）ケースがあり、Exchange Online 管理センターもライセンス未契約で使えない――結果として「消したくても消せない」状態になります。

なぜ重複が起きるのか（ルールを正しく理解する）

Entra ID では、メールアドレス系の属性に重複禁止の制約が存在します。特に proxyAddresses は Exchange 系ワークロードが参照するため、テナント全体での一意性が強く求められます。

属性値の例重複判定の考え方補足
proxyAddressesSMTP:[email protected]
smtp:[email protected]		テナント内のすべての対象（ユーザー、グループ、連絡先、共有MBX、削除済みアイテム等）で一意SMTP:（大文字）はプライマリ SMTPを示し、smtp:（小文字）はエイリアス。大文字小文字は役割を示すだけで、重複は大文字小文字を区別せずに判定されます。
mail[email protected]ユーザー/連絡先等をまたいで一意多くの環境でproxyAddressesと同一値が入るため、セットで確認必須。

見落としやすい「重複の温床」

  • クラウド専用ユーザー（過去の試行で作成した一次アカウント）
  • ソフト削除済みオブジェクト（ユーザー/グループ/連絡先）：ごみ箱内に残存
  • 組織の連絡先（organizationContact）やゲスト（UserType=Guest）
  • 配布グループ/メール有効セキュリティグループ/共有メールボックス

最短解決：Graph βエンドポイントでproxyAddressesを「完全置換」

Exchange Online ライセンスが無くても、Microsoft Graph βの PATCH /beta/users/{id} で proxyAddresses を配列ごと上書きできます。不要な値は送らない＝列挙しないことで削除されます（完全置換）。

前提：必要な権限（委任）

  • User.ReadWrite.All または Directory.AccessAsUser.All（委任）
  • グローバル管理者であっても、Graphに対する管理者同意が無いと Graph Explorer 等で403 Forbiddenになります

最短は Graph Explorer で対象テナントにサインインし、Modify permissionsから上記スコープを付与して Admin consent を与える方法です（本番での変更は必ずChange管理の下で）。

現在のproxyAddressesを確認（β）

GET https://graph.microsoft.com/beta/users/{UserObjectId}?$select=id,displayName,mail,proxyAddresses

戻りの proxyAddresses 配列に、重複の原因となる値（例：SMTP:[email protected]）が含まれていることを確認します。

不要なアドレスを除外して上書き（完全置換）

PATCH https://graph.microsoft.com/beta/users/{UserObjectId}
Content-Type: application/json

{
"proxyAddresses": [
"SMTP:new[[email protected]](mailto:[email protected])",
"smtp:new[[email protected]](mailto:[email protected])",
"smtp:new[[email protected]](mailto:[email protected])"
]
}
  • 送信した配列がそのまま置き換えられます。残したい値だけを列挙してください。
  • プライマリにしたいアドレスは SMTP: の大文字で指定します。

変更後の確認

GET https://graph.microsoft.com/beta/users/{UserObjectId}?$select=id,proxyAddresses

不要な値が消え、残したい値だけになっていることを確認します。

Entra Connect の同期を再実行

# エクスポートを急ぐ場合（増分）
Start-ADSyncSyncCycle -PolicyType Delta

# ルール変更や多数の差分後で念のため完全同期を行いたい場合

Start-ADSyncSyncCycle -PolicyType Initial

PowerShellだけで完結させたい（REST直叩き手順）

Graph PowerShell（Microsoft.Graph）では環境により proxyAddresses が空に見えることがあります。そこで、Invoke-MgGraphRequest または純正の Invoke-RestMethod で β REST を直接叩くのが確実です。

方法A：Invoke-MgGraphRequestでβを叩く

# 管理者同意済みで実行
Connect-MgGraph -Scopes "User.ReadWrite.All","Directory.AccessAsUser.All" -ContextScope Process
Select-MgProfile -Name "beta"  # βプロファイル

# 1) 現在のproxyAddressesを確認

$userId = "<対象ユーザーのObjectId>"
Invoke-MgGraphRequest -Method GET -Uri "[https://graph.microsoft.com/beta/users/$userId`?$select=id,displayName,mail,proxyAddresses](https://graph.microsoft.com/beta/users/$userId`?$select=id,displayName,mail,proxyAddresses)"

# 2) 残したいアドレスを定義（完全置換）

$body = @{
proxyAddresses = @(
"SMTP:new[[email protected]](mailto:[email protected])",
"smtp:new[[email protected]](mailto:[email protected])"
)
} | ConvertTo-Json

# 3) 上書き

Invoke-MgGraphRequest -Method PATCH -Uri "[https://graph.microsoft.com/beta/users/$userId](https://graph.microsoft.com/beta/users/$userId)" -Body $body -ContentType "application/json"

# 4) 検証

Invoke-MgGraphRequest -Method GET -Uri "[https://graph.microsoft.com/beta/users/$userId`?$select=id,proxyAddresses](https://graph.microsoft.com/beta/users/$userId`?$select=id,proxyAddresses)"

方法B：MSALでトークン取得 → Invoke-RestMethod

# 必要: MSAL.PS モジュール or 既存のアプリ登録（機密/公開いずれも可）
# スコープ例: "https://graph.microsoft.com/.default"（アプリ許可）または "User.ReadWrite.All Directory.AccessAsUser.All"（委任）

$tenantId = ""
$clientId = ""      # 公開クライアント可
$scopes   = "User.ReadWrite.All Directory.AccessAsUser.All"

$token = (Get-MsalToken -ClientId $clientId -TenantId $tenantId -Scopes $scopes).AccessToken
$headers = @{ "Authorization" = "Bearer $token"; "Content-Type"="application/json" }

$userId = "<対象ユーザーのObjectId>"

# 現在値

Invoke-RestMethod -Method GET -Uri "[https://graph.microsoft.com/beta/users/$userId`?$select=id,mail,proxyAddresses](https://graph.microsoft.com/beta/users/$userId`?$select=id,mail,proxyAddresses)" -Headers $headers

# 置換

$body = @{
proxyAddresses = @("SMTP:new[[email protected]](mailto:[email protected])","smtp:[email protected]")
} | ConvertTo-Json

Invoke-RestMethod -Method PATCH -Uri "[https://graph.microsoft.com/beta/users/$userId](https://graph.microsoft.com/beta/users/$userId)" -Headers $headers -Body $body

# 検証

Invoke-RestMethod -Method GET -Uri "[https://graph.microsoft.com/beta/users/$userId`?$select=proxyAddresses](https://graph.microsoft.com/beta/users/$userId`?$select=proxyAddresses)" -Headers $headers

重複の有無を事前に洗い出すクエリ集（横断チェック）

アドレスの重複はユーザー以外にも潜んでいます。以下は代表的な横断検索例です（β）。

ユーザー・ゲスト・連絡先での重複検索

# 例: <addr> を重複チェック
$addr = "smtp:[email protected]"

# ユーザー

GET [https://graph.microsoft.com/beta/users?$count=true&$filter=proxyAddresses/any(p:p](https://graph.microsoft.com/beta/users?$count=true&$filter=proxyAddresses/any%28p:p) eq '{addr}') or mail eq '[[email protected]](mailto:[email protected])'&$select=id,displayName,mail,proxyAddresses

# 組織の連絡先

GET [https://graph.microsoft.com/beta/contacts?$count=true&$filter=proxyAddresses/any(p:p](https://graph.microsoft.com/beta/contacts?$count=true&$filter=proxyAddresses/any%28p:p) eq '{addr}') or mail eq '[[email protected]](mailto:[email protected])'&$select=id,displayName,mail,proxyAddresses

# グループ（配布/メール有効セキュリティ含む）

GET [https://graph.microsoft.com/beta/groups?$count=true&$filter=proxyAddresses/any(p:p](https://graph.microsoft.com/beta/groups?$count=true&$filter=proxyAddresses/any%28p:p) eq '{addr}') or mail eq '[[email protected]](mailto:[email protected])'&$select=id,displayName,mail,proxyAddresses

削除済みアイテム（ごみ箱）の確認

# ユーザー（削除済み）
GET https://graph.microsoft.com/beta/directory/deletedItems/microsoft.graph.user?$filter=proxyAddresses/any(p:p eq '{addr}') or mail eq '[email protected]'&$select=id,displayName,mail,proxyAddresses

# グループ（削除済み）

GET [https://graph.microsoft.com/beta/directory/deletedItems/microsoft.graph.group?$filter=proxyAddresses/any(p:p](https://graph.microsoft.com/beta/directory/deletedItems/microsoft.graph.group?$filter=proxyAddresses/any%28p:p) eq '{addr}') or mail eq '[[email protected]](mailto:[email protected])'&$select=id,displayName,mail,proxyAddresses

削除済みに該当する場合は、完全削除（パージ）するか、対象の proxyAddresses を別値へ変更してから復元します。

トラブル時のナレッジ（原因と対処の対応表）

症状推定原因対処
Graph Explorer で 403 Forbidden必要スコープの未付与/未同意User.ReadWrite.All または Directory.AccessAsUser.All を追加し、管理者同意を与える
PowerShellで proxyAddresses が空に見える現行のGraph PowerShellでは項目が省略される/既定プロファイルv1.0で取得しているβ RESTを直接叩く、または Select-MgProfile beta と Invoke-MgGraphRequest を使用
PATCHが失敗（400/409）置換後の配列に依然重複がある、または形式不備完全置換で残したい値だけを列挙。SMTP:/smtp:のプレフィックスとメール形式を再確認
同期エラーが消えないDelta Sync未実行、もしくは別オブジェクトに重複が残存Start-ADSyncSyncCycle -PolicyType Delta 実行。再度横断検索で重複ゼロを確認

安全に進めるためのチェックリスト

  • 本番変更の前に該当ユーザーの proxyAddresses をエクスポートしてバックアップ（JSON/CSV）
  • プライマリSMTPは一つだけ。SMTP: が重複しないよう厳密に定義
  • UPN (userPrincipalName) と mail を混同しない。同期元（オンプレミス）の設計を確認
  • 削除済みオブジェクトも検索対象に含める（ごみ箱を見落とさない）
  • 変更後は Delta Sync 実行 → エクスポートログを確認 → 監査ログへ記録

代替策（参考：GUI派／運用制約がある場合）

どうしてもRESTでの変更が難しい場合の回避策です。

  • Exchange Online ライセンスを一時付与し、メールボックスを作成→代理アドレスをGUI（Exchange 管理センター）で調整→ライセンスを外す。
    メリット：操作が視覚的で確実。デメリット：コスト・手続きが増える。
  • ユーザー再作成は最終手段。MFAやアプリ登録、RBAC、監査の参照先など広範に影響が及ぶため、極力避ける。

実践例：クラウド専用ユーザーに残った古いアドレスを除去

  1. 重複しているアドレス（例：[email protected]）を特定（ユーザー/グループ/連絡先/削除済みで横断検索）。
  2. 対象ユーザー（クラウド専用）の proxyAddresses を GET で取得し、SMTP:[email protected] と必要なエイリアスだけを残した配列を作る。
  3. PATCH /beta/users/{id} に作成した配列を送信（完全置換）。
  4. GET で反映を確認 → Delta Sync 実行 → エクスポートでエラーが解消したことを確認。

よくある質問（FAQ）

Q. ベータ（β）エンドポイントの更新は安全？

βは将来変更される可能性がある非推奨インターフェースです。とはいえ、本件のように「Exchangeライセンス無しでクラウド側の残存アドレスを削除したい」要件では実務的に有力です。必ず検証環境で事前確認のうえ、本番ではChange管理・監査を行ってください。

Q. PATCH は差分ではなく完全置換？

はい。proxyAddresses は配列の差分更新ではなく完全置換として扱われます。残したいすべての値を忘れず列挙してください。

Q. Graph PowerShellで見えないのは不具合？

環境やバージョンにより proxyAddresses が既定では返らない・空に見えることがあります。確実性を取るなら β REST直叩きを用いましょう。

Q. 変更後にメール配送へ影響は？

プライマリSMTP（SMTP:）や必要なエイリアス（smtp:）を誤って削除すると配送不能となる恐れがあります。必ずバックアップと二重チェックを行い、営業時間外に実施しましょう。

運用設計のベストプラクティス（再発防止）

  • ソース・オブ・オーソリティの一元化：メールアドレス生成規則（mailNickname → proxyAddresses）をオンプレミス/クラウドで統一。命名規則をスクリプト化。
  • 事前予約（アドレスの仮押さえ）：退職者や統合時は、再利用予定のアドレスを事前に別オブジェクトへ退避しない。ごみ箱も含めアドレスを完全解放してから再割当。
  • 監視/検知：新規作成・移行ジョブの直前に、候補アドレスで横断検索（前述クエリ）を自動実行して重複をブロック。
  • 棚卸し：定期的にクラウド専用アカウント・連絡先・削除済みを棚卸しし、不要な proxyAddresses を削除。
  • 命名変更の安全策：組織変更や社名変更でドメインが変わる場合、旧ドメインのエイリアスを計画的に残しつつ、重複検出ジョブを併走。

参考スクリプト：重複候補を一括チェック → 置換まで半自動化

次の例は、候補アドレスの一覧（CSV）を読み込み、横断検索→対象ユーザーの proxyAddresses を置換する流れの雛形です（β）。本番投入前に十分な検証を行ってください。

# CSV形式: UserId,Primary,Aliases (セミコロン区切り)
# 例:
# 1111-aaaa-... , [email protected] , [email protected];[email protected]

Connect-MgGraph -Scopes "User.ReadWrite.All","Directory.AccessAsUser.All"
Select-MgProfile beta

$csv = Import-Csv .\addresses.csv
foreach($row in $csv){
$userId = $row.UserId
$primary = $row.Primary
$aliases = @()
if($row.Aliases){ $aliases = $row.Aliases.Split(";") }

# 横断検索（例示：ユーザーのみ。必要に応じて contacts/groups/deletedItems も併記）

$needle = "smtp:$primary".ToLower()
$dupUsers = Invoke-MgGraphRequest -Method GET -Uri "[https://graph.microsoft.com/beta/users?`$filter=proxyAddresses/any(p:p](https://graph.microsoft.com/beta/users?`$filter=proxyAddresses/any%28p:p) eq '$needle') or mail eq '$primary'&`$select=id,displayName"
if($dupUsers.value | Where-Object { $_.id -ne $userId }){
Write-Warning "重複検出: $primary"
continue
}

# 完全置換ボディ作成（プライマリ1件＋エイリアス複数）

$proxy = @("SMTP:$primary")
foreach($a in $aliases){ if($a){ $proxy += "smtp:$a" } }

$body = @{ proxyAddresses = $proxy } | ConvertTo-Json
Invoke-MgGraphRequest -Method PATCH -Uri "[https://graph.microsoft.com/beta/users/$userId](https://graph.microsoft.com/beta/users/$userId)" -Body $body -ContentType "application/json"

Write-Host "Updated: $($userId) <= $($primary) / aliases: $($aliases -join ',')"
}

エラー解析のコツ：ログの読み方

  • Entra Connect の Synchronization Service Managerで「Export」タブ→失敗行をダブルクリック→Detailed Message に AttributeValueMustBeUnique と対象属性名（proxyAddresses または mail）が出ます。
  • 同メッセージ内で「どの値が衝突しているか」が表示される場合は、その値を鍵に横断検索すると早いです。
  • 「対象オブジェクト」がクラウド側の既存ユーザーであることも多いので、ObjectId（GUID）を特定してから前述の GET /beta/users/{id} を当てます。

ケーススタディ：移行プロジェクト中の「一時アカウント」が犯人

メール移行のパイロット中に、クラウドへ手作りで一次ユーザーを作成し、ドメイン切替後も残存していたケースです。オンプレミス側を同期すると、同じ SMTP:[email protected] を持つため衝突。
対処は、一次ユーザー（クラウド専用）の proxyAddresses から該当の値を除去し、オンプレミスユーザー側でプライマリ指定を維持する、という方針です。RESTの完全置換なら、GUI不要で数分で解決できます。

セキュリティと監査

  • 付与するスコープ（User.ReadWrite.All / Directory.AccessAsUser.All）は強力です。最小権限で期間限定の付与にとどめ、作業後は必ず剥奪します。
  • 変更内容（旧/新の proxyAddresses）と実行者、時刻、チケット番号を監査ログに記録します。
  • 自動化する場合は、承認フロー（Change管理）と二重チェック（4-eyes）を必ず噛ませます。

まとめ（要点の再掲）

  • AttributeValueMustBeUniqueは、ほぼproxyAddresses / mail の重複が原因。
  • Exchange Onlineライセンスが無くても、Graph βの完全置換PATCHで不要な proxyAddresses を除去可能。
  • 403は権限不足のサイン。グローバル管理者でもGraphの管理者同意が必須。
  • ユーザー以外（連絡先・グループ・ゲスト・削除済み）も横断検索。ごみ箱を忘れない。
  • 変更後はDelta Syncを回して、エクスポートのエラー消失まで確認。
  • 再発防止として、アドレス生成規則の一元化・事前重複チェック・定期棚卸しを運用に組み込む。

付録：コマンド早見表

目的コマンド/リクエストポイント
現在のproxyAddresses取得GET /beta/users/{id}?$select=id,mail,proxyAddressesβで取得。PowerShellで空に見える場合はREST直叩き。
完全置換で上書きPATCH /beta/users/{id}（{"proxyAddresses":[...]}）SMTP:（大文字）がプライマリ。残したい値だけ列挙。
横断検索（ユーザー）GET /beta/users?$filter=proxyAddresses/any(p:p eq 'smtp:<addr>')mail 等も併せて確認。
削除済みの横断検索GET /beta/directory/deletedItems/microsoft.graph.user?...ごみ箱の見落としが頻出。
同期の手動実行Start-ADSyncSyncCycle -PolicyType Delta必要に応じてInitialでフル。

この記事の価値（読者メリット）

従来、Exchange OnlineのGUIに頼っていたアドレス調整を、ライセンスの有無に関わらずGraph APIだけで完結させる具体的な手順を示しました。小規模の単発対応はもちろん、移行プロジェクトでの大量処理にも拡張しやすい構成です。エラーの根本理解、横断的な重複検知、完全置換による安全な除去、そして再発防止の運用――この一連の実装を通じて、Entra Connect Syncの安定運用とアドレス管理のガバナンス強化が実現します。

付録B：サンプルJSON（バックアップ/リストア用）

変更前にバックアップしておくと、万が一のときに即時復旧できます。

{
  "userId": "00000000-0000-0000-0000-000000000000",
  "before": {
    "proxyAddresses": [
      "SMTP:[email protected]",
      "smtp:[email protected]"
    ]
  },
  "after": {
    "proxyAddresses": [
      "SMTP:[email protected]",
      "smtp:[email protected]"
    ]
  },
  "changedBy": "[email protected]",
  "changedAt": "2025-01-01T12:34:56Z",
  "ticket": "CHG-12345"
}

付録C：よくある入力ミス

  • プレフィックスの付け忘れ：SMTP: / smtp: を必ず付ける。
  • プライマリの二重化：SMTP: が2件以上 → エラー。
  • メール形式の誤り：全角混入、空白、末尾ドットなど。
  • 意図しない削除：完全置換で必要なエイリアスを漏らす → 事前バックアップ、4-eyesで回避。

最後に

「編集できない proxyAddresses が重複していて同期が止まる」という、どの規模のテナントでも起こり得る問題を、ツールやライセンスの制約を超えて解消する現実解をまとめました。RESTの一撃で道が開けます。あなたのテナントでも、まずは1件、βエンドポイントで安全に検証し、運用へスムーズに取り込んでみてください。

Azure
PowerShell Microsoft Graph Azure AD Connect Entra ID proxyAddresses AttributeValueMustBeUnique

この記事を書いた人

佐藤健司のアバター 佐藤健司

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

関連記事

コメント

コメントする

目次