Microsoft Store エラー0x8007000Aでアプリをインストールできない原因と直し方（Windows 11 24H2）

Microsoft Storeでアプリを入れようとすると毎回「0x8007000A」が出て失敗し、PowerShellのGet-AppxPackageでも同じエラーになる──しかもwinget（App Installer）まで消えてしまった。sfc/DISMやwsreset、トラブルシューティング、さらにはクリーンインストールでも直らない。そんな“詰み”状態でも、原因を切り分けて「ユーザープロファイル再生成」に踏み込むと一気に復旧することがあります。

今回の症状：Microsoft Storeが何をしても0x8007000Aで失敗する

本記事が想定する状況は次のようなものです。

• Microsoft Storeでどのアプリでもインストール不可（エラー0x8007000A）
• PowerShellでGet-AppxPackageを実行しても同じエラー
• wingetが使えない／App Installer自体が消えた
• sfc / DISM、wsreset.exe、ウイルス対策無効化、Storeトラブルシューティング、修復インストール（失敗）、クリーンインストールまで試しても改善しない
• Windows 11 24H2（OS ビルド 26100.4770）

結論：ユーザープロファイル破損が濃厚。対処は「プロファイル再生成」が最短ルート

この手のケースで最も重要なのは、OS全体の問題か、アカウント（ユーザー）固有の問題かを切り分けることです。別のローカル管理者アカウントではStoreが正常に動くなら、かなりの確度でユーザープロファイル側の破損に寄ります。

確認項目	結果	読み取れること
別のローカル管理者でStoreが動くか	動く	OS全体ではなくアカウント固有（プロファイル起因が濃厚）
同じユーザーだけ0x8007000Aが出るか	出る	Store/UWPの構成、認証トークン、資格情報などがユーザー範囲で破損している可能性
sfc / DISM / wsresetで改善するか	しない	Store本体やシステムファイルというより、ユーザー配下の状態が怪しい

0x8007000Aとは？「環境が正しくありません」がStoreで出る典型パターン

0x8007000Aは、Win32の意味合いで言うと「環境が正しくありません」系のエラーとして扱われます。Microsoft Storeは、ユーザーごとに多くの状態を持っています。例えば以下のような要素です。

• Microsoft Store/UWPアプリのユーザー別キャッシュ
• ライセンスや認証に関わるユーザー別コンポーネント（トークン、Broker系）
• UWP（Appx）の登録情報とユーザー環境の紐づき

このどこかが崩れると、StoreだけでなくPowerShellのAppx操作（Get-AppxPackageなど）も一緒に不調になりやすく、さらにApp Installerが消える・壊れるとwingetまで巻き込まれて「復旧に使う道具がない」状態になりがちです。

まずやるべき切り分け：別アカウントで動くか確認する

ここを飛ばすと、遠回りになります。すでに心当たりがある場合でも、判断材料として残しておくと後の作業がスムーズです。

別の管理者アカウントでStoreを試す

1. 別のローカル管理者アカウントでサインイン（なければ一時的に作成）
2. Microsoft Storeを開き、適当な無料アプリでインストールを実行
3. エラー0x8007000Aが出るか確認

ここで正常なら、最短の解決策は次の章の「プロファイル再生成」です。逆に、どのアカウントでもダメなら、ネットワーク制限・ポリシー・証明書・時刻同期・セキュリティ製品・企業管理（Intune等）など、マシン全体側の疑いが強くなります（ただし今回の前提は「別アカウントでは正常」で、アカウント固有の問題を狙います）。

一般的な対処が効かない理由：ユーザー配下が壊れていると“正常化コマンド”が空振りする

Store不調でよく案内される手段は、たしかに多くのケースで有効です。しかし、ユーザープロファイルが壊れていると、いくらシステムを修復しても「壊れたユーザー環境」に戻った瞬間に再発します。

