サイバーエージェントのゲーム・エンタメ事業部が、大規模運営型ゲーム開発を見据えた統合型レンダリングシステム「Sirius」を開発中。Houdiniも推進、現場スタッフに話を訊いた

スマートフォン向けゲームにおいて、グラフィック品質の水準は年々高まり続けている。詳細なキャラクターモデルはもちろん、空や水面、植物、天候、広大なフィールドといった環境表現も、作品の印象を大きく左右する要素になってきた。

サイバーエージェントゲーム・エンターテイメント事業部（SGE）では、そうしたゲーム開発の技術課題をグループ横断で支える組織として、SGEコア技術本部（以下、コアテク）が存在している。そして現在コアテクが力を入れているのが、統合型レンダリングシステム「Sirius」だ。

Siriusは、ゲームエンジンではUnityをベースとしながら、各子会社に分散していたシェーダーやレンダリングパイプラインを統合するための描画基盤として開発が進められている。一方で現在は、単なる開発効率化に留まらず、数年先に求められるグラフィック品質を見据えたR&Dの役割も強めているという。

サイバーエージェントは、同社が得意とするアニメ調（スタイライズド）表現をどのように発展させようとしているのか。そして、オープンワールド規模の開発を見据えたSiriusをどのように活用しているのか。開発に携わる清原隆行氏、岡本穏氏、畳悠樹氏に話を訊いた。

──自己紹介をお願いいたします。

清原隆行氏（以下、清原氏）：
コアテクのグラフィックチームでリーダーをしております、清原です。以前は大阪のコンソール系の会社で13年ほど働き、その後は専門学校で7年ほど講師をしていました。その際に書籍を出版したご縁もあり、サイバーエージェントに転職しました。現在はSiriusなどの基盤開発のほか、各プロダクトにおけるグラフィックス系の不具合修正や、パフォーマンスチューニングなども担当しています。

岡本穏氏（以下、岡本氏）：
グラフィックスエンジニアの岡本です。私も清原さんのチームでグラフィックス開発を担当しています。これまでは複数のゲーム会社でグラフィックスエンジニアとして働き、ゲームエンジン開発にも携わってきました。サイバーエージェントには1年半ほど前に中途入社し、現在はSiriusの開発をメインに、各プロダクトからの要望を基盤に反映しています。

畳悠樹氏（以下、畳氏）：
同じくコアテクのグラフィックチームに所属している畳です。立ち位置としては、テクニカルアーティストというよりグラフィックスエンジニア寄りになります。ゲーム業界歴は9年ほどで、以前はコンシューマーゲーム開発に約6年間携わっていました。現在はSiriusの開発やHoudini周りを担当しており、以前は社内でデファクトスタンダードになっているエフェクトシェーダー「NOVA Shader」の管理・開発などもおこなっていました。

統合型レンダリングシステムSiriusとはなんなのか？

──そもそもSiriusとはどういったものなのでしょうか。統合型レンダリングシステムとのことですが。

清原氏：
Siriusは、各プロダクトが実現したい表現に特化するため、社内基盤として開発しているレンダリングシステムです。我々はゲームエンジンとしてUnityを採用していますが、Unityは拡張性が高い一方で、そのまま使うだけでは各子会社が求める表現を形にしづらいこともあります。

そのためこれまでは、各社がそれぞれ専用のシェーダーやレンダリングパイプラインを構築していました。それらを統合したものがSiriusです。Unityという基盤の上に、さらにSiriusのようなレンダリングシステムを乗せて拡張しているイメージですね。

各社の基盤における共通部分を統合し、開発効率を高めていくことは、我々コアテクの大きなミッションのひとつです。事業部の中には、アニメ・漫画調のスタイライズドな表現を強みとしている会社もあり、そうした各社の技術を吸い上げ、いわゆる「車輪の再発明」を防ぐ仕組みを作ろうというのが、もともとのSiriusの始まりになります。

