この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）
本番サーバーで障害対応をしていて、こんな経験をしたことはありませんか。ログを何十分も調べ続けているのに、問題が発生したはずの時刻のエントリがどこにもない。実は、サーバーのタイムゾーン設定が間違っているだけで、こういう状況に陥ります。
私がSE時代の2003年頃、まさにこの状況にはまり込みました。夜22時に発生した本番障害の対応で
/var/log/messagesを開き、22時台のエントリを1時間以上探し続けた末、先輩エンジニアに「そのサーバー、タイムゾーン確認した？」と一言言われて気づいたのです。サーバーがUTC（協定世界時）のままになっていて、ログの時刻がJST（日本標準時）より9時間遅れて記録されていました。22時のエラーはログ上では13時に記録されていたわけです。この記事では、20年以上Linuxサーバーを運用・指導してきた経験から、Linuxのタイムゾーン設定の確認・変更方法と、よくあるトラブルの対処手順を解説します。設定後の確認手順まで含めて、実際のコマンド出力例とともに紹介します。
この記事のポイント
・UTCとJSTの9時間差がログ調査の混乱を招く最もよくある原因
・タイムゾーン確認は timedatectl コマンド1つで済む
・NTP時刻同期とタイムゾーン設定は別の設定——混同しないこと
・設定後は必ず date コマンドで時刻を目視確認する習慣をつける
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
タイムゾーンがUTCのままだった日の話
私がまだSEとして現場に出始めた2003年頃のことです。担当していたWebサービスで、夜になると断続的なエラーが発生するという障害報告が上がりました。ユーザーから「22時ごろにページが開けなくなる」という情報だけを頼りに、/var/log/messagesとApacheのエラーログを開いて調べ始めました。22時台のエントリを探すのですが、どうしても見当たりません。21時台にも23時台にも意味のあるエラーは出ていない。「再現しない障害なのか？」と思い始めた頃に、先輩が隣に来て画面を見た瞬間、こう言いました。
「あ、このサーバーUTCのままになってるよ。13時台のログ見て」
画面をスクロールして13時台を確認したところ、大量のエラーエントリが並んでいました。JST22時はUTCでは13時。9時間の差をまったく意識していなかったのです。そのサーバーは別の担当者がインストールした際にタイムゾーン設定を省略してしまっていて、OSのデフォルトであるUTCのまま本番稼働していました。
セミナーで3,100名以上の受講生を指導してきた中で、「ログを調べてもエラーが見つからない」という相談を受けると、まず最初にタイムゾーン設定を確認するよう伝えています。それだけこのミスは現場で繰り返されています。
あの日以来、私は新しいサーバーを立ち上げる際には必ずタイムゾーンを確認し、JSTへの設定を最初の手順に入れています。「動いているから大丈夫」ではなく「正しく動いているか確認してから次へ進む」という習慣が、あの1時間の無駄から生まれました。
なぜタイムゾーン設定がサーバー運用で重要なのか
タイムゾーンの設定は、一見すると「ログの表示時刻が変わるだけ」のように思えます。しかし実際には、サーバー運用のさまざまな場面で影響が出ます。ログ調査での時刻整合性
複数のサーバーにまたがる障害を調査するとき、ログの時刻がバラバラだと事象の前後関係を正確に追えません。Webサーバー・DBサーバー・ロードバランサーのログを突き合わせて原因を絞り込む作業は、全サーバーの時刻が一致していることが前提です。
cronの実行時刻
cronはシステム時刻に従って動作します。タイムゾーンがUTCのサーバーで「毎朝9時にバックアップ」という設定にすると、実際にはJSTの18時（UTC9時）に実行されます。深夜0時に実行したいジョブが業務時間中に動いてしまう、という事態も起きます。
セキュリティ監査ログの信頼性
不正アクセスの調査では、ログの時刻が正確でないと証拠能力に疑問が生じます。社内の情報セキュリティポリシーで「ログの時刻精度」を要件に定めている場合、タイムゾーンのズレはコンプライアンス上の問題になります。
SSL証明書・Kerberosの時刻依存
SSL/TLSの証明書検証やKerberos認証は時刻の正確性に依存します。サーバー時刻が大きくズレていると認証エラーになることがあります。
これらの理由から、タイムゾーン設定はOSインストール直後に確認・設定する最初の作業のひとつです。後回しにして「動いているからいいか」は、いつか痛い目を見ます。
タイムゾーンの確認方法（timedatectl / dateコマンド）
RHEL 9 / Rocky Linux 9 / AlmaLinux 9 / Ubuntu 24.04 LTS で動作確認した手順を紹介します。1. timedatectlコマンドで確認する
RHEL7以降・Ubuntu16以降のsystemd環境では、timedatectlコマンドでタイムゾーンと時刻同期の状態を一括確認できます。# timedatectl Local time: Wed 2026-09-03 12:34:56 JST Universal time: Wed 2026-09-03 03:34:56 UTC RTC time: Wed 2026-09-03 03:34:56 Time zone: Asia/Tokyo (JST, +0900) System clock synchronized: yes NTP service: active RTC in local TZ: no
・Time zone: 「Asia/Tokyo (JST, +0900)」になっているか確認する
・System clock synchronized: 「yes」であればNTP同期が機能している
・NTP service: 「active」であればchronydが動いている
「Time zone: Etc/UTC (UTC, +0000)」と表示されていたら、タイムゾーンの設定が必要です。次のセクションで変更方法を解説します。
2. dateコマンドで現在時刻を確認する
最もシンプルな確認方法です。出力に「JST」が含まれていれば日本標準時に設定されています。# date Wed Sep 3 12:34:56 JST 2026 # ls -la /etc/localtime lrwxrwxrwx. 1 root root 33 Apr 10 09:00 /etc/localtime -> ../usr/share/zoneinfo/Asia/Tokyo
/etc/localtimeがどのzoneinfo定義ファイルへシンボリックリンクしているかで、設定されているタイムゾーンが分かります。「Asia/Tokyo」へのリンクになっていれば正しい状態です。UTCのままの場合は「Etc/UTC」か「UTC」を指しています。タイムゾーンの設定・変更方法
1. timedatectl set-timezoneでJSTに変更する（推奨）
systemd環境ではtimedatectlコマンドで変更するのが最もシンプルで確実です。rootまたはsudo権限が必要です。# タイムゾーンをJSTに変更する # timedatectl set-timezone Asia/Tokyo # 変更後に確認する # timedatectl Local time: Wed 2026-09-03 12:34:56 JST Universal time: Wed 2026-09-03 03:34:56 UTC Time zone: Asia/Tokyo (JST, +0900) System clock synchronized: yes NTP service: active RTC in local TZ: no # NTP同期を有効にする（有効化されていない場合） # timedatectl set-ntp true # 現在時刻を目視確認する # date Wed Sep 3 12:34:56 JST 2026
timedatectl set-timezoneを実行すると、/etc/localtimeのシンボリックリンクが自動的に更新されます。再起動不要で即時に反映されます。利用可能なタイムゾーン一覧を確認するには次のコマンドを使います。
# アジア地域のタイムゾーン一覧を表示する # timedatectl list-timezones | grep Asia Asia/Aden Asia/Almaty Asia/Amman ... Asia/Tokyo ...
2. NTP時刻同期の設定（chronyの確認）
タイムゾーンは「どの地域の時刻として表示するか」を決める設定であり、「時刻が正確かどうか」とは別の話です。時刻のズレを自動補正するにはNTP同期が必要で、RHEL7以降ではchronyがデフォルトのNTPクライアントです。# chronydの状態を確認する # systemctl status chronyd * chronyd.service - NTP client/server Loaded: loaded (/usr/lib/systemd/system/chronyd.service; enabled; preset: enabled) Active: active (running) since Wed 2026-09-03 12:00:00 JST; 34min ago ... # NTP同期の状況を確認する（同期しているサーバーの一覧） # chronyc sources MS Name/IP address Stratum Poll Reach LastRx Last sample =============================================================================== ^+ ntp1.jst.mfeed.ad.jp 2 6 77 11 +183us[ +183us] +/- 12ms ^* ntp2.jst.mfeed.ad.jp 2 6 177 11 -126us[ -126us] +/- 12ms
NTP同期とタイムゾーン設定のどちらも正しくして初めて「正確な日本時刻がログに記録される」状態になります。crontabの設定と実行結果の関係については、crontabコマンドの設定と書き方も参考にしてください。
3. RHEL6・CentOS6以前の設定方法
systemd以前（RHEL6以前）の環境ではtimedatectlが使えません。その場合は/etc/sysconfig/clockを編集してタイムゾーンを設定します。# /etc/sysconfig/clockの内容を確認する # cat /etc/sysconfig/clock ZONE="Asia/Tokyo" UTC=false ARC=false # 手動でシンボリックリンクを設定する（バックアップしてから実行） # cp -p /etc/localtime /etc/localtime.bak # ln -sf /usr/share/zoneinfo/Asia/Tokyo /etc/localtime # 変更後に時刻確認 # date
タイムゾーン設定でエラーが出た時のトラブル対処
timedatectl set-timezoneが「Failed to set time zone」で失敗する
このエラーはいくつかの原因が考えられます。原因1: root権限がない
timedatectl set-timezoneはroot権限またはsudo権限が必要です。一般ユーザーで実行するとエラーになります。# sudoを付けて実行する # sudo timedatectl set-timezone Asia/Tokyo # または rootに切り替えてから実行 # su - # timedatectl set-timezone Asia/Tokyo
「Asia/Tokyo」は正しいですが、「Asia/tokyo」（小文字）や「JST」（略語）では設定できません。
timedatectl list-timezonesで正確な名前を確認してから実行してください。原因3: systemd-timedatedが起動していない
timedatectlコマンドはsystemd-timedatedデーモンと通信して動作します。このデーモンが停止していると操作できません。# systemd-timedatedの状態を確認する # systemctl status systemd-timedated * systemd-timedated.service - Time & Date Service Loaded: loaded (/usr/lib/systemd/system/systemd-timedated.service; static) Active: active (running) since Wed 2026-09-03 12:00:00 JST; 5s ago
NTP同期が「System clock synchronized: no」のままになる
NTP同期が有効にならない場合、まずchronydの起動状態と設定ファイルを確認します。# chronydが起動しているか確認 # systemctl status chronyd # 停止していれば起動・自動起動を設定 # systemctl start chronyd # systemctl enable chronyd # 同期状況の詳細確認 # chronyc tracking Reference ID : AC1C2A01 (172.28.42.1) Stratum : 3 Ref time (UTC) : Wed Sep 3 03:34:56 2026 System time : 0.000123456 seconds fast of NTP time Last offset : +0.000123456 seconds RMS offset : 0.000234567 seconds Frequency : 10.234 ppm slow
私が現場でよく見かけるのが、クラウド環境（AWS EC2・Azure VMなど）でVMのNTPクライアントを別途設定してしまい、クラウド側のタイムサーバーとの競合が起きているケースです。AWS EC2では169.254.169.123（Amazon Time Sync Service）を使うのが推奨です。
まとめ
Linuxサーバーのタイムゾーン設定は、インストール直後に必ず確認・設定する習慣をつけてください。タイムゾーンのズレは障害調査を根本から迷走させます。私はSE時代に1時間以上を無駄にしてから、この習慣を絶対に手放しませんでした。| やりたいこと | コマンド |
|---|---|
| タイムゾーンと時刻同期の状態を確認する | timedatectl |
| タイムゾーンをJSTに変更する | timedatectl set-timezone Asia/Tokyo |
| 現在の時刻とタイムゾーンを確認する | date |
| 利用可能なタイムゾーン一覧を表示する | timedatectl list-timezones |
| NTP同期を有効にする | timedatectl set-ntp true |
| NTP同期サーバーの一覧と状態を確認する | chronyc sources |
| chronyの同期詳細（時刻のズレ量）を確認する | chronyc tracking |
| localtime定義ファイルの向き先を確認する | ls -la /etc/localtime |
タイムゾーン設定から始める「サーバー構築の型」を学びたい方へ
タイムゾーン・NTP・ファイアウォール・ユーザー管理——サーバーを安全に動かすには、個別のコマンドを覚えるだけでなく「確認の順序と型」が必要です。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 前のページへ：Linuxでpingは通るのにサービスに繋がらなかった日の話｜SE時代の障害切り分けで学んだネットワークとプロセスの関係
- この記事の属するカテゴリ：Linux学習ガイドへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます