Windows 11 の新しい PC に Microsoft Edge でサインインしてもブックマークや拡張機能が一切同期されず、edge://sync-internals に network error と出る――現場で頻発するこの症状は、実は多くのケースで IPv6 経路の破損 が原因です。本記事は、最短復旧（IPv6 の一時無効化）から恒久対策、企業/家庭ネットワーク別の確認ポイントまでを一気通貫で解説します。
目次
新しい PC で Edge の M365 プロファイルが同期できないときに起きていること
症状は次のようにまとまります。
- Windows 11 の新しい PC で Microsoft アカウント（または職場/学校アカウント）で Edge にサインインしても、同期が開始しない。
- お気に入り（ブックマーク）や拡張機能、パスワード、設定などが 0 件のまま。
edge://sync-internalsを開くと “network error”、“Transport State: Connection error” などの表示。- 同一アカウントでも 他の PC では正常に同期できる。
結論の要点（先に知りたい方向け）
- 同期エンドポイント（クラウド側）が AAAA（IPv6）で返っており、クライアント側またはネットワーク側の IPv6 が破損/遮断していると、Edge は接続に失敗し同期が始まりません。
- IPv6 を一時的に無効化すると直ちに同期が成功するケースが非常に多いです（本質は IPv6 経路/設定の問題）。
- 恒久対策は、ネットワーク全体で IPv6 を正常化するか、暫定的に Edge 同期に関与する宛先の通信を IPv4 優先にする運用を検討します。
まずは最短で復旧（IPv6 を一時的に無効化 → 同期 → 再度有効化して検証）
復旧を急ぐときの手順です。後述の恒久対策に進む前に、ユーザー影響を最小化して「とりあえず同期を通す」ことを目的とします。
GUI で IPv6 を一時的に無効化する
- 「設定」→「ネットワークとインターネット」→「アダプターのオプションを表示」。
- 対象の Wi‑Fi（または Ethernet）アダプターを右クリック →「プロパティ」。
- 「インターネット プロトコル バージョン 6 (TCP/IPv6)」のチェックを外す →「OK」。
- Edge を再起動し、「設定 → プロファイル → 同期 → 今すぐ同期」で確認。
PowerShell で素早く切替（管理者権限の端末）
# アダプター名の確認
Get-NetAdapter | Select-Object Name, Status
# 例: Wi-Fi の IPv6 バインドを無効化
Set-NetAdapterBinding -Name "Wi-Fi" -ComponentID ms_tcpip6 -Enabled $false
# 例: 再度有効化
Set-NetAdapterBinding -Name "Wi-Fi" -ComponentID ms_tcpip6 -Enabled $true 同期が成功したら、必ず IPv6 を再度有効化して、問題が再発しないか（＝ネットワーク側が原因でないか）を確認します。無効のままの固定運用は推奨しません。理由は後述します。
なぜ IPv6 が原因になるのか（技術的背景）
Edge は OS の名前解決とソケットを使ってクラウドの同期サービスへ接続します。DNS から AAAA レコード（IPv6）が返る環境では、先に IPv6 経路を試行することがあります。ところが、次のような環境不整合があると接続が失敗します。
- ルーター/ONU が IPv6（IPoE）を半端に有効にしており、実経路が不安定・断続的。
- 社内 DNS が 誤った AAAA を返す、または DNS6 のキャッシュが破損している。
- プロキシ/SSL インスペクション/VPN が IPv6 を通さない（IPv4 のみ透過）。
- 宅内機器の ファームウェア不整合（IPv6 まわりの不具合）。
この結果、Edge は「同期サービスに到達できない」と判断し、edge://sync-internals に network error が出続けます。一時的に IPv6 を切ると IPv4 での接続に切り替わり、直ちに同期が開始される――という挙動になります。
10分で切り分けるチェックリスト（再現性の確認）
| チェック | 実施コマンド/操作 | 期待される結果 | 判定と次アクション |
|---|---|---|---|
| DNS が AAAA を返すか | nslookup -type=AAAA <同期関連のホスト名例> | IPv6 アドレスが返る | 返る場合、IPv6 経路を重点確認 |
| IPv6 での疎通 | ping -6 <返ってきた IPv6> | 応答あり | 応答なし→ IPv6 経路/フィルタを疑う |
| TLS 443 到達性 | Test-NetConnection -ComputerName <ホスト> -Port 443 | TCP Test Succeeded | 失敗→ ファイアウォール/プロキシ/経路を点検 |
| IPv6 を切った直後に同期するか | 前述の GUI/PowerShell 手順 | 数秒～1分で同期開始 | 同期する→ 原因は高確率で IPv6 |
| 別ネットワークで再現するか | スマホテザリング等で接続 | 同期成功 | 成功→ 元のネットワーク機器/ISP 側の問題 |
原因と対処の早見表
| 主原因 | 具体的な兆候 | 暫定対処 | 恒久対策 |
|---|---|---|---|
| IPv6 経路不通/不安定 | ping -6 失敗、TNC 失敗 | IPv6 一時無効 | ルーター更新、IPv6 設定の正常化 |
| DNS の AAAA 誤応答 | 社内 DNS でのみ再現 | 暫定で外部 DNS へ切替 | DNS 設定修正、ゾーン/フォワーダー見直し |
| プロキシ/VPN が IPv6 非対応 | VPN 接続時のみ失敗 | VPN/プロキシを一時無効 | デュアルスタック対応、分割トンネル設計 |
| セキュリティ製品の SSL 検査 | 証明書エラーやハンドシェイク失敗 | 同期ドメインを検査除外 | 検査ポリシー最適化、証明書配布の整備 |
IPv6 を無効にしたままにすべきでない理由
- Windows の一部機能や最新のネットワークサービスは IPv6 前提で最適化されています。
- 企業ネットワークでは将来の更改で IPv6 を前提にすることが増え、後からの巻き戻しコストが高くなります。
- “直ったように見せる” 応急処置に留まり、根本原因（DNS/ルーター/プロキシの不備）を温存します。
恒久対策：ネットワーク全体の正常化 or IPv4 優先の戦略的運用
1) IPv6 を正しく使えるように整備する（推奨）
- ルーター/ファームウェア更新：最新化で IPv6 の既知不具合を回避。
- DNS 設定の点検：社内 DNS が正しい AAAA を返しているか。上位フォワーダー/キャッシュも確認。
- RA/DHCPv6 の整合：プレフィックス配布、デフォルトゲートウェイ、DNS 配布の一貫性。
- プロキシ/VPN のデュアルスタック：IPv6 を通過させるか、分割トンネルで同期エンドポイントを直行。
- ファイアウォール：IPv4/IPv6 で
tcp/443のアウトバウンドを対称に許可。
2) 一定期間、IPv4 優先にする（ネットワーク更改までのブリッジ）
環境事情ですぐに IPv6 を正常化できない場合、Windows の優先度を調整し、IPv4 を優先する暫定策があります。代表例：
- レジストリ
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\ParametersのDisabledComponentsに 0x20（IPv4 優先）を設定し再起動。
※ 0xFF（完全無効化）は推奨しません。変更は組織の標準手順に従い、影響評価とロールバック計画を用意してください。 - Intune/グループポリシーで一時的に展開し、ネットワーク更改後に戻す運用。
また、社内 DNS にポリシーを設定して特定ドメインの AAAA 提供を抑制する設計もありますが、副作用が大きいため最後の手段とし、期間と対象を厳格に管理してください。
「IPv6 以外かもしれない」場合の追加確認ポイント
Windows アカウント/サインイン状態
- 「設定 → アカウント → 職場または学校にアクセスする」で対象アカウントが 正しく接続/認証されているか。
- 個人の Microsoft アカウント（MSA）と Microsoft Entra ID（旧 Azure AD） を取り違えていないか。
Office / Microsoft 365 のライセンス状態
- 同じアカウントで Office アプリが 正常にアクティブか。アカウントの有効性を確認。
ポリシーの影響（グループポリシー / Intune）
- Edge のポリシー確認：アドレスバーに
edge://policyを入力し、SyncDisabled、SyncTypesListDisabled、BrowserSignin などの設定有無を確認。 - ローカルレポート：
gpresult /h report.htmlを生成し、適用 GPO を精査。 - Intune 管理下なら、設定プロファイル/コンプライアンスポリシー/条件付きアクセスが 同期を間接的に阻害していないかを確認。
Entra ID（旧 AAD）参加の有無
dsregcmd /statusで Device State / SSO State を確認。未参加でも本件の直接原因ではありませんが、参加によりトークン/SSO が安定し改善する例があります。
ネットワーク/端末で実施する詳細診断
DNS と名前解決の健全性
# IPv6 スタックの状態
Get-NetIPInterface -AddressFamily IPv6 | Format-Table
# DNS キャッシュのクリア（管理者権限のコマンドプロンプト）
ipconfig /flushdns
# 名前解決の検証（AAAA / A）
nslookup -type=AAAA <対象ホスト名>
nslookup -type=A <対象ホスト名> 経路と到達性の確認
# 物理リンクとルーティング
Get-NetRoute -AddressFamily IPv6 | Sort-Object -Property RouteMetric
# TCP 443 の疎通
Test-NetConnection -ComputerName <対象ホスト名> -Port 443 -InformationLevel Detailed Edge 側の観点（ユーザーでも確認できる）
- edge://sync-internals：Transport State、Disable Reasons、Last Synced Details を確認しスクリーンショットを取得。
- edge://version：チャネル/ビルド/OS バージョンの把握（チャネル差異による一時的な事象切り分け）。
- edge://policy：同期関連ポリシーの有無。
企業ネットワークで頻出する落とし穴と対処
プロキシ/SSL インスペクション
- プロキシが IPv6 を トンネルせずドロップしている。
- SSL インスペクションで 同期ドメインの証明書を置換しハンドシェイク失敗。
- 対処：同期関連の宛先を 検査除外、または 直行例外（プロキシバイパス）の定義。
VPN の設計
- フルトンネルで IPv6 を 強制無効にしているが、DNS は AAAA を返す構成。
- 対処：分割トンネルでクラウド宛を直行、または AAAA を返さないよう DNS ポリシーを統一。
社内 DNS の分断
- オンプレ拠点/クラウド拠点で ゾーンの整合が取れていない、フォワーダーの到達性に問題。
- 対処：上位 DNS の設計見直し、キャッシュ期限と負荷分散の適正化。
家庭/小規模オフィスでの実践手順
- ルーター再起動/最新化：ファームウェア更新を適用。
- IPv6 機能の有効/無効を明示：中途半端に“ON だが実経路なし”を避ける。
- DNS 設定の見直し：ルーターの DNS を既定に戻すか、信頼できるリゾルバーへ切替。
- セキュリティソフトの SSL 検査除外：ブラウザ同期/ログイン系ドメインを除外。
- 別回線での比較：スマホテザリングで同期が直るなら回線/機器側が原因。
管理者向け：ポリシー/ファイアウォールの整備ポイント
代表的な Edge ポリシー（ADMX/Intune）
- SyncDisabled：同期を完全に無効化。
- SyncTypesListDisabled：特定タイプ（Favorites, Extensions など）を禁止。
- BrowserSignin：ブラウザへのサインインを制御。
- RestrictSigninToPattern：許可するドメインを制限。
意図せずこれらが適用されていないかを edge://policy と GPO/Intune レポートで二重確認します。
ファイアウォールの観点
- IPv4/IPv6 の両方で
tcp/443アウトバウンドを許可。 - SSL インスペクション/HTTPS プロキシの例外リストに同期ドメインを追加。
- DNS（
udp/53ほか DoH/DoT を使う設計の可否）を整理。
トラブルが IPv6 起因かを簡単に“見える化”する工夫
- ログオンスクリプトで
Test-NetConnectionの結果を収集し、IPv4/IPv6 の成功率をダッシュボード化。 - クライアントからの
Get-NetAdapterBinding結果を収集し、どの機器で IPv6 が有効/無効かを可視化。 - DNS ログで AAAA クエリのヒット率と失敗率を把握。
復旧後の品質確認（ユーザー側でできること）
- 同期ダッシュボード：
設定 → プロファイル → 同期でエラーがないか。 - Favorites の件数：同期前後で増減が期待通りか。
- 拡張機能の自動復元：必要な拡張が揃っているか。
- パスワード/設定：別 PC で保存した内容が新 PC に反映されているか。
- edge://sync-internals：Last Synced Details の時刻が直近になっているか。
Q&A：よくある疑問
Q. IPv6 を無効のまま運用して良いですか？
A. 推奨しません。将来のサービスやセキュリティ最適化は IPv6 を前提に進みます。根本原因の解消（DNS/ルーター/プロキシの整備）を目標にしてください。
Q. すべての PC で同時に起きるわけではないのはなぜ？
A. 端末ごとのドライバー/ルーティング/DNS キャッシュ差、ネットワーク機器の負荷やフラップ、VPN の状態により IPv6 経路の品質が時間的・空間的に揺らぐためです。
Q. 「IPv6 は疎通するが同期は失敗」することはある？
A. あります。L4 の疎通はしても、TLS ハンドシェイクを中間機器が検査/書き換えして失敗するケースや、特定の SNI/ALPN でのみ拒否されるケースがあります。SSL インスペクションの除外や 直行例外を試してください。
運用に組み込む“安全な暫定策”の設計例
- 段階的ロールアウト：IPv6 優先度変更（
DisabledComponents=0x20）を少数グループで検証 → 段階展開。 - タイムボックス：暫定策に期限を設定し、期限までにネットワークの恒久対策を完了。
- 監視指標：同期成功率、TLS 443 エラー率、DNS AAAA ヒット率、ユーザー苦情件数を週次でレビュー。
安全にロールバックできるようにする（変更管理の基本）
- レジストリ/ポリシー変更前に バックアップを取得。
- 変更は スクリプト化（配布/回収が容易な形）。
- 変更履歴を残す（誰が/いつ/どの端末に）。
- ロールバック手順を 事前検証し、緊急時に即時適用できるようにしておく。
まとめ：再発させないための優先順位
- 最短復旧：IPv6 を一時無効化 → Edge 再起動 → 同期が始まることを確認。
- 原因特定：DNS の AAAA、IPv6 経路、プロキシ/VPN/SSL 検査の有無を 10 分チェックで切り分け。
- 恒久対策：ネットワーク全体の IPv6 を正常化（推奨）。やむを得ない場合は一時的に IPv4 優先。
- ポリシー/端末状態：
edge://policy、gpresult、dsregcmdで統制が同期を阻害していないかを確認。 - 検証と監視：再発を防ぐための指標を定義し、短いサイクルで見直す。
付録：現場で使えるコマンドスニペット集
ネットワーク基本
ipconfig /all
route print -6
Get-NetIPInterface -AddressFamily IPv6
Test-NetConnection -Port 443 -ComputerName <ホスト名>
DNS まわり
ipconfig /flushdns
nslookup -type=AAAA <ホスト名>
nslookup -type=A <ホスト名>
ポリシー可視化
gpresult /h C:\Temp\gpreport.html
Start-Process C:\Temp\gpreport.html
Entra ID の参加状態
dsregcmd /status
IPv6 の一時無効/再有効（アダプター名は環境に合わせて）
Set-NetAdapterBinding -Name "Wi-Fi" -ComponentID ms_tcpip6 -Enabled $false
Set-NetAdapterBinding -Name "Wi-Fi" -ComponentID ms_tcpip6 -Enabled $true
補足メモ（運用ガイドライン）
- ユーザーサポートでは「IPv6 無効化→同期→再有効化」を標準手順としてテンプレ化し、所要 5 分のメニューにまとめる。
- ネットワークチームは ルーター/ファームウェアと DNS 設定の健全性を四半期ごとに健康診断。
- セキュリティチームは SSL インスペクションの除外リストの棚卸しを定期実施。
コメント