Google フォトからNASへ移行する際の失敗5選｜メタデータとTakeoutの落とし穴

移行時の主な失敗パターン早見表

Google フォトから NAS に移すとき、写真の日時や位置情報が正しく引き継がれないことがあります。元ファイル内のEXIFは残っていても、Google Photos上で加わった情報はJSON sidecarへ分かれることがあるためです。NAS側がそのJSONを読まない場合、時系列や地図表示が崩れやすくなります。

なぜGoogle フォトからNAS移行は難しいのか

Google フォトから写真をダウンロードしてNASに入れるだけなら、作業自体はシンプルです。難しさが出るのは、Google フォト上で成立していた情報のまとまりを、そのまま別の環境へ持っていけないところです。Googleは公式ヘルプでも、Takeoutでは元ファイルにない追加メタデータを二次JSONへ出力し、ダウンロード要求からアーカイブ作成までの間に行った変更は反映されないことがあると案内しています。

Google フォトは写真ファイルとは別に追加情報を管理している

iPhoneやデジタルカメラで撮影した写真には、ファイル本体にEXIF形式で撮影日時・カメラ設定・GPS座標が埋め込まれています。ファイルをコピーすれば情報も一緒に移動します。

Google フォトもアップロード時点ではEXIFを保持しますが、ユーザーがGoogle フォト上で加えた編集はEXIFに反映されません。撮影日時の手動修正、後から追加した位置情報、説明文の追加といった変更はGoogle独自のデータベースに保存され、Takeout書き出し時にJSONファイル（sidecar）として写真ファイルとは別に出力されます。

加えて、「保存容量の節約画質」を使っていた場合はアップロード時に再圧縮が発生し、EXIFの一部が失われることがあります。Google フォトに長期間保存していた写真は、撮影時のオリジナルとは微妙に異なる状態になっている可能性があり、この差分がNAS移行時に表面化します。

NASは製品ごとに読み取れるメタデータが違う

EXIFが正しくファイルに残っていても、NAS側の写真管理アプリがそのすべてを読み取るとは限りません。

主要なNAS製品はいずれも、Google TakeoutのJSON sidecarを自動で読み込みません。Google フォト上で編集した日時や位置情報をNASに反映するには、ユーザー自身がアップロード前にJSONの情報をEXIFに書き戻す必要があります。動画ファイルではさらに事情が複雑で、製品ごとに参照する日時フィールドが異なるため、写真は正しい順に並んでいるのに動画だけバラバラ、という現象が起きます。これは「失敗2」で詳しく取り上げます。

{{UGPRODUCT}}

失敗1------メタデータがずれて時系列が崩れる

Google フォトからNASへの移行で報告されるトラブルの中で、写真一覧を開いてみると、数年前の家族旅行の写真がつい最近の日付で表示されていたり、年代順に並んでいたはずのアルバムがバラバラになっていたりする。原因のほとんどは、メタデータの扱いに関する理解不足にあります。

なぜJSON sidecarが問題になるのか

Google Takeoutで書き出した写真データには、画像ファイルとは別に「.json」という拡張子のファイルが付属しています。たとえば「IMG_1234.jpg」という写真には「IMG_1234.jpg.json」というファイルがペアで存在します。

このJSONファイルの中には、以下のような情報が格納されています。

• 撮影日時（photoTakenTime）
• GPS座標（geoData / geoDataExif）
• 写真の説明文（description）
• Google Photos上での表示タイトル（title）
• お気に入り登録の有無（favorited）
• アーカイブ状態（archived）

ここで問題になるのは、NASの写真管理アプリはこのJSONファイルを無視するという点です。Synology Photos、QNAP QuMagie、UGREEN UGOSのいずれも、写真のインデックス作成時にはファイル本体のEXIFデータだけを読み取ります。JSONファイルが同じフォルダに置かれていても、その中身は参照されません。

つまり、Google フォト上で日時や位置情報を編集していた場合、その編集後の正しい情報はJSONにしか存在しないにもかかわらず、NASはそれを読めない。結果として、NAS上には「編集前の古い情報」または「情報なし」の状態で写真が登録されることになります。

