Cowork「Virtualization is not enabled」と出る原因と対処法
仮想化を有効にしても出る「Virtualization is not enabled」の原因は、エディション制限・サービス未登録(管理者権限なしのインストールを含む)・検出ロジック側の問題の3系統です。公式の対処手順をまとめます。
CoworkのローカルセッションでBIOSとWindowsの両方の仮想化設定を確認済みのはずなのに、「Virtualization is not enabled」と表示されることがあります。原因はハードウェアの設定ミスとは限りません。Windowsのエディション制限、仮想化サービスの未登録(管理者権限なしのインストールを含む)、検出ロジック側の問題という性質の異なる3系統に分かれるため、切り分け方を知らないと同じ操作を繰り返すだけになりがちです。
エラーが示す内容と発生タイミング
Coworkのローカルセッションは、シェルコマンドとコード実行だけをホストOSから隔離した専用VMで行い、Windowsではこの隔離をHyper-Vが担います。「Virtualization is not enabled」は、このVMを起動する前の事前チェックで仮想化機能が検出できなかったときに出る画面です。エラーメッセージの全文は次のとおりです。
Virtualization is not enabled. Claude's workspace requires hardware virtualization (Hyper-V). Enable virtualization in your computer's BIOS/UEFI settings, then restart.
事前チェックの段階で止まるため、VMが起動した後に出る「workspace unavailable」とは表示されるタイミングも意味も異なります。両者の違いは後述します。
原因1: Windows Homeエディションは仕様上動作しない
Coworkが必要とするのは、Windows Home Editionには含まれない機能です。公式のデプロイ手順書は「Claude Desktop for WindowsはCoworkを使うためにVirtual Machine Platformを必要とする」と説明しています。一方でGitHub上のドキュメント改善Issueは、実際にはHyper-Vのフル機能であるvmms(Virtual Machine Management)サービスが必要だと指摘しています。このサービスはWindows Pro・Enterprise・Educationのみに含まれ、Homeには含まれません。Windows Homeにも「Virtual Machine Platform」と「Windows Hypervisor Platform」はありますが、これだけではCoworkのVMベースのサンドボックスには不十分だという内容です。
自分の環境がHomeかどうかは、設定の「システム」→「バージョン情報」の「Windowsの仕様」で確認できます。Pro・Enterprise・Educationであれば、原因は次の2系統のどちらかに絞られます。
原因2: サービスが登録されていないケース
Windows Pro・Enterprise環境であっても、仮想化サービスが正しく登録されず検出に失敗することがあります。主な経路は2つです。機能自体は有効なのに内部のサービススタックが登録されない経路と、管理者権限なしでインストールした経路です。
機能内部のサービス登録が抜けている場合
Windows Pro・Enterprise環境でも、Virtual Machine Platformの機能自体は有効なのに、内部のサービススタック(HNS・vmcompute・vfpext)が正しく登録されていないことがあります。公式のトラブルシューティング手順はこの状態を「Missing HCS services: HNS, vmcompute, vfpext」というエラーで説明しており、これは今回の「Virtualization is not enabled」とは文言が異なります。ただしどちらも仮想化スタックの検出に失敗した状態を指すため、診断・対処の手順は共通です。公式の手順は、この状態を診断・修正する具体的な手順を示しています。
まず機能とサービスの状態を確認します。
Get-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform
Get-Service vmcompute, hns機能が無効、またはサービスが見つからない場合は再度有効化します。
Enable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform -All再起動は必ず「再起動」を使い、シャットダウンしてから電源を入れ直す操作は避けます。Windowsの高速スタートアップが有効な環境では、シャットダウンのサイクルだと仮想化サービスが未初期化のまま残ることがあるためです。VMwareやVirtualBoxを同じ端末で使っている場合は、Windowsハイパーバイザーが起動時に立ち上がる設定になっているかも確認します。
bcdedit出力のhypervisorlaunchtypeがAutoになっていない場合は、次のコマンドで設定してから再起動します。
bcdedit /set hypervisorlaunchtype auto管理者権限なしでインストールした場合
公式のWindows展開ガイドは、個人インストールについて「Coworkを含むフル機能を使うには管理者権限が必要」と明記しています。管理者権限を持たないユーザーでもインストール自体は完了しますが、その場合Cowork on desktop自体が使えません。これとは別に、per-userのAdd-AppxPackageによるインストールでは、Coworkが依存するWindowsサービスの登録が行われないまま完了することがある、とも説明されています。今回の「Virtualization is not enabled」がこの経路とどこまで一致するかは公式に明記されていませんが、同様の検出エラーにつながる可能性はあります。インストール時にUACプロンプトが出た記憶がない、あるいは「いいえ」を選んで進めた心当たりがある場合は、いったんアンインストールし、管理者権限を許可したうえで入れ直す価値があります。
原因3: 検出ロジック側の問題で正しい環境でも出ることがある
BIOSでのIntel VT-x有効化、Windows機能(Hyper-V・Virtual Machine Platform・Windows Hypervisor Platform)の有効化、bcdeditでのhypervisorlaunchtype auto設定は、いずれも定番の対処です。GitHub Issueには、これらをすべて済ませsysteminfoで「A hypervisor has been detected」まで確認しても「Virtualization is not enabled」が消えないという報告があります。Dell・Lenovo・ASUS・MSIなど複数メーカーのWindows 10 Pro・Windows 11 Pro環境から、2026年2月に相次いで寄せられました。なおこのIssueはstate_reason=completedとしてクローズされていますが、タイムラインに修正コミットへの参照は見当たりません。同じ症状が出た場合は、まず手元の環境が最新版かを確認するとよいでしょう。
ある報告者は、Coworkが内部で使っているとみられるWMIクエリ(VirtualizationFirmwareEnabled・VMMonitorModeExtensions・SecondLevelAddressTranslationExtensions)に着目しています。これらの値はHyper-V稼働中の環境ではすべてFalseを返すといい、ハイパーバイザーがハードウェア層を抽象化する以上、想定どおりの挙動だと分析しています。この分析はコミュニティ側の調査であり、Anthropicによる公式な原因確認ではない点には注意が必要です。ログにはyukonSilver not supported (status=unsupported)やVM not supported (win32/x64), skippingという行が残っていたとする報告もありますが、これらの内部コンポーネント名について公式な説明は見当たりません。
診断ログでどのチェックが失敗しているか特定する
公式の手順書は、どの項目が失敗しているかを個別に確認する方法も示しています。Claude Desktopの「ヘルプ」→「トラブルシューティング」→「ログを表示」からsupported-features-info.jsonを開くと、チェック項目ごとの結果を確認できます。原因の切り分けに迷ったら、まずこのファイルを見るのが遠回りになりません。
対処の優先順位
切り分けから対処までを次の順で試します。
| 順番 | 確認・対処 | 対象 |
|---|---|---|
| 1 | 確認・対処Windowsのエディションを確認する(Home以外か) | 対象全員 |
| 2 | 確認・対処インストール時にUACプロンプトを許可したか確認し、必要なら管理者権限で入れ直す | 対象全員(インストール直後) |
| 3 | 確認・対処Get-WindowsOptionalFeatureとGet-Service vmcompute, hnsで状態確認 | 対象Pro/Enterprise |
| 4 | 確認・対処機能を再有効化し、シャットダウンでなく「再起動」で反映させる | 対象Pro/Enterprise |
| 5 | 確認・対処VMware/VirtualBox併用時はbcdeditでhypervisorlaunchtypeを確認 | 対象併用環境 |
| 6 | 確認・対処supported-features-info.jsonで失敗項目を特定する | 対象解消しない場合 |
Windows Homeの場合はこの表の1で原因が確定し、2以降を試しても解消しません。
管理対象デバイスでは組織ポリシーが仮想化を止めていることもある
会社支給のパソコンなど組織が管理するデバイスでは、セキュリティポリシーが仮想化機能自体を制限しているケースもあります。個人の再起動作業だけでは解決しないため、IT管理者に仮想化機能の制限有無を確認してもらう必要があります。組織側でMSIXパッケージを一括導入している場合の設定キーや配布手順はClaude DesktopをWindowsで一括導入する手順(MSIX)に、Cowork固有のMDM管理者設定はCoworkのMDM管理者設定にまとめています。
「workspace unavailable」との違い
似た文脈で出る別のエラーに「workspace unavailable」があります。「Virtualization is not enabled」がVM起動前の事前チェックで止まるのに対し、「workspace unavailable」は隔離VMが一時的に起動できていない状態を示すエラーです。ファイル操作やWeb検索は動き続ける点も異なります。詳しい切り分けはCoworkで「workspace unavailable」と出たときの対処法にまとめています。Cowork全体の仕組みを確認したい場合はClaude Cowork(クロードコワーク)とはが入り口になります。
まとめ
「Virtualization is not enabled」が出たら、まずWindowsのエディションを確認します。Homeであればこの制限が原因で、回避策はありません。Pro・Enterpriseであれば、インストール時に管理者権限を許可したかを確認したうえで、Virtual Machine Platformの機能とサービスの状態を確認し、シャットダウンでなく再起動で反映させ、必要に応じてbcdeditでハイパーバイザーの起動設定を見直します。ここまで試しても解消しない場合は検出ロジック側の問題である可能性があるため、supported-features-info.jsonで失敗項目を特定しつつ、関連するGitHub Issueの最新状況もあわせて確認します。