2 ポイント 投稿者 GN⁺ 2026-03-03 | 1件のコメント | WhatsAppで共有
  • 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%)**するが、時間の経過とともに再び低下

一時的な回避策

  • Claude Desktopを終了後、次のコマンドでVMとキャッシュを削除
    rm -rf ~/Library/Application\ Support/Claude/vm_bundles  
    rm -rf ~/Library/Application\ Support/Claude/Cache  
    rm -rf ~/Library/Application\ Support/Claude/Code\ Cache  
    
  • この対応で一時的な性能改善は可能だが、定期的な再起動が必要
  • 一部ユーザーはVMフォルダの権限をchmod 000に変更して再生成を防止

ユーザーフィードバック

  • Cowork無効時でもVMが動作してメモリを占有
  • 一部ユーザーは21GB超まで肥大化したVMバンドルも報告
  • VMはアプリ起動時に自動で再プロビジョニングされ、圧縮ファイル(rootfs.img.zst)まで残って重複したストレージ浪費が発生
  • Coworkを一度も使っていないユーザーでも10GBバンドルを発見し、メモリリークだと認識
  • ストレージ容量に制約のあるMacユーザーは無効化オプションの必要性を強調

透明性と信頼性への懸念

  • ユーザーは、事前通知なしに12〜20GBのディスクと2GBのRAMを占有する点を問題視
  • インストール時または初回起動時の通知VMの事前ダウンロード可否の選択Cowork無効化トグルの提供などを提案
  • 一部ではVMサンドボックス設計の意図は理解できるものの、説明不足がユーザーの信頼を損なうと指摘
  • 「アプリがユーザーに知らせずシステム資源を使うのは信頼を損なう」という意見が多数

