CoworkがWindows 10で起動しない原因 — HCS 0x80370102の切り分け
Hyper-Vを有効にしても「HYPERVISOR_VIRT_DISABLED」で止まるCoworkのVM。ログの読み方、先に潰す3つの原因、潰しても直らない報告の中身を比べます。
Windows 10 ProでCoworkのローカルVMが起動せず、ログにHRESULT 0x80370102とHYPERVISOR_VIRT_DISABLEDが並ぶ。そのとき、BIOSの仮想化もHyper-Vも有効なのに、アプリだけが「仮想化が無効」と言い張ることがあります。GitHubのissue #97365は、Windows 10 Pro 22H2(ビルド19045)で全項目を確かめても直らない例です。ここでは、ログの読み方、先に潰すべき原因、潰しても直らない場合の報告の中身を順に並べます。
ログの1行はHyper-Vの未導入を指している
#97365の報告者が貼ったログでは、create_vm_configの段階でVMの作成に失敗します。要点は次の3行です。
[VM:steps] create_vm_config started
[VM:start] VM boot failed: HCS operation failed: ... HRESULT 0x80370102
"Cannot create system 'cowork-vm-…' since Hyper-V is not installed on the host."
[VM:start] HCS error detected, available=true, missing=[], sentinel=HYPERVISOR_VIRT_DISABLEDHCS(Host Compute Service)は、Windowsが仮想マシンやコンテナーを作るときの窓口です。0x80370102はそこが返したエラーで、メッセージは「Hyper-Vがホストに入っていない」です。アプリはこれをHYPERVISOR_VIRT_DISABLEDという分類名に変換して表示します。
ここで見落としやすい点が2つあります。
missing=[]は、HCS関連のサービス欠落(vfpextなど)が見つからなかったという意味です。サービスが足りない症状はvfpextエラーの記事の領分で、ここでは当たりません- 分類名はバージョンによって変わります。2026年3月のissue #34201では、同じ0x80370102が
HYPERVISOR_SERVICE_ERRORと分類されていました。画面の文言だけでなく、HRESULTとメッセージ本文で同じ系統かを判断します
Coworkのコード実行は専用のLinux VMで行われ、WindowsではHyper-Vがそれを隔離します。この前提はサポート記事のアーキテクチャ概要に書かれています。VMを作れないときは、Coworkのローカルセッションが使えません。
ログはどこにあるか
ログの名前はcowork_vm_node.logです。置き場所は入れ方で変わります。
| インストール方法 | ログの場所(報告にあるパス) |
|---|---|
| 通常(#97365の報告) | ログの場所(報告にあるパス)%LOCALAPPDATA%\Claude\Logs\ |
| Microsoft Store(MSIX。#34201の報告) | ログの場所(報告にあるパス)%LOCALAPPDATA%\Packages\Claude_*\LocalCache\Roaming\Claude\logs\ |
#97365の報告者はMSIX版と書きながら、前者のパスを挙げています。見つからないときは両方を探します。#34201には、ログが一度も作られなかったという報告もあります。その環境ではVMの起動を試みる前に、アプリ内の対応判定が非対応と返していたとの推測が書かれていました。ログが無い場合と、ログに0x80370102がある場合は、別の段階で止まっていると考えてください。
先に潰す3つの原因
0x80370102は、本当にHyper-Vが動いていなくても出ます。次の順で確かめると、無駄な再起動が減ります。
Windows側の確認手順
- 1
ファームウェアの仮想化を確かめる
Windowsの機能一覧でHyper-Vが「有効」でも、ファームウェア(BIOS/UEFI)側で仮想化が切れていると動きません。#34201では、解決した報告者が
systeminfoで「Virtualization Enabled In Firmware: No」を見つけ、BIOSで有効にして直しました。Windowsの画面上のHyper-Vは有効のままだったそうです。 - 2
ハイパーバイザーが起動時に立ち上がるか見る
bcdeditのhypervisorlaunchtypeがAutoかを確かめます。#34201と#97365の報告者は、どちらもこれをAutoにしていました。 - 3
Hyper-Vの機能と関連サービスを見る
Microsoft-Hyper-V-AllとVirtualMachinePlatform、サービスのvmms、vmcompute、CoworkVMServiceが動いているかを見ます。有効化したら再起動を挟みます。
確認用のコマンドをまとめます。#97365で報告者が使っていたものと同じ項目です。
(Get-CimInstance Win32_Processor).VirtualizationFirmwareEnabled
(Get-CimInstance Win32_ComputerSystem).HypervisorPresent
bcdedit /enum | Select-String hypervisorlaunchtype
Get-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-All
Get-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform
Get-Service vmms, vmcompute, CoworkVMServiceサポート記事のWindows展開ガイドで、Coworkの要件として名指しされているのはVirtual Machine Platformです。有効化のコマンドはEnable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform -All -NoRestartで、反映には再起動が要ります。Hyper-V全体を入れる必要があるとは書かれていません。
全部問題ないのに出るとき — #97365の中身
#97365の環境は、Windows 10 Pro 22H2(ビルド19045)、Microsoft StoreのMSIX版Claude Desktop 2.9939.2、CPUはAMD Ryzen 9 7950Xです。報告者が確かめた項目は上の確認コマンドとほぼ同じで、結果は次のとおりです。
報告者が確認した状態
ファームウェアの仮想化
True
VirtualizationFirmwareEnabled
ハイパーバイザー
True
HypervisorPresent
起動設定
Auto
hypervisorlaunchtype
関連サービス
Running
vmms / vmcompute / CoworkVMService
Hyper-V有効化後に再起動しても、同じエラーが毎回のアプリ起動で出ます。VMの本体(バンドル)のダウンロードとインストールは成功しており、create_vm_configでだけ落ちます。アプリは「自動での再インストールはしない。次回の起動で再試行する」とログに書いて、VMをオフラインのまま残します。
issueの末尾で、報告者は期待する動作を2つ書いています。VMが作成されて起動することと、ホストが本当に非対応なら「仮想化が無効」ではなくそう伝えることです。#97365はopenで、コメントは付いていません。
同じHRESULTの過去報告を並べる
#97365は、同じ症状の過去のissueを複数挙げています。そのうち#34201と#77711を、#97365と並べます。
| issue | 環境 | 分類名 | 結末 |
|---|---|---|---|
| #34201(2026年3月) | 環境Windows 10 Pro 22H2、MSIX | 分類名HYPERVISOR_SERVICE_ERROR | 結末コメントの1人がBIOSの仮想化無効を見つけて解決。not plannedで終了 |
| #77711(2026年7月) | 環境Windows 11 Pro 24H2、MSIX | 分類名(0x80370102。メッセージは「hypervisor not running」) | 結末コメントはbotの自動クローズのみ。staleで終了 |
| #97365(2026年9月) | 環境Windows 10 Pro 22H2、MSIX | 分類名HYPERVISOR_VIRT_DISABLED | 結末open |
#77711の報告者は、Process Monitorでワークスペースの起動操作を約100秒記録しました。vmcompute.exe、vmms.exe、HCS、hvsocketなどへのアクセスは1件も出ていません。そこから、Hyper-Vに問い合わせる前に、アプリ自身の事前チェックがエラーを出しているのではないかと推測しています。これは報告者の推測で、アプリの実装を確かめたものではありません。
#97365のログにはHCSからのエラーメッセージが含まれるので、事前チェックだけで落ちた#77711とは段階が違う可能性もあります。同じHRESULTでも、原因は1つではなさそうです。
Windows 10が対応OSかはサポート記事で区別されていない
サポート記事の「Cowork desktop requirements」は、Windows 10か11かを分けて書いていません。アーキテクチャ概要が挙げるのは「WindowsではHyper-V」という点までです。#34201のコメントには「Windows 10 Pro x64がアプリの内部判定で非対応にされている」という推測がありますが、運営側の返信は付いていません。
したがって、Windows 10で動くと断言も、動かないと断言もできません。Windows 10で、上の確認をすべて通してもだめなら、報告が集まっているissueに環境を足す以外に確実な手立てはありません。
症状が似ている別のエラーとの見分け方
Windows 10で出るCoworkのVM系エラーには、似た見た目のものがいくつかあります。
ログの違いで見分ける
Missing HCS services: vfpext
VMを作る前の事前チェックで止まり、Coworkのタブが押せません。
missing=[…]に欠けたサービス名が入ります。→ vfpextエラーの対処connect ENOENT \\.\pipe\cowork-vm-service
CoworkVMServiceがStoppedのまま、手動でStart-Serviceしても「予期せず終了した」と返る例です(#84682、Windows 10 Pro、MSIX)。Hyper-V自体の問題ではなく、サービスが立ち上がらない問題です。→ CoworkVMServiceが起動しない原因Virtualization is not enabled
VMの起動を試みる前の対応チェックで出る画面です。→ 「Virtualization is not enabled」の原因
0x80370102(本記事)
VMの作成を試みて、HCSが「Hyper-Vが入っていない」と返したときです。
create_vm_configで止まります。
#84682の報告者は、Hyper-VとVirtual Machine Platformが有効なことを確認し、ワークスペースの再インストールまで試しています。それでもサービスが立ち上がらず、Windows 10 Proで同系統の行き止まりに当たっています。
報告に添えるとよい情報
#97365の構成は、報告の型として使えます。再現手順、ホストの確認結果、ログを揃えると、調べる側が切り分けを繰り返さずに済みます。
- OSのエディションとビルド(例: Windows 10 Pro 22H2、19045)と、MSIXか通常版か
- CPUと、ファームウェアでの仮想化の設定名(AMDならSVM)
- 上の確認コマンドの結果
cowork_vm_node.logの該当部分。非英語環境のログは文字化けすることがあるので、意味を訳して添える
もう1つ、#97365の補足に実害のある副次的な問題が書かれています。VMバンドルの更新が数週間、ディスク容量不足(16.1GB必要)で失敗していました。ログには非致命の警告としてしか残らず、vm_bundles\warm\に古いバンドルが溜まっていたそうです。0x80370102とは別の問題ですが、空き容量が少ない環境では、あわせて確認する価値があります。
まとめ
0x80370102が出たら、まずファームウェアの仮想化、hypervisorlaunchtype、Hyper-V関連の機能とサービスの3点を、コマンドで実際に確かめます。画面上の「有効」を信用しないのが要点です。#34201には、この見直しだけで解決した例があります。
全部がTrueでAutoでRunningなのに出るなら、#97365と同じ状態です。この状態から利用者側の操作で直ったという報告は、#97365・#34201・#77711のいずれにもありません。同じ環境の人は、#97365に自分の構成とログを足すのが現実的です。症状が別のサービス系エラーなら、上の別記事の切り分けに移ります。