SSD Nodes Learn Hosting plans →
ガイド Matt Connor著者 Matt Connor

Immichで写真の日付・時刻がずれる原因と直し方:EXIFとタイムゾーン

Immichで写真がコピーした日に並ぶ。カメラの写真だけ同じ日の中で9時間ずれる。Immich v3.2.4 のソースで確かめた原因ごとに、確認コマンドと、Immichとexiftoolでの直し方を説明します。

Immichで写真の日付がずれるのはなぜか

Immichで写真の日付や時刻がずれる原因は、大きく2つです。1つ目は、写真に撮影日時のEXIF(Exchangeable Image File Format、写真に埋め込まれる撮影情報)がないことです。この場合、Immichはファイルの日付を代わりに使います。2つ目は、撮影日時はあってもタイムゾーンのオフセット(UTCとの時差。日本なら +09:00)がないことです。この場合、Immichはその時刻をUTCとして読みます。

1つ目では、写真がコピーした日やダウンロードした日に並びます。2つ目では、日付は正しいのに、同じ日の中の並び順が9時間ずれます。原因ごとに、確かめるコマンドと直し方が違います。

ここでの説明は、2026年10月時点の最新リリースである Immich v3.2.4 のソースコードと照らし合わせて書いています。日時の扱いはリリースごとに変わってきたので、古い記事の手順がそのまま当てはまらないことがあります。Immichをまだ立てていない場合は、先にGoogle フォトの代わりに Immich を VPS で動かす手順を見てください。

まず確認:写真のどのタグに日時が入っているか

推測で直す前に、ファイルが実際に持っている日時を見ます。道具は exiftool です。Ubuntu では libimage-exiftool-perl というパッケージ名で入ります。

sudo apt update && sudo apt install -y libimage-exiftool-perl
exiftool -a -G1 -s -time:all IMG_1234.JPG

-time:all は日時に関係するタグだけを表示します。-G1 はタグがどのグループにあるかを表示します。出力は次のような形です(値は例です)。

[System]        FileModifyDate                  : 2026:09:30 21:12:05+09:00
[ExifIFD]       DateTimeOriginal                : 2025:04:05 14:00:00
[ExifIFD]       CreateDate                      : 2025:04:05 14:00:00
[ExifIFD]       OffsetTimeOriginal              : +09:00

見るべき点は2つです。[ExifIFD] DateTimeOriginal があるか。そして OffsetTimeOriginal があるか。[System] の行はファイルシステムの日付で、写真そのものの情報ではありません。

Immich v3.2.4 は、撮影日時を次の順にタグから探します。SubSecDateTimeOriginal、SubSecCreateDate、DateTimeOriginal、CreationDate、CreateDate、MediaCreateDate、DateTimeCreated、GPSDateTime、DateTimeUTC、SonyDateTime2、SourceImageCreateTime。このどれも見つからないと、原因1の動きになります。

Immichのログで原因を確かめる

Immich自身にも、どちらの原因かを聞けます。ログの詳しさを debug に上げると、日時が見つからない写真とタイムゾーンが見つからない写真がログに出ます。Immichの docker-compose.yml があるディレクトリで実行します。

echo 'IMMICH_LOG_LEVEL=debug' >> .env
docker compose up -d
docker compose logs -f immich-server | grep -E 'No exif date time found|No timezone information found'

次に、Web画面でずれている写真を開き、右上のメニューから「メタデータを更新」を選びます。原因1の写真なら No exif date time found, falling back on ... が出ます。原因2の写真なら No timezone information found for asset ... が出ます。確認が終わったら .env から IMMICH_LOG_LEVEL=debug の行を消して、もう一度 docker compose up -d を実行します。debug のままだとログが大きくなるからです。

原因1:撮影日時がなく、コピーした日に並ぶ

EXIFに撮影日時がないとき、Immich v3.2.4 は2種類の日付を比べて、一番古いものを使います。1つはアップロードしたアプリが送ったファイル作成日時です。もう1つはサーバー上のファイル自体の日付(更新日時と作成日時)です。

問題は、ファイルの日付が簡単に変わることです。ファイルをコピーしたり、ブラウザでダウンロードしたりすると、更新日時はその操作をした時刻になることが多いです。すると「一番古い日付」が作業した日になり、写真がその日に並びます。

確かめ方は簡単です。上の exiftool -time:all で DateTimeOriginal も CreateDate もなく、[System] の行しか出ないなら、これが原因です。stat IMG_1234.JPG の Modify: がコピーした日なら、Immichもその日を使っています。

