Claude DesktopとCoworkが重いときの原因と対処法

Claude Desktopが重い、ファンが回りっぱなしになる、といった症状の多くは、Coworkタブが使う隔離VM(仮想マシン)が原因です。タブごとに負荷の出どころが違うため、まずどのタブで重くなっているかを切り分けると、対処が早く決まります。

「重い」と「遅い」は別の症状

「重い」と「遅い」は別の症状として切り分けて考えます。「遅い」はClaudeの応答生成そのものに時間がかかる症状で、モデルの選択や指示の複雑さが主な要因です。一方「重い」は、ファンが高速回転する・アプリの切り替えがもたつく・パソコン全体が固まるといった、CPUやメモリの消費量そのものが原因の症状です。

本記事が扱うのは後者です。応答が遅いだけで動作自体は軽い場合は、モデルや指示内容の見直しが対処になるため、本記事の手順は当てはまりません。

Desktopの3タブで負荷の出どころが違う

Claude DesktopにはChat・Cowork・Codeの3タブがあり、それぞれ動く場所が異なります。Chatはローカルでファイルアクセスを行わない会話専用タブで、負荷はごく軽量です。CodeタブはClaude Code CLIと同じエンジンをローカルでネイティブに動かし、大きなコードベースを扱うと相応にCPU・メモリを使います。

Coworkだけが構造的に重い理由は、実行の仕組みそのものが他の2タブと違うからです。公式のアーキテクチャ解説によると、Coworkのローカルセッションは2つの実行環境で構成されています。Claudeとの会話やファイル読み書きはデバイス上でネイティブに動く一方、シェルコマンドとコードの実行だけは、ホストOSから隔離された専用のLinux VM内で行われます。このVMはmacOSではApple Virtualization.framework、WindowsではHyper-Vというハイパーバイザーが担っています。

Coworkの隔離VMが重くなる実例

このVM構造が実際にどれだけ重くなるかは、anthropics/claude-codeリポジトリのGitHub issue #22543で具体的に報告されています。報告者の環境はmacOS・システムRAM 8GBです。Coworkの利用後にVMバンドル(~/Library/Application Support/Claude/vm_bundles/claudevm.bundle/rootfs.img)が10GBまで肥大化し、アイドル時のCPU使用率が24〜55%まで上昇したと記録されています。同じissueのコメント欄では、Windows版でも%AppData%\Roaming\Claude\vm_bundles\claudevm.bundle\rootfs.vhdxという同種のファイルが確認されています。コメント投稿者の一人は、サイズが21GBを超えたと報告しています。

このissueにはbug・high-priority・performance・area:desktopのラベルが付いており、開発チーム側のトリアージ対象として扱われていることがうかがえます。

Linux版のDesktopアプリでは、Coworkを使うためにQEMUとUEFIファームウェア、ハードウェア仮想化(KVM)へのアクセスが前提条件として明記されています。これらが揃っていないとCoworkタブ自体が起動要件エラーを表示するため、Linux環境で「重い」以前に「Coworkが使えない」場合は、ハードウェア仮想化が有効になっているかをまず確認します。

Coworkをクラウドセッションに切り替える

ローカルの隔離VMが負荷の主因である以上、最も直接的な対処はCoworkをクラウドセッションで動かすことです。公式のアーキテクチャ解説によると、Coworkのセッションは既定でクラウドセッション(Anthropicのサーバー上で動く方式)です。隔離VMを使うローカル実行は、既存のデスクトップ展開向けに残された選択肢と位置付けられています。

セッション開始時に実行環境をクラウド側にすると、コード実行はAnthropicのサーバー上に用意された一時サンドボックスで行われ、パソコン側にVMが立ち上がりません。ローカルファイルやブラウザーが必要な場面はClaude Desktopアプリ経由で接続済みフォルダーにアクセスする形になるため、動作の仕組み自体が変わる点は踏まえておく必要があります。Team・Enterpriseプランでは、組織側でクラウドセッションの可否を制御している場合もあります。

