散らばった家族写真を救出｜Googleフォト・iPhone・古いMacの重複を安全に整理

妻の写真は、Googleフォト、今のiPhone、古いMac、DVDに分かれていました。どこにしかない写真があるのか、同じ写真が何枚あるのかも分からない。下手に整理を始めると、大事な写真まで消してしまいそうでした。

そこで最初にしたのは、削除ではなく「救い出すこと」です。Google Takeoutで書き出し、iPhoneと古いMacは別々に保存し、内容が同じか確認できたものだけを重複として扱いました。この記事では、消さずに集めてから整理した流れを残します。

家族写真を守るまでの全4回

1. 第1回｜iPhoneの容量不足から、保存先を決めるまで
2. 第2回｜Nextcloudを夫婦のiPhoneから見られるアルバムに
3. 第3回｜写真・動画が「消えた？」表示トラブルを直した記録
4. 第4回｜Googleフォト・iPhone・古いMacの写真をまとめて救出（この記事）

最初にしたのは、写真の置き場所を全部書き出すこと

確認できたのは、Googleフォト、現在のiPhone、古いMacBook、外付けHDD、DVDです。GoogleフォトとiPhoneには同じ写真も多くありますが、片方にしかない写真や動画も混ざっています。ここで「GoogleにあるからiPhone側は消してよい」とは考えませんでした。

▼ 実際の画面

Googleフォトは、Google Takeoutで全部書き出した

Googleのデータを書き出せる「Google Takeout」を使いました。最初は50GBずつの大きなファイルにまとめましたが、途中で失敗。回線が切れたときのやり直しも大変です。そこで、約4GBずつに分けて作り直しました。

写真や付属情報を一つにまとめたZIP形式のファイルは10個。001から010まで番号がそろっているかを確認し、ZIPが壊れていないかを調べてから、中のファイルを取り出しました（解凍）。約4GBずつなら、途中で失敗しても、そのファイルだけをやり直せます。

書き出し完了のメールが届いただけでは、まだ安心できません。ダウンロードしたZIPを開けるところまで確認して、ようやく退避できたと考えることにしました。

現在のiPhoneは、Google側と混ぜずに保存した

次に、今使っているiPhoneの写真と動画を別のフォルダーへ保存しました。ここではGoogleフォトから出したファイルと混ぜません。「googlephotos書き出し」と「iphone現在分」のように入口を分け、どこから来たファイルかを残しました。

▼ 実際の画面

先に混ぜると、あとで同じ写真が見つかったときに、どちらを元に戻せばよいか分からなくなります。重複を探す前に、出どころを分けて残す。この一手間が、やり直しを楽にしました。

「同じ写真っぽい」では削除しなかった

見た目が同じ写真でも、編集後のもの、少し小さくなったもの、日時だけ書き換わったものがあります。そこで、ファイルの中身から作る「SHA-256」という長い番号を比べました。難しそうな名前ですが、家族写真の整理では「中身が同じなら同じ指紋になる」と覚えれば十分です。

最初に、ファイル名の末尾にある「.JPG」「.MOV」などの種類を示す部分（拡張子）で対象を集めた段階では、Google側が15,174件、iPhone側が6,106件で、両方にある完全一致のファイルは1,236件でした。この時点の計算は20,044件です。ただし、これは最終結果ではありませんでした。あとから拡張子のない動画と、iPhone側だけにある重複も調べています。

ファイル名や撮影日が同じだけでは削除していません。反対に、名前が違っても指紋が同じなら、中身は同じです。写真整理ソフトの「似ている写真」表示は候補探しには便利ですが、削除の最終判断は別にしました。

拡張子がないファイルを、写真ではないと決めつけなかった

IMG_1221という、名前の最後に.JPGや.MOVがないファイルがありました。拡張子だけで写真や動画を集める方法では、このファイルは対象から外れてしまいます。

そこでファイルの種類を調べる命令「file」を入力すると、Apple QuickTimeのMOV動画でした。さらにSHA-256で比べると、iPhone側に中身が完全に同じファイルが見つかりました。

