This article was translated from English by ChatGPT 5.
なぜゲームは最適化がひどいのか？#
よくゲームを遊ぶ人なら感じているはずだ。ここ数年、多くのタイトルの「最適化」は壊滅的に悪い。
最近インディーゲーム開発を調べていて、最適化に関する情報を集めた。この記事では、なぜゲームの最適化がここまで悪いのかを共有したい。
TL; DR#
ゲームの規模とエンジンの複雑さが急拡大する一方で、開発者は締め切りや「新技術とハードで解決できるだろう」という発想により、継続的な最適化を核心タスクとして扱わない。その結果、ハードのリソースを食い切れていないのにカクつく。
もちろん、理由がそれだけなら記事を書く必要もない。まず「最適化が悪い」とは何かを定義しよう。
最適化#
フレームレートが低い？
ゲームがカクつく？
ネットが悪い？
結局、何が「最適化不足」なのか？
ボトルネック#
従来の GPU ボトルネック ―― グラボが100%使用されフレームレートの上限を決める ―― はもはや唯一でも、最も一般的な問題でもない。現代のゲームのボトルネックは多様化し、見えにくくなっている。
特にありがちなのは シングルスレッドCPUのボトルネック だ。
マルチコアCPUが普及しているにもかかわらず、物理計算、AI、リソース管理、描画命令（Draw Call）の送信といったエンジンの基幹ループは依然としてメインスレッドやレンダースレッドに依存している。
タスクマネージャーのCPU使用率は平均値なので騙されやすい。もし重要なスレッドが単一コアで100%に達すれば、他のコアが暇でも全体が待たされる。
8車線の高速道路で1車線が渋滞すると、残り7車線が空いていても通行効率は落ちる。結果として、CPU全体は25%程度でもフレームレートが限界に達し、命令送信の遅延によるカクつきが出る。
メモリとキャッシュレイテンシ も潜在的な性能キラーだ。
RAM、CPUキャッシュ、VRAM間のデータ転送が遅れるとCPU/GPUが待機し、空サイクルが発生し、パフォーマンス低下やカクつきを招く。
BIOSでXMP/EXPOを有効にしていないためにメモリが定格以下で動作していたり、データアクセスの効率が悪いコードも原因となる。
I/Oとストレージのボトルネック も無視できない。
広大で精細なオープンワールドでは、HDD/SSDからのテクスチャやモデルの読み込み速度がシームレスさを左右する。
トラバーサルスタッター#
トラバーサルスタッター はオープンワールドで非常に多い。
エリアを跨ぐ際に起こる一瞬の停止やフレーム低下のことだ。
原因はレベルストリーミングやワールドパーティション。メモリを節約するためエリアを動的に読み込むが、遅延したりメインスレッドと競合すると必要リソースが揃わずカクつく。
（個人的に最悪だったのは Starfield ――キャラクリで数値を変えるだけでカクついた。）
シェーダーコンパイル#
最もPCゲーマーを悩ませるのが シェーダーコンパイルによるスタッター。ハード性能に関係なくトップスペックPCでも起こる。
シェーダーはGPUで動く小さなプログラムで、色・光・影・反射・透明などを決める。コンパイルは高級言語をGPU用の機械語に翻訳する作業だ。
コンソールは固定ハードなので、開発段階で全シェーダーをプリコンパイルし同梱できる。PCは数千ものGPUが存在しISAが異なるため、中間の バイトコード を配布し、実行時にドライバがGPU固有コードに翻訳する必要がある。これがシェーダーコンパイルだ。
古いAPI（DX11など）はドライバが裏で処理したが効率は低かった。DX12やVulkanでは管理責任が開発者側に移った。
PSO（Pipeline State Object） を事前にキャッシュしないと、ゲーム中に初めて遭遇したエフェクトや敵で即時コンパイルが走り、レンダーパイプラインを数十〜数百msブロックしてカクつきを起こす。
（有名なのは The Callisto Protocol、設定ファイル改造でプリロードを有効化する人までいた。）
コンソール中心主義の弊害#
CPU単スレッド、トラバーサルスタッター、シェーダーコンパイル。これらは結局 コンソール優先の開発体制 に起因する。
PC固有の多様性や複雑性に十分なリソースが割かれず、リリース後のパッチ頼みが常態化した。その結果「PC版の最適化は後回し」という認識が広まり、悪循環で全体の品質が落ちている。
では「最適化不足」とは？#
CPU/GPU使用率が低いのにカクつく、これが典型的。突然のスタッターやリソースの不適切利用は「最適化不足」と呼べる。
（オンラインの最適化は別問題で、サーバー性能ではなくクライアント/サーバー間ロジックの不具合であることも多い。）
Unreal Engine 5#
UE5の柱は Nanite（仮想化ジオメトリ） と Lumen（動的GI/反射）。映画並みのビジュアルを可能にするが、性能コストは大きい。
Nanite#
NaniteはLOD作成の手間を省き、超高密度モデルを自動管理・レンダリングできる。ただし無料の性能ブーストではなく、基盤コストがある。単純なシーンでは従来手法より遅いこともある。
制限も多く、Skeletal Mesh対応は実験段階、透明材質は非対応、SSD依存など。
Lumen#
Lumenは動的なGI/反射を提供。従来のライトマップ焼き込みでは不可能な、動的ライトや時間変化へのリアルな応答を可能にした。
ただしPS5/XSXで1080p内部解像度を前提に設計され、4KはTSRアップスケーリング頼み。
ソフトウェアRTとハードウェアRTの二段構えで性能と品質を切り替えるが、高品質モードは極めて重い。
アップスケーリング#
NaniteとLumenを両立させるには、1440p/4K 60FPS以上での快適動作は アップスケーリング必須 となる。
DLSS / FSR#
NVIDIA DLSS、AMD FSR は今や避けられない。
必需品化#
かつては低スペPC用の補助機能だったが、今やAAA開発はDLSS/FSRを前提に性能目標を設定している。
例：Remnant II は設計段階からアップスケーリングを組み込んでいた。
現実#
しかし現実は、開発者がアップスケーリングに頼りすぎているという批判が強い。ネイティブ60FPSを達成する努力の代わりに、DLSS/FSRに任せてしまう。
欠点も多い：
- ゴースト/残像：高速移動する物体の縁に発生しやすい。
- 細部損失/ぼやけ：推測補完なので細かい模様が消えたり不自然になる。1080p/1440pでは特に顕著。
結果、多くのプレイヤーにとって「画質と操作感を犠牲にフレームを得る」取引に見える。
人#
結局、ゲームは人が作り人が遊ぶ。最適化問題の根本はAAA産業の経済構造にある。
コスト#
AAA開発費は今やハリウッド級。
2〜3億ドルが当たり前、マーケ込みで5億〜10億ドル規模になる。
発表日が財務報告や商戦期に直結し、延期は株価に直撃する。結果、技術的完成度より日程が優先される。
クランチ#
日程と現実の乖離は クランチ を生む。80〜100時間労働も珍しくない。
最適化は手間のかかる作業で、プロファイリングやリファクタリングが必要。だが開発終盤のクランチ状態では後回しにされ、手をつけられないまま出荷される。
根本的な問題は早期のアーキテクチャにあり、リリース直前では修正不能。
サイバートラッシュ化#
最適化不足のAAAは、単なる技術妥協ではなく 組織的失敗の産物 だ。
マーケが誇大広告し、不可能なスケジュールを強制、開発はクランチでしのぎ、最適化は最初に切り捨てられる。
結果、発売日に届くのは未完成品。Day1パッチや後続修正はQAの責任をプレイヤーに転嫁しているだけ。
プリオーダー＋ライブサービスはこの構造を助長し、財務的に成功するため会社は改善しない。Anthem が典型例だ。
結論#
「最適化が悪い」が最初に浮かぶゲームは、すでに問題だ。ゲームは「面白さ」が本質。
グラフィックは加点要素にすぎない。8ビット時代のゲームや、Outer Wilds のようなカートゥーン調でも高評価なのはその証拠だ。
最適化は立ち上げ時から始めるべきで、後でパッチで直せばいいものではない。