Visual Studio 2022 発行で「An unexpected network error has occurred」エラーが出る原因と回避策（Microsoft Store 連携／ストア関連付け失敗）

Visual Studio 2022 の最新更新環境でアプリを発行（公開）しようとした瞬間、「An unexpected network error has occurred（予期しないネットワークエラーが発生しました）」で止まり、先に進めない――この手のトラブルは原因の切り分けが難しく、時間だけが溶けがちです。この記事では、ローカル環境の問題か製品側の不具合かを見分ける手順と、急ぎのときに公開作業を進めるための現実的な迂回策をまとめます。

Visual Studio 2022 の発行で出る「An unexpected network error has occurred」とは

このエラーは、Visual Studio が Microsoft Store（Partner Center）側の情報を取得する処理に失敗したときに表示されることが多いメッセージです。特に、次のようなウィザード画面で発生しやすい傾向があります。

「公開」から「アプリケーションとストアを関連付ける（Associate app with the Store）」を実行したとき
「Create App Packages（アプリパッケージの作成）」でストア向けパッケージを作ろうとしたとき
既存のアプリ名（予約名）一覧を取得しようとして「更新／Refresh」したとき

表示文言が「ネットワークエラー」でも、実際には回線の瞬断だけでなく、認証トークンの不整合、プロキシや SSL 検査、サービス側の一時障害、Visual Studio の不具合など、原因が幅広いのが厄介な点です。

画面に出やすい文言	よく起きる場面	意味合い（ざっくり）
An unexpected network error has occurred	関連付けウィザードの「Refresh」	Partner Center から一覧を取得できない
The app list cannot be refreshed / retrieved	予約名の一覧表示	取得 API の応答がエラー、または認証失敗
Microsoft Store is experiencing network issues	関連付け開始直後	ストア側サービス要因の可能性が上がる

結論：長期間続く／複数環境で再現するなら「既知の不具合」を疑う

まず結論から言うと、この事象は既知の不具合として扱われ、製品チームに報告済みとして案内されているケースがあります。そのため、個別 PC の設定をいじっても解決しないことが現実に起こりえます。

とくに次の条件に当てはまる場合は、環境要因よりもVisual Studio 側またはストア側の既知不具合（サービス障害を含む）の可能性が高まります。

発生から 2 週間以上、毎日試しても改善しない
別の PC／別ユーザー／別ネットワーク（テザリング等）でも同じ
Partner Center の Web 画面では普通にサインインでき、アプリも見えるのに、Visual Studio のウィザードだけ失敗する
コミュニティ（Developer Community / Q&A / SNS 等）で同時期の報告が増えている

この状況では、むやみに「再インストール」「キャッシュ削除」を繰り返すより、Microsoft Developer Community の該当チケットを探して投票・コメントし、修正（アップデート提供）を待ちつつ、迂回策で公開を進める方が、結果として最短になります。

原因の切り分け：ローカル要因か、製品／サービス要因か

以下の表は、実務でよく使う切り分け観点です。チェックの順番を固定すると、迷走しにくくなります。

確認ポイント	ローカル要因の可能性が高い	製品／サービス要因の可能性が高い
別ネットワーク（スマホテザリング等）	テザリングだと成功する	テザリングでも失敗する
別 PC（クリーン環境）	別 PC では成功する	別 PC でも失敗する
Partner Center（Web）へのサインイン	Web でもサインイン不能／表示が不安定	Web は正常だが VS だけ失敗
社内プロキシ／SSL 検査	社内 LAN のみ失敗、社外では成功	どこでも失敗、同時期報告多数
Visual Studio のアカウント状態	VS でサインイン自体が不安定	サインインはできるが「アプリ一覧取得」だけ失敗

10分でできるトラブルシューティング（まずここだけ）

「どっちが悪いのか」を短時間で見極めるための最小手順です。全部やる必要はなく、上から順にどこで挙動が変わるかだけ確認してください。

Partner Center 側が生きているかを先に確認する

ブラウザ（できれば Edge）で Partner Center にサインインする
対象アプリ（既存アプリ）や予約済みアプリ名が見えるか確認する
提出（Submission）画面が開けるか確認する

ここで Web 側も不安定なら、Visual Studio 以前にアカウントやサービス側の問題の可能性が高いので、先に Partner Center サポートや障害情報の確認が近道です。

Visual Studio のサインイン先アカウントを見直す

ストア公開は「Visual Studio にサインインしているアカウント」と「Partner Center の開発者アカウント」が一致している必要があります。複数アカウントを使い分けていると、意図しないアカウントで API を叩いて失敗することがあります。

Visual Studio の右上（アカウント）から、Partner Center の開発者アカウントが主アカウントとして有効になっているか確認
不要なアカウントを一度サインアウトしてから、開発者アカウントのみで再試行

サインイン方式を「埋め込み」→「システム」に切り替える

