CoworkがWindows ARM64で起動しない原因 — 60秒タイムアウトの切り分け

Snapdragon搭載のWindows PCでClaude Desktopを開くと、チャットは動くのにCoworkだけが「Failed to start Claude's workspace」で止まります。表示は「VM connection timeout after 60 seconds」が多数派です。GitHubのissue #40198は、この症状にSamsung Galaxy Book4 Edge、Surface、ASUS、Dellなどの報告が69件集まった、openのスレッドです。

先に結論を書きます。報告を読むと、同じ「起動しない」でも原因は少なくとも2系統に分かれます。ひとつは、ARM64機にx64版のアプリが入っているケース。もうひとつは、ARM64版でVMは立ち上がるのにゲストが接続してこないケースです。前者はインストールし直しで直った報告があり、後者は直った報告と直らない報告が混在しています。

まず3つの症状を見分ける

#40198のコメントに出てくるエラーは、画面の文言とログの形で3つに分けられます。

3行目がスレッドの大半です。vm_bootとadd_plan9_sharesは数ミリ秒で終わるのに、その後のゲスト接続が来ないまま60秒で打ち切られます。

2行目の0x80004001は、同じスレッドの中で別症状として扱われています。Windows 10で出る0x80370102(HCSが「Hyper-Vが入っていない」と返す)とも別物なので、そちらはWindows 10で起動しないときの切り分けを見てください。

最初に確かめるのはアプリのビルドの種類

#40198の2つのコメントが、同じ点を指しています。ARM64機に入っているClaude Desktopが、実はx64版だったという例です。

あるコメントでは、ASUS Vivobook S 15(Snapdragon X Plus)で0x80004001とMicrosoft Virtual BIOSのエラーが出ていました。パッケージ名はClaude_1.24012.9.0_x64__...で、resourcesにあるVMイメージはsmol-bin.x64.vhdxだけだったそうです。報告者は、x64版がx86系のVM設定を組み立て、ARM64のHyper-Vが実装していないレガシーなBIOSデバイスに当たって失敗するのではないかと推測しています。これは報告者の仮説で、アプリの実装を確かめたものではありません。

別のコメントは、Dell Latitude 7455(Snapdragon X EliteとX Plusの2台)での比較です。同じ機体、同じ日、同じ1.24012.9で、x64版は「isolated Linux environment failed to start (not supported on this device)」と即座に拒否され、ARM64版に入れ替えると起動したとあります。ARM64版はx64版の上から上書きインストールでき、アンインストールは要らなかったそうです。

ここで注意したいのは、画面のバージョン番号では見分けられない点です。同じ1.24012.9でも、アーキテクチャーが違えば別のビルドです。PowerShellで確かめます。

Get-AppxPackage *Claude* |
  Select-Object Name, Version, Architecture, PackageFullName

ArchitectureがArm64ならARM64版です。X64と出たら、Snapdragon機でもx64版が動いています。MSIX以外の入れ方なら、タスクマネージャーの「詳細」タブで列の見出しを右クリックし、「アーキテクチャ」を表示してclaude.exeの行を見る方法が書かれています。

Claudeのサポート記事にあるWindows向け展開ガイドには、ダウンロードとしてMSIXのx64版とarm64版が並んでいます。入手先の見分け方として、報告者はclaude.ai/downloadの「Desktop」欄にある「Windows (Arm 64)」のリンクを勧めていました。上部の大きなボタンの行き先は変わったことがある、という理由です。この点は報告者の観察で、サポート記事には書かれていません。

ただし、ARM64版を入れても直らない報告は多数あります。次の節がそちらです。

ARM64版で60秒タイムアウトになるとき

ARM64版のログは、どの報告もよく似た形をしています。

[VM:start] smol-bin.arm64.vhdx copied successfully
[VM:steps] create_network completed
[VM:steps] create_vm_config completed
[VM:steps] vm_boot completed (112ms)
[VM:steps] add_plan9_shares completed (4ms)
[VM:start] Still waiting for guest connection... 50921ms elapsed, 101 polls
[VM:start] Connection timeout, last completed step: add_plan9_shares
[VM:start] Startup failed: Error: VM connection timeout after 60 seconds

ホスト側の手順はすべて成功しています。止まるのは、VMの中のLinuxが「起動した」とホストに知らせてこない段階です。ログの置き場所は、報告では%APPDATA%\Claude\logs\でした。VM関連はcowork_vm_node.log、サービス側はcowork-service.logです。

ログが残らない例もあります。ある報告者はcowork_vm_node.logが作られず、vm_bundlesフォルダーもできなかったと書いています。ログの有無で、止まっている段階が違う可能性があります。

Claudeのサポート記事は、どのチェックが失敗しているかを見る場所として、Claude Desktopの「Help > Troubleshooting > Show Logs」にあるsupported-features-info.jsonを挙げています。仮想マシンやVDIのようにネストした仮想化がない環境はCoworkの対象外とも書かれています。物理のSnapdragon機では当たらない条件ですが、仮想環境でARM版Windowsを動かしているなら、まずここを疑います。

「実はゲストが遅れて接続している」という報告

スレッドには、タイムアウトの正体について踏み込んだ報告が2つあります。

