Claude_Coworkでdevice_bashが使えない

この記事は Claude を用いて執筆しています。 ただし、実際の切り分け・検証・判断は手元の Windows 環境で行った結果に基づいており、内容は実体験ベースで整理しています。

実験用の Windows 端末で Claude（Cowork）に作業を任せようとしたところ、途中で Claude 自身が次のようなことを言い出しました。

1
2
この端末ではリモートシェル（device_bash）は提供されていません。
私が新たに有効化できる機能ではありません。

ファイルの一覧取得や転送はできるのに、PC 上でコマンドを実行するシェルだけが使えない、という状態です。

一見すると「アプリのバージョンが古い」「アカウントに機能が展開されていない」といった、ユーザー側ではどうにもならない話に見えます。しかし最終的な原因は BIOS で仮想化支援（Intel VT-x）が無効だったために、Windows の Virtual Machine Platform が機能せず、Claude がコードを実行するための VM が動いていなかったことでした。

この記事では、まず 「何が起きていたのか」と「どう直したのか」 を簡潔にまとめ、その後で詳細な経緯を書きます。急いでいる方は「トラブルの概要」と「解決策」だけ読めば十分です。

トラブルの概要

発生した症状

Claude Desktop で PC を紐づけると、フォルダの一覧取得やファイルの受け渡しは正常にできる
しかし、PC 上でコマンドを実行するシェル（内部ツール名 device_bash）だけがツール一覧に出てこない
エラーメッセージは一切出ない。ツールが最初から存在しないように見える
Claude に理由を聞いても「この構成では提供されていない」「自分では有効化できない」という回答で、原因は推測止まり

シェルが使えないと、ダウンロードやハッシュ検証などを PC 上で直接実行できません。一度クラウド側で処理してからファイルを転送する、という遠回りになり、転送サイズの上限にも引っかかります。

環境

ThinkPad X270
Windows 11 Home（クリーンインストール直後）
Claude Desktop（2026 年 9 月時点の最新版）
クラウド上の Claude のセッションから、Claude Desktop 経由でこの PC を紐づけて利用
BIOS の仮想化支援（Intel VT-x）は無効のまま

もともと USB 機器の実機検証用に用意した端末で、仮想マシンを動かす予定がなかったため、BIOS の仮想化設定は触っていませんでした。

用語の整理：「この端末」「シェル」とは何か

Claude の回答に出てくる「この端末」が、クラウド側を指すのか手元の PC を指すのか分かりにくかったので、先に整理しておきます。

この構成では、Claude が扱う実行環境が 2 つあります。

実行環境	場所	Claude から見えるもの
クラウド側の作業環境	Anthropic のサーバ上の Linux サンドボックス	Bash などのツール。手元の PC のファイルには直接触れない
紐づけた PC	手元の Windows 機	`device_list_dir`、`device_stage_files`、`device_commit_files`、`device_bash` などのリモート端末用ツール

Claude が「この端末」と言っていたのは後者、つまり手元の PC です。そして今回使えなかった device_bash は、手元の PC 側でコマンドを実行するためのシェルです。

ファイル系のツールは使えてシェルだけが無い、という状態は、この 2 系統が別々に動いていることを示しています。

一見したときの誤解しやすいポイント

この状況だけを見ると、次のように考えがちです。

Claude Desktop のバージョンが機能に対応していない
アカウントや端末構成に、まだ機能が展開されていない
WSL2 が入っていないから動かない
Claude 自身が「有効化できない」と言っているので、ユーザー側では打つ手がない

実際、Claude の回答もこの方向の推測でした。しかも後で分かったことですが、その説明の一部（WSL2 ベースかもしれない、など）は実態とずれていました。

AI が自分の実行環境について説明するとき、その内容が正しいとは限りません。 ツールが一覧に無いことを「非対応」と言い切っていても、実際には前提条件が足りていないだけ、ということがあります。

実際の原因

Anthropic のヘルプセンターには、次のことが書かれています。

Cowork をローカルで実行する場合、Claude の会話処理やファイルの読み書きは PC 上で直接動くが、シェルコマンドや Claude が書いたコードは専用の Linux VM の中で実行される
その VM は、Windows では Hyper-V によってホスト OS から隔離されている
Windows で Cowork を使うには Virtual Machine Platform が必要
VM が起動できない間も、ファイル操作や Web のツールは動き続け、シェルとコード実行だけが使えなくなる