Visual Studio のオプションにあるサインイン方式（埋め込みブラウザー／システムブラウザー）の切り替えで改善する場合があります。社内プロキシやセキュリティ製品が絡む環境では特に有効です。

ツール → オプション → 環境 → アカウント → サインインオプション
埋め込みブラウザーを使っている場合は、システム（Windows）側の認証を使う設定に変更

プロキシ／VPN／SSL 検査の影響を確認する

社内ネットワークで「普段の Web は問題ないのに、特定の API だけ失敗する」場合は、WinHTTP プロキシや SSL 検査が原因になりがちです。まずは Windows が見ているプロキシ状態を確認します。

netsh winhttp show proxy

プロキシが設定されている場合：一時的にプロキシを外せる環境（テザリング等）で挙動が変わるか確認
SSL 検査が入る場合：企業の証明書配布や例外設定が必要になることがある（ただし、今回の症状が広範囲なら製品側要因の可能性も高い）

同じ手順を「別ネットワーク」で試す（最重要）

迷ったらこれです。スマホのテザリングなどで環境を切り替えて再試行し、結果が変わるかを見ます。

社内 LAN だけ失敗 → ローカル要因（プロキシ、FW、SSL 検査）の可能性が濃厚
どこでも失敗 → 既知不具合／サービス側要因を疑う

「既知の不具合」ルートに乗せる：Developer Community を軸に追跡する

同じエラーが長期間続き、しかも複数の開発者から報告されている場合は、Microsoft 側で不具合として追跡されていることがあります。この場合の基本方針はシンプルです。

Developer Community で cannot associate app with store や unexpected network error などのキーワード検索をする
該当チケットが見つかったら投票（Vote）し、自分の環境・発生日・VS バージョン・アプリ種別（UWP/WinUI/MSIX 等）をコメントする
更新通知を受け取れるようにフォローし、修正がリリースされたら Visual Studio を更新して再試行する

投票と再現情報が集まるほど、製品チーム側で優先順位が上がりやすくなります。逆に、各自がローカルで試行錯誤しても、根本がサービス側なら時間だけが失われます。

急ぎの場合の迂回策：Visual Studio の「ストア関連付け」に依存しない

ここからが実務で一番大事な部分です。「関連付けウィザードが壊れている」ことと「ストア公開ができない」ことは同義ではありません。状況に応じて、公開作業を前に進める選択肢があります。

Partner Center 側で手動アップロードする（王道の迂回）

Visual Studio のウィザードでストア連携ができなくても、パッケージ（.msix/.appx やバンドル）を作成して、Partner Center の提出画面でアップロードすれば公開作業は進められます。

アップロードに使われる拡張子（代表例）	特徴	おすすめ度
.msixupload / .appxupload	パッケージ＋シンボル等がまとまっており、ストア提出向け	高
.msixbundle / .appxbundle	複数アーキテクチャをまとめたバンドル。提出・配布の管理が楽	中
.msix / .appx	単体パッケージ。検証用途にも便利（ただし提出要件に注意）	中

注意点として、アプリの種類や提出条件によっては .msixupload/.appxupload が推奨（または必須に近い）になることがあります。とはいえ、まずは「パッケージ作成ができるか」を先に押さえるのがコツです。

プロジェクト種別ごとの「パッケージ作成」ポイント

迂回策を選ぶには、まず自分のプロジェクトがどの系統かを整理しておくと迷いません。

プロジェクト例	提出の実体	パッケージ ID を設定する場所	関連付けが壊れたときの現実解
UWP	AppX / MSIX	Package.appxmanifest（Identity）	パッケージ作成 → Partner Center 手動アップロード
WinUI 3（パッケージ化）	MSIX（.wapproj 経由）	Package.appxmanifest ＋ Package.StoreAssociation.xml	StoreAssociation を手動で用意 → パッケージ作成
WPF/WinForms + MSIX Packaging	MSIX（デスクトップアプリ）	Packaging Project（.wapproj）側	ウィザードに頼らずビルド成果物を作る
.NET MAUI（Windows）	MSIX（構成による）	プロジェクト設定＋マニフェスト	まずは Store 以外でパッケージ生成可否を確認

「手動で関連付け」を行い、パッケージ作成だけ通す（StoreAssociation.xml を用意する）

WinUI 3（Windows App SDK）やデスクトップアプリを MSIX 化している場合、Windows Application Packaging Project（.wapproj）を使っているケースが多いです。この構成では、ストア関連付けに成功するとプロジェクト内に Package.StoreAssociation.xml が生成されます。

ウィザードが失敗して生成されない場合でも、既に公開できた別アプリの StoreAssociation ファイルを流用して必要箇所を差し替える、あるいは Partner Center の情報をもとに必要な値を埋めた XML を用意することで、パッケージ作成だけ通せることがあります。

手動関連付けの手順（例）

