GoogleフォトからSynology Photosへ：5万枚の移行で遭遇した「JSONメタデータ問題」と解決スクリプト

Update:

「ストレージの空き容量が残り15%です」。この通知を見るたびに、Google Oneのアップグレードボタンを押すべきか、それとも重い腰を上げて脱出するべきか悩んでいました。私のGoogleアカウントには、過去10年分の家族写真、旅行の記録、そして検証用のスクリーンショットなど、計5万枚（約450GB）の画像が眠っていました。

クラウドは確かに便利です。しかし、月額料金を「家賃」として払い続けるモデルに対し、エンジニアとしての私は常に違和感を抱いていました。「データは自分の手元（オンプレミス）に置いてこそ、真の所有と言えるのではないか」。そう決意し、AWS S3 Glacierへのコールドアーカイブも検討しましたが、最終的に閲覧性と家族への共有のしやすさを考慮し、Synology Photos（NAS）への完全移行を決断しました。しかし、そこには単なるファイルコピーでは済まされない、Google Takeout特有の「メタデータ消失」という深い落とし穴が待っていたのです。

移行環境と発生した「時系列バラバラ」問題

今回の移行プロジェクトにおける環境は以下の通りです。単純なコピー作業に見えますが、データ量がテラバイト級に近づくと、ネットワーク帯域やI/Oスループットがボトルネックになります。

  • Source: GooglePhotos (Google Takeout経由でエクスポート)
  • Destination: Synology DS224+ (DSM 7.2, RAM 6GB増設済み)
  • Client OS: macOS Sonoma (M1 Pro) / Ubuntu 22.04 LTS (処理用)
  • Network: 1Gbps LAN (Wi-Fi経由での転送は不安定なため有線必須)

まず最初にぶつかった壁は、Googleが提供するデータエクスポートツール「Google Takeout」の仕様です。意気揚々とダウンロードしたzipファイルを解凍し、NASの /photo ディレクトリにSMB転送してみました。そしてSynology Photosのインデックス処理が終わるのを待ってブラウザを開いた瞬間、私は絶句しました。

致命的な現象：
2015年に撮影したはずの子供の写真が「今日（転送日）」の日付になり、タイムラインのトップに表示されている。さらに、撮影地情報（GPS）が消失している写真が多数存在する。

なぜこのようなことが起きるのか。それは、GooglePhotos上で編集された日付や位置情報が、画像ファイル（JPEG/HEIC）のExifヘッダーに直接書き込まれず、「同名のJSONファイル」として分離されてエクスポートされるからです。つまり、IMG_1234.jpg と共に IMG_1234.jpg.json が生成され、本当の撮影日時はJSON側にしか書かれていないケースがあるのです。

失敗談：単純な上書きツールの限界

最初は、一般的なフリーソフトや「Exif Fixer」のようなGUIツールを使ってJSON情報を結合しようとしました。しかし、5万枚という規模では以下の問題が発生し、処理が完遂できませんでした。

  1. ファイル名の不一致： Google Takeoutは、重複ファイル名が発生すると IMG_1234(1).jpg のようにリネームしますが、JSON側との対応付けが複雑になり、多くのツールがクラッシュしました。
  2. メモリ不足： すべてのファイルリストをメモリに展開するタイプのスクリプトでは、数万ファイルの処理中にHeap Memoryエラーが発生。
  3. HEICの扱い： iPhoneで撮影されたHEIC形式に対応していないツールが多く、動画ファイル（MOV/MP4）の撮影日時は無視されることがありました。

解決策：ExifToolによるメタデータ強制結合

GUIツールに頼るのは諦め、業界標準の最強ツール ExifTool を使って、コマンドラインから確実にメタデータをマージすることにしました。この方法は泥臭いですが、最も確実で、制御可能です。

以下は、私が実際に使用したシェルスクリプトの簡略版です。Google Takeoutのフォルダ構造を再帰的に探索し、JSON内の PhotoTakenTimeTimestamp を画像の DateTimeOriginal に焼き付けます。

#!/bin/bash
# 依存関係: exiftool がインストールされていること
# 警告: 必ずバックアップを取ってから実行してください

TARGET_DIR="./GoogleTakeout_Unzipped"

echo "メタデータの修復を開始します: $TARGET_DIR"

# findコマンドで全ディレクトリを走査
find "$TARGET_DIR" -type f -name "*.json" | while read json_file; do
    # 対応する画像ファイル名を推測 (拡張子を取り除く)
    # 例: image.jpg.json -> image.jpg
    base_image="${json_file%.*}"
    
    if [ -f "$base_image" ]; then
        # JSONからExifへの書き込み
        # -TagsFromFile: JSONファイルをソースとして指定
        # -DateTimeOriginal: 撮影日時を復元
        # -GPS*: 位置情報を復元 (地図機能のために必須)
        
        exiftool -overwrite_original \
                 -TagsFromFile "$json_file" \
                 "-DateTimeOriginal<PhotoTakenTimeTimestamp" \
                 "-CreateDate<PhotoTakenTimeTimestamp" \
                 "-ModifyDate<PhotoTakenTimeTimestamp" \
                 "-GPSLatitude<GeoDataLatitude" \
                 "-GPSLatitudeRef<GeoDataLatitude" \
                 "-GPSLongitude<GeoDataLongitude" \
                 "-GPSLongitudeRef<GeoDataLongitude" \
                 "$base_image"
                 
        echo "Fixed: $base_image"
    else
        # ファイル名の(1)などの揺らぎ対応が必要な場合のログ
        echo "Skipped (Image not found): $base_image" >> error_log.txt
    fi
