CEDEC 2025 レポート：映画・ゲームシネマティック制作を支えるDispatcherシステムの裏側

こんにちは。ゲームソリューション部の出村です。

ここでは、「映画制作・ゲームシネマティック作成を支えるJob管理・レンダーファーム運用におけるDispatcherシステム」というセッションについてレポートします。マーザ・アニメーションプラネット社（以降、マーザ社と表記）の制作現場では、ワークフローの個々の業務をどのように自動化して業務効率を向上させているかについて述べられていました。

セッション内容

映画制作・ゲームシネマティック作成を支えるJob管理・レンダーファーム運用におけるDispatcherシステム
「ソニック×シャドウ TOKYO MISSION」や「たべっ子どうぶつ THE MOVIE」をはじめとする映画作品だけでなく、Live映像作品やゲームシネマティックムービー制作において、レンダーファーム・Asset管理・Job管理を担うDispatcherの運用についてご紹介します。

これらのノウハウを通じて、各DCC（デジタルコンテンツ作成ツール）への展開方法や、作品制作における調整法、運用法などについても詳しく解説します。

内容について

このセッションでは、高品質な映像制作の現場を支える、自社開発のDispatcherシステムについて、その役割から具体的な運用事例まで詳しく解説されていました。

Dispatcherとは

Dispatcherとは、レンダリングジョブを複数のコンピューターに効率的に分散・配信するためのソフトウェアです。

例えば、映画の1シーンで1000フレームのレンダリングが必要な場合、Dispatcherが10台のコンピューターに各100フレームずつ処理を自動で割り振ります。これにより、1台のマシンでは10時間かかるような重い処理を、わずか1時間で完了させることが可能になります。

アニメーション制作の全体フロー

アニメーション制作は、大きく分けて「プリプロダクション」「プロダクション」「ポストプロダクション」という工程で進められます。今回のセッションでは、特に多くのトライアンドエラーがあり、データ処理が集中する「プロダクション」と「ポストプロダクション」の工程が中心に解説されました。

プロダクションはライティングやレンダリングなどを行い、ポストプロダクションではそこで生成された素材を合成し、最終的な映像に仕上げていきます。Dispatcherは、これらの工程間で発生する繰り返しの作業や、工程間のデータ受け渡しを自動化し、効率化するために開発されたとのことです。

パイプラインとタスク

プロダクション工程には、スライドに示されているように非常に多くのタスクが存在します。各タスクでは、処理の重い作業を「Job」としてサーバーに実行させたり、複数のJobを組み合わせて一連の処理を自動化したいというニーズが常に存在します。これらの要求を実現し、制作環境の統一を図るために「パイプライン」と呼ばれる仕組みが存在します。

パイプラインとワークフロー

セッションでは、「パイプライン」と「ワークフロー」の違いについても定義されていました。

「パイプライン」が、Dispatcherなどを用いてタスクの自動化を実現するための「ツール群」を指すのに対し、「ワークフロー」は、プロジェクトにおけるデータの流れや、どのタイミングでチェックを行うかといった「ルール」そのものを指します。この二つを整備することが、大規模な制作を円滑に進める上で非常に重要です。

マーザ社におけるワークフロー

こちらがマーザ社の抽象化されたワークフローです。図の中のオレンジ色の線は、すべてデータの受け渡しが発生している箇所を示しており、これらの複雑なやり取りをパイプラインが担当しています。特にレンダリングやコンポジットといったサーバーでの処理が必要な工程で、Dispatcherが活躍します。

PipelineツールとしてのDispatcher

Dispatcherは、このパイプラインを実現するためのツールの一つとして、制作チームに提供されています。各タスクで発生するデータのPublish（提出・共有）やImport、大量のレンダリング、プロジェクト出荷時のデータ変換やエンコードなど、サーバーで行うべき様々な処理をDispatcher経由で実行することで、アーティストが本来のクリエイティブな作業に集中できる環境を構築しています。

2種類の内製Dispatcher

Marza社では、用途に応じて「Harvester」と「jobCenter」という2種類のDispatcherを内製（インハウス）で開発・運用しているとのことです。ここからは、それぞれのツールの解説がなされました。

Harvester

HarvesterはPythonで開発されたCLIツールで、「JOB」「FOLDER」「TASK」という3階層で処理を管理します。すべてのJOBはデータベース（MySQL）で管理されており、大きな特徴としてタスク間の依存性を設定できる点が挙げられます。これにより、「タスクAが完了したら、次にタスクBを実行する」といった複雑な連続処理を制御することが可能です。

HarvesterとAWSの連携

Harvesterは、社内のレンダーファーム（Marzaマシン）だけでなく、AWSのクラウドサーバー（EC2）にも処理を投げることができます。

AWSを利用する理由

AWSを利用する最大の理由は、社内サーバーのスペックではメモリ不足などでクラッシュしてしまうような、極めて負荷の高いレンダリング処理に対応するためです。映画『ソニック × シャドウ TOKYO MISSION』の制作時にも、膨大な計算リソースを必要とするシーンで実際にAWSが活用されたそうです。このように、処理内容に応じてオンプレミスとクラウドを適材適所で使い分けられる柔軟な体制が構築されています。

JobCenter

もう一つのDispatcherであるJobCenterは、ファイルベースでJobを管理し、socket通信を用いてワーカー（処理を実行するマシン）を制御するシステムです。

HarvesterとJobCenterの特徴の違い

スライドに示されているように、HarvesterはDBベースでプロジェクトの優先度管理が必要な処理が扱えますし、JobCenterはファイルベースで再帰的な構造を要求するJOBが扱えるようになっています。
このように特性の異なる2つのシステムを併用することで、制作現場の多様なニーズにきめ細かく対応しています。

連携事例：AutoBlast

具体的な連携事例として、アニメーターが作成したデータを次の工程に渡す（Publishする）際に利用する自社ツール「AutoBlast」が紹介されました。アーティストがMaya（3DCGソフト）でPublishボタンを押すと、ファイルのチェックから動画のエンコード、そしてプロジェクト管理ツール（Flow Production Tracking）へのアップロードまで、一連の処理がJobCenterによって自動的に実行されます。

HarvesterとJobCenterの具体的な連携方法

このAutoBlastの処理は、HarvesterとJobCenterが連携することで実現されています。まずHarvesterが「アニメーションのPublish」という大きなJobを生成し、そのJobがJobCenterに送信されます。JobCenterは、受け取ったJobをさらに細かいタスクに分解して実行します。この仕組みにより、アーティストはボタンを一度押すだけで、その後の面倒な処理から解放され、待ち時間なく次の作業に移ることができます。

まとめ

本セッションのまとめです。HarvesterとjobCenterという2つのDispatcherシステムを自社で構築・運用することで、オンプレミスとクラウドを組み合わせた柔軟なリソース管理や、チェックフローの自動化を実現し、高品質な映像作品を支える強力なパイプラインを設計していることがよくわかりました。

感想・雑感

セッションを拝見し、華やかな映像制作の裏側で、いかに緻密で合理的なシステムが稼働しているかを垣間見ることができました。特に印象的だったのは、単一の万能なツールを目指すのではなく、「Harvester」と「jobCenter」という特性の異なる2つの内製Dispatcherを連携させ、それぞれの長所を活かして制作現場の課題を解決している点です。

アーティストの創造性を最大限に引き出すためには、彼らを煩雑な手作業から解放し、クリエイティブな思考を妨げない環境が不可欠です。それを実現するために、ワークフローを深く理解し、最適なツールを自ら開発・改善し続けるというアプローチはかなり有効である事がよく理解できました。