JavaScriptを活用した私の200GB iCloud整理作業
(andykong.org)- iCloudストレージが200GBの上限に近づき、写真だけで約 127GB を占めるようになったため、1TBへのアップグレードではなく、大きな動画を自分で探して削除する回避策を試した
- Apple PhotosとiCloud Webには ファイルサイズ順の並べ替え がなく、別アプリでもiCloudにオフロードされた写真が0Bのように表示され、整理の基準として使いにくかった
- iCloud Photos Webの動画再生時間バッジが
video-text-badgeというHTML要素である点を利用し、JavaScriptで長い動画を見つけて 赤い枠 で表示した - 30秒超の動画をダウンロードして削除したところ、ダウンロードしたファイルは約 7GB だったが、iCloudストレージは約 55GB 減るという予想外の差が出た
- 新しい4K動画ではファイルサイズとiCloudの表示変化がほぼ一致したが、古い動画は実際のファイルよりiCloud上で大きく計上され、古い大きな動画 が整理の優先対象になり得る
iCloud Webで長い動画を抽出する
- Appleのストレージ警告の後、200GBから1TBに上げると料金が3倍以上に跳ね上がるため、代替策を探し始めた
- ストレージの大半は写真で、約 127GB を占めていたが、Apple PhotosとiCloudブラウザには写真を ファイルサイズ順 に並べ替える機能がなかった
- 重複写真や動画ファイルサイズを表示するアプリも、iCloudにオフロードされた写真を0Bのように表示し、実際の整理にはあまり役立たなかった
- iCloud Webサイトの
Photos -> Media Types -> Videosに移動した後、画面をできるだけ縮小して多くの動画を一度に表示させた - 各動画の再生時間バッジがHTML要素ならJavaScriptで検索・フィルタリングできると考え、長い動画を強調表示するコードを書いた
- 再生時間バッジのクラスは
video-text-badge - ページ内のバッジを探して再生時間基準で並べ替え、特定のしきい値を超える項目を強調表示する
- iCloudは画面に読み込まれた要素だけを取得するため、新しくスクロールで入ってくる要素も処理できるよう、タイマーで繰り返し実行する
- 再生時間バッジのクラスは
- 使い方は、iCloudページでJavaScriptコンソールを開き、gist全体を貼り付ける方式
- 結果として20秒より長い動画が赤い枠で表示され、複数の大きな動画を選択してダウンロードした後、削除しやすくなった
削除後のストレージ変化と2回の実験
- スクリプトでiCloud動画のうち 30秒超 の項目をすべて削除したところ、ダウンロードした動画は約7GBだったが、iCloudストレージは約55GB減った
- ダウンロードした全動画はディスク上で8GBを占めた
- iCloud使用量は199GBから143GBに減った
- 1回目の実験では、動きの多い 4K動画 をアップロードしてiCloudストレージの反応を確認した
- アップロードしたファイルサイズは281MB
- アップロード後のiCloud使用量は145.33GB
- ダウンロードして削除した後も、ファイルは依然として281MB
- 削除後のiCloud使用量は145.6GBと表示され、表示値の差は約270MB程度だった
- 2回目の実験では、古い動画の中からiCloudが大きなファイルとして表示する短い動画を選んで確認した
- iCloudはその動画を128MBと表示した
- ダウンロードしたファイルは47MBだった
- 削除前のiCloud使用量は145.29GB、削除後は145.12GBで、約170MB減った
- 約7GBのファイル削除で7倍を超えるストレージが解放され、古い大きな動画は実際のファイルよりiCloud上で大きな ストレージ占有量 を持つようだった
- 原因は確認できていないが、結果として 50GB以上 のiCloudストレージを確保でき、同じ作業を再び行うための小さなJavaScriptスクリプトが残った
1件のコメント
Hacker Newsのコメント
Photos.appではファイルサイズが表示されないため、大きなファイルを見つけるPhotos.app拡張や別アプリを作ろうかと思った。
しかしAPIは「ファイルサイズ」を公開していないようで、少なくとも簡単な方法は見つからなかった。
「写真」や「動画」は、基盤となる「photo or video object」を表示するビューに近いと考えている。動画をトリミングしても元のフル動画は残っており、書き出しをして初めて、トリミング後の小さい実ファイルが作られるようだ。
そのため、ファイルサイズの見え方が違うのだと思う。さらに、誰かがファイルサイズを取得するAppleScriptを作ったとのこと: https://discussions.apple.com/docs/DOC-250000422
「ファイルサイズ」はどのAPIで探していたのか気になる。
PhotoKit APIでPhotos.appからサイズデータを取得できた: https://alexwlchan.net/2023/finding-big-photos/
約2.6万件ある自分のライブラリでしか試していないが、最大の項目を探す指標としては有用だった。ただし、1GBの動画を書き出したときにiCloud使用量が1GB減るかどうかは確認していない
そのため、ライブラリではサムネイル1枚に見える取り込み直後の写真が、実際には5MBかもしれないし50MBかもしれない
iPhoneのストレージをあれほど神経質に管理しても、いつも限界近くになる理由の説明にもなる
osxphotos query --min-size 100MB --add-to-album "Big Files"100MBより大きいすべての写真と動画を見つけて「Big files」アルバムに追加する。
詳しくは
osxphotos query --help、ブラウザでドキュメントを開くならosxphotos docsを参照。ちなみに自作ツールですバグかもしれないが、場合によってはiCloudが同じファイルの複数バージョンを密かに保存している可能性もある。Appleは他のメディアファイルでも似たことをしているので。
最後の例が興味深い:
「iCloudでは動画が128MBと表示されていたが、ダウンロードしてみると実際の動画は48MBで、削除したら空き容量が約170MB増えた」
これは、iCloudが単に例示ファイルのサイズを誤表示しているだけではないことを示唆している。128MBのファイルを削除したなら、iCloud容量も約128MBしか空かないはずだが、実際には表示サイズ128MBとダウンロード版48MBを足した176MBに近い容量が空いた。iCloudが空き容量を10MB単位で丸めて表示するなら、十分つじつまが合う
結局、ストレージをあるサービスにどんどん囲い込まれることになり、総保存量ベースで定期課金されるのに、そのストレージをどう最適化すべきかの情報はほとんどない。固定の料金帯にとどまりたい、あるいはストレージ/コスト比を下げたい消費者の立場では、ただ手をこまねいて払い続けるしかないのかと思ってしまう。
テック業界の現代的なビジネス戦略は、複雑さの陰に隠れることだ。コストは複雑すぎて理解しづらいし、内部情報を競合に見せすぎることになる、という理屈だ。しかし会社がコスト以上で運営されているかを確認するときには、そうした指標をどうにか算出している。消費者が理解しようとすると、突然「複雑すぎる」ことになる。
問題は、技術が実際に複雑すぎる規模まで大きくなっていることが多く、経営層もそれを分かっているので、かなり有効な言い訳になっている点だ。そして都合よく、まさにその部分に投資を集中してマージンを乗せる
トリミング後のファイルはiCloud表示サイズより小さかったが、未変更のオリジナルをダウンロードするよう選ぶと、サイズはiCloud表示と一致した
したがって、写真をiCloudに同期するときは個々のファイルだけが同期されるのではなく、Photosアプリが管理する「Photos Library」コンテナが同期される。
FinderやFilesアプリで個別ファイルを直接追加した場合は、iCloudとローカルファイルシステムでサイズが正確に一致する
ハードディスクやUSBメモリを買えば、一定のGBを好きなように使える。1GBのファイルを入れれば、空き容量は1GB減る。ファイルシステムによってはメタデータで数KB失うかもしれないが、どのファイルシステムを選ぶかはユーザー次第であり、保存装置に強制されるものではない。
NANDコントローラがブロックマッピングテーブル保存のためにオーバープロビジョニング領域を数MB使っていたり、利便性のためにデータを重複保存していたりしても、ユーザーがそのオーバープロビジョニング領域のコストを請求されることはない。
ここではHTTPでアクセスする保存装置を売っておきながら、1GBのファイルを書き込むと、自分たちの都合で複製・変換などを行い、ユーザーが頼んでもいないその複製物の保存コストまで請求している。これは新しく、予想外だ
このアイデア／解決策を TamperMonkey/Greasemonkey スクリプトにした
基準に合わないすべての要素を「非表示」にする機能も追加した
https://github.com/seffignoz/icloudcleanup
私が セルフホスティングをする理由の1つがこれ。クラウド提供者の明確さと透明性を信用していない。セルフホスティングのソリューションのほうがずっと不安定で安全性が低く、性能も劣っていたとしても、おそらく乗り換えないと思う
個人的には immich を使っている。iOS/Android アプリ、サーバーコンポーネント、同期／バックアップのオプションを備えた、かなり完成度の高いソリューションだ
https://immich.app/
Google はそうしている。https://one.google.com/storage と https://photos.google.com/quotamanagement を見ると、削除する項目をうまく見つけさせ、最終的には削除に疲れてより多くのストレージを買わせようとする作りになっている
iCloud は フル品質のオリジナルを保存し、スマホにはより低品質の最適化版をダウンロードする仕組みだと理解している
iPhone の設定で
Apple ID > iCloud > Photosに行くと、デフォルトで有効になっている「Optimise iPhone Storage」オプションがあるこのオプションの説明には、スマホの空き容量が不足すると、フル解像度の写真や動画は自動的により小さいデバイス向けバージョンに置き換えられ、フル解像度版はいつでも iCloud からダウンロードできるとある
これはかなり合理的に見える
これは Settings > Manage storage で見られるスマホのストレージ容量の話で、クラウドストレージ とは無関係だ
興味深い記事だ。私も似たような問題のせいで iCloud プランを上げる必要があったので、Apple にとっては修正の優先度が高くないのかもしれない
RAW+JPEG で撮影すると Apple Photos は2つの画像を1組にまとめる。写真愛好家にとって極端に珍しいやり方でもなく、ライブラリに重複に近い写真が大量にたまらず、RAW と JPEG を簡単に切り替えられるので便利だ
しかし、この結合方式と記事で説明されているファイルシステム設計のせいで、2つを簡単に分離して RAW だけを削除するのは不可能に見える。何年も経った今では絶対に触らない巨大な RAW ファイルが残っているのに、ずっと小さい JPEG は残したいので削除できない
オリジナルを書き出してライブラリから削除し、その後 JPEG だけを再インポートするのがいちばん簡単そうだが、そうするとライブラリに蓄積してきた長年分のメタデータを失う
だから結局プランを上げるしかない
顔認識のような追加機能のことなら、JPEG を再インポートしたあとにアプリが再処理しないのだろうか？
osxphotos export /path/to/export --has-raw --skip-raw --exiftoolRAW ペアを持つすべての画像を書き出しつつ RAW コンポーネントはスキップし、exiftool(https://exiftool.org/) を使ってキーワードのようなメタデータを書き出した JPEG ファイルに書き込む。その後 Photos にドラッグするか、
osxphotos import /path/to/export/*を実行して再インポートできるexport と import コマンドには、エクスポート先ディレクトリなどを制御するほかのオプションも多い。
osxphotos help export、またはブラウザでドキュメントを開くにはosxphotos docsを使うとよい。ちなみに私が osxphotos の作者だFile/Export Unmodified Originals を実行すると、RAW+HEIC とメタデータが入った別個のサイドカーファイルが書き出されるようだ。そのあと RAW ファイルだけを別に取り除いて HEIC ファイルをインポートすれば、サイドカーのメタデータファイルも自動的に取り込まれるという
ただし編集内容は失われる。それでも somehow「copy edits」はできるようだ。技術に詳しい人なら AppleScript でこの過程を自動化できるかもしれない
しかし、これは不必要に面倒で、Photos.app に内蔵されているべき機能だ。より高い iCloud 料金プランへ誘導する助けになるので、優先度が低いのは明らかに見える
驚いたことに、連休前にAppleから似たようなストレージ通知を受け取り、iCloudに置いておく代わりに、すべての写真・動画を自分のメディアサーバーへダウンロードすることにした。
iCloudからアーカイブをダウンロードする簡単で直感的な方法はない。複数のマシンやデバイスを使って、少しずつ進めている。
最近のAppleの変化の問題は、大した理由もなく価格を上げることだ。私たちはこれからも写真や動画を撮り続けるし、最新の技術や機能のせいでファイルサイズは大きくなり続けるしかない
Google Takeoutのように動作する。Mac、iPhone、iPad、PCで appleid.apple.com のApple IDアカウントページにログインし、「Data & Privacy」に進んで「Manage Your Data and Privacy」を選ぶ。
次のページで「Get a copy of your data」に進み、「Get started」を選べばよい
https://github.com/icloud-photos-downloader/icloud_photos_downloader
必要ならiCloudから写真をダウンロードしたり、形式変換したりもできる。数日ごとに新しい写真をNASへ送って常にローカルコピーを維持し、これらのコピーは毎晩Backblaze B2にもバックアップしている。
形式変換のおかげで、写真をHEIC+JPGのペアで保持でき、元データと使いやすい版を一緒に持てる。
本当に欲しいのは、iCloud Driveにも同じことをしてくれるツールだ。そこにいろいろな資料を入れているのだが、納得できる形でバックアップする方法がなくて気になっている。Appleの推奨方法(https://support.apple.com/en-us/HT204055)はかなり物足りない
一番嫌なのは、200GBから2TBへ飛ぶ不自然な料金プランの区切りだ。多くの家族にちょうどよい500GBや1TBを段階的に支払う方法がない。
ストレージがコモディティになった時代には、使ったGBごとに課金されるべきだ
私のiCloudストレージを大きく圧迫しているのは、写真の「live」動画版だ。ごく短い動きの断片が付いている写真より、ファイルサイズのほうが大きい。
今のところ見つけた対処法は、ファイルをローカルにダウンロードし、iCloudから削除し、ローカルの動画を消して、残った静止画像だけをアップロードし直すことだけだ。
時間がかかるうえに雑で、途中で何かを消したり大事なものを失ったりしないか不安になる。
実際に残しておきたい少数の「live」画像を見分けて保持できる程度の編集コントロールを提供しつつ、この処理を自動化してくれるツールがあるのか気になる
私の読み方で合っているのだろうか？
これが広く起きている現象なら、Appleがアップグレードを促すために数字を水増ししていると見なせて、訴訟につながる可能性もあるのではないか？
法律の専門家ではないが
写真や動画を追加すると、Photosアプリはそれらを解析し、編集履歴を含めてアプリが動作するために必要なさまざまなメタデータを保存する。最終的にそれがiCloudへ同期される
AppleがiCloudでまだ古いファイルシステム形式を使っている可能性もある。登場してからかなり経っているし、保存形式を変えることに気を配っていなかったのかもしれない。古いアカウントの画像・動画が「古い」ドライブにある可能性もある