2026年のKitsu Submitでのプレゼンを通して、Pete Draperは参加者に、自身のキャリアにおける2つの大きな章と、CGWireが開発したオープンソースの制作トラッキングプラットフォームであるKitsuが、両方の“業務の中核（オペレーショナル・バックボーン）”になった経緯を語りました。
彼のストーリーは、「正しいツールを選べば、小さなチームでも大規模な複雑さを、正気を保ちながら管理できる」ということの模範です。
Peteは、業界で約30年近くのキャリアを持つVFXスーパーバイザーです。2009年にインドでスタジオを立ち上げ、そこで約40〜50本の映画に携わりました。インドの話題作『RRR』もその一つで、この作品はアカデミー賞の検討のために提出され、国際長編映画部門で23名のノミネート候補のリストにまで到達しました。
その後、彼は広告テクノロジー（バーチャル・プロダクト・プレイスメント）の領域へ移行し、Ryffという会社で重要な制作リーダーとして活躍しました。
彼の講演は、両方の経験をそのまま土台にしていますが、プレゼンの大部分はRyffにフォーカスしていました。そこでは、従来のVFXスタジオが通常直面しない種類の制作上の難題が待っていたのです。
課題：数百のプロジェクトがあるのに、中心となる背骨がない
Peteが2022年にRyffに加わったとき、同社は彼が「ナプキンの裏（back of a napkin）」と呼んだ仕組みで運用していました。多くの仕事を扱っていたにもかかわらず、制作インフラがあらゆる方向に分断されていたのです。
中央の制作ストレージはなく、独立したGoogleスプレッドシートが多数存在し、3拠点にチームが分散。ローカルマシンの性能が足りないため、レビューはリモートのAWS環境で行われていました。さらに、あらゆる種類の指標やレポーティングの仕組みもありませんでした。
Peteが言うように、「基本的にはすべてが請負（コントラクター）やフリーランサー、開発者を通じて行われていて、制作プロセスとして何がどう追跡されているかは、まったく把握できていなかった」のです。
なぜそれがこれほど重要だったのかを理解するには、Ryffが実際に何をしていたのかを知る必要があります。
事業：規模の大きいバーチャル・プロダクト・プレイスメント
RyffはAIを使って映画やテレビ番組を分析するプラットフォームを運営しており、ブランドの差し込みができるように、表面（サーフェス）、画面（スクリーン）、空のスペースをコンテンツが撮影され配信された後にデジタルで挿入できる箇所として特定していました。ディナーシーンでテーブル上にブランドロゴが現れるような場合や、カーチェイスの間に車窓越しに看板が差し替えで見えるような場合です。
同社には2種類のクライアントがいました。コンテンツの所有者（番組や映画を提供する側）と、そのコンテンツの中に商品を配置するために支払うブランドです。この2つを結びつけることで、極めて複雑な制作マトリクスが生まれます。たとえば1つの契約（ディール）で、同じブランドに関する10件のプレイスメントが、5つの別の番組に必要になることがあります。しかもその契約の権利は、特定の地域や時間帯にのみライセンスされています。ライセンスが切れると別のブランドが同じプレイスメントの場所に入ってくるため、コンポジット全体を新しいアセットで作り直す必要が出てきます。
PeteがRyffを離れる時点では、Ryffの主要なストレージは約46,000タイトル、そして固有のプレイスメントはおよそ146,000件でした。
各プレイスメントは複数のショットに対応し得るため、実際のショット数はさらに指数的に増えます。
ある1番組（World Poker Tour）の1シーズンでは、チームは34話にまたがって約1,700ショットを処理し、各話には40〜100ショットが含まれていました。すべて、1話あたり24時間というターンアラウンドで対応します。
これは、スプレッドシートで解決できる種類の問題ではありません。
『RRR』の制作中にKitsuを知る
Peteが最初にKitsuに出会ったのは、2018年後半の『RRR』制作のときでした。彼のチームはすでにいくつかの制作トラッカーを試していました。Tactic、Cerebro、Ftrack、ShotGridなど。しかしどれも合いませんでした。
「CGWireのKitsuが、あるGoogle検索の途中でふと目に入ってきたんです」と彼は言います。
彼はそれをテストし、チームに見せました。すると反応はすぐに返ってきました。「制作担当だけじゃなく、アーティスト側も。とても分かりやすい。シンプルでした。たとえばTacticのように、コンピュータサイエンスの学位が必要な感じではありませんでした。」
使いやすさという観点は、最初に見える以上に重要です。スタジオ環境では、トラッキングツールはチーム全員が一貫して使って初めて機能します。アーティストを混乱させたり、長いオンボーディングを必要とするシステムは、締切が迫りショットを素早く動かす必要がある“まさにその瞬間”に、まったく間違ったタイミングで摩擦を生みます。
KitsuはCOVIDパンデミックの時期にも役立ちました。リモートワークが現実的になったのは、どこにいてもアーティストがフィードバックやレビュー用のバージョンを受け取れたからです。まるで自分のスーパーバイザーが隣に座っているかのように。
Kitsu上にRyffのパイプラインを構築する
PeteがRyffに参加したとき、Kitsuは彼の最初の大きな推奨でした。しかし、単に導入して「使ってください」と指示しただけではありません。
時間をかけて彼とチームは、その上に制作インフラ全体を構築しました。単なるレビュー／承認ツールとして使うだけでなく、複数のシステムをつなぐミドルウェアとして活用したのです。
1. 中央集約されたアセットライブラリ
最初の大きな構成要素は、共有アセットライブラリです。プラットフォームの別の貢献者が最初に開発したライブラリ構造を使って、チームはパイプラインを通過するすべてのブランドアセットごとのリポジトリを構築しました。2Dロゴ、3Dモデル、デジタル屋外広告のビルボード構造、オーバーパスモデルなど。すべてのアセットはRyffのS3クラウドストレージにリンクされ、進行中の制作プロジェクトにも接続されました。
ライブラリは約2,317アセットまで成長しました。各アセットは、単なる名前やサムネイルを超えた形でメタデータを保持しています。エントリーにはカテゴリ（化粧品、乗用車、自動車、食品・飲料など）、サブカテゴリ（たとえばアルコール飲料か非アルコールか）、3Dオブジェクトではミリメートル、2Dではピクセル単位での寸法、そしてそのアセットがブランドから提供されたものか、アーティストから入手したものか、Ryff内部で制作されたものかが記録されました。
寸法フィールドには、直接的な実用性がありました。Ryffのシステム内の各プレイスメントも、定義された“スペース”パラメータを持っています。この2つを照合することで、あるアセットが特定のプレイスメント位置に物理的に収まるかどうかをシステムが自動でフラグでき、そうでなければコンポジット段階でしか表面化しない種類のエラーを減らせます。
またライブラリは、ブランドの所有権や地域ごとのライセンス情報も追跡していました。これにより営業チームは強力な検索ツールを手に入れます。Peteが強調するように、「Salesは“Chanelに対してこれまで何をやった？”と聞けて、そこから全ショットをそのまま引っ張ってこられます。」
2. クライアントをプロジェクトとして管理する
各ブランドの契約（ディール）は、Kitsuの中でそれぞれ独自のプロジェクトになりました。
これらのプロジェクトは、作業中のショットだけでなく、どのアセットがどのプレイスメントに割り当てられているか、各差し込み（インサーション）の現在のステータス、そしてそれが会社のCRMやプロジェクト管理ツール上の契約とどう結びついているかも追跡していました。
KitsuをJiraに接続するのは大変でした。「JiraのAPIについてね」とPeteは、いら立ちをほとんど隠さずに指摘しました。「誰かあれと格闘したことあります？ええ、かなりひどいです。」現実的な解決策は、2つのシステムを“ライブ連携なしで”人間が照合できるように、JiraのチケットIDを各Kitsuプロジェクトに手作業でコピーすることでした。
3. 複数キャンペーンにまたがるバージョン管理としてのプレイリスト
RyffのパイプラインにおけるKitsuの、より洗練された使い方の一つがプレイリストでした。というのも、同じショットが複数のブランドキャンペーンに対して同時に作業され得るため、バージョン番号だけでは、どのレンダーがどの契約に対応するのかを特定するには不十分だったのです。あるクライアント向けにはショットのバージョン5が正解かもしれませんが、同じシーンで別のクライアントが作業していれば、バージョン8が正解になることがあります。
Peteのチームは、各Kitsuプレイリストを、対応する“差し込み順（インサーション順）の番号”で命名することで解決しました。プレイリストは、ショットを追加すると特定のバージョンに固定され、新しいバージョンが公開されても自動更新はされません。その結果、プレイリストは「どのバージョンがどのキャンペーンに属するか」を示す安定した記録になりました。 「差し込み順の同じ番号で実際のプレイリストを名付けることで、相関が取れるんです」と彼は言いました。
4. Resolveからのプロジェクト作成を自動化する
Ryffは主要なコンポジットツールとしてDaVinci Resolveを使用していました。これは、粒状感（グレイン）の一致精度、カラー空間の正確さ、そして技術レベルで入力に対して出力が一致していることを保証できる必要があったための、意図ある選択でした。ResolveはVPN上での本物のマルチユーザー協業もサポートしており、20名規模のリモートチームにとって重要でした。
Resolveのタイムライン上の各ビデオトラックは、単一の仮想プロダクトプレイスメントを表しています。トラック名はVP1、VP2、VP3…のように付けました。ResolveはプロジェクトデータをPythonからアクセス可能な形式で保存するため、チームはタイムライン構造を読み取り、手作業のデータ入力なしにKitsu内のショットを自動生成できるスクリプトを書きました。
当初は、OpenTimelineIO（アプリ間で編集タイムラインをやり取りするための標準）を使ってタイムライン情報をエクスポートし、Kitsuのインポートツールに合わせたCSVファイルに変換していました。
その後、その“中間ステップ”を、Resolveの内部からKitsu APIに直接アクセスするスクリプトに置き換えました。OpenTimelineIOベースの方法から直接API方式への変更には、作業の約30％ほど手戻りが発生しましたが、その分、より高速で信頼性も高くなりました。
そのスクリプトは、ショットを作る以上のことをかなり多く実行します。1回の自動処理で、FFmpeg（コマンドラインのメディア処理ツール）を使ってマスターのエピソードファイルから個々のショットクリップを切り出し、各ショットに対応するKitsu互換のH.264プレビューを生成し、マッチムーブ作業用のJPEGシーケンスを作成し、制作ストレージ上のフォルダ構造を構築し、事前に用意したテンプレートからKitsuのプロジェクトを作成し、シーケンスやショットを投入し、コンフォーム（conform）QCクリップをアップロードし、すべてが作業可能になったことを部門の責任者に通知します。
テンプレートプロジェクト自体が独自の工夫でした。同じアーティストがすべての番組で作業し、タスク構造もプロジェクトごとにほぼ同じだったため、各プロジェクトを手作業でセットアップするのには大きな時間がかかっていました。 「僕らは、プロジェクトを“作る”ためにかける時間のほうが、実際にやる作業より長かったんです」とPeteは言います。このテンプレートスクリプトは、既存プロジェクトのタスクタイプ、タスクステータス、アーティスト割り当てなどを読み取り、それを丸ごと新しいプロジェクトに複製しました。
カバレッジ指標と、判断を守る技術
チームがKitsuに組み込んだ、やや珍しいカスタム指標の一つが「coverage value（カバレッジ価値）」と呼ばれるものです。この指標は、ブランドのプレイスメントが実際にフレームのどれだけの割合をカバーしているかを測り、ショットの全時間をフレームごとに分析します。
その理由は、技術的な面もあれば政治的な面もありました。ブランドのクライアントは、視認性を最大化するために、プレイスメントがフレームの一定割合をカバーするよう求めることがよくありました。 「Salesはこう言います。“よし、20パーセントくらい必要だ”」とPeteは話します。「聞こえは控えめな数字に聞こえるけど、20パーセントって、フレーム全部のそれだけです。かなりの量ですよね。」
基本的なコンピュータビジョン手法でカバレッジの割合を計算し、入力フレームと出力フレームを比較して差分を測ることで、チームはクライアントの要求を支持したり、逆に押し返すための“具体的な根拠”を作り出せるようになりました。たとえば「20パーセントのカバーが必要」という要望に対して、データが「それではコンテンツ所有者（＝番組側）が却下するような形でフレームを支配してしまう」と示していれば、Peteは勘に頼って議論するのではなく、数字を提示できるのです。
指標には、高い値（カメラがズームしているときのショット中の最大カバレッジ）、低い値（プレイスメントがフレーム外に出たときなどでゼロになることもある）、そして全時間にわたる平均が記録されました。これら3つの値はすべて、Kitsuのカスタムフィールドとして保存されます。
レポーティング、通知、そしてMicrosoftの問題
Ryffの歴史のかなりの部分では、通知はSlackを通じて流れていました。SlackはWebhookによってKitsuとネイティブに連携できます。アーティストのタスクが更新されると、数秒以内に通知がスマホやデスクトップに表示されます。
その後、会社のリーダーシップがMicrosoft Teamsへ切り替えました。Slackはキャンセルされました。Google DriveはMicrosoft SharePointに置き換えられました。
この移行によって、エンジニアリング上の悩みが2つ生まれました。1つ目は、自動レポーティングです。以前はほぼリアルタイムでデータをGoogleスプレッドシートへ書き出していたものを、SharePoint上でホストされたExcelファイルで動かせるようにする必要がありました。
「SharePointのPython APIで仕事をするのは、“歯を自分で全部抜いて、もっと気持ちいい体験を得る”みたいな感じでしたね」とPeteは、皮肉めいて語っています。
追加された複雑さにより、ログインするだけでも複数の認証ステップが必要になり、さらにリアルタイム更新の挙動は失われました。Excelは誰かが開いているとファイルをロックするからです。
2つ目の問題は通知でした。KitsuはTeamsをネイティブではサポートしていません。
チームの解決策は、Kitsuサーバー上で動作するカスタムリスナーサービスを作り、イベントを監視して、Azureを介して個々のTeamsユーザーへ通知を振り分けることでした。全通知を共有チャンネルへ送るようなTeams webhookの方式は採用しませんでした。共有チャンネルに送れば全員が溢れかえってしまうからです。その代わり、通知は関係のある本人に直接届けられます。
さらに彼らは、勤怠（タイムシート）のリマインダーも自動化しました。毎朝、直近3日間にどのアーティストも稼働時間の記録をしていない場合がないかをスクリプトが確認し、Teamsサービスを通じて個別に通知を送ります。リマインダーを“公開の呼びかけ”ではなく通知システム経由でルーティングすることで、気まずさの要因を減らし、コンプライアンス（遵守）の向上にもつながりました。
最終的な数値
PeteがRyffを去った年の11月までに、単一のKitsuインスタンスには（個別のTVエピソードは別として）543のアクティブプロジェクト、2,317アセット、18,300ショットが収まっていました。これらは1台のサーバーで運用され、メディアはマウントされたS3バケットに保存されていました。チーム規模は約20名のアーティストで、完全にリモートで作業しています。
AI検出、コンポジット、クオリティコントロール、そして納品までを含む、World Poker Tourの1エピソード分のターンアラウンドは、開始当初の1週間半から24時間へと圧縮されました。
アニメーション・スタジオ向けの要点
Pete Draperの講演は、やや珍しいビジネスモデルに固有の内容でしたが、学びは複数のプロジェクト、複数のクライアント、あるいはその両方を扱うあらゆるスタジオに、そのまま応用できます。
制作トラッカーは、全員が使ってはじめて機能します。そしてそれは、スーパーバイザーだけにとってではなく、アーティストにとっても“使いやすい”必要があります。Kitsuは、Peteの両方のスタジオで初日からそのテストをクリアしました。
自動化は、セットアップの“コスト税”をなくします。標準のショット追跡フィールドで基本はカバーできますが、カバレッジ比率、タイムコードオフセット、アセット寸法、インサーション順IDなど、あなたのワークフローに固有のフィールドを追加することで、トラッキングシステムは単なる管理記録ではなく“意思決定を支援するツール”になります。プレイリストはバージョニングの台帳として機能し得ます。
そしておそらく最も重要なのは、連携されたシステムへ向けて構築することです。Kitsuはスタンドアロンのトラッカーとしても十分に機能します。しかし、編集ツールからデータを受け取り、コミュニケーション・プラットフォームへ通知を送り、レポーティング用ダッシュボードへデータを供給し、アセットストレージへリンクする“ハブ”として使うと、はるかに効果が高まります。接続するシステムが増えるほど、適切に保守していくための投資に対するリターンが大きくなります。