──コアテクはもともと各会社をサポートする部門ということでしたが、今の話を聞くとSiriusはR&D的……つまり研究開発としての側面もありそうです。

清原氏：
当初は各社の技術を集約する目的でSiriusを作っていたので、R&Dにはそこまで力を入れていませんでした。ただ開発を進める中で、今後私たちが競合タイトルに対して競争力を持っていくには、少し先を見据えたR&Dも必要ではないかという話になってきました。

ちょうどそのタイミングで、ゲームエンジンの開発経験もある岡本さんがコアテクに加わりました。そこから、先進的な表現を含めたR&DもSiriusの主目的のひとつとして進めていこう、という流れになりました。

──ずばり、Siriusの強みは、どのようなところにあるのでしょうか。

清原氏：
Siriusは開発当初から、多機能なレンダリングシステムを目指してきました。すでにさまざまな機能が搭載されているので、プロダクト側が新しいルックを作る際に、毎回イチから作る必要がありません。ルック開発（ルックデブ）にかかる時間を短縮できるのは、大きな強みだと思います。

──キャラクターのルックは、各会社や各プロダクトの描写したい表現の差も大きそうです。そのあたりはどのように対応しているのでしょうか。

清原氏：
キャラクターのスタイライズドレンダリングについては、各プロダクトの需要に合わせて開発しています。そのため、共通基盤としてのR&Dの要素はそこまで強くありません。いま主にR&Dを進めているのは、エンバイロメント、つまり環境表現の分野ですね。

岡本氏：
方針としては、キャラクターはプロダクトごとに個別にサポートし、エンバイロメントについては前もっていろいろな引き出しを用意しておくようにしています。

キャラクターに関しては、各社から技術を吸い上げた結果、かなり多くのバリエーションに対応できるようになっています。一方でエンバイロメントも、完全に同じ見た目になるわけではありません。スタイライズ寄りからリアル寄りまで調整できるオプションもありますし、軽い表現を使うのか、負荷は高いけれどリッチな表現を使うのかといった最適化もできるようにしています。

──そもそもエンバイロメントはどういうゲームでもある程度共通化して使えるので、共通基盤としてありつつ幅も必要であると。エンバイロメントについて、現状のSiriusではどのような表現が実装されているのでしょうか。

岡本氏：
畳さんから後ほど詳しく説明してもらいますが、植物や「風」の表現はすでに実装済みです。ボリューメトリッククラウドを含めた空の表現についても、プロダクトレディの状態になっています。水面周りは、ちょうど現在開発しているところですね。

清原氏：
そのほかの例としては、リアルタイムの天候変化や時間変化にも対応しています。これはもともと事業部内に潜在的な需要がありました。過去のプロダクトでも、より進んだ天候表現を試してみたいという要望があったんです。ただ、そのときは工数の問題もあり、実際に検証する前に選択肢から外れてしまいました。

もしその時点で技術的な選択肢が用意されていれば、現場での検証も進み、いずれさらに品質の高い表現につながったかもしれません。そうした想いがきっかけとなって、Siriusに天候・時間変化の仕組みを導入しました。

gif削除しました

岡本氏：
昼夜の時間サイクル、晴れ・雨・曇りといった天候を断片的に切り替えるのか、それとも連続的にシフトさせるのかを選べるようにしています。ゲームによってはカチッと切り替えたい場合もあれば、境目が分からないようにシームレスに変化させたい場合もあると思います。できるだけ、どういう要望が来ても対応できるようにするのが目指すところですね。

ゲームの開発期間はプロダクトごとに決まっているので、その中に収まらない規模の取り組みもあります。そうしたものについて、コアテクが横断部署としてニーズを拾い上げ、応えていけたらと考えています。

Unityベースで、大規模運営型ゲームを

──Siriusが目指している水準や方向性はありますか。

