「ストレージの空き容量が不足しています」。この警告が深夜のスマートフォンに表示されたとき、多くのエンジニアは二つの選択肢を迫られます。月額課金のプランを上位にアップグレードしてGooglePhotosのエコシステムにさらに深く依存するか、それとも初期投資を行って自前のプライベートクラウドを構築するかです。私のケースでは、家族の写真と動画の総量が2TBを超えようとしており、パブリッククラウドのランニングコストと、AIによるデータスキャン（プライバシー）への懸念が無視できないレベルに達していました。本稿では、単なるカタログスペックの比較ではなく、実際に数万枚の写真を移行する際に直面した技術的課題（特にメタデータの欠損問題）と、それを解決するためのスクリプト、そして5年スパンでのTCO（総所有コスト）分析について共有します。
アーキテクチャの相違：オブジェクトストレージ vs ブロックストレージ
技術的な観点から見ると、この比較は「スケーラブルなオブジェクトストレージ（S3ライクな構造）」と「ローカルネットワーク上のブロックストレージ（RAID構成）」の比較と言い換えることができます。Googleのインフラは圧倒的な計算資源を持ち、TensorFlowを用いたTPU上で画像認識処理を行うため、「犬」や「結婚式」といった検索クエリに対して驚異的な速度で応答します。
一方で、Synology Photosを稼働させるNAS（例えばDS920+やDS1621+など）は、ローカルのCPU（Intel CeleronやAMD Ryzen Embedded）に依存します。私が最初に直面したのは、インデックス作成のボトルネックでした。数万枚の写真を一度にアップロードすると、SynologyのバックグラウンドタスクがCPU使用率を100%に張り付かせ、数日間NASの反応が鈍化する現象が発生しました。
多くのユーザーはここで「Synologyは使いにくい」と誤解してしまいますが、これはファイルシステムとメタデータ管理の仕様の違いによるものです。この問題をエンジニアリングで解決しなければ、真の移行は完了しません。
失敗談：単純なドラッグ＆ドロップの代償
当初、私はWindowsのエクスプローラー経由で、ダウンロードしたGoogle TakeoutのフォルダをそのままSynologyの`/photo`ディレクトリにSMB転送しました。結果は惨憺たるものでした。2015年に撮影したはずの写真が「今日の日付」で登録され、ファイル作成日が更新日として扱われてしまったのです。GooglePhotos上では正しく表示されていたメタデータが、ダウンロードの過程でファイル本体（バイナリ）には埋め込まれず、サイドカーJSONファイルとして分離されていたことが原因でした。
解決策：ExifToolによるメタデータ再統合
この問題を解決するには、分離されたJSONファイル内の情報を読み取り、画像ファイルのExifヘッダに書き戻す処理が必要です。以下は、私が作成したPythonスクリプトのロジックを簡略化したBashワンライナーの概念実証です。最強のツールであるExifToolを使用します。
// 警告：必ずバックアップを取ってから実行してください
// Google Takeoutの仕様は頻繁に変更されるため、ドライラン（テスト実行）を推奨します
# ディレクトリ内のすべてのJPGに対して、同名のJSONから日時情報を復元する
# -TagsFromFile : JSONファイルを参照元とする
# -DateTimeOriginal : 撮影日時を復元
# -overwrite_original : バックアップファイルを作らず上書き（容量節約のため）
exiftool -r -d %s -TagsFromFile "%d/%F.json" \
"-GPSAltitude<GeoDataAltitude" \
"-GPSLatitude<GeoDataLatitude" \
"-GPSLatitudeRef<GeoDataLatitude" \
"-GPSLongitude<GeoDataLongitude" \
"-GPSLongitudeRef<GeoDataLongitude" \
"-DateTimeOriginal<PhotoTakenTimeTimestamp" \
"-CreateDate<PhotoTakenTimeTimestamp" \
"-ModifyDate<PhotoTakenTimeTimestamp" \
-overwrite_original \
-ext jpg -ext mp4 .
// 解説：
// Google TakeoutのJSON構造では "PhotoTakenTimeTimestamp" がUNIX時間で格納されている場合があります。
// GPS情報もJSONに含まれているため、地図表示機能のためにこれらも復元します。このスクリプトを実行することで、画像ファイル自体に正しい撮影日時と位置情報が埋め込まれます。この状態でSynology Photosへアップロードすることで、DSM（DiskStation Manager）のインデクシングサービスが正しくタイムラインを構築できるようになります。
コストとパフォーマンスの比較分析
エンジニアとして気になるのは、定性的な「便利さ」だけでなく、定量的なコストとパフォーマンスです。以下に、2TBのデータを5年間運用した場合の試算をまとめました。
| 比較項目 | GooglePhotos (2TB Plan) | Synology Photos (DS224+ / 4TBx2) |
|---|---|---|
| 5年間の総コスト (TCO) | 約 ¥84,000 (¥1,300/月 × 60) | 約 ¥75,000 (本体 + HDD) |
| データ所有権 | Google (規約によりAI学習利用の可能性) | 完全なユーザー所有 |
| アップロード速度 | ISPの上り帯域に依存 (通常遅い) | ローカルLAN速度 (1Gbps/2.5Gbps) ※爆速 |
| AI検索精度 | Sランク (文脈理解が可能) | Bランク (顔・物体認識は可能だが文脈は弱い) |
| RAW現像対応 | 限定的 (プレビューのみ) | 対応 (機種による) |
表から分かる通り、5年スパンで見るとコストは逆転し始めます。しかし、最も大きな違いは「アップロード速度」です。Wi-Fi 6環境下のローカルネットワークであれば、ギガバイト級の動画ファイルも数秒でNASに転送完了します。GooglePhotosへのアップロードでプログレスバーを眺め続けるストレスから解放されたのは、予想外のメリットでした。
Synology Photos 公式仕様を確認するエッジケースと運用上の注意点
Synology Photosへの移行はすべてがバラ色ではありません。運用してみて判明したいくつかのエッジケースについて警告しておきます。
また、自宅のインターネット回線がIPv4 over IPv6（DS-Liteやv6プラス）環境の場合、外部アクセス（外出先から写真を見る機能）の設定に工夫が必要です。Synologyの「QuickConnect」機能を使えばルーターのポート開放なしで接続できますが、リレーサーバーを経由するため転送速度が著しく低下することがあります。高画質な動画を外出先からストリーミング再生したい場合は、VPNサーバーの構築やDDNSの設定が必要になるでしょう。
結論：エンジニアにとっての「資産」とは
GooglePhotosは「体験」を提供し、Synology Photosは「資産管理」を提供します。もしあなたが、写真を単なるSNSシェアの材料として消費するだけなら、GooglePhotosの利便性は最強です。しかし、写真は「データの奔流」ではなく、人生のログであり、自ら管理すべき資産であると考えるなら、Synology NASへの投資は極めて合理的です。初期設定やメタデータの整理といったエンジニアリングコストを支払うことで、私たちはデータの主権を取り戻すことができるのです。
Post a Comment