AIに動画を編集させると聞くと、映像を「見て」判断していると思いがちです。しかしVideo Useの設計はそうではありません。
LLMは映像を直接「見ない」。音声トランスクリプトで「読む」。この割り切りが、単語単位の精密なカットを可能にしています。
この検証の概要
調査日 | 2026年4月20日 |
|---|---|
対象 | Video Use（browser-use/video-use）／2026年4月17日前後リリース |
やりたかったこと | Claude Codeを使って動画編集をどこまで自動化できるかを把握する |
実現すること | 「生の映像フォルダ → Claude Codeにチャット → |
状況 | リサーチのみ実施。実際のセットアップ・動作検証は未着手 |
判定 | 追加検証が必要 |
本記事はリサーチ段階の記録です。実機での動作確認は未実施のため、品質・処理時間・コストの実測値は含みません。
結論：音声で読むから、単語境界で切れる
この設計の意味を整理します。
動画編集の自動化で難しいのは「どこで切るか」です。映像フレームを解析する方式では、フレーム単位の判断になります。しかし話し言葉のカットで必要なのは「単語の切れ目」です。
Video Useは2層構造でこれを解決しています。
- 第1層（必須）: ElevenLabs Scribe APIによる音声トランスクリプト（単語レベルタイムスタンプ・話者分離）
- 第2層（任意）: 必要時の静的フレーム合成
単語レベルのタイムスタンプがあれば、「えーと」の始まりと終わりを正確に指定できます。映像を見なくても、切る位置は決まります。
裏を返せば制約もあります。音声依存のため、映像のみの情報（テロップ等）は処理できません。
処理パイプライン
Transcribe（ElevenLabs Scribe）
→ Pack（音声+ビジュアルをLLMが読める形式に圧縮）
→ LLM Reasoning（EDL生成）
→ Render（FFmpeg）
→ Self-Evaluation（最大3回自動修正）
→ edit/final.mp4 出力注目すべきはPackとSelf-Evaluationです。
Packは「LLMが読める形式に圧縮する」工程です。大量のトランスクリプトをそのまま渡すのではなく、判断に必要な形に整えてから渡す——AIに長い素材を扱わせる際の基本形です。
自動検証ループ：レンダリング後に自分でチェックする
実用性を左右する仕組みです。
レンダリング後に映像ジャンプ・音声ポップ・字幕埋め込みを自己チェックし、最大3回まで自動修正します。
動画編集の失敗は、出力してみないと分かりません。カット位置がずれていれば映像が飛び、フェードが足りなければポップノイズが入ります。生成したものを自分で確認して直す経路があるかどうかで、実用性が変わります。
主要機能
- フィラーワード除去 — 「えーと」「uh」「umm」、無音、言い直しを自動カット
- 自動カラーグレーディング — warm cinematic / neutral punch などをセグメント別に適用
- オーディオフェード — カット箇所に30msフェード挿入（ポップノイズ防止）
- 字幕焼き込み — カスタムスタイル対応（デフォルト：2-word大文字チャンク形式）
- アニメーションオーバーレイ — Manim / Remotion / PIL を使ったグラフィック並列生成
- プロジェクトメモリ —
project.mdに編集履歴を永続化し、続きから再開可能
細かいところでは30msフェードが実務的です。カットしただけではプツッというノイズが入ります。この処理を自動で挟むかどうかは、仕上がりの印象に直結します。
使い方
cd /path/to/raw-footage
claude
# 例：「edit these into a launch video」
# 例：「フィラーワードを除去して字幕を焼き込んで」プリセットやメニュー操作は不要で、自然言語のみで編集指示が完結します。Claude Codeのスキルとして動作するため、~/.claude/skills/video-use にシンボリックリンクを張って組み込みます。
前提条件
- ElevenLabs APIキーが必須（別途取得・課金）
- FFmpegのインストールが必要（
brew install ffmpeg） - Claude Codeのスキルとして動作（独立したPython SDK/APIは未提供）
懸念点
- ElevenLabs Scribeへの外部API依存（コスト・可用性リスク）
- コミット数7件と極めて初期フェーズ。本番利用には不安定な可能性があり、破壊的変更が頻発するおそれ
- 独立したAPI/SDKがなく、Claude Code以外からの利用は想定外
- ライセンスファイルの明示的な記載が未確認
- 音声依存のため、映像のみの情報は処理不可
市場の位置づけ
この分野への注目度も記録しておきます。
- 提供元はBrowser Use（Y Combinator W25採択、2025年3月に$17Mシードラウンド調達）
- リポジトリはスター1,600+
- a16zが「2026年をエージェント動画編集元年」と位置付けている
また、提供元は「browser-use」→「workflow-use」→「macOS-use」→「video-use」とユースケースを拡張しています。ブラウザ操作で培った「AIに操作させる」設計を、対象を変えて展開している形です。
次に確認すべきこと
実機検証では、特に日本語対応が焦点になります。
- 日本語音声のトランスクリプト精度（日本語フィラー「えーと」「あのー」の除去精度）
- 1分の動画処理にかかる時間とAPIコスト
- 字幕焼き込みの日本語対応
- Remotionとの連携によるアニメーションオーバーレイの実用性
よくある質問
AIは映像を見て編集しているのですか？
直接は見ていません。ElevenLabs Scribe APIによる音声トランスクリプト（単語レベルタイムスタンプ・話者分離）を「読む」設計です。必要時のみ静的フレームを合成して補います。
なぜ音声ベースなのですか？
単語境界で精密にカットできるためです。話し言葉の編集で必要なのは単語の切れ目であり、単語レベルのタイムスタンプがあれば映像を見ずに切る位置が決まります。
無料で使えますか？
Video Use本体はOSSで無料ですが、ElevenLabs APIキーが必須です。Scribe APIの従量課金とClaude Codeの利用料が別途かかります。
本番運用できますか？
現時点では慎重に判断すべきです。コミット数7件と極めて初期フェーズであり、破壊的変更が頻発する可能性があります。
まとめ
- LLMは映像を直接見ず、音声トランスクリプトで「読む」。単語レベルのタイムスタンプが精密カットを可能にする
- パイプラインはTranscribe → Pack → LLM Reasoning → Render → Self-Evaluation
- レンダリング後に自己チェックし最大3回まで自動修正する検証ループを内蔵
- フィラー除去・字幕焼き込み・カラグレを自然言語のみで指示できる
- 制約はElevenLabs Scribeへの依存と映像のみの情報は処理できないこと
- コミット数7件の初期フェーズ。本番利用は安定化を待つべき
AIに何かを判断させるとき、扱いやすい形のデータに落としてから渡すと精度が上がります。動画を音声として読む設計は、その一例です。
株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のコンテンツ制作へのAI活用を支援しています。ご相談はお問い合わせフォームから、継続的な伴走支援についてはAI参謀をご覧ください。