UnityのTimeクラスを徹底解説！正確な時間管理をマスターしよう

Unityでゲームを作っていると、
「Time.deltaTimeは毎回掛けているけど、正直なところ意味はよく分かっていない」
「ポーズやスローモーションを入れたら、なぜか挙動がおかしくなった」
そんな経験はありませんか？

UnityのTimeクラスは、ほぼすべてのゲームで使われる重要な仕組みです。
ですが実際には、

• なぜ deltaTime を掛ける必要があるのか
• Update と FixedUpdate をどう使い分けるべきか
• timeScale を変更すると、どこまで影響が出るのか

といった部分を「なんとなく」の理解のまま使っている人も少なくありません。

その状態でもゲームは一応動きます。
ただし、後からポーズ処理・速度調整・端末差といった要素が増えてくると、
「なぜこの挙動になるのか分からない」「直したつもりが別の場所が壊れる」
という状況に陥りやすくなります。

この記事では、UnityのTimeクラスを

• ゲームループと時間管理の考え方
• 各Time系APIの役割と設計意図
• 実務でよく起きる失敗とその回避方法

という流れで整理し、
「とりあえず使っている状態」から「意図を持って使える状態」になることを目指します。

初心者の方にも分かるように基礎から説明しつつ、
中級者手前の方がつまずきやすいポイントや設計視点も丁寧に補足していきます。

「時間まわりの処理に、いまいち自信がない」
そう感じている方は、ぜひこのまま読み進めてみてください🙂

---

結論

Unityの時間管理で一番大切なのは、
「フレームレートに依存しないようにしつつ、処理の役割ごとに“使う時間”を分けること」です。

Timeクラスは、単に時間の数値を取得するためのものではありません。
「この処理はフレーム基準でいいのか？」「物理として扱うべきか？」「止めるべき時間か？」といった
設計判断を支えるための仕組みです。

基本となる考え方は、次の3点に集約できます。

• 移動・演出・入力処理は Update 内で行い、必ず Time.deltaTime を使ってフレーム差を吸収する
• 物理演算に関わる処理は FixedUpdate に分離し、一定時間ステップで制御する
• 一時停止や演出制御では Time.timeScale の影響範囲を理解し、必要に応じて unscaled 系の時間を使う

逆に言うと、

• とりあえず deltaTime を掛けている
• 全部 Update に書いている
• timeScale = 0 にすれば全部止まると思っている

このような状態は、後からバグや仕様変更に弱い設計になりがちです。

この先の章では、
「なぜそう分けるのか」「分けないと何が起きるのか」を順番に解説していきます。

---

ゲームループとUnityにおける「時間」の正体

Timeクラスを正しく理解するためには、まず
「ゲームはどういう流れで動いているのか」を知っておく必要があります。

なぜ時間管理が必要なのか

ゲームは内部で、次のような処理を高速で繰り返しています。

• 入力を受け取る
• キャラクターやオブジェクトの状態を更新する
• 画面を描画する

これをゲームループと呼びます。
Unityでは、このループが1フレームごとに回っています。

ここで問題になるのがフレームレートです。

例えば、

• 60FPSの環境 → 1秒間に約60回ループが回る
• 30FPSの環境 → 1秒間に約30回しか回らない

もし「毎フレーム1ずつ移動する」という処理を書いていた場合、
フレームレートが高い環境ほど、ゲームが速く進んでしまうことになります。

この問題を解決するために必要なのが、
「フレーム数」ではなく「経過時間」を基準に処理を行う考え方です。

Unityのゲームループと時間計測の関係

Unityでは、エンジン内部で正確に時間が計測されており、
その結果が Timeクラス を通して私たちに提供されています。

つまり Timeクラスは、

• 「前のフレームから、実際に何秒経ったか」
• 「ゲーム内時間を何倍速で進めているか」
• 「物理演算用に固定された時間間隔」

といった情報をまとめて管理している時間の基盤です。

ここで重要なのは、
Unityは「毎フレーム同じ時間が流れている」とは考えていないという点です。

フレームごとの処理時間は常に変動します。
だからこそ Unityは、

• フレーム基準で動く Update
• 時間基準で動く FixedUpdate
• その間をつなぐ Time クラス

という役割分担を用意しています。

---

Time.deltaTimeとは何か？（フレームレート非依存の核心）

Timeクラスの中でも、最もよく使われているのが
Time.deltaTime です。

多くのサンプルコードやチュートリアルで
「移動量に deltaTime を掛けましょう」と書かれているため、
理由は分からないけど、とりあえず掛けているという方も多いと思います。

Time.deltaTimeの正体

Time.deltaTime は、
「前のフレームから、現在のフレームまでに経過した時間（秒）」を表します。

例えば、

• 60FPS前後で安定している場合 → 約0.016秒
• 30FPS前後の場合 → 約0.033秒

というように、
フレームレートに応じて毎フレーム値が変化します。

Unityはこの「実際に経過した時間」を計測し、
それを deltaTime として渡してくれている、というイメージです。

なぜ deltaTime を掛ける必要があるのか

ここで大事なのが、
「移動量 = 速度 × 時間」という考え方です。

例えば、

• 速度：1秒あたり5ユニット進む
• 経過時間：0.016秒

であれば、そのフレームで進む距離は 「5 × 0.016」になります。

これをコードにすると、次のような形です。

transform.position += direction * speed * Time.deltaTime;

このように書くことで、
フレームレートが変わっても「1秒あたりの移動量」は一定になります。

逆に deltaTime を掛けずに

transform.position += direction * speed;

と書いてしまうと、
フレームが多い環境ほど、1秒間に処理される回数が増え、
結果としてゲームの進行速度が変わってしまいます。

よくある勘違いと注意点

Time.deltaTime について、初心者の方がつまずきやすいポイントも整理しておきましょう。

• 毎フレーム同じ値ではない
  処理が重いフレームでは値が大きくなります
• どこでも使えば良いわけではない
  物理演算では FixedUpdate 用の時間を使う必要があります
• 掛け算の位置が重要
  「速度」に対して掛ける意識を持つと混乱しにくくなります

また、
FixedUpdate 内で Time.deltaTime を参照した場合、
実際には Time.fixedDeltaTime の値が返される点も覚えておくと安心です。

---

UpdateとFixedUpdateの決定的な違い

Time.deltaTime を理解できたら、次に必ず整理しておきたいのが Update と FixedUpdate の違いです。

この2つを何となく使っていると、 「動くけど不安定」「環境によって挙動が変わる」 といった問題が起きやすくなります。

Updateの役割（可変時間ステップ）

Update は、
描画フレームごとに1回呼び出される処理です。

フレームレートが高ければ呼ばれる回数は増え、 重くなれば呼ばれる回数は減ります。

そのため Update は、

• プレイヤー入力の取得
• 見た目の移動・回転
• UIアニメーションや演出

といった、
「多少ズレても問題になりにくい」「見た目重視」の処理に向いています。

このとき、フレーム差を吸収するために Time.deltaTime を使う、という流れになります。

FixedUpdateの役割（固定時間ステップ）

一方 FixedUpdate は、
一定の時間間隔で呼び出される処理です。

デフォルトでは 0.02秒（= 1秒間に50回） という固定間隔で実行されます。

このタイミングはフレームレートとは独立しているため、 Unityの物理演算システムは FixedUpdate を基準に動いています。

そのため、

• Rigidbody への力の加算
• 物理挙動に関わる移動処理
• 衝突計算の前提となる処理

こういった内容は、
必ず FixedUpdate に書くのが基本です。

間違った使い分けで起きる問題

よくある失敗として、

• 物理移動を Update に書いてしまう
• FixedUpdate で見た目の処理まで行ってしまう

といったケースがあります。

これをやってしまうと、

• 動きがガタつく
• 環境ごとに挙動が変わる
• 再現性のないバグが発生する

といった問題につながりやすくなります。

「動いているからOK」ではなく、 その処理が“何に依存しているか”で置き場所を決める という意識がとても大切です。

Update / FixedUpdate の使い分けについては、 こちらの記事でより詳しく解説しています👇

---

Time.timeScaleで時間を操作する仕組み

ここまでで、 「時間をどう測るか（deltaTime）」 「どこで処理するか（Update / FixedUpdate）」 を整理してきました。

次は、
ゲーム内の“時間そのもの”を操作する方法として Time.timeScale を見ていきましょう。

timeScaleとは何か

Time.timeScale は、 ゲーム内時間の進む速さを倍率で指定するプロパティです。

• 1.0：通常速度（デフォルト）
• 0.5：半分の速さ（スローモーション）
• 2.0：2倍速
• 0：時間停止（ポーズ）

この値を変更すると、 「timeScaleの影響を受ける時間」を使っている処理は、 まとめてスピードが変わります。

ポーズ実装で起きがちな落とし穴

「ポーズ = Time.timeScale = 0」 という実装は、Unityではよく使われます。

ただし、このとき次のような挙動になります。

• Update は呼ばれ続ける
• FixedUpdate は停止する
• WaitForSeconds を使ったコルーチンは止まる
• Time.deltaTime は 0 になる

そのため、

• ポーズメニューが動かない
• UIアニメーションが止まる
• 再開時に処理がズレる

といったトラブルが起きやすくなります。

「全部止まってほしい処理」と 「止まってほしくない処理」を 最初から分けて考えることが重要です。

スローモーション実装時の注意点

timeScale を 0.5 などにすると、 スローモーション演出を簡単に作れます。

ただし、ここでも注意点があります。

• 物理演算の精度が落ちることがある
• 操作感が重く感じる場合がある
• fixedDeltaTimeとのバランスが崩れることがある

プロジェクトによっては、 timeScale に合わせて Time.fixedDeltaTime を調整する、 という選択肢も出てきます。

ただしこれは 必ずやるべき処理ではなく、ケースバイケースです。

「見た目の演出を優先したいのか」 「物理挙動の正確さを優先したいのか」 という判断軸で考えると整理しやすくなります。

timeScale を使ったポーズ実装の落とし穴については、 こちらの記事でより詳しく解説しています👇

---

Scaled / Unscaled を理解する（止めたい処理・止めたくない処理）

Time.timeScale を使うと、ゲーム全体の時間をまとめて制御できます。
ですが実務では、
「止めたい処理」と「止めたくない処理」が混在するケースがほとんどです。

その切り分けに使うのが、
Scaled（timeScaleの影響を受ける時間）と Unscaled（timeScaleの影響を受けない時間）という考え方です。

unscaledDeltaTimeとは何か

Time.unscaledDeltaTime は、 timeScale の影響を受けない、実際の経過時間を返します。

つまり、

• timeScale = 1 → 通常の経過時間
• timeScale = 0.5 → ゲーム内はスローだが、unscaled は通常通り
• timeScale = 0 → ゲームは停止しても、unscaled は進み続ける

という挙動になります。

ポーズ中でも動かしたい処理には、 この unscaledDeltaTime を使う、というのが基本方針です。

コルーチンでの待機時間の違い

コルーチンを使っている場合、 待機処理にも Scaled / Unscaled の違いがあります。

• WaitForSeconds
  ゲーム内時間（Scaled）で待機する。ポーズ中は止まる
• WaitForSecondsRealtime
  実時間（Unscaled）で待機する。ポーズ中でも進む

例えば、

• ポーズ中のUIフェード演出
• メニュー表示のアニメーション
• 演出用のカウントダウン

こういった処理は、 ゲームが止まっていても進んでほしいため、 WaitForSecondsRealtime を使うのが適しています。

実務でよくある使い分け例

ここまでを踏まえると、 時間の使い分けは次のように整理できます。

• キャラ移動・戦闘・物理
  → Scaled（deltaTime / FixedUpdate）
• ポーズ中のUI・演出
  → Unscaled（unscaledDeltaTime）
• ゲーム進行と無関係な表示
  → Unscaled を優先

「この処理は、ゲームが止まっても動くべきか？」
と一度自分に問いかけてみると、 使う時間の種類が自然に決まってきます。

---

実装パターン別：正しい時間管理の考え方

ここまでで、Timeクラスの考え方や Scaled / Unscaled、Update / FixedUpdate の役割を整理してきました。

この章では、それらを踏まえて
「実際の実装では、どこで・どの時間を使うべきか」を パターン別に整理していきます。

移動・回転・見た目の処理

キャラクターやオブジェクトの移動、回転、アニメーションなど、 見た目に関わる処理は基本的に Update で行います。

このとき重要なのが、 必ず Time.deltaTime を使うことです。

例えば、

transform.Translate(direction * speed * Time.deltaTime);

このように「速度 × 時間」で移動量を計算することで、 フレームレートが変わっても動きの速さが安定します。

逆に、

• 演出なのに FixedUpdate に書いている
• deltaTime を掛けずに値を加算している

こうした実装は、後からズレやすくなる原因になります。

物理演算に関わる処理

Rigidbody を使った移動や力の加算など、 物理エンジンに依存する処理は 必ず FixedUpdate に分離します。

Unityの物理演算は、 FixedUpdate の固定時間ステップを前提に計算されているため、 Update で操作すると不安定になりやすいです。

また、FixedUpdate 内で時間を扱う場合は、 Time.fixedDeltaTime を使う意識を持つと、 処理の意味が分かりやすくなります。

タイマー・カウント系の処理

「一定時間経過したら処理を行う」 「プレイ時間を計測する」 といったタイマー系の処理は、 時間管理の理解度がそのまま品質に出やすい部分です。

基本となる考え方はシンプルで、

• Update 内で
• deltaTime を加算して
• 一定値を超えたら処理する

という形になります。

この方法を使えば、 フレームレートに依存しない安定したタイマーを実装できます。

タイマー実装の具体例については、 こちらの記事で詳しく解説しています👇

---

ここで一度整理（途中まとめ）

ここまでで、UnityのTimeクラスについて かなり多くの要素が出てきました。

一度ここで、 「結局、何をどう判断すればいいのか」を シンプルに整理しておきましょう。

① この処理はフレーム基準か？時間基準か？

まず考えるべきなのは、 「その処理はフレームごとに動けばいいのか、それとも時間を基準にしたいのか」です。

• 見た目・入力・演出 → Update ＋ Time.deltaTime
• 物理・衝突・力の計算 → FixedUpdate

「どこに書くか」で迷ったら、 物理かどうかを判断基準にすると失敗しにくくなります。

② この処理は timeScale の影響を受けるべきか？

次に考えるのが、 「ポーズ中でも動いてほしい処理かどうか」です。

• ゲーム進行に関わる処理 → Scaled（deltaTime）
• UI・演出・メニュー操作 → Unscaled（unscaledDeltaTime）

timeScale を変更する前提があるなら、 この切り分けを最初から意識して設計することが重要です。

③ 「とりあえず動く」実装で止まらない

Unityは柔軟なエンジンなので、 多少雑な書き方でも動いてしまいます。

ですが、

• 後から速度を変えたい
• ポーズを入れたい
• 端末差に対応したい

こうした要求が出てきたとき、 時間管理の設計が甘いと一気に破綻します。

「今は問題ない」ではなく、 「後から壊れにくいか？」という視点で Timeクラスを使えるようになると、 実装の安心感が大きく変わってきます。

---

学習を深めたい人向け（書籍紹介）

ここまで読み進めていただいた方は、 Timeクラスについて「使い方」だけでなく、 なぜそう設計するのかという視点がかなり整理できていると思います。

この段階に来た人におすすめなのが、 一度、基礎を体系的に整理できる教材に触れてみることです。

断片的な知識がつながると、 Update・FixedUpdate・timeScale まわりの判断が 一気に楽になります。

Unityの教科書 Unity 6完全対応版

Unity全体の仕組みを、 「なぜその書き方になるのか」という視点で解説している一冊です。

Timeクラス単体だけでなく、 Update思想・ゲームループ・設計の考え方がセットで整理されているため、 「時間管理が腑に落ちない」状態から抜け出しやすくなります。

✅ Amazonでチェックする
✅ 楽天でチェックする

楽しく学ぶUnity「3Dゲーム」作りのきほん　Unity6対応

こちらは、 実際に手を動かしながら理解を深めたい人向けの一冊です。

移動・当たり判定・演出などを作る中で、 自然と deltaTime や Update の役割に触れる構成になっているため、 「読んで分かったつもり」になりにくいのが特徴です。

✅ Amazonでチェックする
✅ 楽天でチェックする

Timeクラスは、 一度理解すると、以降の実装すべてに効いてくる基礎知識です。

このタイミングでしっかり整理しておくと、 ポーズ・速度調整・難易度調整といった要素を追加するときも、 迷いにくくなります。

---

よくある誤解・注意点

Timeクラスは便利な反面、 「何となく理解したつもり」のまま使い続けてしまいがちです。

ここでは、実務で特によく見かける誤解や、 あとからトラブルになりやすいポイントを整理します。

deltaTimeを掛ければ何でも解決するわけではない

「フレームレート非依存にするために、とりあえず deltaTime を掛ける」 という考え方は、半分正解で半分危険です。

確かに見た目の移動や演出では有効ですが、

• 物理演算に関わる処理
• FixedUpdate 前提の計算

こうした部分に無理やり deltaTime を使うと、 かえって挙動が不安定になることがあります。

「この処理は何に依存しているのか？」を考え、 deltaTimeを使う前提そのものを疑う癖をつけると安心です。

FixedUpdateに全部書けば安全、ではない

「FixedUpdateは一定間隔だから、ここに全部書けば安定する」 と思われがちですが、これもよくある誤解です。

FixedUpdateはあくまで物理演算のための更新タイミングです。

• 入力処理
• UI更新
• 見た目のアニメーション

これらをFixedUpdateに詰め込むと、 入力遅延やカクつきの原因になります。

「物理かどうか」を基準に、 処理の置き場所を分ける意識が大切です。

timeScale = 0 にすれば「全部止まる」と思っている

timeScaleを0にすると、 多くの処理が止まるのは事実です。

ただし、

• Update自体は呼ばれ続ける
• Unscaledな時間は進み続ける

という点を理解していないと、 「止めたはずなのに処理が動いている」 と混乱しやすくなります。

ポーズ実装では、 止める・止めない処理を明示的に分けることが重要です。

時間管理は後回しにすると痛い

開発初期は、 多少雑な時間管理でも問題になりません。

ですが、

• 演出を増やしたい
• 難易度を調整したい
• プラットフォーム差に対応したい

こうした段階に進むと、 時間管理の甘さが一気に表に出てきます。

Timeクラスは後から直すより、 最初に理解しておく方が圧倒的に楽です。

---

まとめ

この記事では、UnityのTimeクラスについて 「なんとなく使う」状態から「意図を持って使う」状態になることを目的に、 基礎から順番に整理してきました。

最後に、特に大切なポイントを振り返ります。

• 時間管理の目的は、フレームレート差を吸収すること
  フレーム数ではなく「経過時間」を基準に処理を考える
• Update / FixedUpdate は役割で使い分ける
  見た目・入力は Update、物理は FixedUpdate
• Time.deltaTime は万能ではない
  どの処理に使う時間なのかを意識する
• timeScale は影響範囲を理解して使う
  止めたい処理・止めたくない処理を分けて設計する
• Scaled / Unscaled を意識するとポーズ実装が安定する

Timeクラスは、一度理解してしまえば ゲーム全体の設計を支えてくれるとても頼れる基盤になります。

逆に、ここが曖昧なままだと、 ポーズ・速度調整・難易度変更といった要素を追加するたびに 実装が不安定になりがちです。

「今は動いている」ではなく、 「後から仕様が変わっても壊れにくいか？」 という視点で Timeクラスを扱えるようになると、 Unityでの開発がぐっと楽になります。

ぜひ今回の内容を、 これからの実装や設計の判断基準として活用してみてください🙂

---

参考文献

• Unity公式ドキュメント：Time クラス
• Unity公式ドキュメント：Time.deltaTime
• Unity公式ドキュメント：Time.timeScale
• Unity公式ドキュメント：MonoBehaviour.FixedUpdate
• Unity公式ドキュメント：Time.unscaledDeltaTime
• Unity公式ドキュメント：WaitForSeconds
• Unity公式ドキュメント：WaitForSecondsRealtime
• Unity Blog：Fix Your Timestep!
• Game Programming Patterns：Game Loop

---

よくある質問（FAQ）