本連載では、CG映像制作におけるテクニカル系スタッフの仕事の現状と課題を、パイプライン開発の専門家である痴山紘史氏（日本CGサービス（JCGS）代表）が探っていく。第14回では、多様なジャンルのCG映像制作を手がけるデジタル・フロンティアを取材。前編では、幅広い制作案件を支えるTechnical Divisionの体制と、約10年にわたって整備・改良されてきたパイプライン基盤について紹介した。

後編では、USDを組み込んだワークフローの構築、Unreal Engine（以下、UE）を用いた案件への対応、生成AIによる開発の効率化に焦点を当てる。新しい技術を実制作へ落とし込む過程で生じる課題と、それらに向き合うResearch and Development（以下、R&D）およびテクニカルディレクター（以下、TD）の役割、さらにAI時代に求められる人材像を掘り下げる。

MayaとHoudiniをつなぐUSDワークフローの構築

山口泰史氏（以下、山口）：Netflixシリーズ『今際の国のアリス』におけるUSDの活用は、主にHoudiniを扱うエフェクトチームと、そこに関わるTDによって、現場主導で進められました。まずは実制作で試し、一定の成果が得られたことで、「今後も取り入れていく必要がある」という認識が社内に広がっていきました。

山口：現在進行中の大規模作品では、この取り組みをもう一段進め、USDを正式なワークフローとして組み込むために、Technical Divisionが中心となって環境を構築しています。ただし、全社的にHoudiniへ移行したわけではなく、現在も多くの作品でMayaを使用しています。まずはこの大規模作品をひとつの実証例とし、成果が得られれば、今後ほかの作品にも展開していこうとしている段階です。

USDの導入に伴って、パイプラインそのものを変更したわけではありません。もともと、どのようなデータにも対応できるようにパイプラインを設計しているため、今回行なったのは、ワークフロー上でどのようなデータをパブリッシュし、それらをどう組み上げるかという部分のカスタマイズです。このプロジェクトで得られた知見は、DF TALKの「USDをワークフローに取り込んでみてわかったこと」でも公開しています。

今回のワークフローでは、エフェクト、ライティング、最終レンダリングをHoudini（Solaris）で行い、それ以外の工程は主にMayaとMotionBuilderで進めています。アセット制作では、従来のMaya向けデータと併せてUSDデータを出力します。その後、ボディやフェイシャルのアニメーションなどはMayaで制作し、各工程から必要なキャッシュをUSDとしてパブリッシュします。最後に、それらをHoudiniのライティング工程で組み上げるというながれです。

ルックデベロップメントにはMayaとArnoldを使用し、最終レンダリングはHoudiniのKarmaで行なっています。そのため、両者のレンダリング結果ができるだけ近くなるように調整しています。完全に一致させることはできませんが、おおよそ同じ見た目になるところまでは合わせています。マテリアルのパラメータをそのまま移しただけでは同じ画にならないため、ひとつずつ地道に調整しています。

一方で、USDを適用しやすい作品と、そうでない作品があるとも感じています。リアル寄りの作品や実写VFX、フルCG作品には展開できる可能性がありますが、セル調のアニメ作品への適用は、まだ難しいのが実情です。USDの標準的なシェーディング環境だけでは、セル調表現に必要な機能が十分に揃っていないためです。

セル調表現に限らず、実際にUSDを使い始めると様々な問題が出てきます。そのひとつが、DCCツールごとに異なる単位系の扱いです。これまで社内では、Maya上で扱いやすい縮尺に合わせてアセットを制作することが多かったのですが、今回はUSDやHoudiniとの連携を考慮し、従来とは異なるスケールを採用しています。

Hairについても、MayaからUSDデータとして出力するだけでは処理できない部分があるため、Houdini側から別途データを出力するなど、工程ごとに対応方法を変えています。

そのため、現時点では、まだ「これが最適なワークフローだ」と言えるかたちにはなっていません。Maya、Houdini、USDそれぞれの実装が発展していけば、いずれ定番となるかたちが見えてくると思います。ただ、今はまだ実制作を進めながら、そこで生じる問題をひとつずつ解決しているところです。

ゲーム、映像、VTuber案件を支えるUEワークフロー

栗原翼空氏（以下、栗原）：UEに携わる機会が多いのは、ゲーム案件のクライアントから依頼される仕事です。こうした案件では、クライアントから提供されたUEの開発環境をベースに制作を進めます。

浅野晃汰氏（以下、浅野）：UEを最終環境として使用する場合、特にアニメーションでは確認事項が増えます。通常の案件では基本的にはMayaやMotionBuilderでアニメーションを制作し、Maya上で作業者が確認することで、素材としての品質を担保しています。

