はじめに
去年の10月にUbuntu 25.10にアップデートしてから、デュアルブート環境で時刻が定期的にズレるようになった。当時はchrony が初めてデフォルトNTPデーモンになったタイミングで、/etc/chrony/chrony.conf の rtcsync を一行コメントアウトして凌いでいた。
ただ、これはどう見ても対症療法だった。パッケージ更新で設定が戻る可能性があるし、そのたびに同じ修正をするのも気持ちが悪い。
そうこうしているうちに Ubuntu 26.04 LTS（Resolute Raccoon）のリリース日が近づいてきた（公式発表では2026年4月23日）。せっかくLTSに上げるならクリーンインストールしたい。でも、クリーンインストールしたら同じ chrony.conf 修正をまたやるのか？と考えたとき、これは違うなと思った。
LTSは向こう5年使う前提の構成だ。対症療法を毎回焼き直すくらいなら、一度Windows側を触って恒久対処にしたほうがいい。というわけで、26.04 LTS のクリーンインストール前に、先にWindows側の設定を済ませることにした。
この記事は、そのときに考えたことと実際の手順の記録。同じく「25.10で時刻ズレに遭遇して、chrony.conf を弄って凌いでいる」という方が、26.04 LTSへの移行タイミングで一度構成を整理する参考になれば。
25.10 で起きたこと（これまでの経緯）
最初は原因が分からなかった。timedatectl set-local-rtc 1 は昔からデュアルブート環境の定番で、LTS時代（24.04以前）ではこれでWindowsと時計を合わせられていた。
sudo timedatectl set-local-rtc 1 --adjust-system-clock25.10でも timedatectl の表示上は RTC in local TZ: yes になる。でも、数十分後にWindowsを起動すると時計が9時間ズレる（JST環境の場合）。おかしい、と timedatectl を再確認しても依然として yes のまま。なのに、RTCの中身はUTCで書かれている。
根本原因と、chrony が絡む理由
調べていくうちに、まず整理すべきはこういう構造だとわかった。
ズレの根本原因は、WindowsとLinuxの RTC（ハードウェア時計）の解釈の違いにある。
- Linux は基本的に RTC を UTC として扱う
- Windows は初期状態で RTC をローカル時刻として扱う
これはchronyとは関係なく、昔からデュアルブートにつきまとう古典的な問題だ。従来の対処は「Linux 側を set-local-rtc 1 で Windows に合わせる」だった。
ここでchronyが絡んでくる。Ubuntu 25.10 で systemd-timesyncd から chrony にデフォルトが変わった（Ubuntu公式ドキュメント）。Ubuntu が配布する /etc/chrony/chrony.conf には rtcsync ディレクティブが有効で入っており、chrony.conf(5) マニュアルを読むと、Linux ではこのモードでカーネルが 11 分ごとに RTC に書き込みを行う。この挙動は RTC を UTC で運用する前提と相性が良いため、set-local-rtc 1 で Linux 側だけを「RTC=ローカル時刻」に寄せる従来手法は、以前より安定しにくくなった。
つまり、chrony自体がズレの主因ではなく、従来の回避策（set-local-rtc 1）を効きにくくした要素という整理になる。具体的な挙動はこうだ。
timedatectl set-local-rtc 1で RTC をローカルタイムに設定するtimedatectl上はローカルタイム設定になる（これ自体は嘘ではない）- 11分後、
rtcsync経由でカーネルが RTC を UTC で上書きする - Windows 起動時、RTC（UTCで書かれた値）をローカルタイムとして解釈して9時間ズレる
逃げ道が一つ減った、という言い方が一番しっくりくる。
当時の対症療法
/etc/chrony/chrony.conf の rtcsync をコメントアウトした。
sudo sed -i 's/^rtcsync/#rtcsync/' /etc/chrony/chrony.conf
sudo systemctl restart chronyこれでカーネル経由の RTC 上書きが止まり、set-local-rtc 1 が従来通り機能するようになった。当座は解決。
なぜ 26.04 クリーンインストールを機に変えるのか
対症療法には3つの不満があった。
1. パッケージ更新で設定が戻るリスク
chrony や systemd の更新で conffile プロンプトが出たときに見逃すと、rtcsync が戻る。その後数十分放置してからWindows側で9時間ズレ、ということが起きる。ありがたくない。
2. 環境をセットアップするたびに同じ作業
26.04 にクリーンインストールしたら、また同じ修正を入れる必要がある。自動化するほどの作業量ではないが、だからこそ毎回手で直すのも筋が悪い。
3. rtcsync を切るのは Linux 単体で見ても微妙な選択
Arch Wiki の chrony ページには、rtcsync を切ると RTC のドリフト追跡が効かなくなるので、間欠運用のデスクトップには向かないと書かれている。デュアルブート用途のマシンは普通に間欠運用なので、ここは小さいながらも副作用がある。
要するに、Linux 側で何かを「切って」凌いでいる構成自体が、クリーンインストールを跨いで持ち越すには少し筋が悪い。だったら、Windowsを一回触ってUTC読みに変えてしまえば、以後 Ubuntu 側はデフォルトのまま（rtcsync 有効、RTC=UTC）で運用できる。これが一番シンプルだ、という結論になった。
解決策: Windows 側の RTC を UTC 読みに切り替える
Windows には「RTC を UTC として解釈する」ためのレジストリ値がある。Microsoft コミュニティの議論でも言及されている HKLM\System\CurrentControlSet\Control\TimeZoneInformation\RealTimeIsUniversal がそれにあたる。設定画面やグループポリシーには露出しておらず、レジストリ経由でのみ有効化する。
なお、
RealTimeIsUniversalはMicrosoftの公式サポート文書に記載がないキーだ。デュアルブート界隈では長く使われてきた実質標準の設定ではあるが、公式サポート設定ではない点は頭に置いておきたい。
管理者権限の PowerShell で以下を実行する。
New-ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\TimeZoneInformation" `
-Name "RealTimeIsUniversal" -Value 1 -PropertyType DWord -Forcecmd 派はこちらでも同じ。
reg add "HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation" /v RealTimeIsUniversal /t REG_DWORD /d 1 /f値の型は DWORD が無難
ネットの記事を見ると RealTimeIsUniversal を QWORD で作っている例と DWORD で作っている例が混在している。どちらでも動く環境が多いのだが、仮想化環境の PV ドライバで QWORD が問題を起こした報告もあり、Microsoft コミュニティの最近のやりとりでも DWORD で書く例が中心になっている。私自身は物理マシンのデュアルブートなので両方試したことはあるが、確実にこちらが正しいと言い切れるソースはMicrosoft公式にはないため、「迷ったら DWORD」くらいの温度感で捉えるのが正確だと思う。
書き込み後は以下で型を確認できる。
(Get-ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\TimeZoneInformation" -Name RealTimeIsUniversal).RealTimeIsUniversal.GetType().Name
# → Int32 が出れば DWORD で作れている作業順序が一番大事
レジストリを書き換えてそのまま再起動すると、Windows は RTC（まだローカルタイムで書かれている値）を UTC として読んでタイムゾーンオフセットを足すので、結果的に9時間ズレて起動する。私は25.10で一度この罠を踏んだ。
正しい順序は以下の通り。これから初めてUbuntu 26.04を入れる（現在はWindows単体の）人: ステップ1〜3は不要なので、直接「ステップ4（Windowsでのレジストリ設定）」からでOK。
ステップ1: Ubuntu 側で chrony の設定を素に戻す
25.10 で rtcsync をコメントアウトしていたなら、ここで戻す。
sudo sed -i 's/^#rtcsync/rtcsync/' /etc/chrony/chrony.conf
sudo systemctl restart chrony26.04 にクリーンインストールしたばかりなら、この手順は不要（最初から rtcsync 有効）。
ステップ2: RTC を UTC に切り替える
sudo timedatectl set-local-rtc 0 --adjust-system-clock
timedatectl
# "RTC in local TZ: no" を確認ステップ3: chrony が NTP 同期を完了していることを必ず確認
ここを飛ばすと、不正確なシステム時刻がそのまま RTC に書き込まれて、Windows 起動時に大ズレを起こす。
chronyc tracking出力のうち、以下の2行を確認する。
Reference ID : C0248F4E (ntp-b3.nict.go.jp) # ← 00000000以外なら同期成功
Leap status : Normal # ← Normalなら正常Reference ID が 00000000 のままだと、まだ一度も NTP 同期に成功していない状態。この状態で次のステップに進むと後述する「21時なのに6時」事件が起きる。
ステップ4: Windows を起動してレジストリを設定
Ubuntu をシャットダウンし、Windows を起動して PowerShell でレジストリを書き込む。
New-ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\TimeZoneInformation" `
-Name "RealTimeIsUniversal" -Value 1 -PropertyType DWord -Forceステップ5: 高速スタートアップを切って完全シャットダウン
Windows 11 の高速スタートアップが絡むと RTC 周りの挙動確認がややこしくなるので、いったん切って完全シャットダウンに統一しておくと安全だ。
powercfg /h offその後、スタートメニューから「シャットダウン」を選び、電源が完全に落ちたのを確認してから起動する。
動作確認
Ubuntu 側で確認する。
$ timedatectl
Local time: 木 2026-04-23 21:35:00 JST
Universal time: 木 2026-04-23 12:35:00 UTC
RTC time: 木 2026-04-23 12:35:00
Time zone: Asia/Tokyo (JST, +0900)
System clock synchronized: yes
NTP service: active
RTC in local TZ: noRTC in local TZ: no で、RTC time が Universal time と一致していれば成功。
Windows 側はタスクバーの時計が正しいJSTを示していればOK。念のため PowerShell で確認するなら以下。
Get-DateUbuntu ↔ Windows を何度か往復してもズレが発生しなければ完了。この状態なら chrony.conf はデフォルトのままで動くので、次に26.04 LTSへクリーンインストールした際も、Linux 側は追加設定ゼロで済む想定になる。
副作用について
事前に把握しておきたい副作用を正直に挙げる。実運用で刺さるものは少ない。
1. UEFI/BIOS 画面の時刻が UTC 表示になる
これが唯一ほぼ確実に体感する副作用。ファームウェア設定に入ると時計が-9時間（JST基準）でズレて見える。壊れているわけではなく単に表示がそうなるだけだが、BIOSで時刻依存の設定をするときは頭の中で換算が必要になる。
2. Microsoft 公式には未サポートの設定
RealTimeIsUniversal は Microsoft 公式ドキュメントに記載のないレジストリキーだ。デュアルブート界隈では長く安定して使われてきた実質標準の設定ではあるが、公式サポートではないので、将来のメジャーアップデートで挙動が変わる可能性はゼロではない、という建前上のリスクがある。実用上の懸念は小さいが、頭の片隅には置いておきたい。
3. FAT/exFAT のタイムスタンプ
FAT系はタイムスタンプをローカル時刻のまま格納するため、UTC化した Windows でフォーマットした USB メモリや SD カードを別の（UTC化していない）Windows マシンに挿すと、ファイルの更新時刻が-9時間ズレて見えることがある。NTFS や最近の exFAT 実装では問題ない。クラウド経由のやり取りが主なら実害はゼロ。
影響しないもの
よく心配されるが実は大丈夫なもの。
- タスクスケジューラ
- イベントログの時刻
- NTFS のファイル更新日時表示
- Windows Update やメンテナンスのスケジュール
- Outlook の予定
- WSL2 ゲスト OS の時刻
これらは全てシステム時刻（タイムゾーン適用済み）ベースで動くため、UTC化の影響を受けない。
トラブルシューティング
Windows の時刻が大きくズレた場合
25.10 運用中に一度やらかしたケース。「21時なのに Windows が6時を示している」という症状が出た。
原因は、RTC 切り替え時に Ubuntu 側の chrony がまだ NTP 同期を完了していなかったため、不正確なシステム時刻がそのまま RTC に書き込まれたこと。つまり「ステップ3を飛ばした」ときに起きる。
応急処置は以下。
# 管理者 PowerShell で手動設定（日時はスマホなどを見て実際の現在時刻を手打ちしてください）
Set-Date -Date (Get-Date "2026-04-23 21:35:00")
# その後 NTP 同期先を設定して同期
w32tm /config /manualpeerlist:"ntp.nict.jp,0x8" /syncfromflags:manual /update
Restart-Service w32time
w32tm /resync /force時刻が合えば Windows が正しい UTC を RTC に書き戻してくれるので、次回起動からは正常化する。
w32tm /resync で「時刻データが利用できなかったため〜」と出る
システム時刻のズレが大きすぎて NTP の許容オフセットを超えている可能性が高い。上記の Set-Date で手動補正してから再度 w32tm /resync /force を試す。
まとめ
25.10 から 26.04 LTS への移行を機に、デュアルブート時刻問題を Windows 側で片付けた話でした。要点を整理すると、
- デュアルブート時刻ズレの根本原因は Windows と Linux の RTC 解釈差で、これはchrony化以前から存在する古典的な問題
- Ubuntu 25.10 以降は chrony デフォルト化に伴い、従来の回避策（
set-local-rtc 1）が効きにくくなった rtcsyncをコメントアウトして凌ぐ方法もあるが、パッケージ更新で戻るリスクと、クリーンインストールのたびに同じ作業をする不毛さがある- LTS は5年の前提なので、Windows 側の
RealTimeIsUniversalをDWORD=1に設定して Linux デフォルトに任せる構成のほうが結果的に楽 - 作業順序は「Ubuntu で RTC を UTC に揃える → chrony の NTP 同期完了を確認 → Windows でレジストリ設定 → 完全シャットダウン」
- 実用上の副作用は小さいが、BIOS/UEFI 画面の時刻表示や FAT/exFAT のタイムスタンプには一応注意
26.04 LTS のクリーンインストール前後は、構成を整理する絶好のタイミングだと思う。5年使うなら、5分の手順を一度やっておく価値は十分あるという判断でした。
コメント