写真と動画の整理とは|何ができて、どこで詰まるか
写真と動画の整理という言葉で調べる人の手元では、たいてい2つの仕組みが同時に動いています。写真アプリが抱えているライブラリと、Finderのフォルダに散らばった素材です。この2つは設計思想が違うため、片方の作法をもう片方に持ち込むと必ずどこかで噛み合わなくなります。この記事では、その境目がどこにあり、詰まりがどの層で起きているのかを切り分けます。
同じ言葉で、2つの別々の仕組みが呼ばれている
Macで写真と動画を扱う経路は大きく2つです。1つは写真アプリのライブラリで、もう1つはフォルダに置いたままのファイルです。
ライブラリ方式は、写真アプリが専用の入れ物を持ち、そこに取り込んだ素材をデータベースとして管理します。入れ物の実体は「ピクチャ」フォルダの中にある拡張子 photoslibrary のパッケージで、Finderからは1つの塊にしか見えません。日付・場所・人物・アルバムといった情報はこのデータベース側に書かれていて、ファイルの名前には反映されません。だからライブラリの中では名前を気にする必要がなく、逆に言えば名前で探す発想が通じません。
フォルダ方式は、書き出したJPEG、画面収録のmovファイル、カメラのカードから吸い出したフォルダ、受け取った動画などが、そのままFinderに並んでいる状態です。こちらは名前と階層がすべてです。どこに置いたかと、何という名前かの2つでしか区別できません。
詰まりの多くは、この2つを同時に、かつ無意識に使っていることから起きます。撮ったものはライブラリ、もらったものと書き出したものはフォルダ、という分かれ方が自然にできてしまうためです。検索の窓も別々で、写真アプリの検索欄はフォルダ側を見ませんし、Finderの検索はライブラリの中身を1件ずつのファイルとして返しません。「あるはずなのに出てこない」の大半は、探している場所が反対側だった、という形をしています。
| 見る観点 | ライブラリ方式 | フォルダ方式 |
|---|---|---|
| 区別のよりどころ | データベースの属性 | 名前と階層 |
| 名前の役割 | ほぼ無い | すべて |
| 一括処理 | アプリの操作に依存 | コマンドで自由に書ける |
| 他アプリからの参照 | 書き出しが要る | そのまま参照できる |
| 壊れたときの復旧 | ライブラリ単位 | ファイル単位 |
枚数が多い問題と、容量が大きい問題は別の問題
写真と動画をひとまとめに語ると、対処を間違えます。この2つは詰まる理由が違うからです。
写真は枚数の問題です。1枚あたりは小さく、数千枚あっても容量としてはそれほど積み上がりません。しかし枚数が多いと、目で見て選ぶ作業が成立しなくなります。スクリーンショットが典型で、撮った瞬間は用事があっても、翌週には何のために撮ったのか分からない画像が大量に残ります。ここで必要なのは容量の削減ではなく、捨ててよいものを機械的に選び出す条件です。
動画は容量の問題です。本数は少なくても、1本が写真の数百倍から数千倍の大きさになります。画面収録や高解像度で撮った素材は、数分でギガバイトの単位に届きます。ここで枚数を減らす発想を持ち込んでも効きません。効くのは、置き場所を本体のディスクから外へ移すことと、編集が終わった素材の中間ファイルを残さないことです。
自分がどちらで詰まっているかは、実際に測れば1分で分かります。ターミナルで対象のフォルダに対して du -sh * を実行すれば各項目の合計容量が並び、ls | wc -l を実行すれば件数が出ます。容量の上位に動画が並ぶなら容量の問題、件数だけが突出しているなら枚数の問題です。両方が同時に起きているなら、先に手を付けるのは容量のほうです。動画を外に出すと、残りの作業を行う余地がディスクにできます。
du -sh ~/Downloads/* | sort -h | tail -20
ls ~/Desktop | wc -l
日付が3つあり、どれを見るかで並びが変わる
写真と動画の整理でいちばん静かに崩れるのが日付です。1つのファイルには、性格の違う日付が少なくとも3つ付いています。
1つ目は撮影日時で、写真ならEXIFの中、動画ならメタデータの中に書かれています。実際にシャッターを切った時刻なので、内容と結び付いた唯一の日付です。2つ目はファイルの作成日で、そのファイルがそのディスクに現れた時刻です。3つ目は変更日で、中身が最後に書き換えられた時刻です。
問題は、コピーや書き出しをすると2つ目と3つ目が更新されてしまうことです。3年前に撮った写真を今日書き出せば、作成日は今日になります。Finderの日付順で並べ替えたときに、古い写真が先頭に来るのはこのためです。順番がおかしいのではなく、見ている日付が違います。
手元のファイルがどの日付を持っているかは、mdls で確かめられます。
mdls -name kMDItemContentCreationDate -name kMDItemFSCreationDate -name kMDItemFSContentChangeDate IMG_1234.HEIC
撮影日時が空で返る種類もあります。スクリーンショットと画面収録がそれで、カメラを通っていないため撮影日時そのものが存在しません。この場合に頼れるのは名前に入っている日付です。つまり、名前で日付を管理する仕組みと、メタデータで日付を管理する仕組みの両方が、同じフォルダの中に混ざっています。並べ替えが安定しない原因はここにあります。
1枚に見えて、1つのファイルではないもの
Finderの上で1項目に見えても、実体が1つとは限りません。この食い違いは、一括処理を書いたときに初めて表に出ます。
Live Photosは静止画と短い動画の組です。書き出し方によっては、HEICとmovの2ファイルが並んで出てきます。片方だけを移動すると、もう片方は意味を失って残ります。RAWで撮る設定にしていると、RAWとJPEGが同じ名前で拡張子だけ違う組になります。名前で重複を判定する処理を書くと、この組を重複とみなして片方を消してしまう危険があります。
形式の話も絡みます。iPhoneで撮った写真の既定はHEIC、動画はHEVCで、どちらも容量を抑える代わりに受け取り側を選びます。編集の現場で使うProResは逆に、扱いやすさと引き換えに容量が大きく膨らみます。同じ「動画」という言葉でも、圧縮された配布用の1本と、編集用の素材では桁が違います。
つまり写真と動画の整理とは、ファイルを並べ替える作業ではなく、何を1単位とみなすかを決める作業です。組になっているものを組のまま動かすと決めるのか、必要な片方だけを残すと決めるのか。ここを先に決めないまま一括処理を走らせると、あとから復旧できない形で片側が欠けます。実行の前に、mv を echo に置き換えた空打ちで対象の一覧を目で見ておくと、この種の事故は起きません。
同じ写真が何箇所にもあるように見える理由
重複しているように見えて、実際には重複していない場合があります。逆もあります。
写真アプリに読み込むとき、既定ではライブラリの中へコピーが作られます。元のファイルを消さなければ、元とライブラリ内の2つが存在することになります。これは本当の重複です。一方で、APFSのディスクの中で cp -c を使って複製した場合は、クローンが作られるだけで実際の容量はほとんど増えません。Finderの情報では同じ大きさが2つ表示されますが、ディスクの空きはその分減りません。見えている数字と実際の消費が一致しないのは、この仕組みのためです。
この挙動は手元で確かめられます。ターミナルで man cp を開くと、-c は clonefile を使ってコピーする指定で、コピー元とコピー先が別のファイルシステムにある場合や、コピー先がクローンに対応していない場合だけ通常のコピーに切り替わる、と書かれています。同じディスクの中で複製した覚えがあるなら、見えている重複は容量を食っていない可能性があります。
本当に中身が同じかどうかを名前や大きさで判断すると外します。確実なのは中身から計算した値を比べることで、shasum -a 256 が同じなら中身は同じです。名前が違っても、拡張子が違っても、この値が一致すれば同じ中身です。
find ~/Pictures -type f -name '*.jpg' -exec shasum -a 256 {} + | sort | uniq -w64 -d
手元にある写真が、本体ではない場合がある
写真アプリには、本体をiCloudに置いて、手元には表示用の軽い版だけを残す設定があります。
フル解像度の写真およびビデオをiCloudに保存します。 出典: support.apple.com
この設定が入っていると、ライブラリのパッケージの中を直接のぞいても、フル解像度の実体が無いことがあります。整理のために外部から処理を掛けようとして、思ったサイズにならない、あるいは処理が途中で止まる場合、原因はこれです。iCloud Driveの側にも同種の設定があり、長く開いていないファイルが手元から退避されます。Finderの上ではアイコンに雲の印が付きますが、コマンドから見ると存在するのに中身が取れない状態になります。
この仕組みは容量を節約するためのもので、設定として間違っているわけではありません。問題になるのは、手元にあるように見えるかどうかと、実際に読めるかどうかが一致しない点です。整理の処理を書くときは、対象が手元にある状態かどうかを先に確かめる必要があります。
同じことが外付けディスクでも起きます。ライブラリや素材を外付けに移した場合、そのディスクをつないでいない間は当然読めません。加えて、外付けの検索の索引は既定で作られないことがあり、Finderの検索に出てこない原因になります。整理の仕組みを作るときは、いつ手元にあり、いつ手元に無いのかを先に決めておく必要があります。常時つないでいない置き場は、日々触るものの置き場には向きません。
いま詰まっているのはどの層か
ここまでを1つの表にまとめます。自分の状況に近い行から手を付けると、余計な作業をせずに済みます。
| 症状 | 詰まっている層 | 先に決めること |
|---|---|---|
| あるはずのものが検索で出ない | 2つの仕組みをまたいでいる | どちらを主にするか |
| ディスクの空きが足りない | 容量(動画) | 外に出す置き場 |
| 選ぶ作業が終わらない | 枚数(画像) | 捨ててよい条件 |
| 並べ替えると順番がおかしい | 日付の種類 | どの日付を基準にするか |
| 一括処理で片方だけ残った | 1単位の定義 | 組をどう扱うか |
| 処理を掛けても中身が取れない | 実体の所在 | 手元に置く範囲 |
道具側の資料から読み取れること
この分野の道具がどこを補おうとしているかは、公開されている資料の並びからも読み取れます。ファイル管理アプリの機能紹介では、フォルダの表示と、ターミナルの実行と、AIへの指示を1つの窓で扱える点が先に置かれています。上で挙げた詰まりの多くが、見る作業と実行する作業を別の窓で行き来する過程で起きることの裏返しです。どの機能がどの詰まりに対応するのかはできることに一覧があります。
処理を掛けたい対象が手元に無い、という問題については、扱う端末を増やす方向の解き方もあります。Macの前を離れているあいだに続きを進められるかどうかで、素材の置き場の決め方が変わるためです。この考え方はiPhone・iPadから続きをで説明されています。
道具そのものを選ぶ段階なら、同種のアプリがそれぞれどこに重心を置いているかを並べた他のファイル管理との比較と、無料で試せる範囲と費用が分かれる地点を示した料金を先に見ておくと、比較の軸がずれません。導入前に出やすい疑問はよくある質問にまとまっています。
写真と動画の整理は、道具を入れれば終わる作業ではありません。どの日付を基準にするか、何を1単位とみなすか、どこまでを手元に置くか。この3つを決めた時点で、残りは機械の仕事になります。決めずに始めると、道具を変えるたびに同じところで止まります。
よくある質問
写真アプリのライブラリと、フォルダでの管理はどちらを主にすべきですか?
撮影した写真が中心ならライブラリ、書き出しや受け取りが中心ならフォルダが向いています。重要なのはどちらが優れているかではなく、片方を主に決めて、もう片方には最小限しか置かないことです。両方に同じ素材が分散している状態が、探す時間を増やしている原因です。
並べ替えると古い写真が先頭に来るのはなぜですか?
Finderが見ているのがファイルの作成日で、撮影日時ではないためです。コピーや書き出しをすると作成日は当日に更新されます。撮影日時で並べたい場合は、写真アプリの側で見るか、EXIFの撮影日時を名前に埋め込んでから並べ替えます。
重複したファイルを名前や容量で見分けてもよいですか?
確実ではありません。RAWとJPEGの組のように、名前が同じでも中身が別のものがあります。中身が同じかどうかは shasum -a 256 の値で判定するのが確実で、名前が違っても値が一致すれば同じ中身です。
外付けディスクに移した素材がFinderの検索に出てこないのはなぜですか?
外付けの検索の索引が作られていないか、ディスクをつないでいないためです。常時つないでいない置き場は、日々触る素材の置き場には向きません。完成した素材の保管先として使い、作業中のものは本体のディスクに置く形が安定します。