Claude Desktopが「このファイルはほかのプログラムで使用されています」で起動しない問題を再起動せず解決した

はじめに

Windows版Claude Desktopを起動しようとしたところ、次のポップアップが表示され、起動できなくなりました。

このファイルはほかのプログラムで使用されています。

タイトルバーには、次のようなClaudeの実行ファイルパスが表示されていました。

C:\Program Files\WindowsApps\Claude_<version>_x64__pzs8sxrjxfjjc\app\Claude.exe

PCを再起動すれば解消するものの、作業中の状態を保持するためにも再起動は避けたいところです。そこでWindowsのイベントログとプロセス状態を調査し、再起動せずに復旧しました。

調査の結果、Claude.exeが単純にファイルロックされていたわけではなく、更新前のClaude Desktopから起動された長時間実行プロセスが旧バージョンのAppXコンテナーに残留していたことが原因と判明しました。

環境

今回確認した環境と発生条件は次のとおりです。

• OS: Windows 11
• Claude Desktop更新前: 2.110.0.0
• Claude Desktop更新後: 2.110.1.0
• インストール形式: MSIX/AppX
• インストール先: C:\Program Files\WindowsApps
• 発生時の前提条件: Claude Desktop上のセッションから、長時間実行されるCLI／Python処理を開始していた

Claudeのバージョンとパッケージ状態は、次のコマンドで確認できます。

Get-AppxPackage Claude |
    Select-Object Name, PackageFullName, Status, InstallLocation |
    Format-List

実行結果のとおり、パッケージの表示状態（Status）自体は正常（Ok）を示していました。

Name            : Claude
PackageFullName : Claude_2.110.1.0_x64__pzs8sxrjxfjjc
Status          : Ok

しかし、パッケージが Status: Ok であっても、旧バージョンのAppXコンテナーが残留していると、Claude Desktopの起動に失敗することがあります。

最初に試したこと

Claude関連プロセスの終了

まず、Claude本体とNative Messaging関連のプロセスを終了しました。

Get-Process Claude,chrome-native-host -ErrorAction SilentlyContinue |
    Stop-Process -Force

しかし、プロセス終了後も起動エラーは解消しませんでした。

Windows設定からの「終了」と「修復」

続いて、Windowsの設定画面からアプリの「終了」と「修復」を試みました。

設定
  → アプリ
  → インストールされているアプリ
  → Claude
  → 詳細オプション

「終了」を実行した直後にもかかわらず、修復を実行すると次のメッセージが表示されました。

このアプリは現在実行中のため、修復できませんでした。

タスクマネージャー等の画面上ではClaudeが起動していないように見えても、OS側ではパッケージがなお使用中として扱われていました。

イベントログの確認

AppXの修復・登録エラー

原因を特定するため、まずAppXの修復・登録に関するイベントログを確認しました。

Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-AppXDeploymentServer/Operational'
    StartTime = (Get-Date).AddHours(-6)
} |
Where-Object {
    $_.Message -match 'Claude|0x80073D02'
} |
Select-Object TimeCreated, Id, LevelDisplayName, Message |
Format-List

ログには次のエラーが記録されていました。

0x80073D02:
次のアプリを閉じる必要があるため、インストールできません:
Claude_<version>_x64__pzs8sxrjxfjjc

AppModel Runtimeのエラー

次に、AppModel Runtimeのログを確認しました。

Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-AppModel-Runtime/Admin'
    StartTime = (Get-Date).AddHours(-6)
} |
Where-Object {
    $_.Message -match 'Claude|0x80070020'
} |
Select-Object TimeCreated, Id, LevelDisplayName, Message |
Format-List

このログには、問題の核心を示すイベントが記録されていました。

イベント ID 215:
0x80070020:
ジョブの変換中にエラーが発生したため、
ClaudeのDesktop AppXコンテナーを作成できません。

イベント ID 208:
0x80070020:
ランタイムの構成中にエラーが発生したため、
Claudeのプロセスを作成できません。

