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