2026 年の Kitsu Submit で、Wizz Studio のリード開発者である Guilhem Compain が登壇し、あらゆる小規模スタジオがよく知る課題について参加者を案内しました。それは、少人数チームでタイトな納期のなか、根本的に異なるアニメーション手法にまたがって多様なプロジェクトを管理することです。
彼の講演では、Wizz が行ってきた技術的な選択と、制作に求められる創造性の柔軟性を損なわずにハイブリッド・パイプラインに構造をもたらそうとするあらゆるスタジオのための実践的なガイドが取り上げられました。
大きな使命を担う少数の開発チーム
Wizz は 2004 年に設立された、パリを拠点とするアニメーションスタジオで、従業員は約 20 名、常駐のアーティストは 40 名ほどです。Quad グループの一員で、Quad Film、Quad Drama などの制作関連組織も同グループに含まれます。
Wizz が異色なのは、取り扱う手法の幅が非常に広いことです。2D のコマ送りアニメーション、3D、ストップモーション、モーショングラフィックス、そしてミックスメディアがすべて同じ屋根の下で行われます。主に制作しているのは短編シリーズ、トレーラー、ティーザー、ミュージックビデオで、時折フィクション作品のプロジェクトもあります。
この多様性が、運用上の複雑さを生みます。Wizz は TVPaint、Photoshop、Nuke、Blender など、多くのソフトウェアツールにまたがって制作しています。制作ごとに前回とはまったく異なる見え方になり得るうえ、制作期間は通常数か月以上に及ぶことはほとんどありません。だからこそ、スピードと明確さは選択肢ではなく必須なのです。
Guilhem は、このすべてが起きている背景について率直に語りました。Wizz の開発チームは、正確に 2 人で構成されています。彼は約 1 年前に参加し、もう一人のパイプライン TD である Hadrien Farre は、スタジオに 4〜5 年在籍しています。この規模が、これから続くあらゆる話に重要な影響を与えます。
「私たちの開発チームはかなり小さいんです。2 人ですから、それが必然的に、パイプラインで私たちが作れて実装できることに影響します」と Guilhem は述べました。
これは、多くの中規模スタジオにとって見慣れた状況です。課題は「良いパイプラインがどのようなものかを理解すること」ではありません。限られたリソースのなかでそれを構築し、維持し続けながら、きちんと仕事を納品することが難しいのです。
Wizz における Kitsu の役割
Kitsu は、Wizz のインフラにおける 2 つの中核的な柱のうちの 1 つとして機能しています。もう 1 つは QuadPype で、こちらは open-source の OpenPype をフォークして作られた、彼らの社内パイプラインツールです（第 4 バージョンでは AYON として知られるようになっています）。Kitsu と QuadPype は、Guilhem が「抽象化レイヤー」と呼ぶものとして機能します。つまり、異なるソフトウェアツール同士が直接会話することを許すのではなく、すべてがこの 2 つのシステムのどちらかを経由するのです。
「私たちのデータに関して、ある種の主権を得られます」と Guilhem は説明しました。「重要なデータは、主として Kitsu のみが保持します。すべてのソフトウェアがそこに接続される。そうすることで、ソフトウェア同士が直接やり取りするのを防げます。」
ドキュメント化されていないツール間依存関係による混乱や、チェーンのどこかのアプリケーションが壊れたときに制作データを失ってしまうような経験をしてきたスタジオにとって、この種の集中化は「解決策」として馴染みがあります。Kitsu は「何が存在するのか」「何が承認されたのか」「まだ作業が必要なのは何か」を記録する唯一の正本になります。
Guilhem は、Wizz が Kitsu を使うことを意図的にシンプルにしている点を強調しました。彼らは、プラットフォームが提供するすべての機能を使い尽くしてはいません。代わりに、Kitsu を可視化とトラッキングのツールとして活用しています。つまり、ファイルシステムを掘り下げたり、アーティストに直接確認したりしなくても、コーディネーター、ディレクター、制作スタッフがプロジェクトの状態をひと目で把握できる場所です。
アセットはタスク、コメント、リテイクによって追跡されます。ショットも同じロジックに従います。
「シーケンス」は、従来のアニメーションの文脈での意味よりも、少しゆるく使われています。Wizz では、シーケンスがカラー・ボード関連のあらゆるものを表すこともあれば、メインプロジェクトとは別にトレーラーの作業を切り分けるために使われることもあります。
構造は「制作が実際にどう組織されているか」に合わせて調整され、硬直した枠組みに押し込むことはしません。ブレイクダウンはキャスティング（配役）を扱い、それが下流のパイプラインツールへ渡されます。プレイリストは、監督が確認し、直接注釈を付けられるような即席の編集を生み出します。
Kitsu がパイプラインに接続される場所
続いて、講演では Kitsu のデータが自動化のために QuadPype へ流れていく仕組みが説明されました。
Wizz は専用サーバー上で同期サービスを動かしています。このサービスは Kitsu のイベントシステムを監視し、プラットフォーム上で何かが変わるたびにイベントを発行します。たとえばステータス更新、新しいコメント、タスクの割り当てなどです。同期ループはそれらのイベントを取り込み、関連性でフィルタし、QuadPype が照会するローカルデータベースに結果を書き込みます。
「Kitsu で何かをすると、誰かがそれを聴けるイベントが必ず発火します」と Guilhem は説明しました。「私たちは取り込んだアクションをすべてフィルタして、必要なものだけに絞り込みます。そして、関連する各イベントごとに、データベース上のデータを追加・変更・削除するコードを実行します。」
チームが OpenPype の標準機能に加えて行った特筆すべき追加は、同期の中にキャスティング情報を含めたことです。アーティストがシーンを開くと、QuadPype が Kitsu 上でキャストされた内容に基づいて、正しいアセット、プロップ、要素を自動的に読み込めるようになりました。これにより、そうであればアーティストが毎回覚えて正しく実行しなければならない手作業のステップが取り除かれます。
そこからデータはランチャーへ流れます。ランチャーは実質的に QuadPype のアセットマネージャーです。アーティストは、自分のプロジェクト、アセット、ショットが Kitsu から直接取り出されて表示されます。ファイルシステム上に存在するファイルと、公開（パブリッシュ）済みのファイルがひと目でわかります。ショットを選び、タスクを選んで、適切なソフトウェアでそれを開きます。
公開の流れも同様のロジックに従います。アーティストが自分の成果物を公開すると、パブリッシャーは Kitsu から設定を直接取得します。フレーム開始、フレーム終了、そしてそのショットに対して設定されているその他の関連パラメータです。整合性チェックは自動で実行され、アーティストのファイルが Kitsu が指定する内容と一致していることを検証します。フレームレンジが一致しない場合は、公開処理が完了する前にシステムがフラグを立てます。
最後に Guilhem が強調したのは、彼らが「Build First Workfile」と呼ぶものです。このツールは Kitsu からキャスティング情報を読み取り、事前に定義された構造に従って、正しい要素がすべて読み込まれた状態の開始シーンを自動生成します。新しいショットの作業を始めるアーティストにとって、これは多くの手作業のセットアップを大幅に削減します。
難しい課題：2D アーティストとパイプライン文化
Guilhem は、パイプラインの議論でしばしば見過ごされることがある「2D と 3D の制作文化のギャップ」について時間を割きました。
「2D には、2D のパイプラインは“オーガニック”であるべきだ、という考えがあります」と彼は言いました。「つまり、アーティストは制約なしで好きなことをすればいい、という意味です。 一方で 3D のパイプラインは、後で技術的な問題が起きないようにするために、アーティストができることをできるだけ制限しようとします。もちろん、答えはその中間のどこかにあります。」
この緊張関係は実際に起きています。2D のワークフローは歴史的に、小規模でよりインフォーマルな環境で育ってきたため、アーティスト自身がファイルの整理や命名規則を管理してきました。そこにパイプラインツールを導入するということは、そのアーティストたちに対して「自分たちの視点ではずっと問題なく機能してきた習慣」を変えてもらうよう求めることになります。抵抗が生まれるのは、あながち不合理ではありません。
Guilhem は Wizz での具体的な摩擦点も説明しました。たとえば Windows のアーティストは、ファイル名にアクセント文字を含めた状態でコピー＆ペーストしがちで、それが下流のパイプライン上の問題につながります。彼は、行為を完全に止めるのではなく、サイレントな修正で対応するべきだと主張しました。ファイルは通すが、名前は自動でリネームする。「見えない形で整える、それが目標です」と彼は言いました。
導入プロセスはまだ進行中です。「全員が満足する瞬間があるとは思いません」と彼は認めました。
彼が提示した提案は、技術的というよりも組織的なものです。まず人と話すこと。実際に異なるアーティストがどう働いているのかを理解し、どんな制約が妥当かについて彼らを意思決定に巻き込み、その理解を土台にツールを作るべきであって、逆にするべきではないのです。
次に来るもの
Guilhem は、チームが今後進めたい改善点のリストで締めくくりました。具体的には、ランチャーのビューをフィルタして、特定のアーティストに割り当てられたタスクだけを表示すること（これはすでに AYON のリポジトリにあり、QuadPype 向けに適用できる）、Kitsu のステータスやコメントが変わったときにアプリ内通知を行うこと、そして Kitsu のコメントをソフトウェアへ直接取り込むことで、アーティストがブラウザへ切り替える必要をなくすことです。
また、より大きな願望にも触れました。QuadPype で一度何かを書けば、それがすべてのソフトウェア連携に自動的に反映されるようにすることです。「QuadPype や OpenPype、AYON のようなパイプラインツールが本当に輝くのは、そこです」と彼は言いました。「一度書けば、すべてのソフトウェアで動きます。なぜなら、各連携はソフトウェア本体から少し外側に存在していて、会話はしていてもソフトそのものの中に完全に埋め込まれているわけではないからです。」
同じような道を歩むスタジオに向けて、Wizz のパイプラインは GitHub の quadproduction/QuadPype で公開されています。
スタジオ向け要点
Wizz の事例は、現実のごちゃごちゃした、複数手法の制作環境の中で「Kitsu を基盤に構築する」とはどういうことかを、地に足のついた形で示しています。似た状況のスタジオにとって、いくつかのポイントが際立っています：
- Kitsu のすべての機能を使わなくても、価値は得られます。Wizz は主に Kitsu を可視化・トラッキングのレイヤーとして使っており、それだけでもコーディネーターやディレクターにとって大きなメリットになります。
- Kitsu が下流ツールにとっての「唯一の正本（権威あるデータソース）」になるほど、価値は積み上がります。フレームレンジ、キャスティング、タスクのステータス：Kitsu に記録したことは、パイプラインの別の場所で設定・検証・自動化に使うことができます。
- 技術的な統合の課題は現実にありますが、管理可能です。Wizz は同期レイヤーを Kitsu 自身のイベントシステムに基づいて作りました。これは、この種の用途に適しています。
より難しい課題は組織面です。アーティストが、そのシステムのデータが信頼できる状態に保たれるほど一貫して信頼し、使い続けるようにすることです。
そしてもしハイブリッド・スタジオを運営しているなら、パイプライン規律をめぐる 2D/3D の文化的な分断は、あらためて正面から認識しておく価値があります。ツールが良くても、それを取り巻く習慣が不十分なら性能は発揮されません。
