--- title: 『バイオハザード レクイエム』へとつながる『バイオハザード』シリーズとRE ENGINEの歩み、そして技術への挑戦 [RE:2026 2026年10月2日登壇] tags: #capcom #カプコン #カプコン技研 #re engine #re2026capcom #ゲーム開発 #ゲームエンジン #バイオハザード レクイエム #バイオハザードシリーズ author: [カプコン技研](https://www.docswell.com/user/CAPCOM_RandD) site: [Docswell](https://www.docswell.com/) thumbnail: https://bcdn.docswell.com/page/LJ39N3Y1J5.jpg?width=480 description: 2026年10月にカプコンが開催した「CAPCOM オープンカンファレンス RE:2026」の講演資料です。 ■ 講演映像(再生リスト) https://www.youtube.com/watch?v=t3l1GD_0XJc&list=PLD_N6X6tKlCM published: November 13, 26 canonical: https://www.docswell.com/s/CAPCOM_RandD/51QNPV-RE2026-WEST-7 --- # Page. 1 ![Page Image](https://bcdn.docswell.com/page/LJ39N3Y1J5.jpg) 『バイオハザード レクイエム』へとつながる 『バイオハザード』シリーズと RE ENGINEの歩み、そして技術への挑戦 加茂 政春 # Page. 2 ![Page Image](https://bcdn.docswell.com/page/8JDGW45KJG.jpg) 『バイオハザード レクイエム』へとつながる 『バイオハザード』シリーズと RE ENGINEの歩み、そして技術への挑戦 加茂 政春 皆さま、本日はご参加いただきありがとうございます。 カプコンの加茂です。 本講演では、『バイオハザード レクイエム』へとつながる、『バイオハザード』シリーズとRE ENGINEの歩み、そしてその中で向き合ってきた技術的な挑戦についてお 話しします。 『バイオハザード7 レジデント イービル』、『バイオハザード ヴィレッジ』、そして『バイオハザード レクイエム』と、同じシリーズ、同じRE ENGINEを使った開発であって も、開発環境や求められる表現、対応すべき課題は大きく変化してきました。 今回は、各タイトルを振り返りながら、タイトル開発とエンジン運用の関係、そして課題に対応するための協力体制についてご紹介します。 1 # Page. 3 ![Page Image](https://bcdn.docswell.com/page/VEP39MG378.jpg) 概要説明 『バイオハザード7 レジデント イービル』の話 『バイオハザード ヴィレッジ』の話 『バイオハザード レクイエム』の話 エンジン運用 協力体制 2 本日の流れです。 『バイオハザード7』から順にそれぞれのタイトル開発の振り返りをして 最後に、複数タイトルでRE ENGINEを運用していく中で見えてきた課題と、それを支える協力体制についてお話しします。 2 # Page. 4 ![Page Image](https://bcdn.docswell.com/page/27V4M96NEQ.jpg) 3 ここからは、3つのタイトルの開発を順に振り返っていきます。 まずは、10年以上にわたるタイトル開発の流れを簡単に見ていきます。 3 # Page. 5 ![Page Image](https://bcdn.docswell.com/page/5JG1GZN57L.jpg) 概要説明 2017 2021 2026 10年以上にわたる タイトル開発 ・技術導入 ・品質向上 ・エンジン進化 4 RE ENGINEを使ったタイトル開発は、すでに10年以上にわたって続いています。 私自身も、『バイオハザード7』から始まり、『ヴィレッジ』、そして『レクイエム』と、複数のタイトル開発に関わってきました。 同じバイオハザードシリーズであり、使用しているゲームエンジンも同じRE ENGINEです。 そのため、一見すると、前回のタイトル開発で得られた知識や経験を、そのまま次のタイトルでも活用できるように思われるかもしれません。 4 # Page. 6 ![Page Image](https://bcdn.docswell.com/page/47QDXLQLEP.jpg) 概要説明 タイトル開発 エンジン運用 課題 協力体制 5 しかし実際の開発では、新しい技術の導入やエンジンの更新、ほかのタイトルで開発された機能の取り込みなどが継続的に行われています。 同じシリーズ、同じゲームエンジンを使った開発であっても、開発環境や機能、運用方法は少しずつ変化していきます。 そのため、新しいタイトルの開発を始める際に、前回のタイトルで得た知識や振り返りの内容を、そのまま踏襲することが難しい場合があります。 ここからは、『バイオハザード7』、『ヴィレッジ』、『レクイエム』の各タイトルを振り返りながら、当時の開発で直面した課題についてお話しします。 少し思い出話のような内容になりますが、お付き合いいただければと思います。 なお、今回取り上げる内容は特に印象深かったものについてとなり、各タイトルで発生した課題のすべてではありません。 そして、それぞれのタイトルを振り返った後に、複数タイトルでRE ENGINEを運用していく中で見えてきた課題や、その課題に対応するための協力体制についてお 話ししたいと思います。 5 # Page. 7 ![Page Image](https://bcdn.docswell.com/page/KE4Z6DN5J1.jpg) 6 ここからは、各タイトルの開発を振り返っていきます。 最初に取り上げるのは、『バイオハザード7 レジデント イービル』です。 本作は、RE ENGINEを使用して開発された初めてのタイトルです。 新しいゲームを開発すると同時に、新しいエンジンや開発方法を構築していくという状況の中で、さまざまな試行錯誤がありました。 6 # Page. 8 ![Page Image](https://bcdn.docswell.com/page/L71RVZ527G.jpg) バイオハザード7 レジデント イービル １．シーン階層によるゲーム設計 Root Scene Stages / World Scenes 1つのシーンから 必要な依存関係を収集 ２．プログラムがシーンアセットの一部になる タイトルプログラム クラスのプロパティ ItemID / bool など シーンアセット内に プロパティを保存 Area Scenes プログラム状態 Game Objects Assets / Script PKG シーンアセット状態 一致している必要がある PKG作成 データ漏れを防ぐ = 不一致になると、シーンを開けないリスク 7 このタイトルで発生した課題について説明する上で前提となる２つのことについてまずはお話しします。 1点目がシーンアセットを運用しているという点で、RE ENGINEではそれ以前の開発においてプログラムで解決していたステージ管理がシーンアセットによるデータ管理に移行し ており、エンジンは当初より、シーンアセット内に別のシーンアセットを内包させることができ、シーンの階層構造を作成できるようになっていました。 PKG（パッケージ）を作成する際には、１つのシーンアセットを指定してPKGを作成するようになっており、タイトルはシーンの階層を設計し、1つのシーンからゲームに必要なす べてのシーンを把握できるようにしています。 シーンアセットに内包されているアセットはそのシーンから依存関係を把握できますので、PKGを作成する際にデータ漏れがないような仕組みになっていました。 DLCを作成するときもDLC用のPKGを作成するときに一つのシーンを選択してPKGを作成します。 2点目はタイトルプログラムもアセットになりえるということです。 タイトルプログラムで作成されるクラスのプロパティがシーンアセットにシリアライズされることになっています。 アセットにクラスの情報が記録されますので、プログラムの状態とシーンアセットの状態は一致している必要があります。 7 # Page. 9 ![Page Image](https://bcdn.docswell.com/page/G7W1L952J2.jpg) バイオハザード7 レジデント イービル プログラム:本編から地続きに更新 シーンアセットは 本編 / DLCごとに作業・リリース プログラムはリリース後も 継続して更新される 本編シーンアセット DLC1シーンアセット DLC2シーンアセット DLC3シーンアセット 8 以上の2点を踏まえ発生した課題について説明いたします。 タイトル本編とDLCのリリースを、シーンアセットとプログラムの視点から確認していきます。 『バイオハザード7』では本編リリース後、割と近いタイミングでDLCを２つリリースしています。 これと同時にもう１つのDLCも開発されている状態でした。 それぞれのシーンアセットの作業区間はこのように時間軸で個別に作業からリリースまでされていますが、 対応するプログラムについては本編から地続きになっています。 8 # Page. 10 ![Page Image](https://bcdn.docswell.com/page/4JZPM9N473.jpg) バイオハザード7 レジデント イービル プログラム:本編から地続きに更新 本編はパッチで更新可 本編シーンアセット DLC1 シーンアセット:ロック / 更新不可 DLC1シーンアセット DLC1リリース後に シリアライズ内容を変更すると… DLC1のシーンを開けなくなる DLC2シーンアセット DLC3シーンアセット 9 注目するポイントはこの矢印のタイミングです。 DLC1をリリースした時点でDLC１のシーンアセットの内容がロックされます。 リリースしたDLCのシーンアセットはDLC1単体のパッケージとしてユーザー様に渡されているので内容は更新することができません。 一方で本編のシーンアセットはDLC1リリース時にパッチでアップデートが入りますのでプログラムの更新を反映することができます。 シーンアセットに内包されているプログラムの内容、シリアライズされているプロパティは一致している必要がありますので、 DLC1リリース以降で、DLC１シーンにシリアライズされている内容を変更するとDLC１のシーンを開くことができなくなります。 9 # Page. 11 ![Page Image](https://bcdn.docswell.com/page/YE6MNK8GJV.jpg) バイオハザード7 レジデント イービル 問題になった変更:enum enum変更後 DLC1リリース後に 更新 プログラム定義されたenum ItemID enum ・Herb ・Key ・Coin … ItemID enum ・Herb ・Key 追加 ・NewItem ・Coin … 一致していない シーンアセットに保存 DLC1シーンへ保存 ItemID enum ・Herb ・Key ・Coin … 追加・入れ替え・文字変更もできない状態 10 シリアライズされている内容の変更というのは、たとえばフラグとしてbool型で保存されていたプロパティが値型に変更される、という感じです。 このような変更はあまりないのですが、問題は列挙型のenumでした。 当時の環境では、enumに列挙されている内容を少しでも変えると変更されているとみなされ シーンアセットと一致していない状態になっていました。 追加も、入れ替えも、文字変更についても一切できませんでした。 これが露見したタイミングがDLC1をリリースした後のQAでしたので、トラブルが発生しました。 10 # Page. 12 ![Page Image](https://bcdn.docswell.com/page/GE5Z5P9X74.jpg) バイオハザード7 レジデント イービル ItemID追加で起きたこと DLC1 DLC1 発売 DLC2 発売 プログラム ItemIDを新規発行 総数:10個 シーンアセット ロック ItemIDを追加 総数:10+α個 DLC1保存内容と 情報が変わる リスク 当時の対応 ・DLCシーンでシリアライズされている DLC1の内容が適用されなくなる プロパティの拡張禁止 ・enumは将来追加を見越して予約枠を定義 11 分かりやすい例をあげますと、 DLC1でアイテムを配布するのでアイテム用のIDを新規発行します。 これはアイテムIDというenumに追加して対応したとします。 その後DLC1がリリースされて、その時点のItemIDの総数が10個だったとします。 DLC2でもアイテムを配布するのでまた新規のIDをItemIDのenumに追加します。 この時点でのプログラムではDLC1のシーンで保存されているItemIDと情報が変わってしまうため、DLC1を開くことができなくなります。 このままプログラムパッチをリリースすると今まで有効だったDLC1の内容が適用されなくなってしまう事態になります。 と、いうようなことが起きましたので、DLCシーンで、シリアライズされているプロパティの拡張を禁止したり、 新規でenumを作成する場合は将来追加されることを見越して予約枠をある程度定義しておく、といった対応がしばらく流行りました。 11 # Page. 13 ![Page Image](https://bcdn.docswell.com/page/972RN62QER.jpg) バイオハザード7 レジデント イービル ミニトピック ストリーミングテクスチャー 12 ミニトピックとして、 『バイオハザード7』から、ストリーミングテクスチャーの機能が有効になって対応しています。 所謂データの裏読みというものとの本格的な付き合いが始まったタイミングになりました。 『バイオハザード7』時でもいろいろありましたが、この裏読みという機能はタイトル開発が進んでいくにつれ個人的には悩ましいものへとなっていきます。 この時はそれを知る由もありませんでした。 12 # Page. 14 ![Page Image](https://bcdn.docswell.com/page/DJYDP9YYJM.jpg) 13 続いて、『バイオハザード ヴィレッジ』の開発についてお話しします。 『バイオハザード7』の開発を通じて、RE ENGINEには多くの機能追加や改善が行われました。 一方で、エンジン側が進化したことにより、前作の設計や実装をそのまま利用することが難しい部分も出てきました。 そこで『ヴィレッジ』では、一度設計を見直し、新しい環境に合わせて再構築するところから開発を進めています。 13 # Page. 15 ![Page Image](https://bcdn.docswell.com/page/V7N65LPR78.jpg) バイオハザード ヴィレッジ RE ENGINEのアップデートを受け、設計をゼロベースで再構築 『バイオハザード7』 タイトル開発と同時に エンジンを構築 エンジン対応 課題に対する RE ENGINE更新 『バイオハザード ヴィレッジ』 新しい設計に合わせて ゼロベースで再設計 コンポーネントベースから、自前クラスで管理する方針へ 変更した方針 Before：コンポーネント多数 After：自前クラスで制御 Character Move コンポーネントは１つだけ Action Game Object Camera AI Game Object Character Control Class 状態管理 移動 アクション Camera IK 14 『ヴィレッジ』を作成する時、すべての設計を一度白紙に戻してゼロベースで構築しなおしました。 これは、『バイオハザード7』がタイトルを開発しながらエンジンを作っていくという状況だったため、『バイオハザード7』で発生した課題に対しエンジン対応が行われた結、『バイオハ ザード7』で作成したプログラムについては新しいエンジンの設計に対応できていなかったためです。 ゼロベースで設計しなおす時に『バイオハザード7』から変えた点の一つとして、コンポーネントベースで機能作成していたところを、コンポーネントではなく、自前でクラスを作成して 管理する方針に変えました。 これは主にキャラクター制御の部分での対応ですが、機能別でコンポーネントを作成してオブジェクトにアタッチしていく方法を振り返った結果、インスペクターの表示が煩雑になっ てしまったり、コンポーネントの数が多すぎるため表示までの時間が⾧くなったりしました。 また、パフォーマンスチェック時にコンポーネント単位でマーカーが仕込まれてチェックできるのですが、各コンポーネント自体がバラバラで稼働しているため、キャラクター単体での処 理時間の計測が難しかったりしてパフォーマンス対応の計画が立てにくいなどありました。 なんとなく同じ時系列でRE ENGINEを使っているタイトルのほとんどが、コンポーネントを作りすぎずに自前クラスの制御で開発する方針になっていった気がします。 14 # Page. 16 ![Page Image](https://bcdn.docswell.com/page/YJ9LY43ZE3.jpg) バイオハザード ヴィレッジ 自前クラス化で見えた、ガベージコレクションの処理負荷 前提 GCは特別意識せず 再設計を進行 参照関係の増加 ClassAが外部から参照され、 その参照が減る度にClassAから参照されているクラスの依存 チェックが実行される Class A Class B Class D 発覚した課題 参照関係が深い / 循環参照で チェックに膨大な時間 Class C Class E ・ ・ ・ 15 少し時間を戻します。 『バイオハザード7』開発時、RE ENGINEではない別のゲームエンジンを使って開発を行っていたチームが、ガベージコレクションの処理負荷問題に頭を悩ませていました。 『バイオハザード7』のパフォーマンス対応時ではガベージコレクションが問題に挙がったことは記憶には無く、そのためパフォーマンスチェック時にガベージコレクション自体をあんまり意識してい ませんでした。 と、いう前提があったので『ヴィレッジ』で再設計するときもガベージコレクションについては特別意識していませんでした。 コンポーネントベースで機能作成していればメモリの生存管理はアタッチしているゲームオブジェクトに依存しますが、自作の場合は生存管理が参照されているかどうかに依存するので、 対象の参照カウンタが減った場合にチェックが実行されることになり、依存関係が深いクラスや循環参照をつくってしまうと、このチェックに膨大な時間がかかることになります。 『ヴィレッジ』の開発中にこれが問題として発覚して調査対応を進めていく過程で内容を理解し始めたのですが、依存関係を構築する手段が単純な参照だけでなくデリゲートなどのイベ ント購読によっても参照関係となる上、すでに大量に利用されている状況から調査するのがとても大変でした。 『ヴィレッジ』はそれこそコードを全部改める勢いの力業で対応した感じですが、現在では仕様の周知と調査機能の充実により大きく問題になることが少なくなってきている印象です。 ただ、デリゲートについて、作った側はどんな仕組みから使われるかを気にして作ることが少ないという印象なので、これの利用に関しては今でもどういった運用にするべきなのかは考え続け ています。 15 # Page. 17 ![Page Image](https://bcdn.docswell.com/page/GJ8X6QLY7D.jpg) バイオハザード ヴィレッジ キャラクター・背景モデルの高ポリゴン化で、メッシュが目立つ存在に 特定ステージ全体のメモリ使用量（雰囲気比較） テクスチャーが支配的 テクスチャー テクスチャー 2 メッシュが目立つ テクスチャー 0.6 メッシュ 1 メッシュ 1 バイオハザード7 ベイカー邸全域 ヴィレッジ 城ステージ メッシュ メッシュサイズだけで比較すると 約1.8倍 『バイオハザード7』では目立ちにくかったメッシュが、 『ヴィレッジ』以降のメモリ課題として顕在化 16 また、このころからキャラクターや背景などのモデルのポリゴン数が上がってきた印象があります。 『バイオハザード7』時にメモリをチェックしているときにはさほど気にならなかったメッシュですが、『ヴィレッジ』以降はかなり目につくようになってきています。 『バイオハザード7』の背景データで特定のステージ全体のメモリ使用量について、メッシュとテクスチャーの比率はメッシュ１に対してテクスチャー２という割合でした。 メモリ視点で見ると、まだテクスチャーが支配的です。 一方で『ヴィレッジ』について、同様に特定ステージ全体のメモリ使用量についてメッシュとテクスチャーの比率がメッシュ１に対してテクスチャ0.6とかというステージも ありました。 メッシュのサイズだけで『バイオハザード7』と『ヴィレッジ』を比較するとだいたい1.8倍くらい『ヴィレッジ』の方が大きいです。 比較しているものとしては、『バイオハザード7』のベイカー邸全域と『ヴィレッジ』の城のステージです。 正確なものではありませんので、なんとなく雰囲気だけで見ていただければと思います。 16 # Page. 18 ![Page Image](https://bcdn.docswell.com/page/LJL89XL9ER.jpg) バイオハザード ヴィレッジ 終盤のメモリ削減では、メッシュは一律に下げにくい タイトル終盤のメモリ不足対応 メッシュでは困難 従来の伝家の宝刀 Texture Mesh 解像度を一律で下げる 段階を一気に下げにくい 何とか収める選択肢はあったが、 品質には影響する 終盤にモデルを作り直して 成立させるのはほぼ不可能 ヴィレッジでは特に恩恵が少なく実行しにくい施策に 17 この現象により、タイトル開発の終盤でメモリ不足によるクラッシュなどの対応を実行するときに テクスチャの解像度を一律でさげて何とか収めるといった伝家の宝刀みたいな方法があったのですが、 メッシュではそれをするのが難しく、タイトル終盤という時期で考えるとほぼ不可能という感じになりました。 『ヴィレッジ』は背景に採用したシェーダーの作用により特にテクスチャーサイズが全体的に抑えられていたので、これの恩恵が少なかったです。 恩恵が少ない割に品質にはちゃんと影響するので施策として実行しにくかったです。 このあたりの本格的な対応は次の『レクイエム』に託されることになりました。 17 # Page. 19 ![Page Image](https://bcdn.docswell.com/page/47M6ZLMVJW.jpg) バイオハザード ヴィレッジ ミニトピック レイトレース 18 『ヴィレッジ』のミニトピックとしては、レイトレースがあります。 レイトレースがミニトピックなのかという感じですが、 主人公のイーサンはまともなフェイスモデルがありませんでしたので、早々に反射の対象から外れてあまり困ることはありませんでした。 ここで楽した分、次の『レクイエム』では対応が大変になりました。 ここでは、処理に必要なデータはカメラに写ってからロードする。という点だけ押さえておきます。 18 # Page. 20 ![Page Image](https://bcdn.docswell.com/page/P7RP6KVWJ9.jpg) 19 続いて、『バイオハザード レクイエム』についてお話しします。 『ヴィレッジ』の開発では、キャラクターや背景モデルの高品質化に伴い、メッシュデータの増加が新たな課題として見え始めていました。 『レクイエム』では、さらに高い表現品質が求められる一方で、幅広い性能のプラットフォームへ同時に対応する必要がありました。 高品質なアセットをどのように各環境で成立させるか。 ここでは、LODの運用を中心に、その対応についてご紹介します。 19 # Page. 21 ![Page Image](https://bcdn.docswell.com/page/PJX3MLZV7X.jpg) バイオハザード レクイエム LOD運用:高品質アセットと多様な性能要件を両立するために メッシュの 高ポリゴン化が顕著に 主要アセットは 高品質仕様で制作 同時リリース・幅広い性能レンジ 将来的な ハードウェア進化 High Mid Low 専用モデル制作は 現実的ではない LODモデルの利用を検討 キャラクター 運用が異なる 背景 20 『バイオハザード レクイエム』では、『ヴィレッジ』から課題に上がり始めていたメッシュの高ポリゴン化が顕著になってきます。 『レクイエム』では将来的なハードウェアの進化も見据え、キャラクターモデルをはじめとした主要アセットを高品質な仕様で制作していました。 また、動作させるハードウェアの設定について幅広いレンジの対応も求められている状況でかつ、リリース日についても対応プラットフォームにおいて同時であったため、 それぞれの性能要件にそった専用モデルの制作は現実的ではありませんでした。 そこで、LODモデルの利用について検討し始めました。 LODモデルの利用については、キャラクターと背景それぞれで運用が異なりました。 まずはキャラクターの運用からお話しします。 20 # Page. 22 ![Page Image](https://bcdn.docswell.com/page/3JKYGL857D.jpg) バイオハザード レクイエム キャラクターLOD:5段階から製品品質として使える段階を選定 品質評価 LOD2までなら 製品利用可能 LOD_0 最高品質 LOD_1 LOD_2 LOD_3 LOD_4 LOD2を LOD0段階として運用 TAと協力して 客観的に評価 LODレベルが上がるにつれて ポリゴン数が減少 プラットフォーム性能により LOD0 / LOD2運用を切替 21 キャラクターモデルについて『レクイエム』では５段階のLODモデルを用意していました。 LOD_0が最高品質、LODレベルが上がるにつれてポリゴン数が減少する運用です。 これらのLODを製品品質として利用できるかどうかを確認することにしました。 この検討にはチームのアーティストに依頼せず、後ほど紹介するアドバンスドゲーム開発室のTAと協力して採用するLODの選定を行っています。 品質評価の結果、LOD2までなら製品として利用しても問題なさそうであるとなったので、LOD2のモデルをLOD0段階として運用するようにしました。 これは対応プラットフォームの性能によりどちらかで運用するという形をとっています。 チームのアーティストに評価を依頼した場合、正直なところ、LOD_2をLOD_0として扱うという判断に納得してもらえるわけがありませんので、評価が進まなくなる 可能性もありました。 そこで、客観的な視点で品質評価を行えるTAの方に協力をお願いしています。 21 # Page. 23 ![Page Image](https://bcdn.docswell.com/page/LE39N321E5.jpg) バイオハザード レクイエム 背景LOD:メモリ事情に応じて、2段階の一律対応へ タイトル終盤 メモリ不足が課題 LOD0 LOD1 100% 60% 背景LODを作成 近距離利用によるエラー 品質評価ではなく メモリ事情から一律対応 アーティストが 集中的に確認 それ以外 1000ポリゴン以上 しきい値 ディテールサーチ利用モデル 5000ポリゴン以上 AD判断のもとで 修正方針を決定 22 一方で背景モデルについては、必要に応じてLODを作成するという形でした。 タイトル終盤に近付くにつれ、メモリ不足が課題となってきたタイミングで、背景モデルについてもLODモデルを作成して対応するようにしました。 背景モデルのLODは２段階のみ作成するようにして、LOD0か、LOD1のどちらかしか利用しないような運用にしています。 キャラクターモデルの時とは異なり品質評価からではなく、その時のメモリ事情からLOD1の品質をLOD0のポリゴン数に対して60%の数になるような一律対応にしています。 この対応については、ポリゴン数が一定数以上のモデルに対して実行するようにしきい値を設けて対応をしています。 しきい値については、ディテールサーチで利用されているモデルは5000ポリゴン以上から対応、そうでないものは1000ポリゴン以上から対応するという方針にしていました。 キャラクター、背景それぞれに対応が入りましたが、本来遠い距離で運用するものを近距離でも利用するためエラーが出てきます。 このエラーについては、アーティストによる集中的な確認作業により問題を抽出し、アートディレクターの判断のもとで修正方針を決定し、必要な修正を行っています。 22 # Page. 24 ![Page Image](https://bcdn.docswell.com/page/8EDGW4ZKEG.jpg) バイオハザード レクイエム プラットフォームごとのLOD対応 プラットフォームごとに 利用しないLOD段階が出る 1PKGで対応する場合 Windows PCなど 対象プラットフォームへ コンバート 設定により、不要LODが メモリに乗らないよう対応 利用しないLOD段階を PKGから除外 同一アセット群を前提にしつつ、 プラットフォームごとのメモリ負荷を制御 23 また、プラットフォームによっては利用しないLOD段階も出てくることになるため、 対象プラットフォームへコンバートする際に、利用しないLOD段階を除外するという対応も行っています。 ただし、Windows PCで動作するプラットフォームなど、PKGは１つだが、ハードウェアスペックの幅が広く、 すべてのLODをパッケージ内に入れておく必要がある場合についてはコンバート時に除外せず、設定により不要なLODがメモリに乗らないような対応を行っていま す。 23 # Page. 25 ![Page Image](https://bcdn.docswell.com/page/V7P39MD3J8.jpg) バイオハザード レクイエム ミニトピック ストリーミングメッシュ 24 『レクイエム』のミニトピックとしては、ストリーミングメッシュになります。 ストリーミングメッシュについては、先ほど説明した１PKGでLOD対応する時に不要なLODがメモリに乗らないようにするときにこの機能を利用して実現をしています。 ゲーム実行中にストリーミングをするような運用は行っていません。 24 # Page. 26 ![Page Image](https://bcdn.docswell.com/page/2JV4M91N7Q.jpg) バイオハザード レクイエム ミニトピック:裏読みの増加 ミニトピック:これまでのまとめ ゲーム中の見え方を安定させるため、なるべく裏読みを発生させない設計へ ストリーミング テクスチャー レイトレース ストリーミング メッシュ ステージ データ 裏読みだらけで大変 変化を抑え、ゲーム中の品質を安定させる方向で設計 25 ここで、これまでのミニトピックのまとめになります。 ストリーミングテクスチャー、レイトレース、ストリーミングメッシュいずれも所謂裏読みが発生するものです。 これらに加えてステージなどゲームに必要なデータ、ステージなどの裏読みをする必要があります。 裏読みだらけで大変です。 『バイオハザード』はチームの傾向として変化が激しい状態を好まない傾向があります。 たとえばストリーミングテクスチャーについても、優先処理により1つのメッシュのテクスチャが、きれいな状態とそうでない状態が頻繁に切り替わるくらいなら、 きれいでない状態のままの方が良いという判断が下る形です。 ですので、なるべくゲーム中に裏読みが発生しない状態をつくるための努力として、ステージデータの裏読みについては、ステージ開始時のロード時間短縮のため最初は必要な 分しかロードしていませんが、一度ロードしたステージデータについて再度利用される可能性がある場合は、なるべく破棄しないような設計にしています。 これから先また裏読みが必要な技術がでてこないか戦々恐々としております。 25 # Page. 27 ![Page Image](https://bcdn.docswell.com/page/5EG1GZ25JL.jpg) 26 ここまでは、各タイトルの開発で発生した課題についてお話ししてきました。 ここからは、少し視点を変えて、RE ENGINEそのものをどのように運用しているのかについてご説明します。 RE ENGINEは、一つのタイトルだけのために開発されているエンジンではありません。 複数のタイトル開発と並行しながら、日々機能の追加や更新が行われています。 その継続的な進化を、各タイトルがどのように取り込み、どのタイミングで独自の開発環境へ移行するのか。 まずは、その基本的な仕組みからご紹介します。 26 # Page. 28 ![Page Image](https://bcdn.docswell.com/page/4JQDXLPL7P.jpg) エンジン運用 基本説明 マスターブランチ 日々更新 定期ビルド タイトル配布用 エンジン テスト タイトル開発 それぞれにブランチを作成し、 状況に最適な構成で運用 エンジン本体 プロジェクトデータ 27 まずは、開発でエンジンを運用する上での構成について簡単に説明いたします。 １タイトルの開発において、エンジン本体とプロジェクトのデータに分かれて管理されていて、 プロジェクトのデータとはそのタイトルのアセットやエンジンに対するタイトル毎で変更可能な設定などがあります。 RE ENGINEのマスターブランチは日々更新されていて、定期的にビルドが実行されます。 詳細は省きますが、ビルドされたものをテストし、パスしたものがタイトル配布用のエンジンとして、プロジェクトデータで設定可能なRevisionとして各タイトルが取得できるように なっています。 この状態から、エンジン本体、プロジェクトデータ、アセットなどそれぞれにブランチを作成することができるようになっており、 その組み合わせによって状況に最適な構成を作成して運用しています。 今回はエンジン運用について話になりますのでエンジンブランチに絞ります。 27 # Page. 29 ![Page Image](https://bcdn.docswell.com/page/K74Z6DY5E1.jpg) エンジン運用 タイトル専用エンジンブランチへの切り替え 継続的に更新 マスターブランチ タイトル用ブランチ作成 切り替え後も取り込みが必要 タイトル側 必要な機能がそろったら なるべく早く切り替えたい マスターブランチとは切り離して運用 不具合対応 追加機能 エンジンチーム負担 28 エンジンのブランチは、展示用ビルドなどスポットで利用されることもありますが、 ほぼすべてのタイトルにおいて開発の中盤から終盤においてタイトル用のエンジンブランチが作成され、マスターブランチとは切り離されて運用されます。 RE ENGINE自体は、複数のタイトル開発と並行し継続的に更新が行われています。 安定性などを考慮するとタイトル開発の視点だけで言うなら、必要な機能がそろったらなるべく早くタイトル用のエンジンブランチを作成したいです。 しかし、タイトル用のエンジンブランチを作成した後も不具合対応や、追加機能の実装が必要になるケースがありその都度タイトル用のブランチにも対応を取り込 む必要が出てきます。 タイトルの視点だけでみたら、早期にエンジンブランチを作成することはあまりリスクが大きくないという印象なのですが、エンジンチームの負担は大きいのでこのあたり はいつも適切なタイミングを模索しております。 28 # Page. 30 ![Page Image](https://bcdn.docswell.com/page/LJ1RVZ62JG.jpg) エンジン運用 タイトルブランチ後・・・ タイトルは完成へ集中／マスターブランチは継続して進む 継続更新 マスターブランチ エンジン更新は止めても マスターは止まらない 切り替え タイトル専用ブランチ 確認はできる ただし、全更新を追う余裕は少ない 次々に更新が入る 完成に向けて集中 別環境での検証も難しい 結果:タイトル終了まで マスターは一旦忘れる 29 と、いうわけで遅くともタイトル終盤のタイミングではエンジンについてはタイトル専用のものに切り替わっているということになります。 このタイミングからタイトル完成に向けて集中していくことになります。 ですが、タイトルでエンジンの更新をとめたとしても、当然エンジンのマスターブランチは進んでいきます。 タイトル作業者視点で、エンジンのマスターブランチにどのような更新が入っているのかといった内容については確認すること自体はできますが、 その内容を気にする余裕も別環境を作って動作検証する余裕もほとんどないため、タイトル終了までマスターブランチのことは忘れます。 29 # Page. 31 ![Page Image](https://bcdn.docswell.com/page/GJW1L9W2E2.jpg) エンジン運用 タイトルブランチ後・・・ 例:バイオハザード レクイエム 専用ブランチ後の更新量 期間:2025年9月下旬 ～ 2026年6月26日 RE ENGINE マスターブランチ 4845 件 承認済みマージリクエスト バイオハザード レクイエム 専用ブランチ 545 件 取り込まれた更新 把握済み545件の外側に、約4300件の未知の更新が残る 30 ここで、『バイオハザード レクイエム』を例にちょっとした数値をご紹介いたします。 『バイオハザード レクイエム』のタイトル専用エンジンブランチを作成した日付は、2025年9月下旬になります。 『バイオハザード レクイエム』の専用エンジンブランチに対して、エンジンの変更を取り込む承認済みのマージリクエストは、2026年6月26日のタイトルアップデートまでの期間において545件となり ます。 専用ブランチ作成後からは安定度が重要視されますので、基本的には不具合の対応が多く取り込まれることになりますが、『バイオハザード レクイエム』ではパストレーシングをはじめとしたレンダリ ング関連の対応が開発終盤まで実装されていた都合、レンダリング関連の機能対応について多くの件数が含まれています。 一方で、『バイオハザード レクイエム』の専用ブランチを作成した時期から、2026年6月26日までの、RE ENGINEのマスターブランチに対して実行された承認済みのマージリクエストは4845件と なります。 『バイオハザード レクイエム』の専用ブランチに取り込まれた545件の内容すべてを把握していたとしても4300件ほどの未知なる更新内容が、ここから次のタイトル開発をおこなう際には降りかかっ てくることになります。 降りかかってくることにはなりますが、実際にそれに対して構えるようなことはなく、正直なところを申し上げると、前作の延⾧から作り始めて、先に説明した膨大な更新分の内容についてはやっていく うちに知れたら取り入れたりするような受け身的な感じで、積極的に更新された内容を開発に取り込んでいこう、みたいな感じではありませんでした。 30 # Page. 32 ![Page Image](https://bcdn.docswell.com/page/4EZPM954J3.jpg) エンジン運用 タイトル開発は「試作」から「制作」へ進む タイトル開発期間 試作期間 制作期間 試作で承認を得て、 製品化に向けた制作へ 継続タイトル 新規タイトル 試作期間の特徴 前作の環境をベースに作り始めること 先行タイトルを参考にして、 多くの試行を短いサイクルで進めるため、 が多い 動く環境から構築することが多い スピードが求められる 31 もう少しだけ説明いたします。 現状において、RE ENGINEを使ってタイトル開発を始めるタイミングの選択として,継続タイトルの場合は、前作の環境をベースにまず作り始める、ということが多 いと考えられます。 新規タイトルの場合でも、すでに先行しているタイトルがいくつもある状況ですので、あえてゼロベースで設計することは少なく、何かのタイトルを参考にしながら作る ことが多いと考えられます。 タイトル開発は試作から始まり、その試作の内容により会社の承認を得て製品化に向けた制作がおこなわれるようになります。 試作期間は様々な試行を数多くこなして進行するため、スピードも求められます。そのため、現状ではこの試作検証においては動いているものをカスタマイズしなが ら進めることが多いです。 例えば、『バイオハザード ヴィレッジ』の試作をする上で、『バイオハザード7』の環境の延⾧でそのまま進行するような感じです。 31 # Page. 33 ![Page Image](https://bcdn.docswell.com/page/Y76MNK9GEV.jpg) エンジン運用 試作期間中のエンジン検証 ゲーム検証と並行して、マスターブランチでの実装検証も進む ゲーム検証 前作環境のまま運用 動いているものを カスタマイズ 試作期間中 実態としては または マスターブランチへ移植 アセットとプログラムを 移植して動作 （どちらのケースでも） 並行してマスターブランチでの実装検証を行う 積極的に最新実装を取り込むというより、 必要になった時に知り、取り入れることが多い 32 この時、エンジンも前作環境そのままで運用するか、マスターブランチのエンジンにアセットとプログラムを移植して動作させるようにするか、などの選択はありますが、 いずれの場合においても、マスターブランチでの実装検証は、試作期間中にゲーム検証と並行して行われることが多いです。 このタイミングでマスターブランチのエンジンと向き合うのですが、先ほどのお話の通りで積極的な取り込みというのはあんまりないという印象です。 32 # Page. 34 ![Page Image](https://bcdn.docswell.com/page/G75Z5PNXJ4.jpg) エンジン運用 タイトル開発を並べてみる マスターブランチ タイトルA 試作 制作 置いていかれる期間 タイトルA 2 試作 制作 タイトルA 3 試作 制作 置いていかれる期間 タイトル開発と並走 次作の開始 繰り返し ブランチ作成後は、マスターブラ ンチとの差分が生まれる 戻るタイミングで、 更新内容と向き合う 継続タイトルでは 同じ構造が続いていく 33 タイトル開発を並べて見てみます。 タイトルAのエンジンブランチ作成タイミングがこのあたり、タイトルA2を作り始めるこのタイミングでマスターブランチに戻ります。 これが繰り返されていくわけですが、タイトル開発とともに動いているのなら、マスターブランチから置いていかれている期間についてはこのくらいとなります。 33 # Page. 35 ![Page Image](https://bcdn.docswell.com/page/9J2RN65Q7R.jpg) エンジン運用 人の流動で、知識差はさらに広がる マスターブランチ タイトルA 2 タイトルA 試作 制作 試作 制作 タイトルA 3 試作 タイトルA追加コンテンツ制作 別タイトルBの開発から合流 期間が⾧くなる 情報の内容もズレる 制作 追加コンテンツ後に合流 別タイトルから合流 参考実装の古さ 追いつく条件 マスターブランチから 離れている期間が⾧くなる 始まりの時期が異なり、 欠落する情報も変わる 最新タイトルでも、参照元 が古い情報の場合がある 動作に支障がなければ 更新されにくい 34 ただ、人の流動については必ずしもその限りではありません。 タイトルA終了後継続してタイトルAの追加コンテンツを作成していた人がその後タイトルA2の制作を行う場合、 マスターブランチから置いていかれている期間が⾧くなります。 同様に別のタイトルBの開発を行ってからタイトルA2に合流した場合についてもその期間は異なり、 さらにタイトルBからの場合は期間の⾧さよりもその始まりのタイミングがタイトルA経験者とはズレていますので、 置いていかれている情報の内容にも差が生じます。 また、開発中参考にするのは別のタイトル開発の実装であることが多いです。 だいたい直近でリリースされているタイトルを参考にすることが多いので、最新タイトルの開発ではあるが参考にしているのは古い情報ということがあります。 どこかでマスターブランチの実装に基づいたタイトルの実装を拾えればその内容がマスターブランチの時間軸まで追いつきますが、 ゲームの動作に支障がなければ更新が行われることはないです。 34 # Page. 36 ![Page Image](https://bcdn.docswell.com/page/DEYDP9KYEM.jpg) エンジン運用 別タイトルの機能を取り込むときに起こること マスターブランチ タイトルA 2 タイトルA 試作 制作 試作 タイトルA 3 制作 試作 制作 タイトル B 試作 制作 人・実装の流入 タイトル B 限定のつもり タイトル A2 で再利用 エンジン側は改修済み 後から発覚 そのタイトル向けの機能・実 装として扱われている 人の流入により、同じ機能 を使った実装が行われる 本来はマスターブランチ側の 新しい機能で実現したい 情報欠落により、差し戻 しが発生することがある 35 さらに、別のタイトルから人の流入がある場合について。 タイトルＢで利用したエンジンの機能をタイトルＡ２でも利用して実装することは普通に考えられることですが、 その機能はタイトルＢのQA対応で急遽対応した機能だったため、エンジンとしては改修された機能で同様のことを実現してほしかったが、 その情報が欠落して実装後に発覚して差し戻したりすることもあるにはありました。 35 # Page. 37 ![Page Image](https://bcdn.docswell.com/page/VJN65LRRJ8.jpg) エンジン運用 個人努力によるフォローから、組織的なサポートへ 踏襲しにくい 知識量の誤差 個人努力で補完 組織へ 他タイトルのノウハウを そのまま活用しにくい マスターブランチの取り組みに 対する理解差が生まれる 状況をつなぐ人たちが 個別にフォローする タイトル開発を支援する 体制に発展 タイトル開発をサポートする組織 知見を集約し、継続的に支える 気づいている人がつなぐ 人数と経験が増える 支援体制へ発展 課題の存在を理解する人が、 個人努力でフォローしていた 開発タイトル数・期間が積み重なり、 中心となる人が増える タイトル開発を支える組織として 機能するようになる 36 このように、他タイトルのノウハウを上手に踏襲しにくい状況やマスターブランチでの取り組みについてスタッフ間での知識量の誤差があることについては、 誰も気づいていないわけではなくその状態を何とかするべく行動する人たちが個人努力によるフォローで何とかつながっていました。 RE ENGINEでの開発タイトルも開発期間もそれなりの数と時間をかけてきていますので、こういった人が徐々に増えてきて、 そういった人たちが中心となりタイトル開発をサポートする組織にまで発展することになりました。 36 # Page. 38 ![Page Image](https://bcdn.docswell.com/page/YE9LY4MZ73.jpg) 37 ここからは、タイトル開発を組織的に支え、技術やノウハウを共有するための協力体制についてご紹介します。 37 # Page. 39 ![Page Image](https://bcdn.docswell.com/page/GE8X6Q1YJD.jpg) タイトル価値の向上に貢献する組織 38 アドバンスドゲーム開発室は将来必要となる新しい技術や表現を研究するだけでなく、 タイトル開発に参加し、現場が抱える課題やニーズを的確に捉えながらワークフローや技術の革新を通じて開発活動を進化させ、タイトル価値の向上に貢献する 組織です。 『バイオハザード レクイエム』の開発途中から本格的に稼働してもらいました。 38 # Page. 40 ![Page Image](https://bcdn.docswell.com/page/LEL89XQ97R.jpg) タイトル価値の向上に貢献する組織 39 それぞれのグループについて簡単に紹介させていただきます。 まずはTAグループです。 アプリケーション開発とアーティストをつなぐ技術を扱うチームです。 ワークフローの開発や効率化を進めるだけでなく、フェイシャルやリギング技術者を擁することでアセットと技術の両面でのサポートを得意とします。 39 # Page. 41 ![Page Image](https://bcdn.docswell.com/page/4JM6ZL1VEW.jpg) タイトル価値の向上に貢献する組織 常設展示 光を追え! ～『バイオハザード レクイエム』に見るパストレーシング～ アプリケーション開発とアーティストをつなぐ技術を扱うチーム 40 今回のオープンカンファレンスでは展示のコンテンツである 「光を追え!～『バイオハザード レクイエム』に見るパストレーシング～」 において成果物の一端を確認できます。 40 # Page. 42 ![Page Image](https://bcdn.docswell.com/page/PJRP6KLWE9.jpg) タイトル価値の向上に貢献する組織 41 続きまして、SIGです。 こちらは、特定の領域に関する知識や研究成果・技術を共有する複数のコミュニティが互いに協力する組織です。 SIGで特定領域の案件を受けることで、タイトルに所属する個々のスキルに依存せず効率よく問題を解決します。 SIGは現在6つのグループがあります。 それぞれについて簡単に紹介いたします。 41 # Page. 43 ![Page Image](https://bcdn.docswell.com/page/PEX3MLWVJX.jpg) タイトル価値の向上に貢献する組織 社会人向け講演 『バイオハザード レクイエム』プレイヤーとキャラクターを シンクロさせ恐怖感とカタルシスを生むアニメーション技術 キャラクター制御のエンジニアリング・品質担保を行うチーム 42 SIGCharacterは、キャラクター制御のエンジニアリング・品質担保を行うチームです。 今回のオープンカンファレンスでは、 「『バイオハザード レクイエム』プレイヤーとキャラクターをシンクロさせ恐怖感とカタルシスを生むアニメーション技術」 において成果物の一端を確認できます。 42 # Page. 44 ![Page Image](https://bcdn.docswell.com/page/3EKYGLV5JD.jpg) タイトル価値の向上に貢献する組織 レンダリングにおける 機能開発・品質担保・最適化を専門に扱うチーム 43 SIG Renderingは、レンダリングにおける機能開発・品質担保・最適化を専門に扱うチームです。 ハイクオリティなビジュアルとパフォーマンスを保証するために技術導入を進めています。 43 # Page. 45 ![Page Image](https://bcdn.docswell.com/page/L739N3M175.jpg) タイトル価値の向上に貢献する組織 ・PlayStation5 ・XBOX Series X|S ・Nintendo Switch 2 ・Steam ・Epic Games Store ・GeForce NOW ゲームをリリース可能な状態にし、 マルチプラットフォーム展開する事を専門に扱うチーム 44 SIG MultiPlatformは、ゲームをリリース可能な状態にし、マルチプラットフォーム展開する事を専門に扱うチームです。 ソフト・ハードの両面の観点から、なるべく多くのユーザーにゲームを届けられるように活動をしています。 44 # Page. 46 ![Page Image](https://bcdn.docswell.com/page/87DGW46K7G.jpg) タイトル価値の向上に貢献する組織 ゲーム開発の効率化に関することを専門に扱うチーム 45 SIG DevOpsは、ゲーム開発の効率化に関することを専門に扱うチームです。 開発中の様々な手間の削減や確認作業の効率化を進めています。 45 # Page. 47 ![Page Image](https://bcdn.docswell.com/page/VJP39MY3E8.jpg) タイトル価値の向上に貢献する組織 ネットワーク機能を専門に扱うチーム 46 SIG Networkは、ネットワーク機能を専門に扱うチームです。 チームの標準装備として、ネットワーク機能を扱えるようにサポートしています。 46 # Page. 48 ![Page Image](https://bcdn.docswell.com/page/2EV4M9GNJQ.jpg) タイトル価値の向上に貢献する組織 領域を問わず新規のさまざまな課題を技術的手段で解決するチーム 47 SIG Dev1Labは、領域を問わず新規のさまざまな課題を技術的手段で解決するチームです。 開発現場から届く様々な問題をエンジニアリングをして解消していく組織です。 47 # Page. 49 ![Page Image](https://bcdn.docswell.com/page/57G1GZ85EL.jpg) タイトル価値の向上に貢献する組織 48 続いて、REthinkです。 開発中に発生するデザインや表現の課題に対し、高い技術力と豊富な経験を駆使して解決するアーティストチームです。 『バイオハザード レクイエム』においてはいくつかのステージにおいてリファレンス制作でご協力いただきました。 48 # Page. 50 ![Page Image](https://bcdn.docswell.com/page/4EQDXL9LJP.jpg) タイトル価値の向上に貢献する組織 開発中に発生するデザインや表現の課題に対し、 高い技術力と豊富な経験を駆使して解決するアーティストチーム 49 こちらがその一例となります。 49 # Page. 51 ![Page Image](https://bcdn.docswell.com/page/KJ4Z6DX571.jpg) タイトル価値の向上に貢献する組織 50 最後にCharacterStrikeです。 豊富な経験を持つアーティストとエンジン開発の技術者が協力し、これまでにないキャラクター表現技術の開発を推進するスペシャリストチームです。 50 # Page. 52 ![Page Image](https://bcdn.docswell.com/page/LE1RVZN2EG.jpg) タイトル価値の向上に貢献する組織 常設展示 『プラグマタ』ディアナで解説! ～髪の毛の一本一本まで高精細なストランドヘア～ 常設展示 恐怖を演出する、『バイオハザード レクイエム』の キャラクター表現解説 豊富な経験を持つアーティストとエンジン開発の技術者が協力し、 これまでにないキャラクター表現技術の開発を推進するスペシャリストチーム 51 今回のオープンカンファレンスでは展示のコンテンツである 「『プラグマタ』ディアナで解説!～髪の毛の一本一本まで高精細なストランドヘア～」 と 「恐怖を演出する、『バイオハザード レクイエム』のキャラクター表現解説」 51 # Page. 53 ![Page Image](https://bcdn.docswell.com/page/GEW1L94272.jpg) タイトル価値の向上に貢献する組織 常設展示 触れて体感、『バイオハザード レクイエム』の キャラクター表現クオリティー 豊富な経験を持つアーティストとエンジン開発の技術者が協力し、 これまでにないキャラクター表現技術の開発を推進するスペシャリストチーム 52 さらに、体験コンテンツである 「触れて体感、『バイオハザード レクイエム』のキャラクター表現クオリティー」 において成果物の一端を確認できます。 52 # Page. 54 ![Page Image](https://bcdn.docswell.com/page/47ZPM924E3.jpg) まとめ 新しい技術への挑戦と、開発体制の進化へ 知見を持ち寄り、互いに協力して 課題へ対応する 技術の進歩に伴い、 課題も変化し続ける エンジン開発 専門組織 タイトル開発 53 ここまで、『バイオハザード7 レジデント イービル』から『バイオハザード レクイエム』までを振り返りながら、タイトル開発の中で直面してきた課題についてご紹介してき ました。 技術の進歩に伴って、ゲームに求められる品質や表現は年々高くなっています。それに合わせて、開発現場で解決しなければならない課題も変化し続けています。 そうした変化に対応していくためには、一つのタイトルや一人の開発者だけで解決するのではなく、 エンジン開発、タイトル開発、そして専門組織がそれぞれの知見を持ち寄り、互いに協力しながら取り組んでいくことがますます重要になってきています。 今回ご紹介した内容も、そのような取り組みの一例です。 これからも、タイトルの価値をさらに高められるよう、新しい技術への挑戦と、それを支える開発体制の進化を続けていきたいと考えています。 以上で、本日の講演を終わります。 53 # Page. 55 ![Page Image](https://bcdn.docswell.com/page/YJ6MNKVG7V.jpg) ありがとうございました。 54 ご清聴ありがとうございました。 54