よくある対処	狙い	プロファイル破損時に効きにくい原因
sfc /scannow	システムファイル修復	ユーザー配下（AppData等）の破損は基本的に対象外
DISM /RestoreHealth	コンポーネントストア修復	OS側が健全でも、ユーザー状態が壊れていればStoreは失敗する
wsreset.exe	Storeキャッシュ初期化	キャッシュだけでなく、登録情報・トークン・ユーザー構成が壊れていると戻らない
トラブルシューティング	典型問題の自動修正	深い破損（プロファイルや資格情報の崩壊）は直せないことがある
修復インストール	OS上書き修復	ユーザー環境を引き継ぐため、壊れた状態も一緒に残り得る

本命対処：ユーザープロファイルを再生成してStoreを復旧させる

ここからが核心です。問題ユーザーのプロファイルを作り直すことで、StoreとUWP周りが“新品の状態”に戻り、0x8007000Aが解消することがあります。

作業前の注意（大事）

• 必ず対象ユーザーからサインアウトした状態で実施します。
• 作業は別の管理者アカウントで行います。
• ユーザーフォルダーを触るため、途中で中断しないのが安全です。
• BitLockerや企業管理端末の場合は、社内手順・管理ポリシーの影響を考慮してください。

方法A：ユーザーフォルダーを.oldにリネームして“自動再生成”させる（手早く確実）

実例でもこれで復旧しています。Windowsは、ログオン時に既存プロファイルが見つからない（または使えない）場合、新しいユーザープロファイルを自動作成します。その挙動を利用します。

1. 別の管理者アカウントでサインイン
2. エクスプローラーで C:\Users\ を開く
3. 問題のユーザーフォルダーを探す（例：C:\Users\Taro）
4. フォルダー名を Taro.old のようにリネーム
5. その後、元のアカウントでサインイン
6. 新しいユーザープロファイルが作成されたら、Microsoft Storeを起動して動作確認

リネームだけでうまく新規作成に進まない場合は、次の「補強手順」を追加すると成功率が上がります。

方法Aの補強：プロファイル参照をクリーンにする（うまくいかない時だけ）

リネームしても古いパス参照を掴んでしまったり、一時プロファイルになったりする場合があります。その場合は、Windowsが参照するプロファイル情報を整理します。

• 設定 → アカウント → その他のユーザー（環境により表記は近い項目）で、対象ユーザーをいったん削除（ローカルアカウントの場合）
• または、システムの詳細設定 → ユーザープロファイルから該当プロファイルを削除できる場合は削除
• それでもダメなら、レジストリの HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList にある該当SIDの ProfileImagePath が古いパスを指していないか確認（編集は慎重に）

レジストリ編集は環境によって事故要因にもなるため、基本はリネーム→再サインインで進め、どうしても詰まる時だけ上級手段として検討してください。

方法B：新規ユーザーを作って“乗り換える”（よりクリーンで再発しにくい）

「旧プロファイルに触れたくない」「サインイン後の挙動が不安定」という場合は、新しいローカル管理者（または標準）ユーザーを作って、そちらに移行するのが堅実です。手順は単純で、結果が安定しやすいのがメリットです。

1. 別アカウント（管理者）で、新しいユーザーを追加
2. 新ユーザーでサインインして初期設定を完了
3. Microsoft Storeが正常に使えるか確認
4. 問題なければ、新ユーザーへデータ移行して旧ユーザーは整理

データ移行のコツ：コピーしすぎると“不具合も移る”

プロファイル再生成で最もやりがちなのが、旧プロファイルのAppDataを丸ごと戻してしまい、壊れた状態まで復元して再発するパターンです。安全に移行する目安を表にまとめます。

