supplemental-metadata.json とは？Google Takeout で名前が切れる理由と (1) の付き方
2024 年に Google が Takeout のサイドカー名を変えた理由、名前が 46 文字で切れる仕組み、重複ファイルの (1) がどこに付くのか、編集済みコピーの扱い、そして古いスクリプトが写真を飛ばす原因を説明します。対処法も併せて紹介します。
前は問題なく Takeout を直せたスクリプトを走らせたら、今回は写真の半分が飛ばされた。あるいはフォルダーを見ると、ある写真の横には IMG_5512.HEIC.supplemental-metadata.json があり、別の写真の横には PXL_20240311_183022711.jpg.supplemental-m.json がある。後者は壊れているのだろうか。
どちらも壊れていません。Google がサイドカーの命名を変えただけで、2024 年より前に書かれたガイドの多くはそれを知りません。
2024 年の名前変更
長い間、IMG_5512.HEIC のサイドカーは IMG_5512.HEIC.json でした。写真名の後ろに .json。単純で、どのスクリプトもこれで照合していました。
2024 年のある時点で、Google は IMG_5512.HEIC.supplemental-metadata.json に切り替えました。中身も項目も同じで、名前だけ長くなりました。裸の .json だと写真自体のデータのように見えるので、supplemental-metadata でファイルの正体を示そうとしたのでしょう。それ以降のエクスポートは新しい名前です。どこかのドライブに古いエクスポートがあれば古い名前で、混ぜたフォルダーには両方が入ります。
<写真名>.json を探すものは、今では何も見つけられずに先へ進みます。すべてのファイルに「サイドカーが見つかりません」と報告するツールもあれば、黙ってファイル日時、つまりダウンロード日に落ちるツールもあります。後者ではエラーが出ないまま写真の日付が狂います。「直したのに直らない」という投稿の多くはこの静かな失敗が原因です。
46 文字での切り詰め
2 つ目の変化は前からあったものですが、名前変更で影響が大きくなりました。Google はサイドカーのファイル名全体を 46 文字で切り詰めます。以前の短い接尾辞ではほとんど問題になりませんでした。.supplemental-metadata.json が付くと、写真名が 19 文字を超えたあたりから接尾辞が欠け始めます。
Pixel の PXL_20240311_183022711.jpg は 26 文字です。.supplemental-metadata.json を足すと 53 文字。Google はこれを 46 文字に切って PXL_20240311_183022711.jpg.supplemental-m.json にします。Samsung の 20240311_183022.jpg は 20240311_183022.jpg.supplemental-metada.json になります。メーカーごとに切れ方が違うので、単一の接尾辞で照合することはできません。
確実なルールはこうです。サイドカー名は <写真名>.supplemental-metadata.json の前方部分（プレフィックス）である。スクリプトは固定文字列との比較ではなく、これを確かめる必要があります。自分で付けた長いファイル名は写真名自体が切られることもあるので、JSON 内の title 項目も読む価値があります。
(1) はどこに付くのか
Google フォトは同じ名前のファイルを 2 つ持てますが、Takeout は 1 つのフォルダーに置かなければなりません。そこで 2 つ目に連番を足します。IMG_5512.HEIC と IMG_5512(1).HEIC です。
サイドカーは IMG_5512.HEIC.supplemental-metadata.json と IMG_5512(1).HEIC.supplemental-metadata.json になると思うでしょう。違います。連番はサイドカー名の末尾、.json の直前に移ります。IMG_5512.HEIC.supplemental-metadata(1).json です。古い形式では IMG_5512.HEIC(1).json でした。
つまりツールは、写真名から (1) を取り、サイドカー名を組み立て、.json の直前に (1) を戻さなければなりません。切り詰めと組み合わさると PXL_20240311_183022711.jpg.supplemental-(1).json のような名前になります。実際のエクスポートに含まれています。
連番付きの重複は思ったより多いです。同じ写真を 2 つのアルバムに保存した、編集して Google が両方を残した、2 台のスマートフォンがどちらも IMG_0001.JPG と名付けた。どれも重複を生みます。
編集済みコピー
Google フォト内で編集した写真は IMG_5512.HEIC と IMG_5512-edited.HEIC の 2 ファイルとして出てきます。サイドカーは普通 1 つで、元の名前に付いています。編集済みコピーには専用のサイドカーがないので、素朴なツールでは日付なしになります。慎重なツールは -edited を外して元のサイドカーを使い回します。
手作業で照合する
exiftool を使うなら、接尾辞ごとに 2 回実行します。
exiftool -r -d %s -tagsfromfile "%d/%F.supplemental-metadata.json" "-DateTimeOriginal<PhotoTakenTimeTimestamp" -ext jpg -ext heic -overwrite_original .
exiftool -r -d %s -tagsfromfile "%d/%F.json" "-DateTimeOriginal<PhotoTakenTimeTimestamp" -ext jpg -ext heic -overwrite_original .そのあと exiftool -r -if 'not $DateTimeOriginal' -filename . で、まだ日付がないものを一覧します。残るのが切り詰めと (1) の組です。いちばん簡単な対処は、短いスクリプトでそれらのサイドカーを本来の完全な名前にリネームしてから exiftool を再実行することです。無料のコミュニティ製ツール GooglePhotosTakeoutHelper にはこの照合が組み込まれており、ターミナルに抵抗がなければよく勧められます。ただしリリースが Google の変更に遅れることがあるので、ファイルが飛ばされたら issue トラッカーを確認してください。
アプリで
Takeout JSON Metadata Fixer は、これらのケースをすべて設定なしで処理します。Windows、Mac、Linux で動きます。
各写真について、2024 年の名前、古い名前、移動した (1)、最後にフォルダー内の .json のうち完全な名前のプレフィックスになっているものを順に試します。編集済みコピーは元のサイドカーを借ります。それから日付と GPS をファイルに書き込みます。何枚がサイドカーと一致し、何枚が EXIF やファイル日時に落ちたかを報告するので、何かを削除する前に照合がうまくいったか確認できます。ドライランは書き込まずに計画だけ表示します。最初の 1000 枚は無料です。
よくある質問
supplemental-metadata.json の中身は古い .json と違いますか？
いいえ。項目は同じです。title、photoTakenTime、creationTime、geoData、geoDataExif など。変わったのはファイル名だけです。
サイドカーがまったくない写真があります。なぜですか？
Live Photos の動画部分にはないことが多いです。ごく古いアップロードにもありません。それと、サイドカーが切り詰められていたり連番が移っていたりすると、ツールが「ない」と報告しているだけで実際にはある場合があります。フォルダーを自分で見てください。
サイドカーを古い形式の名前に戻せますか？
はい。古いスクリプトがまた動くようになります。.supplemental-metadata を外し、(1) を写真名の部分に戻すリネームで十分です。まずコピーで試してください。
Google はまた名前を変えますか？
あり得ます。ツールにとって安全なやり方は、正確な接尾辞ではなく、プレフィックスと title 項目で照合することです。