pdoom-video：Claude Opus 5.5が全シーンを生成した4K生成ミュージックビデオの仕組みとコード解析

2026年9月、AIと人間の協働で制作されたミュージックビデオがGitHubに登場し、約2,000のスターを集めた。その名は pdoom-video ── AI安全性・技術的特異点をテーマにした楽曲「I'm Upping My P(doom)」を、TypeScriptとthree.jsで完全生成したコードベースのミュージックビデオだ。

p(doom)とは何か？ AI安全性コミュニティで使われる用語で、「人類に壊滅的な影響を与えるAIが出現する確率」を指す。技術的特異点に近づく現代において、この確率（p）への見方は研究者・開発者のあいだで大きく分かれている。pdoom-videoはその文化的文脈を映像として昇華した作品だ。

Claude Opus 5.5とClaude Codeが全シーン設計からレンダラー実装まで担当したという点で、生成AIによるクリエイティブコーディングの到達点を示すプロジェクトである。

Claude Code生成ミュージックビデオ「使い方」：クローンからプレビューまで5分で動かす方法

まず最初にローカル環境で動かしてみよう。必要なのは bun、Google Chrome、ffmpeg の3つだけだ。

# リポジトリをクローン
git clone https://github.com/mexicat/pdoom-video
cd pdoom-video/app

# 依存関係インストール
bun install

# ブラウザプレビュー起動
bunx vite

http://localhost:5173 を開くとリアルタイムプレビューが始まる。スペースキーで再生・一時停止、←/→ で1秒シーク、[/] でシーン切り替えができる。最近のMacなら60fpsでリアルタイムレンダリングが可能だ。

4K60fps書き出しコマンド

bun scripts/render.ts video --scale 2 --samples auto --shutter 0.2 --out ../out/pdoom-4k.mp4

--scale 2 で3840×2160（真の4Kレンダリング、アップスケールではない）、--samples auto でモーションブラー品質を自動最適化する。M5 Proで全曲レンダリングに約2.5時間かかるGPU集約処理だ。

コードアーキテクチャを読む：17シーンが時間の純粋な関数として実装される仕組み

このプロジェクトの技術的核心は「すべてのフレームが楽曲再生時間の決定論的な関数」という設計原則だ。ブラウザプレビューとオフラインエクスポートが完全一致するのはこの設計によるもので、シーンコードは副作用を持たない純粋関数として書かれている。

ディレクトリ構造とシーンAPI

app/src/
  engine/     ← レンダラーコア（タイムライン・ポストプロセス・タイポグラフィ）
  scenes/     ← 17シーンのモジュール（open, hook, shoggoth, spacetime...）
  timeline.ts ← 歌詞行・ビート格子に基づくシーン配置
scripts/render.ts ← headless Chrome → WebSocket → ffmpegパイプライン

各シーンは open.ts, shoggoth.ts など独立したモジュールとして実装され、タイムライン上のウィンドウに割り当てられる。three.jsのGPUラインバッチ、Archivo/IBM Plex Mono/Cormorant Garamondフォント、ハロレーションやフィルムグレインのポストプロセスが組み合わさって映像が生成される。

シーンAPIの基本パターンは以下のような純粋関数だ：

// 各シーンは再生時間 t（秒）を受け取り、そのフレームの状態を返す
export function render(t: number, scene: SceneContext): void {
  const progress = (t - scene.start) / scene.duration;
  // three.jsオブジェクトの更新（副作用なし・同一 t で同一結果）
  scene.mesh.rotation.y = progress * Math.PI * 2;
}

この設計により、任意のフレームを独立してレンダリングでき、並列処理や中断・再開が容易になる。

モーションブラーの最適化アルゴリズム

# 通常：1フレームあたり12サブフレーム
# 通常カメラ動作：36サブフレーム
# 激しいウィップ・スラム：108〜324サブフレーム
bun scripts/render.ts video --samples auto  # 品質を自動決定

--samples auto は各フレームのサブフレーム数を「前後フレームの差分が閾値（デフォルト3/255）を超えるまで増やす」アダプティブアルゴリズムで決定する。これにより静止フレームでは高速化し、動きの激しいシーンでは最高品質を維持する。

three.js TypeScript ジェネレーティブアートを4Kで実現する技術スタック

pdoom-videoが採用している技術スタックは生成アート制作のリファレンスになる組み合わせだ。

音楽同期パイプライン（3層構造）

歌詞の単語レベルタイミングは以下の3段階で生成されている：

1. Demucs (htdemucs_ft): 音源分離でボーカルトラックを抽出
2. CTC強制アライメント + Whisper交差検証: 単語ごとのタイムスタンプを高精度化
3. beat/downbeat/onsetアナライザ: BPM(132.007)・ビート・ドラム/ボーカルのエンベロープを抽出