浅野：ただし、最終的にUEを使用する案件では、Mayaで制作したアニメーションがUE上でも正しく再現されるよう、TDが開発した出力ツールによって品質を担保しています。その上で、UE上でも最終的な挙動を確認します。また、クライアントから「アニメーションをフルベイクしないでほしい」と指定されることもありますが、ベイク方法を変えると、アニメーションやシミュレーションの結果に差異が生じる場合があります。

その場合は、アニメーション作業の後工程を担当する方と連携し、それぞれの結果を重ね合わせながら、問題が発生している箇所と原因を切り分けていきます。MayaやMotionBuilderからのFBXデータの出力に問題があれば、FBX自体を調整することもあります。自分たちのツールとDCCツール側のどちらに原因があるのかを突き止めるところまで含めて対応しています。

山口：ゲーム案件では、制作の終盤までデータの更新が続きます。途中でリグの構造が変わったり、アセットによってジョイント名がわずかに異なっていたりすることもあるため、その都度対応しなければいけません。

こうした問題を早い段階で発見するため、MotionBuilderのPlayblast、Maya上の表示、UEでのレンダリング結果を工程ごとに比較しています。補助骨の計算など、DCCツールによって挙動が異なる部分もあるため、動きが一致しているかだけでなく、シルエットが崩れていないか、意図した形で再現されているかまで確認します。

あるゲーム案件では、全てのアニメーターの制作環境にUEを導入しました。ライティング済みのシーンにキャラクターとアニメーションを読み込み、最終的な画に近い状態まで、アニメーター自身が確認できる体制を構築したんです。それまで当社では、アニメーターが最終環境で自ら結果を確認することは少なかったので、新しい試みでしたね。

栗原：一方、映像案件では、プレイ可能なゲームをつくることではなく、UEを使って映像を制作し、最終的に映像素材を出力することが目的となります。そのため、デザイナーの作業は、ビューポート上での画づくりと確認が中心になります。こうした映像制作特有の使い方に合わせて、UEの環境やツールを整備する必要があります。

UEのプロジェクトは、既存のパイプラインにそのまま乗せることができません。Mayaであれば、サーバ上のデータを直接リファレンスしてシーンを構築できますが、UEでは必要なデータをエンジン内へ取り込む必要があります。そのため、パイプライン上のデータを取得し、UE側でシーンを構築できるしくみを用意しています。

それを担うのが、TDが開発した共通ツール「WorkfileManager」です。パブリッシュ済みのデータを読み込んでUE上にシーンを構築できるほか、UEから出力された素材をパブリッシュすることもできます。

栗原：映像用途では、色の扱いにも特有の問題があります。UEには独自のトーンマッパーがあり、そのまま素材を書き出すと、UEのトーンマッピングが適用された色になってしまいます。そのため、意図しない色変換が加わらない状態で、UEから素材を出力できるように調整しています。

こうした映像用途特有の問題は、デザイナーだけで解決することが難しい場合があります。それらに対応し、デザイナーがストレスなく制作に集中できる環境を整えることも、TDの役割だと思っています。

自社で企画・運営しているVTuber「マリア・ブーゲンビリア」では、また異なるかたちでUEを活用しています。現在はYoutubeやTikTokを中心に活動しており、配信と運用を支える基盤部分のツールは、私がイチから開発しました。

栗原：実際に操作するアクターさんと話し合いながら、どのようなUIであれば使いやすいのか、どのような機能が必要なのかを詰めていきました。配信サービスと連携し、視聴者からの反応や名前などを画面上に表示するしくみも実装しています。

栗原：アクターさんがひとりで自宅から配信する場合でも負担にならないよう、ひとつの画面内で必要な操作を完結できる、使いやすいUIを目指しました。自社企画だったので、既存の環境に合わせるのではなく、配信のしくみそのものから構築できました。

山口：UE上でシーンを構築する方法は、これまでの制作方法とは大きく異なるため、TDにとっては大変な部分もあります。ただ、そこにこそ、私たちがいる価値があるのだと思います。新しい技術や制作方法は次々に入ってくるので、その都度、テクニカル部門と制作現場の双方が対応していかなければいけません。そうした変化を持続可能な方法へ落とし込むことが、私たちの仕事なのだと思います。

生成AIの安全な活用と、パイプライン開発の効率化

齊藤 弘氏（以下、齊藤）：開発業務にAIを使い始めたのは、3年ほど前です。最初に社内へ導入したのはGitHub Copilotで、既存のコードをふまえて、コードの補完や生成を支援してもらう使い方が中心でした。導入にあたって重視したのは、公開されているコードと一致する提案を抑制できるか、入力した情報がどのように扱われるかという点です。システム部門とも相談し、契約内容や設定、入力してよい情報の範囲を確認した上で利用しています。

