Claude Desktopが0x80070057で起動しない — MSIX版とChromeフォルダのジャンクション

Windows版Claude Desktop(MSIX)が「The parameter is incorrect」のダイアログで起動しなくなる報告が、2026年9月30日にGitHubのissue #98328に集まりました。再インストールもRepairも効かない症状です。報告者たちが突き止めた原因は、%LOCALAPPDATA%\Google かその一つ下の Chrome がジャンクション(別ドライブへのフォルダ転送)になっていることでした。

先に確かめる点は2つです。

• イベントビューアーの Microsoft-Windows-AppModel-Runtime/Admin にID 216と208が並び、どちらも 0x80070057 か
• %LOCALAPPDATA%\Google から Chrome\User Data までのどこかがジャンクションかシンボリックリンクか

両方に当てはまるなら、ジャンクションを一時的にリネームするだけで起動するという報告が複数あります。

症状はどう見えるか

起動すると、Claude.exe のパスを添えた「The parameter is incorrect.」のダイアログが出ます。issueでは次の点が報告されています。

• Claudeのログには新しい行が一行も増えない(プロセスが始まる前に失敗する)
• 同じ端末でWindows Terminalや電卓、メモ帳など他のパッケージアプリは起動できる
• 発生はClaude 2.16120.0.0(MSIX)への自動更新後で、直前のバージョンは同じ環境で動いていた

ログが増えない点は、原因調査で迷う大きな要因です。報告者は、ログの出力先がいつの間にか %LOCALAPPDATA%\Claude\logs に移り、旧来の LocalCache\Roaming\Claude\logs が更新されなくなっていたことも指摘しています。古い方を見て「何も出ていない」と判断しないよう、両方を確認してください。

0x80070020とはイベントIDが違う

Claude Desktopの起動失敗で最も知られるのは 0x80070020 です。見た目はどちらも「起動しない」ですが、原因も直し方も別物です。

0x80070020側の原因と直し方はClaude Desktopが起動しない0x80070020エラーの原因と対処法にあります。issueの報告者も、0x80070020の事例は再起動か再インストールで直ったが今回は違う、と書き分けています。

原因はマニフェストの除外ディレクトリ

ClaudeのMSIXマニフェスト(2.16120)には、ファイルシステムの書き込み仮想化から外すディレクトリが5つ書かれています。issueが引用している該当部分は次のとおりです。

<virtualization:FileSystemWriteVirtualization>
  <virtualization:ExcludedDirectories>
    <virtualization:ExcludedDirectory>$(KnownFolder:LocalAppData)\Microsoft\Office\16.0\WEF</virtualization:ExcludedDirectory>
    <virtualization:ExcludedDirectory>$(KnownFolder:LocalAppData)\Google\Chrome\User Data</virtualization:ExcludedDirectory>
    <virtualization:ExcludedDirectory>$(KnownFolder:LocalAppData)\Claude-3p</virtualization:ExcludedDirectory>
    <virtualization:ExcludedDirectory>$(KnownFolder:LocalAppData)\Claude-Data</virtualization:ExcludedDirectory>
    <virtualization:ExcludedDirectory>$(KnownFolder:LocalAppData)\Claude\logs</virtualization:ExcludedDirectory>
  </virtualization:ExcludedDirectories>
</virtualization:FileSystemWriteVirtualization>

Microsoftのスキーマ文書では、ExcludedDirectory は $(KnownFolder:...) で始まる文字列で、ファイルシステム仮想化から除外するディレクトリを指定する要素です。この要素の利用には unvirtualizedResources 制限付き機能が必要と書かれています。

この5つのうち、他人が管理するフォルダーは Google\Chrome\User Data だけです。報告者は、このパスがジャンクションを通るとWindowsがDesktop AppXコンテナの作成に失敗する、と整理しています。Windows側の内部動作まではissueに書かれていません。確認された事実は、ジャンクションを外すと起動することです。

どこがジャンクションだと起動しないか

issueとコメントで確認された配置は4件です。

注意したいのは報告者Bのような「一段深い」配置です。このコメントの本人は、最初 fsutil reparsepoint query で Google\Chrome\User Data を調べて「リパースポイントではない」と判断しました。その後 Google\Chrome 自体を調べ直し、そこがジャンクションだったと訂正しています。User Data だけを見て安心せず、Google と Chrome を上から順に確認する必要があります。

自分の環境で確かめる手順

PowerShellで、除外ディレクトリに至る各階層の種類を確認します。LinkType に Junction か SymbolicLink が出た階層が候補です。

$base = "$env:LOCALAPPDATA\Google"
$chrome = "$base\Chrome"
$ud = "$chrome\User Data"
Get-Item $base, $chrome, $ud -ErrorAction SilentlyContinue |
  Select-Object FullName, LinkType, Target

コマンドプロンプトなら fsutil reparsepoint query でも調べられます。階層ごとに実行します。

fsutil reparsepoint query "%LOCALAPPDATA%\Google"
fsutil reparsepoint query "%LOCALAPPDATA%\Google\Chrome"
fsutil reparsepoint query "%LOCALAPPDATA%\Google\Chrome\User Data"

fsutil が User Data をリパースポイントでないと返しても、PowerShellでは同じパスに Target が出ることがあります。3行とも実行して結果を見比べてください。