対策：「Google フォト Takeout Helper」や「ExifTool」等の書き戻しツールの活用と確認項目

JSON sidecarの問題を解決するには、NASにアップロードする前に、JSONの情報を写真ファイルのEXIFに書き戻す処理が必要です。手作業で1枚ずつ修正するのは現実的ではないため、専用ツールを使います。

代表的なツールは以下の2つです。

Google フォト Takeout Helper（無料・オープンソース）

GitHub上で公開されているPython製のツールで、Takeoutで書き出したフォルダを指定するだけで、JSONファイルの情報を対応する写真のEXIFに自動で書き戻してくれます。撮影日時、GPS座標、説明文に対応しており、処理後は不要になったJSONファイルを削除するオプションもあります。

コマンドライン操作が必要ですが、READMEに従えばIT初心者でも実行可能なレベルです。WindowsでもMacでも動作します。

ExifTool（無料・クロスプラットフォーム）

Phil Harveyが開発した、メタデータ操作の定番ツールです。写真・動画のEXIF、IPTC、XMPなどあらゆるメタデータを読み書きできます。Google Photos Takeout Helperよりも細かい制御が可能ですが、コマンドの記述がやや複雑なため、メタデータの扱いに慣れている人向けです。

書き戻し後に確認すべき項目：

ツールで一括処理した後は、必ずサンプルチェックを行ってください。全ファイルを1枚ずつ確認するのは非現実的なので、以下の方法で効率よく検証します。

1. 撮影日時の確認： 処理済みフォルダを日付順にソートし、明らかに日付がおかしいファイルがないかを目視で確認する。年初・年末や旅行期間中の写真など、日付を覚えている写真を数枚ピックアップして照合するのが効率的です。
2. GPS情報の確認： ExifToolやEXIF確認ができるアプリ（iPhoneなら「Metapho」、PCなら「ExifToolGUI」など）で、ランダムに10〜20枚選んで位置情報が正しく入っているかを確認します。
3. ファイル形式の確認： JPEG、HEIF、PNGなど形式の異なるファイルをそれぞれ数枚ずつ選び、書き戻し処理でファイルが破損していないかを確認します。画像が正常に表示されること、ファイルサイズが極端に変わっていないことをチェックしてください。
4. 動画ファイルの確認： 動画はEXIFの構造が写真と異なるため、書き戻しツールが正しく動作しないケースがあります。特にMOV形式やMP4形式の動画は、ツールによって対応状況が違います。動画ファイルについては後のセクション「失敗2」で詳しく取り上げます。

失敗2------動画とLive Photos（動く写真）の扱いが難しい

メタデータの書き戻しで写真の時系列を修正できたとしても、動画ファイルには同じ方法が通用しない場合があります。 さらに、Live Photosやモーションフォトはファイル構成自体が変わってしまうため、写真とは別の対処が必要です。

写真と動画でExifデータの扱いが違う理由（作成日と撮影日の混同）

写真ファイル（JPEG、HEIF、PNGなど）のメタデータは、EXIFという標準化された形式でファイル内に格納されています。「撮影日時」というフィールドが明確に定義されており、ほぼすべての写真管理ソフトがこのフィールドを「撮影日」として認識します。

一方、動画ファイル（MOV、MP4など）には、EXIFに相当する統一的な「撮影日時」フィールドが存在しません。 代わりに、動画のコンテナ形式ごとに異なる複数の日時フィールドが存在します。

問題は、NASの写真管理アプリがどのフィールドを「撮影日」として採用するかが製品ごとに異なるという点です。あるNASアプリはCreateDateを参照し、別のアプリはFileModifyDateを使う。Takeoutで書き出した動画は、ダウンロードや解凍の過程でFileModifyDateが「書き出し実行日」に上書きされることがあるため、このフィールドを参照するNASアプリでは、すべての動画が同じ日付に並んでしまうという現象が起きます。

さらに厄介なのが、MOV形式の動画でCreateDateがUTC（協定世界時）で記録される仕様です。日本時間（JST）はUTCより9時間進んでいるため、NASアプリがタイムゾーン補正を行わない場合、2024年1月1日の午前0時に撮影した動画が「2023年12月31日 15:00」として表示されるケースがあります。日付をまたぐタイミングで撮影した動画ほど、この9時間のずれが目立ちます。

