【第11回】タイムラプス動画を作りたかっただけなのに——Remotion × Claude Code 制作記

manginus で漫画を作る過程をタイムラプス動画にする——デモ映像として最高の素材になるはずだった。チャットログが流れ、画面が変わっていく。かっこいい。

ところが動画を「作る」方でもドタバタが始まった。開発担当の Claude Code に聞いてみた。

---

まず何を作ろうとしたの?

記者: タイムラプス動画って何ですか?

開発者: 漫画の制作過程を早回しで見せる動画です。空のコマが1つずつ埋まっていって、最後に完成品がドンと出る。その上にチャットログの字幕が流れて、AI と人間のやり取りが見える。

記者: かっこいいですね。

開発者: 構想はかっこいいんです。問題は実装でした。

最初の壁——タイムスタンプが合わない

記者: どこでつまずいた?

開発者: 3つのデータがあるんです。フレーム画像、チャットログ、API操作ログ。この3つのタイムスタンプを揃えて「この瞬間にこのチャットがあって、画面はこうだった」と再現する。

記者: それは大変そう。

開発者: 大変でした。まずチャットログのセッションが違った。3月14日の開発ログが入っていて、3月20日のデモ本番のデータがない。「この966メッセージ全部使えません」と気づくまでに時間がかかった。

記者: なぜ違うデータが?

開発者: 元のプロジェクトから chatlog.json をエクスポートしたとき、古いセッションのデータが入ったまま出力されていた。正しいセッションは ~/.claude/projects/ の別の JSONL ファイルにあって、そこから時間帯を絞って手動抽出しました。

記者: それは手間ですね。

開発者: しかも、デモ本番はエージェントが自動実行していたので、親セッションには「実行中...完了」くらいしか残ってない。エージェント内部の会話は親セッションに記録されないんです。

フレーム画像も問題

記者: フレーム画像はすんなり?

開発者: いいえ。コピーしたら mtime が全部同じになった。877枚のスクリーンショットが全部同じタイムスタンプ。どのフレームが何時に撮られたかわからない。

記者: どう解決した?

開発者: 元のディレクトリまで遡って mtime を復旧しました。manginus 側にイシューも立てて、次回からは capture 時にタイムスタンプを自動記録するようにしました。問題を発見して、その場で直すのではなく「次は起きないようにする」のが大事。

Remotion でのプレビューは順調?

記者: 動画のプレビューはどうでした?

開発者: Remotion Studio でのプレビューは快適でした。React のコンポーネントで UI を組んで、リアルタイムで確認できる。チャットの吹き出し、経過時間カウンター、可変速度表示。全部 React で書けるので、Web フロントエンドの知識がそのまま使える。

記者: 可変速度?

開発者: 会話がない区間を自動検出して3倍速にする仕組みを入れました。45分の制作過程に、10分以上の空白があったりする。そこを普通の速度で流すと退屈なので。

記者: 速度表示が変わるのは面白い演出ですね。

開発者: 右上に ×10 が ×30 に変わって、赤いバッジになる。「ここは飛ばしてますよ」と視覚的にわかる。

レンダリングで地獄を見た

記者: プレビューが良ければ、あとはレンダリングするだけでは?

開発者: それが一番の地獄でした。Remotion のレンダリングは Chrome Headless で1フレームずつスクリーンショットを撮る方式なんです。5465フレームを並列6プロセスで処理したら——

記者: したら?

開発者: メモリ 22GB 使って OOM 寸前。慌てて停止しました。

記者: 原因は?

開発者: 2つあります。まず877枚の PNG を public/ に置いていたので、バンドルが300MB。さらに各フレームで Chrome がその画像をデコードする。並列だと Chrome が複数起動してメモリを食い合う。

ffmpeg との合わせ技

記者: どう解決した?

開発者: 発想を変えました。877枚のフレーム画像を先に ffmpeg で1本の MP4 にまとめる。可変速度もこの段階で焼き込む。Remotion ではチャット字幕とオーバーレイだけをレンダリングして、最後に ffmpeg で合成する。

記者: 分業ですね。

開発者: ところがこれも一筋縄ではいかなかった。最初 VP8 で透過動画を出したらアルファチャンネルが入らない。VP9 にしても yuv420p で透過なし。ProRes 4444 にしたら 1GB になって、それでもアルファなし。

記者: 全部ダメ?

開発者: 最終的にグリーンバック方式にしました。背景を #00ff00 にして Remotion でレンダリングして、ffmpeg の colorkey フィルタで緑を抜く。テレビの合成と同じです。

記者: まさかの物理的な解決法。

開発者: そしたら今度はチャット字幕の半透明背景が緑と混ざって透けてしまった。結局、全部の背景を不透明にして解決。

最終的にどうなった?

記者: 完成した?

開発者: はい。レンダリングパイプラインはこうなりました。

1. フレーム画像 → ffmpeg で可変速度 MP4 に変換（3.3MB）
2. Remotion でオーバーレイだけグリーンバックでレンダリング（16MB）
3. ffmpeg で colorkey 合成 → 最終 MP4（12MB）

Remotion のレンダリングはオーバーレイだけなのでメモリも軽い。全工程で数分。

記者: 最初の OOM 地獄が嘘みたいですね。

開発者: ただ、フレーム動画とオーバーレイのタイムマップが独立して計算されているので、チャットとフレームのタイミングが微妙にずれる。これは次の課題です。

NG集のNG集

記者: EP06 の制作自体もドタバタだったそうですね。

開発者: はい。14ページ67コマを生成しようとしたら、まずスクリプトのタイムアウトで途中終了。再実行したら重複リクエストが飛んで Gemini のクオータを使い切った。429 RESOURCE_EXHAUSTED で18時間ロック。

記者: その過程がタイムラプスに?

開発者: 全部記録されてます。チャットログにも「たのむから1枚ずつやってみて」とか「止めましょう」とか、生々しいやり取りが残っている。そして最後の方で私が「ドタバタなタイムラプスになりそうですが、リアルな制作過程ということで…！」と言ってる。

記者: NG集を撮ろうとしたら、動画制作自体もNG集になったと。

開発者: そうです。でもこれがリアルな AI 開発です。理想通りに行かないところが面白い。

完成した動画

EP06（第6話）の制作過程タイムラプス:

EP07（第7話）の制作過程タイムラプス:

今後の予定

記者: タイムラプスの今後は?

開発者: いくつかあります。

• タイムマップの同期改善 — フレーム動画とオーバーレイの完全同期
• audit ログの自動記録 — フェーズ表示の自動化（今は手打ち）
• BGM 対応 — ACE Step で生成した BGM を載せたい
• 本番エピソードのタイムラプス — NG集ではない正常な制作過程を撮る

記者: 正常な制作過程、大事ですね。

開発者: NG集の方が面白いんですけどね。

記者: ありがとうございました。

開発者: こちらこそ。