はじめに
こんにちは、fptrendy.com編集部のしゅーです。
最近Anthropic社のAIアシスタント「Claude」のデスクトップ版に「Cowork」という新機能が加わりました。簡単に言えば**「Claudeに作業フォルダを任せて、裏でタスクをこなしてもらう」**機能です。投資情報の定期調査や記事ネタ探しなど、使いどころが多そうだと思い、試してみることにしました。
ところが──これが丸1日以上格闘する羽目になる壮大なトラブルシューティングの幕開けだったのです。
同じエラーで困っている方が1人でもいれば、この記事がお役に立つはずです。結論から言うと、Windowsのアプリ保存先設定が「Dドライブ」になっていることが原因でした。
遭遇したエラー
Claude Coworkでワークスペースを起動しようとすると、以下のエラーが出て何度やっても先に進まない状態になりました。
Claude のワークスペースの起動に失敗しました
EXDEV: cross-device link not permitted, rename
'C:\Users\xxx\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\.wvm-tmp-XXXXX\rootfs.vhdx'
-> 'C:\Users\xxx\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\rootfs.vhdx'
Claudeまたはコンピュータを再起動すると解決する場合があります。
問題が解決しない場合は、ワークスペースを再インストールできます。
エラーメッセージの通りに再起動しても、再インストールしても、同じエラーが繰り返し出続けます。Windows 11 HomeからProにアップグレードしても症状は変わりませんでした。
エラーの意味
EXDEV: cross-device link not permittedというエラーは、別々のドライブ(またはボリューム)間でファイルをrename(移動)しようとして失敗しているという意味です。
ここで不思議なのは、エラーメッセージ上では移動元も移動先も同じC:\Users\xxx\AppData\...\claudevm.bundle\配下なのに、なぜ「別ドライブ間の移動」と判定されるのか、という点でした。
試行錯誤の道のり
ステップ1:ウイルス対策ソフトを疑う
仮想ディスクイメージ(.vhdx)はウイルス対策ソフトに検疫されやすいと聞いていたので、まずはここを疑いました。ウイルスバスタークラウドを使っていたので、リアルタイムスキャンをオフにしてClaudeを再起動。
結果: 症状変わらず
念のためウイルスバスター本体を完全停止しても、エラーは再現しました。これは犯人ではありませんでした。
ステップ2:シンボリックリンクで回避を試みる
エラーの出るパスC:\Users\xxx\AppData\Roaming\Claude\が、何らかの理由で別ボリュームとして扱われているのではと仮説を立てました。
そこで、管理者PowerShellでRoaming\ClaudeをLocal\Claudeへのシンボリックリンクにすることで、「同一ボリューム内の同じフォルダ」として扱われるように仕向けてみました。
New-Item -ItemType SymbolicLink -Path "C:\Users\xxx\AppData\Roaming\Claude" -Target "C:\Users\xxx\AppData\Local\Claude"
結果: EXDEVエラーは出なくなったが、今度はCoworkが0%のまま進まなくなる。さらに翌朝にはClaude Codeタブまで「No path to Claude code executable」エラーで動作停止
シンボリックリンク対策は完全に逆効果でした。アプリ自体が不安定になり、白い画面で固まるなど症状が悪化。
ステップ3:Claudeをクリーン再インストール
シンボリックリンクを削除し、Claudeをアンインストールして再インストール。Claude Codeタブは復活しました。しかしCowork側は相変わらず0%のままという状態。
ステップ4:作業フォルダをDドライブに指定してみた
ここで発想を変えて、Coworkの作業フォルダをCドライブのAppDataではなく、最初からDドライブに作ってみたらどうなる? と試しました。
New-Item -ItemType Directory -Path "D:\_claude_cowork" -Force
そしてCoworkの画面でD:\_claude_coworkを作業フォルダに指定。
結果: あっさり動作成功 🎉
これが大きなブレークスルーでした。
真の原因を突き止める
動くようになったのは嬉しいのですが、「なぜDドライブ指定で動くのか」が気になります。PowerShellで調べてみると、衝撃的な事実が判明しました。
Get-ChildItem "C:\Users\xxx\AppData\Local\Packages\Claude_pzs8sxrjxfjjc" -Force
結果を見ると、Claudeの各フォルダのModeがd----lとなっていて、末尾のlはシンボリックリンク(正確にはジャンクション)を意味します。さらに各フォルダのTargetを調べると:
Target: D:\WpSystem\S-1-5-21-xxx\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\...
Claudeアプリ本体がCドライブに見えていたのに、実体はDドライブにあったのです。
なぜDドライブに入っていたのか
これは、Windows 11の**「新しいコンテンツの保存先」**設定で、新しいアプリのインストール先がDドライブになっていたためでした。筆者のPC(Dell製)は購入時から、あるいはどこかのタイミングでこの設定が有効になっていて、UWPアプリ(Microsoft Store形式のアプリ)が自動的にDドライブへ配置される仕組みになっていました。
調べてみると、Claude以外にもChatGPTデスクトップ、VS Code、PowerToys等、17個のUWPアプリがDドライブに配置されていました。
EXDEVエラーの真相
こうして全貌が見えてきました。
- Claudeはジャンクション経由でC:側から参照されるが、実体はDドライブ
- Coworkは内部で
.wvm-tmp-XXX\rootfs.vhdxという一時ファイルを作成後、最終的な場所にrename(移動)する処理がある - このrename処理で、**あるパスはジャンクション経由でC:扱い、別のパスは実体解決されてD:扱いになり、OS的には「別ボリューム間の移動」**と判定
- Windowsは同一プロセス内で別ボリューム間のrenameを許可しないため、EXDEVエラーが発生
つまり、Claudeアプリ開発側が「Windowsのアプリ保存先がDドライブになっているユーザー」のケースを想定していなかったのが原因でした。
最終的な解決方法
根本解決のため、以下の手順で環境をクリーンに整えました。
手順1: Windowsの設定で新しいアプリの保存先を「Cドライブ」に変更
設定 → システム → 記憶域 → ストレージの詳細設定 → 新しいコンテンツの保存先で、「新しいアプリの保存先」をCドライブに変更。ついでに他の項目もすべてCドライブに揃えておくと今後安心です。
手順2: Claudeデスクトップアプリを完全アンインストール
設定 → アプリ → インストールされているアプリ → Claude → アンインストール。
ここで重要なのは**「Claude Code」(コマンドライン版)は削除しない**こと。Claude CodeはNode.jsのnpmパッケージとして別管理されているので、デスクトップ版とは別物です。
手順3: 残骸フォルダを完全削除
管理者PowerShellで、CとDの両ドライブの残骸を削除します。
# C側の残骸
Remove-Item "C:\Users\xxx\AppData\Local\Packages\Claude_pzs8sxrjxfjjc" -Recurse -Force -ErrorAction SilentlyContinue
Remove-Item "C:\Users\xxx\AppData\Roaming\Claude" -Recurse -Force -ErrorAction SilentlyContinue
Remove-Item "C:\Users\xxx\AppData\Local\Claude" -Recurse -Force -ErrorAction SilentlyContinue
# D側の残骸
Remove-Item "D:\WpSystem\S-1-5-21-xxx\AppData\Local\Packages\Claude_pzs8sxrjxfjjc" -Recurse -Force -ErrorAction SilentlyContinue
手順4: PC再起動
ここは省略しない方がいいです。メモリとレジストリをきれいにするため。
手順5: Claudeデスクトップアプリを再インストール
claude.ai/downloadから最新版をダウンロードしてインストール。手順1でアプリの保存先をCに変更済みなので、今度は自動的にCドライブへ配置されます。
手順6: インストール結果を確認
$cpath = "C:\Users\xxx\AppData\Local\Packages\Claude_pzs8sxrjxfjjc"
Get-Item $cpath -Force | Select-Object Mode, LinkType, Target
Get-ChildItem $cpath -Force | Select-Object Name, Mode
Modeがd-----(末尾にlがない)、LinkTypeとTargetが空であれば、本物のCドライブ実体としてインストールされた証拠です。
以上で完全復旧しました。Coworkの作業フォルダはどこを指定しても動作するようになり、筆者の場合は普段使っているObsidianのVault内に_claude_coworkフォルダを作って一元管理しています。
同様の症状で困っている人への確認ポイント
まとめとして、チェックリストを残しておきます。
確認1: 自分のPCでClaudeがどこに実体配置されているか
管理者PowerShellで以下を実行:
Get-Item "C:\Users\<ユーザー名>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc" -Force | Select-Object Mode, LinkType, Target
Modeがd----lでTargetにD:\や別ドライブが表示される場合、ジャンクション経由で別ドライブに実体があります。これがEXDEVエラーの根本原因である可能性が高いです。
確認2: Windowsの新規アプリ保存先設定
設定 → システム → 記憶域 → ストレージの詳細設定 → 新しいコンテンツの保存先で「新しいアプリの保存先」がどこになっているか。ここがCドライブ以外になっていれば、それがEXDEVエラーの間接的な原因です。
確認3: OneDriveの同期状態
CoworkやClaude Codeの作業フォルダをOneDrive配下に置く場合、OneDriveの「ファイル オンデマンド」機能でプレースホルダー(実体はクラウドにしかないファイル)状態になっていると、読み書きで不具合が起きる場合があります。ただし筆者の環境では、OneDrive配下のMyVault内でも問題なく動作しています。
確認4: ウイルス対策ソフトの影響
リアルタイム保護が.vhdxファイルを検疫していないか。疑わしければ一時的に停止して動作確認すると切り分けられます。ただし筆者の場合はこれは原因ではありませんでした。
やってはいけないこと: シンボリックリンクでの小手先対処
Roaming\ClaudeをLocal\Claudeにシンボリックリンクで誘導する対処は逆効果です。EXDEVエラーは一時的に回避できる場合がありますが、Claude Codeタブを含むアプリ全体の動作が不安定になります。根本原因であるドライブ配置の問題を直接解決しましょう。
学んだこと
今回のトラブルで改めて実感したのは、**「エラーメッセージに書いてあるパスが、OSが実際に操作しているパスと必ずしも一致しない」**ということです。Windowsのジャンクション(またはシンボリックリンク)は便利な機能ですが、アプリ側が「パスの実体解決」をどの段階でどう行うかに依存して、こういう想定外の動作を引き起こすことがあります。
また、「保存先をDドライブにしておく」というWindowsの機能は、容量節約としては優秀ですが、一部の新しいアプリ(特にAI系のように独自の仮想環境を持つもの)では互換性問題の原因になり得ることを学びました。新しいSSDは大容量化が進んでいるので、現代的には「新規アプリはCドライブに揃える」方が安全かもしれません。
おわりに
Anthropic社のClaude、そして新機能のCoworkは、使い始めるとこれまでとは違う作業体験が得られるとても面白いツールです。記事作成や投資情報の調査といった筆者の普段の作業にも、すぐに組み込んで活用しています。
1日以上の格闘でしたが、結果的にはWindowsの動作の仕組みやUWPアプリの配置について多くを学べる機会にもなりました。同じエラーで困っている方の参考になれば幸いです。
(編集後記おわり)