現実的な対処法：

この問題に完璧な解決策はありません。現時点で取れる対応は以下のとおりです。

• 静止画を優先し、動画部分は補助的な扱いにする： 分離されたMP4ファイルをまとめて別フォルダに移動し、静止画だけをNASの写真ライブラリに登録する。動画部分が必要なときだけ別フォルダから参照する運用です。
• ファイル名で紐付けを維持する： 静止画と動画のファイル名が同じ（拡張子だけ異なる）であれば、後から対応関係を追跡できます。ファイル名を変更する際は、ペアの関係が壊れないよう注意してください。
• Google フォトからの移行ではなく、iPhoneから直接NASにバックアップし直す： もしiPhone本体やiCloud上にオリジナルのLive Photosが残っている場合は、Google Takeout経由ではなく、iPhoneからNASアプリ（UGOSなど）で直接バックアップするほうが、Live Photosの形式を維持できる可能性が高くなります。

Live Photosやモーションフォトの枚数が少ない場合は大きな問題にはなりませんが、日常的にLive Photosを使っていた人は、移行前にその枚数を把握しておくことを推奨します。Google フォトの検索バーで「モーション」と入力すると、対象の写真を絞り込むことができます。

失敗3------Google Takeoutの書き出しが重い、遅い、ダウンロードが失敗する

Takeout自体の使い勝手の悪さです。Google Takeoutは無料で使える公式のデータエクスポート機能ですが、大量の写真・動画を扱う場面では、想像以上に時間がかかり、途中で失敗するリスクも小さくありません。

エクスポートに数分〜数日かかる理由

Google Takeoutの「エクスポートを作成」ボタンを押してから、実際にダウンロードリンクが届くまでの時間は、データ量によって大きく異なります。

この時間の大半は、Google側のサーバーでアーカイブを生成する処理に費やされます。ユーザーの回線速度は関係ありません。Googleのサーバー負荷状況によっても処理時間は変動するため、同じデータ量でもタイミングによって完了までの時間が違うことがあります。

エクスポートが完了すると、登録メールアドレスに通知が届きます。ただし、ダウンロードリンクの有効期限は約1週間です。この期限を過ぎるとリンクが無効になり、もう一度エクスポートをやり直す必要があります。出張や旅行で数日間PCに触れない時期にエクスポートを開始すると、戻ってきたときにはリンクが切れていた、というケースは珍しくありません。

もう一つ注意すべきなのが、エクスポート処理中にGoogle Photos側でデータを変更しないことです。Takeoutがアーカイブを生成している最中に写真を追加・削除・編集すると、書き出されるデータと実際のライブラリに不整合が生じる可能性があります。

対策：一括本番の前に少量アルバムで試す（ZIPサイズは2GB〜10GB推奨）

Takeoutのエクスポートには時間がかかり、失敗した場合のやり直しコストも高いため、いきなり全データを書き出すのは避けるべきです。 まずは小規模なテストを行い、自分の環境で問題なく動くことを確認してから本番に臨んでください。

テスト移行の手順：

ステップ1：テスト用のアルバムを選ぶ

Google Photosで100〜300枚程度のアルバムを1つ選びます。理想的なのは、以下の条件を満たすアルバムです。

• 写真と動画の両方が含まれている
• Live Photosまたはモーションフォトが数枚含まれている
• 撮影日時が明確に分かっている（旅行や行事の日付など）
• GPS情報が記録されている写真がある

ステップ2：Takeoutで対象アルバムだけをエクスポートする

Google Takeoutの設定画面で、「Google フォト」を選択した後、「すべてのフォトアルバムを含める」のチェックを外し、テスト用のアルバムだけを選択します。分割サイズは2GBで十分です。

ステップ3：ダウンロード・解凍・書き戻しを実行する

生成されたZIPをダウンロードして解凍し、Google Photos Takeout HelperまたはExifToolでJSONの書き戻しを実行します。この段階で、ツールが正常に動作するか、エラーが出ないかを確認します。