岡本氏：
当社ではUnityをメインに開発していますが、最近はグラフィック表現に優れたUnreal Engine 5でモバイルゲームを開発する会社も増えています。そうしたタイトルにも対抗できる水準を目指しています。

また、ゲームは開発が始まってからリリースされるまでに数年かかります。だからこそ今の水準だけでなく、数年先に必要とされる品質やパフォーマンスを踏まえて開発しています。

たとえば天候表現については、いわゆるオープンワールド系のゲームで採用されている手法に基づいて開発しています。奇をてらうというより、広く使える汎用性の高いものにすることを意識しています。複数のプロダクトで使える基盤にすることが重要ですね。

──オープンワールドの開発も視野に入っていると。ほかの方はどのようなことをされているのでしょうか。

畳氏：
私は、パーティクルやプロシージャル生成を得意とする3DCGソフトウェア「Houdini」周りの整備を担当しています。

近年は、リッチかつスタイライズドな表現の人気も高まっており、サイバーエージェント内でもそうしたビジュアルのタイトルを開発できるようにしたいという需要が出ていました。ただ、大規模な開発になると、特にアセット周りで物量の問題が出てきます。そこでHoudiniが力を発揮します。

一方で、これまで各社にHoudiniのノウハウが十分に溜まっていたわけではありません。そこで事業部内で大規模タイトルの開発に関わる複数社にヒアリングし、やはりHoudiniは必要になってきそうだということで、R&D的に開発を進めてきました。

──3DCGのソフトウェアとしてはBlenderやMaya、Houdiniなどがあります。詳しくない方のためにHoudiniの強みを教えてください。

畳氏：
Houdiniは、プロシージャルなアセット制作を得意とする統合型3DCGソフトウェアです。たとえばBlenderやMayaは、端的に表現するならば、ろくろで陶器を作るように、最終的に見せたいモデルを直接形にしていくツールです。一方でHoudiniは、ノードと呼ばれる単純な処理をいくつも組み合わせ、その場で最終的なモデルを作っていくようなソフトです。データ的な要素が強いので、後から大きさを2倍にしたり、モデルを差し替えたりといった調整がしやすいんですね。大規模開発では、仕様変更による作り直しのコストが大きくなるため、効率面でもHoudiniは便利です。

ただ、特にモバイルゲーム開発ではHoudiniの導入がそこまで進んでいない面もあります。Houdiniは覚えるまでのハードルが高く、普段使っているツールとは考え方が違います。どちらかというとプログラム的にアセットを構築していくため、慣れていないアーティストさんには難しい部分があります。とはいえHoudiniは今後必要になってくる技術だと考えています。そこで、Houdiniを使うハードルをいかに下げるかという点に着手しました。

──具体的には、どのような取り組みをされたのでしょうか。

畳氏：
「Houdini Engine for Unity」を活用しました。これは、Houdiniのプロシージャル機能をUnityのエディター上で使えるようにするものです。

本来であれば、テクニカルアーティストがHoudini上でアセットを作り、それをUnityにインポートします。ただ、そもそもテクニカルアーティスト人材の数は限られていますし、仕様変更があるたびにテクニカルアーティストがアセットを調整する必要があります。仮にテクニカルアーティストが多かったとしても、Houdiniのライセンス料の負担もあります。

対してHoudini Engine for Unityは無料のツールで、Unity上でHoudiniのプロシージャル技術を用いたアセット生成ができるようになります。つまり、レベルや背景にHoudini製のアセットを配置したいアーティストやレベルデザイナーが、Houdiniそのものの仕組みを深く知らなくても扱えるようになる。テクニカルアーティストがプロシージャル生成用のファイルを用意しておけば、後は毎回介在しなくても作業できるので、ワークフロー自体が変わるんです。

ただし、Houdini Engine for Unityもそのまま利用するのではなく、使い勝手をよくするために改良したい場合があります。そこを各子会社が個別に対応するのは非効率なので、コアテク側で整備しているという流れになります。

──Siriusにおいて、Houdiniをどのように活用していますか。

