Photos ライブラリが Mac の中で一番大きい理由

このブログで扱っているすべてのカテゴリの中で、Photos は個人の Mac において単独で最大のものであ ることがほとんどです——どの開発者向けキャッシュよりも、System Data よりも大きく、ディスク上のそ れ以外すべてを合わせたよりも大きいことさえあります。

du -sh ~/Pictures/Photos\ Library.photoslibrary

パッケージの中に実際に入っているもの

Finder では Photos Library.photoslibrary は1つのファイルのように見えますが、実際にはパッケー ジです——右クリックして Show Package Contents を選べば、本当の構造が見えます。

du -sh ~/Pictures/Photos\ Library.photoslibrary/*

• originals/ — すべての写真と動画の、フル解像度・無加工のオリジナルデータです。ライブラリ 全体のサイズの80%以上を占めるのが普通で、特に最近の iPhone の4K動画があるとその傾向が強まりま す。
• resources/ — Apple による派生データです。UI が必要とするあらゆるサイズのサムネイル、 デバイス上で処理される顔認識のインデックス、そして調整を加えた写真の編集履歴（編集が非破壊的に 保たれるよう、オリジナルとは別に保持されます）。
• database/ — 実際のカタログです。アルバム、タグ、日付、どの写真がどこにあるか。他の部分 に比べれば小さいものの、失われると実際に困る部分です——これはあなたのメディアそのものではな く、その整理情報です。

iCloud Photos の「Optimize Mac Storage」——実際は何をしているのか

iCloud Photos を有効にしている場合、System Settings → Apple ID → iCloud → Photos に 「Optimize Mac Storage」という項目があります。これは容量の小さいデバイス向けバージョンをローカ ルに保持しておき、実際に写真を開いたときにオリジナルをオンデマンドでダウンロードする仕組みです。 ほとんどの人がまだ引いたことのない、最も効果の大きいレバーです。

# No shell equivalent — this is a toggle in System Settings, not a command.
# System Settings → [your name] → iCloud → Photos → Optimize Mac Storage

トレードオフはこうです。しばらく見ていなかった古い写真を開くと iCloud からのダウンロードが発生 し、インターネット接続が必要で、初回は少し時間がかかります。ほとんどの人にとって日常使いの中では 気づかないレベルで、しかも数十ギガバイトをその場で解放できます。ただしこれが機能するのは、ライブ ラリが実際に iCloud Photos に裏付けられている場合に限られます——そもそも iCloud Photos にサインイ ンしていなければ、この設定に関係なくすべてローカルに保存されたままです。

iCloud Photos を使っていない場合

ライブラリがローカルのみ——iCloud 同期なし、または iCloud がオフ——の場合、「optimize」ボタンは 存在せず、選択肢はもっと手作業寄りになります。

重複や類似写真を削除する。 Photos アプリ自体の Utilities → Duplicates ビュー（最近の macOS バージョン）は、アプリに組み込まれた完全一致・ほぼ一致の重複検出を表示します——連写のシー ケンスや誤ってのインポートは、ここでよくある要因です。

Photos のゴミ箱を空にする。 アプリ内で写真を削除しても、実際に容量が解放されるまでの30日 間は「Recently Deleted」アルバムに移動されるだけです——Finder のゴミ箱と同じ仕組みで、対処法も 同じです。

Album → Recently Deleted → Delete All、あるいは30日待つ。

ライブラリを移動する、または毎日は使わないものを書き出す。 Photos は複数ライブラリと外部ドラ イブへの保存に対応しており、めったに開かないアーカイブ用ライブラリを分けて、ローカルには作業用の ライブラリだけを残すことができます。これはこの記事の中でも最も大きなワークフローの変更で、上記を すべて最適化してもまだ容量が厳しい場合にのみ検討する価値があります。

直接触ってはいけないもの

originals/ や resources/ の中のファイルを手動で編集したり、パッケージ内のものをアプリ以外の 方法で削除したりしては絶対にいけません——database/ のカタログは originals/ 内のすべてのファ イルについて正確なパスとチェックサムを追跡しており、手動での変更はカタログと実態のずれを引き起こ します。これによりライブラリが壊れたり、ファイルはディスク上に技術的には残っているのにアプリ上で は写真が「消えた」ように見えたりすることがあります。ここで容量を解放する正当な方法はすべて、 Photos アプリ自体か iCloud の最適化設定を通じたものであり、パッケージの中を狙った rm コマンド では決してありません。

ディスク全体の中での位置づけ

Photos は、個人の Mac にある主要なストレージカテゴリの中でも、実質的にキャッシュでもガラクタでも ない唯一のものと言えるでしょう——それはあなたが実際に所有しているものです。「この88GBは本物で、あ なたのものです」というのは、「この62GBはビルドキャッシュで不要です」というのと同じくらい知る価値 のある情報です——ただ、その情報に対してとるべき行動が違うだけです。

だからこそ、開発中の無料 Mac アプリ DevCruft では、Photos を他のスキャン対象とは違う扱いにする設計 にしています。マップ上では実サイズのまま「keep」として色分けし、DerivedData や古びた node_modules フォルダのようにワンクリック解放の対象として提示することはしません。公開時にお知らせを受け取りた い方は、ウェイトリスト に登録してください。

Mac 上でもう一つ知っておく価値のある、キャッシュではない大きな存在については、 iPhone バックアップのガイド を参照してください——Photos の 同期とローカルバックアップはよく混同されますが、まったく別のストレージカテゴリです。