Google Takeout の写真:本当の日付はJSONにある

Google Takeout(Googleのデータ書き出し機能)で取り出した写真は、この原因の代表例です。スクリーンショットや保存した画像など、もともとEXIFに撮影日時がない写真があるからです。ZIPを展開すると、ファイルの更新日時も展開した日になります。

本当の日付は、写真の横にあるJSONファイルに入っています。名前は IMG_1234.JPG.supplemental-metadata.json のような形で、古いTakeoutでは IMG_1234.JPG.json です。中を見てみます。

sudo apt install -y jq
jq '.photoTakenTime' 'IMG_1234.JPG.supplemental-metadata.json'

timestamp はUNIX時間(1970年1月1日 UTC からの秒数)で、formatted は人が読める形です。写真だけをImmichにアップロードしても、この日付は使われません。ImmichはJSONファイルを読まないからです。

そこで、JSONを読んでからアップロードする immich-go を使います。2026年10月時点の最新タグは v0.32.0 で、Immich v3 に対応しています。リリースのタグを固定して取得します。

curl -LO https://github.com/simulot/immich-go/releases/download/v0.32.0/immich-go_Linux_x86_64.tar.gz
tar xzf immich-go_Linux_x86_64.tar.gz
./immich-go --help

APIキーはImmichのWeb画面の「アカウント設定」から作ります。まず --dry-run で、何をアップロードするかだけを確かめます。

./immich-go upload from-google-photos --server=http://localhost:2283 --api-key=YOUR_API_KEY --dry-run /path/to/takeout-*.zip

結果に問題がなければ、--dry-run を外して実行します。immich-go はEXIF、XMPサイドカー、TakeoutのJSON、ファイル名の順に日付を探します。EXIFがない写真では、JSONの日付をアップロード時の日時としてImmichに渡します。Immichは上で書いたとおり一番古い日付を選ぶので、JSONの日付が残ります。Takeout全体の移行の流れは、Immich への Google フォト移行で説明しています。

すでにWeb画面からTakeoutの写真を入れてしまった場合は、それらをImmichから削除し、ゴミ箱を空にしてから immich-go で入れ直すのが確実です。

LINE から保存した写真:残っているかは自分で確かめる

LINEのトークから端末に保存した写真に撮影日時が残るかどうかは、ここでは決めつけません。保存の方法やアプリのバージョンによって、結果が変わりうるからです。Immichの公式FAQは、WhatsAppから保存したファイルにはメタデータがないと書いています。LINEについては、手元のファイルで確かめるのが正しい手順です。

exiftool -a -G1 -s -time:all line_saved_photo.jpg

[ExifIFD] DateTimeOriginal が撮影した日時を指していれば、そのまま取り込めます。[System] の行しかなければ、撮影日時は失われています。その場合、本当の日付はトークの日付から人が判断するしかありません。後で説明する exiftool の手順で日時を書き込んでから、Immichに取り込みます。

原因2:オフセットのない時刻はUTCとして読まれる

多くのデジタルカメラは、DateTimeOriginal に 2025:04:05 14:00:00 のような時刻だけを書きます。この時刻がどのタイムゾーンのものかは、ファイルのどこにも書かれていません。

Immich v3.2.4 は、まず OffsetTimeOriginal などのオフセットタグを見ます。なければGPSの情報(撮影位置、またはGPSのUTC時刻と撮影時刻の差)からタイムゾーンを推定します。どちらもないと、ソースコードは時刻を「UTCの 14:00」として保存します。該当箇所には do not let JavaScript use local timezone というコメントがあります。サーバーのタイムゾーンをわざと使わない作りです。

その結果、日付と表示上の時刻は正しく見えます。タイムラインの日付は、撮影地の時刻(localDateTime)で決まるからです。ところが、同じ日の中の並び順は fileCreatedAt(撮影の瞬間をUTCに直した値)で決まります。

例で見ます。京都旅行で、カメラ(GPSなし)で 14:00 に1枚、iPhoneで 15:00 に1枚撮ったとします。iPhoneの写真に +09:00 が入っていれば、その瞬間は UTC 06:00 です。カメラの写真は UTC 14:00 として保存されます。本当はカメラの写真が1時間先なのに、タイムラインではiPhoneの写真より後に撮ったものとして並びます。旅行中のカメラの写真がまとめて9時間後ろにずれるので、順番が崩れます。

確かめ方は、ずれた写真で exiftool -a -G1 -s -time:all を実行し、OffsetTimeOriginal も [GPS] の行もないことを見ることです。ログでは No timezone information found for asset が出ます。

