目次

Claude Desktop（Windows）を更新した直後にアプリを起動しようとすると、「このファイルはほかのプログラムで使われています」というダイアログが出て起動できない——そしてPCを再起動するまで直らない。この症状は、Microsoft Store 形式（MSIX）版のClaude Desktopで報告されている既知の不具合だ（GitHub #53247 ほか）。

本記事の結論を先に言う。PCの完全再起動は必ずしも必要ない。Windowsを一度サインアウト→サインインするだけで復旧できる場合が多い（PC再起動やClaudeのログアウトではない）。以下、すぐ効く手／効かない手／エラーの本当の正体を、確定・推定・未確定を分けて整理する。この記事はWindows 11 Home（10.0.26200）実機1台での調査ログと、GitHub上の既知issueを突き合わせた内容だ。

⚠️ この記事の確度ラベル：✅確定＝実機ログ or issueで直接確認／🟡推定＝状況証拠からの解釈／🔴未確定＝判断できていない。「原因＝ファイルロック」など、断定できないものは断定しない。

0x80070020 · APPMODEL-RUNTIME 215 / 208

まず試すべき復旧の順番

① Windowsをサインアウト→サインイン
スタート→ユーザーアイコン→「サインアウト」。最速でPC全体の再起動は不要な場合あり（#53247）
② PCを再起動
確実だが重い。①で戻らない時に
③ Squirrel版へ乗り換え
再発を断つ恒久策（#57221 報告者）

1. 結論——まずWindowsのサインアウトで復旧する

この不具合の実害は「起動できない」ことだが、復旧に必ずしもPCの完全再起動は要らない。#53247 の分析によれば、問題の原因となる「孤立したハンドル」はWindowsのユーザーセッション単位で残るため、Windowsを一度サインアウトして入り直すだけでクリアされる。多くの人は反射的にPCを再起動しているはずで、そのぶん時間を短縮できる。

「サインアウト」＝Windowsの話。PC再起動やClaudeのログアウトではない

ここで言うサインアウトは Windowsのユーザーアカウントからのサインアウト（スタート → 左下のユーザーアイコン → 「サインアウト」）のこと。開いているアプリは一旦閉じられるが、PCの電源は切れず、起動より速い。Claudeアプリ／アカウントのログアウトでも、アプリの再起動でもない——それらでは直らない。

  • ✅ すぐ直したい：サインアウト（ログオフ）→ サインイン。これで起動できるようになるケースが報告されている（#53247）。
  • ✅ 確実に直したい：PCを再起動。重いが確実。
  • ✅ 再発を止めたい：MSIX版をやめてSquirrel版（インストーラ版）へ乗り換え（後述・#57221 報告者の手順）。

2. 症状——更新後、起動しようとすると出る

典型的な流れはこうだ。Claude Desktopの更新が適用された後、アプリを開こうとすると、Windowsのエクスプローラ風ダイアログで「このファイルはほかのプログラムで使われています」が表示され、起動しない。閉じて再度開いても同じで、PC再起動（またはログオフ）まで復旧しない。

ここが重要だが、このダイアログの文言は実態を正確に表していない（詳細は§4）。また、更新そのものは成功している——失敗しているのは更新ではなく「アプリの起動」だ。対象はMicrosoft Store 形式（MSIX）版のClaude Desktopである。

3. 対処——効く手／効かない手

ここが一番の事故ポイントだ。ネット上には「サービスを止めれば直る」といった情報があるが、この不具合では効かないと報告されている。効く手と効かない手をはっきり分ける。

✅ 効く（報告あり）
  • Windowsのサインアウト→サインイン（最速・PC再起動不要な場合あり）
  • PCの再起動（確実）
  • Squirrel版へ乗り換え（恒久・再発防止）
🔴 効かないと報告（推奨しない）
  • Stop-Service CoworkVMService（再起動して再発）
  • taskkill で Claude/Cowork 関連を全終了
  • Reset-AppxPackage / Add-AppxPackage -Register
  • AppXSvc・ClipSVC・vmcompute 等の各サービス再起動

右側の手段は #48003 と #53247 の両方で試されて失敗したと記録されている。時間の無駄になりやすいので、まずログオフを試すのが合理的だ。

恒久策：Squirrel版（インストーラ版）へ乗り換える

更新のたびに踏むのが耐えられない場合、#57221 の報告者はMSIX版をアンインストールし、インストーラ（Squirrel）版に切り替えることで、更新・起動の両方の問題が解消したとしている。手順の要旨：

  1. Store（MSIX）版のClaude Desktopを完全にアンインストール。
  2. Claude公式のダウンロード、または winget（例：winget install Anthropic.Claude）でインストーラ版を導入。
  3. その後は自動更新で最新版まで上がる。

🟡 理屈としては、C:\Program Files\WindowsApps 配下とAppXコンテナ層の制約から外れるため、と説明されている。環境によって挙動は変わりうるので、乗り換え前に用途（企業配布ポリシー等）を確認したい。

4. エラーの正体——ファイルロックではない（確定）

ダイアログは「ファイルが使われています」と読めるが、実機ログで見ると失敗箇所は別だ。イベントログ Microsoft-Windows-AppModel-Runtime/Admin に、次が記録される（✅実機で確認）。

イベント ID 215:
0x80070020: Cannot create the Desktop AppX container for package
            Claude_..._x64__pzs8sxrjxfjjc
            because an error was encountered converting the job.

イベント ID 208:
0x80070020: Cannot create the process for package ... [LaunchProcess]
要素意味
0x80070020ERROR_SHARING_VIOLATION。Windowsが「別のプロセスが使用中」と一般的に文言化するコード。ダイアログの正体はこれ。
[LaunchProcess]起動の失敗であって更新の失敗ではない（更新は成功済み）。
失敗箇所Desktop AppXコンテナの生成——具体的には Job Object を Silo に変換する段階。

そして✅「ファイルロックは存在しない」ことが検証で確認されている。#53247 では handle.exe と Process Explorer で調べ、ユーザー空間のファイルロックが無いことが示された。つまり「他プログラムがファイルを掴んでいるから」という説明は、少なくともユーザー空間のロックとしては誤りだ。実体はAppX/Desktop Bridgeのコンテナ層（Job/Silo）の問題である。

5. 原因は2説あり、未決着

「コンテナ層の問題」までは確定だが、その引き金については見解が2つあり、まだ決着していない。断定を避け、両論を併記する。

説A：サービスがJob Objectを占有（#57221）

パッケージ同梱の CoworkVMService（SYSTEM権限・自動起動）がパッケージのJob Objectを握り、新パッケージのコンテナ生成を妨げる、という説。実機ではエラーがサービス再インストールと同一秒に発生しており、この説と整合的（🟡状況証拠）。

説B：起動時クラッシュで後始末が走らない（#53247）

起動時にClaudeのプロセスがクラッシュすると、カーネル側のSilo/Jobの後始末が走らず、孤立ハンドルが残る。以降の起動が同じパッケージのJob変換に失敗する、という説。ログオフで直る事実はこの説と整合。

注意すべき点として、説A（サービス占有）が正しければ「サービス停止で直る」はずだが、実際には効かないと報告されている（§3）。この矛盾があるため、どちらが本命かは決着していない。🔴 現時点では両論併記が誠実だ。

なお、この症状は多言語で確認されている。#53247 の報告者はポルトガル語環境で、ダイアログは 「Há um outro programa usando este arquivo no momento」（別のプログラムがこのファイルを使用中）と表示されており、日本語版の文言と同一の症状だ。

🔴 公式修正の状況：調査時点で公式の恒久修正はリリースされていない。中心的なissue #53247 は Open のまま（担当者なし）。issue側では「CoworkVMServiceを自動起動→オンデマンド起動（Manual）に変更する」「サービス実体を WindowsApps の外へ移す」といった恒久修正が提案されている段階だ。

6. 自分の端末で確認する（PowerShell）

自分の不具合が本記事と同じものか、以下で確認できる（管理者権限は不要）。イベント 215／208 と 0x80070020 が出ていれば同じ問題だ。

Get-WinEvent -LogName 'Microsoft-Windows-AppModel-Runtime/Admin' |
  Where-Object { $_.Message -match 'Claude' } |
  Select-Object TimeCreated, Id, Message | Format-List

更新の履歴と突き合わせたい場合、および同梱サービスの現在の設定を見る場合：

Get-WinEvent -LogName 'Microsoft-Windows-AppXDeploymentServer/Operational' |
  Where-Object { $_.Message -match 'Claude' } |
  Select-Object TimeCreated, Id, LevelDisplayName, Message | Format-List