移行対象	おすすめ度	理由・注意点
デスクトップ／ドキュメント／ピクチャ／ダウンロード	高	ユーザーデータ中心で安全。まずここを移すだけでも業務復帰できることが多い
ブラウザのプロファイル（Chrome/Edgeのユーザーデータ）	中	アカウント同期で戻せるなら同期推奨。フォルダーコピーは拡張機能の不具合も一緒に移る可能性
.ssh／開発用鍵／設定ファイル	中	必要なら移行。ただし権限（ACL）が崩れると動かないことがあるためコピー後に動作確認
AppData\Roaming	低〜中	アプリ設定が多い。必要なアプリの必要なフォルダーだけを選んで移すのが安全
AppData\Local\Packages（UWP関連）	低	Store/UWPの状態そのもの。ここを戻すと0x8007000Aが再発することがある

データコピーは、エクスプローラーでも良いですが、量が多い場合はrobocopyが安定します。

robocopy "C:\Users\Taro.old\Documents" "C:\Users\Taro\Documents" /E /COPY:DAT /R:1 /W:1
robocopy "C:\Users\Taro.old\Desktop"   "C:\Users\Taro\Desktop"   /E /COPY:DAT /R:1 /W:1
robocopy "C:\Users\Taro.old\Pictures"  "C:\Users\Taro\Pictures"  /E /COPY:DAT /R:1 /W:1

/COPY:DATにしているのは、ACL（権限）まで持ってきて思わぬアクセス問題を起こすのを避けるためです。部署PCなどで厳密に権限を維持する必要があるなら、要件に合わせて調整してください。

プロファイル再生成後にやること：Store更新とApp Installer（winget）の復旧

Storeの更新を一括で当てる

1. Microsoft Storeを開く
2. ライブラリを開く
3. 更新を取得を実行して、更新が落ち着くまで待つ

Store自体や依存コンポーネントが古いままだと、症状が不安定に見えることがあります。まずはライブラリで更新を揃えるのが定石です。

App Installer（winget）を入れ直す

新プロファイルでStoreが動けば、App Installerは次の流れで戻せます。

1. Microsoft Storeで「App Installer」を検索
2. インストール
3. ターミナル（PowerShell）でwinget -vなどを実行して確認

「Storeは動くのにApp Installerが検索に出ない／インストールができない」場合は、Storeの更新が完了していない、もしくは組織ポリシーで制限されている可能性があります。まずはライブラリ更新を完走させ、それでもダメなら管理者（情シス）側の制限も疑ってください。

補助策：衝突要因を潰して“再発”を防ぐ

プロファイル再生成で直ったとしても、同じ原因（常駐の干渉や強制クリーナーなど）が残っていると再発することがあります。次の対策は、復旧後の安定化に効きます。

クリーンブートで常駐干渉を切り分ける

1. msconfig（システム構成）を開く
2. サービスタブで「Microsoft のサービスをすべて隠す」にチェック
3. すべて無効
4. スタートアップはタスクマネージャー側で不要項目を無効化
5. 再起動してStoreの挙動を確認

これで改善が出るなら、セキュリティ・ネットワーク・最適化（クリーナー）系の常駐がStoreの動作に影響している可能性があります。復旧後に常駐を戻すときは、段階的に有効化して犯人を特定すると再発防止になります。

時刻・地域の整合（念のための“地味に効く”ポイント）

• 時刻の自動設定：オン
• タイムゾーンの自動設定：オン
• 地域設定：日本／米国などにいったん切り替えて戻す

Storeは証明書や署名検証、トークン期限など時刻に敏感です。大きくずれていなくても、同期が不安定な環境では手当てしておく価値があります。

Storeの再登録（やるなら新プロファイル上で）

旧プロファイルが壊れていると再登録系は失敗しがちです。再生成後の環境で、必要な場合のみ行います。

PowerShell（管理者）で例：
Get-AppxPackage -AllUsers Microsoft.WindowsStore | Foreach {
  Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"
}

実行可否や成功/失敗は環境によって差が大きいので、「再生成後もStoreが不安定」「特定のUWPだけ壊れている」といった場合の選択肢として覚えておく程度でOKです。

クリーンインストールでも直らないのに、プロファイル再生成で直るのはなぜ？