ステップ4：NASにアップロードして検証する

書き戻し済みの写真・動画をNASにアップロードし、以下の項目をチェックします。

• 撮影日時が正しく表示されているか
• GPS情報が地図上に反映されているか
• 動画が正常に再生されるか
• Live Photos / モーションフォトはどう表示されるか
• サムネイルが正しく生成されているか

ステップ5：問題があれば原因を特定して修正する

テスト移行で問題が見つかった場合、100〜300枚の範囲であれば原因の特定と修正が容易です。ここで発見した問題点と対処法を記録しておけば、本番の全データ移行で同じ問題に悩まされずに済みます。

テスト移行にかかる時間は、慣れていなくても半日程度です。 全データの移行が失敗して最初からやり直す場合の時間的コスト（数日〜1週間）を考えれば、テスト移行は費用対効果の高い予防策です。テストで問題がなければ、同じ手順を全データに対して実行するだけで、安心して本番移行を進められます。

失敗4------NASに入れた後で重複や散在が起きる

移行直後はきれいに整理できていたはずなのに、使い続けるうちにファイルが増殖したり、同じ写真が別々のフォルダに散らばったりする。原因を理解しておけば、事前に防ぐことができます。

Takeout解凍後のフォルダ構造がそのままだと管理しづらい理由

Takeoutから書き出したデータを解凍して、そのままの状態でNASにアップロードする人は少なくありません。「とりあえず入れておけば後で整理できる」という考え方ですが、この「とりあえず」が後々の管理を大幅に難しくします。

Takeoutの解凍後フォルダには、以下のようなファイルが混在しています。

• 写真ファイル本体（.jpg、.heic、.pngなど）
• 動画ファイル本体（.mp4、.movなど）
• JSONメタデータファイル（.json）
• Google Photosが自動生成した加工版ファイル（-edited、-effectsなどの接尾辞付き）
• Live Photos / モーションフォトの分離動画ファイル
• アルバム名フォルダに入った重複コピー

書き戻しツールでJSONの情報をEXIFに統合した後も、JSONファイル自体はフォルダ内に残ったままです。NASの写真管理アプリはJSONファイルを写真としては認識しませんが、ファイルマネージャーで見ると大量のJSONが写真ファイルの間に並んでいる状態になり、手動でフォルダを操作する際に紛らわしくなります。

また、Takeoutのフォルダ名にはGoogle側が付けた命名規則（「Photos from 2023」など英語表記）が使われています。NASに入れた後でフォルダ名を日本語に変更したり、独自の構造に組み替えたりすると、元のTakeout構造との対応関係が分からなくなり、後から検証や追加移行をする際に混乱の原因になります。

対策としては、NASにアップロードする前の段階で、不要なファイルの削除とフォルダ構造の再編成を済ませておくのが効率的です。具体的には以下の手順を推奨します。

1. 書き戻しツールでJSONの情報をEXIFに統合する
2. 処理済みのJSONファイルをすべて削除する（ツールによっては自動削除オプションあり）
3. 加工版ファイル（-edited等）が不要であれば削除する
4. アルバム名フォルダの重複ファイルを、前セクションで説明した手順で処理する
5. 整理済みのフォルダをNASにアップロードする

この前処理を怠ると、NAS上に「写真10,000枚＋JSON10,000ファイル＋重複3,000枚＋加工版500ファイル」のような状態が生まれ、後から整理する手間は前処理の何倍にもなります。

写真・動画・編集版ファイルをどう区別するか

Takeoutの出力には、ユーザーが撮影したオリジナルファイル以外に、Google Photosが自動的に生成したファイルが含まれていることがあります。これらを区別せずにNASに入れると、「見覚えのない写真がライブラリに混ざっている」「同じ構図の写真が微妙に異なるバージョンで複数存在する」といった混乱が起きます。

識別のポイントは、ファイル名の接尾辞とフォルダの位置です。

-editedファイルについて： Google Photos上でトリミングや色調補正などの編集を行った場合、その編集版が別ファイルとして出力されます。オリジナルと編集版の両方が必要な場合は、NAS上で「オリジナル」と「編集済み」のサブフォルダを分けて保存すると管理しやすくなります。編集版が不要であれば、アップロード前に削除して構いません。