Get-CimInstance Win32_Service -Filter "Name='CoworkVMService'" |
  Select-Object Name, StartMode, State, PathName

7. 混同しやすい別問題

Claude Desktop（Windows）には、コードが似ていて混同されやすい別の不具合がある。本記事の 0x80070020（起動失敗）とは別物なので切り分けたい。

症状コード本件との違い
本記事：更新後に起動しない0x80070020—
更新が失敗する（#49655）0x80073CF6起動ではなく更新の失敗。別コード。
再インストールが「Servicing」で固まる（#51132）0x80073D28 等導入処理のスタック。別コード。

また、Claude Code CLI（デスクトップアプリが管理する claude.exe）の更新時に EPERM: operation not permitted, unlink ... claude.exe が出ることがあるが、これは旧バージョンの削除に失敗しているだけで新版導入は成功しており、本件とは無関係だ。

まとめ

  • ✅ まずWindowsをサインアウト→サインイン：復旧にPC全体の再起動は必ずしも不要（#53247）。ダメならPC再起動。
  • 🔴 サービス停止・再登録は効かないと報告：時間の無駄になりやすいので避ける。
  • ✅ 正体は「ファイルロック」ではない：AppXコンテナ層（Job→Silo変換）の失敗。ダイアログ文言は実態を表していない。
  • 🔴 引き金は2説あり未決着：サービス占有説（#57221）／起動時クラッシュ→孤立ハンドル説（#53247）。公式修正は未提供。
  • ✅ 恒久策はSquirrel版へ乗り換え：更新・起動の問題が解消したとの報告（#57221）。

この記事は実機1台（Windows 11 Home 10.0.26200）の調査ログとGitHub issueの突き合わせに基づく。全ユーザーで同一に再現するとは限らない点、原因の細部が未決着である点は、正直に踏まえて使ってほしい。

FAQ

Q1. 一番速く直す方法は？

Windowsを一度サインアウトしてサインインし直すのが最速です（スタート → ユーザーアイコン → 「サインアウト」）。PC再起動でも、Claudeアプリ／アカウントのログアウトでもありません。#53247 によれば、原因となる孤立ハンドルはWindowsのユーザーセッション単位で残るため、PC全体の再起動までは不要な場合があります。それでも直らなければPCを再起動してください。

Q2. 「サービスを止めれば直る」と見たのですが？

この不具合では効かないと報告されています（#48003・#53247）。Stop-Service CoworkVMService はサービスが再起動してエラーが再発し、Reset-AppxPackage や各サービスの再起動も解決しなかったと記録されています。まずログオフを試すのが合理的です。

Q3. 本当にファイルがロックされているの？

いいえ。ダイアログは「ファイルが使われています」と読めますが、検証（handle.exe / Process Explorer）でユーザー空間のファイルロックは無いと確認されています（#53247）。実体はAppX/Desktop Bridgeのコンテナ層（Job Object→Silo変換）の失敗で、0x80070020（ERROR_SHARING_VIOLATION）という汎用コードがそう文言化されているだけです。

Q4. 原因は結局なに？

コンテナ層の問題までは確定ですが、引き金は2説あり未決着です。①CoworkVMService（自動起動）がJob Objectを占有する説（#57221）、②起動時クラッシュでSilo/Jobの後始末が走らず孤立ハンドルが残る説（#53247）。サービス停止で直らない事実は①と矛盾するため、現時点では断定できません。

Q5. 公式の修正は出ていますか？

調査時点で公式の恒久修正はリリースされていません。中心的なissue #53247 はOpenのままです。issue側では「サービスをオンデマンド起動（Manual）に変える」等の恒久修正が提案されている段階です。

Q6. 更新のたびに毎回起きる？

🔴 断定できません。実機では「更新のたびに起きる」という体感があった一方、イベントログで確認できたのは更新6回中2回のみでした（ログの上限で古い記録が消えていた可能性があり、判別できていません）。頻度には個体差がある可能性があります。

Q7. 再発させない方法は？

MSIX（Store）版をやめてSquirrel（インストーラ）版へ乗り換えると、更新・起動の両問題が解消したという報告があります（#57221）。Store版を完全アンインストールしてから、公式サイトやwingetでインストーラ版を入れる形です。企業配布ポリシー等の制約がある場合は事前に確認してください。

関連記事