(2026) PythonでKitsuプレイリストをエクスポートして共有する方法

アニメーターとしてキャリアを始めた頃、たいてい最初に直面するのはつらい真実です――時には痛い形で。素晴らしい仕事をするのは仕事の半分にすぎず、分かりやすく共有することが残りの半分です。映像そのものはしっかりしていたのに、レビューのプロセスは完全にカオスだったショートフィルムの案件を覚えているかもしれません。メールで行ったり来たりするQuickTimes、shot_final_v3_really_final.movのような名前のファイル、そして「どのメモがどのバージョンに当たるのか」が誰にもはっきり分からない状況。クライアントは混乱し、上長はイライラし、あなたはアニメーションよりもファイル管理に時間を費やしていました。

数年先の話になると、Kitsuプレイリストはスタジオのアニメーションレビューのあり方を根本から変えてくれます。

プレイリストは、構造化、追跡性、そして見せ方をきれいに整えてくれます。ショットをグループ化し、バージョンを追い、フィードバックを一元化できます。多くのチームにとって、それだけで十分大きなメリットです。

ただし制作現場で長年学ぶことがあります。どのスタジオやクライアントも、まったく同じレビュー手順を共有しているわけではないということ。資産をオフラインで送る必要があることもあります。クライアントが「シーケンスごとにきちんと梱包されたもの」を求めることもあります。法務やセキュリティ上の制約で、直接Kitsuアクセスを渡せない場合もあります。そういうときでも、単一の共有方法に閉じ込められることなく、Kitsuの強みを活かしたいはずです。

この記事はまさにそのための内容です。

最後には、Kitsuプレイリストを作成し、Pythonでそのデータを抽出し、関連するすべてのアセットを分かりやすいフォルダ構造にダウンロードし、共有しやすいようにまとめて圧縮する方法が分かるようになります。このやり方は実制作で何時間も節約でき、アーティストとクライアント双方のレビューをよりスムーズにします。

では、順を追って分解していきましょう。

1. Kitsuプレイリストを作成する

しっかりしたレビューのワークフローは、明確な意図から始まります：あなたは一体、何についてフィードバックが欲しいのでしょうか？ Kitsuプレイリストは、その目的のために作られています。

Kitsuのダッシュボードからプレイリストを作成するのは簡単です。プロジェクトに移動し、Shots または Assets のセクションへ進み、レビューしてほしいアイテムを選び始めます。プレイリストは「レビューの物語（ナラティブ）」だと考えると分かりやすいです。すべてを放り込むのではなく、次のことを自問してみてください：

• これはブロッキングのレビューですか？
• これは仕上げ（ポリッシュ）のパスですか？
• アニメーション、ライティング、コンポのどこに焦点を当てていますか？

たとえばショートのシネマティック案件なら、別々のプレイリストを作るかもしれません：

• "Animation Blocking – Act 1"
• "Facial Polish – Key Shots"
• "Final Lighting Review"

この小さな整理だけでも、クライアントのレビューが大幅に焦点を持つようになります。

Kitsuでは、ショットを選択したら新しいプレイリストを作成し、分かりやすい名前を付け、物語が伝わるようにショットを並べ替えられます。並び順は、人が思う以上に重要です。クライアントが再生ボタンを押したとき、アート、タイミング、そしてリビジョンを1か所で判断できます。

2. プレイリストのデータを取得する

準備が整ったら、次はコードを書いていきます。

まずはGazu APIクライアントでKitsuに認証します：

import gazu
gazu.set_host("http://localhost/api")
gazu.log_in("admin@example.com", "mysecretpassword")

続いて利用可能なプロジェクトをKitsuに問い合わせ、ターミナルに表示します。ユーザーはプロジェクトを選択し、その選択が以降すべての範囲（スコープ）を決定します。プロジェクトは動的に取得されるため、スクリプトは修正なしでさまざまな制作環境で動作します：

productions = gazu.project.all_projects()
for i, p in enumerate(productions):
print(f"{i} {p'name'}")
production = productionsint(input("Select project: "))

そこから選択したプロジェクトからプレイリストを問い合わせ、同じように表示します。プレイリストが選ばれたら、スクリプトはAPIからプレイリスト全体のオブジェクトを取得します。

playlists = gazu.playlist.all_playlists_for_project(production)
for i, pl in enumerate(playlists):
print(f"{i} {pl'name'}")
playlist = gazu.playlist.get_playlist(playlistsint(input("Select playlist: ")))

playlistには、編集（選定）のための参照情報がすべて含まれています。ショット、バージョン、並び順、そしてリンクされたファイルに至るまで、このオブジェクトからアクセスできます。

3. 関連アセットをダウンロードする

次のステップは、プレイリストのデータを「ディスク上でレビューできる形」に変換することです。

出力は、制作の現実を反映したフォルダ階層になります。最上位にプレイリスト、その下にシーケンス、さらにその中にショット。実際のメディアは、誰もが見つけられる場所に配置されます。

Playlist_Name/
└── Seq_010/
├── Shot_010_001/
│   ├── anim_v003.mov
│   └── anim_v003.png
└── Shot_010_002/
└── Seq_020/
└── Shot_020_005/

