チュートリアル

Claude Code に vlog を自動編集させる：再現可能なワークフロー

Pieter Levels は旅行素材を Claude Code に渡し、約 10 分の完成映像に編集した。どのツールを使ったのかを分解し、このワークフローを自分で構築する方法を説明する。

Nov 3, 2026

本記事の手法は Pieter Levels（@levelsio）が 2026 年 11 月に X で共有した実測に基づく。元の投稿：https://x.com/levelsio/status/2116959423117857026 。ツールチェーンを補足説明した返信：https://x.com/levelsio/status/2116961807315169718 。以下は彼の共有内容に対する私たちの分解と再現手順の説明である。

Pieter Levels は DJI で撮影した素材を Claude Code に渡し、約 10 分の vlog に編集させた。自分はわずかな調整だけを行い、事後にどのツールを具体的に使ったのかを知った。

これは分解して見る価値がある。曖昧な「AI 動画編集」を、再現可能なエンジニアリングワークフローに落とし込んでいるからだ。

具体的に何をしたのか

チェーン全体の順序は次のとおり：

文字起こし：mlx-whisper で音声をタイムスタンプ付きテキストに変換
フレーム抽出：一定間隔で画面をキャプチャし、1 枚の画面グリッド画像に結合
話者分離：SpeechBrain の ECAPA モデルでどの発話が誰によるものかを区別
意思決定：Claude が文字起こしテキストと画面グリッドを同時に読み、どの時間帯を残すかを決定
出力：JSON 編集リストを生成する（動画を直接編集するのではない）
レンダリング：リストに従って ffmpeg でカット・結合
補完：OpenCV と YuNet で顔サムネイルを作成、Pillow で冒頭字幕を描画

重要なのは第 4・5 ステップだ。モデルが行うのは「動画編集」ではなく、「2 つの構造化データを読み、1 つの編集判断を出力する」ことである。

なぜこの設計が機能するのか

動画を直接モデルに与えてはダメなのか？技術的には可能だが、コストが制御不能になる。1 時間の素材をフレーム単位で計算すると、トークン数は天文学的な数字になる。

このワークフローは 2 回の圧縮を行っている：

1 回目の圧縮は音声側。 1 時間の語りを文字にすると約 1 万数十字になり、モデルが読むのは安価だ。タイムスタンプが保持されるため、各文が動画内のどこにあるかを把握できる。

2 回目の圧縮は画面側。 定期的にフレームを抽出してグリッドに結合すると、1 枚の画像で複数の時点の画面を見られる。モデルは画像を見て「この区間は歩いているか」「この区間に風景はあるか」を判断でき、連続フレームを見る必要はない。

2 回の圧縮後、元々数時間の素材がモデルが一度に読める入力になり、意思決定コストが許容範囲まで下がる。

自分で構築する場合、順序が重要

ステップ 1：まず文字起こしをしっかり行う

音声トラックを分離し、タイムスタンプ付きテキストに変換する。このステップの品質が後続のすべての判断を決める。

語り中心の vlog では、文字起こしの正確さがモデルに「この話は終わった」という境界を選べるかどうかに直結する。背景音が騒がしい素材では文字起こしが欠落し、モデルがそれに基づいて切った段落が文の途中で途切れやすくなる。

ステップ 2：編集リストのフォーマットを設計する

モデルに出力させるのは「00:12 から 01:47 を保持」のような自然言語ではなく、固定スキーマの JSON だ：

{
  "segments": [
    {"start": 12.4, "end": 107.2, "reason": "民宿に到着、部屋を紹介"},
    {"start": 340.1, "end": 402.8, "reason": "海辺の夕日のタイムラプス"}
  ],
  "total_duration": 596.1
}

固定フォーマットがあれば、スクリプトが直接消費でき、自然言語を解析する必要がない。フィールドに reason を含めることで、人間が確認する際に各セグメントを残した理由がわかる。

ステップ 3：レンダリングは ffmpeg に任せる

モデルは意思決定のみを出力し、カットと結合は ffmpeg で行う。こうすれば各环节を個別にデバッグできる：編集判断がおかしければプロンプトを変えるかモデルを替え、画面がおかしければ ffmpeg のパラメータを調べる。