done

echo "処理完了。Synology Photosへアップロードしてください。"

このスクリプトの肝は、-TagsFromFile オプションを使ってJSONを「サイドカーファイル」として扱い、そこから特定のタグ（撮影日時やGPS座標）を画像本体へ注入している点です。特に PhotoTakenTimeTimestamp はUnixタイムスタンプ形式であることが多いですが、ExifToolはこれを自動的に適切な日時フォーマットへ変換してくれるため、非常に強力です。

Note: 動画ファイル（MP4/MOV）の場合、Exif標準のタグではなく QuickTime:CreateDate などを操作する必要があります。上記スクリプトは静止画メインのため、動画が含まれる場合はタグ指定の調整が必要です。

この前処理を行った後、Synology Photosの /photo ディレクトリへファイルを転送しました。すると、DSMのインデックスサービスが走り出し、ブラウザ上のタイムラインが見る見るうちに「正しい過去の日付」で埋め尽くされていきました。あのバラバラだった記憶が、正しい時系列で整列する様子は、エンジニアとして一種のカタルシスを感じる瞬間です。

移行後のパフォーマンスとコスト比較

GooglePhotos（クラウド）とSynology Photos（オンプレミス）を実際に運用して感じた違いを、数値と体感の両面から比較します。

比較項目 Google Photos (2TB Plan) Synology Photos (DS224+)
5年間の総コスト 約 85,000円 (月額1,300円換算) 約 60,000円 (本体+HDD) ※買い切り
プライバシー Googleの規約に依存 (AI学習対象) 完全な所有権 (ローカル処理)
表示速度 (宅内) インターネット回線に依存 爆速 (LAN内ならギガビット転送)
顔認識精度 超高精度 (マスク着用でも認識) 高精度 (ただしインデックスに時間がかかる)
RAWファイルの扱い 容量を圧迫するため敬遠しがち HDD容量がある限り無制限

特筆すべきは「表示速度」です。自宅のWi-Fi環境下であれば、サムネイルのスクロールはGoogle Photosよりも圧倒的に高速です。オリジナルの4K動画を再生する際も、バッファリング待ちがほぼ発生しません。これは、インターネット回線を経由せず、LAN内でデータが完結している最大のメリットです。

一方で、外出先からのアクセス（モバイル回線経由）については、自宅のアップロード帯域（上り回線速度）に依存します。Synologyの「QuickConnect」機能は便利ですが、リレーサーバーを経由するため若干の遅延を感じることがあります。私はVPNサーバー（Tailscale）を併用することで、セキュアかつダイレクトな接続環境を構築しました。

Synology Photos 公式セットアップガイド

注意点とエッジケース：これから移行する人へ

Synology Photosは素晴らしいソリューションですが、万能ではありません。移行前に知っておくべき「落とし穴」があります。

1. HEICとLive Photosの扱い

iPhoneユーザーの場合、HEIC形式の表示にはSynology側でAdvanced Media Extensions（AME）のインストールが必要です。これにはSynologyアカウントでのログインが必須となります。また、Live Photos（動く写真）は、静止画と動画ファイルとして正しくペアリングされていれば再生可能ですが、メタデータが破損していると静止画としてしか認識されないケースがありました。

2. 顔認識処理中のCPU負荷

5万枚の写真を一度に流し込むと、Synology PhotosのAIエンジンが顔認識のためにバックグラウンドで走り続けます。DS224+（Celeron J4125）クラスのCPUでも、最初の数日間はCPU使用率が常に80%を超え、他のDockerコンテナなどの動作が重くなる現象が見られました。移行は「寝る前」に行い、数日間はインデックス処理が終わるのを辛抱強く待つ必要があります。

Best Practice: 大量の写真を転送する際は、Synology Photosの管理画面から「インデックス再作成」を手動でトリガーせず、フォルダ単位で徐々にファイルを追加していくと、システムへの負荷を分散できます。

結論：データの「賃貸」から「持ち家」へ

GooglePhotosからの移行作業は、正直に言えば手間がかかります。特にExif情報の整理は、技術的な知識がないと途方に暮れるポイントかもしれません。しかし、その労力を乗り越えた先には、「自分の思い出を、自分の管理下に置く」という確かな安心感があります。

Synology Photosは、GooglePhotosのUXを非常に良く研究しており、移行後の違和感は最小限です。もしあなたが毎月のクラウドストレージ課金に疑問を感じているなら、NASへの投資は長い目で見て金銭的にも精神的にも大きなリターンをもたらすでしょう。まずは週末、HDDをベイに挿入するところから始めてみてはいかがでしょうか。

Related Posts

Loading…

Post a Comment