Cowork「Virtualization is not enabled」と出る原因と対処法

CoworkのローカルセッションでBIOSとWindowsの両方の仮想化設定を確認済みのはずなのに、「Virtualization is not enabled」と表示されることがあります。原因はハードウェアの設定ミスとは限りません。2026年2月にはアプリの更新をきっかけに、設定が正しい環境で一斉に出ました。ほかにも、MSIXの入れ方や仮想環境での実行など、BIOSを見直しても動かない原因があります。

表示された文言ごとの確認先

似た文言が複数あるため、画面の表示から読む節を決められます。

このエラーが出るタイミング

Coworkのローカルセッションは、シェルコマンドとコード実行だけをホストOSから隔離した専用VMで行い、Windowsではこの隔離をHyper-Vが担います。「Virtualization is not enabled」は、VMの起動を試みる前の対応チェックで止まるときに出る画面です。#27316に貼られたログでは、startVMがskippingになっていました。エラーメッセージの全文は次のとおりです。

Virtualization is not enabled. Claude's workspace requires hardware virtualization (Hyper-V). Enable virtualization in your computer's BIOS/UEFI settings, then restart.

メッセージはBIOS設定を促しますが、チェックで止まる理由はそれだけではありません。また、この話はローカルセッションに限られます。クラウドのセッションは、Anthropicが管理する基盤の隔離された一時サンドボックスでエージェントとコード実行が動くため、端末のVMを使いません。

設定が正しいのに出たとき: 2026年2月のアプリ更新

最初に疑う価値があるのは、アプリ側の不具合です。GitHubのIssue #27316には、Dell・Lenovo・ASUS・MSI・Gigabyteなど複数メーカーのWindows 10 ProとWindows 11 Proから報告が集まりました。報告者の多くは、BIOSの仮想化、Hyper-V、Virtual Machine Platform、Windows Hypervisor Platformを有効にし、bcdeditでhypervisorlaunchtype autoを設定し、systeminfoで「A hypervisor has been detected」まで確認していました。

自分の環境が設定どおりなのに出るときは、Claude Desktopを最新版に更新してから開き直します。Coworkの利用にはWindows版の最新バージョンが必要だと、公式のCoworkの始め方ページにも書かれています。更新後も同じ文言が出る場合は、次節以降の原因を順に見ます。

端末側の設定ではないという調査報告

同じIssueには、同一アカウントの2台で調べた投稿があります。デスクトップPCでは動き、ノートPCだけが失敗するという内容です。失敗する側のログには、起動のたびに次の2行が出ていました。

[cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported)
[startVM] VM not supported (win32/x64), skipping

投稿者はClaudeのアンインストール、データフォルダーの削除、CoworkVMServiceの削除、再起動、再インストールまで試しましたが、最初のログは同じでした。そこから、unsupportedという判定は端末に保存された値ではなく、外部から決まる値ではないかと推測しています。デスクトップPCも1月26日から2月21日の午前まで同じ2行を出し、再インストール後に起動できるようになったそうです。

この分析は一人の投稿者による推測で、Anthropicが原因を確認したものではありません。ログにこの2行が残っている場合は、BIOSやWindowsの設定を触る前に、アプリの更新状況を確かめる手がかりになります。

更新後に別のエラーへ変わった報告

