SE歴20年の筆者が、この条件で市販アプリを検討して「足りない」と判断し、結局CLIツールを自作した。2026年8月時点で18,225件を索引化し、iPhone側を15GBほど空けたところまで来ている。

先に結論を書くと、手間の大半は「転送」ではなく「これはもう退避済みか？」の判定にあった。この記事はその判定をどう作ったかと、動かして初めて見えた数字の話をする。ツール自体は公開していないので、使えるのは考え方と落とし穴のほうだ。

なぜ市販アプリでは足りなかったのか

前提：手持ちの環境と、そこから消える選択肢

条件を並べる。

NASは築古2LDKのスマートホーム構成図に載せているものと同じで、もともと写真・動画のバックアップ用に置いていた。つまり保管先は最初からあって、足りていなかったのは「iPhoneから、重複させずに、安全に移す」部分だけだった。

3行目をわざわざ書いたのは、ここで選択肢がひとつ消えるからだ。MacとApple Developer Programが揃っていれば、iPhone上で完結するアプリを自分で書くという手がある。写真ライブラリにフルアクセスして、NASへ送って、端末から消すところまで1つのアプリでやれる。うちはどちらも無いので、この道は最初から検討対象にならない。作るならWindows側に置くしかない。

そして厄介なのが最後の「既存資産」だ。何年も前に手動でコピーしたもの、別のアプリで送ったものがNASに散らばっている。ここを無視して新しく全部コピーすると、同じ写真が二重三重に増えていく。

「iPhoneだけでNASへ」が成立しなかった理由

最初に試したかったのはPCを介さない方法だった。iOS 13以降、ファイルAppからSMBでNASに繋げるし、ショートカットAppで「写真を検索→ファイルを保存→写真を削除」まで自動化できる。開発者ライセンスもいらない。

これが成立しなかった理由は2つある。

ひとつは、ショートカットにはNAS上の既存ファイルのハッシュを取って照合する手段がないこと。できるのはせいぜい「バックアップ済みアルバムに入れたかどうか」程度で、それは「このアプリで移したものだけ」のタグ付けにすぎない。過去の資産とは突合できない。

もうひとつは、うちのLinkStationの世代だとSMB1しか話せない可能性があったこと。iOSのファイルAppはSMB2以上にしか繋がらないので、その場合は入口で詰む。Windows側なら「SMB 1.0/CIFSクライアント」を有効にすれば繋がる。

ただしこれは手放しで勧められる回避策ではない。MicrosoftはSMBv1の検出・有効化・無効化についての公式ドキュメントで、SMBv1を2014年に非推奨とし、Windows 10 バージョン1709以降は既定でインストールしないと明記している。有効にするならクライアント機能だけにとどめ、サーバー機能は有効にしない。NAS側がSMB2以上を話せるなら、当然そちらを使うべきだ。

4案を要件で潰した結果

検討した案と、落ちた理由。

MTPを選んだ副次的な利点として、MTP経由の削除はWindowsエクスプローラの削除と同じ経路なので、iOSの写真App側の管理情報が正しく更新される。DCIMを直接叩く方式だと写真Appに不整合が残ることがある。

実際に使い分けはこうなっている。既存資産6,114件の索引化と再配置という重い初期作業はUSB経路で片付け、日常の追加はiPhoneアプリからWi-Fiで流す。 初期作業のほうはNASを直接読める必要があるので、PC以外に選択肢がなかった。

一方、日常のほうはWi-Fiで済んでしまっている。USBを引っ張り出すのは「しばらく放置して溜まった、これは時間がかかりそうだ」となったときくらいだろう、というのが今の見込みだ。

実際に動かして分かった数字

18,225件の内訳

statusコマンドの出力がこれだ。索引の総数は18,225件で、内訳は既存資産の走査が6,114件、ツール経由で退避したものが12,111件。撮影日時が判定できなかったものが3件ある。

失敗は全経路で0件。ただしこれは「検証したから失敗しなかった」ではなく、「転送のたびに照合していて、一度も不一致で落ちなかった」という意味だ。後述するように書き込み後にNAS上の実体を読み直して照合しているので、壊れたコピーがあればここに数字が立つ。1万2千件でそれが起きていない、という読み方をしている。

5,122件が「重複」と判定された意味

数字として一番効いたのは2台目のiPhoneだ。

• 1台目：退避8,703件 / 重複（完全一致）51件
• 2台目：退避3,235件 / 重複（完全一致）5,122件

2台目は、繋いだ写真のうち5,122件が「もうNASにある」と判定された。何も考えずに全部コピーする方式だったら、この5,122件が丸ごと二重保存になっていた計算になる。既存資産を全走査してハッシュ索引を作る処理は重いが、入れておいてよかったと思ったのはこの数字を見たときだった。

Wi-Fi経由のモバイルアプリ側でも同じ判定が働く。画面のログで「スキップ(キャッシュ)」が並んでいるのが、送らずに済ませているファイルだ。

17年分が1つのDBに集まった