畳氏：
基本的には、Houdiniがアセット、Siriusが描画を担当します。ただし、アセット側も少し複雑なことをしようとすると、描画と関わってきます。決まった仕様に沿って動いてほしい場合などですね。

たとえばSiriusでは、草や木を大量に配置し、それらを風で揺らす機能があります。本来は、風で揺れるための情報をアセット側に入れる必要があります。Houdiniを使えばそうした情報を入れやすいのですが、実際にそれを扱える人は限られています。

そこでSirius側に、描画側の仕様に合わせたアセットの生成を補助するHoudiniのツールを用意しています。各プロジェクトでSiriusの描画機能を利用しやくするための橋渡しをしているイメージですね。

──Houdiniは、社内ではどういった場面で使われることが多いのでしょうか。

畳氏：
子会社の方で大規模な破壊表現に導入したりしています。ハリウッド映画のような演出を想像していただければ分かりやすいと思いますが、破壊表現では大量の破片が発生します。それらをアーティストさんが手付けでアニメーションを付けるのは難しいんですね。その点、Houdiniはシミュレーションが得意なので、リアルな壊れ方や破片の飛び散り方を作りやすいです。

もうひとつはレベルデザイン用途です。たとえばフィールド内の川の流れを少し変えたいときに、Houdini Engine for Unityを使ってインタラクティブに変更する、といった使い方があります。Houdiniだと自然な見た目に仕上がりやすいので、そうした場面で使うことが多いですね。

──コアテクでは、VAT（Vertex Animation Texture）にも力を入れていらっしゃると聞きました。VATについても教えてください。

畳氏：
VATはVertex Animation Textureの略で、CPUで再生する3DCGのアニメーションデータをテクスチャとして保存し、GPUで読み込むことでCPU負荷を軽減する仕組みです。

ちなみにこれは宣伝になりますが、7月に開催されるCEDEC2026でVATについて講演する予定です（講演URL）。そこでは、Houdiniを使ったVATの導入と、それを基盤としてどのように子会社へ展開したかという2つのテーマでお話しする予定です。

VAT自体はテクスチャを読むだけなので、仕組みとしては意外とシンプルです。ただし実際にプロジェクトで使うには、使用メモリが増大するリスクや、そもそもVAT素材をどう用意するのかといった課題があります。

そうした課題に対し、Houdiniを活用することで解決できる部分があります。ただ、世の中に出回っているHoudiniの資料が少し古かったり、Unity上で扱う際の細かなワークフローや注意点があったりするんですね。そこでHoudiniでVATを作り、Unityで素早く使える状態にする機能をSiriusに実装しました。

CEDECでは、アセット生成やUnity側の操作など、イテレーションを回すうえで便利な方法を再現性のあるかたちで伝えたいと考えています。

──お三方の担当領域はかなり違うんですね。

清原氏：
そうですね。ただ、エンバイロメントの開発とHoudiniは密接に関わっているところがあります。

岡本氏：
大規模なゲームでは、アセットに求められる数や種類が非常に多くなります。そこでHoudiniを活用し、必要なアセットをたくさん作ろうというのが開発の上流にあります。ここが畳さんの担当領域ですね。

そして、それらをUnityに持ってきた後に、できるだけ多く表示したい、あるいはパフォーマンスを考えて調整したいという部分を私が担当しています。アセットを作る部分と、描画・最適化する部分で役割分担している形です。

──最適化において苦労している点はありますか。

岡本氏：
Unityを魔改造しているわけではないので、やはりメモリや処理性能の限界にどう立ち向かうかという問題はあります。特に処理負荷については、単に動けばいいというものではありません。最初は遊べても、しばらくすると端末が熱くなって遊べなくなる、といったこともあります。実際の動作まで考慮して対応する必要があります。

モバイル向けに開発する以上、そこは避けて通れません。制約が多い中で、いかに品質を高めるかが腕の見せ所だと思います。