（1）付きファイルについて： Takeoutが出力するファイルの中に「IMG_1234(1).jpg」のような連番付きファイルが存在する場合、これはTakeoutの分割処理やアルバム重複の過程で生成されたコピーである可能性が高いです。オリジナルと内容が同一かをハッシュ値で確認し、同一であれば削除してください。

移行前後で使うべき命名ルールとフォルダルール

重複と散在を長期的に防ぐには、移行のタイミングで命名ルールとフォルダルールを決めて、以降のバックアップにも統一的に適用することがです。移行時にルールを決めておかないと、Takeoutデータ、iPhoneからの自動バックアップ、手動コピーのファイルが混在し、数年後には誰にも整理できない状態になります。

ファイル名のルール：

原則として、ファイル名はリネームしないことを推奨します。理由は以下の3つです。

• 元のファイル名を維持しておけば、Google PhotosやiPhoneのデータと照合できる
• リネームの過程でファイルの対応関係が壊れるリスクがある（特にLive Photosのペア）
• NASの写真管理アプリは、日付やメタデータで写真を整理するため、ファイル名で並べ替える必要性が低い

どうしてもリネームが必要な場合は、「撮影日時_元のファイル名」（例：20230415_IMG_1234.jpg）の形式にすると、ファイルマネージャー上でも時系列で並び、元のファイル名との対応も追跡できます。

失敗5------NASに入れた安心感で元データを早く消してしまう

NASへのアップロードが完了すると、「無事に移行できた」という安心感から、Google Photos側のデータをすぐに削除したくなります。Google Photosのストレージ容量を空けたい、サブスクリプションをダウングレードしたい、という動機がある人ほど、この傾向は強くなります。ですが、アップロードの完了は「移行の成功」を保証しません。 ファイルがNAS上に存在することと、そのファイルが正しい状態で使える状態にあることは、まったく別の話です。

移行完了とバックアップ完了は別物

多くの人が見落としがちなのが、「ファイルが存在する」と「データが保全されている」の違いです。

NASのフォルダを開いて写真のサムネイルが表示されていれば、見た目上は移行が成功したように見えます。ファイル数を数えて、Google Photosの枚数と一致していれば、なおさら安心します。ですが、この段階で確認できているのは「ファイルがNASのストレージに書き込まれた」という事実だけです。

以下のような問題は、サムネイル一覧やファイル数のチェックだけでは発見できません。

• 撮影日時がTakeout実行日に置き換わっている
• GPS情報が欠落し、地図表示ができない
• 動画ファイルが破損していて再生できない
• Live Photosの動画部分が静止画と分離している
• 「保存容量の節約画質」で再圧縮された低画質版がオリジナルとして保存されている
• 一部のファイルが転送途中でエラーを起こし、0バイトのファイルとして残っている

数ヶ月後にこれらの問題が発覚した時点でGoogle Photos側のデータを削除済みだと、比較対象も復元元も存在しません。Google Photosで写真を削除すると、ゴミ箱に移動した時点から60日のカウントダウンが始まります。この60日間は、NAS上のデータに問題が見つかったときに復元できる最後のセーフティネットになります。ゴミ箱の手動消去は行わず、60日の自動削除に任せてください。

NAS上のデータ検証とバックアップ設計が完了すれば、Google フォトからの移行作業は実質的に完了です。ここから先は、NASに集約した写真・動画を家族とどう共有するかを考える段階に入ります。LINEやiCloud共有アルバムでは画質が落ちる、Google Photosでは相手にアカウント作成を求めるといった共有面の制約をNASでどう解決するかについては、家族の写真・動画を画質を落とさず共有する方法｜NAS活用7ステップで詳しく解説しています。

チェックすべきは件数、容量、時系列、ランダム抽出、動画再生

Google Photos側のデータを削除する前に、以下の5つの観点でNAS上のデータを検証してください。全ファイルを1枚ずつ確認する必要はありませんが、各観点で少なくとも数十枚のサンプルをチェックすることを推奨します。