Codeタブ・CLIエンジン側が重いとき

Coworkを使っていない、あるいはクラウドセッションに切り替えても重いままの場合は、Codeタブが使うClaude Code CLIエンジン自体の負荷を疑います。公式のトラブルシューティングガイドは、大きなコードベースを処理する際にCPU・メモリを大きく消費し得るとした上で、次の手順を案内しています。

1. /compactを定期的に実行し、コンテキストサイズを小さく保つ
2. 大きな作業の区切りでClaude Codeを閉じて再起動する
3. 大きなビルドディレクトリを.gitignoreに追加する
4. CLIではclaude --safe-modeで起動し、プラグイン・MCPサーバー・フックのどれが原因かを切り分ける(このフラグにDesktop側の対応する設定は無く、切り分け自体はCLIから行う)

/compact

これらを試してもメモリ使用量が高止まりする場合、/heapdumpコマンドで詳細な診断ファイルを書き出せます。コマンドメニューには出てこない隠しコマンドなので、全部タイプして実行する必要があります。実行すると会話内にRSS(常駐セットサイズ)・JSヒープ・配列バッファ・ネイティブメモリの内訳とリーク兆候の有無が要約表示され、原因がJSヒープ側かネイティブメモリ側かをその場で切り分けられます。.heapsnapshotファイルには会話内容や認証情報を含む全文字列が残るため、公開のissueに添付しないよう注意が必要です。書き出す内容や報告先の手順はClaude Codeの/heapdumpでメモリ使用量の高さを診断するにまとめています。

Mac・Windowsでリソース使用量を確認する

どのプロセスがどれだけ消費しているかは、OS標準のツールで確認できます。Macでは「アクティビティモニタ」を開き、CPUタブ・メモリタブでClaude関連のプロセス(Claude、Virtual Machine Serviceなど)を確認します。WindowsではCtrl+Shift+Escでタスクマネージャーを開き、詳細タブでClaudeのプロセス一覧とメモリ使用量を見ます。

アプリ自体が応答しなくなった場合、公式の手順ではMacはCmd+Option+EscのForce Quit、Windowsはタスクマネージャーからのプロセス終了で対処します。強制終了しても会話は失われず、同じフォルダーでclaude --resumeを実行すれば元のセッションに戻れます。

それでも解消しないとき

上記を一通り試しても改善しない場合、前述のGitHub issueではCoworkのVMバンドルとキャッシュを手動で削除する回避策が報告されています。ただしこれは公式の推奨手順ではなくコミュニティ側の報告である点を踏まえ、実施する場合はDesktopアプリを完全に終了してから行います。

改善しない状態が続く、または頻繁に「workspace unavailable」のようなVM関連のエラーが出る場合は、Coworkで「workspace unavailable」と出たときの対処法で扱っているVM起動不能のケースに当てはまっていないかも確認してください。「重い(動くが遅い)」と「workspace unavailable(VMが起動できない)」は別の症状です。403エラーや起動しない・空白画面といった別種の不具合はClaude Code Desktopが起動しない・403エラーの対処法で扱っています。

Web・モバイル版という選択肢

ローカルのリソース制約そのものがネックな場合、Coworkはデスクトップアプリに限らずWeb版・モバイル版からも利用できます。クラウドセッションであればどの面から始めても同じアーキテクチャで動くため、パソコンのスペックに余裕がないときの回避策になります。3つの利用形態の違いはCoworkのウェブとモバイル対応で比較しています。

まとめ

Claude Desktop・Coworkが重い場合、まず疑うべきはCoworkのローカル実行が使う隔離VMです。GitHub issueの報告では10GB超のVMバンドルと高いCPU使用率が確認されており、クラウドセッションへの切り替えが最も直接的な対処になります。Coworkを使っていないのに重い場合は、CodeタブのCLIエンジン側を疑い、/compactや再起動、/heapdumpでの診断を順に試します。原因がVMの起動失敗なのか、起動はしているが重いだけなのかを見分けることが、対処を早める一番のポイントです。