ポップアップには「ファイルがほかのプログラムで使用されています」としか表示されませんが、エラーコード 0x80070020 とログの記述から、新バージョンのClaude用AppXコンテナーを作成できないことが根本的な問題だと分かります。

関連サービス（CoworkVMService）の影響切り分け

Claude Desktopには、次のWindowsサービスが登録されています。

Get-CimInstance Win32_Service |
Where-Object {
    $_.Name -match 'Claude|Cowork'
} |
Select-Object Name, DisplayName, State, StartMode, ProcessId, PathName |
Format-List

確認できたサービスは次のとおりです。

Name        : CoworkVMService
DisplayName : Claude
State       : Running
StartMode   : Auto
PathName    : ...\resources\cowork-svc.exe

このサービスを停止したうえで、AppXパッケージの再登録も試みました。

Stop-Service -Name CoworkVMService -Force

$package = Get-AppxPackage Claude

Add-AppxPackage `
    -DisableDevelopmentMode `
    -Register (Join-Path $package.InstallLocation 'AppxManifest.xml')

パッケージの再登録自体は正常に完了したものの、Claude Desktopの起動エラーは解消しませんでした。

CoworkVMService はサービス用の独立したコンテナーで動作しているため、サービス停止や再登録を行っても状況は変わらず、今回の起動阻害の主因ではないことが切り分けられました。

起動失敗のメカニズム：旧AppXコンテナーと残留子プロセス

イベントログを時系列で整理すると、次のような流れで問題が発生していました。

1. 更新前のClaude Desktopから長時間処理を開始した
2. 処理の実行中にClaude Desktopの自動更新が行われた
3. Claude本体のウィンドウおよび画面上のプロセスは終了した
4. Claudeから起動された子プロセスはバックグラウンドで実行を継続していた
5. 子プロセスが所属する旧AppXコンテナーだけがOS内に残留した
6. 新版Claude用のコンテナー作成が 0x80070020 で失敗した

旧コンテナーを管理者権限で調査したところ、複数のプロセスが残留していました。

代表的なものは次のとおりです。

シェルプロセス
Pythonランチャー
Pythonワーカープロセス
外部CLIツール
コマンドプロンプト

プロセスの親子関係は、おおむね次のようになっていました。

Claude Desktop（更新前）
└─ シェル
   └─ 長時間実行スクリプト
      ├─ ワーカープロセス
      │  └─ 外部CLIツール
      └─ ワーカープロセス
         └─ 外部CLIツール

さらに、親プロセスが既に終了したPythonの multiprocessing ワーカーも残留していました。

python.exe -c "from multiprocessing.spawn import spawn_main; ..."

これらのプロセスは、プロセス名や実行ファイルパス上はClaudeとは無関係に見えます。しかし、実際にはClaudeの旧AppXコンテナー（ジョブオブジェクト）に所属しています。

Windowsのジョブオブジェクトでは、一度所属した実行中プロセスを後から切り離せません。そのため、子プロセスが1つでも残っている限り、旧コンテナーも破棄されずに残り続けます。

この挙動はMicrosoftの公式ドキュメントにも記載されています。

• Job Objects - Microsoft Learn

同様の症状は、AnthropicのGitHubリポジトリでも報告されています。

• Windows desktop app won't launch after package upgrade: 0x80070020
• Background processes retain the old AppX container

記事執筆時点では、この構造的な問題に対する恒久的な修正は確認されていません。

PC再起動によって解消する理由

PCを再起動すると、旧Claudeコンテナーに所属していた子プロセスもすべて強制終了されます。

コンテナー内の最後のプロセスが終了してジョブオブジェクトが解放されると、OSは旧コンテナーを正常に破棄できるようになります。その結果、新版Claude用のAppXコンテナーが問題なく作成され、起動できるようになります。

つまり、再起動によって壊れたファイルが修復されたのではなく、旧コンテナーを掴んでいた残留プロセスが一掃されたことで問題が解消していたと考えられます。

再起動せずに復旧する手順

注意事項