山口：現在は、Claudeについても社内で少しずつ利用を始めています。ただし、ここでお話ししているのは、Technical Divisionが社内ツールやパイプラインを開発する際の利用です。CGの画づくりには使用していません。また、プログラムコード自体を成果物として納品するAM事業部も、今回お話ししている利用範囲には含まれていません。

開発用途であっても、案件ごとの条件や情報の取り扱いを確認し、クライアントから預かったデータに関わる部分には十分注意しています。単に「会社としてAIを使っている」と説明するのではなく、どの部門が、どのような目的と範囲で利用しているのかを明確にする必要があると認識しています。

齊藤：制作現場におけるAI活用については、昨年、社内向けのガイドラインも策定しました。禁止事項を並べるのではなく、どのようなリスクがあり、利用前に何を確認すべきかをチェック項目として整理しています。利用するサービスの仕様や契約内容、案件ごとの条件を確認した上で、安全性を確保できる範囲で活用を進めるという考え方です。

山口：社内でも、立場によってAIに対する見解は異なります。経営層や制作現場には新しい技術を活用したいという思いがある一方で、システムやセキュリティを管理する部門は、安全性を確認できないものに対してブレーキをかけなければいけません。

どちらかが間違っているわけではなく、AIを使いたい側と、情報や制作環境を守る側の双方が納得できる利用範囲を探っている段階です。難しい調整ではありますが、避けては通れない部分だと思います。

齊藤：今後を考えると、AIはすでに無視できない存在です。「使うか、使わないか」ではなく、「どこで、どのように使うか」を考えなければいけません。当社のパイプラインには、この10年ほどの運用を通じて様々な情報が蓄積されています。それぞれのデータが何を意味するのか、アセットとショットがどのような関係にあるのかといった情報も、パイプライン上のルールとして整理されています。

そうした情報をAIにどう扱わせ、パイプラインやツールの提供方法をどう変えていくかは、これから取り組むべき課題です。必ずしも、全てを社内インフラだけで完結させることが最適とは限りません。利用条件や情報の取り扱いを確認した上で、クラウドサービスを活用する可能性もあると思います。

AIに限らず、USDやOpenPBRなど、新しい標準規格やオープンな技術も次々に登場しています。そうした技術も取り入れながら、パイプラインを継続的に更新していきたいと考えています。

もちろん、新しい技術を試したからといって、すぐに実制作で使えるとは限りません。検証した結果、問題が多く、「今回はこの作品での採用を見送ろう」と判断することもあります。それでも継続的に動向を追い、実用に耐えられる段階に達したものから制作へ取り入れていきたいですね。

山口：TDの立場から見ると、生成AIによって開発コストをどこまで圧縮できるかは、今後かなり重要になると思います。生成AIの登場によって、従来は多くの時間と人手を要した表現を、短時間で実現できるようになりつつあります。それに伴い、制作物に対する価格も、業界全体として下がっていく可能性があります。

一方、制作会社には、クライアントから預かったデータを守り、人が責任をもって制作した成果物を提供することが求められています。それが会社への信頼にもつながります。ただ、「人の手でつくるから高くて当然」と言うだけでは、競争力を維持できません。

だからこそ、生成AIを直接的な画づくりに使用しない場合でも、その裏側にあるツール開発やパイプライン整備を効率化し、制作全体のコスト構造を改善する必要があります。そこは、TDが取り組むべき領域だと考えています。

現在は、プロジェクト固有の対応、いわゆる「show対応」にかなりの時間を費やしています。案件ごとに設定やツールを調整し、過去のコードから利用できるものを探し出して、現在の要件に合わせて修正する作業が数多くあります。こうした作業をAIによって効率化できる体制が整えば、開発の進め方は大きく変わると思います。

過去に開発した資産も大量にありますが、担当者がすでに退職していたり、仕様がわからなくなっていたりと、十分に活用できていないものがあります。現在も動いてはいるものの保守できないコードや、よく似た機能をもつツールが別々に存在しているケースもあります。

そうした過去のコードをAIに解析させ、処理内容や構造を整理することで、現在の環境でも再利用できる手応えを感じています。これまでであれば、コードを読み解くために必要な時間を考えて、活用を諦めていたような資産にも、再利用の可能性が生まれています。

そこで生まれた余力は、新しい技術や表現への取り組みに振り向けなければいけません。従来と同じ仕事を低コストでこなすことだけを目的とするのではなく、生成AIによる開発の効率化を、次の制作方法やしくみを生み出すことにつなげていきたいですね。

