Unityでキャラクターを動かし始めた頃、
「移動処理はUpdate？それともFixedUpdate？」
「なんとなくUpdateに書いてるけど、これで合ってるのかな……」
こんなモヤっとした経験、ありませんか？
実際、Unity初心者〜中級者の方からよく聞くのが、
- キャラクターがカクカクする
- 物理挙動が安定しない
- PCとスマホで動きが変わる
といった悩みです。
そして原因を辿っていくと、多くの場合「処理を書く場所」が間違っています。
Unityには Update / FixedUpdate / LateUpdate という代表的な更新関数がありますが、
それぞれは似ているようで役割がまったく違うんです。
にもかかわらず、
「とりあえずUpdateに書けば動くから」
「FixedUpdateは物理っぽいから何となく使ってる」
という状態で実装を続けてしまうと、
後から原因不明の不具合や調整地獄にハマりがちです。
この記事では、Unityにおける
- Update / FixedUpdate / LateUpdate の役割と実行タイミング
- 入力・物理・移動・カメラ処理の正しい置き場所
- なぜ「ズレ」や「カクつき」が起きるのか
を、初心者〜中級者の方にもイメージしやすい形で解説していきます。
「なんとなくUpdateに書いている状態」から一歩抜け出して、
自分で判断して処理の場所を選べるようになることがゴールです 🙂
結論：Update / FixedUpdate / LateUpdateは「役割」で使い分ける
先に結論からお伝えします。
Unityの Update / FixedUpdate / LateUpdate は、
「処理の内容（役割）」で使い分けるのが正解です。
- Update：入力取得・UI・物理を伴わない処理
- FixedUpdate：Rigidbodyを使った物理演算・物理移動
- LateUpdate：カメラ追従など、最終的な見た目調整
この役割分担を守るだけで、
- キャラクターのカクつき
- 物理挙動の不安定さ
- 端末やFPSによる挙動の違い
といったトラブルの大半は防げます。
逆に言うと、
「全部Updateに書いている」
「なんとなくFixedUpdateを使っている」
この状態が一番危険です。
今は動いていても、後から必ず調整が難しくなります。
このあと本文では、
- それぞれの更新関数がいつ・なぜ呼ばれるのか
- どんな処理を置くと問題が起きるのか
- 実務で使いやすい王道パターン
を順番に整理していきます。
「UpdateとFixedUpdate、どっちに書くべき？」と迷ったときに、
理由をもって判断できるようになることを目指して、ここから一緒に見ていきましょう。
Updateとは何をする場所か
Updateは、1フレームに1回呼び出される更新関数です。
ただし重要なのは、実行間隔が一定ではないという点です。
フレームレートが高ければ短い間隔で、
重い処理があれば間隔が伸びます。
つまり Updateはフレームレートに依存する 更新処理です。
この特性から、Updateは次のような処理に向いています。
- キーボード・マウス・ゲームパッドなどの入力取得
- UIの更新処理
- 物理演算を伴わないオブジェクト移動
- タイマーやクールダウン管理
特に大事なのが入力処理です。
GetKeyDown や GetMouseButtonDown のような入力は、
「そのフレームだけtrueになる」仕組みになっています。
そのため、毎フレーム必ず呼ばれるUpdateで入力を取得することで、
入力の取りこぼしを防ぐことができます。
また、Update内での移動処理では、
Time.deltaTime を掛けるのが基本です。
これによって、
- FPSが高くても速くなりすぎない
- FPSが低くても遅くなりすぎない
という、フレームレート依存を抑えた動きが実現できます。
なお、Updateは「毎フレーム呼ばれる」ため、
処理を書きすぎるとパフォーマンスに直結します。
「この処理、本当に毎フレーム必要かな？」と迷ったときは、
一度立ち止まって見直すのがおすすめです。
Updateの実行特性については、こちらの記事も参考になります。
次は、Updateとよく混同されがちな FixedUpdate について、
「なぜ物理処理はこっちなのか」を掘り下げていきましょう。
FixedUpdateとは何をする場所か
FixedUpdateは、一定の時間間隔で呼び出される更新関数です。
デフォルトでは 0.02秒（＝1秒間に50回） 実行されます。
ここで重要なのは、FixedUpdateは
- 毎フレーム必ず呼ばれるわけではない
- 1フレーム中に0回・1回・複数回呼ばれることがある
という点です。
この仕組みは、Unityの物理エンジン（Physics）と強く結びついています。
Unityの物理演算は、フレームレートではなく、
FixedUpdateの固定ステップを基準に計算されます。
そのため、次のような処理はFixedUpdateに書くのが基本です。
- Rigidbodyを使った移動処理
- Rigidbody.AddForce / velocity の操作
- 物理演算を前提とした挙動制御
もしこれらをUpdateに書いてしまうと、
- FPSが高い端末では移動が速くなる
- FPSが低い端末では挙動が不安定になる
といったフレームレート依存の問題が起きやすくなります。
「PCでは問題ないのに、スマホだと挙動がおかしい」
というケースの多くは、ここが原因です。
なお、FixedUpdate内では Time.deltaTime を使っても、
内部的には Time.fixedDeltaTime が返されます。
ただし、可読性や意図を明確にするためにも、
物理計算では Time.fixedDeltaTime を明示的に使うのがおすすめです。
Rigidbodyを使った挙動の考え方については、
こちらの記事も参考になります。
次は、カメラのカクつき問題と深く関係する LateUpdate を見ていきましょう。
LateUpdateとは何をする場所か
LateUpdateは、その名の通り
すべてのUpdate処理が終わったあとに呼び出される更新関数です。
実行順としては、ざっくり次のイメージになります。
- Update（各オブジェクト）
- FixedUpdate（必要に応じて）
- LateUpdate（各オブジェクト）
LateUpdateの最大の特徴は、
「他の処理がすべて終わった結果を見てから動ける」点です。
この性質から、LateUpdateは次のような処理に向いています。
- カメラの追従処理
- アニメーション後の位置・回転補正
- 見た目だけを調整する最終処理
特にカメラ追従では、LateUpdateを使うかどうかで
画面のカクつき（ジッター）が出るかどうかが大きく変わります。
もしカメラをUpdateで動かしている場合、
- キャラクターがUpdateやFixedUpdateで移動
- その途中の状態をカメラが追いかける
というズレが発生し、
結果として「瞬間移動しているような見え方」になることがあります。
LateUpdateでカメラを制御すれば、
- キャラクターの移動がすべて完了したあと
- 最終的な位置だけを参照して
カメラを動かせるため、滑らかな追従が実現できます。
カメラ追従を実装する具体例については、
こちらの記事も参考になります。
次のセクションでは、
「なぜ間違った場所に書くと不具合が起きるのか」を、
入力・物理・カメラの3つの視点から整理していきます。
なぜ「間違った場所」に書くと不具合が起きるのか
ここまでで、Update / FixedUpdate / LateUpdate の役割は整理できました。
では次に、「なぜ間違った場所に書くと不具合が起きるのか」を具体的に見ていきましょう。
この理由を理解できると、
- なぜカクつくのか
- なぜ端末で挙動が変わるのか
- なぜ再現性がなくなるのか
が一気に腑に落ちます。
入力処理をFixedUpdateで行うと起きる問題
初心者の方がやりがちなのが、
入力処理をFixedUpdateで取得してしまうケースです。
例えば、
Input.GetKeyDownInput.GetMouseButtonDown
これらは、「そのフレームだけtrueになる」入力です。
一方でFixedUpdateは、
- 毎フレーム必ず呼ばれるわけではない
- フレーム間でスキップされることがある
という性質を持っています。
この2つが組み合わさると、
- 入力されたフレームでFixedUpdateが呼ばれない
- 結果として入力を検知できない
という「入力の取りこぼし」が発生します。
「たまにジャンプしない」
「ボタンを押しているのに反応しない」
といった症状が出る場合、
入力取得の場所をまず疑ってみてください。
物理処理をUpdateで行うと何が起きるか
次に多いのが、物理演算をUpdateで行っているケースです。
Updateはフレームレートに依存するため、
- FPSが高い → 実行回数が多い
- FPSが低い → 実行回数が少ない
という差がそのまま挙動に影響します。
たとえ Time.deltaTime を掛けていても、
Rigidbodyを直接操作している場合は、
物理エンジンとの同期ズレが起きやすくなります。
結果として、
- 端末によって移動距離が微妙に変わる
- 衝突判定が安定しない
- 再現性の低いバグが発生する
といった問題につながります。
時間管理の考え方については、
こちらの記事も合わせて読むと理解が深まります。
カメラがカクつく本当の理由
「キャラクターはちゃんと動いているのに、
画面がカクついて見える」
この場合、カメラの更新タイミングが原因であることが非常に多いです。
例えば、
- キャラクター：FixedUpdateで移動
- カメラ：Updateで追従
という構成だと、
- キャラの移動がまだ途中
- その中途半端な位置をカメラが追う
というズレが毎フレーム発生します。
このズレが積み重なることで、
「ガタガタ揺れているような見え方」になるのです。
カメラをLateUpdateで動かすことで、
- キャラ移動がすべて完了したあと
- 最終的な位置だけを参照
できるようになり、カクつきは大きく改善されます。
この「タイミングのズレ」が原因になる例として、
動く床のケースも参考になります。
次のセクションでは、
これらを踏まえた実践的な処理の分担パターンを紹介していきます。
実践：処理の正しい分担パターン
ここからは、これまでの内容を踏まえて、
実務でもそのまま使いやすい「王道パターン」を紹介します。
「結局どう書けばいいの？」と迷ったときは、
まずこの形に当てはめて考えるのがおすすめです。
王道パターン：入力 → 物理 → 見た目
もっともトラブルが少なく、再現性も高いのが、
次の役割分担です。
- Update：入力を取得する
- FixedUpdate：物理演算で移動させる
- LateUpdate：カメラなど見た目を調整する
ポイントは、
「Updateでは動かさない」という点です。
Updateでは入力だけを取得し、
その結果を変数に保存しておきます。
その入力結果を使って、
FixedUpdateでRigidbodyを操作します。
最後にLateUpdateで、
移動が終わったあとのキャラクター位置を使って
カメラを追従させます。
この流れにすると、
- 入力の取りこぼしが起きにくい
- 物理挙動がフレームレートに依存しない
- カメラのカクつきが出にくい
というメリットを同時に得られます。
CharacterControllerを使う場合の考え方
すべてのキャラクター移動が、
Rigidbody前提というわけではありません。
CharacterControllerを使う場合は、
物理エンジンに完全に任せているわけではないため、
- Updateで移動処理を書く
Time.deltaTimeを掛けて制御する
という構成でも問題ありません。
ただしこの場合も、
- 入力はUpdate
- カメラはLateUpdate
という役割分担は変わりません。
「Rigidbodyか、CharacterControllerか」で、
FixedUpdateが必須かどうかが変わる、
という認識を持っておくと判断しやすくなります。
実務でよくある例外パターン
実際の開発では、必ずしも王道パターンだけではありません。
例えば、
- UI操作（ボタン・スライダー）
- アニメーション駆動の移動
- 物理を使わない演出オブジェクト
こういった処理は、
UpdateやLateUpdateだけで完結させることも多いです。
大切なのは、
「これは物理エンジンと同期する必要があるか？」
「毎フレーム実行する意味があるか？」
を自分で判断できることです。
次のセクションでは、
こうした判断に直結するパフォーマンスと設計の視点を整理していきます。
パフォーマンスと設計の視点
Update / FixedUpdate / LateUpdate を正しく使い分けることは、
見た目や挙動だけでなく、パフォーマンスや設計の健全性にも直結します。
ここでは、初心者〜中級者の方が見落としやすいポイントを整理します。
FixedUpdateを増やしすぎる危険性
「物理処理は全部FixedUpdateに書けば安心」
と思ってしまいがちですが、これは少し危険です。
FixedUpdateは、物理の遅れを取り戻すために
1フレーム中に複数回呼ばれることがあります。
そのため、
- FixedUpdate内に重い処理を書く
- 不要な計算を毎回行う
と、CPU負荷が一気に跳ね上がります。
特にスマホや低スペック端末では、
- FPS低下
- 物理計算が追いつかない
といった悪循環に陥ることもあります。
FixedUpdateには、
「物理に直接関係する処理だけを書く」
という意識がとても重要です。
物理精度と負荷のバランス
Unityでは、
FixedUpdateの実行間隔（Fixed Timestep）を変更できます。
数値を小さくすると、
- 物理演算の精度が上がる
- その分、処理回数が増える
逆に大きくすると、
- 負荷は下がる
- 物理挙動が荒くなる
というトレードオフがあります。
「なんとなくデフォルトのまま」ではなく、
ゲーム内容に合わせて調整することで、
安定性とパフォーマンスの両立がしやすくなります。
設計として意識したい考え方
更新関数の使い分けは、
単なるテクニックではありません。
「この処理の責務は何か？」を考える、
設計の第一歩でもあります。
- 入力の責務
- 物理挙動の責務
- 見た目調整の責務
これらを自然に分離できるようになると、
- バグが追いやすくなる
- 仕様変更に強くなる
- コードが読みやすくなる
というメリットもついてきます。
次のセクションでは、
Update / FixedUpdate に関する理解をさらに深めたい人向けに、
おすすめの学習リソースを紹介します。
さらに理解を深めたい人向け
ここまで読んで、
- 「理屈は分かったけど、実装になるとまだ不安」
- 「自己流からちゃんとした書き方に直したい」
と感じた方も多いと思います。
このセクションでは、
Update / FixedUpdate の理解を一段深めるのに役立つリソースを紹介します。
Update問題を体系的に理解したい人へ
Update・FixedUpdate・Time・物理演算の話は、
断片的に知っていると、どうしても混乱しがちです。
「なぜそうなるのか」
「どう設計すべきなのか」
を一冊で整理したい場合、
定番ですが、やはりこの本が非常に参考になります。
Unityゲーム プログラミング・バイブル 2nd Generation
✅ Amazonでチェックする ｜ ✅ 楽天でチェックする
Update / FixedUpdate の違いだけでなく、
- 時間管理の考え方
- 物理挙動の設計
- 実務に近いコード構成
まで一貫して学べるため、
「なんとなく理解」から抜け出したい人に向いています。
キャラクター制御を実装レベルで学びたい人へ
「本や記事だけだと、どうしてもピンとこない」
という方には、実際に動く実装を見るのが一番早いです。
その点で、プロジェクト構造ごと参考になるのが、
高品質なキャラクターコントローラー系アセットです。
Ultimate Character Controller
✅ アセットストアでチェックする
このアセットでは、
- 入力処理と移動処理の分離
- Update / FixedUpdate の適切な使い分け
- カメラやアニメーションとの連携
といった点が、
実務レベルの設計で実装されています。
「自分のコード、ここが弱いかも？」と
見直すきっかけにもなるので、
中級者以上を目指す方にもおすすめです。
次は、
初心者が特に勘違いしやすいポイントを整理していきます。
よくある誤解・初心者が勘違いしやすい点
最後に、Update / FixedUpdate / LateUpdate まわりで、
初心者〜中級者が特につまずきやすい誤解を整理しておきます。
ここを押さえておくだけでも、
「原因が分からない不具合」にハマる確率はかなり下がります。
FixedUpdateは毎フレーム必ず呼ばれる？
これは非常に多い誤解です。
FixedUpdateは「毎フレーム」ではありません。
固定時間ステップを基準に、
- 呼ばれないフレームがある
- 1フレーム中に複数回呼ばれることがある
という挙動をします。
そのため、
- 入力取得
- フレーム単位の状態管理
をFixedUpdateに書くのは基本的にNGです。
Time.deltaTimeはどこでも同じ？
UpdateとFixedUpdateの両方でTime.deltaTime が使えるため、混乱しやすいポイントです。
FixedUpdate内では、
Time.deltaTimeはTime.fixedDeltaTimeと同じ値
になります。
ただし、
「物理計算であることを明示する」
という意味でも、FixedUpdate内ではTime.fixedDeltaTime を使う方が安全です。
LateUpdateはカメラ専用？
LateUpdateはカメラで使われることが多いですが、
カメラ専用というわけではありません。
本質は、
「他の処理がすべて終わったあとに実行したい処理」
です。
そのため、
- アニメーション後の位置補正
- 最終的な見た目の微調整
などにも使えます。
まとめ
この記事では、Unityにおける
Update / FixedUpdate / LateUpdate の違いと使い分けを解説してきました。
最後にポイントを振り返ります。
- 更新関数は「役割」で使い分ける
- 入力はUpdate、物理はFixedUpdate、見た目はLateUpdate
- 不具合の多くは「処理を書く場所のミス」が原因
「とりあえずUpdateに書く」状態から抜け出すだけで、
コードの安定性と再現性は大きく向上します。
私自身も、Unityを触り始めた頃は
UpdateとFixedUpdateを混ぜて書いて、
原因不明の挙動に何度も悩まされました。
ですが、役割を意識して整理するようになってからは、
「なぜこう動くのか」を説明できる実装ができるようになりました。
もし今、
「なんとなく動いているけど、正しいか自信がない」
と感じているなら、
ぜひ一度、処理の置き場所を見直してみてください。
きっと、Unityでの実装が
今よりずっとラクで楽しくなるはずです 🙂
参考文献・参考リンク
- Unity公式マニュアル：Fixed Updates
- Unity公式マニュアル：イベント関数の実行順序（Execution Order）
- Unity Script Reference：MonoBehaviour.FixedUpdate
- UnityのUpdate関数について分かりやすく解説（shibuya24.info）
- UpdateとFixedUpdateの違いを整理する（Zenn）
- UnityのUpdate / FixedUpdateをどう使い分けるか（note）
- Unityイベント関数まとめ（UMI Studio Blog）
- What is the difference between Update and FixedUpdate?（Stack Overflow）
- What is the right way of using Update and FixedUpdate?（Stack Overflow）
- When should I use FixedUpdate instead of Update?（Reddit / r/unity）
- UnityのUpdateとFixedUpdateの違いまとめ（Qiita）
- Rigidbody.MovePositionを使った移動と壁へのめり込み対処（YouTech School）
- Unity Update vs FixedUpdate Explained（YouTube）
- When to use Update, FixedUpdate and LateUpdate in Unity（YouTube）
よくある質問（FAQ）
- QUpdateとFixedUpdate、移動処理はどちらに書くべき？
- A
Rigidbodyを使う場合はFixedUpdate、
CharacterControllerや物理を使わない移動はUpdateが基本です。
- QRigidbodyを使っていない場合もFixedUpdateは必要？
- A
必須ではありません。
物理エンジンと同期する必要がなければ、Updateだけで問題ありません。
- Qカメラがどうしてもカクつく場合のチェックポイントは？
- A
まず、
- カメラをLateUpdateで動かしているか
- ターゲットの移動処理がどこに書かれているか
を確認してみてください。
それだけで改善するケースは非常に多いです。
※当サイトはアフィリエイト広告を利用しています。リンクを経由して商品を購入された場合、当サイトに報酬が発生することがあります。
※本記事に記載しているAmazon商品情報（価格、在庫状況、割引、配送条件など）は、執筆時点のAmazon.co.jp上の情報に基づいています。
最新の価格・在庫・配送条件などの詳細は、Amazonの商品ページをご確認ください。