1件のコメント

 
GN⁺ 2026-03-03
Hacker Newsの意見
  • こんにちは、Anthropic の Felix です。私は Claude CoworkClaude Code を担当しています
    Cowork は、Linux VM 内で動作する Claude Code エージェントハーネスの上に構築されており、Apple の Virtualization Framework や Microsoft の Host Compute System を通じて実行されます
    こうしている理由は 3 つあります
    (1) Claude がユーザーの代わりに自由にコードを書ける 独立したコンピュータ環境 を提供するため
    (2) 他のサンドボックス化ソリューションよりも セキュリティ境界の保証 が確実であるため
    (3) 技術に詳しくないユーザーに、より安全な利用体験を提供するため
    ただしトレードオフがあることは認識しており、Cowork を使わない、あるいは VM なしで使いたい人向けの改善案を検討中です

    • フィードバックを言うなら、Cowork が 10GB のストレージを使うのであれば、事前にユーザーへ知らせて ワンクリックで削除できるようにすべきです
      「承認疲れ(approval fatigue)」を減らすことは短期的には Anthropic に有利でも、ユーザーにとって長期的な利益にはなりません
      こうしたパターンが定着する前に止めたほうがよいと思います
    • 公式または準公式の Claude サンドボックス向けコンテナイメージ を提供してほしいです。Cowork VM を外部でも使えるようにしてほしいです
    • 説明は素晴らしいですが、実際には Cowork が 性能低下や電力消費の問題 を引き起こしているという不満があります
    • Cowork が VM 上で動いているとは知りませんでした。マーケティングでこれを明確に伝えていれば、もっと早く試していたと思います
    • Claude Desktop から Mac VM(UTM 内)で実行しようとしたところ、Apple Virtualization Framework 関連のエラーが発生しました
      すでに VM 内で実行中だったため、ネストされた仮想化エラー が起きたようです。エラーメッセージを改善するか、すでに VM 内であれば Cowork が独自 VM を省略するようにするとよいと思います
  • 最近のアプリがディスクアクセスを乱用しているのには驚かされます
    たとえば Apple Podcasts アプリは理由もなく 120GB のポッドキャストファイル をダウンロードして削除しません。「System Data」と表示されるため、外付けドライブを探す羽目になりました

    • macOS の「System Data」問題は本当にひどいです。Docker、音楽ライブラリ、キャッシュなどのせいで、1〜2 年に 1 回は クリーンインストール をしなければなりません
    • ~/Library/Messages フォルダを見ると、iMessage の同期のせいで 100GB 以上を占有しています。こういうものは クラウドにオフロード すべきです
    • 5G 時代なのに、いまだに音声ファイルをデフォルトでダウンロードするのは理解できません。ストリーミングで十分です
    • 私も Time Machine のバックアップ問題で、512GB 中 300GB が「System Data」と表示され、1 日分の作業を失いました
    • こうした問題を解決するために、Mole のようなツールを使っています。また、warp/gemini CLI で不要なキャッシュを見つけて削除しています
  • 「vibe coding」がもたらす祝福と呪いを同時に感じています。まさに 雰囲気コーディングの両面性 です

  • VM サンドボックスは Cowork の中核です。コード生成機能を安全に提供するには 隔離環境 が不可欠です
    ユーザーに特定フォルダへのアクセス権だけを与え、書き込み権限が必要な場合は警告を出す UI を提案します

  • 実際のところ、LLM がなくても開発は VM の中で行うのがよいです
    Vagrant のようなツールは今でも有用です
    Cowork の主な対象は非開発者であり、コードを書くアシスタント型 AI として捉えるのが適切です
    専門家は別の Mac Mini で作業しますが、一般ユーザーにはそれはできないので、VM が現実的な解決策です

    • 最近は VPS プロバイダも多く、exe.devsprites.devshellbox.dev のようなところで簡単に環境を作れます
    • 私は複雑なプロジェクトには devcontainer を好みます。Docker と NixOS を活用すれば、より軽量で柔軟な開発環境を作れます
    • macOS では Lima が最高の選択でした。Claude Code をイメージとして置き、必要なディレクトリだけをマウントします。Vagrant よりはるかに滑らかに動作します
    • 「じゃあプログラミングするときもコンドームを使うのか?」という冗談が出るほど、セキュリティへのこだわり が過剰だという反応もありました
  • Anthropic の社員たちが Claude Code で Claude Code を開発していると聞きました
    AI は製品の完成度を高めますが、品質低下 が問題です。結局、熟練した開発者が再び必要になるでしょう
    初期ユーザーには、モルモットのように製品をテストしなければならない責任があります

    • こうした 1st party 製品がオープンソースと競争できるのか疑問です。無料で、しかもより良い代替手段があるのに、わざわざ使う理由がありません
    • Anthropic 内部の品質問題を見ると、社員の大半は ジュニア未満のレベル に見えます。Bun チームくらいが例外に見えます
  • ここ 30 分ほど DaisyDisk でノート PC を整理していたところ、Cowork の 10GB VM を見つけました
    アプリが不要にストレージを占有することは多いのに、整理機能はほとんどありません
    Xcode も長い間起動していないのに、複数 OS 向けの SDK やシミュレータを保持し続けています

    • こうした問題を解決するには DevCleaner を使えばよいです
    • macOS には crondfind があるのに、なぜこうした整理作業を自動化しないのか不思議です
  • Cowork は Apple Virtualization Framework を使っているため、ネストされた VM エラー が発生します
    機能制限、容量の無駄、遅延が生じます。OpenAI が使っている Seatbelt サンドボックス のほうがよりよい代替案かもしれません
    関連リンク

    • しかし Seatbelt はほとんど役に立たないと思います。なぜ Cowork を VM の中で動かそうとするのか気になります。独自 VM を使えば十分ではないですか?
    • そのうえ Seatbelt は 文書化がほとんどされていません
  • 不便ではありますが、こうしたサンドボックス方式こそが エージェント型ツールの本質 です
    内蔵サンドボックスなしで動くツールは、いずれ データ損失 を引き起こすことになります

  • おそらく Anthropic 内部で「アプリの性能改善」というプロンプトを投げたら、こういう結果になったのだと思います