名前を見て不要と決めるのではなく、中身を確認して集計へ戻しました。Google側の件数は15,175件、GoogleとiPhoneの間の完全一致は1,237件となり、さらにiPhone内だけで重なっていた9件を除くと、iPhoneの異なるファイルは6,097件です。

9月3日の統合計画では、6,097＋15,175−1,237＝20,035件になりました。前の表は最初の比較、こちらは追加確認後の統合計画です。件数が変わったのは、すべて同じ集計をしていたわけではないからです。

なお、後日の自動バックアップ設定では、その時点でサーバーにあった妻のファイル20,044件を一覧にした別の記録もあります。この一覧と統合計画の差の内訳までは、今回確認できていません。統合計画の件数を、そのまま後日のサーバーに実際に保存されていた件数とは扱わないようにしています。

同じファイル名でも、7年違う写真があった

中身が同じファイルを除くことと、名前が同じファイルを扱うことは別の問題でした。実際にGoogle側では、IMG_1966.JPGという同名の写真に2014年と2021年のものがありました。IMG_5575.HEICでは2018年と2019年、IMG_0173.MOVでは2017年と2022年の例も見つかっています。

これらを同じフォルダーにまとめて「同じ名前だから上書き」としてしまうと、別の思い出を失うことになります。重複として除く条件は名前ではなく、中身の完全一致にしました。

統合前には、どの元ファイルをどの名前で保存するかの計画を作り、保存先でファイル名が重ならないことを確認しました。この「保存するときにファイル名が重なる問題」と、第3回の「同名写真とMOVがアプリで一組に見える問題」は、分けて調べています。

写真に付いてきた情報ファイル（JSON）は、すぐ捨てなかった

Takeoutのフォルダーには、写真の横にJSONという小さな情報ファイルがたくさん入っています。写真ではないので、最初は不要に見えました。でも、撮影日時やGoogle側で持っていた情報を確認するときに役立つことがあります。

特にGoogle側での作成日時を表す「creationTime」と、撮影日時を表す「photoTakenTime」は同じとは限りません。Googleへ入れた日と、実際に撮った日が違う場合があるからです。移行先で日付が正しく見えると確認できるまでは、JSONも一緒に残しました。

日付の情報は、すべての写真に同じ形で付いていたわけではなかった

移行後に撮影した順に並べたいので、JSONの情報とファイル本体の撮影日時を照合しました。ファイルをダウンロードした日やGoogleへ登録した日を撮影日と取り違えると、昔の写真が別の時期に並んでしまいます。

作業記録では、Google側15,175件の日時の手掛かりを、対応するJSONで確認できた15,146件、同じ名前の関連ファイルに付いたJSONを使った27件、ファイル内部の日時を使った1件、組になるHEIC写真の情報と、目で見た確認を合わせて判断した1件に分けています。その段階では未解決が0件になりました。

関連ファイルのJSONでも、名前が同じというだけで日付をそのまま使ってよいわけではありません。同じ番号でも撮った年が違う例があったためです。そのファイルに対応するJSONがあるものと、さらに情報を突き合わせる必要があるものを分け、例外を最後まで確認したことが大事でした。

全件処理へ進む前に、10件でテストしています。JPG・HEIC・MOV・MP4を含めて日時を確認し、ファイルの中身が変わっていないかは先ほどの「中身の指紋」（SHA-256）が一致するかでも確かめました。撮影日時の扱いが正しいことと、原本の内容を損なっていないことを、別々に見ています。

古いMacには、写真アプリの保存データが二つあった

古いMacの「ピクチャ」フォルダー（画像の保存場所）を見ると、「iPhoto Library」と「写真 Library」が並んでいました。どちらも、写真アプリが写真や管理情報をまとめて保管する「ライブラリ」という保存データです。容量はiPhoto Libraryが約105.78GB、写真 Libraryが約137.8GB。名前だけでは、どちらが今使っていた本体か判断できません。