直感に反しますが、現場ではよくあります。理由はシンプルで、Store周りの不具合は“OSの破損”よりも“ユーザー状態の破損”が原因になっていることがあるからです。

• クリーンインストール後、同じMicrosoft アカウントでサインインし、設定同期や復元で壊れた状態の一部が戻ることがある
• バックアップからAppDataを広く戻す運用だと、Store/UWPの不調要素まで復元しやすい
• OSは健全でも、ユーザーのトークン・資格情報・UWP登録の整合が崩れているとStoreが失敗する

だからこそ、「別アカウントでは正常」という情報が取れた時点で、延々とOS修復を繰り返すよりプロファイル再生成に寄せるのが合理的です。

再発防止：やってはいけないこと／やっておくと安心なこと

やってはいけない（または慎重に）	理由
クリーナー系ツールでAppData配下を強制削除	Store/UWPの状態やトークン類が壊れやすい
C:\Program Files\WindowsApps周辺の手動削除	権限が特殊で、削除・改変が高確率で破綻につながる
セキュリティ/ネットワーク常駐を無制限に増やす	通信・証明書・プロキシ・フィルタリングがStoreの認証に干渉する場合がある

やっておくと安心	効果
非常用のローカル管理者アカウントを1つ用意	今回のような“ログオンして直す”系の復旧がすぐできる
サインイン直後にStoreのライブラリ更新を揃える	Store関連を最新化して不整合を減らす
データ移行はユーザーデータ中心、AppDataは最小限	不具合の持ち込みを避けやすい

すぐ試せる最小手順（この順でやると迷いにくい）

1. 別の管理者アカウントでサインインして、Storeが動くか確認
2. 動くなら、問題ユーザーをサインアウトした状態でC:\Users\<ユーザー名>を.oldにリネーム
3. 元のアカウントでサインインして新プロファイルを自動作成
4. .oldからデスクトップ／ドキュメントなど必要データだけ戻す
5. Storeのライブラリ → 更新を取得で更新を揃える
6. 必要ならStoreでApp Installerを入れてwingetを復旧

よくある質問

ユーザーフォルダーをリネームすると、データは消えますか？

リネームは削除ではないため、基本的にデータ自体は残ります。Taro.oldのように別名で残るので、必要なものを新プロファイルへコピーできます。ただし、OneDrive連携や暗号化、アプリのライセンス状態などコピーでは戻らないものもあるため、重要データは個別に確認してください。

AppDataはどこまで戻していいですか？

まずは戻さないのが安全です。アプリ設定がどうしても必要な場合は、該当アプリのフォルダーだけを選別して戻し、戻すたびにStoreやUWPの挙動が正常なままか確認してください。特にAppData\Local\Packagesを戻すのは、再発の引き金になりやすいので避けるのが無難です。

企業PCで「別アカウント作成」ができません

組織ポリシー（GPO/Intune）で制限されている可能性があります。その場合、プロファイル再生成は情シス側の手順が必要になることがあります。切り分け結果（別アカウントで正常／対象ユーザーだけNG、0x8007000A、Get-AppxPackageも失敗、App Installer不在）をまとめて相談すると話が早いです。

まとめ：0x8007000Aは“OS修復”より“プロファイル再生成”が効くことがある

Microsoft Storeのエラー0x8007000Aが、sfc/DISMやwsreset、トラブルシューティング、果てはクリーンインストールでも直らないとき、原因がOSではなくユーザープロファイルの破損にあるケースがあります。別アカウントでStoreが動くなら、その可能性はさらに上がります。

解決のポイントは、問題のユーザーフォルダーを.oldへリネームして新しいプロファイルを再生成し、データは必要最小限を移行すること。復旧後はライブラリ更新を揃え、App Installerを入れ直せばwingetも戻せます。最短距離で復旧したいなら、切り分け→プロファイル再生成の流れを軸に進めてください。