タイマー依存バグ ― OSクロックとゲームロジックのズレ

ゲームの世界では「時間」がすべての基準となる。物理演算、アニメーション、ネット同期――そのどれもが正確なタイミングに依存している。しかし実際の環境では、OSクロックの補正やスリープ復帰、電源制御によって時間の流れが微妙に揺らぐ。そのわずかなズレが、キャラクターの瞬間移動や物理の暴走といった「タイマー依存バグ」を生む。

本稿では、この見えにくい時間の歪みと、OSクロックとゲームロジックの齟齬が生じる仕組みを体系的に解説する。

第1章　タイマー依存バグの分類とメカニズム

1-1 定義とスコープ

「タイマー依存バグ」とは、時間計測やスケジューリングの誤差・不一致によって、ゲームロジックが意図しない挙動を示す不具合の総称である。多くの場合、開発段階では正常に動作しているように見えるが、異なるハードウェア環境・電源モード・OSバージョンで実行すると挙動が変わり、フレーム更新の乱れやアニメーションの不整合、さらにはネットワーク同期の破綻などを引き起こす。
このバグは、いわゆる「フレームレート依存バグ」とは異なり、時間の測定基準そのものが揺らぐ点に特徴がある。つまり、どれほど処理負荷を調整しても、「どの時計を信じるか」という設計を誤ると再発する。本章では、時間の種類とその構造を理解し、ズレが発生する理屈を整理する。

1-2 タイムソースの種類と特性

ゲームやOSが利用する「時間」には、複数の定義が存在する。主なものは次の3種類である。

Wall Clock（リアルタイム）

現実世界の時刻を示す時計であり、NTP（Network Time Protocol）やユーザー手動調整によって補正される。
そのため、時間が突然進んだり戻ったりする可能性がある。ゲーム内でこれを使用すると、クールダウンやイベントスケジュールが一瞬で完了する、あるいは永遠に終わらないといった現象が起こり得る。

NTP は通常 “slew（なだらかな補正）” を優先するが、手動変更・異常系・仮想化環境などで“ステップ変更（瞬間ジャンプ）”が発生することもある【5】。このため、ロジック制御に Wall Clock を混在させる設計は避けるのが原則である。

Monotonic Clock（単調増加クロック）

Monotonic Clockとは、システム起動からの経過時間を測定する時計であり、時間が**常に単調増加（減少しない）**することを保証する。一般にゲームロジックのタイミング制御はこの時計を基準に設計されるべきである。

各OSにおける代表的な実装は次の通りである：

• Windows：QueryPerformanceCounter (QPC)
• Linux：CLOCK_MONOTONIC
• macOS / iOS：mach_absolute_time

---

1. 各プラットフォームの挙動

Windows：QPC（QueryPerformanceCounter）

• 起動時に周波数が固定され、稼働中は変化しない。
• QueryPerformanceFrequency() は起動直後に一度だけ取得し、キャッシュして使うことが推奨されている【2】。
• スタンバイや休止（スリープ）中も時間が進む仕様だが、Microsoft公式文書では明示的に断定されていない。
  　→ そのため、スリープ復帰直後に異常に大きな Δt（経過時間差）が観測される可能性がある。
  　→ 実運用では、クランプ（値の上限制限）やウォームアップ処理を導入して補正するのが安全である【2】。
  

Linux：CLOCK_MONOTONIC / CLOCK_MONOTONIC_RAW / CLOCK_BOOTTIME

• CLOCK_MONOTONIC は単調増加するが、**NTPの “slew” 補正（時刻の微調整）**の影響を受ける可能性がある。
• CLOCK_MONOTONIC_RAW はこの外部補正を受けず、純粋なハードウェア時間を返す【3】。
• さらに CLOCK_BOOTTIME はスリープ中も時間が進むため、復帰直後のΔt挙動を制御しやすい。
  　→ 用途に応じて、CLOCK_MONOTONIC／CLOCK_MONOTONIC_RAW／CLOCK_BOOTTIME を選択するのが望ましい【3】。
  

macOS / iOS：mach_absolute_time と mach_continuous_time

• mach_absolute_time は スリープ中は進まない。
• 一方、mach_continuous_time は スリープ中も進む【4】。
• macOS の clock_gettime() 体系では以下の対応関係がある：

API名	スリープ中の挙動	概要
CLOCK_UPTIME_RAW（≒mach_absolute_time）	進まない	起動後の稼働時間を純粋に測定
CLOCK_MONOTONIC / mach_continuous_time	進む	システム全体の経過時間を測定

Apple公式文書間では表現の揺れが見られるが、本稿ではDarwinの仕様（上記の対応）に基づいて整理する【4】。

---

2. 運用上の指針

• スリープを挟む環境（例：ノートPC、モバイル）では、
  　→ スリープ時間を含む時計（CLOCK_BOOTTIME／mach_continuous_time）の使用を検討する。
• 高精度な物理時間差が重要な用途（例：物理シミュレーション）では、
  　→ 外部補正の影響を排除できる CLOCK_MONOTONIC_RAW を優先する。
• 復帰直後の異常値対策として、Δtにクランプ処理やウォームアップ期間を設ける。

---

Monotonic Clock は、「時間が巻き戻らない」ことを保証する基準時間源であり、
その実装差はスリープ・NTP補正・外部同期の扱いに現れる。
したがって、クロスプラットフォーム設計においては、
「どの時間を含めるべきか（スリープを含むか否か）」を明示的に選択し、
Δt（経過時間）の異常挙動を前提とした防御的設計を行うことが重要である。

High-Resolution Timer（高分解能タイマ）

**高分解能タイマ（High-Resolution Timer）**とは、非常に短い時間単位（マイクロ秒〜ナノ秒オーダー）で経過時間を精密に計測できるタイマである。
物理演算・アニメーション補間・入力遅延測定など、フレーム単位より細かい時間制御を必要とするゲーム開発やシミュレーションで不可欠の仕組みである。

---

1. OSごとの特性と設計上の注意点

Windows環境

• Windowsでは、システム全体のタイマ分解能を変更するAPIとして timeBeginPeriod() が用いられる。
• この設定変更は、システム全体のタイマ精度・スケジューラ挙動・電力消費に影響するため、
  　→ 設定と解除を対で行い、必要最小限の期間だけ有効化する設計が推奨される【2】。
• Windows 10 version 2004 以降では、timeBeginPeriod() の影響範囲が原則プロセス単位に限定されたが、
  　→ それでも不要な常時設定は避け、フレームワーク側で自動管理される場合でも明示的に制御するのが望ましい【2】。

Linux / macOS環境

• Linux や macOS では、clock_gettime() における CLOCK_MONOTONIC などの高精度クロックが主に利用される。
• これらはシステムのタイマ分解能設定を直接変更する仕組みを持たないが、スリープ中の挙動（進む／止まる）やNTP補正の影響範囲は時計種別によって異なる（詳細は Monotonic Clock の節を参照）。

---

2. 実行環境による挙動差

ブラウザ環境（Web API）

• Webブラウザでは、performance.now() がモノトニックで高精度な時間源として利用できる。
  　一方、Date.now() はNTPや手動調整による“実時刻”の影響を受けるため、時間計測には適さない【7】。
• また、バックグラウンド（非アクティブ）タブではタイマや rAF（requestAnimationFrame）が強くスロットルされる。
  　→ 一部環境では “1fps” 程度に落ち込むこともあるが、ブラウザ・バージョン・電源状態によって異なるため、固定値として断定しないほうが安全である【7】。

仮想環境（Virtual Machine / Sandbox）

• 仮想マシンやサンドボックスでは、ホストOSのクロック精度・電源制御ポリシーに依存して、
  　高分解能タイマが低精度化または不安定化する場合がある。
• 特にクラウドやブラウザベースのゲーム実行環境では、**「同じAPIを使っても計測精度が異なる」**という前提を理解しておく必要がある。

---

3. 運用上のベストプラクティス

1. 必要な期間のみ高分解能を有効化する
   　電力消費やスケジューラ負荷を抑えるため、フレーム処理やベンチマークなど限定的な用途に絞る。
2. モノトニックな時間源を使う
   　NTP補正やシステム時刻変更の影響を受けないAPI（例：performance.now()、CLOCK_MONOTONIC）を選択する。
3. 環境差を吸収する抽象化層を設ける
   　スリープ・バックグラウンド・仮想環境の差を吸収するため、統一的な時間取得モジュールを設計する。

---

高分解能タイマは、時間の「粒度」そのものを制御する低レベルの仕組みであり、その挙動はOS・ブラウザ・電源管理・仮想化層によって大きく異なる。「高精度であること」と「常に安定していること」は同義ではない。
したがって、開発者は時間APIの背後にあるクロック源の性質を理解し、**必要な場面にのみ精度を上げる「節度ある設計」**を行うことが重要である。

1-3 代表的な発生パターン

deltaTimeスパイク（経過時間の跳ね）

一時停止やスリープ復帰、NTP補正などで1フレーム分のdeltaTimeが極端に大きくなる。これにより、キャラクターが急にワープしたり、物理演算が発散する。
例えるなら、「1秒ごとに少しずつ進めるはずの時計が、突然30秒進んだ」ようなものである。

フレームペーシングの崩れ

VSyncや省電力制御によってフレーム生成間隔が一定でなくなり、アニメーションがカクつく。
OSスケジューラのタイムスライス（通常10～16ms）がGPUの描画完了タイミングと合わない場合にも発生する。

固定ステップと可変ステップの混在

物理演算を固定ステップで、アニメーションや入力を可変ステップで更新する設計において、経過時間の誤差が累積して同期ズレを生む。
数フレームの誤差が1分後には数秒の違いになることもある。

タイムアウト誤作動

タイマベースのリトライやエフェクト制御が、スリープ中のタイマ遅延によって異常終了する。
特にモバイルOSのバックグラウンド処理では、タイマが意図的に遅延または統合される（Timer Coalescing）ため、時間が“圧縮された”ような挙動を示す【6】。
（補足：Android では主に Doze / App Standby による遅延・バッチングの影響として現れる【6】。iOS / macOS の「Timer Coalescing」という用語と区別して捉えると実装判断が明確になる。）

ネット同期の不整合

クライアントごとに異なるクロックを参照していると、補間・巻き戻し（ロールバック）処理の基準がズレ、プレイヤーの位置が瞬間移動する。この問題は、サーバ権威モデルでも発生しうる。

1-4 症状から見る兆候

タイマー依存バグは、目に見える現象として多様に現れる。典型的な症状には次のようなものがある。

• 物理演算の振動や跳ね返りの異常（トンネル化）
• アニメーションの瞬間的な飛びやカクつき
• クールダウンやバフ時間の異常な短縮・延長
• 同期ゲームにおける巻き戻り・テレポート現象
• サウンド再生やエフェクト発火の一斉発生・無音化

これらの多くは、フレーム単位ではなく時間基準の誤差から生じている。つまり、CPUやGPUの性能差ではなく、どのクロックが“真の時間”として扱われているかに根本原因がある。
タイマー依存バグは再現が難しく、一見ランダムな現象に見えるが、次章で示すように、実験的に再現・観察できる構造的な問題である。

---

第2章　検証的知見：再現可能な実験デザイン

2-1 シミュレーション設計（Empirical Approach）

タイマー依存バグは偶発的に見えるが、条件を統制すれば再現可能である。本節では、時間のズレを意図的に発生させる検証設計を紹介する。目的は「理論的理解」ではなく、現象を数値とログで観察できる状態にすることにある。
再現実験では、以下の三つの変数を操作する。

• deltaTime（フレーム経過時間）のスパイク注入
  例：通常16.6msのところに、人工的に300msの遅延を挿入。
  → 物理エンジン（例：Box2D, Bullet）ではオブジェクトが瞬間移動、または貫通現象（トンネル化）が発生。
  
• クロックドリフトの注入
  例：1分あたり+50ppm（parts per million）の誤差を仮想的に加算。
  → 数十分後にアニメーションやタイマーイベントのズレを観測可能。
  
• クロックジャンプの模擬
  例：実行中にOSのWall Clockを±5分変更。
  → std::chrono::system_clock 利用コードが即座に「過去に戻る」または「未来に飛ぶ」現象を示す。
  この操作により、時間依存ロジック（例：ログ保存、バフ更新）が誤発火する様子を観測できる。
  補足（表現の精緻化）：実運用の NTP は通常 “slew” を用いるが、手動変更や異常系ではステップ変更が起こり得ることを前提にテストケースを設けると再現性が上がる【5】。

また、モバイルではスリープ／レジューム操作を挟み、サスペンド中に発火予定だったタイマが「再開直後に連続発火」するケースも検証対象に含める（Doze/App Standby 等の影響）【6】。

2-2 計測指標の設定

再現実験では、バグの有無を感覚的に捉えるのではなく、時間系列データとして定量化することが重要である。主な指標は以下の通り。

指標	意味	典型的な観察対象
フレームジッタ (Frame Jitter)	フレーム間隔の揺らぎ。p95/p99を評価。	可変fpsループ、VSync制御
シミュレーション遅延 (Simulation Lag)	入力から描画反映までの遅延時間。	ネット同期・補間処理
deltaTimeスパイク頻度	1フレームで閾値超過（例：>50ms）した回数。	スリープ・GC・NTP補正
イベント遅延時間	タイマ発火の予定時刻との差。	クールダウン・リトライ制御
ロールバック頻度	ネット同期で巻き戻しが発生した割合。	対戦・協力ゲーム
エネルギー保存誤差	物理演算での運動量/エネルギー保存率。	固定ステップ検証

これらの数値は、理論値との差分として評価する。たとえば、60fpsを目標とした場合、理想Δtは16.6ms。これに対し平均値が16.7msであっても、標準偏差が大きい（>2ms）ならば、アニメーション上の不安定さが顕在化する。

2-3 観察と解釈（再現事例）

可変ステップ物理の発散

deltaTimeスパイクを挿入した場合、積分ステップが一気に進み、速度計算が暴発。
→ 観察結果: 0.5秒スパイクでオブジェクトの位置誤差が5倍に増幅。
→ 解釈: 可変Δt物理は、時間変化を線形と仮定するため、非線形力学では誤差が急増。

NTPジャンプによるタイマ誤発火

実行中に時刻を5分戻すと、system_clock を使用するスケジュールイベントが即時キャンセル。
→ 観察結果: クールダウン中のスキルが「再使用可能」と誤判定。
→ 解釈: Wall Clockベースの時刻計算が「未来のイベント」を過去に移動させた。

背景化によるイベント密集

モバイル端末をスリープし30秒後に復帰。OSがTimer Coalescingを行い、休止中のイベントが連続発火。
→ 観察結果: ゲーム再開直後に複数の敵出現やSE同時再生。
→ 解釈: イベントキューの「一括処理」挙動を想定していない実装。
（補足：Android では Doze/App Standby による遅延・バッチングが主因であり、iOS/macOS の Timer Coalescing とは経路が異なるが、結果の現れ方は類似する【6】。）

スロットリング下での描画カクつき

Chromeブラウザにおいてバックグラウンドタブ化時、requestAnimationFrame が強くスロットル（環境により停止・低頻度化）。
→ 観察結果: 再アクティブ化直後、内部時間と描画時間が乖離し、アニメが一瞬進みすぎる。
→ 解釈: 実行間隔が物理Δtに比例せず、補間処理がオーバーシュート【7】。

これらは異なる条件に見えるが、根底には「参照している時間源の非一貫性」がある。つまり、時間の指標が揺れる限り、上層のロジックは必ず誤作動する。

2-4 データの可視化と評価方法

数値データを視覚的に把握することで、バグの本質が明確になる。以下は推奨される可視化手法である。

• ヒストグラム（deltaTime分布）
  平均付近に鋭いピークを持ちつつ、右方向に長い裾野（スパイク）がある場合、スリープ復帰やNTP補正の影響が疑われる。
• タイムラインプロット（経時変化）
  フレーム番号を横軸、Δtを縦軸に取ると、一定間隔で周期的なスパイクが確認できる。OSスケジューラの断続的介入を示唆。
• 箱ひげ図（プラットフォーム比較）
  Windows, Linux, Android, iOSなどでΔtの分散を比較。
  → AndroidはDozeモードで中央値が延び、Linuxは安定。
  こうした比較により、OSレベルのタイマ精度差を定量評価できる。
• クロック差分グラフ
  Wall ClockとMonotonic Clockの差を時系列で描くと、NTP同期による「瞬間的なジャンプ」や“slew”の痕跡が視覚化される。
  たとえば、1時間あたり数十ミリ秒の「時計修正」が繰り返されていることが確認できる。

これらの可視化は、ゲームエンジン内部のログまたは外部ツール（例：Grafana, RRDTool）を用いて容易に実現できる。重要なのは、「時間を測る対象」ではなく、「時間そのものの安定性」を測るという視点である。

2-5 再現条件のまとめ（実務向けチェックリスト）

テスト項目	操作内容	想定される影響
NTP同期（±数分）	システム時刻を調整	Wall Clock参照コードが誤発火
サスペンド／レジューム	スリープ→再開	deltaTimeスパイク発生（※OSによりスリープ中の経過の扱いが異なる）
CPUスロットリング	高負荷＋温度制御	VSync間隔の変動
VRR切替（60↔120Hz）	ディスプレイ設定変更	フレームペーシング乱れ
背景化／復帰	モバイルアプリ最小化	イベント一括発火
GC強制発生	メモリ逼迫テスト	一時的フリーズによるΔt跳ね

これらの条件を組み合わせることで、現場で再現しにくいタイマー依存バグを安定的に観察できる。特にQA工程では、テスト対象を「時間環境」として扱う発想が重要である。

2-6 小結：時間の「揺らぎ」は制御可能である

ここまでの実験から明らかになるのは、タイマー依存バグは「不可避のノイズ」ではなく、観測と設計で制御可能な系だという点である。OSクロックの挙動は乱数ではなく、電源・省電力制御・同期ポリシーという決定論的要因に支配されている。
次章では、この知見を踏まえ、ズレを前提とした堅牢な時間設計の原則を体系化する。そこでは、クロック選定、固定ステップ、補間、クランプといった実践的な技法を中心に論じる。

第3章　設計原則：ズレを前提とした時間設計

3-1 クロック選定の基本方針

タイマー依存バグの根源は、「どの時間を信じるか」の設計にある。したがって、最初に確立すべきは時間源（Time Source）の分離と明示化である。

ゲームロジック用クロック（Monotonic Clock）

絶対時刻ではなく「経過時間」を測定する。NTP補正や時刻変更の影響を受けず、単調増加が保証される。
実装例：

• Windows：QueryPerformanceCounter()（QPC）
• Linux：CLOCK_MONOTONIC または CLOCK_MONOTONIC_RAW【3】
• macOS / iOS：mach_absolute_time()【4】
• ブラウザ：performance.now()【7】

補足（精緻化）：Linux の CLOCK_MONOTONIC は NTP の“slew”の影響を受け得る一方、CLOCK_MONOTONIC_RAW は外部補正の影響を基本的に受けない。Windows の QPC はブート時に周波数が確定し稼働中は不変であるため、QueryPerformanceFrequency は起動時に一度取得してキャッシュする。さらに、QPC はスリープや省電力遷移の影響で復帰直後に大きなΔtが観測され得るため、クランプやウォームアップの対策が必要である（設計上の注意として明示するのが安全）。

UI・カレンダー用途クロック（Wall Clock）

現実世界と対応づける必要がある箇所（例：日付表示、ログ記録など）のみに使用。
ロジック制御に混在させると、NTP 同期や手動調整時に時刻が逆行するため危険である。

設計原則として、「ゲームの時間は常に Monotonic で流れ、UI だけが現実と結びつく」という構造を採用する。これは、ゲームが1つの仮想宇宙を形成し、その中では時間が外界と独立して進行する、という世界モデルに近い。

3-2 ゲームループ設計 ― 固定ステップと可変描画の分離

時間制御の中心となるのがゲームループ（Game Loop）である。多くのバグはここに潜む不整合から発生する。
基本方針は「物理シミュレーションは固定ステップ、描画は可変ステップ」である。

固定タイムステップ（Fixed Timestep）

物理演算や AI 更新など、決定的な結果を要する処理では、一定間隔（例：1/60 秒）で更新する。

while (running) {
    now = get_monotonic_time();
    delta = now - previous;
    previous = now;
    accumulator += delta;

    while (accumulator >= FIXED_DT) {
        update(FIXED_DT);
        accumulator -= FIXED_DT;
    }

    render(accumulator / FIXED_DT);
}

accumulator を使うことで、処理落ちがあっても物理時間の整合を保てる。

deltaTime クランプ

異常スパイクを防ぐため、Δt が閾値（例：0.05 秒）を超えた場合は上限を設ける。

delta = std::min(delta, 0.05f);

この単純な制約だけでも、NTP 補正やスリープ復帰時の暴走挙動を大幅に軽減できる。

フレームペーシング

レンダリング側では、VSync や VRR（可変リフレッシュレート）との整合性をとる。CPU が早すぎる場合、sleep_until() などで制御し、システムクロック粒度に応じた待機を行う。
これにより、描画負荷に左右されない「知覚上の時間安定性」を確保できる。

補足（Web/モバイルの挙動差）：ブラウザでは バックグラウンド時に requestAnimationFrame やタイマが強くスロットル（または停止）され得る。固定の“1fps”などと断定せず、復帰後の Δt クランプやウォームアップで吸収する。

3-3 タイマ・スケジューラ設計

時間管理のもう一つの要は、イベントスケジューリングである。
典型的な失敗は、system_clock（Wall Clock）を利用して未来のイベントを予約してしまうことだ。NTP 補正や OS 時間変更でイベントが過去扱いとなり、即時実行されることがある。

相対時間スケジューリング

常に**経過時間（relative time）**を基準にイベントを管理する。

struct Timer {
    double remaining;
    void update(double dt) {
        remaining = std::max(0.0, remaining - dt);
        if (remaining == 0.0) trigger();
    }
};

この設計なら、クロックジャンプやサスペンド復帰の影響を受けにくい。

タイマ管理構造

• Timer Wheel（時間を区切って効率的に発火管理）
• Min-Heap（最も早いイベントを先頭に維持）

どちらも「現在時刻」を Monotonic で更新することを前提に設計する。
OS のタイマスロットリング対策として、複数イベントのバッチ処理を許容し、多少の遅延を吸収できるようにするのが望ましい。

3-4 物理・アニメ・サウンドの時間整合性

異なるサブシステムがそれぞれ独自の時間を持つと、挙動のズレが拡大する。特に物理・アニメ・サウンドは同期性の確保が重要である。

物理エンジン

• 固定 Δt（例：1/60 秒）で更新。
• 一時停止やスパイク発生時はサブステップを使い補間。
• 高速移動体には**連続衝突検出（CCD）**を併用してトンネル化を防ぐ。

アニメーション

アニメーションは可変時間で再生されるが、補間係数（alpha = accumulator / FIXED_DT）を利用して、前回と次回の物理状態間を線形補間する。
スパイク発生時にはヒステリシス補間や指数平滑化を用い、滑らかさを維持する。例えるなら、揺れるカメラにダンパーを入れるように、時間変化を“緩衝”する設計である。

サウンド

オーディオ再生はしばしば**独立したクロック（Audio Clock）**で動作する。
ゲームクロックとの差分を定期的に計測し、**補正ストレッチ（Time Stretching）**をかけて同期を維持する。これにより、フレーム落ちや遅延でも音ズレを最小化できる。

3-5 ネットワーク同期の時間モデル

オンラインゲームでは、複数の端末間で時間を一致させる必要がある。しかし、すべてのデバイスが完全に同じ時刻を持つことは不可能である。ここで重要なのは、絶対同期ではなく一貫した相対時間を保つことである。

• サーバ権威モデルでは、サーバ時刻を基準にクライアント時刻を補正。
  → クライアントは「サーバ時間 − RTT/2」を基準に内部クロックを調整。
• ロールバック方式では、クライアントが入力と状態を一定期間（例：100ms）遅延させて送信し、過去の状態を再計算。
  → 巻き戻し可能な最大ウィンドウを物理 Δt に比例して設計する。
• 外れ値除去：NTP や ping 測定による時刻外れ値を、**中央値フィルタ（Median）**や IQR フィルタで平滑化。

つまり、ネット同期の目的は「全員が同じ時計を見る」ことではなく、**「異なる時計でも同じ出来事を同じ順序で扱う」**ことである。

3-6 防御的プログラミングと監視設計

ズレを完全に防ぐことは不可能であるため、検知と緩和の仕組みを組み込むことが実務的である。

• deltaTime スパイク検出ロジック：Δt が閾値を超えた場合に警告ログ。閾値はプラットフォーム別に調整。
• タイマ補正ログ：Monotonic と Wall の差分を定期的に出力。NTP 補正の瞬間が可視化できる。
• ウォームアップモード：スリープ復帰直後に数フレームを安定化期間として扱い、Δt を徐々に復帰。
• テレメトリの永続化：予期せぬカクつきが発生した際、直前 30 秒の Δt ログを送信する設計。
  → 運用段階での事後分析に役立つ。

3-7 小結：時間設計を「制御変数」として扱う

タイマー依存バグの防止は、単に API 選定の問題ではない。時間を設計要素のひとつとして明示的に制御する発想が必要である。
理想的な設計では、

• どの時間が使われているかを明示化（Monotonic / Wall 分離）
• Δt をクランプし、可視化する
• エベントを相対時間で駆動する
• サブシステム間で時間の一貫性を担保する

といった原則を実践することで、OS クロックや環境の違いを超えた安定したゲームロジックが実現する。
次章では、この設計原則を現場に適用するための実装スニペット・QA 手法・リスク管理を具体的に整理する。

---

第4章　実装・運用・QAの実務チェックリスト

4-1 実装スニペット：堅牢な時間管理の基本構造

ここでは、前章で述べた設計原則を実装レベルで具体化する。ポイントは、時間計測を一箇所に集約し、テスト・監視可能な構造にすることである。

固定ステップループの例（C++ 擬似コード）

constexpr double FIXED_DT = 1.0 / 60.0; // 60Hz
double accumulator = 0.0;
auto previous = get_monotonic_time();

while (running) {
    auto now = get_monotonic_time();
    double delta = std::min(now - previous, 0.05); // クランプ
    previous = now;
    accumulator += delta;

    while (accumulator >= FIXED_DT) {
        update(FIXED_DT); // 物理・AI更新
        accumulator -= FIXED_DT;
    }

    double alpha = accumulator / FIXED_DT;
    render(alpha); // 補間描画
}

• get_monotonic_time() は環境依存の高分解能タイマを抽象化したもの。
• Δt の上限をクランプし、スパイクに対して安定性を確保。
• alpha 補間により描画は滑らかに維持される。

このループ構造は、**Fiedler による「Fix Your Timestep」論文【1】**でも推奨されており、時間制御の定番設計である。

Monotonic タイムプロバイダの抽象化

class TimeProvider {
public:
    virtual double now() const = 0;
};

class SystemTimeProvider : public TimeProvider {
public:
    double now() const override { return get_monotonic_time(); }
};

// テスト時に差し替え可能
class MockTimeProvider : public TimeProvider {
    double t = 0.0;
public:
    void advance(double dt) { t += dt; }
    double now() const override { return t; }
};

これにより、単体テストで時間経過をシミュレートできる。ゲームループの再現試験や時間依存バグの再発確認を自動化しやすくなる。

4-2 プラットフォーム別の注意点

Windows

• 高精度クロックは QueryPerformanceCounter() を使用【2】。
• timeBeginPeriod() によるタイマ精度向上は電力消費増やシステム全体への影響に注意（必要期間に限定し、開始/終了を対で扱う）。Windows 10, version 2004 以降は原則プロセス単位で作用するよう整理されたが、最小限利用の基本は変わらない。
• QPC の周波数はブート時に確定し稼働中は不変。QueryPerformanceFrequency は起動時に一度だけ取得してキャッシュする。
• スリープや省電力遷移の影響で復帰直後の Δt が大きくなり得るため、復帰直後の Δt クランプは必須。

Linux

• clock_gettime(CLOCK_MONOTONIC) を基本とし、外部補正の影響を避けたい場合は CLOCK_MONOTONIC_RAW を検討【3】。
• CPU スリープ後の計測誤差を補正する仕組み（ウォームアップ/クランプ）を導入すると安定。
• ★補足（最小限の追記）：サスペンド中も進む単調時計が必要なケースでは CLOCK_BOOTTIME も選択肢となる。復帰直後のΔt挙動を用途に合わせて選び分けると良い。

macOS / iOS

• mach_absolute_time() を推奨【4】。
• **CADisplayLink は描画用クロック（UI 向け）**であり、物理ループと分離して扱うこと。
• バックグラウンド遷移時にタイマが停止するため、復帰時の Δt を必ずクランプする。
• スリープ中は mach_absolute_time が進まないため、復帰直後の差分が大きくなり得る点に留意。
• ★補足（最小限の追記）：スリープを含む単調時間が必要なら mach_continuous_time も活用できる（用途に応じて使い分け）。

Android

• Doze / App Standby によりタイマがスロットリングされる【6】。
• SystemClock.elapsedRealtimeNanos() を使用し、Wall Clock との差分を記録する。
• スリープ復帰直後は**ウォームアップフェーズ（3〜5 フレーム）**を設け、Δt を漸次復帰させる。

Web（ブラウザ）

• 時間取得は performance.now() を使用。Date.now() は NTP/手動調整の影響を受ける。
• **非アクティブタブでは setTimeout/requestAnimationFrame が強くスロットル（または停止）**されるため、復帰後の Δt 補正が必須【7】。

4-3 計測・ロギングの設計

タイマー依存バグを早期発見するためには、「時間の揺らぎを常に観測する」仕組みが欠かせない。

実装例（疑似コード）

double dt = now - prev;
if (dt > 0.05) {
    log_warn("Delta spike detected: %.3f sec", dt);
    spike_count++;
}

log_trace("dt=%.4f, monotonic-wall=%.4f",
          dt, get_wall_time() - get_monotonic_time());

• スパイク検知ログ：閾値超過を警告。
• クロック差分ログ：NTP 補正などで時刻が変化した瞬間を検出。

直前 30 秒の Δt ヒストリーを記録しておくと、クラッシュ後の分析が容易になる。
さらに、テレメトリを活用して統計的に異常傾向を検出（例：平均 Δt ＋ 3σ 超過）すれば、リリース後も自動監視が可能である。

4-4 QA 再現レシピ

再現困難なタイマー依存バグを検出するには、環境変数を意図的に揺らすテストが有効である。QA 向けの基本手順を以下に示す。

テスト項目	手順	期待される現象
NTP 補正	実行中にシステム時刻を ±5 分変更	Wall Clock 依存コードの誤発火
サスペンド／レジューム	スリープ後に復帰	deltaTime スパイク、物理暴走
CPU スロットリング	高温状態でクロック制御	フレーム間ジッタ
VRR 切替	ディスプレイを 60Hz ⇔ 120Hz へ変更	ペーシング乱れ、補間誤差
タブ非アクティブ	Web で別タブへ切替	描画停止、復帰後ジャンプ
バックグラウンド復帰	モバイルアプリの最小化→復帰	イベント密集発火

各テストでは、Δt ヒストグラム・ジッタグラフ・エネルギー保存率を測定する。
また、QA 工程では「再現できない＝発生していない」とは限らないため、ログに残る時間異常を重視して判定することが望ましい。

4-5 リスクアセスメントとフェイルセーフ

運用段階では、バグが発生しても致命的にならないよう、安全策を組み込むことが求められる。

時間依存クリティカル領域の明確化

例：クールダウン、報酬配布、ランキング集計、課金ロジック。
これらは Wall Clock 基準で管理されることが多く、NTP 補正による巻き戻りの影響を受けやすい。

安全な既定値の設置

• Δt が異常に大きい場合、上限でクランプ。
• タイマが誤作動した場合、**デフォルト遅延（例：100ms）**を挿入。
• タイムアウト計測では**上限＋安全係数（例：1.2 倍）**を設定。

フェイルセーフ機構

例：物理エンジンが不安定化した際に、一時的に固定 60Hz にフォールバック。
→ ユーザー体験を維持しつつ、再計測を待つ構造。

自動緩和ロジック

実行中にスパイクが検出された場合、一定期間の平均 Δt にスムージング補正をかける。
これにより、スリープ復帰や負荷変動時のショックを和らげることができる。

4-6 運用監視とテレメトリ分析

時間管理はリリース後も劣化しうる。特に、OS アップデートやハードウェア変更が影響を与える可能性があるため、運用監視体制を整備することが重要である。

リアルタイム監視ダッシュボード

• 平均 Δt・p95/p99 ジッタ
• クロックジャンプ頻度
• OS 別タイマ精度ランキング
  → これらを Grafana などで可視化し、長期的トレンドを追跡。

自動異常検出

学習モデルや統計分析により、特定バージョン・デバイス・OS での異常パターンを検出。
→ QA 前に早期アラートを発報できる。

A/B テストによるクロック手法比較

CLOCK_MONOTONIC vs CLOCK_MONOTONIC_RAW など、異なるタイムソースの挙動を定量比較し、最適な設定を継続的に更新する。

4-7 小結：時間を「品質保証の対象」とする

タイマー依存バグは、コードロジックだけでなく、OS やハードウェアの設計にまで及ぶ複合的な問題である。したがって、**時間そのものを品質指標（Quality Metric）**として扱う姿勢が必要である。

本章で示したように、

• Monotonic クロックの統一、
• Δt クランプ＋ロギング、
• QA 環境でのクロック揺らぎ再現、
• 運用中のテレメトリ監視、

という一連の工程を確立することで、タイマー依存バグは予測可能で可視化されたリスクに変わる。
次章（結論）では、こうした実践知を整理し、開発組織として「時間の信頼性」をどう確立すべきかを総括する。

第5章　結論：時間の信頼性を設計するという発想

5-1 要約 ― ズレは「欠陥」ではなく「設計変数」である

本稿で扱った「タイマー依存バグ」は、単なる実装ミスではなく、時間という物理的制約を正しく扱えていない設計上の問題である。OSクロックの補正、電源制御、スリープ復帰、NTP同期――これらはすべて環境が持つ自然な挙動であり、バグではない。
つまり「ズレ」は避けるものではなく、前提として設計に織り込むべき変数である。

本稿を通じて導いた主要な要点は以下のとおりである。

• 時間源の分離と明示化
  ゲームロジックは Monotonic Clock を使用し、UI のみ Wall Clock に依存させる。
• 固定ステップ＋可変描画の設計
  Δt をクランプし、物理・AI 処理を決定論的に制御する。
• 相対時間によるイベント管理
  絶対時刻に依存しないスケジューリングで、NTP やスリープの影響を排除。
• 検知・可視化・テレメトリ
  deltaTime スパイクを記録し、時間の安定性を品質指標として監視。
• QA 再現と運用監視の統合
  テスト環境でクロック揺らぎを再現し、運用段階で長期的傾向を追跡する。

これらの原則を実装段階から組み込むことで、「偶発的バグ」と見なされてきた時間異常を、予測可能で管理可能な現象へと変換できる。

5-2 開発プロセスへの提言 ― 「時間品質保証（Time QA）」の導入

近年のゲームは、マルチプラットフォーム化・オンライン常時接続化により、時間の一貫性が新たな品質軸となっている。特に、ネット同期型タイトルでは、クライアント間のわずかな時刻差がゲーム進行そのものに影響を与える。
従来の QA はビジュアル・動作・メモリ・ネットワーク安定性を対象としてきたが、今後は**時間品質（Time Consistency）**を新たな検証項目に加える必要がある。

具体的には以下の3層を提案する。

• 設計層（Design QA）：
  クロックポリシーを設計ドキュメントで明示化し、使用 API を標準化する。
• 実装層（Code QA）：
  system_clock などの使用箇所を自動検出し、コードレビューで Monotonic 利用を強制。
• 運用層（Telemetry QA）：
  実行中の Δt 分布・スパイク率・クロック差分を常時監視し、閾値超過を自動検知。

このように、時間を機能的依存ではなく品質的依存として管理することで、ゲームの再現性とユーザー体験の安定性を長期にわたって維持できる。

5-3 哲学的含意 ― 「時間は共有資源である」

技術的な視点を超えて見ると、タイマー依存バグの問題は、システムが「時間をどう共有するか」という根源的課題に通じる。
マルチスレッド・分散システム・オンラインゲーム――いずれも複数の主体が異なる時間感覚を持ち、それを調停する設計が求められる。
したがって、エンジニアが扱う「時間」は、単なる数値ではなく、システム間の信頼の尺度でもある。

この意味で、タイマー依存バグの克服とは、「異なる世界線に存在する時計を、整合的に語り合わせる試み」と言えるだろう。
ゲームが現実と接続されるほど、この整合性の設計は難しく、同時に創造的でもある。

5-4 実践的まとめ ― 安定した「時間軸」を作るために

最後に、現場で活かせる実践的指針を整理する。

項目	原則	実装・運用例
時間源	Monotonic 基準を統一	QueryPerformanceCounter, CLOCK_MONOTONIC / *_RAW, mach_absolute_time, performance.now()
ゲームループ	固定ステップ＋補間描画	Δt クランプ、accumulator 方式
タイマ管理	相対時間スケジュール	Timer Wheel / Min-Heap 構造
検証	再現的シミュレーション	Δt スパイク、NTP 補正、Doze/バックグラウンド復帰
監視	テレメトリ・可視化	平均 Δt・スパイク率・クロック差分
リスク対策	フェイルセーフ＋安全値	フォールバック 60Hz、遅延挿入、ウォームアップ

これらを標準プロセスとして文書化し、チーム全体で共有することが、時間信頼性を高める第一歩となる。

5-5 結語 ― 「時間を制御できるゲーム」は信頼できる

ゲーム開発とは、プレイヤーに一貫した時間体験を提供する営みである。
それは単に 60fps で動くことではなく、環境やデバイスが変わっても、同じ論理的時間軸上で世界が進行するという保証を意味する。

タイマー依存バグの防止とは、OS クロックの揺らぎを抑えることではない。
それは**「時間の流れを、設計として支配する」**ことに他ならない。

Monotonic な設計、固定ステップ、相対時間、そして観測の仕組み。
これらを積み重ねることで、ゲーム世界の時間は現実世界の揺らぎから独立し、真に安定した体験を提供できる。
すなわち、「時間を信頼できるゲーム」は、プレイヤーからも信頼されるゲームである。

---

参考文献

【1】Gaffer on Games, Glenn Fiedler: “Fix Your Timestep!” (2004)
【2】Microsoft Docs: QueryPerformanceCounter / QueryPerformanceFrequency（高分解能タイマ、周波数特性、スリープ時挙動の注意点）
【3】Linux man-pages: clock_gettime, CLOCK_MONOTONIC, CLOCK_MONOTONIC_RAW（NTP 補正の扱い差）
【4】Apple Developer Documentation: mach_absolute_time, CADisplayLink（モノトニック時間とスリープ時の挙動、描画用クロック）
【5】IETF RFC 5905: Network Time Protocol Version 4（slew / step 補正の概説）
【6】Android Developers: Doze & App Standby（バックグラウンドでのタイマ/ジョブ遅延・統合の仕様）
【7】WHATWG / MDN: performance.now(), requestAnimationFrame, Timer throttling（モノトニック時間源とバックグラウンド時のスロットリング挙動）

免責事項

本記事は一般的な情報提供を目的としたものであり、記載された数値・事例・効果等は一部想定例を含みます。内容の正確性・完全性を保証するものではありません。詳細は利用規約をご確認ください。