国内最大規模のゲーム開発者向けカンファレンス「CEDEC2026」が、2026年7月22日（水）から7月24日（金）までの日程で開催されました。2日目となる23日（木）には、バンダイナムコスタジオの保田 智明氏、都甲 裕太朗氏、ジョ シキン氏が登壇し、「『SOL-AVES』とゲームで実践した描画最適化事例」と題した講演が行われました。
Nintendo Switch 2用ソフト『カービィのエアライダー』を開発初期の720p・約15fpsという状態から、1画面プレイ時において60fpsの安定動作へと導いた取り組みが紹介された本講演。高負荷となる「4画面分割プレイ」を基準に描画負荷を切り分け、同社の内製ゲームエンジン「SOL-AVES（ソルアヴェス）」とゲーム実装の両面から進められた最適化手法が語られました。
TEXT / 浜井 智史
登壇したバンダイナムコスタジオの保田 智明氏、都甲 裕太朗氏、ジョ シキン氏。保田氏とジョ氏はゲーム側、都甲氏は「SOL-AVES」のグラフィックス開発を担当している
「SOL-AVES」は、バンダイナムコスタジオの先端技術を集約し、AAAタイトルの開発効率化を目指して構築されたというゲームエンジン。データ指向設計と並列処理、高速なビルドやライブ編集、プラグインによる拡張性を特徴としています。
その最初の採用タイトルとなったのが『カービィのエアライダー』。任天堂が発売するNintendo Switch 2用ソフトで、バンダイナムコスタジオが全編を受託開発しています。
講演では、最大6人でコースを周回する「エアライド」と、最大16人で浮島を自由に駆け回る「シティトライアル」の2つのモードが主な開発事例として取り上げられました。
『カービィのエアライダー』紹介映像
保田氏によれば、本作はゲームとエンジンを並行して開発し、相互に発展させていったプロジェクトだったとのこと。
エンジン側が描画パイプラインを構築するための基盤やライティング、シェーダー・マテリアルの開発環境を整え、ゲーム側がそれらを用いてパイプラインを組み上げ、作品固有の表現や最適化を実装するという役割分担がなされました。もっとも、実際の現場ではチームの境界にとらわれず、対応できるメンバーが柔軟に作業を進める体制を敷いていたそう。
最新の描画技術だけではなく、商用エンジンでは一般的に備わっている機能の発展版も含め、基礎的な機能を着実に積み上げていく形で開発・実装されました。
ここからは都甲氏よりエンジンの設計と最適化について解説されました。
SOL-AVESの描画では「中間描画コマンド」と呼ばれる方式を採用。ゲーム側がSetGeometryやSetMaterialといった抽象的なコマンドを発行すると、エンジン側で描画順に合わせた並べ替えやデータ設定を行い、各プラットフォームの描画APIへ変換して実行する仕組みです。
この基盤の上に、インスタンシングやLOD、エフェクトなどの基本機能や、DDGI（※）が用意されています。本作ではこれらの機能を活用し、また開発中に拡張しながら実装が進められました。
※ Dynamic Diffuse Global Illuminationの略。間接光をリアルタイムにシミュレーションするレンダリング手法
本作ではパフォーマンスの目標値として携帯モードで1080p、据え置きモードで1440p、1画面プレイ時は60fpsを掲げており、4画面分割時には40fps以上が目指されました。
ところが開発初期の段階では、720pで約15fpsにとどまり、メモリ使用量も想定を大きく上回っていたそう。高品質なピクセル処理や過密な頂点、高解像度テクスチャの読み込みが重なったうえ、レース中の激しい場面変化によってパフォーマンスも安定しませんでした。
そこで開発チームは、ボトルネックを「頂点処理」「ピクセル処理」「テクスチャへのアクセス」の3つに切り分け、それぞれに対するアプローチを組み合わせて最適化を進めていきました。
1．高品質なピクセル処理
→超解像
→VRS（Variable Rate Shading：可変レートシェーディング）
→DDGI（Dynamic Diffuse Global Illumination）
2．過密な頂点
→LOD（Level of Detail）
→デバッグ機能の拡張
3．高解像テクスチャ読み込み
→ASTC（Adaptive Scalable Texture Compression）
ピクセル処理の負荷を軽減するため、最初に着目したのは、Nintendo Switch 2で利用できる超解像と可変レートシェーディングです。
SOL-AVESはもともとDLSSに対応しており、本作でも当初は採用が検討されましたが、開発当初はDLSS自体の処理コストが60fpsの目標に対して重く、採用が見送られました。
代わりに選ばれたのが、Nintendo SDKのアップスケーラーです。こちらはカラー画像のみを入力とする仕組みであり、超解像の入力用に深度情報やモーションベクター（※）、露出情報を必要としないため、超解像入力用のモーションベクターを出力する「Velocity Pass」も削減できました。
※ 画面上の各ピクセルにおける、前フレームからの動き（移動方向や移動量）を表す情報
なお、各アップスケーラーには処理速度や細かな形状の復元、対応プラットフォームの面で得意・不得意があり、開発するゲームに応じた選択が必要だと都甲氏は説明しました。
Nintendo SDKのアップスケーラーによる入出力の比較。入力は1707×960（スライド左）、出力は2560×1440（スライド右）で、縦横約1.5倍に拡大している
可変レートシェーディング（VRS：Variable Rate Shading）は、複数のピクセルを2×2や4×4などの単位でまとめてシェーディングし、色や質感を求める計算の実行頻度を下げます。描画する画素数を変える動的解像度とは、負荷を減らす仕組みが異なります。
シェーディングの粒度は、ドローコール単位やプリミティブ単位で決定できるほか、あらかじめ用意したテクスチャの領域（タイル）ごとに指定もできます。SOL-AVESではVRSをプログラムからの制御に加え、マテリアル単位でも設定可能としました。
超解像とVRSでピクセル負荷を軽減できる見込みが立った一方、解像度を下げすぎたり、シェーディングを粗くしすぎたりすれば画質も低下するため、描画処理そのものの改善も進められました。その一つが、周囲から回り込む間接拡散光を表現する「DDGI（Dynamic Diffuse Global Illumination）」の最適化です。
通常DDGIでは、空間内に配置したプローブ（※）にレイトレーシングで収集した照明情報を持たせ、描画対象の位置に近いプローブを参照して間接光を計算しますが、本作ではプローブの照明情報をあらかじめエディタ上でベイクしています。ランタイムではその事前計算データを読み込み、元のプローブデータは動的に更新しません。
※ 空間内のある位置における照明情報を保持する参照点
エディタ側でライティング情報を事前にベイクし、実機で利用するDDGIの処理フロー
プローブを配置する空間領域である「ボリューム」は、ステージ全体を広く覆うものと、洞窟などの細かな照明変化を拾うための局所的なものを重ねて配置していました。描画時には、各ピクセルが影響を受けるボリュームを調べ、さらに各ボリュームの周囲8プローブを参照します。ボリュームが重なる場所では参照が増えるため、この処理が負荷となっていました。
最適化にあたって着目したのは、ゲーム進行中にステージの大規模な構造変化がなく、動的な天候変化や時間経過もないという本作の仕様です。ゲームスピードが速く、細かな違いを注視されにくいことも踏まえ、静的なメッシュ向けの「DDGI Vertex Bake」と、動くキャラクター向けの「Character DDGI」が用意されました。
「DDGI Vertex Bake」は、シーンのロード時にDDGIの参照結果をモデルの頂点へ保持しておく手法です。ライティング時には保存した結果を利用するため、ピクセルごとにボリュームやプローブを探索する負荷を減らせます。頂点単位になることで細部の情報量は減るものの、最終的な見た目の違いはおおむね目立たず、本作の用途に適していました。
通常のDDGIと「DDGI Vertex Bake」における間接拡散光の成分の比較
一方「Character DDGI」は、キャラクターの中心位置を基準に周囲8プローブの情報を収集し、モデル全体のライティングに利用する仕組み。各プローブの影響度をコンピュートシェーダー（※）で先に計算し、バッファへ保持することで、ピクセルごとに繰り返していた探索処理を省きます。
※ GPUを用いて汎用的な並列計算を行うプログラム
キャラクターが移動すれば、現在位置に応じたプローブを参照し直します。プローブに保持された照明情報は事前計算したまま、移動先に応じて参照する情報を変えることで、間接光の表現と負荷の軽減を両立しました。
「Character DDGI」による間接拡散光の成分。キャラクターの位置に応じた照明情報を参照している
続いて、頂点負荷への対策が紹介されました。「シティトライアル」のステージには、地上・地下・上空にわたって多種多様なオブジェクトが密集しています。画面上では極めて小さく、最終的なピクセルに寄与しない微小な三角形も多数存在しており、カリングとともにLODの調整が重要になったといいます。
SOL-AVESは標準的なMesh LODに加え、HLOD（Hierarchical LOD Volume）を搭載しています。
Mesh LODでは、調整時にLODの段階を色分けして可視化し、ワイヤーフレーム表示も併用しながら、過剰に細かく分割されている箇所を洗い出します。ドローコール数や描画パスごとに投入される頂点数、GPU処理時間を確認できるデバッグ表示も整備され、開発終盤にはモデルごとの頂点数と描画されたピクセル数の割合を表示する機能も実装されました。
HLOD（Hierarchical Level of Detail）は、形状だけでなくマテリアルの構成も含めて簡略化が可能。都甲氏が示した事例では、マテリアル数がHLOD0では22個であったのに対し、HLOD1では3個へ削減。より軽いマテリアルへと置き換え、ドローコールの削減も図られています。
テクスチャによる帯域とメモリへの負荷に関しては、単色でありながら1024×1024ものサイズだったテクスチャなどを洗い出して縮小するだけではメモリが許容上限に収まらず、全体のテクスチャ解像度を半分にすると画質の低下を招いてしまうなど、対処が難航していました。
そこで導入されたのが、圧縮率と画質のバランスをテクスチャごとに調整できる圧縮形式「ASTC（Adaptive Scalable Texture Compression）」です。画素をまとめるブロックのサイズを4×4、6×6、8×8などから細かく選択でき、本作では多くのテクスチャがASTCへ置き換えられました。
一方で都甲氏は、ASTCはDirectX 12ではサポートされていない点にも言及。エディタ表示だけで最終的な品質を判断せず、Nintendo Switch 2の実機上での確認が必要だったと補足しました。
続いては保田氏より、ゲーム側において取り組まれた最適化の事例として、描画パイプライン全体の終盤に置かれるアップスケーリングに焦点を当てて紹介しました。
パドックに多数のプレイヤーが集まる場面や、キャラクター・エフェクトが重なる場面では描画負荷が高まり、映像の滑らかさが損なわれます。一方、ゲームの状況が変われば、再び負荷の低い状態へ戻ります。こうした負荷の変動に対応するために導入されたのが、動的解像度です。
高負荷時には内部の描画解像度を下げてピクセル処理を軽減し、描画した画像を表示サイズまで拡大して出力します。その後、処理負荷に余裕が戻れば再び解像度を引き上げていきます。ただし、低解像度で描画した画像を拡大するため、輪郭のジャギーなどが目立ちやすくなります。
解像度の切り替えをプレイヤーに意識させない制御ノウハウも紹介。フレームレート維持を最優先するため、解像度を下げる際は即座に反応させる一方、戻す際は段階的にゆっくりと引き上げます。ただし、ポーズ画面や撮影モードなどカメラが静止している場面では、画質を優先して設定上の最高描画解像度へ即座に復帰させています。
一般的なバイリニア補間は、近傍4画素を位置に応じて重み付けしながら補間する方式で、処理速度に優れる一方、拡大時に輪郭がぼけやすいという課題があります。
そこでNintendo SDKのアップスケーラーを用いることで、バイリニア補間より負荷がかかるものの、画質と処理速度のバランスが良好だったと保田氏は評価しました。
超解像の適用比較。左は640×360の入力画像を比較用に拡大表示したもの、右は1920×1080への超解像出力結果。カービィの輪郭に表れるジャギーや粒状感に違いを確認できる
なお、処理負荷が低い場面であっても、内部解像度は出力解像度と等倍になるまでは引き上げず、あえて超解像を介すことで画質向上とアンチエイリアス効果を得ています。先に言及された「動的解像度を最高値へ戻す」処理も、戻すのはあくまで設定された内部描画解像度の上限値までとなります。
内部描画解像度・超解像後の解像度・出力解像度・接続先TVの解像度は、それぞれ明確に切り分けて設計されています。据え置きモードでは、負荷に応じた内部解像度で3Dシーンを描画した後、超解像処理によって常に1440pへと伸張し、そこから最終的な出力解像度へ変換するパイプラインが組まれました。4K TVへ接続する場合も、1440pの出力映像をその先の段階で2160p（4K）へ拡大する経路が採られています。
超解像の導入にあたっては、他のグラフィックス表現と組み合わせた際の検証も重ねられました。
たとえばHDR表示の有効時、カービィの滑らかな体表グラデーションに階調の段差が浮き出る「バンディング」が発生。拡大処理をバイリニア補間へ戻すと目立たなくなる現象でしたが、明確な原因特定に至らなかったため、実用上の対処として、HDR表示時はキャラクターのアップが多いシーンに限りバイリニア補間へ切り替えています。
また、ディザリングとの相性も検証。本作では素材のほつれ表現や、HLOD切り替え時のクロスフェードにディザリングを使用しています。動的解像度によって元のディザパターンが粗くなった場合でも、Nintendo SDKのアップスケーラーとの組み合わせでは超解像適用後に見え方を維持できたとのことです。
2.2倍の超解像を適用した後もディザリングの見え方が保たれた例
さらに4画面分割プレイ時には、4つの画面全体に対して一度だけ超解像を適用することで処理を単純化しました。ただしこの方式では、画面分割の境界部分において隣接する別画面のピクセルまで補間してしまう現象が生じます。
幸い本作では、もともと分割境界の上に十字状のUIが重なるデザインだったため、境界の補間がプレイヤーの目に触れることはありませんでした。保田氏は、同様の一括超解像処理を採用する場合は境界付近の挙動を十分に確認し、必要に応じてビューごとの個別適用を検討することを推奨しています。
動的解像度で負荷を安定させ、超解像でその切り替わりを目立ちにくくすることに成功しましたが、この2つの施策だけでは、当初の目標フレームレートには届かなかったといいます。
ここから登壇者がジョ氏へ交代し、さらなる最適化の実践事例が紹介されました。
4画面分割プレイでは視点が1つから4つへと増えるため、ジオメトリ処理やカリング、ドローコールなど、ビューごとに必要となる処理負荷が単純計算で約4倍へと増大します。そこで、最も条件が厳しい4画面分割で主要なボトルネックを解消し、その成果を1～2人プレイ時のパフォーマンス改善にもつなげるという方針が採られました。
まず優先されたのは頂点シェーダーの最適化。動的解像度によって描画する画素数を減らせば、ピクセルの色を計算する処理は軽くなりますが、ポリゴンや頂点そのものの数は減りません。ピクセル処理と頂点処理を明確に切り分けて対策を進め、あらかじめ頂点側のボトルネックを緩和することで、解像度の低下による軽量化効果が十分に発揮されました。
負荷計測にあたっては、4画面分割の条件に加えて、装飾を施した「デコレーション付きマシン」と最も描画負荷の高いキャラクターを組み合わせて検証しました。
まずは内製プロファイラを用い、大量のドローコールやイベント発生時における負荷の急増（スパイク）を洗い出して修正。そのうえでNintendo SDKのGPUプロファイラを使い、より詳細な原因を特定していきました。
得られた計測結果は、1画面・2画面・4画面それぞれの描画プリセットにも反映されました。LODやエフェクトの発生数、描画パスなどを一元管理し、画面分割数や携帯モードといったプレイ条件に合わせて細かく制御する仕組みが整えられています。
GPUプロファイラの別の計測では、テクスチャフェッチがボトルネックになっていることがわかりました。そこで解像度とフォーマットを見直し、テクスチャ圧縮フォーマット「ASTC」を適用。多くのテクスチャを従来のBC形式から「ASTC 8×8」へと変更しました。圧縮後のビットレートは、BC1が4bppであるのに対し、ASTC 8×8は2bppです。
もっとも、ASTC 8×8を適用するとブロックノイズが目立ってしまうテクスチャも一部に存在しました。ブロックサイズを小さくして調整する余地はあったものの、開発スケジュールの都合上、すべてのテクスチャで最適な設定を探る時間がなかったため、画質に問題が生じたものは元のBC圧縮へ戻されました。
ジョ氏の報告によれば、ASTCの導入によってメモリサイズを15%削減できたほか、ピクセルシェーダーをより効率よく稼働できるようになったといいます。
続いては、ライトを絞り込む方式を見直すことで頂点シェーダーを最適化。
本作では多彩なマテリアルや半透明表現に対応するため、オブジェクトを描画する際にフォワードレンダリングを採用しています。この方式で多数のライトを扱うには、各ピクセルに影響するライトを効率よく絞り込む必要があります。
開発初期にはForward+を採用していましたが、その構成で必要だった深度プリパス（Depth Prepass）がドローコールと頂点処理の負荷を増やしていました。そこで、高負荷なステージに限ってClustered Shadingへ移行。最終的には、ステージごとの負荷特性に応じて両方式を使い分ける形に落ち着きました。
本作では、オクルージョンカリングに「静的な方式」と「動的な方式」の2種類を用意しています。
静的な方式では、カメラが存在する位置ごとに、見える可能性のあるオブジェクトをあらかじめリスト化します。ゲーム実行中は、その可視候補リストをもとにして描画対象を絞り込みます。
事前データはMaya上で作成。カメラが存在すると想定される位置にブロックを配置し、各ブロックから見えるオブジェクトをリストへ記録します。ただし、データの計算に数日を要するケースがあり、複数台のPCを用意して計算する運用が必要だったといいます。
事前の可視判定に用いるブロック群
加えて、地上と地下をつなぐ出入口付近では正しい可視データを自動生成できず、リストを手作業で調整する必要がありました。再計算のたびに手直しが発生するうえ、動的に生成されるオブジェクトには適用できないという制約も抱えていました。
そこで新たに導入されたのが、動的な遮蔽判定を行う「Hi-Z Occlusion Culling」です。画面の深度情報を階層化し、オブジェクトを囲むAABB（※）単位で手前の物体に隠れているかどうかを実行時に判定します。動的に生成されるオブジェクトに対しては高いカリング効果を発揮した一方、巨大な背景メッシュは境界ボックス自体も大きくなるため、カリングの効果を得にくい傾向があったとジョ氏。こうした特性を踏まえ、静的な方式と動的な方式を組み合わせて運用されました。
※ Axis-Aligned Bounding Boxの略。座標軸に平行な面で構成される境界ボックス。複雑な形状を単純な箱型で包み、交差や遮蔽の判定を簡略化するのに用いる
エンジンに用意されたLODの活用例も紹介されました。
巨大な建築物などは遠方から見ても画面の広い範囲を占めるため、スクリーンサイズを基準にすると狙い通りに頂点削減を進めにくい場面があります。そのため、本作の背景モデルの多くでは「カメラからの距離」を基準とする方式が採用されました。
「シティトライアル」では、地上と地下に分かれたステージ構造もHLODの制御に活用されました。プレイヤーキャラクターが地上にいる間はほぼ視界に入らない地下エリアをHLODに切り替え、逆に地下にいる間は地上エリアをHLODへと切り替えます。
地上と地下を行き来する出入口が限られている点を生かし、出入口に配置した判定領域を通過したか否かで、プレイヤーの所属エリアを判定している
LOD用モデルに対しては、複数のマテリアルを1つの大きな画像へと統合するアトラス化も施されました。自動最適化ツール「InstaLOD」を用いた事例では、7個のマテリアルを1個に統合したモデルが紹介。ベースカラーやノーマル、メタリックといったテクスチャを種類ごとに1枚へまとめることで、統合後もPBRマテリアルとしてライティングを調整できるように工夫されました。
一方、ブレンドマテリアルを使用しているモデルには、MayaとShaderFXを用いた別ツールで対応が図られました。ただし、マテリアルの統合結果を最も高精細なLOD0に適用しようとすると、必要となるテクスチャ解像度が肥大化するため、統合マテリアルは主にLOD2やLOD3付近の段階から適用されました。
キャラクターモデルについても、表示されるシーンに応じて使用するLODの範囲が調整されました。アウトゲームではLOD0～5を使用する一方、インゲームではデータ容量の大きいLOD0を除外してLOD1～5のみを使用することでメモリ使用量を削減。さらに、操作プレイヤー以外のキャラクターはLOD2から使用するなど、用途に応じて細かく使い分けられています。
頂点側の最適化によって動的解像度を活用できるようになったところで、目標解像度の達成に向けたピクセルシェーダーの最適化へ。
ポストエフェクトの適用場面と処理負荷が見直され、一部のエフェクトはインゲームでの使用を取りやめてリアルタイムムービーのみに限定。インゲームに残す処理に対してもパスごとの負荷基準を設定しました。
VRSについては、プレイヤーの視線が集まりやすい画面中央ではシェーディングの品質を高く保ちつつ、画面の周辺部や動きの激しい部分で処理を粗くする方針が採られました。
具体的には、主に三角形などのプリミティブごとにシェーディング単位を指定し、モーションベクターを用いて画面上の動きの大きさを参照しています。システムとしては最大4×4単位まで対応したものの、最終的な製品版の運用では画質とのバランスを考慮して最大2×2までに制限したそうです。
VRSの処理単位を色分けしたデバッグ表示
間接光については、エンジン側で用意された「DDGI Vertex Bake」と「Character DDGI」が活用され、間接光の品質と1画面60fpsの目標を両立できました。
動的解像度と画面分割という2つの特徴から始まったゲーム側の最適化。多岐にわたる開発作業を支えたのは、エンジンチームとゲームチームの密接なコミュニケーションだったといいます。両チームの座席を近くに配置して口頭で気軽に相談できる環境を整え、密に意見を交わしたことが、多くの最適化につながったと語られました。
エンジンにはNintendo Switch 2に合わせた機能拡張を行い、ゲーム側にはタイトルに求められる多様な描画機能を実装。双方から仕様を見直して複数のボトルネックに対処していく積み重ねによって1画面60fpsの安定動作に到達したと保田氏が総括し、講演を締めくくりました。
『カービィのエアライダー』公式サイト「SOL-AVES」とゲームで実践した描画最適化事例 | CEDEC2026ゲームメーカーズで編集や諸業務に携わっています。『星のカービィ』シリーズと『ポケモン不思議のダンジョン』シリーズが好きです。
西川善司が語る“ゲームの仕組み”の記事をまとめました。
Blenderを初めて使う人に向けたチュートリアル記事。モデル制作からUE5へのインポートまで幅広く解説。
アークライトの野澤 邦仁（のざわ くにひと）氏が、ボードゲームの企画から制作・出展方法まで解説。
ゲーム制作の定番ツールやイベント情報をまとめました。
CEDECで行われた講演のレポートをまとめました。
UNREAL FESTで行われた講演のレポートやインタビューをまとめました。
GDCで行われた講演などのレポートをまとめました。
CEDEC+KYUSHUで行われた講演のレポートやイベントレポートをまとめました。
GAME CREATORS CONFERENCEで行われた講演のレポートをまとめました。
Indie Developers Conferenceで行われた講演のレポートやインタビューをまとめました。
ゲームメーカーズ スクランブルで行われた講演のアーカイブ動画・スライドやレポートなどをまとめました。
東京ゲームショウで展示された作品のプレイレポートをまとめました。
BitSummitで展示された作品のプレイレポートをまとめました。
ゲームダンジョンで展示された作品のプレイレポートをまとめました。
日本と文化が近い中国でゲームを展開するための知見を、LeonaSoftware・グラティークの高橋 玲央奈氏が解説。
インディーゲームパブリッシャーの役割や活動内容などを直接インタビューします。