自分のClaudeがMSIX版かどうかは、次のコマンドで見分けられます。issueのコメントは、同じコマンドでMSIX版を削除してからwinget版を入れ直しています。パッケージが表示されればMSIX版として入っていると読めます。ワイルドカードの * は省かずに入力してください。

Get-AppxPackage *Claude*

イベントログでID 216と208を拾うには、次のようにします。

Get-WinEvent -LogName "Microsoft-Windows-AppModel-Runtime/Admin" -MaxEvents 50 |
  Where-Object { $_.Id -in 208, 216 } |
  Select-Object TimeCreated, Id, Message

メッセージ末尾に 0x80070057 と configuring runtime が出ていれば、本記事の症状です。converting the job なら0x80070020側を見てください。

対処: 3つの選択肢

ジャンクションをいったん外す

起票者と別の報告者Aは、ジャンクションのリネームで即座に起動したと報告しています。起票者の手順は次のとおりです。

ren "%LOCALAPPDATA%\Google" Google_bak

起動を確認できたら、起票者は恒久策としてジャンクションを廃し、Chrome のデータを実フォルダーとして %LOCALAPPDATA%\Google に戻しました。ClaudeとChromeの両方が動いたとのことです。流れは次のとおりです。

issueに書かれているのは「ジャンクションを外し、Chrome のデータを実フォルダーへコピーした」までで、コピー方法や所要時間の記載はありません。Chromeのプロファイルは大きくなりやすいので、戻し先のドライブに空きがあるかは事前に見ておくと安心です。別の報告者Aは確認後にジャンクションを元に戻し、元の状態に復元しています。ただし元に戻すと、同じ配置に戻るため再発する可能性が高いと見られます。リネームは切り分け用の一時策と見てください。

非MSIX版(winget)に切り替える

報告者Bのうち一人は、MSIXを削除して winget install Anthropic.Claude で入れ直し、ジャンクションに触れずに動いたと書いています。別のコメントでも同じ方法が試され、インストーラーの種類は exe、配布元は downloads.claude.ai(wingetマニフェスト1.44121.2)でした。インストール後に自動更新され、失敗していたMSIXと同じ2.16120.0になったが、そのまま起動できたという内容です。

つまり、アプリ本体のバージョンは同じで、MSIXというパッケージ形式の仕組みを通ったときだけ失敗しています。

Get-AppxPackage *Claude* | Remove-AppxPackage
winget install Anthropic.Claude

MSIXを消す前に、会社のポリシーを確認してください。Team・Enterpriseの一括配布ではMSIXが公式の配布形式で、per-user配布やIntuneの扱いに条件があります。詳細はClaude Desktop MSIXをWindowsへ一括導入する手順にあります。管理端末では、差し替える前に管理者へ確認するのが無難です。

効かなかったこと

以下はissueで「効果なし」と報告されています。時間を使う前の目安にしてください。

• explorer.exe shell:AppsFolder\Claude_pzs8sxrjxfjjc!Claude からの起動
• 設定アプリのRepairとReset
• %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\SystemAppData\Helium のリネーム
• 通常の再起動
• Remove-AppxPackage から再起動、クリーン再インストール(最初の起動の段階で失敗するため)
• sfc /scannow と DISM /RestoreHealth

ログに出る別のエラーは原因ではない

起動を試みるたびに、CoworkVMService: failed to configure/disarm SCM recovery actions ... Access is denied という行が記録されます。起票者はこれを「無関係なノイズ」としており、別のissueでサービスの権限設定による既知の挙動だと整理しています。CoworkのVMサービス側の起動失敗は別の原因で、Claude DesktopがCoworkVMServiceで起動しない原因と対処法で扱っています。

修正されたかどうか

issueは2026年9月30日にクローズされました。ただしスレッド上にAnthropic側のコメントはなく、修正バージョンの記載もありません。ジャンクション環境が直ったと断定できる材料は、issueからは得られません。

起票者が出していた要望は3つです。

1. サードパーティのブラウザフォルダーをマニフェストの除外に入れない、またはリパースポイントを許容する
2. AppModel-Runtimeの216と0x80070057を検知して、意味の分かるメッセージを出す
3. MSIX以外のインストーラーを用意する

3つ目は、MSIX版しかない状況への不満として別のissue(#93008)でも挙がっています。

自動更新で突然起きる点が厄介

今回の症状は、設定を変えていない端末で自動更新を境に起きています。別の報告者が引用したログでは、アイドルタイムアウト後に「stealth update」が走り、2026年9月29日の22時台に新バージョンへ切り替わっていました。報告者はそれ以降、起動のたびに失敗しています。

数年前から使っているジャンクションが、更新後に急に問題化した形です。容量の小さいシステムSSDの節約で AppData 配下を別ドライブへ逃がすのは広く行われています。更新後にClaude Desktopだけが開かなくなったときは、Claude側の再インストールを繰り返す前に、%LOCALAPPDATA% 直下のリンクを一覧するのが近道です。

Get-ChildItem $env:LOCALAPPDATA -Force |
  Where-Object { $_.LinkType } |
  Select-Object Name, LinkType, Target

Google や Chrome が一覧に出てきたら、前節の手順で User Data までの階層を確かめてください。