- macOSでCowork機能を有効にすると、システム上に約10GBの仮想マシン(VM)バンドルが自動生成され、パフォーマンスが急激に低下する
- このファイルは
~/Library/配下に保存され、削除しても翌日に再生成される
- これが存在すると、CPU使用率の上昇(24〜55%)、スワップ増加、UIの遅延など、継続的な性能低下が発生する
- 一時的な回避策としてVMバンドルとキャッシュフォルダを削除すると約75%の性能改善があるが、時間が経つと再び遅くなる
- 複数のユーザーが透明性の不足とストレージの浪費を指摘し、VM生成の可否を選べる設定と事前通知を求めている
問題の概要
- Cowork機能を使った後、Claude Desktopが非常に遅くなり、起動遅延・UIのラグ・応答遅延が発生
- 性能低下はセッション中にも徐々に悪化し、VMバンドルファイルが10GBまで増大して自動再生成される
- この問題は**macOS環境(8GB RAM)**で再現される
調査結果
- Cowork機能が生成するVMバンドルは
~/Library/Application Support/Claude/vm_bundles/claudevm.bundle/rootfs.imgに存在
- このファイルは削除しても1日以内に再生成され、自動クリーンアップも行われない
- VMバンドルとキャッシュを削除すると、使用ストレージは11GB → 639MBに減少し、作業速度は約75%向上
- しかし再起動後、数分以内にCPU使用率は**24% → 55%**へ上昇し、**swapins 20K → 24K+**へ増加
- これはメモリリークまたは累積的な処理負荷による性能低下の可能性を示唆する
観測された挙動
- アイドル状態でもCPU使用率が24〜55%
- スワップ活動が継続的に増加し、数分以内に性能低下
- Coworkセッションごとに10GBのVMバンドルを再生成
- **削除後は一時的に改善(75%)**するが、時間の経過とともに再び低下
一時的な回避策
ユーザーフィードバック
- Cowork無効時でもVMが動作してメモリを占有
- 一部ユーザーは21GB超まで肥大化したVMバンドルも報告
- VMはアプリ起動時に自動で再プロビジョニングされ、圧縮ファイル(
rootfs.img.zst)まで残って重複したストレージ浪費が発生
- Coworkを一度も使っていないユーザーでも10GBバンドルを発見し、メモリリークだと認識
- ストレージ容量に制約のあるMacユーザーは無効化オプションの必要性を強調
透明性と信頼性への懸念
- ユーザーは、事前通知なしに12〜20GBのディスクと2GBのRAMを占有する点を問題視
- インストール時または初回起動時の通知、VMの事前ダウンロード可否の選択、Cowork無効化トグルの提供などを提案
- 一部ではVMサンドボックス設計の意図は理解できるものの、説明不足がユーザーの信頼を損なうと指摘
- 「アプリがユーザーに知らせずシステム資源を使うのは信頼を損なう」という意見が多数
1件のコメント
Hacker Newsの意見
こんにちは、Anthropic の Felix です。私は Claude Cowork と Claude Code を担当しています
Cowork は、Linux VM 内で動作する Claude Code エージェントハーネスの上に構築されており、Apple の Virtualization Framework や Microsoft の Host Compute System を通じて実行されます
こうしている理由は 3 つあります
(1) Claude がユーザーの代わりに自由にコードを書ける 独立したコンピュータ環境 を提供するため
(2) 他のサンドボックス化ソリューションよりも セキュリティ境界の保証 が確実であるため
(3) 技術に詳しくないユーザーに、より安全な利用体験を提供するため
ただしトレードオフがあることは認識しており、Cowork を使わない、あるいは VM なしで使いたい人向けの改善案を検討中です
「承認疲れ(approval fatigue)」を減らすことは短期的には Anthropic に有利でも、ユーザーにとって長期的な利益にはなりません
こうしたパターンが定着する前に止めたほうがよいと思います
すでに VM 内で実行中だったため、ネストされた仮想化エラー が起きたようです。エラーメッセージを改善するか、すでに VM 内であれば Cowork が独自 VM を省略するようにするとよいと思います
最近のアプリがディスクアクセスを乱用しているのには驚かされます
たとえば Apple Podcasts アプリは理由もなく 120GB のポッドキャストファイル をダウンロードして削除しません。「System Data」と表示されるため、外付けドライブを探す羽目になりました
~/Library/Messagesフォルダを見ると、iMessage の同期のせいで 100GB 以上を占有しています。こういうものは クラウドにオフロード すべきです「vibe coding」がもたらす祝福と呪いを同時に感じています。まさに 雰囲気コーディングの両面性 です
VM サンドボックスは Cowork の中核です。コード生成機能を安全に提供するには 隔離環境 が不可欠です
ユーザーに特定フォルダへのアクセス権だけを与え、書き込み権限が必要な場合は警告を出す UI を提案します
実際のところ、LLM がなくても開発は VM の中で行うのがよいです
Vagrant のようなツールは今でも有用です
Cowork の主な対象は非開発者であり、コードを書くアシスタント型 AI として捉えるのが適切です
専門家は別の Mac Mini で作業しますが、一般ユーザーにはそれはできないので、VM が現実的な解決策です
Anthropic の社員たちが Claude Code で Claude Code を開発していると聞きました
AI は製品の完成度を高めますが、品質低下 が問題です。結局、熟練した開発者が再び必要になるでしょう
初期ユーザーには、モルモットのように製品をテストしなければならない責任があります
ここ 30 分ほど DaisyDisk でノート PC を整理していたところ、Cowork の 10GB VM を見つけました
アプリが不要にストレージを占有することは多いのに、整理機能はほとんどありません
Xcode も長い間起動していないのに、複数 OS 向けの SDK やシミュレータを保持し続けています
crondやfindがあるのに、なぜこうした整理作業を自動化しないのか不思議ですCowork は Apple Virtualization Framework を使っているため、ネストされた VM エラー が発生します
機能制限、容量の無駄、遅延が生じます。OpenAI が使っている Seatbelt サンドボックス のほうがよりよい代替案かもしれません
関連リンク
不便ではありますが、こうしたサンドボックス方式こそが エージェント型ツールの本質 です
内蔵サンドボックスなしで動くツールは、いずれ データ損失 を引き起こすことになります
おそらく Anthropic 内部で「アプリの性能改善」というプロンプトを投げたら、こういう結果になったのだと思います