① 件数の照合

Google Photosの「ストレージ」画面で表示される写真・動画の総数と、NAS上のファイル数を比較します。完全一致が理想ですが、数十枚程度の差は許容範囲です。Google Photosが自動生成したコラージュやアニメーション、またはTakeout処理時の重複分が差異の原因になることがあります。ただし、数百枚以上の差がある場合は、転送漏れや重複の可能性が高いため、原因を特定してください。

② 容量の照合

件数だけでなく、データ総量（GB）も確認します。NAS側の合計容量がGoogle Photosの使用容量に対して極端に小さい場合、サムネイルだけが転送されてオリジナルが欠けている可能性があります。逆に大幅に大きい場合は、アルバム重複によるファイルの増殖が考えられます。

③ 時系列の確認

NASの写真管理アプリで写真を日付順に表示し、明らかにおかしい日付の写真がないかを確認します。特に注目すべきポイントは以下の3つです。

• 古い写真の日付が正しいか（初期のデータほどメタデータの問題が出やすい）
• 直近の写真の日付が「Takeout実行日」に置き換わっていないか
• 年をまたぐタイミング（12月〜1月）の写真が正しい年に入っているか

④ ランダム抽出によるスポットチェック

年代ごとに5〜10枚をランダムに選び、以下を確認します。

• オリジナル画質で表示されるか（拡大してもピクセルが粗くないか）
• GPS情報が保持されているか（地図表示やロケーション情報が出るか）
• Google Photos上で追加した説明文やタイトルが反映されているか（書き戻しツールで対応した場合）

⑤ 動画の再生確認

動画ファイルは写真よりも破損リスクが高いため、個別に確認が必要です。年代ごとに2〜3本の動画を選び、最初から最後まで再生できるかを確認してください。特に、長尺の動画（5分以上）は途中で再生が止まったり、音声と映像がずれたりするケースがあるため、短い動画だけの確認では不十分です。

削除前に最低2系統で確認する

上記の検証をNAS上で完了した後も、Google Photosのデータをすぐに削除するのは推奨しません。 もう1つの確認手段として、NAS以外の場所にもデータが存在する状態を作ってから削除に踏み切るのが安全です。

「2系統確認」の考え方：

データの保全において、同じデータが2箇所以上に存在する状態を維持するというのが基本原則です。移行のタイミングでは、「Google Photos」と「NAS」の2箇所にデータが存在しています。ここからGoogle Photosを削除すると、NAS1箇所だけになります。

NASのHDDが故障した場合、その時点でデータは完全に失われます。RAIDを構成していても、複数HDDの同時故障や筐体の故障には対応できません。

安全に削除するための手順は以下のとおりです。

ステップ1：NAS上のデータ検証を完了する（前述の5項目）

ステップ2：NASとは別の場所にバックアップを作成する

選択肢は主に3つあります。

• 外付けHDDへのコピー（手軽でコストも低い）
• 別のクラウドストレージへのアップロード（Amazon Photos、Backblazeなど）
• 別のNASやPCへのネットワークコピー

ステップ3：バックアップ先のデータも検証する

バックアップ先でもファイル数と容量を照合し、ランダムに数枚を開いて正常に表示されるか確認します。

ステップ4：Google Photosのデータを削除する

NASとバックアップ先の2箇所にデータが正しく存在することを確認できた段階で、Google Photosのデータを削除します。

ステップ5：削除後もすぐにはGoogle Photosのゴミ箱を空にしない

Google Photosで写真を削除しても、ゴミ箱に60日間残ります。この60日間が最後のセーフティネットになるため、NASのデータに問題が見つかった場合にゴミ箱から復元できます。ゴミ箱の手動消去は行わず、60日間の自動削除に任せてください。

まとめ

Google フォトからの移行を始める前に、自分のデータ量に合ったNASのモデルを選んでおくと、書き戻しツールやテスト移行の運用設計がスムーズになります。家庭用の2ベイモデルから、写真・動画クリエイター向けの4ベイ・8ベイモデルまでの選択肢はUGREEN NASync シリーズで確認できます。