索引が育つと、年で絞れるようになる。2026年の4,778件から2010年の2件まで、17年分が1つのSQLiteに入っている。バラバラの場所にあった写真が「いつ撮ったか」で一列に並ぶのは、容量を空ける目的とは別の副産物だった。

位置情報を持つ写真は地図に落とせる。イベントで撮った写真が会場周辺にまとまるので、「あのとき撮ったやつ」を日付ではなく場所から辿れる。

削除を安全にするためにやっていること

コピー → ハッシュ再照合 → 削除

削除は取り返しがつかない。だから順番を固定している。

「コピーが終わった」ではなく「NAS上の実体を読み直して一致した」を条件にしているのが要点だ。書き込み途中で切れても検知できないまま削除に進むのが一番怖い。

削除可能なのに、まだ消していない

statusの出力に「端末から削除可能」という行がある。1台目8,754件、2台目8,357件。合計1万7千件が「検証を通ったので消してよい」状態として数えられている。

ただし実際に空けたのは15GBぶんで、やり方はビューアでサイズの大きい順に並べて、上から選んで消しただけだ。長めの子供の動画は手元に残しているし、写真は枚数が多いのでほとんど棚卸しできていない。「消してよい」と判定された数と、実際に消した数はまったく違う。

このへんは自動化の限界だと思っている。ツール側も、モバイルアプリからのアップロードではsafe_to_delete_on_deviceを常にfalseで返し、端末からの自動削除はしない設計にした。削除はビューアで写真を見ながら選ぶ経路だけに絞っている。

退避してもiPhone側が手狭なままなら、次は本体容量そのものを上げるかどうかの判断になる。写真が6割を占める256GBをどう扱うかは256GBのまま次の1年を過ごす判断で、512GBとの差額35,000円と合わせて整理した。

先に知っておきたかった落とし穴

「元のフォーマットのまま」にしないとハッシュが安定しない

これが一番ハマりどころだった。iPhoneの 設定 > 写真 > MacまたはPCに転送 を 「元のフォーマットのまま」 にしておく必要がある。

AppleもHEIF/HEVCメディアの取り扱いについての公式ページで、iPhoneから写真をPCへ読み込むとJPEGやH.264に変換される場合があり、変換したくなければ設定で「元のフォーマットのまま」を選ぶよう案内している。

変換されると何が困るか。変換結果はバイト単位で毎回同じとは限らないので、ハッシュが変わって重複判定が機能しなくなる。同じ写真を何度も「新規」として取り込んでしまう。ハッシュで重複を潰す設計とは相性が最悪だった。

iCloudの「ストレージを最適化」だとオリジナルが取れない

iCloud写真で「iPhoneのストレージを最適化」にしていると、端末上にあるのは軽量版で、フル解像度のオリジナルはiCloud側にある（iCloud写真の設定について）。この状態の写真はMTPから取得できないので退避対象にならない。「オリジナルをダウンロード」にしておくか、iCloud写真自体を使わない運用にするかを先に決めておく必要がある。

ここは目的と相性が悪い点でもある。iCloudの最適化は「端末の容量を空ける」機能なので、やりたいことは同じだ。ただし写真の置き場所がAppleのサーバーになる。NASに置きたい理由が「自分の管理下に置きたい」なら、最適化はオフにしてローカルにオリジナルを持たせる必要がある。

索引DBをNAS上に置くのは、本当は推奨されない

索引はSQLiteで、家族で共用するためNAS上に置いている。これはSQLiteの公式見解に反する構成だと分かったうえでやっている。

SQLite公式のネットワークファイルシステム上での利用に関するページは、書き込み時の排他ロックがネットワークFSでは正しく動かない例が知られており、それがDB破損につながった実績があると明記している。「Rely upon it at your (and your customers’) peril（信頼するなら自己責任で）」という強い書き方だ。ネットワーク越しに共有したいならPostgreSQL等のクライアント/サーバー型を使えというのが本来の答えになる。

それでもSQLiteのままにしているのは、自分と家族しか使わない小規模用途で、同時書き込みを起こさない運用にできると判断したからだ。具体的にはロックファイルで排他し、同時に走らせない。実際、定期実行のタスクとぶつかって「他のプロセスが処理中です」で止まったことが何度かある。止まるのは正しい動作だが、そもそも複数人が同時に使う前提なら、この構成は選ぶべきではない。

なお、ここで相手にしているNASは壁美人とワイヤーネットで壁掛けにしたものだ。設置の手順はそちらにまとめてある。

よくある質問

まとめ

3点にまとめる。

1. 手間は転送ではなく判定にある。 「これはもう退避済みか」を既存資産まで含めて判定できるかどうかで、方式の選択肢がほぼ決まった。iPhone単体で完結する方法はここで落ちた
2. 数字が設計の答え合わせになった。 2台目のiPhoneで5,122件が重複と判定された。この機能が無ければ丸ごと二重保存だった
3. 削除は検証の後。 NASに書いた実体を読み直して一致を確認してから消す。それでも自動では消さず、見ながら選ぶ運用にしている

写真ではなく録画データを手元に置き続ける話はレコーダー撤退と録画データの逃がし方に書いた。データを自分の管理下に置くという意味では同じ問題を扱っている。