ファイルのタイムスタンプを任意の日時に変更する実務手順

まず結論：タイムスタンプを指定日時に変更するコマンド

ファイルのタイムスタンプを特定の日時に変更するには、touch コマンドの -t オプションまたは -d オプションを使います。

# -t オプション：CCYYMMDDhhmm.ss 形式で厳密に指定
touch -t 202403151430.00 report.log

# -d オプション：人間が読みやすい書式で指定（こちらが現代的）
touch -d "2024-03-15 14:30:00" report.log

変更後は stat コマンドで mtime・atime・ctime の3つをまとめて確認できます。ls -l は mtime しか表示しないため、確認には stat を使うのが確実です。

stat report.log

  File: report.log
  Size: 0               Blocks: 0          IO Block: 4096   regular empty file
Device: fd00h/64768d    Inode: 131074      Links: 1
Access: 2024-03-15 14:30:00.000000000 +0900
Modify: 2024-03-15 14:30:00.000000000 +0900
Change: 2026-07-11 10:22:35.481209876 +0900

Access と Modify は指定どおり 2024-03-15 になっています。一方 Change（ctime）だけは操作を実行した「今」の日時になっており、touch では変更できません（詳しくは後述）。

タイムスタンプの3種類を押さえる

Linux のファイルには3種類のタイムスタンプがあります。操作の目的によってどれを変更すべきかが変わるため、違いを把握しておくと現場での判断が早くなります。

種別	正式名称	更新タイミング	touch で変更
mtime	modification time	ファイルの内容を書き換えたとき	可
atime	access time	ファイルを読み取ったとき	可（条件あり）
ctime	change time	内容・権限・所有者などメタデータが変わったとき	不可

ls -l や find -mtime、rsync の差分検出で参照されるのは基本的に mtime です。バックアップ・デプロイ・ログ管理など実務上の操作対象は mtime がほとんどです。

用途別コマンド集

-t オプション：厳密な日時を数値で指定する

フォーマットは [[CC]YY]MMDDhhmm[.ss] です。世紀（CC）・年（YY）・秒（.ss）は省略でき、省略した場合は現在の年・秒0が補完されます。スクリプト内で厳密な日時を渡したいときに適しています。

# 2024年3月15日 14:30:00 に変更
touch -t 202403151430.00 report.log

# 秒を省略（.00 扱い）
touch -t 202403151430 report.log

# 年も省略（実行時の年が補完される）
touch -t 03151430 report.log

-d オプション：柔軟な書式で指定する（現代的な方法）

-d オプションは GNU date と同じ書式を受け付けます。相対表現が使えるため、テスト環境のファイルを素早く「N日前」に設定したい場面で特に重宝します。

# ISO 8601 形式
touch -d "2024-03-15 14:30:00" report.log

# タイムゾーン付き
touch -d "2024-03-15 14:30:00 JST" report.log

# 相対指定（テスト・デバッグ向け）
touch -d "2 days ago"   old_data.csv
touch -d "last Monday"  weekly.log
touch -d "1 year ago"   archive.tar.gz

シェルスクリプト内でシェル変数と組み合わせるときは、ダブルクォートで変数を展開します。

TARGET_DATE="2024-03-15 14:30:00"
touch -d "$TARGET_DATE" report.log

別ファイルのタイムスタンプをそのままコピーする

-r オプションを使うと、参照ファイルの mtime・atime をそのままコピーできます。デプロイ後に複数ファイルのタイムスタンプを揃えたいケースで便利です。

# reference.conf のタイムスタンプを target.conf にコピー
touch -r reference.conf target.conf

# ディレクトリ内の複数ファイルに一括適用
for f in /var/log/app/*.log; do
  touch -r /var/log/app/reference.log "$f"
done

mtime・atime を個別に操作する

デフォルトでは mtime と atime の両方が変更されます。-m（mtime のみ）または -a（atime のみ）を付けることで、どちらか一方だけを操作できます。

# mtime のみ変更（atime は現状維持）
touch -m -t 202403151430.00 report.log

# atime のみ変更（mtime は現状維持）
touch -a -t 202403151430.00 report.log

# 変更結果を stat で確認
stat report.log

現場での活用シーン

タイムスタンプの書き換えは「ファイルの日付を偽る」操作に聞こえますが、実際の現場では正当な用途が数多くあります。

バックアップスクリプトの動作検証では、rsync や独自スクリプトが「更新日時が新しいファイルだけ転送する」ロジックを正しく動作させているかを確かめるために、意図的に古いタイムスタンプのファイルを用意する手法がよく使われます。実際のファイル内容を変更せずに済むのがポイントです。

古いファイルの削除スクリプトのテストでも役立ちます。find /var/log -mtime +30 -delete のようなクリーニングスクリプトを本番環境で検証する前に、30日以上前のタイムスタンプを持つダミーファイルを使って動作を確認できます。

# テスト用ダミーファイルを「45日前」として作成
touch -d "45 days ago" /tmp/dummy_old.log

# 削除スクリプトが対象として拾うか確認（-delete は外してドライラン）
find /tmp -name "dummy_old.log" -mtime +30

logrotate の動作確認では、ローテーション対象ログのタイムスタンプを数日前に設定することで、設定ファイルを変更せずにローテーションを手動でトリガーできます。ステージング環境での検証コストを大幅に下げられる手法として、ある運用現場では標準的な手順として取り入れられています。

Makefile・ビルドツールのキャッシュ制御でも活用できます。make は依存ファイルの mtime を比較して再ビルドの要否を判断するため、特定ファイルのタイムスタンプを意図的に変えることでキャッシュヒット・ミスの挙動を制御できます。

注意点と落とし穴

ctime は touch では変更できない

ctime（change time）はカーネルが管理するメタデータで、通常ユーザーには変更権限がありません。touch を実行すると mtime を過去の日時に書き換えられますが、その操作自体が「メタデータの変更」に当たるため、ctime は「実行した今」に更新されます。セキュリティ監査ツールや侵入検知システムが ctime を参照して改ざんを検出するのはこの仕様を利用しています。mtime を書き換えても ctime には痕跡が残る点は覚えておきましょう。

noatime / relatime マウントオプションに注意

多くの本番サーバーでは I/O 負荷を減らすため、/etc/fstab に noatime または relatime が設定されています。この状態では touch -a で atime を変更しても、次回ファイルを読み取ったときに OS が atime を更新しない（あるいは条件付きでのみ更新する）ため、設定した値が保持されないことがあります。atime を操作する前にマウントオプションを確認しましょう。

# マウントオプションを確認する
findmnt -o TARGET,OPTIONS /

# /etc/fstab を確認する（コメント行を除外）
grep -v "^#" /etc/fstab

未来の日時を設定するとスクリプトが誤作動する

touch -d "2099-01-01" のように未来の日時を設定すると、find -mtime -1（1日以内に更新されたファイル）などの条件フィルターで常にヒットし続けます。バックアップ対象として毎回転送され続けるといった問題が起きやすいため、テスト後は本来の日時に戻すかファイルを削除するようにしましょう。

NFS・SMB 共有ではタイムゾーンのずれに注意

NFS や Samba/SMB 経由でマウントしたパスのファイルは、サーバー側のタイムゾーン設定によって表示がずれることがあります。UTC で動いているサーバーから JST のクライアントが参照する場合、stat の出力が想定外の時刻を示すことがあります。タイムスタンプ操作後はサーバー側でも stat を実行して確認するのが安全です。