コンテナに TZ を設定しても直らない

以前のImmichの資料には、コンテナに TZ を設定してからメタデータを抽出し直す、という手順がありました。v3.2.4 では、上のとおりオフセットのない時刻はサーバーのタイムゾーンと関係なくUTCとして読まれます。そのため、TZ=Asia/Tokyo を設定しても、この並び順のずれは直りません。

ただし TZ が無関係になったわけではありません。v3.2.4 のストレージテンプレート(アップロードした写真を年月日のフォルダに分ける機能)は、フォルダ名の日付をサーバーのタイムゾーンで決めます。UTCのままだと、日本時間の朝に撮った写真が前日のフォルダに入ることがあります。コンテナの時刻は次のコマンドで見られます。

docker compose exec immich-server date

UTC と出れば、コンテナはUTCで動いています。設定方法と注意点はDocker Compose で TZ を設定してコンテナの時刻を合わせる方法にまとめています。

直したら「メタデータの展開」をやり直す

元ファイルを直した後は、Immichにファイルを読み直させます。1枚ずつなら、写真を開いて右上のメニューから「メタデータを更新」を選びます。全体なら、「管理」の「ジョブ」を開き、「メタデータの展開」(英語版では Extract Metadata)の「すべて」を押します。「欠落」はまだ抽出していない写真だけが対象です。直したファイルを読み直すには「すべて」を選びます。写真が多いと時間がかかるので、使う人が少ない時間に実行してください。

直し方A:Immichの「日時を編集」で直す

元のファイルに触れずに直すなら、Immichの機能を使います。Web画面で写真を選び、メニューから「日時を編集」を開きます。

1枚だけなら、正しい日時とタイムゾーンを直接入れます。複数の写真をまとめて直すときは、日時を直接入れてはいけません。全部の写真が同じ時刻になるからです。代わりに「オフセットを用いて日付を変更」を選び、ずらす量を指定します。

原因2の写真なら、ずらす量は -9 時間(-540 分)、タイムゾーンは Asia/Tokyo です。v3.2.4 のこの処理は、保存されている瞬間(UTC 14:00)に指定の時間を足し、タイムゾーンを書き換えます。UTC 14:00 から9時間引くと UTC 05:00 になり、Asia/Tokyo では 14:00 です。表示の時刻はそのままで、並び順だけが正しくなります。

編集した内容の保存先は、元のファイルではありません。Immichは元ファイルを変更しないと公式FAQに書いてあり、v3.2.4 のソースでも、編集した日時はデータベースとXMPサイドカーに書かれます。サイドカーの名前は、元ファイルの名前に .xmp を付けたものです(例:IMG_1234.JPG.xmp)。中身は次のように確かめます。

exiftool -G1 -s -XMP:DateTimeOriginal IMG_1234.JPG.xmp

+09:00 が付いた時刻が入っていれば成功です。アップロードした写真がディスクのどこにあるかは、Immich が Docker で写真を保存する場所を見てください。

注意点が1つあります。サイドカーは元ファイルと同じフォルダに作られます。外部ライブラリを :ro(読み取り専用)でマウントしていると、そのフォルダには書き込めません。そのため、編集はデータベースにだけ残り、ファイルの横には何も残りません。外部ライブラリの日付を長く正しく保ちたいなら、直し方Bのほうが向いています。

サイドカーは、元ファイルと同じくらい大事なデータになります。バックアップの対象から外さないでください。手順はImmich のバックアップと復元にあります。

直し方B:exiftoolで元ファイルを直してから取り込み直す

写真をImmichの外でも使うなら、元ファイルを直すのが確実です。別のアプリやサービスに移しても、正しい日時がついていきます。

必ずコピーで作業します。日時を間違えて書くと、元の値に戻す手がかりがなくなるからです。

cp -a ./trip-2025-kyoto ./fixed

cp -a は更新日時も保ったままコピーします。

カメラの写真にオフセットだけを足すには、次のようにします。-if で、まだオフセットがない写真だけを対象にします。

exiftool -if 'not $OffsetTimeOriginal' -OffsetTimeOriginal=+09:00 -OffsetTime=+09:00 -OffsetTimeDigitized=+09:00 -overwrite_original ./fixed

カメラの時計を日本時間のまま海外へ行った場合は、時刻もずれています。たとえばタイ(UTC+7)なら、カメラの時計は現地より2時間進んでいます。2時間戻してから、現地のオフセットを書きます。

exiftool '-AllDates-=2' -OffsetTimeOriginal=+07:00 -OffsetTime=+07:00 -OffsetTimeDigitized=+07:00 -overwrite_original ./fixed

