はじめに
システム運用において「時刻の正確さ」は、障害解析・セキュリティ監査・ログ相関のすべてに直結する重要要素です。
本記事は、４大クラウド（AWS/Azure/GCP/OCI） における時刻同期とタイムスタンプの扱いを、日本の現場で実際に困りやすい論点（UTC と JST、うるう秒、ログの保存と表示）に焦点を当てて整理しました。
なお、各社の細部仕様（内部 NTP の実装、うるう秒の扱いなど）は随時更新されうるため、最終判断は必ず公式ドキュメントで確認してください。
1. クラウド基盤における時刻同期の基本（要点サマリ）
| 観点 | 要点 | 実務ヒント |
|---|---|---|
| 基盤 | VM はハイパーバイザーの クロックに同期して起動される |
初期値は概ね正しいが、稼働中の ドリフト対策に NTP 必須 |
| NTP 補正 | 各クラウドは内部ネットワーク 到達の時刻サービスを提供 |
外部公開 NTP より内部提供を優先 （レイテンシ・到達性・ セキュリティ） |
| 保存と表示 | 保存は UTC、表示は JSTが原則 | 調査・監査は UTC、現場オペは JST 表示に切替 |
| うるう秒 | 方式は事業者により異なる | 分散トレースや金融系は方式差での ズレに注意、公式確認が安全 |
うるう秒で出てくるスミア（leap smear/Smearing）とは、うるう秒を“1秒まるごと追加”せず、前後の一定時間に“薄く伸ばして配る”方式です。
2. ４大クラウドの時刻同期サービス（俯瞰）
内部提供の時刻サービスはすべてあります。
代表アドレスは例示のみとしていますので、実運用は各社最新の推奨に合わせてください。
| クラウド | 代表的な到達方法/ アドレス（例） |
OS 側の典型 設定ツール |
備考 |
|---|---|---|---|
| AWS | NTP（169.254.169.123 / fd00:ec2::123）はリープ秒 をスミア PTP ハードウェアクロックは スミアなし（=UTCの1秒挿入） 混在は非推奨 |
chrony / ntpd /Windows Time |
VPC 内から到達可 |
| Azure | ホスト時刻同期（既定） 必要に応じ外部NTP 併用設計に注意 |
chrony / ntpd /Windows Time |
ゲスト時刻サービスと NTP の併用設計に留意 |
| GCP | metadata.google.internal （外部IP不要） リープ秒は12時間前後の 計24時間でスミア 外部NTPと混在禁止 |
chrony / ntpd /Windows Time |
Google 提供の時刻源 または推奨経路を利用 |
| OCI | 169.254.169.254/UDP123 |
chrony / ntpd /Windows Time |
リージョン設計と 到達経路を事前確認 |
3. UTC と JST（日本の実務での落とし穴）
| 観点 | 推奨/方針 | 理由 | リスク/補足 |
|---|---|---|---|
| ログの基準 | 保存は UTC | リージョン横断 での相関・監査 に必須 |
JST 保存のみだと 海外拠点・他 SaaS と突合が難 |
| 画面表示 | 運用画面は JST 表示 | 現場オペの即時性・ 可読性 |
UI でタイムゾーン 切替を設ける |
| 集計・分析 | DW/DL は UTC 統一 | 集計の一貫性・ 再現性 |
可視化層でのみ JST |
| 監査証跡 | UTC 固定・改変不可 | 法規・証跡要件 | 署名/ハッシュで 改竄対策 |
| 相互照合 | タイムゾーン明記 | 工数削減・誤読防止 | ダッシュボード凡例 に TZ を表示 |
4. ログ運用チェックリスト（現場でそのまま使える）
| 項目 | 推奨状態 | 確認方法 | 備考 |
|---|---|---|---|
| 収集基準 時刻 |
UTC で格納 |
スキーマ/ テーブル定義 |
・PostgreSQL：TIMESTAMP WITH TIME ZONE（= timestamptz） ・SQL Server：datetimeoffset ・BigQuery：TIMESTAMP は 常に UTC、DATETIME はTZなし ・MySQL：TIMESTAMP は UTCで保存し入出力時に セッションTZで変換、 DATETIME はTZ無関係 |
| 表示時刻 | 役割別に切替 （JST/UTC） |
ダッシュボード 設定 |
ユーザー毎 既定 TZ |
| NTP 参照先 | クラウド内部 提供に統一 |
構成管理・CMDB | 例外は申請制 |
| うるう秒 方針 |
方式と影響範囲 を明記 |
設計書・運用手順 | 事前リハーサル 必須 |
| 相関 ID | 追跡用 ID で連鎖 | ログ設計・APM | 時刻誤差を補う 横串軸 |
5. 最小設定スニペット（例）
実環境では各社の最新推奨・セキュリティ方針を優先。以下は「方針の型」を示す最小例です。
Linux（chrony）
# /etc/chrony.conf
server 169.254.169.123 iburst prefer # AWS の例。（AWS=169.254.169.123 / GCP=metadata.google.internal / OCI=169.254.169.254 / Azure=原則ホスト同期、外部NTPを使うならそのFQDN）
# server <provider-internal-ntp> iburst
driftfile /var/lib/chrony/drift
makestep 1.0 3
rtcsync
Windows
# 管理者で実行。内部提供のアドレスに置換
# AD ドメイン参加環境では原則メンバーサーバーに手動ピアを入れず、フォレストルートPDCのみに外部NTPを設定
w32tm /config /syncfromflags:manual /manualpeerlist:"169.254.169.123" /update
w32tm /resync /force
6. うるう秒と分散トレース（方式差を前提に設計）
| 項目 | 何が起きるか | どう備えるか |
|---|---|---|
| うるう秒の 挿入/平滑化 |
一時的に時刻が「進む/戻る」 「ゆっくり平滑化される」 など方式差が出る |
事業者の方式を公式で確認し、 重要バッチ・ジョブの停止/ 緩和策を準備 |
| ログ順序の 乱れ |
ミリ秒～秒オーダーで 前後の可能性 |
相関 ID と 単調増加の論理時刻 （例：カウンタ）を併用 |
| 金融/約定の タイムスタンプ |
規制・約定時刻が 監査対象 |
UTC 固定・改変不可、 署名・ハッシュで保全 |
「どのクラウドがどの方式か」は変更される可能性があるため、最新版の公式情報で都度確認してください。
7. なぜ？を5回で深掘り
| なぜ？ | 答え | 示唆 |
|---|---|---|
| 時刻同期が重要？ | ログ相関・監査・障害復旧の 起点だから |
NTP と保存時刻の 標準化が最優先 |
| 保存は UTC？ | リージョンや SaaS 横断で唯一の 共通基準だから |
DW/DL は UTC 固定、 UI で変換 |
| 表示は JST も必要？ | 日本の現場オペは直感的で迅速に 判断できるから |
役割別既定 TZ と切替機能を実装 |
| 内部提供 NTP を使う？ | レイテンシ・可用性・到達性・ セキュリティで有利だから |
外部 NTP は例外運用 に限定 |
| 方式差（うるう秒）を 気にする？ |
分散トレースや約定時刻に 影響するから |
方式の公式確認＋ 事前リハーサル |
8. 仮説 → 根拠/データ → 再検証 → 示唆・次のアクション
| フレーム | 内容 |
|---|---|
| 仮説 | クラウドの時刻同期仕様を理解し、保存 UTC/表示 JST を徹底 すれば、障害解析と監査対応のリードタイムを大幅短縮できる |
| 根拠/データ | 内部提供 NTP の到達性・レイテンシ優位、UTC 統一での 相関容易性、うるう秒方式差による乱れの実例 （※各社公式・社内事例で要確認） |
| 再検証 | 本番相当の時刻イベント（うるう秒想定・クロックドリフト 注入）で演習し、ダッシュボードの TZ 切替や相関 ID 追跡を検証 |
| 示唆・次アクション | ①NTP 参照先の標準化（内部提供に統一） ②スキーマを UTC 固定 ③可視化層の TZ 切替 ④方式差に関する設計注記と年次リハーサル |
付録：導入時の意思決定テンプレ（１枚）
| 決めること | 選択 | 根拠 | 例外運用 |
|---|---|---|---|
| NTP 参照先 | 内部提供に統一 | 可用性・レイテンシ・到達性 | 外部は申請制 |
| 保存 TZ | UTC 固定 | 相関・監査の基準 | なし |
| 表示 TZ | 役割別に JST/UTC | 運用効率 | ユーザー上書き可 |
| うるう秒 | 公式方式を踏襲 | 方式差での乱れ回避 | 年次リハ実施 |
おわりに
「時刻」は見えないインフラですが、設計時に１つ決めておくだけで後工程の混乱を激減できます。
本記事の要点は、「内部提供 NTP の活用」「保存は UTC・表示は JST」「方式差は公式で都度確認」といったところです。
ここまで決めておけば、あとは各プロダクトの実装に落とすだけです。
時間を操り、正しく理解しやすい情報としてタイムスタンプを活用していきましょう。