ここからの操作は、旧コンテナー内で実行されているプロセスを強制終了します。私のように、データ処理、機械学習、ビルド、レンダリング、ログ監視などを実行中だった場合、処理は途中で中断されます。

また、次のようにプロセス名だけで一括終了するのは避けてください。

# 実行しない
Get-Process python | Stop-Process -Force

Claudeとは無関係に動いている作業中のPython処理まで巻き込んで終了させてしまうためです。

旧コンテナーに所属するPIDの特定

今回の復旧では、管理者権限のPowerShellからWindowsのNTオブジェクト名前空間を走査し、Container_Claude_ で始まるジョブオブジェクトを調査しました。

調査手順は次のとおりです。

1. NtOpenDirectoryObject と NtQueryDirectoryObject で対象のジョブ名を確認する
2. NtOpenJobObject を JOB_OBJECT_QUERY 権限で開く
3. QueryInformationJobObject の JobObjectBasicProcessIdList を呼び出し、所属するPID一覧を取得する
4. 取得したPIDごとに、プロセス名、開始時刻、親PID、コマンドラインを確認する
5. 実行中の作業内容を確認したうえで、対象プロセスのみを終了する

旧コンテナー内の子プロセスはClaudeという名前やパッケージ情報を持たない場合があるため、この方法は通常の Get-Process Claude よりも確実に特定できます。

関連するWin32 APIの仕様は以下のとおりです。

• QueryInformationJobObject - Microsoft Learn
• IsProcessInJob - Microsoft Learn

対象PIDを取得したら、終了前にプロセス情報を確認して記録します。

Get-CimInstance Win32_Process |
Where-Object {
    $_.ProcessId -in $targetPids
} |
Select-Object `
    Name,
    ProcessId,
    ParentProcessId,
    CreationDate,
    ExecutablePath,
    CommandLine |
Format-List

対象が間違いなく旧Claudeから開始された処理であることを確認したうえで、PIDを指定して終了します。

$targetPids = @(
    # 直前の調査で特定したPIDだけを指定する
)

foreach ($targetPid in $targetPids) {
    $process = Get-Process -Id $targetPid -ErrorAction SilentlyContinue

    if ($process) {
        Stop-Process -Id $targetPid -Force
    }
}

PIDは再利用される可能性があるため、過去に取得したPIDをそのまま使い回すのではなく、終了直前にプロセス名・開始時刻・コマンドラインを必ず再確認してください。

なお、一般的な利用環境において最も安全な復旧方法は、作業内容を保存したうえでのWindows再起動です。本節の手順は、どうしても再起動を避けたい状況で、かつ対象プロセスを正確に識別できる場合に限って実施してください。

Claudeの起動確認

旧コンテナー内のプロセスがすべて終了するまで数秒待機してから、Claude Desktopを起動します。

Start-Sleep -Seconds 5

Start-Process explorer.exe `
    -ArgumentList 'shell:AppsFolder\Claude_pzs8sxrjxfjjc!Claude'

起動後の状態もコマンドで確認します。