リストに従ってカットし結合する最小構成：

# リストに従ってセグメントごとにカット
ffmpeg -ss 12.4 -to 107.2 -i input.mp4 -c copy seg_01.mp4

# 結合
printf "file 'seg_01.mp4'\nfile 'seg_02.mp4'\n" > list.txt
ffmpeg -f concat -safe 0 -i list.txt -c copy out.mp4

-c copy は再エンコードしないため、数桁高速になる。前提として各セグメントのエンコードパラメータが一致している必要があるため、カット前に一度エンコードパラメータを統一しておく。

ステップ 4：意思決定をモデルに任せる

このステップは HiAPI を接続するだけでよい。Claude Code の設定は Claude Code と Codex を HiAPI に接続を参照。Key を設定すれば、Claude Code で実行される推論は Opus 5.5（入力 $2.02、出力 $10.08 / 100 万トークン）経由になる。

1 時間の素材で、文字起こしテキストと数十枚の画面グリッドを合わせた入力はおよそ 2〜3 万トークン。Opus 5.5 の入力料金で計算すると、1 回の完全な意思決定のコストは数円から十数円程度。人間が 1 時間編集する工数と比べれば、この桁なら迷う必要はない。

シーンを変えれば再利用できる

同じ構造で、入力ソースを変えれば別のプロダクトになる：

シーン	入力	編集目標
ポッドキャスト切り抜き	長尺音声 + 文字起こし	独立したセグメントにできる意見を選び出す
会議の振り返り	画面録画 + 文字起こし	決議と TODO を保持
講座の精密編集	講義動画	沈黙と繰り返しを除去
インタビュー集	マルチカメラ	テーマ別に再構成

カテゴリごとにプロンプトは異なるが、「文字起こし → 圧縮 → 意思決定 → レンダリング」という骨格は同じだ。

ハマりやすい落とし穴

タイムスタンプのずれ。 ツールによって文字起こしのタイムスタンプ基準が数十ミリ秒ずれることがあり、切り出した段落の冒頭が欠ける。解決策はまず短い素材でキャリブレーションすること。

モデルは残しすぎる傾向がある。 初回実行では編集が甘く、出力が目標尺より長くなりがち。プロンプトで目標尺を明示し、超過したら選び直すよう指示する。

カット点が文の途中に落ちる。 モデルにタイムスタンプだけを与えると、文の途中で切る可能性がある。文字起こしの文境界も一緒に与え、文境界で選ばせる。

再エンコードに時間がかかる。 各セグメントのエンコードパラメータが一致しないと -c copy が失敗し、再エンコードに退化して 1 時間の素材では非常に長くかかる。パラメータ統一のステップは省けない。

よくある質問

Claude Code は必須か？

必須ではない。長文を読み、スキーマに従って JSON を出力できるモデルなら、この意思決定环节は担当できる。Claude Code の利点は、自分でスクリプトを書き、ffmpeg を実行し、結果を見て調整できるため、手動でフローをつなぐ時間を省けることだ。

Apple シリコンなしで mlx-whisper は動くか？

動かない。mlx は Apple のフレームワークだ。非 Apple マシンでは faster-whisper や whisper.cpp に置き換える。ロジックは同じ。

フロー全体でどれくらいかかるか？

素材の文字起こしが大部分を占め、1 時間の素材で M シリーズチップならおよそ十数分から数十分、モデルサイズによる。意思決定环节は数分。レンダリングは -c copy なら高速。

編集結果はそのまま使えるか？

Levels 自身の説明では少量の調整を行ったとのこと。自動フローが解決するのは「数時間の素材から 10 分を選び出す」という最も時間のかかる部分で、細部のリズムやトランジションは人間が調整した方が速い。

重要な結論

このワークフローが機能する核心はモデルがどれだけ賢いかではなく、動画をモデルが読めるデータに変えたことにある。文字起こしが音声を圧縮し、フレーム抽出グリッドが画面を圧縮し、モデルはセグメント選択の意思決定だけを行い、レンダリングは ffmpeg に返す。再現したいなら、「素材をタイムスタンプ付きテキストに変換する」ステップから始めればよく、残りはエンジニアリング作業だ。

出典