AllDates は DateTimeOriginal、CreateDate、ModifyDate をまとめて指す名前です。

撮影日時がまったくない写真には、日時を直接書きます。LINEの写真のように、日付をトークから判断した場合です。

exiftool -DateTimeOriginal='2025:04:05 14:00:00' -OffsetTimeOriginal=+09:00 -overwrite_original ./fixed/line_saved_photo.jpg

ファイル名に日時が入っている写真なら、exiftool はファイル名の数字から日時を読めます。

exiftool -if 'not $DateTimeOriginal' '-DateTimeOriginal<Filename' -overwrite_original ./fixed

ただし、ファイル名の時刻が現地時刻かUTCかは、機種によって違います。1枚で結果を確かめてから全体に実行してください。

-overwrite_original を付けないと、exiftool は IMG_1234.JPG_original という控えのファイルを残します。そのフォルダを外部ライブラリとして読ませると、控えも写真として取り込まれます。作業用のコピーで直しているので、ここでは付けています。

直した後は、もう一度 exiftool -a -G1 -s -time:all で中身を確かめます。

Immichへ取り込み直す

直したファイルは中身が変わったので、チェックサムも変わります。Immichは同じチェックサムのファイルを重複として弾きます。しかし直したファイルは別の写真として入るので、古い写真と二重になります。そのため、先にImmichから古い写真を削除し、ゴミ箱を空にします。それから取り込み直します。

./immich-go upload from-folder --server=http://localhost:2283 --api-key=YOUR_API_KEY ./fixed

外部ライブラリの場合は、元のフォルダのファイルを直したファイルで置き換えます。その後、ライブラリをスキャンし、上で説明した「メタデータの展開」を実行します。日時が正しく並んだことを、タイムラインで確かめてください。

AとBのどちらを選ぶか

直す枚数が少なく、写真をImmichの中だけで見るなら、直し方Aが手軽です。元ファイルに触れないので、間違えても戻せます。

外部ライブラリを読み取り専用にしている場合や、Takeoutのように数千枚単位で直す場合は、直し方Bを選びます。正しい日時がファイルそのものに入るので、Immichを入れ直しても、別のサービスへ移っても日時は残ります。

FAQ(よくある質問)

Immichで写真がアップロードした日やコピーした日に並ぶのはなぜですか?

写真のEXIFに撮影日時がないからです。その場合、Immichはアップロード時に送られたファイル作成日時と、サーバー上のファイルの日付のうち、一番古いものを使います。コピーやダウンロードで更新日時が作業した日になると、写真もその日に並びます。exiftool -a -G1 -s -time:all で DateTimeOriginal がないことを確かめ、exiftool で日時を書き込んでから取り込み直してください。

カメラで撮った写真だけ、同じ日の中で順番がずれるのはなぜですか?

カメラが時刻にタイムゾーンのオフセットを書いていないからです。Immich v3.2.4 は、オフセットもGPSもない時刻をUTCとして保存します。日付と表示の時刻は正しく見えます。しかし並び順はUTCに直した瞬間で決まるので、日本で撮ったカメラの写真は9時間後に撮ったものとして並びます。Immichの「日時を編集」でオフセット -9 時間とタイムゾーン Asia/Tokyo を指定するか、exiftool で OffsetTimeOriginal=+09:00 を書き込んで直します。

docker-compose.yml に TZ=Asia/Tokyo を設定すれば直りますか?

Immich v3.2.4 では、オフセットのない撮影時刻の読み方は TZ で変わりません。ソースコードが、サーバーのタイムゾーンを使わずにUTCとして読むように作られているからです。TZ が影響するのは、ストレージテンプレートが作るフォルダ名の日付などです。並び順を直すには、オフセットをファイルに書くか、Immichの「日時を編集」を使います。

Immichで日時を編集すると、元の写真ファイルは書き換わりますか?

書き換わりません。編集した日時は、データベースと、元ファイルの横に作られるXMPサイドカー(例:IMG_1234.JPG.xmp)に保存されます。外部ライブラリを読み取り専用でマウントしているとサイドカーを作れないので、元ファイルを exiftool で直すほうが確実です。

Google Takeout の写真の日付を正しく取り込むには?

Takeoutの本当の撮影日時は、写真の横にあるJSONファイルの photoTakenTime に入っています。写真だけをアップロードしても、ImmichはこのJSONを読みません。immich-go の upload from-google-photos を使ってください。JSONの日付を読んでからアップロードするので、EXIFのない写真も撮影日に並びます。