更新日：2026年8月28日｜カテゴリ：バックアップ・データ保護
結論：撮影日が写真の中に残っていれば、NASに入れるだけで年月順に並ぶ
Googleフォトの写真をNASへ移す作業は、Google Takeoutで書き出す → 中身を確認する → NASの写真フォルダへ置く、この3つで終わります。当サイトがSynology DS223jで通したところ、デジカメで撮った未編集のJPGは、ファイルの更新日時がzip展開日に書き換わっていても、Synology Photosのタイムラインで正しく2018年11月の位置に並びました。撮影日が写真の中（EXIF）に残っていれば、日付は壊れません。
壊れるのは、撮影日時がファイルの中に書かれていないファイルです。当サイトでは、2020年1月3日に撮ったスクリーンショット（PNG）がタイムライン上で作業日の2026年8月27日に化けました。これは、無料ツール（個人開発・無保証）を通して元の日付に戻せました。
進める順番は、①画質設定を確認 ②その期間の写真がNASに既にないか確認（どちらも「移す前に確認する2つのこと」） ③Takeoutで書き出す（手順1） ④壊れているか判定（手順2） ⑤そのままでよいものをNASへ置く（手順3） ⑥壊れているものは復元してから置く（手順4・5）。解約は、中身を見て納得してから最後に判断すれば間に合います。
毎月の容量通知に追われる状態から抜けたい、というのがこの作業の動機だと思います。この形にすると、家族の写真の置き場所が「毎月払い続ける契約」から「手元にある機械」に変わります。容量が足りなくなればHDDを大きいものへ入れ替えて伸ばせますし、写真が増えたぶん料金が上がることもありません（かかり続けるのは電気代と、いずれ来るHDDの交換費用です）。
移す前に確認する2つのこと
申請の前に、数分で終わる確認が2つあります。どちらも後から取り返しがつきにくい部分です。
1. バックアップの画質設定を見る
パソコンのブラウザで photos.google.com を開き、設定（歯車）→「バックアップの画質」を見ます。ここが「元の画質」なら、Googleは撮影時と同じ解像度のファイルを預かっています。公式の説明は次のとおりです。
- 元の画質＝「写真と動画は撮影時と同じ解像度で保存され、画質は変更されません」
- 保存容量の節約画質＝「サイズが 16 MP を超える写真は、16 MP に縮小されます」「動画の解像度が 1080p を上回る場合は、1080p（高画質）にサイズ変更されます」
出典：Google フォト ヘルプ「バックアップの画質を選択する」（2026年8月27日に当サイトが確認）
つまり節約画質で預けた写真は、Googleの側に縮小後のファイルしか無い可能性があります。手元のスマホやカメラに原本が残っているなら、そちらから直接NASへコピーしてください。
原本がもう残っていない場合、Takeoutで受け取れるのは縮小後のファイルだけになります。縮小されたものを移しても、画質が元に戻ることはありません。それでも「Googleの中にしか無い」状態からは抜けられるので、移す価値はあります。今後撮るぶんだけでも「元の画質」に切り替えておくと、同じことを繰り返さずに済みます。
2. その期間の写真が、すでにNASに無いか確認する
当サイトがつまずいた点です。Synology PhotosのスマホアプリでNASへ自動バックアップしている人は、同じ写真がスマホ経由で既にNASへ入っていることがあります。そこへTakeoutの分を追加したところ、同じ写真が2枚ずつ並びました。Synology Photosは、内容が同じ写真を自動で1枚にまとめてはくれません。
対策は、取り込む前にその年月のタイムラインを見ておくことです。二重になっても、File Stationで取り込んだフォルダごと削除すれば表示は元に戻ります（当サイトで確認済み）。取り込み先を専用フォルダにしておくと、やり直しが楽です。
手順1：Google Takeoutで書き出す
takeout.google.com を開き、「選択をすべて解除」してから Googleフォトだけにチェックを入れます。ここで注意したい設定が2つあります。
- アルバム単位で絞れる：「すべての写真アルバム」ボタンから、対象のアルバムだけを選べます。当サイトはアルバム1件（合計113.2MB）だけを選んで書き出しました。展開すると41ファイルあり、内訳は写真が約20点と、写真1枚ごとに付いてくる情報ファイル、アルバム全体の情報ファイル1件です
- エクスポート形式：写真は「元の形式／PNG／JPG／WEBP」、動画は「元の形式／MP4」から選べます。写真に付いている情報（撮影日など）は、写真とは別のJSONというファイルで出てきます（中身は手順2で見ます）。写真は「元の形式」のままが無難です
いきなり全期間を申請せず、まずアルバム1件で通して練習するのがおすすめです。所要時間についてGoogle公式は「この処理に数分から数日かかります」と幅を持たせていますが、当サイトの実測では113.2MBのアルバム1件を13時44分に申請し、完了メールが同じ13時44分に届きました。数百GB規模なら数日かかる前提で、小さく試すぶんには数分で返ってきます。
受け取り側の制限も先に押さえておきます。いずれもGoogle公式の記述です。
| 項目 | 公式の記述 |
|---|---|
| ファイル形式 | 「.zip」と「.tgz」から選択（zipはほとんどのパソコンで開ける） |
| 分割サイズ | 「作成するアーカイブの最大サイズを選択します」（上限50GB） |
| 有効期限 | 「アーカイブは 7 日程度で期限切れになります」 |
| ダウンロード回数 | 「各アーカイブのダウンロードは 5 回までに制限されています」 |
出典：Google アカウント ヘルプ「Google からデータをダウンロードする」（2026年8月27日に当サイトが確認）
当サイトの完了メールにも、期限として申請の7日後の日付が表示されました。申請したら1週間以内に受け取る、これだけは忘れないでください。
手順2：更新日時は展開日に変わる。判定は「撮影日時」で行う
ダウンロードしたzipを展開すると、Takeout/Googleフォト/アルバム名/ の中に写真が並びます。当サイトの中身は、デジカメのJPG（1枚あたり約3.5〜8.7MB＝エクスプローラー表示。元解像度と整合する大きさ）と、次のファイルが1枚ごとにペアで入っていました。
DSC_0307.JPG（写真の本体）DSC_0307.JPG.supplemental-metadata.json（1KBほどのテキストファイル）
この2つ目がサイドカーJSONです。Google公式は「Google フォトのコメントなど、元のファイルにない追加のメタデータは、セカンダリ JSON ファイルにダウンロードされます」と説明しています。撮影日時のうち写真の中に書き込めなかったぶんが、こちらに出てきます。
出典：Google フォト ヘルプ「Google フォトからデータをダウンロードする」（2026年8月27日に当サイトが確認）
そして、展開した瞬間にファイルの更新日時は全滅します。当サイトでは、エクスプローラーの「更新日時」列が全ファイル「2026/08/27 13:50」＝zipを展開した時刻になりました。ここだけ見て「日付が消えた」と判断しないでください。
supplemental-metadata.json がペアで並び、「更新日時」列は全ファイルが展開時刻になっています（2026年8月27日・当サイト運営者が撮影）。見るべきなのは更新日時ではなく、写真1枚のプロパティ→詳細タブにある「撮影日時」です。ここが入っていれば、そのままNASへ入れて問題ありません。
| 手元のファイル | プロパティの撮影日時 | そのままNASへ入れてよいか |
|---|---|---|
| デジカメ・スマホで撮った未編集のJPG | 入っている | 入れてよい（当サイトでは正しい年月に並んだ） |
| スクリーンショット（PNG） | 空 | 復元ツールを通してから入れる |
| SNS保存・スキャン画像など | 空のことがある（当サイトでは未検証） | 撮影日時が空なら復元ツールへ |
| 動画（MP4/MOV） | — | 当サイトでは未検証 |
枚数が多い場合、1枚ずつ確認する必要はありません。この判定は「そのままNASへ入れて済むか」を知るための下見です。数百枚を超えるなら、全部まとめて手順5の復元ツールに通してしまうほうが早く終わります。ツールは写真1枚ごとにサイドカーJSONの撮影日時を読んで日付を決める作りで、当サイトの実行ログでも、処理した4ファイルすべてが「json」（＝JSONの日付を採用）と表示されました。ただし当サイトがツールに通したのはスクリーンショット4点だけで、EXIFが入った写真をまとめて通したときの挙動は確認できていません。不安なら、コピーを作って数枚だけ先に通し、結果を見てから残りを流してください。
zipが複数に分かれた場合も、展開の作業は要りません。復元ツールの起動画面には「複数のzipをそのまま扱える（Handles multiple ZIP files seamlessly）」と書かれており、ファイル選択の画面で Ctrlキーを押しながらzipを全部選ぶよう案内が出ます（当サイトはzip1個で試したため、複数選択時の動作は未検証です）。
手順3：そのままNASに入れたらどうなったか
判定でOKだったフォルダは、そのままNASへコピーします。Synology公式も「DSM の File Station または他のファイル共有プロトコルを介して」 "/home/Photos" または "/photo" フォルダへ直接アップロードする方法を案内しています。
この2つは置き場所の性格が違います。/home/Photos は自分だけが見る個人スペース、/photo は家族全員で共有するスペースです。家族の思い出をまとめたいなら /photo、自分用に整理するなら /home/Photos を選びます（どちらが使えるかはDSMの設定で変わるので、File Stationで実際に存在するほうを使ってください）。
枚数が多いときは、パソコンからSMBでコピーするほうが速く済みます。SMBは、パソコンのエクスプローラーからネットワーク越しにNASのフォルダを開いて、ドラッグ&ドロップでファイルを置ける仕組みのことです。
出典：Synology ナレッジセンター「Synology Photos で写真を管理する」（2026年8月27日に当サイトが確認）
結果は冒頭に書いたとおりです。更新日時が2026年8月27日に化けていた写真が、Synology Photosのタイムラインでは2018年11月25日・28日の正しい位置に並びました。
Synology公式KBは「Synology Photosは写真とビデオのメタデータを使用して日付を決定します」とし、情報が足りないときだけ「アップロード時間または最終変更時間がリストされます」と説明しています。順番を決めているのはファイルの日付ではなく、写真の中身のほうです。
出典：Synology ナレッジセンター「Synology Photos に表示される写真の日付が正しくない場合」（2026年8月27日に当サイトが確認）
ここまでは「NASが手元にある人」の話です。この並び順を作っているのはSynology Photosで、Synology製NASのDSMに標準で入っているアプリです。当サイトが今回使ったのは2ベイの入門機DS223jで、この価格帯の機種でも同じ結果になりました。機種選びから始める場合は家庭用NASのおすすめランキングに、2ベイ〜4ベイの比較をまとめています。
すでにNASがある場合、取り込み先の容量を決めるのは、写真より動画です。4K動画も残す家庭は最初から大きめを選ぶほうが後が楽で、容量の考え方とHDDの選び方はNAS用HDDのおすすめにまとめています。
手順4：壊れるのはスクリーンショットのようなファイル
次に「壊れる系」を試しました。書き出したのはスクリーンショットだけを集めたアルバムです。中身は Screenshot_*.png などのPNGが4枚と、1枚ごとのサイドカーJSON、そしてアルバム全体の メタデータ.json でした。
- PNGはプロパティの撮影日時が空。スクリーンショットとして保存される時点で、撮影日時が写真の中に書き込まれていないためです
- 更新日時はzip展開時刻
PNGにも撮影日時などのEXIFを入れる規格（eXIf チャンク）は用意されています。ただし当サイトが見たスクリーンショットには書かれておらず、Windowsのプロパティでも空欄でした。「PNGだから絶対に持てない」ではなく、「スクリーンショットには通常書かれていない」というのが実測の範囲です。
参考：W3C「Portable Network Graphics (PNG) Specification (Third Edition)」11.3.4.5 eXIf（2026年8月28日に当サイトが確認）
この状態でNASへ入れると、本来2020年1月3日に撮ったスクリーンショットが、Synology Photosのタイムラインで作業当日の2026年8月27日として表示されました。メタデータが無いときに最終変更時間を見るためで、故障ではありません。撮影日そのものはサイドカーJSONに残っているので、次の手順で書き戻せます。
手順5：無料ツールで撮影日を書き戻す
サイドカーJSONの日付を、写真そのものへ書き戻すのが復元ツールの役割です。ここで、検索結果とツールの現状にずれがあります。
- 検索でよく出てくる本家 TheLastGimbus/GooglePhotosTakeoutHelper は、最新リリースが v3.4.3＝2023年9月24日で、その後の更新が止まっています（未クローズのissue・プルリクエストが87件＝2026年8月27日時点）
- 実際に更新が続いているのは、フォークの Xentraxx/GooglePhotosTakeoutHelper_Neo。当サイトが使った v6.2.1 は2026年8月26日リリース（協定世界時。日本時間では8月27日の未明）です
出典：GooglePhotosTakeoutHelper（本家） ／ GooglePhotosTakeoutHelper_Neo リリース一覧（いずれも2026年8月27日に当サイトが確認）
サイドカーJSONの名前は途中で .supplemental-metadata.json 形式へ変わっており、古い解説どおりの手順が当たらない場面があります。リリース日が新しいものを選ぶのが安全です。
windows-x64.exe を使います。v6.2.1が公開されたのは、当サイトが最初に試した2026年8月27日午後の約10時間前（同日未明）でした（2026年8月27日・当サイト運営者が撮影）。実行前に必ず読んでください
- 🔴 ファイルは「コピー」ではなく「移動」されます（開発元のREADMEに "Files are moved, not copied"＝ファイルはコピーではなく移動される、"keep the original ZIPs as backup!"＝元のzipはバックアップとして残しておくこと、と記載）。この記事の手順ではzipを展開しないままツールに渡し、ツールが空フォルダへ展開したうえで、その展開後のファイルを移動します（zipはそのまま手元に残る設計です）。すでに自分で展開したフォルダのほうを入力に指定する場合は、そのフォルダのコピーに対して実行してください（入力にしたフォルダは、ファイルが移動されて中身が変わります）。どちらの進め方でも、zipは別の場所にもう1つ残しておくのが安全です
- 🔴
--ignore-albumsオプションは、アルバムにしか無い写真を恒久的に削除します。意味が分かるまで付けない - 個人が開発・公開しているツール（Apache-2.0・無保証）です。元データを残したまま試すのが大前提です
- 開発元は「JPEG以外の形式へEXIFを書き込むには ExifTool が必要」（原文 "EXIF writing for non-JPEG formats requires ExifTool"）としています。ただし当サイトが試したスクリーンショット（PNG）では、ExifToolを認識させた実行でも書き込みは0ファイルで、ファイルの日時が直るだけで日付の復元は成立しました（後述）。JPEGなど他の形式で書き込みが働くかは未検証です
- 手順の実行は自己責任でお願いします。作業前に、消えて困るデータのバックアップが別途あることを確認してください
出典：GooglePhotosTakeoutHelper_Neo README（2026年8月27日に当サイトが確認）
用意するのは、zipとツール本体とExifTool
作業用のフォルダを1つ作り、次のものを置きます。
- Takeoutでダウンロードしたzip（展開しないまま置きます）
gpth_neo-6.2.1-release-windows-x64.exe（前掲のリリースページから）exiftool.exe（ExifTool公式サイトからダウンロード）exiftool_filesフォルダ（3と同じzipに入っているExifToolの本体）
exiftool.exe と exiftool_files フォルダごと置いた正しい構成です（2026年8月28日・当サイト運営者が撮影）。ExifToolはWindows向けにzipで配布されており、中身はランチャーの実行ファイル（exiftool(-k).exe）と、本体の exiftool_files フォルダ、README の3点です。実行ファイルを exiftool.exe にリネームして使うのが一般的な導入方法ですが、zipの中のexeだけをコピーすると認識されません。exiftool_files フォルダごと作業フォルダに入れてください。当サイトは最初にexe（リネーム後57KB）だけを置いて認識されず、フォルダごと入れ直したところ認識されました（両方の実測は後述）。
起動すると、英語の質問が12問ほど続く
exeをダブルクリックすると、黒い画面（コマンドプロンプト）が開いて英語の対話が始まります。数えたところ質問は約12問。当サイトは全部そのままEnterを押す（デフォルトのまま）だけで最後まで通り、成功しました。
質問されるのは、元のフォルダをそのまま使うか／重複ファイルを消すか／写真を年月フォルダに分けるか／拡張子の不一致を直すか／EXIFへ書き込むか／アルバムをどう扱うか、といった項目です。当サイトが通ったデフォルトは「zipを自動で展開」「元の入力フォルダで直接作業」「重複は削除」「1つのフォルダにまとめる」「拡張子は標準的な修正」「EXIFへの書き込みは有効（既定はYes）」「アルバムはショートカット方式」「作成日時は同期しない」でした。
なお、個人開発のexeでは、環境によってWindowsの警告（SmartScreen）が表示されることがあります（当サイトの実行では表示されませんでした）。表示された場合は、ダウンロード元が公式のリリースページかどうかを確認してから判断してください。
フォルダの指定は2回。ここはWindowsの画面が開く
黒い画面だけで完結するわけではありません。①zipを選ぶ ②展開先のフォルダを選ぶ の2回、見慣れたWindowsのダイアログが開きます。ここでマウスで選ぶだけなので、パスを手入力する場面はありませんでした。
つまずいた点：展開先は「空のフォルダ」でないと進めない
当サイトが1回止まったのがここです。展開先に中身のあるフォルダを選ぶと拒否されます。画面には「展開先のフォルダは空でなければならない」「関係ないファイルの誤削除を防ぐため、空でないフォルダは使わない」という趣旨の警告が出ます。嫌がらせではなく、データを守るための設計です。
解決は簡単で、ダイアログ左下の「新しいフォルダーの作成」で空のフォルダを1つ作り、それを指定するだけでした。
ExifToolが無くても・あっても、スクリーンショットの復元結果は同じだった
先に結論を書くと、どちらでも結果は同じでした。
当サイトは復元を3回通しています。最初の復元は2026年8月27日で、この結果が後掲の「正しい日付に戻ったタイムライン」の図です（このときExifToolはexeだけを置いた状態で、画面は記録していません）。翌8月28日に、手順の画面を1コマずつ残すため同じzipでもう一度通し（8月28日の1回目）、続けて exiftool_files フォルダごと置いて再実行しました（8月28日の2回目）。この節を含め、手順5に載せている実行画面はすべて8月28日のものです。3回とも対象はスクリーンショット（PNG）で、結果は同じ＝ファイルの日時が直るだけでした。
8月28日の1回目（exeだけを置いた状態）。同じフォルダに exiftool.exe を置いていたにもかかわらず、「Exiftool not found! Continuing without EXIF support...」（ExifToolが見つかりません。EXIF対応なしで続行します）と表示されたまま処理が進みました。原因は、前掲のとおりzipの中のランチャーexeだけをコピーし、本体の exiftool_files フォルダを入れていなかったことです。
それでも終了時の統計は、「Wrote EXIF data to 0 files」（EXIFを書き込んだファイル数＝0）、「DateTime extraction method — json: 4 files」（日付の取得元はすべてJSON）。写真の中身には書き込まれないまま、JSONから読んだ撮影日をファイルの日時へ反映しただけで、この記事の目的（タイムラインが正しい年月に並ぶ）は達成されました。
8月28日の2回目（exiftool_files フォルダごと置いて再実行）。構成だけを直してもう一度通すと、今度は「Exiftool found! Continuing with EXIF support...」（ExifToolを検出しました。EXIF対応ありで続行します）に変わり、認識に成功しました。回答は1回目と同じく全部Enterです。
exiftool_files フォルダごと置いたところ「Exiftool found!」に変わりました（2026年8月28日・当サイト運営者が撮影。ログの保存先パスはマスク処理）。ところが認識に成功しても、復元の結果は1回目と変わりませんでした。完了時の統計は再び「Wrote EXIF data to 0 files」「json: 4 files」で、EXIF書き込みの対象は全カテゴリ0件。つまり当サイトが試したスクリーンショット（PNG）4枚のケースでは、ExifToolがあってもなくても、ファイルの日時を直すだけで復元が完了します（8月28日の2回とも統計が一致＝再現性も確認できました）。
なお、EXIFへの書き込みを無効にして通したわけではありません。回答は既定のまま（EXIFへの書き込みは有効）で、完了画面のログにも書き込みの工程「Write EXIF Data completed」が写っています。工程は動いたうえで、対象が0件だったということです。同じログには「Skipping creation time update」（作成日時は更新しない設定）も出ており、触られたのは更新日時のほうだけでした。
言い換えると、この記事の手順を目的どおりに通すだけなら、ExifToolでつまずいても先へ進んで構いません。一方で、開発元が説明している「JPEG以外の形式へのEXIF書き込み」が実際に働くケースは、対象がPNGだけだったため当サイトでは確認できていません。その処理をあてにする場合、この記事の実測は根拠になりません。
処理は一瞬で終わり、最後に統計が出る
処理は8ステップに分かれて進み、当サイトの規模（写真4枚＋サイドカーJSON）では所要時間の表示が 0h 00m 00s でした（8月28日の1回目。2回目は 0h 00m 01s で、統計の数字は同じです）。最後に「DONE! FREEEEEDOOOOM!!!」と出て [SUCCESS] で終わります。実行ログはファイルにも自動保存されます。
そして、その少し上に出る「Your Processed Takeout can be found on:」の行が、処理後のファイルが入っているフォルダの場所です（下の図ではパスをマスクしています）。NASへ運ぶのは、この行が示すフォルダの中身です。当サイトの1回目は既定のまま通したため、zipを置いた作業フォルダがそのまま整理後の状態になっていました（2回目は出力先を分けて指定したので、別のフォルダが表示されています）。
枚数が数千〜数万になったときの所要時間は、当サイトでは確認できていません。ただし本番規模で時間が乗るのはツールの処理ではなく、①Takeoutの書き出し待ち（公式は「数分から数日」）②zipのダウンロード ③NASへのコピーの3つです。いずれも回線と容量で決まる待ち時間で、パソコンの前に張り付いている必要はありません。まずは小さなアルバムで1回通し、動きを見てから本番のぶんを流すのが安全です。
結果：処理後のフォルダをNASへ入れ直すと、正しい日付に戻った
処理が終わったフォルダをNASへ入れ直します。当サイトでは、この手順で2020年1月3日のスクリーンショットがタイムラインの正しい位置へ戻りました。2019年12月28日〜2020年1月4日の年末年始の写真群も、正しい日付に並び直っています。
ツールを通してもEXIFが空のままなのは、失敗ではない
処理後にPNGのプロパティを見ても、撮影日時の欄は空のままで、変わったのは更新日時のほうでした。前述のとおり当サイトの8月28日の2回の実行ではEXIFへの書き込みが1ファイルも行われておらず、ファイルの日時をJSONの撮影日時に合わせる処理だけが走っています。Synology Photosは「メタデータ→無ければ最終変更時間」の順で判断するため、これで正しい位置に並びます。
ただしファイルの日時に頼っている状態なので、別の場所へコピーし直すと、また日付が動く可能性があります。開発元の説明では、JPEG以外の形式にEXIFを書き込むにはExifToolが要るとされています。写真そのものに撮影日が書き込まれれば、コピーしても日付は動きません。当サイトの対象はスクリーンショットだけで、ExifToolを認識させた実行でも書き込みは0件だったため、どこまで堅牢になるかは確認できていません。
この手順だけは、人を選びます
ここまで読んで気が重くなったなら、その感覚は正しいです。画面は英語のコマンドプロンプトで、質問が10問以上続きます。日本語のインストーラーやボタン操作を想像していた人には、ここがいちばんの壁というのが、当サイトが実際に触った感想です。
一方で、事前に分かっていれば詰まらない種類の壁でもあります。「質問は全部Enterでよい」「フォルダ選びはWindowsのいつもの画面が開く」「展開先は空のフォルダを新規作成する」——この3つを知った状態で始めれば、実際の作業時間は数分でした。手順2の判定で「撮影日時が入っている」写真しか無かった人は、そもそもこの手順自体が不要です。
それでもこの画面は触りたくない、という場合の逃げ道もあります。撮影日時が入っていない写真をそのままNASへ入れても、写真そのものが消えるわけではありません。当サイトのスクリーンショットも、中身は無事なまま「取り込んだ日」の位置に並んだだけでした（手順4）。撮影日時が入っている写真だけを先に運んでしまえば、大半の思い出は正しい年月に収まります。日付がずれたぶんは後からこの手順を通し直せるので、ツールを避けたまま移行を始めても、取り返しはつきます。
移行後の運用：これから撮る写真はアプリで直接NASへ
Takeoutで運ぶのは過去の写真だけにして、これから撮る写真はスマホアプリからNASへ直接バックアップするのが手数の少ない形です。当サイトはSynology PhotosのAndroidアプリを入れ、GoogleフォトとNASの両方へバックアップされる状態で走らせています。この併用なら、Googleフォト側を残したままNASだけで生活できるかを試せますし、家族の端末を1台ずつ移していけます。
アプリ側の設定手順はスマホの写真・動画をNASに自動バックアップする完全ガイドにまとめています。クラウドとNASのどちらを主役にするか迷っている段階なら、先にNASとクラウドの比較を読んでから戻ってきてください。
費用の考え方
Google Oneは使い続けるかぎり毎月かかり、NASは最初にまとまった額がかかって、以降は電気代とHDDの交換費用という形の違いがあります。何年で追い越すかは選ぶ機種と容量で変わるので、いま払っている月額と、狙っているNAS本体＋HDDの合計額を並べて割り算してみるのが早いです。写真の枚数から必要な容量を見積もる手順とHDDの価格帯はNAS用HDDのおすすめに、機種ごとの価格帯は家庭用NASのおすすめランキングにまとめています。
解約したら写真はどうなる？容量がいっぱいのままだとどうなる？
解約してすぐ写真が消えるわけではない一方、容量を超えたまま2年放置するのは危険です。どちらもGoogle公式に書かれています。
- 急がなくてよい：Google Oneを解約しても「Google フォト、ドライブ、Gmail に保存されているすべてのデータは 2 年間以上保持されます」。削除の対象になる場合も「3か月以上前にご連絡します」
- 放置は危険：「割り当て量を超過した状態が2年以上継続している場合」「すべてのコンテンツが削除されることがあります」。超過中は写真のバックアップもGmailの送受信も止まります
出典：Google One ヘルプ「Google One メンバーシップを解約する」 ／ Google アカウント ヘルプ「保存容量ポリシー」 ／ Google フォト ヘルプ「保存容量について」（いずれも2026年8月27日に当サイトが確認）
移行前に「デバイスの空き容量を増やす」を押さない
これはバックアップ済みの写真をスマホ本体から削除する機能で、公式も「写真を削除する前に、必ずバックアップを取ってください」と注意しています。先に押すと手元の原本が減り、Google側のコピーが頼りになります。節約画質で預けていた場合、その頼り先は縮小後のファイルです。
出典：Google フォト ヘルプ「デバイスの空き容量を増やす」（2026年8月27日に当サイトが確認）
プラン料金は改定されることがあるため、金額はGoogle One の公式プランページでご確認ください。
この検証で確認できていないこと
当サイトの検証は、Synology DS223j・Windows PC・「元の画質」設定のアカウントという条件です。次の点は確認できていません。
- 動画（MP4・MOV）の日付の扱い。今回のサンプルは写真のみです。なおSynology公式は、動画の日付をアプリ上で手動修正しても「ビデオのメタデータには書き戻されません」としており、写真と同じようには扱えません
- 節約画質のアカウントで書き出したときに、どの解像度のファイルが返るか
- UGREEN（UGOS Pro）など他社NASが、タイムラインの日付をどこから読むか（一次情報を確認できていません）
まとめ
この記事の要点
- EXIF撮影日が残っている写真は、NASに入れるだけで年月順に並ぶ（当サイトはDS223j＋Synology Photosで2018年11月の位置に整列することを確認）
- 展開時に更新日時は全て展開日に変わるが、これは判定材料にならない。見るのはプロパティの「撮影日時」
- 壊れるのは撮影日時が中に書かれていないファイル（スクリーンショットのPNGなど）。当サイトでは作業日に化けたが、GPTH Neoで元の日付へ戻せた（ExifToolの認識に成功しても失敗しても、EXIF書き込みは0件のまま復元が成立した）
- 復元ツールはファイルを移動する仕様。zipは展開せずそのままツールに渡し、元のzipは必ず残す。実行画面は英語のコマンドプロンプトで、質問は全部Enterで通り、展開先は空フォルダを新規作成する
- Synology Photosアプリでスマホをバックアップ中の人は、入れる前に対象期間のタイムラインを確認する（二重表示は取り込みフォルダの削除で戻せる）
- 解約は最後でよい。ただし容量超過が2年続くと削除の可能性がある
まずはアルバム1件だけTakeoutして、手元のファイルの撮影日時を見るところから始めてください。そこが埋まっていれば、あとは運ぶだけです。
運ぶ先をこれから用意する場合、この記事の検証をすべて通したのは2ベイのDS223jです。写真の取り込みとタイムライン表示に関しては、入門機でもここまでできました。ほかの機種と比べてから決めたいときは、家庭用NASのおすすめランキングに2ベイ〜4ベイの比較をまとめています。