本連載では、CG映像制作におけるテクニカル系スタッフの仕事の現状と課題を、パイプライン開発の専門家である痴山紘史氏（日本CGサービス（JCGS）代表）が探っていく。第14回では、Netflixシリーズ『今際の国のアリス』や映画『果てしなきスカーレット』をはじめ、ゲーム『カービィのエアライダー』のティザームービー、『龍が如く 極３ / 龍が如く３外伝 Dark Ties』のイベントシーンなどを手がけるデジタル・フロンティアを取材。

実写VFXからセル調アニメ、ゲーム、フルCGアニメーション、VTuberまで、幅広いジャンルのCG映像制作を支えるパイプライン開発とワークフロー設計、さらに、その中核を担うResearch and Development（以下、R&D）およびテクニカルディレクター（以下、TD）の役割について、前後編にわたって掘り下げる。

幅広い制作案件を支えるTechnical Division

山口泰史氏（以下、山口）：デジタル・フロンティアはCGスタジオとして、実写VFXやゲーム、セル調アニメ、フルCGアニメーションなど、ジャンルを限定せず幅広いCG映像制作を手がけており、最近ではVTuber案件にも取り組んでいます。案件の割合としてはゲーム関連が多く、およそ半分を占めています。

栗原翼空氏（以下、栗原）：ゲームだけを見ても、オープニングムービーやカットシーン全体を演出も含めて担当する案件もあれば、モデルアセット制作、アニメーション制作、リギングといった工程単位で参加する案件もあります。

山口：東京の本社でCG制作に携わるスタッフは約190名です。このほかに遊技機開発部門もありますが、制作体制は私たちとは分かれています。

案件によっては、企画からアセット制作、アニメーション、エフェクト、ライティング、コンポジットまで、複数の工程を横断して一括で担当します。大規模な案件にも対応できるよう、プロジェクトごとに必要な制作体制を構築しています。 

もうひとつ特徴的なのが、お台場に日本最大級のモーションキャプチャスタジオの「オパキス」を構えていることです。モーションキャプチャだけで完結する案件では、他の制作部門とは独立して稼働したりもします。また、名古屋にAM部があり、台湾にも子会社があるので、案件によっては連携しながら制作を進めています。

これだけ多様な制作現場を支えなければならないため、テクニカル部門としては難度の高い環境でもあります。映画だけを制作する会社であれば、ある程度ワークフローを統一できます。しかし当社が扱う案件の幅は非常に広く、特にゲーム案件は、クライアントやタイトルごとに仕様がまったくちがいます。

例えば、「このドライブ構成を使ってほしい」と指定されても、そのまま社内環境へ適用できるとは限りません。先方のワークフローへ対応しつつ、社内でも無理なく運用できるかたちへ調整する必要があり、案件ごとに最適な運用方法を設計しています。

齊藤 弘氏（以下、齊藤）：そうした制作現場を技術面から支えているのがTechnical Divisionです。Technical Divisionは「開発室」と「TD室」で構成されており、私は開発室、山口はTD室の室長を務めています。

開発室では、OSSのビルドやライブラリ管理、ライセンス確認、パイプライン基盤の開発など、共通インフラにあたる部分を担当しています。3名程度の少人数体制で、各プロジェクトに近い領域については、TD室と密接に連携しながら開発を進めています。

山口：TD室は、業務委託メンバーを含めて約14名の体制です。

齊藤：開発室が共通基盤を整備し、その上で各プロジェクトに合わせたワークフローの構築や運用をTD室が担当しています。両者が連携することで、多種多様な制作案件を技術面から支えています。

R&DとTDを担う4人のキャリア

齊藤：私は神奈川工科大学でCG映像やゲームのプログラミングを学び、CGスタジオでのアルバイトを経て、2011年に新卒でデジタル・フロンティアへ入社しました。

