【第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集の方が面白いんですけどね。

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

開発者: こちらこそ。

後日追記: VP8 alpha は実は通った (2026-06-19)

記者: あの後、別の動画でまた透過オーバーレイをやることになったそうですね。

開発者: ai-news-ep01 という別シリーズで、388秒の長尺をやりました。グリーンバック方式でも良かったんですが、VP8 alpha をもう一度試したら、実は通ったんです。

記者: 前回「アルファチャンネルが入らない」って言ってたじゃないですか。

開発者: 落とし穴が 2 つあったんです。Remotion 側と ffmpeg 側で、それぞれ別の指定が必要でした。

記者: Remotion 側は?

開発者: こうです。

npx remotion render src/index.ts EP01Overlay overlay.webm \
  --codec=vp8 \
  --pixel-format=yuva420p \
  --image-format=png

--pixel-format=yuva420p だけだと「PNG image-format が要る」とエラーで止まる。--image-format=png も必須でした。

記者: これで透過 webm が出る。

開発者: はい。ただし、ffprobe で見ると pix_fmt=yuv420p と表示される。これに前回騙されました。

記者: alpha 入ってないように見えますね。

開発者: 思いました。でも実は WebM コンテナの "AlphaMode" タグが立っていて、alpha plane は本当にある。ffmpeg -c:v libvpx -i overlay.webm -vf alphaextract -frames:v 1 alpha.png で抜き出せます。

記者: ffmpeg 側の落とし穴は?

開発者: これが本丸でした。ffmpeg のデフォルト VP8 デコーダ (vp8) は alpha plane を捨てる。libvpx を明示指定しないと alpha が読めない。

# NG: 背景が消える（alpha が落ちてキャラ以外の領域が黒で塗りつぶされる）
ffmpeg -i bg.mp4 -i overlay.webm -filter_complex "[0:v][1:v]overlay" out.mp4
 
# OK: -c:v libvpx を overlay 入力の直前に置く
ffmpeg -i bg.mp4 -c:v libvpx -i overlay.webm \
  -filter_complex "[0:v][1:v]overlay" \
  -c:v libx264 -crf 20 out.mp4

記者: その指定 1 つで合成結果が完全に変わると。

開発者: 1 つ目のコマンドで合成すると、キャラの場所以外が真っ黒になる。背景動画は完全に消える。-c:v libvpx を 2 つ目の -i の直前に入れるだけで直りました。

記者: 一見「Remotion 側の設定」に見える症状が、実は ffmpeg の入力デコーダ選択でした、と。

開発者: そう。前回 NG集を書いたとき「VP8/VP9/ProRes 全部ダメ」と書いたのは早計でした。VP8 alpha は通る。ffmpeg のデコーダで alpha が落ちていた可能性が高い。

記者: グリーンバック方式と比べてどうですか?

開発者: トレードオフです。

• VP8 alpha: ファイル小（24MB / 388秒）、ffmpeg overlay 1 行で合成、ただし -c:v libvpx 必須の落とし穴
• グリーンバック + colorkey: 普通の mp4 で扱える、エッジに緑が滲む補正が要る、ffmpeg バージョン互換性は安定

配布素材としてアルファ前提（後で別動画と再合成する）なら VP8 alpha が小回り効く。最終 mp4 に焼き込むだけならグリーンバックの方がはまりにくい。

記者: 結論は?

開発者: 「VP8 alpha は罠が多い」は誤りで、「VP8 alpha は罠が 1 個ある」が正しかった。その 1 個が -c:v libvpx。これだけ覚えていれば次は早いです。