Package.StoreAssociation.xml を用意する
- 過去に関連付けに成功したプロジェクトがあるなら、その XML をベースに流用しやすい
- 流用する場合は、少なくとも MainPackageIdentityName / ReservedName / PackageInfoList / LandingUrl など、アプリ固有になりやすい項目を Partner Center の値に合わせて更新
- 流用元がない場合は、Publisher / PublisherDisplayName / DeveloperAccountType など、提出に必要な最小情報を埋める
Package.appxmanifest の Identity を Partner Center と一致させる
- Identity の Name（パッケージ名）
- Identity の Publisher（例：CN=…）
Package.StoreAssociation.xml を .wapproj に追加し、ビルド対象に含める
Visual Studio で アプリパッケージの作成を実行し、生成物を取得（→ Partner Center へアップロード）

XML の構造はプロジェクトによって異なるため、そのままコピペできる「万能テンプレ」はありませんが、目安としては次のような情報が入っています（値は例）。

&lt;StoreAssociation&gt;
  &lt;ReservedName&gt;YourReservedAppName&lt;/ReservedName&gt;
  &lt;MainPackageIdentityName&gt;YourCompany.YourApp&lt;/MainPackageIdentityName&gt;
  &lt;Publisher&gt;CN=12345678-ABCD-....&lt;/Publisher&gt;
  ...
&lt;/StoreAssociation&gt;

作業対象	ファイル	やること	つまずきポイント
ストア関連付け情報	Package.StoreAssociation.xml	ReservedName / IdentityName 等を Partner Center と一致させる	別アプリの値が残ると提出時に不整合
パッケージ ID	Package.appxmanifest	Publisher / Name を Partner Center と一致させる	Publisher が違うとストア側で弾かれる
ビルドへの組み込み	〜.wapproj	StoreAssociation.xml をプロジェクトに追加してビルド対象にする	追加しても参照されない設定だと効果なし

手動編集はミスが起きやすいので、必ずバックアップを取り、差分が追える形（ソース管理のブランチ等）で作業するのが安全です。また、修正版の Visual Studio が出たタイミングで正式な関連付けに戻す運用が推奨です。

CI/CD で「パッケージ作成だけ」自動化する

もし公開作業が頻繁で、今回のように IDE のウィザードに左右されたくないなら、ビルドをパイプライン化してしまうのも有効です。やることは単純で、

MSBuild で Release ビルド
MSIX/AppX のパッケージ作成（バンドル作成）
生成物を成果物として保存し、Partner Center に手動アップロード

という流れに固定します。これにより、ストア関連付けウィザードが不調でも「ビルド成果物を作る」部分は安定します。

ログ取得：サポートやチケットに添えると話が早い

自分の環境が原因かどうかを判断するうえでも、チケットのコメントで再現性を伝えるうえでも、ログは強い武器です。特に、企業ネットワーク配下では「何がブロックされたか」を示せると解決が早まります。

Visual Studio の ActivityLog を出す

devenv /log

上記で起動して再現し、生成された ActivityLog.xml を確認します。エラーが「認証」「通信」「例外」のどれ寄りかのヒントが得られることがあります。

いつ、どの画面で、どのアカウントで失敗したかをメモする

発生日時（タイムゾーン込み）
Visual Studio のバージョン（例：17.xx.x）
Windows のバージョン（Windows 10/11 のビルド）
プロジェクト種別（UWP / WinUI 3 / WPF + MSIX / MAUI など）
ストアの操作（新規予約名の取得／既存アプリ一覧取得／パッケージ作成）

この情報が揃っていると、コミュニティでも「同じ症状かどうか」の判別がしやすくなります。

よくある質問

Visual Studio の再インストールは効果がありますか？

ローカル要因（キャッシュ破損、拡張機能、認証情報の不整合）が原因なら効果が出ることもあります。ただし、複数環境で同時期に発生している場合は、再インストールしても再現することが多いです。切り分けとしては「別ネットワーク／別 PC」テストの方が短時間で結論に近づけます。

Partner Center にアップロードするパッケージはどれが安全ですか？

基本は .msixupload/.appxupload が無難です。生成できない場合は .msixbundle/.appxbundle を試す余地がありますが、アプリ種別によっては提出処理で追加エラーが出ることもあります。まずは「同じ ID（Name/Publisher）で署名・バージョン管理できているか」を優先してください。

手動で StoreAssociation.xml を作るのは危険では？

手動編集は確かにミスが起きやすいですが、急ぎの公開を止めないための現実的な手段になることがあります。ポイントは「Partner Center と一致させる」ことと、「一時しのぎである」ことを前提に、修正版が出たら正攻法に戻す運用にすることです。

まとめ：まずは切り分け、長期化ならチケット追跡＋迂回で前進

「An unexpected network error has occurred」はメッセージが曖昧なぶん、闇雲に試すほど消耗しやすいトラブルです。短時間で切り分けを行い、既知不具合の線が濃ければ Developer Community のチケットを追跡しつつ、Partner Center への手動アップロードや手動関連付けで公開作業を止めない――この二段構えが、最も実務的で安全です。

この記事を書いた人

佐藤健司

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