v1.1.3963へ更新した後に、「RPC error -1: failed to ensure virtiofs mount: Plan9 mount failed: bad address」へ変わったという報告もあります。このエラーは別のIssue(#26554)で追跡されていた不具合です。対処はCoworkの「Plan9 mount failed」エラーが出たときの対処法で扱っています。#27316の返信も、プラグイン一覧の取得で出たこのエラーは別件として扱うよう案内していました。

Windows Homeでは動くのか

Homeで出たときは、エディションが原因かどうかについて、資料の記述が食い違っています。

公式のWindows展開ガイドが挙げる必須機能はVirtual Machine Platformで、エディションの指定はありません。Coworkの始め方ページも、Windows版は全有料プランで使えると書いています。報告者はこのIssueを、要件を明記してほしいというドキュメント要望として出していました。

エディションは、設定の「システム」→「バージョン情報」の「Windowsの仕様」で確認できます。Homeで「Plan9 mount failed」が出る場合は、#26554に利用者による回避策の報告が集まっています。

• 古いclaudeプロセスが10個残り、死んだマウント先を占有していた例があります。タスクマネージャーの詳細タブで終了させたら直ったそうです。
• ログのvm_network_modeがicsなら、Home特有の変種で通常の対処が効かないという報告もあります。HomeにはNetNatのWMIクラスがなく、Coworkが別のネットワーク方式に切り替わるという説明です。

どちらも利用者の投稿で、公式の手順ではありません。

管理者権限なしのインストールでサービスが登録されない

仮想化の設定が正しいのに検出に失敗する原因として、公式の展開ガイドはMSIXの入れ方を挙げています。個人インストールでCoworkを含む全機能を使うには、管理者権限が必要です。インストール時にはWindowsのUACプロンプトが出ます。管理者権限がない場合、Claude自体は入りますが、デスクトップ版のCoworkは使えません。

これとは別に、ユーザー単位のAdd-AppxPackageによるインストールは、Coworkが依存するWindowsサービスを登録しないまま完了することがあります。この状態ではClaudeが入ったように見えても、Coworkは起動しません。展開ガイドの対処は、マシン全体に登録するAdd-AppxProvisionedPackageでの再展開です。

Add-AppxProvisionedPackage -Online -PackagePath "Claude.msix" -SkipLicense -Regions "all"

IntuneでMSIXをLOBアプリとして登録した場合も、ユーザーコンテキストでの導入になるため同じ症状につながります。インストール時にUACプロンプトを許可した記憶がない場合は、アンインストールして管理者権限で入れ直す方法があります。

機能内部のサービス登録が抜けている

Virtual Machine Platformの機能は有効なのに、内部のサービススタック(HNS・vmcompute・vfpext)が登録されていないこともあります。展開ガイドはこの状態を「Missing HCS services: HNS, vmcompute, vfpext」というエラーで説明しています。文言は今回のエラーと違いますが、仮想化スタックの検出失敗という点は共通で、診断手順も同じです。vfpextの欠落に絞った対処はCoworkのvfpextエラー(Missing HCS services)を解消する方法にあります。

まず機能とサービスの状態を確認します。

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 Hypervisor Platformは必須か

公式の展開ガイドがCoworkの要件に挙げるのはVirtual Machine Platformで、Windows Hypervisor Platform(WHP)は載っていません。#27316でも、WHPを有効にしたうえで同じエラーが出たという報告が複数あります。WHPをオンにしても直らないときは、この記事の他の原因を順に見ます。

BIOSの仮想化が無効のままの場合

基本の確認に戻ると解決した例もあります。#27316の2026年3月19日の投稿は、BIOSでIntelの仮想化が無効になっていたのが原因で、有効にして動いたと報告しています。タスクマネージャーの「パフォーマンス」→「CPU」にある「仮想化」の欄が「無効」なら、BIOS側の設定が先です。名称はIntel VT-x、AMD-V、SVMなど機種によって違います。

仮想マシン上やVDIでは動かない

Windowsが仮想マシンやVDI(仮想デスクトップ)の中で動いている場合も、検出が通りません。展開ガイドは、入れ子の仮想化(nested virtualization)がない仮想マシンとVDI環境はサポート対象外で、Coworkは動かせないと明記しています。この環境では、ホスト側で入れ子の仮想化を有効にできるかが条件になります。

診断ログでどのチェックが失敗しているか特定する

どの項目が失敗しているかは、ログで個別に確かめられます。Claude Desktopの「ヘルプ」→「トラブルシューティング」→「ログを表示」からsupported-features-info.jsonを開くと、チェック項目ごとの結果が分かります。

切り分けの順番

管理対象デバイスでは配布方式を管理者に確認する

会社支給のパソコンでは、MSIXの配布方式がユーザー単位かマシン全体かで、Coworkの動作が変わります。配布方式は利用者側では変えられないため、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(クロードコワーク)とはが入り口になります。

まとめ

BIOSとWindowsの設定が正しいのに出る場合、原因がアプリの更新状況やインストールの経路にあった例が報告されています。ハードウェア側の再設定を繰り返す前に、この2点から見るという判断があります。