1つ目は、Snapdragon XのWindows 11 Homeで、ゲスト側のログを突き合わせた例です。ホストから見て失敗でも、ゲストは20分から2時間遅れて接続していたというものです。3か月間で8回の成功があり、最短22分、最長11時間47分だったと書かれています。VMを動かしているプロセスが、約7MBのメモリしか使わないまま、vCPU1つ分をほぼ使い切っていたとも報告されています。報告者はこれを、ゲスト内のタイマーの扱いが原因ではないかと見ています。

2つ目は、起動後に約9分の空白を経てから接続できたという、4月の報告です。こちらも、60秒では到底足りないと主張しています。

どちらも報告者個人の観察と推測です。Claude側の確認や返答は、スレッドには付いていません。ただ、60秒で切れたあともVMがバックグラウンドで動き続けている可能性は、手元の切り分けに使えます。タイムアウト後にvmmem系のプロセスが高いCPU使用率のまま居座るなら、この型を疑う根拠になります。

効かなかった対処、効いたと報告された対処

#40198の報告者たちが試した対処を、結果ごとに分けます。

効いたという報告は、いずれも再現性が限られます。

WSL2の効果については、反対の報告が明確です。「WSL2を入れても直らない」と書いたX Eliteの報告者がいます。別の報告者はWSL2が普通に動いている機体で同じタイムアウトを見ており、ARM64版のHyper-V自体は動いていると述べています。

スリープ復帰後に「VM is already running」になる場合

起動に何度か成功した人でも、スリープから戻ったあとに出るのが、VM is already runningという別の止まり方です。長期記録を残した報告では、スリープと復帰を挟むと半分ほどの確率で発生し、2回挟むとほぼ必ず発生したとあります。ログには、シャットダウン時に0xC037010D(JSONドキュメントが無効)が出て、前のVMが強制終了のまま残っていました。

その報告者が使った回避策は、Host Compute Serviceの再起動です。

Stop-Service vmcompute -Force; Start-Service vmcompute

そのあとClaude Desktopを起動し直します。報告者によれば、アプリがこの操作を自動では行わず、案内もしないため、利用者が知っている必要があるとのことです。この報告者は、vmcomputeの再起動が効いたのはこの型だけで、60秒タイムアウトには効かなかったとも書いています。

確認の順番を絞る

ここまでの報告を、確認の順番にしてみます。上から順に、はいなら次へ進みます。

公式の要件と報告のずれ

Claudeのサポート記事とスレッドの報告には、食い違いが2点あります。

1つ目はbcdeditです。展開ガイドはhypervisorlaunchtypeがAutoかを見て、違えばbcdedit /set hypervisorlaunchtype autoで直すよう案内しています。一方、Dell Latitude 7455の報告者は、Snapdragon Xではbcdedit /enum {current}にこの項目が出ず、それでもsysteminfoにはハイパーバイザーが検出され、仮想化ベースのセキュリティが動いていたと書いています。この報告によれば、項目がなくても異常ではありません。ARM64機では「項目がない」ことを理由に設定し直す必要はなさそうです。

2つ目は、対応状況の書き方です。展開ガイドにはARM64のMSIXが載っていますが、ARM64のSnapdragon機でCoworkが使えるかどうかは、そのページには明記されていません。あるコメントは、ダウンロードページにもCoworkの文書にも制限が書かれていないために、数時間の切り分けとWindowsのアップグレード費用が無駄になったと不満を述べています。別の報告者は、Cowork開始時の準備チェックが警告なしに通ることが、かえって紛らわしかったと書いていました。

ほかにも、同じ機種で結果が分かれる点が、原因の絞り込みを難しくしています。ある報告者は、Surface Laptop 7(Snapdragon X 12コア)では動き、Surface Pro 12インチ(Snapdragon X Plus 8コア)では動かないと書いています。同じバージョン、同じメモリ、同じWindowsビルドでした。ただし、その後に同じLaptop 7世代で0x80004001を報告した例もあり、こちらはビルドの種類が確認されていません。機種で一律に決まるとは言いにくい状況です。

issueの現状

#40198は、2026年3月28日に立てられ、bug、platform:windows、area:coworkのラベルが付いたopenのissueです。コメントは69件で、最後の更新は8月26日です。コメントの投稿者はすべて外部の利用者で、運営側の返答はスレッドにありません。直ったと確認できるバージョンは、スレッド内で示されていません。

最終的な修正を待つあいだに利用者側でできるのは、ビルドの種類の確認と、ログに基づく報告の追記までです。似た見た目の別症状は、原因ごとに分かれています。サービスが立ち上がらないならCoworkVMServiceの起動失敗、HCSサービスが欠けているならvfpextのエラー、対応判定の画面で止まるならVirtualization is not enabledです。Claude Code本体がARM64で落ちる症状は0xC0000005のクラッシュで扱っています。

CoworkのVMはHyper-V上のLinuxで、メモリの使われ方はClaude DesktopがHyper-V仮想マシンを起動する理由で整理しています。ARM64機でも仕組みは同じで、VMイメージだけがsmol-bin.arm64.vhdxになります。

まとめ

Snapdragon機でCoworkが動かないとき、最初の一手は仮想化の再設定ではなく、Get-AppxPackageでArchitectureを見ることです。x64版が入っていたと特定した報告は2件あり、入れ替えで直ったと確かめたのはそのうち1件です。

ARM64版でも60秒で止まる場合は、直る見込みのある対処がまだ確立していません。ゲストの接続が遅れているだけという報告もあり、その場合は設定を変えても結果が変わらないはずです。確認の記録を残して、#40198に追記するのが次の一手になります。