最後の点は、今回の「ファイル系は使えるのにシェルだけ無い」という症状とそのまま一致します。

今回の端末では BIOS で VT-x が無効だったため、Windows のハイパーバイザーが起動できず、Virtual Machine Platform が機能しない状態でした。流れとしては次のとおりです。

1
2
3
4
5
BIOS で VT-x が無効
  → Windows のハイパーバイザーが動かない
  → Virtual Machine Platform が機能しない
  → Claude のコード実行用 VM が起動できない
  → シェル（device_bash）が提供されない

なお、device_bash がこの VM 上で動いていると公式に明記されているわけではありません。ただ、公式に説明されている VM の前提条件を満たしたところで復旧したので、同じ仕組みに依存していると考えるのが自然です。

解決策

結論

BIOS で Intel VT-x を有効にし、Windows の Virtual Machine Platform を有効にして再起動することで解決しました。

Windows 11 Home のままで復旧しています。Pro へのアップグレードは不要でした。

手順

1. BIOS で VT-x を有効にする

PC を再起動して BIOS 設定画面に入り、仮想化支援を有効にします。

ThinkPad の場合は、Security → Virtualization の中に次の 2 項目があります（機種によって場所や名称は異なります）。

Intel (R) Virtualization Technology ← これを Enabled にする
Intel (R) VT-d Feature

必要なのは前者（VT-x）です。後者（VT-d）との違いは後述します。

保存して起動したら、タスクマネージャーの「パフォーマンス」→「CPU」で、右下の「仮想化」が「有効」になっていることを確認します。PowerShell でも確認できます。

1
(Get-CimInstance Win32_Processor).VirtualizationFirmwareEnabled

True が返れば有効です。

2. Virtual Machine Platform を有効にする

管理者として PowerShell を開き、次を実行します。

1
Enable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform -All

GUI で行う場合は、「Windows の機能の有効化または無効化」（optionalfeatures）を開き、「仮想マシンプラットフォーム」にチェックを入れます。

3. 「再起動」する

「シャットダウン → 電源オン」ではなく「再起動」を選んでください。

Windows の高速スタートアップが有効だと、シャットダウン経由では仮想化関連のサービスが正しく初期化されないことがあります。これは Anthropic のドキュメントにも注意書きがあります。

4. Claude Desktop を起動し直して確認する

Claude Desktop を起動し、新しいセッションで PC を紐づけて、シェルが使えるか確認します。Claude に「device_bash は使えますか」と聞けば、ツール一覧に出ているかどうかを答えてくれます。

確認コマンド

うまくいかない場合は、次の順に状態を確認します。

1
2
3
4
5
6
7
8
# 1. ファームウェア側の仮想化支援
(Get-CimInstance Win32_Processor).VirtualizationFirmwareEnabled

# 2. Virtual Machine Platform の状態
Get-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform

# 3. 関連サービスが存在し、動いているか
Get-Service vmcompute, hns

どのチェックで引っかかっているかは、Claude Desktop の Help → Troubleshooting → Show Logs から supported-features-info.json を開くと確認できます。

VT-x と VT-d の違い

BIOS で名前が似た項目が並んでいるので、混同しやすいところです。

項目	役割	Hyper-V / VMP に必要か
VT-x（Intel Virtualization Technology）	CPU の仮想化支援。ハイパーバイザーが仮想マシンを動かすための命令セット	必要
VT-d（Virtualization Technology for Directed I/O）	I/O の仮想化（IOMMU）。PCI デバイスを VM に直接割り当てたり、DMA 攻撃を防いだりするための機能	必須ではない

VT-x が「VM を動かすための機能」、VT-d が「VM やデバイスのメモリアクセスを整理するための機能」と考えると分かりやすいです。VT-d だけ有効にしても、ハイパーバイザーは起動しません。

VT-d はセキュリティ機能（カーネル DMA 保護など）にも使われるので、有効にしておいて困ることは基本的にありませんが、今回の問題を解決するのは VT-x のほうです。

注意点

Windows Home について。 非公式の解説記事では「Cowork は Hyper-V が必要なので Home では動かない」とするものと、「Home でも Virtual Machine Platform があれば動く」とするものがあり、見解が割れています。Anthropic の公式ドキュメントに書かれている要件は Virtual Machine Platform のみです。今回の環境では、Home のまま device_bash が使えるようになりました。