入社後は既存プラグインの保守・開発を担当し、その後はDCCツールの起動管理やワークフローの自動化、社内で開発していたリアルタイムエンジンの保守・開発などを担当しました。現在はパイプラインやシステム全体の設計を中心に携わっています。

山口：私は大学では経営学を専攻していましたが、卒業後にCG系の専門学校へ進学し、2012年頃にデザイナーとしてデジタル・フロンティアへ中途入社しました。

転機になったのは、デザイナーとして仕事をする中で、作業効率化のためのツールを自作し始めたことです。次第にプログラミングを専門にしたいと考えるようになり、R&Dへ異動しました。当時はNuke向けツールやV-Ray用シェーダ、自社製リアルタイムエンジンの開発などを担当していました。

その後、Unreal Engine（以下、UE）を活用した案件が増えてきたことから、リアルタイムCG制作をより現場に近い立場で支えるため、現在はTD室に所属しています。

栗原：私はHAL東京のゲーム学科を卒業し、2021年に入社しました。学生時代にゲームエンジンを開発していたこともあり、当初はR&Dを志望していましたが、山口から「TDに向いている」と勧められ、TD室へ応募しました。

入社当時は、社内パイプラインとUEとの連携基盤がまだ整備されていなかったため、その構築から始めました。現在はリアルタイム案件を中心に担当しています。

浅野晃汰氏（以下、浅野）：私はゲーム系の専門学校を卒業し、学校からの紹介をきっかけに2019年にデジタル・フロンティアへ入社しました。そのとき初めて、TDという職種の存在を知りました。

入社後は、ショット情報を取得し、社内で閲覧・編集するためのツール開発から担当しました。もともとはゲームプログラマー志望だったため、UI開発は未経験でしたが、勉強しながら開発を進めていました。

その後はアニメーション制作のワークフロー整備を担当するようになり、現在はアニメーションパイプラインの設計やデータフローの構築、納品用データの変換処理などを中心に担当しています。

リモートワークを支える制作環境

山口：勤務形態は、コロナ禍以降しばらくリモートワークが中心でしたが、現在は部署ごとに異なります。テクニカル部門と制作部は全員出社へ移行しており、それ以外の部署については、チーム単位で月1回以上、個人では週1回以上、合計で月5日以上出社するというルールを設けています。後は各チームの裁量に任せていて、毎日出社したい人はもちろん出社できます。

齊藤：リモートワークへ移行した当初は、色を正確に確認できるか、ペンタブレットが問題なく使えるかなど、制作環境の検証にかなり時間をかけました。当時はネットワーク帯域も十分ではなかったため、テレワーク用インターネット回線を増強し、自宅でも社内と同じように作業できる環境を整備しました。

現在は制作マシンをサーバルームへ集約し、ゼロクライアント経由で利用する運用へ切り替えています。そのため、社内で作業するときも、自宅からアクセスするときも、基本的には同じ制作環境を利用できます。

山口：リモートワーク環境の構築で最も苦労したのは、システム室だったと思います。自宅に十分な機材がないスタッフには、余っていたモニタやPCを貸与したり、ゼロクライアント端末を自宅へ持ち帰ってもらったりと、様々な対応を行なっていました。私たちは、彼らが整備してくれた環境を利用する立場でした。

齊藤：もうひとつ大きな課題だったのが、コミュニケーションです。リモートワークではどうしても雑談が減ってしまうため、チャットに加えてバーチャルオフィスサービスの「ovice」を導入しました。

齊藤：誰がどこにいるのかがひと目でわかり、近くにいる人へ自然に声をかけられるので、オフィスで隣の席の人へ話しかけるような感覚を、バーチャル空間でも再現できます。現在も利用していますが、出社が増えたこともあり、利用頻度は以前より落ち着いています。

その後はGoogle Workspaceを導入し、Google Meetも全社員が利用できるようになりました。それ以前はZoomのライセンス数に限りがあり、会議時間を気にする必要がありましたが、その課題も解消されています。