AI時代のTDやR&Dに求められる基礎力と「思い」

山口：AI技術の発展は、これからの開発チームのあり方にも大きな影響を与えると思います。今後は、AIを適切に使いこなせることが、最低限求められるスキルになっていくのではないでしょうか。

その上で、さらに重要になると感じているのが、AIが生み出す成果を管理し、開発全体をリードする力です。AI自体の能力が高くなるほど、何を任せ、どの方向へ進ませるのかを人間が判断しなければいけません。実装する力だけでなく、全体を設計する力が、これまで以上に重要になると思っています。私自身も現在そうした部分を重点的に勉強しています。

ただ、マネジメントやリードする力は、本来であれば、新人に最初から求めるようなものではありません。一方、これから入社する世代にとっては、学生の頃からAIを使うことが当たり前になると思います。AIに何を指示し、返ってきた結果をどう評価するかという経験は、学生のうちから積むことができるのかもしれません。

実際に新人を育成する中でも、AIへどのように指示するかは非常に重要だと感じます。AIを使ってツールを開発しても、出力されたコードをそのまま受け入れてしまうと、中身を確認したときに、とても使える状態ではなかったということがありえます。AIを適切にコントロールして目的に合ったものをつくらせ、最後は人間が内容を確認し、正しいかどうかを判断できなければいけません。

これまでは実務経験を積む中で身につけてきたような判断力が、今後はキャリアの早い段階から求められるようになるかもしれません。そこに、AI時代ならではの難しさがあると思います。

齊藤：AIを使うからこそ、コンピュータサイエンスや数学の基礎知識は、これまで以上に重要になると思っています。例えばソケット通信のしくみを理解していることや、コンピュータの内部で何が起きているのかを頭の中でイメージできることです。

基礎がなければ、「なぜAIがこの結果を出したのか」、「実現したいことに対して、どのような指示を与えるべきか」を考えることができません。エラーが起きたときにも、原因を切り分けられなくなってしまいます。そのため、私も普段から部下に対して、「なぜ、この結果になっているのか」を考えるように伝えています。

コンピュータサイエンスや数学の基礎は、AIによって不要になるのではなく、むしろ重要性が増していくはずです。採用においても、表面的な結果だけではなく、その背後にあるしくみを考えられる人かどうかは、ひとつの判断軸になると感じています。

それに加えて、私たちは映像制作会社なので、「映像が好きだ」という思いも必要です。「AIを使いたい」、「AIで何かをやりたい」ということが目的なのではなく、つくりたい映像があり、それを実現する手段としてAIを使っている人に来てもらいたいと思っています。

山口：新人を採用するときに惹かれるのは、誰かを支えることが好きな人ですね。学生時代にツールをつくり、それを使ったチームのメンバーが良い結果を出してくれたことが楽しかった、面白かったという話を聞くと、一緒に働きたいと思います。

最近、部下にもよく話しているのですが、単に「これが好きです」と言うだけではなく、その思いが、これまでの行動や経験として積み重なっている人がいいと思っています。「良い映画をつくりたい」というのも、そのひとつですよね。

結局、最後に求めるのは「思いがある人」なのだと思います。思いは、AIにはないものなので。

筆者まとめ

デジタル・フロンティアのTechnical Divisionは、約10年にわたってパイプラインを運用・改良しながら、その上に様々な制作案件へ対応するための知見を積み重ねてきました。

現場に近いTDが培った知見を、R&Dが共通基盤として整理し、両者が連携しながら継続的に運用できるしくみへ育てていく。それは重要である一方、決して容易なことではありません。しかし、柔軟に拡張できる基盤があるからこそ、USDやUEといった新しい技術も、実制作のワークフローへ取り込むことができるのでしょう。

今回の取材では、生成AIが開発現場を変えつつある状況も浮かび上がりました。AIを使うか使わないかという二者択一ではなく、利用する部門や目的、扱う情報の範囲を明確にした上で、安全性を確保しながら、開発の効率化やパイプラインの更新へつなげようとする姿勢が印象に残りました。

AIによって過去の開発資産を再利用し、日々の開発やプロジェクト対応を効率化する。そして、そこで生まれた余力を、新しい技術や表現へ振り向ける。AIの導入を単なるコスト削減で終わらせず、次の制作方法やしくみにつなげようとしている点も、デジタル・フロンティアらしい取り組みだと感じます。

最後に語られた「思いは、AIにはない」という言葉は、技術が大きく変わる中で、Technical Divisionが何を大切にしているのかを端的に表しているように思いました。