前作『Unity パフォーマンスチューニング バイブル』から数年が経ち、Unityにも、端末にも、チューニングの進め方にも変化がありました。この序章では、まずエンジンと端末の変化を大づかみに振り返り、そのうえで2026年時点でチューニングがどこへ向かっているのかを述べます。
Unityでいちばん大きく動いたのは描画です。Unity 6でURPにRender Graphが入り、最適化の作業は、コマンドを自分で並べ替えることから、リソースの使い方をエンジンへ正しく宣言し、その結果を確かめることへと重心が移りました。シェーダーのウォームアップや、オブジェクトごとのパラメーターの渡し方にも、Unity 6世代で新しい選択肢が加わっています。C# 側はUnity 6のうちは大きく変わらないものの、Unity 7ではエディタと一部のデスクトッププレイヤーにCoreCLRが導入され、GCの仕組みも大きく変わります。一方、モバイルは当面IL2CPPとBoehm GCのままなので、これまでのメモリ最適化の考え方は引き続き有効です。ビルドと配布のまわりでは、コードを書き換えずに容量・メモリ・速度のバランスを動かせる設定が増えました。
端末も大きく変わりました。GPUのGeekbenchスコア*1で比べると、前作を執筆していた2022年のハイエンドであるiPhone 14 Pro（A16）は18,691でしたが、2026年のiPhone 18 ProやiPhone Duoが載せるA20 Proは55,120と、約3倍になっています。Android側でも、Galaxy S22（Snapdragon 8 Gen 1、Adreno 730）の6,179に対し、Galaxy S26 Ultra（Snapdragon 8 Elite Gen 5 for Galaxy、Adreno 840）は27,501と、4倍を超えています。
ただし、ローエンドはさほど変わっていません。国内で2022年に発売されたGalaxy A23 5Gは、Dimensity 700（Mali-G57 MC2）とメモリ4GBの構成でした。2025年に発売された同じシリーズのGalaxy A25 5Gも、SoCはDimensity 6100+に替わったものの、GPUは同じMali-G57 MC2でスコアは1,400、メモリも4GBのままです。Galaxy S26 Ultraとは約20倍の開きがあります。
iPhoneでも、2022年の時点では、iPhone SE（第2世代）をはじめ、メモリ3GB以下の端末がまだ広く使われていました。2026年にはiPhone 14以降のメモリ6GB以上の端末が主流になりましたが、すでに2022年の時点で、普段使いには十分な性能の端末が行き渡っていたため、新しい端末が出ても買い替えは進みにくくなっています。2025年初めまで販売されていたiPhone SE（第3世代）やiPhone 13などの4GBの端末は今も多く残っており、3GBのiPhone SE（第2世代）もまだ一部で使われています。
その結果、どの端末までをターゲットにするかという、Androidで長く悩まされてきた問題が、iOSでも無視できなくなりました。上はメモリ12GBのiPhone 18 Proから、下は3GBのiPhone SE（第2世代、2020年発売）まで、同じタイトルが対応すべき端末の幅は広がっています。ゲームのジャンルに合わせて、端末の性能に応じて描画表現や品質設定を切り替える工夫が、これまで以上に求められています（第3部3章「端末に応じた描画設定の切り替え」）。
[*1] Geekbench Browser https://browser.geekbench.com/
とはいえ、解こうとしている問題そのものは、前作の頃から大きくは変わっていません。モバイルGPUのメモリ帯域、大量のオブジェクトを描くときのCPU負荷、シェーダーコンパイルによるスパイク、アセットの解放漏れ、端末ごとのメモリ上限。新しい機能の多くは、こうした以前からの問題に対する新しい道具です。そのため本書は、Unity 6以降でしか使えない機能だけを扱っているわけではありません。キャラクターアニメーションの負荷対策、シェーダーの超越関数の近似、AssetBundleの寿命管理、iOSのメモリ上限の引き上げなど、それより前のバージョンのプロジェクトにもそのまま持ち込める内容も多く含んでいます。
第1部から第3部の冒頭では、その領域で2026年に何が変わり、各章で何を扱うのかをあらためて整理しています。症状から章を探したい場合は、巻頭の「課題別の逆引きガイド」を参照してください。
一方、開発現場の側で2026年に最も大きな関心事になっているのはAIです。AIコーディングエージェントは実装やレビューの一部を任せる道具として日常的に使われるようになり、パフォーマンスチューニングもその例外ではありません。本書の第4部3章「チューニングバイブルをAIコーディングエージェントのスキルにする」では、前作と本書の知見をエージェントの評価ルールへ変換する試みを扱っています。
ただしチューニングには、AIに任せる以前の前提があります。計測です。どこが遅いのかを測らずに手を入れても、速くなったのかどうかを判断できません。そのため業界全体としてはまず、計測の自動化に向けた取り組みが進んでいます。ビルドごとに決まった手順で実機の数値を取り、過去の測定と比べて劣化を自動で検知することで、人手でProfilerを開く回数を減らし、気付くのが遅れないようにする方向です。
筆者らが所属するサイバーエージェント ゲーム・エンターテイメント事業部でも、自動化の取り組みとして、AIエージェントからUnityアプリをリアルタイムに観察・操作するためのランタイムブリッジを整備しています。これをデバイスファームと組み合わせ、CIから「機種を確保してアプリを入れ、決めた手順で操作し、計測して結果を引き戻す」までをエージェントに任せる構成です。計測には実機のアプリに組み込んだランタイムのプロファイラを使い、取得したデータをサーバーへ送って、ブラウザから過去の測定と並べて確認したり、閾値を超えた変化を通知したりできるようにしています。サーバーへ送ったデータは後からAIエージェントが取得し、ボトルネックの診断から修正までを行います（第4部2章「デイリービルドの実機プロファイリングを自動化する」）。
もちろん、これで人の判断が要らなくなるわけではありません。何を見て、何と比べ、どこで打ち切るかという基準は、依然として人が持っておく必要があります。自動化できるのは、その基準がすでにある部分だけです。本書が実測値とともに判断の材料を並べているのは、そのためでもあります。