山口：ただ、コミュニケーションツールをひとつに統一しているわけではありません。用途に応じて使い分けています。画のチェックでは、色の再現性や通信遅延の回避が重要になるためZoomを利用しています。 Google Meetは事前に日時を設定した会議、oviceは少し相談したいとき、という使い分けです。

浅野：TD室でも、リモート環境でコミュニケーションをどう維持するかは、よく話し合っていました。夕方に雑談の時間を設けたり、ゲーム大会やZoomでの交流会を開いたり、ワーケーションを実施したりと、意識的に会話の機会をつくっていました。

山口：一方で、コロナ禍をきっかけに定着した文化もあります。以前は打ち合わせといえば会議室へ移動するのが当たり前でしたが、現在は出社していてもGoogle Meetを使うことがあります。

会議室へ移動すると作業の手を止める必要がありますが、オンラインであれば自分の画面を共有しながら相談でき、そのまま作業も続けられます。相手の席まで移動せずに済むことも含めて、業務効率の向上につながっています。

「どんなデータにも対応する」パイプライン基盤

齊藤：現在運用しているパイプラインは「2.0」と呼んでいるもので、2015年頃から開発を始めました。それ以前にもTD主導で構築したパイプラインはありましたが、2.0ではR&D（開発室）が共通基盤を整備し、その上に各プロジェクトのワークフローを乗せていくかたちへ再設計しています。

開発にあたって意識したのは、現場へのヒアリングやテストを重ねながら、日々の作業をできるだけ省力化・共通化することです。加えて、特定のDCCツールやOSに依存しないことも重視しました。単にツールを増やすのではなく、理想的な作業環境を基盤からつくるという考え方です。

最初に取り組んだのは、用語の定義でした。「アセットとは何を指すのか」、「バージョンとは何を意味するのか」といった基本的な概念から認識を揃え、その上で、データをどうながすのか、どのようなルールで管理するのかを定めていきました。

まずルールを設計し、それを実現するためのライブラリやツールを構築する。この順序で開発を進めています。基盤には、ネーミング規則やデータのプロパティ、型など、パイプライン上のルールを扱うPythonライブラリ群があります。例えばdfp Managerというしくみがあり、各ツールはこの共通基盤を利用しながら動作しています。

R&Dは、プロジェクトやDCCツールに依存しない共通領域を担当しています。具体的には、パイプラインライブラリやサーバ側のしくみ、稼働状況の可視化、台湾の子会社へのツールとデータの自動同期などです。

その基盤の上で、各プロジェクトのワークフローに合わせたツールや処理を構築するのがTDです。どのアセットを集め、どのようなかたちでシーンを構築するのかは、プロジェクトやチームによって異なります。そのためTD側で設定や処理を記述し、現場へ提供しています。

山口：基盤自体は、最初の3、4年でおおよそ整ったと思います。その後も運用しながら改修を重ねており、全体としては10年ほど続いている取り組みです。

私も当初はR&Dに所属しており、名称や構成をどう整理するかを考えたり、アセット管理ツールの原型をつくったりしていました。

現場の要望に素早く応えるための共通化

山口：TD室が意識しているのは、特定の技術やツールを導入すること自体ではなく、現場のデザイナーができるだけ迷わず、より良い画づくりへすぐに取りかかれる環境をつくることです。 

TD室のメンバーは、基本的には全員エンジニアです。デザイナーとして直接制作作業を行うことはほとんどありません。

ただし、現場から完全に離れているわけではありません。リアルタイム案件ではシェーダの構築など、画づくりに近い領域まで担うこともあります。UEなどのリアルタイムエンジンに関わる作業をデザイナーだけで完結させるのは難しいため、そこはTDが技術面から支えています。

齊藤：R&DとTDでは、開発の進め方にもちがいがあります。R&Dはライブラリや基盤など、ひとつのものを継続的に開発することが多いため、Gitを中心に使用しています。