結果は data/lyrics.json（単語・音節レベルタイミング）と data/audio.json（BPM・ビート・セクション情報）として保存され、レンダラーから参照される。

類似ツールとの比較：pdoom-video と他の映像生成アプローチ

アプローチ	代表ツール	特徴	pdoom-videoとの違い
React based	Remotion	JSX + Reactで動画生成、プレビューが簡単	React不要・three.js直使用でGPUレンダリング最大化
Processing系	p5.js	JavaScriptで手軽な生成アート	ビデオ書き出しが弱い・音楽同期が非標準
ゲームエンジン	Unity Timeline	高品質・豊富なアセット	重厚なエンジン依存・コードのみでの管理が困難
AI動画生成	Sora, Runway	テキストから動画生成	決定論的制御が困難・コードとして管理できない
Canvas API	konva.js	軽量な2D描画	3D・GPUパフォーマンスに限界

pdoom-videoの最大の差別化点は「すべてがコードとして管理できる」点だ。Gitでバージョン管理でき、diff が明快で、AIとの協働設計プロセスがドキュメント化できる。Sora/Runwayのような生成AIアプローチでは、フレームレベルの再現性や決定論的制御は原理的に困難だ。

Claude Codeとの協働設計プロセス：どのようにAIがコードを生成したか

pdoom-videoが特筆すべき理由の一つは、設計プロセスが docs/TREATMENT.md と docs/ENGINE.md にそのまま記録されていることだ。

docs/
  TREATMENT.md  ← Style Bible：色調・タイポ・モーション設計の概念記述
  ENGINE.md     ← APIドキュメント：Claudeとの対話で生まれたエンジン仕様

実際の協働フロー（著者の記述より）：

1. コンセプト策定: Claudeとの対話でAI安全性テーマをビジュアル言語に翻訳
2. エンジンAPI設計: シーンAPIの形式・タイムライン仕様をClaude Opus 5.5と設計
3. シーン実装: 各シーン（shoggoth, spacetime等）をClaudeが生成・著者がレビュー
4. 音楽解析パイプライン: Python/Demucs/Whisperパイプラインの設計と実装もAI協働

これは「AIにコードを書かせた」のではなく、「設計意思決定の多くをAIとの対話で行った」という協働モデルだ。著者がコードレビュアーとして機能し、AIが実装者として機能した。

なぜ今このプロジェクトか：Claude Codeによる協働設計が示す創造の新しい形

従来の映像制作との違い

従来のモーショングラフィックスでは、Adobe After EffectsやBlenderで人間がキーフレームを手動設定していた。pdoom-videoのアプローチは根本的に異なる──映像のすべてがコードであり、Claudeとの対話を通じてその設計が生まれた。概念・治療法・歌詞アライメント・音声解析・レンダラー・各シーンがClaude Opus 5.5との会話で設計されている。コンセプトやStyle Bibleは docs/TREATMENT.md に文書化されており、エンジンAPIは docs/ENGINE.md に記述されている。

同種のツールとしてはVercelの Remotion（React + Video）があるが、pdoom-videoはReactに依存せず純粋なTypeScript + three.jsで動的グラフィックを実装している点が異なる。ゲームエンジン的なシーングラフと音楽連動タイムラインを小さなコードベースで実現している。

こんな人に向いている：フロントエンドエンジニア・クリエイティブコーダーへの実務シナリオ

シナリオ1：three.jsエンジニアがGPUレンダリングパイプラインを学ぶ

WebGLとthree.jsを業務で使用するフロントエンドエンジニアなら、このコードベースは読みやすいリファレンスだ。GPUラインバッチの描画、ポストプロセスチェーン（ブルーム・ハロレーション・グレイン）の組み合わせ方、headless Chromeからffmpegへのフレーム送信方法など、単一のプロジェクトで複数の高度なテクニックが読める。

シナリオ2：Claude Code活用のクリエイティブコーダーが協働設計の手法を学ぶ

「どこまでAIに設計させられるか」を探求するクリエイターにとって、pdoom-videoはAI協働の可能性を示す実例だ。TREATMENT.md や ENGINE.md の設計ドキュメントを読むことで、Claudeとの対話でどのように技術的な意思決定が行われたかのプロセスが分かる。

シナリオ3：音楽と映像の自動同期システムを構築したいエンジニア

楽曲解析・歌詞アライメント・ビジュアル生成のパイプラインをゼロから実装したいエンジニアには、このコードベースが優れた出発点になる。Python (uv) による音源分離→CTC→Whisperの3段階パイプラインと、その結果をTypeScriptレンダラーで消費する設計は再利用性が高い。

よくある質問（FAQ）

Q：Windowsで動作しますか？