VMware や VirtualBox が入っている場合。 Windows のハイパーバイザーが起動時に読み込まれる設定になっているか確認します。管理者のコマンドプロンプトで bcdedit を実行し、hypervisorlaunchtype が Auto になっていなければ、次を実行して再起動します。

1
bcdedit /set hypervisorlaunchtype auto

Windows 自体が仮想マシン上で動いている場合。 ネステッド仮想化に対応していない VM や VDI 環境では、Cowork は動作しません。

実験用端末で有効にする場合。 Virtual Machine Platform を有効にすると、Windows 自体もハイパーバイザー上で動く構成に変わります。通常の用途ではほぼ影響はありませんが、USB 機器の挙動を検証するなど「素のハードウェア」を前提にしている端末では、前提が変わったことを記録しておき、検証の前に一度動作を確認しておくと安心です。

最短のまとめ

次の条件に当てはまるなら、同じ原因の可能性が高いです。

Claude Desktop で PC を紐づけると、ファイル操作はできるのにシェルだけ使えない
Claude が「この端末ではシェルは提供されていない」と言う
タスクマネージャーで CPU の「仮想化」が「無効」になっている

この場合は、BIOS で VT-x を有効にして、Virtual Machine Platform を有効にし、再起動してください。

経緯や切り分け

ここからは、実際にどう進んだかを時系列で書きます。結論だけ知りたい方は飛ばして構いません。

1. クリーンインストール直後の端末で Claude を使い始める

Windows 11 Home をクリーンインストールし、Claude Desktop を入れて PC を紐づけました。この端末には、ツール類のダウンロード・ハッシュ検証・フォルダ整理を任せる予定でした。

フォルダの一覧取得やファイルの配置は問題なく動いたので、この時点では異常に気づいていません。

2. Claude が「シェルは提供されていない」と言い出す

作業の途中で、Claude が「この端末に device_bash は提供されていない」と言い出しました。代わりに、ダウンロードや検証はクラウド側で行い、小さいファイルは転送、大きいファイルは手動でコピーしてほしい、という回避策を提案してきます。

「この端末」がどこを指すのか分からなかったので詳しく聞くと、Claude の説明は次のようなものでした。

device_bash は、ユーザーの PC 内にある Linux の実行環境で動くシェルとされている
WSL2 ベースか、アプリ内蔵の軽量 VM を想定しているようだ
提供されていない理由は確認できない。アプリが未対応か、WSL2 などの前提が無いか、機能がまだ展開されていないか、のいずれかと推測する
自分の側に有効化する設定は無い

理由は推測で、しかも「自分では有効化できない」と言い切っています。 ここで諦めると、クラウド経由の遠回りな作業を続けることになります。

ただ、推測の中に「前提となる何かが入っていない」という候補があったので、端末側で試してみることにしました。

3. WSL を導入する → 変化なし（しかも WSL1 で起動）

「WSL2 が前提かもしれない」という話だったので、まず WSL を導入しました。インストール自体は完了し、ディストリビューションも起動しました。

しかし、device_bash は出てきません。

後から確認すると、WSL は WSL1 として動いていました。

1
wsl -l -v

VERSION の列が 1 になっていれば WSL1 です。

WSL1 は仮想マシンを使わず、Linux のシステムコールを Windows 側で変換して動く仕組みなので、仮想化支援が無効でも動きます。つまり 「WSL が起動したから仮想化は大丈夫」とは言えず、むしろ WSL1 で動いていたこと自体が、仮想化が効いていないサインでした。

4. BIOS で VT-x を有効にする

WSL2 が使えない理由を考えると、仮想化支援の設定に行き着きます。タスクマネージャーで確認すると、CPU の「仮想化」が「無効」でした。

この端末は仮想マシンを動かす予定がなかったので、BIOS の仮想化設定を触っていませんでした。BIOS に入り、Intel (R) Virtualization Technology（VT-x）を有効にしました。

5. Virtual Machine Platform を有効にする → 復旧

続けて Windows 側で Virtual Machine Platform を有効にし、再起動しました。

Claude Desktop を起動し直して PC を紐づけると、device_bash が使えるようになりました。

なお、この過程では Claude Desktop の再インストールや端末の紐づけ直しも行っています。これらが必須だったかどうかは切り分けていません。少なくとも、VT-x と Virtual Machine Platform を有効にするまでは、何をしても復旧しませんでした。

