Posts xcodeBuildMCP XcodeBuildMCPがストレージの数百GBを占有していた

XcodeBuildMCPがストレージの数百GBを占有していた

XcodeBuildMCPがストレージの数百GBを占有していた

ある日、いつも通り開発を行っていると、ストレージの容量が枯渇しているという旨が通知が届きました。 ストレージは1TB。500GB以上残っていたはずだし、直近でそんなに大きなサイズのデータを扱う作業はしていないです。

しかし、ストレージの空き容量は数GBに迫っていました。

原因の調査

残り数GBでは流石に開発を続けることは厳しいので、原因の調査を開始。 macのシステム設定を見ると、システムデータが700GBを占めていることがわかりました。

該当ファイルを調査すると、~/Library/Developer/XcodeBuildMCP/workspacesが大部分を占めているようです。 このworkspacesディレクトリ内には、ブランチ単位のディレクトリが100個以上あり、それぞれにDerivedDataなどおなじみのビルド成果物がありました。

どうやら、以下のようなことが起こっていたようです。

  • worktreeを使うたびに、~Library/Developer/XcodeBuildMCP/workspacesにディレクトリが作成される
  • worktreeごとに、ビルドした際の成果物が残り続ける
  • これらのパスはXcode自体のビルド成果物~/Library/Developer/Xcode/DerivedDataとはパスが違うため、Xcodeのclean build folderの実行などで削除されない

発生の経緯と暫定対策

XcodeBuildMCPのGitHubリポジトリを見ると、feat(session): auto-scope DerivedData per workspace/project pathというPRが2026-04-28にマージされていました 同じプロジェクトのクローンを同時にビルドした際の競合を防ぐために、ワークスペースやプロジェクトのパスごとにビルドの成果物を作るようになったようです。 これによって、2026-04-28以降、worktreeを作るたびに別のパスに成果物か作られ続けるようになっていき、削除されないまま肥大化したようです。

とり急ぎ、~Library/Developer/XcodeBuildMCP/workspaces配下の成果物は全て削除し、ストレージの空き容量を確保することができました

再発しない仕組みを考える

しばらくはこまめに成果物を削除していたのですが、徐々に面倒になってきました。 不要になった成果物が自然と削除されるようにするため、worktreeを削除するタイミングで、該当の成果物の入ったディレクトリを削除することにします

2026-07-23リリースのv2.7.0では、xcodebuildmcp purgeコマンドが追加されました 紐ついている経過物のディレクトリを調査し、削除するためのコマンドです DerivedDataだけでなく、ビルドログやラインタイムなど、XcodeBuildMCPが作ったもの全般を検出でき、レポートやdry-runにも対応しています このコマンドをworktree削除時に自動実行することにしました。

私はworktreeの作成・削除には自作のラッパーツールを利用しています。 worktreeの作成前後、削除前後に任意のスクリプトを差し込めるようにしているため、XcodeBuildMCPを利用するプロジェクトではworktreeの削除前にxcodebuildmcp purgeが実行されるようにしています。 これで、無限に肥大化を続ける事がなくなり、ストレージを十分確保することができるようになりました