ChromebookのLinux環境でCoworkが使えない理由と対処法

ChromebookのLinux開発環境(通称Crostini)にClaude Desktopを入れても、Coworkタブだけが起動しないことがあります。原因はインストールの失敗ではなく、Coworkが要求するvhost_vsockというカーネルモジュールをCrostiniのコンテナが持てない点にあります。公式ドキュメントはこの組み合わせを「手動でも追加できない」と明記しており、Chromebook上でCowork単体を仮想マシンとして動かす道は事実上ありません。使える入り口はAndroid版アプリやChromeサイドパネルなど、クラウド実行に振り切ったものに絞られます。

Chromebookで何が起きるか

Claude DesktopのLinux版はUbuntu 22.04以降・Debian 12以降を公式対応としており、x86_64・arm64のどちらにも対応します。CrostiniはDebian系のコンテナ環境を提供するため、apt install claude-desktop自体は通ることが多く、ChatタブとCodeタブは問題なく動きます。つまずくのはCoworkタブだけです。

CoworkはDispatchや長時間のエージェント作業を担うタブで、Linux版ではデスクトップアプリがQEMUとKVMでホストする仮想マシンの中でその処理を実行します。ChatタブやCodeタブがホストのプロセスとして動くのに対し、Coworkだけは仮想化そのものを前提にした別構造です。この仮想化レイヤーがChromebookでは成立しません。

もう一つ押さえておきたいのがアーキテクチャです。公式の対応表はx86_64とarm64の両方を挙げており、arm64チップを積んだ低価格帯のChromebookも対象に含まれます。裏を返すと、Cowork起動の失敗はIntel・AMD搭載機に限った話ではなく、arm64のChromebookでも同じvhost_vsockの壁に当たります。アーキテクチャの違いはChat・Codeタブの動作可否には影響しますが、Coworkが起動するかどうかを左右する要因ではありません。

Coworkが要求する仮想化の中身

Coworkを動かすには3つの条件がそろう必要があります。

3つ目が曲者です。/dev/kvmはデスクトップ環境によってはグループなしでも開けますが、/dev/vhost-vsockはkvmグループのメンバーだけが開けるデバイスファイルで、Coworkはこの両方を必要とします。sudo usermod -aG kvm $USERを実行してログアウト・再ログインしても、/dev/vhost-vsock自体がカーネル側に存在しなければ意味がありません。

この仮想マシンサンドボックスは、Cowork設計上の付随機能ではありません。Claude Code DesktopのリファレンスにはrequireCoworkFullVmSandboxという管理者向け設定が別途あり、組織はCoworkセッションを常に完全なVMサンドボックスの中で実行するよう強制できます。仮想化レイヤーはオプションの安全策ではなく、Coworkというタブが成立するための土台そのものだと分かります。

Crostiniでは「直せない」エラーになる

vhost_vsockが絡むエラーには、実は2つの種類があります。1つ目はモジュールはカーネルに存在するのに読み込まれていないだけのケースです。この場合は次のコマンドで直ります。

sudo modprobe vhost_vsock

毎回のブートで自動的に読み込むには、続けて次を実行します。

echo vhost_vsock | sudo tee /etc/modules-load.d/vhost_vsock.conf

2つ目が、Chromebookで実際に起きているケースです。/dev/vhost-vsockが見つからないうえ、実行中のカーネルに/lib/modules以下のモジュールディレクトリ自体が存在しない場合、Coworkタブは「カーネルが必要な仮想化サポートを含んでおらず、手動でも追加できない」旨を表示します。公式ドキュメントはこの組み合わせが「ChromeOSやコンテナベースのLinux環境で一般的」だと明記しています。

CrostiniをはじめとするLinuxコンテナの多くは、コンテナ自身が独立したカーネルを持たず、ホスト側(Chromebookの場合はChromeOS)のカーネルを間借りする構成を採ります。ホストのカーネルはChromeOS自身の用途に合わせて構成されており、コンテナ側から/lib/modulesを通じて追加のカーネルモジュールを読み込む仕組みは用意されていません。Coworkが求めるvhost_vsockのような低レベルのカーネル機能は、この構成では届かないと考えられます。

Chromebookでの実務上の回避策

Chromebook上でCoworkのデスクトップタブそのものを直す方法は、公式ドキュメントを見る限り存在しません。実務的な回避策は、Coworkのクラウド実行に振り切った入り口へ乗り換えることです。

Coworkのウェブとモバイル対応がまとめている通り、Coworkにはデスクトップ以外に3つの入り口があります。Web(claude.aiのHomeタブ)、モバイル(Claude for iOS / Android)、そしてChromeサイドパネルです。claude.comの製品ページで「Download for ChromeOS」を選ぶと、Chromebook向けの専用ビルドではなくGoogle PlayストアのClaude公式Androidアプリ(com.anthropic.claude)に案内されます。ChromeOSはAndroidアプリをそのまま実行できるため、Anthropic自身がChromebookユーザーをこの経路に誘導している形です。

Coworkがクラウド実行かローカル実行か見分ける方法で扱った通り、Web・モバイルから始めたセッションはそもそも常にAnthropicのクラウドで動きます。ローカルファイルへのアクセスやブラウザの実操作だけがデスクトップアプリ経由に限られる仕組みなので、Chromebookで欠けているのはこの「ローカル接続」の部分だけです。タスクの起動・進捗確認・承認応答はAndroid版アプリやWebで完結します。

コーディング作業に限っては、Cowork以外の道もあります。Claude Code CLIはターミナルで動くコマンドラインツールで、QEMUやKVMのような仮想マシンを必要としません。Claude Code install完全ガイドのシステム要件にも仮想化の記載はなく、Debian系ディストリビューション向けのインストール手順がそのままCrostiniのコンテナでも使えます。デスクトップアプリのLinux版インストール手順はUbuntu・Debianを想定した一般的なapt導入を解説していますが、Cowork自体が使えない点はChromebookに固有の制約です。

よくある質問

ファームウェアで仮想化を有効にすれば直るか

直りません。ファームウェアのハードウェア仮想化は「ハードウェア仮想化」の要件を満たすための項目で、/dev/vhost-vsockとモジュールディレクトリの不在という別の要件には関係しません。加えて、一般向けのChromebookはファームウェア設定そのものを開発者モード抜きで触れないため、この項目を試すこと自体が難しい端末がほとんどです。

今後のアップデートでChromebookでもCoworkが起動するようになるか

公式ドキュメントはこの状況を「ChromeOSやコンテナベースのLinux環境で一般的」と、アプリ固有の不具合ではなくホスト環境側の性質として説明しています。ホストのカーネル構成に踏み込む変更は、Claude Desktop単体のアップデートで解決する種類の話ではなさそうです。この制約を解消する計画への言及は公式ドキュメントに見当たりません。

まとめ

ChromebookのCrostiniでClaude Desktopをインストールできても、Coworkタブだけはvhost_vsockカーネルモジュールの欠如で起動しません。原因は設定ミスではなく、コンテナがホストのカーネルを間借りする構成そのものにあり、公式ドキュメントも手動での追加はできないと明記しています。Chromebookで作業を進めるなら、Coworkのクラウド実行に対応したAndroid版アプリ・Web・Chromeサイドパネルのいずれかに乗り換え、ローカルファイルを扱う場面だけは他の端末のデスクトップアプリに任せるのが現実的な線引きです。コーディングだけならCrostini上のClaude Code CLIも選択肢に入ります。