iPhoto Libraryには、以前の写真アプリから移行したことを示す表示がありました。写真アプリで両方を確認し、最近までの写真が入っている約137.8GBの「写真 Library」を本命として扱いました。ただし、古い方もその場では消していません。

古いMacだけで24,760項目、動画は973本あった

写真アプリに表示された項目数は24,760。動画だけでも973本ありました。Googleフォトや現在のiPhoneだけを整理して「全部終わった」と思っていたら、この量を見落とすところでした。

古いMacは動作が遅くても、写真の保管庫としては大切です。アプリから一枚ずつ書き出す前に、写真 Libraryそのものを外付けHDDへ丸ごとコピーしました。

4TBの外付けHDDへ、写真アプリの保存データを丸ごとコピーした

使った外付けHDDは4TBで、空きは約2.46TB。137.8GBの写真 Libraryを置いても十分余裕があります。コピー中にMacが眠らないようにし、終わった後は外付けHDD側から開けるかを確認しました。

ここでも原本側はまだ削除しません。コピー先があること、開けること、項目数に大きな違いがないことを確認してから次へ進みます。

救出した写真は、最後にNextcloudで見られるようにした

▼ 実際の画面

▼ 実際の画面

DVDも、同じ考え方で進める

DVDはまだ作業途中です。DVD_001、DVD_002というようにディスクごとのフォルダーを作り、まず中身を丸ごと外付けHDDへコピーする予定です。写真だけを拾わず、ディスク単位で残すのは、あとで見落としに気づいても元へ戻れるようにするためです。

移したあとも、新しい写真をHDDへ残す仕組みを作った

Nextcloudを日常の保存先にしても、新しく撮った写真がHDDに増えていかなければ、バックアップは古いままになります。まず夫婦のiPhoneからは、今後撮る写真だけをNextcloudへ自動保存する設定にしました。そのうえで、Nextcloudに追加されたファイルだけをMac経由でHDDへコピーする仕組みを作りました。

初回は、サーバーにすでにあるファイルの一覧を基準として記録し、それだけで全部をコピー済みにするわけではありません。過去分の退避と照合は別に行い、一覧を作った時点より後に増えたものをコピーする設計です。

ここでもコマンド入力でつまずきました。コピー用の命令「rsync」と、サーバーへの接続に使う電子的な鍵（SSH鍵）を準備する命令「ssh-add」を、誤って一続きで入力してしまいました。そのため、コピー用の命令に、別の命令向けの指定が混ざっていました。また、鍵の準備ができていない状態では「Permission denied（アクセスが許可されていない）」という接続エラーも出ています。

ファイルが壊れた問題とは分け、コピーの動作と、接続時の本人確認を一つずつ確認しました。その後、処理の記録で本人側の新規1件、妻側の新規8件のコピーを確認できています。自動化の設定を書いたことだけでなく、実際に新しいファイルがHDD側にあることまで確認しました。

この仕組みは、Nextcloudで削除したものをHDDでも消す「完全な同期」にはしていません。サーバー側の誤削除がバックアップ先へそのまま伝わらないよう、新規コピーを基本にしました。HDDをつないでいないときは処理を終える設計なので、定期的につないで、コピーの記録を見る必要はあります。

最後に：写真を消さないために決めた4つのルール

• 移動より先にコピーする
• Google・iPhone・Macなど、出どころを残す
• 重複は見た目ではなく、中身の完全一致で判断する
• 確認が終わるまで、元データと付属情報を消さない

最終的に大切だったのは、フォルダーをきれいにすることではありませんでした。昔の写真を失わず、どこから来たかが分かり、必要なら元へ戻れることです。片づけはそのあとでもできます。家族写真だけは、速さより「消していない安心」を優先してよかったと思っています。

このシリーズを前から読む

← 前の記事
第3回｜写真・動画が「消えた？」表示トラブルを直した記録

＼ 最新情報をチェック ／