6. 公式ドキュメントで裏取り

Claude の説明が推測だったので、Anthropic の公式情報を確認しました。ヘルプセンターの記事で、次の点が確認できます。

ローカル実行のシェルやコードは、Hyper-V で隔離された Linux VM で動く（Cowork architecture overview）
Windows では Virtual Machine Platform が必要（Deploy Claude Desktop for Windows）
VM が起動できないときは、ファイルや Web のツールは動き、シェルとコード実行だけが使えなくなる（Cowork architecture overview）

「WSL2 ベースかも」という Claude の推測は外れていて、実際は Hyper-V 系の VM でした。一方で「前提となる何かが入っていない」という候補は当たっていた、ということになります。

ちなみに、復旧後に Claude がまとめた経緯のメモでは、有効にした BIOS 項目が「VT-d」になっていました。実際に有効にしたのは VT-x です。AI のまとめをそのまま記録に残すと、こういう取り違えが紛れ込みます。

7. 今回の結論

事象の表面

ファイル操作はできるのに、シェルだけがツール一覧に無い
エラーは出ず、Claude も「提供されていない」「有効化できない」と答える
アプリやアカウント側の問題に見える

実際の原因

Claude のシェルやコード実行は、Hyper-V で隔離された Linux VM で動く
その VM には Virtual Machine Platform が必要で、さらにその前提として BIOS の VT-x が必要
VT-x が無効だったため VM が起動できず、シェルが提供されなかった

実務的な見立て

ツールが一覧に無いことは、非対応を意味しない。 前提条件が足りないだけのことがある
AI の自己説明は推測を含む。 自分の実行環境の仕組みや、有効化できるかどうかを正しく把握しているとは限らない
WSL が動いたことは、仮想化が有効な証拠にならない。 WSL1 は仮想化なしで動く
実験用やキッティング直後の端末ほど、BIOS の仮想化設定が無効のまま残っていて踏みやすい

同じ症状に遭遇した人向けの確認ポイント

まず確認したいこと

仮想化支援が有効かどうかを確認します。

1
2
(Get-CimInstance Win32_Processor).VirtualizationFirmwareEnabled
Get-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform

前者が False、または後者が Disabled なら、この記事のケースの可能性が高いです。

次にやること

BIOS で VT-x（Intel Virtualization Technology）を有効にする
Virtual Machine Platform を有効にする
シャットダウンではなく「再起動」する
Claude Desktop を起動し直し、シェルが使えるか確認する

それでも駄目なら、Claude Desktop のログ（supported-features-info.json）で、どのチェックが失敗しているかを確認します。

いきなり遠回りしなくてよいもの

今回のケースに限れば、次の作業は遠回りでした。

WSL の導入（仮想化が無効なら WSL1 で動くだけで、解決しない）
Windows 11 Pro へのアップグレード（Home のまま解決した）
Claude の「提供されていない」という回答を受けて、クラウド経由の回避策で作業を続けること

まずタスクマネージャーで「仮想化」の表示を見るのが一番早いです。

まとめ

今回のトラブルは、表面上は「Claude のシェル機能がこの端末に提供されていない」ように見えたものの、実際には BIOS で VT-x が無効だったために Virtual Machine Platform が機能せず、Claude のコード実行用 VM が起動できなかった ことが原因でした。

解決策は、BIOS で VT-x を有効にし、Virtual Machine Platform を有効にして再起動すること。Windows 11 Home のままで解決しています。

Claude が自分で「有効化できない」と言っていても、原因が端末側の設定にあることはあります。実験用の端末など、仮想化を使う予定のなかった PC で Claude に作業を任せる場合は、最初に仮想化の設定を確認しておくと回り道をせずに済むと思います。

参考

余談（人間執筆。）

AIがすごく便利な時代になりましたね。
昔はChatだけだったのが、今や、PCを直接調査してくれるという。
もちろんセキュリティリスクは山のようにありますが、ログを解析したり、実際にコマンドを実行しながらのログ収集が驚くほど楽になった。
ChatGPTのworkもClaudeのCoworkも使いますが、使用量をたくさん持っていくのがさみしいところ。
どちらかというと、マウス操作をさせるより、deviceBashを使って、Shell操作をさせるほうがコンテキストとしては少なく済みそう。
これからも活用していきたいところ。