リード
Macのストレージ空き容量を増やそうとして、逆に「消したのに減らない！」という怪現象に頭を抱えたことはありませんか？実は今回、私もまさにそのドツボにハマってしまいました。原因をAIと一緒に探っていくと、過去の自分が作った「空のリンク」を必死に消していたというお恥ずかしいポカが判明……（笑）。でも、そこからが本当の逆転劇です。シンボリックリンクや開発環境の整理を駆使し、最終的には空き容量100GB以下から200GBの空きを確保！実体験に基づいた、失敗しないMacストレージ奪還のコツを解説します。
結論：Macのストレージ管理、3つの絶対ルール
Macの内蔵SSD容量を根本的に解決し、安全に空き容量を確保するための結論は以下の3点です。
1. GUIを疑い、ターミナルで「実体」を把握する Finder上の「エイリアス」を削除しても容量は増えません。また、APFSの仕様により一時的なキャッシュが残ることもあります。必ず du コマンドでディレクトリごとの真の占有量を確認してください。
2. 重いライブラリは「シンボリックリンク」で外部SSDへ 音楽制作プラグインやループ素材など、数十GBに及ぶデータは、OSのコア機能であるシンボリックリンクを用いて外部SSDへ完全に逃がします。
3. 開発環境は「Command Line Tools」のみ死守する iOSアプリ開発を行わない場合、巨大なXcode本体やCoreSimulator（約20GB〜）は不要です。フロントエンド開発に必要なCLIツール群だけを残し、大胆に削除します。
1. 序章：消したはずの80GBが戻らない？「エイリアスの罠」と「APFSの仕様」
DTM（Cubase等）やWeb開発を並行して行うと、Macの内蔵SSDはあっという間に枯渇します。空き容量が100GBを切り、作業に支障が出始めたため、私は以前使っていたLogic Proの追加音源（約80GB）を削除することにしました。
しかし、フォルダをゴミ箱に入れ、完全に消去したにもかかわらず、空き容量が一時的に増えた後、すぐに元の値に戻ってしまうという不可解なトラブルに見舞われました。
1-1. 筆者が陥った「ポカ」：エイリアスの実体を消していなかった
原因をターミナルで深く追及した結果、衝撃の事実が判明しました。
私が削除しようとしていた /Library/Application Support/Logic は、過去の自分が容量節約のために外部SSDへ作成していた 「エイリアス（ショートカット）」 だったのです。
私は80GBのデータ実体ではなく、わずか数KBのリンクアイコンを消していただけでした。データ実体はすでに外部SSDに存在していたため、内蔵SSDの容量が減らないのは当然の結果でした。クリエイターのMacは長年の運用でディレクトリ構成が複雑化しています。Finderの見た目だけで判断する危険性を痛感した瞬間です。
1-2. APFSの「パージ可能領域」とローカルスナップショットの真実
また、ファイルを削除した直後に容量が反映されない場合、現在のmacOSのファイルシステムである「APFS（Apple File System）」の仕様も疑う必要があります。
Time Machineのバックアップ先が接続されていない状態が続くと、Macは内蔵ストレージ内に「ローカルスナップショット」を一時的に保存します。これが「パージ可能領域」としてストレージを占有するため、ターミナルでスナップショットを削除するか、OSのキャッシュを再計算させるための再起動（またはセーフモード起動）が必要になるケースが多々あります。
2. 原因究明：ターミナルで「真の容量ドロボウ」を特定する
GUI（ディスクユーティリティ）の「システムデータ」といった曖昧な表示ではなく、エンジニアとして確実に容量の内訳を特定します。
2-1. duコマンドによるディレクトリ階層の可視化
どのフォルダが「ギガ単位」でストレージを食い潰しているかを突き止めるため、以下のコマンドを実行します。
bash
# Dataボリューム内の第1階層をGB単位・容量順に表示
sudo du -g -d 1 /System/Volumes/Data 2>/dev/null | sort -nr-g：GB単位で表示-d 1：深度1（第一階層のみ）を表示sort -nr：数値の大きい順（降順）にソート
2-2. SIP（システム整合性保護）とエラー回避のテクニック
上記コマンドの末尾にある 2>/dev/null は非常に重要です。
現在のmacOSはSIP（System Integrity Protection）という強固なセキュリティ機能により、ターミナルからのフルアクセスを制限しています。そのため、アクセス権のないディレクトリをスキャンすると大量の Operation not permitted エラーが発生し、画面が埋め尽くされてしまいます。
この標準エラー出力を /dev/null（ブラックホール）に捨てることで、読み取れた正常な結果だけをきれいにリストアップすることができます。
私の環境では、以下のディレクトリが真の占有者であることが判明しました。
/Library/Audio/Plug-Ins：30GB（サードパーティ製プラグイン）/Library/Developer：23GB（Xcode関連の遺産）
3. 解決策1：音楽制作プラグインの「シンボリックリンク」外部化
巨大な音源ライブラリを外部SSDへ移すのはDTMの定石ですが、本体のプラグインデータ（Components / VST3など）も外部化することで、さらに数十GBの節約が可能です。
3-1. エイリアスではなく、なぜ「シンボリックリンク」なのか？
macOSのFinderで作成する「エイリアス」は、Apple独自のメタデータに依存しています。そのため、Logic Proの auvaltool やCubaseのVSTスキャナーなどのバックグラウンドプロセスは、これを実体として認識できず、プラグインの読み込みエラーを起こします。
一方、UNIXシステム標準の機能である「シンボリックリンク」を使用すれば、OSレベルでファイルパスを転送するため、DAWアプリはリンクであることを一切意識せず、内蔵ストレージに実体があるかのように振る舞います。
内蔵SSD（Macintosh HD）
└─ /Library/Audio/Plug-Ins/Components ← シンボリックリンク（矢印マーク）
↓ OSレベルで透過的に転送
外部SSD（CT1000X）
└─ /Library/Audio/Plug-Ins/Components ← 実体（30GBのデータ）DAW（Cubase / Logic Pro）はシンボリックリンクを「実体のフォルダ」と認識するため、プラグインの読み込みは正常に動作します。
3-2. ターミナルを使った外部化の完全手順
今回は、30GBを占有していたプラグインフォルダを外部SSD（例：CT1000X）へ移行します。
Step 1：外部SSDへのコピー
Finderを使用して、内蔵側の Components、VST、VST3 フォルダを、外部SSDの同階層（Library/Audio/Plug-Ins/）へ手動でコピーします。 （※転送漏れを防ぐため、移動ではなく必ずコピーから行います）
Step 2：内蔵ストレージの元データ削除
コピー完了後、ターミナルで内蔵側のフォルダを削除します。
bash
sudo rm -rf /Library/Audio/Plug-Ins/Components
sudo rm -rf /Library/Audio/Plug-Ins/VST
sudo rm -rf /Library/Audio/Plug-Ins/VST3Step 3：シンボリックリンクの作成
以下のコマンドを1行ずつ実行し、外部SSDへのリンクを張ります。
bash
sudo ln -s "/Volumes/CT1000X/Library/Audio/Plug-Ins/Components" "/Library/Audio/Plug-Ins/Components"
sudo ln -s "/Volumes/CT1000X/Library/Audio/Plug-Ins/VST" "/Library/Audio/Plug-Ins/VST"
sudo ln -s "/Volumes/CT1000X/Library/Audio/Plug-Ins/VST3" "/Library/Audio/Plug-Ins/VST3"Finderで確認し、フォルダアイコンに「矢印マーク」が付いていれば成功です。
3-3. 【重要】ライセンス管理ツール（DRM）に関する免責・注意点
シンボリックリンクはシステム上完璧に機能しますが、iLok や Waves Central、Native Access など、独自の強固なライセンス管理（DRM）を行っている一部のプラグインメーカーの場合、指定パスに物理的な実体がないとアップデート時にエラーを吐くケースが稀にあります。
移行後に不具合が生じた場合は、各メーカー公式の管理ツールから「修復（Repair）」または「再配置（Relocate）」処理を行ってください。
4. 解決策2：肥大化する開発環境（Xcode）の断捨離
フロントエンドエンジニアにとって、開発環境の維持は必須ですが、無駄なファイルまで抱え込む必要はありません。
4-1. 20GB超の「CoreSimulator」を一掃する
ターミナルの調査で判明した /Library/Developer/CoreSimulator の21GB。これは、過去のiOSバージョンなどの「仮想デバイス（シミュレータ）のOSイメージ」です。現在スマホアプリ開発を行っていないのであれば、これらはただのゴミです。
以下のいずれかのコマンドで、シミュレータの中身を安全に一掃できます。
bash
# シミュレータのOSイメージをすべて削除
sudo rm -rf /Library/Developer/CoreSimulator/*
# または、Apple公式コマンドで「利用不可」なシミュレータのみ削除（より安全）
xcrun simctl delete unavailable4-2. Xcode本体の削除と「Command Line Tools」の死守
巨大な Xcode.app 本体（約40GB）は、アプリケーションフォルダから直接ゴミ箱に入れて削除しても問題ありません（専用のアンインストーラーは不要です）。
【絶対に消してはいけない領域】
ただし、/Library/Developer/CommandLineTools（約5.5GB）は絶対に削除しないでください。ここには Git、Homebrew、Node.js（npmのネイティブビルド）など、フロントエンド開発に不可欠なCコンパイラやシステムツールが含まれています。これを消すと、フロントエンドの開発環境が崩壊します。
**「不要なシミュレータとXcode本体は捨てる、CommandLineToolsは残す」**が、エンジニアにとって最適なストレージバランスです。
5. 実録：生成AIを相棒にした壁打ちデバッグ術
今回のストレージ最適化において、最も強力な武器となったのは 生成AIとの対話 です。
5-1. コマンドエラーの即座解決
ターミナルでの作業中、シンボリックリンク作成時にコマンドが通らないエラーが発生しました。エラー画面のスクリーンショットをAIに投げたところ、「複数行（コメント記号 # を含む）を一度にペーストしたことでzshが構文エラーを起こしている」と即座に指摘を受けました。
自分一人でエラーログを検索して解決策を探すのに比べ、状況のコンテキスト（前提条件）を共有したAIを「専属のインフラエンジニア」として壁打ちに使うことで、作業のダウンタイムは劇的に短縮されます。
6. まとめ：200GBの空き容量が生み出すクリエイティブの余裕
プラグインの外部化とシミュレータの断捨離をやり切った結果、私のMac miniは最終的に 201.4GB の空き容量を確保することができました。
ストレージの余裕は、仮想メモリの安定したスワップ領域の確保に直結し、DAWの重いプロジェクトファイルの読み込みや、Dockerコンテナの立ち上げなど、すべてのパフォーマンスに直接響きます。
「消したはずなのに減らない」と焦った時は、GUIを疑い、ターミナルを開き、AIに助言を求めながら「真のディレクトリ構造」をハックしてみてください。
おすすめのクリエイター向け大容量外部SSD（CTA）
シンボリックリンクを多用する環境では、外部SSDの「読み込み速度」と「安定性」がDAWのパフォーマンスを直結します。ライブラリの外部化に最適なスペックを持つSSDを比較しました。
| 製品名 | 容量 | 読出速度（最大） | 接続規格 | クリエイターへの推奨ポイント |
|---|---|---|---|---|
| Crucial X10 Pro | 1TB / 2TB | 2100 MB/s | USB 3.2 Gen2x2 | プラグインの高速ロードに最適。小型で堅牢。 |
| SanDisk Extreme Pro | 1TB / 2TB | 2000 MB/s | USB 3.2 Gen2x2 | 映像制作や大容量サンプルライブラリの定番。 |
| Samsung T7 Shield | 1TB / 2TB | 1050 MB/s | USB 3.2 Gen2 | コストパフォーマンスに優れ、発熱が少ない。 |
快適な制作環境構築の第一歩として、まずは強力な外部ストレージの導入を検討してみてください。
更新履歴
- 2026-04-22：初稿公開