オフラインレンダリング（scripts/render.ts）はWSL2環境を推奨します。ブラウザプレビュー（bunx vite）はWindows上でも動作しますが、headless Chromeを使うレンダリングスクリプトはMac/Linuxが主な動作環境です。

Q：楽曲「I'm Upping My P(doom)」の音声ファイルは含まれていますか？

リポジトリには歌詞タイミングデータ（data/lyrics.json）と音声解析データ（data/audio.json）は含まれていますが、音声ファイル本体の権利は著者（osmarks・MusicPerson）に帰属します。MITライセンスの対象外のため、音声ファイルの利用や再配布の前に著者への確認が必要です。

Q：自分の楽曲でpdoom-videoのエンジンを再利用できますか？

コード部分（app/src/配下）はMITライセンスで公開されており、自由に利用・改変が可能です。自分の楽曲向けにdata/lyrics.jsonとdata/audio.jsonを差し替え、app/src/scenes/に新しいシーンを追加する形で流用できます。音楽解析パイプライン（scripts/analyze.py）もMIT対象のため、Demucs + Whisperパイプラインごと再利用できます。

Q：three.js以外のレンダリングエンジンでも使えますか？

現在の実装はthree.js（WebGL）に特化しており、WebGPU（Three.js r163以降）への移行も技術的には可能ですが、現バージョンではWebGLが前提です。Canvas 2D APIやPixiJSへの置き換えはシーンAPIの再設計が必要になります。

Q：他のAIモデル（GPT-4o・Gemini等）でも同様の協働設計は可能ですか？

Claude特有の機能（長いコンテキスト・コード生成品質）がこのプロジェクトの成立を支えていますが、設計の考え方（純粋関数シーンAPI・決定論的タイムライン）は他のAIモデルとの協働でも応用できます。ただしTREATMENT.mdのスタイル記述をLLMに正確に解釈させる能力は、モデルによって大きく異なります。

トラブルシューティング：よくあるエラーと対処法

bun install で依存関係エラーが出る場合

# bunのバージョンを確認（v1.1以上推奨）
bun --version

# キャッシュをクリアして再インストール
bun pm cache rm
bun install

headless Chromeが起動しない場合

# Chromeのパスを明示的に指定
CHROME_PATH="/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" \
  bun scripts/render.ts video --scale 1 --out test.mp4

Linux環境では google-chrome または chromium-browser のパスを指定してください。

ffmpegでエンコードエラーが出る場合

# ffmpegのバージョン確認（4.4以上推奨）
ffmpeg -version

# libx264コーデックが利用可能か確認
ffmpeg -codecs 2>&1 | grep libx264

# H.265（HEVC）に切り替える場合
bun scripts/render.ts video --codec hevc --out pdoom-hevc.mp4

レンダリング速度が遅い場合

# 解像度を下げてテスト（1080p）
bun scripts/render.ts video --scale 1 --out pdoom-1080p.mp4

# サンプル数を固定値に設定
bun scripts/render.ts video --scale 2 --samples 12 --out pdoom-fast.mp4

---

使う前に知っておきたいこと：制限・ライセンス・ハードウェア要件

ハードウェア制限

• リアルタイムプレビュー: 最近のMac推奨（M1以降）。Windows/Linuxではオフラインレンダリングのみ。
• 4Kレンダリング: GPUバウンドな処理。M5 Proで全曲約2.5時間。
• エクスポートメモリ: headless Chrome約5GB + ffmpeg約4GB が同時に動作する。

ライセンスの注意点

• コード: MIT License（自由に利用・改変可能）
• フォント: Archivo, IBM Plex Mono, Cormorant Garamond（SIL Open Font License）
• 楽曲・歌詞データ: MIT対象外 ── 著者（osmarks・MusicPerson）に帰属。商用利用前は必ず確認が必要。

依存関係

分析ツール（歌詞タイミング再生成）にはPython環境 (uv) が必要だが、レンダラー自体の実行にはPythonは不要。コミット済みの data/*.json があれば bun + Chrome + ffmpeg だけで動作する。

---

まとめ：AIと協働するクリエイティブコーディングのリファレンス

pdoom-videoはツールではなく「作品」だが、そのコードはTypeScript/three.js開発者が学べる技術的参考書だ。特に関心を持つべきは：

1. 決定論的シーンAPI設計 ── テスト容易性とデバッグ性を両立する純粋関数アプローチ
2. 品質適応型モーションブラー ── アダプティブサンプリングによるレンダリング最適化
3. Claude Codeとの協働設計プロセス ── TREATMENT.md / ENGINE.md に残された意思決定の記録
4. AI生成映像との差別化 ── 決定論的制御・Gitバージョン管理・再現性を両立するコードベース映像制作

GitHub Stars: 約1,964 ── AIと人間の協働で生まれたコードが、コミュニティからどのように評価されるかを示す一例だ。