2026年7月22日から7月24日にかけての3日間で行われた、“CEDEC2026（Computer Entertainment Developers Conference 2026）”。本イベントは、CESA（コンピュータエンターテインメント協会）が主催する、日本最大のゲーム開発者向けカンファレンスだ。
広告
本稿では、その中で行われた“『ドンキーコング バナンザ』の破壊を推進するQA ～楽しく安心な破壊体験のために～”の講演内容をお届けする。講演を行ったのは、任天堂にて本作のテクニカルリードプログラム/ボクセルプログラムを担当した栗原竜矢氏と、オブジェクトプログラムを担当した濱崎福平氏。
『ドンキーコング バナンザ』は、2025年7月に発売された3Dアクション。『スーパーマリオ オデッセイ』の開発チームをベースにした制作陣によって制作された、地形やオブジェクト、敵やNPCにいたるまでのほぼ全要素が破壊できる豪快な作品だ。同作は“CEDEC AWARDS 2026”において、エンジニアリング部門、ゲームデザイン部門、ビジュアルアーツ部門で最優秀賞を受賞している。
『ドンキーコング バナンザ』は、2025年7月に発売された3Dアクション。『スーパーマリオ オデッセイ』の開発チームをベースにした制作陣によって制作された、地形やオブジェクト、敵やNPCにいたるまでのほぼ全要素が破壊できる豪快な作品だ。同作は“CEDEC AWARDS 2026”において、エンジニアリング部門、ゲームデザイン部門、ビジュアルアーツ部門で最優秀賞を受賞している。
CEDEC2026では本作の“破壊”というコンセプトに関する講演が4つ開かれ、ゲームデザインやアート、技術面やデバッグといった側面からの解説が行われた。本講演ではQA（Quality Assurance）、いわゆる品質保証の面から破壊を支えた工程が紹介された。
QAやデバッグと言えば開発終盤に行われるイメージがあるが、本作では早い段階からテスターと開発チームが連携し、自動デバッグなども活用しながらゲーム制作が進められた。その体制作りだけでなく、発生する不具合にどう対処するか、おもしろいバグを敢えて残す場合には何をすべきかを学べる講演だ。
QAやデバッグと言えば開発終盤に行われるイメージがあるが、本作では早い段階からテスターと開発チームが連携し、自動デバッグなども活用しながらゲーム制作が進められた。その体制作りだけでなく、発生する不具合にどう対処するか、おもしろいバグを敢えて残す場合には何をすべきかを学べる講演だ。
プレイヤーの体験を最優先にするQA
『ドンキーコング バナンザ』は地形からNPCにいたるまで、ほぼすべてのものを破壊できるのが特徴であり魅力だ。本作の地形やキャラクターは3次元空間に積み上げられた情報のボックス、ボクセルで構成されている。これにより、パンチの当たった部分だけを壊すなど豊かな破壊表現が実現。
このボクセル技術に関する詳細は、エンジニアチームによる講演“『ドンキーコング バナンザ』すべてが壊せる世界の構築 ～破壊を実現するボクセル技術～”にて解説されている。
このボクセル技術に関する詳細は、エンジニアチームによる講演“『ドンキーコング バナンザ』すべてが壊せる世界の構築 ～破壊を実現するボクセル技術～”にて解説されている。
さて、地形を破壊して掘り進み、ちぎった地形を投げつけて新たな地形を生成するなど、自由な変化が頻繁に起きる本作。そのようなゲームを作るとどうなるか。
当然、バグが多発する。
破壊によって生まれた狭い隙間に潜り込めばコリジョン（当たり判定）抜けが発生し、マップを突き抜け無限落下していくのは当たり前。大量の破壊によって処理落ちも発生すれば、ポリゴンが壊れて透明な足場ができてしまうこともままあったという。
そんな中、QAでは“体験ファースト”の考えで対応が行われた。プレイヤーが破壊をためらわないよう、楽しく安心して破壊できる環境を作る、バグを直すために制約を増やさず、いい体験につながるならバグすら仕様に取り入れるという方針だ。
抜けを防ぐ、ではなく抜けた後を考える
ひとつの例として挙げられたのが、地形のコリジョンに対する対応。『スーパーマリオ オデッセイ』では、地形の隙間にキャラクターが入ってしまうような、V字型の地形には必ず蓋をするようにとのルールがあった。
本作にも一定のルールはあるものの、地形を破壊、生成できる以上、ステージを作る側がどう気を付けてもプレイヤーの動き次第で問題のある地形は生まれてしまう。
では、コリジョン抜けを防ぐために自由な地形の変化を制限するか。これは当然NG。かと言って、コリジョン抜けの問題を放置していては楽しく安全に遊べるとは言えない。
そこでたどり着いた結論は、コリジョン抜けが発生しても体験を損なわずに復帰できるなら問題ない、というもの。
地面を突きぬけて無限落下するのは大問題だが、天井側に抜けるなら問題は少ない。同様に、動く壁と動かない壁に挟まれた場合は動く壁側に抜ける、ボクセルでないオブジェクトとボクセルに挟まれた場合はボクセル側に抜ける、などの処置が取られた。
こうして許容された抜けが発生した場合、ドンキーコングの周囲にあるボクセルは自動的に破壊される。これにより十分な空間を確保し、無限落下などを防いだわけだ。
シーケンスブレイクは発生する前提で考える
本作はステージを順番に攻略するゲームだが、プレイの仕方によってはイベントをスキップするシーケンスブレイクが起きてしまう（これは多くの作品で起こり得る問題だが）。シーケンスブレイクはゲームの進行不可など、さまざまな問題の原因となる。
たとえば、地形をちぎって遠くの足場に投げることで橋のような地形を作り出せば、ボス戦をスルーしてその後のエリアに突入することもできる。
たとえば、地形をちぎって遠くの足場に投げることで橋のような地形を作り出せば、ボス戦をスルーしてその後のエリアに突入することもできる。
ここに対してわかりやすい解決策は、見えない壁を置いてルートを塞いでしまう方法。しかしこれは制約を増やすことにあたるので却下。せっかく見つけたルートを塞がれては楽しくない、という考えだ。
QAチームは逆に、“楽しいならシーケンスブレイクができてもいい”と考えた。プレイヤーが工夫して進んでいけるのが魅力なら、その工夫を活かせるのが望ましい。
では問題を放置したのかと言えば、そうではない。シーケンスブレイクを許容するのであれば、そうしてもゲームが破綻しないようにすることが大事になる。イベントを飛ばしてもゲームの進行やアイテム収集に影響しないよう、別の部分を調整するわけだ。
たとえばボス戦をスルーして進んだ場合でも、そのボスとは後で戦うことができ、撃破時の報酬も獲得できるようにする。
また、あるイベントを前提としたセリフについては、イベントがスルーされた場合はセリフを変更。こうすることで、自然にイベントを飛ばしてしまった人も、「何かまずいことをしちゃったかな？」という不安を抱かずにプレイできる。
安心して遊べる設計については、レベルデザイン（地形や遊びの設計）に関する講演“『ドンキーコング バナンザ』破壊の連鎖でつながるゲームサイクル”でも、来た道を引き返す必要がない自由な探索という観点から解説されている。
こうして、個別のシーケンスブレイクに対して対応するのではなく、ブレイクが発生する前提で制作が進められた。
シーケンスブレイクはステージ内でのボスやイベントスキップのみならず、本作の目玉となるバナンザ変身の要素にすら及ぶ。本来は5種類の変身を習得していくのだが、プレイ次第では2種類のみを獲得し、ほかの変身はスルーできてしまう。
ここに関しても、工夫とテクニック次第で大きな要素を飛ばせてしまうのはおもしろいと判断された。
しかし、エンディング後に開放される要素は、すべての変身が揃っていることを前提にしていた。これでは、変身を揃えずにクリアーした場合はゲームが破綻してしまう。
そこで、エンディング到達時に全変身を取得するイベントが追加された。「まだ習得してないバナンザ… あるよね？」と専用のセリフも用意されており、むしろ隠されたご褒美を見つけた感覚すら味わえる作りになっている。
ゲームを可能な限り早くクリアーするRTA（リアル・タイム・アタック）などでも、上記のシーケンスブレイクは多用される。無茶な進めかたでもゲームが成立すると、視聴者からは「○○（メーカー）はこれを想定していた……？」などの反応がよく出てくるものだ。任天堂はまさに、シーケンスブレイクを想定してゲームを作っていたのだ。
壊れた地形はそのままに、でも復元するときはする
壊した地形やオブジェクトが自動的に復元される作品もあるが、本作で壊した地形は基本的には壊れたまま。自分の行動が地形に履歴として残る形になる。これについては、アートチームの講演にあった“破壊後の描写で達成感を与える”表現にもつながるだろう。
しかし、地形が壊れたままでは困るケースもある。たとえば地形を破壊してくるボスとの戦いだ。ある程度戦っていると地面は深くえぐられ、戦闘開始時とはまるで違った地形になる。
そうなった状況でボスにやられてリトライしたとき、地形がえぐれたままでは戦闘前の演出でボスが浮いてしまったり、戦闘の難度も不当に上がったりといった問題が発生する。
しかし、地形が壊れたままでは困るケースもある。たとえば地形を破壊してくるボスとの戦いだ。ある程度戦っていると地面は深くえぐられ、戦闘開始時とはまるで違った地形になる。
そうなった状況でボスにやられてリトライしたとき、地形がえぐれたままでは戦闘前の演出でボスが浮いてしまったり、戦闘の難度も不当に上がったりといった問題が発生する。
そのため、こういったシチュエーションではプレイヤーが復帰した際に必要な場所だけ復元するなど、プレイヤーが遊びやすくなるような処理がなされている。
これはボス戦に限らず、たとえばマップ内にある橋などもそうだ。崩れた橋から落下してゲームオーバーになった後、橋が崩れたままでは難度が上昇しすぎるため、こういった場所も復帰時に復元される。
これらの復元設定についてはレベルエディタ上で指定可能。レベルデザインを行う人間がバランスをコントロールできるわけだ。
処理落ちを防ぐ最適化はチームプレイで
プレイヤーの体験を損なわないという観点では、最適化も重要だ。せっかくの自由な破壊も、それによって処理落ちが発生していては楽しめない。
処理負荷を抑えるために破壊の自由度を下げるのは、やはり制約の追加となりNG。そこで、破壊以外の処理負荷に余裕を持たせることで、処理落ちの回避が図られた。
本作のステージには多数のオブジェクトが配置されており、破壊以外の処理負荷を減らすのも簡単ではない。また、プロジェクト終盤の修正やブラッシュアップで負荷が増えてしまっては、いたちごっこになってしまう。
処理負荷を抑えるために破壊の自由度を下げるのは、やはり制約の追加となりNG。そこで、破壊以外の処理負荷に余裕を持たせることで、処理落ちの回避が図られた。
本作のステージには多数のオブジェクトが配置されており、破壊以外の処理負荷を減らすのも簡単ではない。また、プロジェクト終盤の修正やブラッシュアップで負荷が増えてしまっては、いたちごっこになってしまう。
QAチームは最適化に関わる人間を増やすことで処理負荷を意識する人を増やす、いわゆるチームプレイでの最適化を解決策に選んだ。
全体の最適化とは別に、各レベル（ステージ）でプログラマー、アーティスト、レベルデザイナーがチームを組み、処理の高い場所を調査して最適化に挑んだ。チームを組むことで、プログラマー以外にも処理負荷を意識してもらうことができたという。
処理負荷を確認しやすくする仕組みとして、マップ上に処理負荷を可視化する球体が用意された。どこでどの方向を向くと処理が高くなるか、それをわかりやすくするものだ。
そのほか、オブジェクトごとに発生している処理負荷をリストで表示する仕組みも作られ、プログラマーでなくとも負荷状況を把握しやすい状況が作られた。
処理負荷ニュースの共有でモチベをアップ
処理負荷を意識させるための取り組みはゲーム内だけでなく、“処理負荷ニュース”という情報発信でも行われた。処理負荷の高いステージランキングとその変化が細かく共有され、自分たちの対応によって負荷が減っていることを実感できるようにしたのだ。
自分たちの対応結果が可視化されるだけでなく、「ほかのステージがこれだけ減らせたなら自分たちも」と互いに高め合う効果も生まれたという。
自分たちの対応結果が可視化されるだけでなく、「ほかのステージがこれだけ減らせたなら自分たちも」と互いに高め合う効果も生まれたという。
ニュースにはプログラマーによるシステムの最適化に関する情報も含まれ、チーム全体のモチベーション維持に役立ったそうだ。
最適化中に行われたチームでのやり取りも一部公開。“丘の階層”のGPU負荷処理が減っていることに喜ぶレベルデザイナー、プログラマーに最適化の相談をする地形アーティストなど、プログラマー以外のメンバーも積極的に取り組んでいたことが示された。
デバッグでは自動化やスーパープレイも活躍
地形や敵の破壊どころか、シーケンスブレイクまでも受け入れた本作。プレイヤーの発想と工夫次第で自由にプレイできるぶん、デバッグがたいへんになりそう、というのは早い段階から想定されていた。
そこで本作では、デバッグ期間の前から体制と仕組みの準備が進められた。
まずデバッグ体制については、多くの任天堂作品でテストに携わってきたマリオクラブのテスターに早期から参加してもらったという。
そこで本作では、デバッグ期間の前から体制と仕組みの準備が進められた。
まずデバッグ体制については、多くの任天堂作品でテストに携わってきたマリオクラブのテスターに早期から参加してもらったという。
マリオクラブは京都に居を構えていた一方で、本作の開発は東京で進められていた。コアメンバーとなるテスターには東京に出向してもらい、開発チームの一員になってもらったそうだ。
テスターをチームメンバーにすることで、開発者への情報確認はスムーズになり、開発者ミーティングに加わることで仕様を決定経緯から理解でき、レベルエディタを使った確認で想定されている遊びも把握、そして自分の裁量で遊ぶフリーチェックも行えるなど、さまざまな恩恵が得られた。
デバッグのための仕組みとして、デバッグ機能も早い段階から準備された。
地形を投げて橋を作る動きを手軽に再現できるように、ボクセルを直接盛ったり削ったりする機能が実装された。ほかにも、壊したボクセルの復元から地形の全破壊といったものまで、バグチェックに便利な機能が多数用意された。これによりシーケンスブレイクの調査も効率化できたという。
また、バグによっては精密な操作が必要になり、再現難度が高いこともある。これを確実にチェックできるよう、スクリプトを組んでドンキーコングを動かす機能も追加。この機能は修正後の確認にも役立ったそうだ。
地形を投げて橋を作る動きを手軽に再現できるように、ボクセルを直接盛ったり削ったりする機能が実装された。ほかにも、壊したボクセルの復元から地形の全破壊といったものまで、バグチェックに便利な機能が多数用意された。これによりシーケンスブレイクの調査も効率化できたという。
また、バグによっては精密な操作が必要になり、再現難度が高いこともある。これを確実にチェックできるよう、スクリプトを組んでドンキーコングを動かす機能も追加。この機能は修正後の確認にも役立ったそうだ。
もうひとつ大きな仕組みとして作られたのが、自動テストだ。スクリプトによるワープで必要なシーケンスを実行していき、地形破壊が必要な場面では実際に壊しながら進め、カットシーンの再生、収集アイテムのコンプリートなども自動でチェックが行われた。
自動テストで検出されたエラーは、その日のうちに修正されたというスピード感も驚きだ。このテスト実行、エラー通知、バグ修正のサイクルが保たれることで、つねに最後まで通して遊べ、収集アイテムもコンプリートできる状況が作られた。
開発チームがデバッグのための仕組みを作り、テスターがエラー検出のためのスクリプトを用意することで、さまざまなテストを量産できたという。
テスターをチームの一員とすることで実装者に直接質問できる環境を作り、テスターの調査時間を短縮。開発からテスターへの仕様変更の連絡もスムーズになり、変更の影響も素早く調査が行えた。そしてバグをその場で開発側に共有できることで、対応も高速化。
早期から準備した甲斐あって、本作のデバッグ環境は非常に充実したものとなった。
スーパープレイによる検証
早い段階から準備を進めたことで、テスターは仕様を深く理解できるようになり、自動デバッグによってつねにゲームが安定して動作する環境も得られた。これらによって生まれたのが、スーパープレイによる検証だ。
通常プレイでは見られないテクニックを駆使したショートカット、最速プレイやシーケンスブレイクの検証、フレーム単位の操作によるテクニックなどの発見も、こういった検証から生まれた。前述したバナンザ変身の取得スキップも、スーパープレイのなかで見つかったもの。
この検証が行えたことで、想定されていたプレイでは見つかりにくい挙動も見つかり、修正するのはもちろん、仕様として敢えて許容するといった決定も下せたという。
このバグ直すか残すかクイズ
講演の終盤では、検知されたバグに対してどう対応したかがクイズ形式で紹介された。
1問目は、ふつうに渡ろうとすると崩れてしまう薄氷の橋に関するバグ。この橋はシマウマバナンザに変身し、素早く駆け抜けることで突破する想定だ。
しかしテスターは、橋の手前にある雪をちぎって橋の上に投げ、雪の足場を作ることで変身を使わずに渡ってしまった。
1問目は、ふつうに渡ろうとすると崩れてしまう薄氷の橋に関するバグ。この橋はシマウマバナンザに変身し、素早く駆け抜けることで突破する想定だ。
しかしテスターは、橋の手前にある雪をちぎって橋の上に投げ、雪の足場を作ることで変身を使わずに渡ってしまった。
ではこのバグを修正したか、それとも残したか？
答えは、残す。プレイヤーの工夫でショートカットできることはおもしろく、致命的な破綻が起きるわけでもない、ということで許容された。実際、ゲーム側に用意された答えをなぞる以外の解法があるのは楽しい要素だ。
第2問は、トロッコに乗って戦うボスで発見されたバグ。本来はトロッコから爆弾を投げ、ボスのコアを削ることでダメージを与えていく。
が、ここでもボクセル地形が活躍。周囲の地形をもぎ取って足場を作り、直接近づいてボクセルを投げつけることでボスを撃破してしまった。
このバグは修正したか、それとも残したか？
これも、結果的には残された。しかし、トロッコに乗らない戦いを許容したことで、新たな問題が生まれた。
トロッコに乗っている状態ではワープができないのだが、上記のバグを使えばトロッコに乗る必要がなく、ボスを倒して終了演出が始まる前にワープできてしまう。
そのままではゲームの進行に影響する可能性があったため、ボス撃破直後はワープできないようにすることで問題は解決された。バグのほうを潰すのではなく、ワープタイミングを制御することで遊びの幅と安全性を両立させたわけだ。
最後の第3問は、シーケンスブレイクに関するバグ。“レース場の階層”というステージでは、レースで1位になると巨大なトロフィーの上に到達でき、そこからつぎのステージに進める。
もう予想がつくかもしれないが、変身を駆使して空を飛べば、レース自体を無視して直接トロフィーの上に到達できてしまった。
さてこのバグは修正したか？ 残したか？
やはりこれも、レース場なのにレースを飛ばせてしまうのがおもしろいとして、そのまま残された。
しかし、つぎのステージへ移動する際に「ランビランブル（レース）も すっごく楽しかったよ！」というセリフがあった。レースを飛ばした場合、このセリフはおかしなことになる。
そこで、直接トロフィーの上に向かった場合は「レースに勝たなくてよかったのかな？」というセリフに変更。ステージの仕掛けを無視したことに対し、ゲーム側がしっかりと反応を返してくれるようになった。
自由に遊べるゲームだからこそ早期からデバッグ体制を整え、その準備があったからこそ問題があるバグは修正し、おもしろいものは仕様として組み込むことができたという。
講演では触れられなかったのでこれはあくまで憶測になってしまうが、一般的にゲームのボイス収録は比較的早い段階で行われる。その後追加で収録を行うのも、それなりにコストが高いだろう。
バグを許容した際に行われるセリフの追加も、早い段階でバグを検知できる体制があったからこそ、追加収録を行う余裕があったのではないだろうか。対応の柔軟性を上げる意味でも、早期からのデバッグ対応には価値があると言えそうだ。
プレイヤーの発見を奪わず、破綻は防ぐ。プラスを残しマイナスを削る品質保証
QAにおいて最初に立てられた3つの方針は、楽しく安心して破壊できること、制約を増やさないこと、そしておもしろいなら活かすこと。
楽しく安心できるとは、体験を損なうマイナスを減らすこと。制約を増やさないとは、できることを減らさない、つまりプラスを減らさないこと。おもしろいを活かすとは、いい体験を生むバグを取り入れるように、プラスを増やすこと。
単にバグをマイナスと捉えて潰すのではなく、プラスになる要素を活かし、伸ばすQA。破壊を推進するQAというのが、本作で行われた品質保証だ。魅力をさらに伸ばすQAというのは、ゲームの安定性を確保する作業のさらに一歩先を行くもの。
プレイヤーが発見した想定外のルートを塞ぐのではなく、仕様として受け入れたうえで破綻がないように周囲を調整する。プレイヤーの体験を最優先とする対応方針も、本作が高く評価されることになった一因だろう。
ゲームの設計やシステム作りとは違った部分から破壊というコンセプトを支え、強める試みは、アートの分野でも行われている。“『ドンキーコング バナンザ』もっと壊したくなる世界 ～驚きデストラクションと濃厚な絵作り～”の講演では、ビジュアルやサウンドによっていかに破壊を楽しめるかが解説されているので、こちらも要チェックだ。