一方でTDは、複数のツールやプロジェクトを横断しながら、現場の要望へ素早く対応する必要があります。例えば「このデータを変換できるようにしたい」、「この作業を自動化したい」といった相談に対して、すぐに試せる状態でツールを提供することが求められます。 その機動力を重視し、TDではPerforceを使うという住み分けをしています。

山口：TDでは、ローカル環境で作成したツールをPerforceに登録し、デザイナーが直接編集できないツール専用領域へパブリッシュします。そこから現場に使ってもらう、というながれです。

TDにとって重要なのは、現場から「こういうものがほしい」と相談されたときに、すぐにつくって提供し、試してもらえる距離の近さです。ただし、機動力を高めるために何でも自由にしているわけではありません。むしろ逆で、開発環境やコードの書き方はできるだけ揃えるようにしています。

私が室長になった頃は、使用するエディタもコードの書き方も、人によってばらばらでした。デザイナーが使う環境は私たちが整備して統一しているのに、その環境をつくる側の開発環境が統一されていなかったわけです。

そこで、使用するエディタ、コードの書き方、ツール内部の構成などを少しずつルール化していきました。例えばGUIをもつツールであれば、処理を書く部分とUIを書く部分を分ける。変数名、関数名、ファイル名の付け方も揃える。そうした基本的なルールを整えていきました。

以前は、本当に各自が自由にコードを書いていました。時間をかけて「これはこう書きましょう」と共有し、新しく入ったメンバーにも同じ書き方を教えながら、少しずつ揃えていきました。

山口：コードの再利用性を高め、別の案件へ展開しようとしたときに、人によって構成や書き方が大きく異なると、そこで開発が止まってしまいます。他のメンバーが書いたコードを見ても、おおよそ何をしているのか理解できる状態にしておくことが、結果的にTDの機動力につながっています。

浅野：以前の担当者が独自に開発していたコードを見ると、現在とは書き方がかなり異なるため、読み解くのに苦労することがあります。現在のコードは構成や書き方がおおよそ揃っていますし、関数にどのような値が必要なのかといった型の情報も書かれているので、開発しやすくなっています。

山口：細かく見れば個人の癖はありますが、変数名、関数名、ファイル名の命名規則など、かなり細かいところまで揃ってきています。フォーマッターやリンターで全てを機械的に強制しているわけではありませんが、誰かが共通部品やライブラリをつくったときに、他のメンバーも手を加えやすい状態にはなっています。

齊藤：ツールの格納場所についても、OSごとのディレクトリ構成や設定ファイルの位置、どこでバージョンを分けるかといった基本的なルールがあります。そのルールの中で、個々のツールにはある程度の自由度をもたせています。

山口：使用しているOSは、ほぼWindowsです。映像制作、特に海外のスタジオではLinuxを使う会社も多いと思いますが、ゲーム会社はWindows中心です。当社は映像とゲームの両方を扱っているため、案件ごとに環境を丸ごと切り替えるわけにはいきません。そのため、どうしてもWindowsが中心になります。

一部のエフェクトシミュレーションではLinuxを使うこともありますが、TDのツールを全てLinuxで動作するように厳密につくっているわけではありません。

齊藤：エンジニアの中だけで完結するのであれば、Linuxの方が便利な場面もあります。ただ、最終的にツールを使うのは現場のデザイナーです。導入の容易さや、普段の制作環境との相性を考慮するとWindowsの方が適しています。

山口：デザイナーにターミナル操作を前提としてもらうのも現実的ではありません。そのため、できるだけGUIを用意し、普段使っているDCCツールの延長で扱えるようにしています。 以前はGUIをひとつつくるだけでも大変でしたが、現在は共通部品が整っているため、以前ほど時間をかけずに現場へ提供できるようになりました。

現場の近くで素早くつくるために、裏側ではできるだけ共通化しておく。TDの開発は、そうした考え方で成り立っています。

本記事の後編は、2026年8月公開予定です。