この構造こそがポイントです。曖昧さを取り除き、ファイルをただ平らに投げ込むのを避け、上長やクライアントがファイル名ではなく「文脈」でナビゲートできるようになります。

プレイリスト名をルートフォルダとして使うため、エクスポートは常に自己完結しており、再実行もしやすくなります。

playlist_name = playlist"name"

次に、プレイリストの各エントリを順に処理し、ショットの完全なレコードを取得します。プレイリスト自体にはシーケンス情報が含まれていないためです。

for shot in playlist"shots":
shot_data = gazu.shot.get_shot(shot"entity_id")

シーケンス名とショット名を使って、決定論的なディレクトリパスを組み立てます。これにより、ディスク上に playlist/sequence/shot の一貫したレイアウトが強制されます。

shot_name = shot_data"name"
sequence_name = shot_data"sequence_name"
shot_dir = os.path.join(
playlist_name,
sequence_name,
shot_name,
)

ディレクトリが存在しなければ作成します。これで、スクリプトを複数回実行しても失敗したり、途中までのダウンロード結果を上書きしたりしにくくなります。

os.makedirs(shot_dir, exist_ok=True)

続いて、各ショットに対応するプレビューのファイル情報を取得します。通常は画像または動画です：

preview = gazu.files.get_preview_file(shot"preview_file_id")

出力が、アーティストや上長が期待する見た目と一致するように、元のファイル名と拡張子を保持します。

preview_filename = f"{preview'original_name'}.{preview'extension'}"
preview_path = os.path.join(shot_dir, preview_filename)

プレビューのメディアはショットフォルダへ直接ダウンロードします。この時点で、プレイリストはディスク上に「きれいで、レビュー可能なディレクトリツリー」として存在しています。

gazu.files.download_preview_file(preview, preview_path)

結果は、説明なしでもzip化・送付・アーカイブ・レビューできる、プレイリストのローカルミラーになります。

4. フォルダを圧縮する

すべてダウンロードできたら、最後のステップは「共有しやすくすること」です。スクリプトはルートのプレイリストフォルダを自動的に1つのアーカイブに圧縮すべきです：

import shutil
shutil.make_archive(
base_name=playlist_name,
format="zip",
root_dir=os.path.dirname(playlist_name),
base_dir=os.path.basename(playlist_name),
)

このアーカイブは引き渡し用の成果物になります。クラウドストレージにアップロードしたり、セキュアなクライアントポータル経由で送ったり、内部でバックアップフォルダとしてアーカイブしたりできます。

クライアントは「ファイルが足りない」「構造が壊れている」といった心配をしなくて済みます。1回ダウンロードして1回解凍するだけで、あとはそのまま動きます。

アーカイブファイル名には、プレイリスト名と日付を含めましょう。半年後に「どのバージョンを送ったの？」と聞かれたとき、その判断が役に立ちます。

Kitsuでクライアントをオンボードする

ある時点から、Kitsuプレイリストのエクスポートが邪魔になってきます。素早いスナップショットを送るときや、単発のメモ対応をするときは問題ありませんが、プロジェクトが本格的に反復フェーズに入ると、状況は急速に散らかっていきます。調整のたびに毎回エクスポートし直し、クライアントは古いカットにコメントしてしまい、フィードバックがメール、PDF、チャットスレッドに分散してしまう。本当にショットを直す代わりに、「そのメモが何を指しているのか」を突き止めるために多くのエネルギーが費やされがちです。

そこで、クライアントを直接Kitsuに招き入れるのが合理的になることが多いのです。 彼らは常に最新バージョンを見られますし、フレーム上に直接描いたりコメントしたりできます。全員がメモを文脈付きで見られるためです。バージョン履歴も保たれるので、クライアントが「2つ前のバージョンの件なんだけど」と聞いてきたとしても、実際に確認できます。チームとしては、推測する場面が減り、メモを別の場所にコピペする時間も減ります。

エクスポートは手早い確認には向いていますが、実制作の規模感には広がりません。Kitsuにクライアントを入れることで、全員が同じ現実に立脚した状態を保てます。

結論

アニメーションの現場で何年も過ごすと、繰り返し出てくる教訓があります。それは「レビューのワークフローがスムーズであるほど、クリエイティブな成果も良くなる」ということです。Kitsuは、プレイリスト、バージョニング、そしてフィードバックの一元化によって、強力な土台をすでに提供してくれています。そのデータを活用し、小さな自動化ツールを組み立てることで、ほぼどんなレビュー状況にも適応できます。

さらに、Kitsuからプレイリストのデータを抽出し、カスタムのレビュー手順に合わせて再構成することも可能です。オフラインパッケージを送る場合でも、外部パートナー向けにアセットを整理する場合でも、あるいはクライアントの手間を少しでも減らしたい場合でも、このアプローチなら主導権をあなたの手に置けます。

公開Githubリポジトリをチェックして、あなたのワークフローに合わせてコードをクローンし、修正してみてください！

そして最後に、ぜひ守りたいアドバイスが1つあります。可能な限り、クライアントを直接Kitsuにオンボードしてください！ クライアントがリアルタイムのレビュー・ルーム、注釈付きメモ、バージョン履歴を体験すると、多くの人は二度と散らかったメールのやり取りに戻りたがらなくなります。