Get-Process Claude |
Select-Object `
    ProcessName,
    Id,
    StartTime,
    Responding,
    MainWindowTitle |
Format-List

正常に起動できた場合、次のような情報が出力されます。

ProcessName     : claude
Responding      : True
MainWindowTitle : Claude

このとき、AppModel RuntimeのイベントログにはイベントID 201 が記録されます。

パッケージ Claude_<version>_x64__pzs8sxrjxfjjc 内の
アプリケーション Claude_pzs8sxrjxfjjc!Claude のプロセスを作成しました。

これで、PCを再起動することなくClaude Desktopを正常起動できる状態に復旧できました。

修復や再インストールで解決しない理由

今回のケースでは、Claudeの実行ファイルや設定データ自体が破損していたわけではありません。

問題の本質は、旧バージョンのAppXコンテナーに実行中のプロセスが残っていた点にあります。そのため、次の対処法を行っても効果はありませんでした。

• Claude.exeの終了
• chrome-native-host.exe の終了
• CoworkVMService の停止
• Windows設定画面からの「終了」
• Windows設定画面からの「修復」
• Add-AppxPackage -Register によるパッケージ再登録
• Claudeの再起動

設定画面からのアプリ「リセット」はローカル設定を消去してしまいますが、旧コンテナー内の残留プロセスが原因である以上、リセットを行っても問題は解決しません。

同様のエラーに遭遇した場合は、安易にリセットや再インストールを行う前に、まずイベントID 208 215 およびエラーコード 0x80070020 の有無を確認することをお勧めします。

再発防止策

長時間処理をClaude Desktopから直接起動しない

最も確実な対策は、長時間実行する処理をClaude Desktopのセッション内から直接実行しないことです。

Claudeにはスクリプトやコマンドの生成のみを依頼し、実行自体はスタートメニューから個別に起動した独立したWindows Terminal上で行います。

Set-Location C:\work\project

.\env\Scripts\python.exe `
    -u scripts\long_running_task.py `
    --config configs\example.json

ここで注意すべき点は、Windows Terminalをスタートメニュー等から独立して起動することです。

Claude Desktop内の組み込みターミナルやClaude Codeセッションから起動すると、その子プロセスがClaudeのAppXコンテナーを継承してしまいます。Claude内で単に Start-Process を呼び出すだけでは、親プロセスがClaudeである以上、コンテナーの所属関係から完全に分離できるとは限りません。

長時間処理に再開機能を持たせる

長時間を要する処理には、不意の終了に備えて以下のような再開・耐障害性の仕組みを組み込んでおくことも有効です。

• チェックポイントの保存
• 処理済みファイルのスキップ
• ステップ単位での再実行機能
• 標準出力・標準エラー出力のファイル保存
• タスクスケジューラからの定期実行
• 専用サービスやジョブランナーの利用

Claude更新前の残留プロセス確認

Claude Desktopの更新や再起動を行う前に、Claudeから開始した以下のような処理がバックグラウンドに残っていないか確認します。

• PythonやNode.jsなどのスクリプトランタイム
• 外部CLIツール
• SSH接続プロセス
• Git関連プロセス
• ログ監視プロセス
• バックグラウンドシェル

プロセス名だけで一括終了するのではなく、コマンドライン引数や親子関係を確認したうえで対処してください。

自動更新の無効化について

Claude Desktopには企業管理向けの disableAutoUpdates ポリシーが存在します。

• Enterprise configuration for Claude Desktop

ただし、この設定はMDM等でバージョンを一括統制する企業環境向けです。個人利用の環境で更新を無効化し続けると、セキュリティ修正や新機能の適用を受けられなくなるため、恒久対策としては推奨されません。

長時間実行タスクをClaudeのプロセス外で実行する運用を徹底するほうが安全です。

まとめ

今回の起動障害は、単純なファイルロックによるものではありませんでした。原因と経緯を整理すると次のとおりです。

• Claude Desktopから長時間処理を起動した
• 処理の実行中にClaude Desktopの自動更新が行われた
• 子プロセスが旧AppXコンテナー内に残った
• OSが旧コンテナーを破棄できなくなった
• 新版Claude用コンテナーの作成が 0x80070020 で失敗した
• 結果として「このファイルはほかのプログラムで使用されています」が表示された

復旧にあたっては、旧コンテナーに所属するプロセスのみを特定して終了させる必要がありました。

再発防止策としては、Claudeにはスクリプトの作成のみを任せ、長時間実行される処理そのものは独立して起動したWindows Terminalで実行する運用が最も効果的です。

また、同じポップアップが表示された場合でも、背後にある原因が同一とは限りません。まずはイベントログを確認し、エラーコード 0x80070020 や「ジョブの変換中」という記録が出ているかどうかを確かめてから対処することをお勧めします。

参考資料

• Job Objects - Microsoft Learn
• QueryInformationJobObject - Microsoft Learn
• IsProcessInJob - Microsoft Learn
• Windows desktop app won't launch after package upgrade: 0x80070020
• Background processes retain the old AppX container
• Enterprise configuration for Claude Desktop