動画編集は、長らく「AIには遠い領域」とされてきました。タイムライン上でクリップを切り貼りし、色を調整し、字幕を載せる——どれも視覚的で、職人的で、自動化しにくい作業の塊だからです。LLMに動画を理解させようとすれば、何万フレームもの画像を読ませることになり、コストも精度も現実的ではありません。
その常識を、意外な角度から崩しにきたのが、本記事で解説する video-use（ビデオユース） です。AIブラウザ自動化で知られる browser-use チームが公開したこのオープンソース（Python・MITライセンス・GitHub約11,000スター）は、「Claude Codeなどのコーディングエージェントで動画を編集する」という、これまでにないアプローチを提示します。素材の入ったフォルダを用意し、エージェントに「これをローンチ動画に編集して」と話しかけるだけで、フィラー（「えー」「あー」）の除去から色調補正、字幕の焼き込み、さらには出力の自己評価まで行い、final.mp4 を返してくれます。
最大の発明は、その設計思想にあります。LLMは動画を「見る」のではなく「読む」——音声の文字起こしを主たる情報源とし、視覚情報は必要なときだけ参照する。これは、browser-useがLLMにスクリーンショットではなく構造化されたDOMを与えたのと、まったく同じ発想を動画に応用したものです。当サイトの読者であるAIエンジニアにとって、この「コンテキスト設計の妙」は学びの多い事例です。AIに難しいタスクを解かせる鍵は、しばしばモデルの賢さそのものより、「何を、どんな形で読ませるか」というコンテキストの作り込みにある——video-useはそれを動画編集という具体例で証明しています。
1. video-useとは — 「コーディングエージェントで動画を編集する」
video-useの公式の一言は明快です。「video-use — Claude Codeで動画を編集する。100%オープンソース。」。使い方も拍子抜けするほどシンプルで、生の素材をフォルダに入れ、Claude Codeと会話し、final.mp4 を受け取る。これだけです。トーキングヘッド（話者の正面映像）、モンタージュ、チュートリアル、旅行動画、インタビュー——プリセットやメニューに縛られず、あらゆるコンテンツに対応します。「どんな動画か」を最初に決め打ちしないからこそ、幅広い素材に柔軟に向き合えるのです。
正確には、video-useは単体アプリではなく、コーディングエージェントに登録する「スキル」です。Claude Code、Codex、Hermes、Openclawなど、シェルアクセスを持つエージェントなら何にでも組み込めます。エージェントがクローン・依存関係のインストール・スキル登録までを担い、動画編集の頭脳としてLLMが、実際の処理エンジンとしてffmpegが動く——という構成です。専用のGUIを持たず、既存のエージェント環境に「能力」として乗る。この形は、AIエージェントが汎用的な実行基盤になりつつある時代を象徴しています。動画編集ソフトを起動するのではなく、いつものClaude Codeに「動画も編集できる」能力が一つ増える、という感覚です。
公式が挙げる主な機能を整理します。
・フィラー語と無音の除去：「えー」「あー」「言い直し」やテイク間の空白を自動カット
・自動カラーグレーディング：各セグメントを色調補正（暖色シネマ調・ニュートラル・任意のffmpegチェーン）
・カットごとの30msオーディオフェード：継ぎ目の「プツッ」というノイズを防ぐ
・字幕の焼き込み：デフォルトは2語ずつの大文字チャンク、スタイルは完全カスタマイズ可能
・アニメーション・オーバーレイ生成：HyperFrames・Remotion・Manim・PILで、アニメごとに並列サブエージェントを起動
・出力の自己評価：すべてのカット境界でレンダリング結果を自己チェックしてから提示
・セッション記憶の永続化：project.md に状態を保存し、翌週のセッションが続きから再開できる
「メニューを操作する」のではなく「やりたいことを言葉で伝える」だけで、これだけの編集が走る——ここがvideo-useの体験の核心です。
特筆すべきは、アニメーション・オーバーレイの生成を並列サブエージェントで処理する点です。挿入したいアニメーションが複数あれば、HyperFrames・Remotion・Manim・PILといった生成手段を、アニメごとに別々のサブエージェントへ割り当てて同時に走らせます。これは、当サイトでも繰り返し触れてきた「マルチエージェントで作業を分担する」設計が、動画制作という具体的なタスクで実用化されている例です。動画は要素ごとに独立して作れる部分が多く、並列化の恩恵が大きいワークロードなので、この設計は理にかなっています。
もう一つ見逃せないのが、project.md によるセッション記憶の永続化です。動画編集は一度で終わらず、「今日はラフカット、来週に微調整」と複数セッションにまたがることが珍しくありません。video-useは編集の状態をファイルに残すため、会話の文脈が切れても、次回のセッションが続きから再開できます。会話の外側に状態を持つというこの発想は、長期的なエージェント運用の定石でもあります。
2. 核心思想 — LLMは動画を「見ない」、「読む」
video-useを単なる「ffmpegのラッパー」と片付けてはいけません。その真価は、LLMに動画をどう理解させるかという、コンテキスト設計の発想にあります。公式の「How it works」は、こう断言します。
LLMは動画を一度も「見ない」。「読む」のだ。
なぜ「見ない」のか。素朴に動画をLLMに渡そうとすると、膨大なフレーム画像を投入することになります。公式の試算は強烈です。
素朴なアプローチ: 30,000フレーム × 1,500トークン = 4,500万トークンのノイズ。 Video Use: 12KBのテキスト + 数枚のPNG。
フレームを総当たりで読ませる素朴な方法は、トークンコストが膨大になるだけでなく、肝心の「どこで切るべきか」という情報がノイズに埋もれてしまいます。動画編集において本当に必要なのは、ピクセルの羅列ではなく「いつ、誰が、何を話したか」という構造化された情報です。この差を生むのが、2層構造の情報設計です。
第1層 — 音声の文字起こし（常時ロード）。各素材に対してElevenLabsのScribeを1回呼び、単語単位のタイムスタンプ・話者分離（ダイアライゼーション）・音声イベント（(laughter)＝笑い、(applause)＝拍手、(sigh)＝ため息）を取得します。すべてのテイクは、約12KBの単一ファイル takes_packed.md にまとめられ、これがLLMの主たる「読む」ビューになります。実際のフォーマットはこうです。
## C0103 (duration: 43.0s, 8 phrases)
[002.52-005.36] S0 Ninety percent of what a web agent does is completely wasted.
[006.08-006.74] S0 We fixed this.
単語ごとに時刻が振られているため、LLMは「この言い直しの開始は2.52秒、終了は5.36秒」と、単語境界の精度でカット点を指定できます。話者分離があることで「インタビューでAさんの発言だけを抜く」といった編集も、音声イベントがあることで「笑いが起きた箇所を残す/カットする」といった判断も、すべてテキストの読解として実行できます。映像を1フレームも見ずに、です。
第2層 — 視覚コンポジット（オンデマンド）。timeline_view というツールが、任意の時間範囲について「フィルムストリップ＋波形＋単語ラベル」のPNGを生成します。ただしこれは判断が必要なときだけ呼ばれます——曖昧な間（ま）、リテイクの比較、カット点の最終確認、といった意思決定ポイントです。
公式自身が、このアイデアの出自を明言しています。「browser-useがLLMにスクリーンショットではなく構造化されたDOMを与えたのと同じ発想——それを動画に適用した」。視覚的に「全部見せる」のではなく、意味のある構造（音声テキスト）を「読ませる」。この一点が、動画編集をLLMの手の届く範囲に引き寄せた最大の発明です。
3. パイプライン — 文字起こしから自己評価まで
video-useの処理は、明快な一本のパイプラインで流れます。
ElevenLabs Scribe"] --> B["Pack
takes_packed.md"] B --> C["LLM Reasons
カット戦略を推論"] C --> D["EDL
編集決定リスト"] D --> E["Render
ffmpegで書き出し"] E --> F["Self-Eval
カット境界を自己評価"] F -->|"問題あり"| G["修正して再レンダリング
最大3回"] G --> F F -->|"合格"| H["プレビュー提示
final.mp4"]
流れを追います。まず各素材を文字起こし（Transcribe）し、takes_packed.md にパック（Pack）。LLMがそれを読んでカット戦略を推論（Reasons）し、EDL（Edit Decision List＝編集決定リスト） を生成します。EDLに従ってffmpegがレンダリング（Render） し、最後に自己評価（Self-Eval） が走ります。
この自己評価ループが秀逸です。レンダリングされた出力に対して、すべてのカット境界で timeline_view を実行し、視覚的なジャンプ・オーディオのプツ音・隠れてしまった字幕といった不具合を検出します。問題が見つかれば自動で修正して再レンダリング（最大3回）。すべてのチェックを通過して初めて、人間にプレビューが提示されるのです。
ここで重要なのは、自己評価が「LLMの推論が正しかったか」ではなく「実際にレンダリングされた成果物が正しいか」を見ている点です。LLMがEDLの上でどれだけ正しくカット点を決めても、ffmpegの書き出しで予期せぬズレが生じることはあります。だからこそ、頭の中の計画ではなく、出力された映像そのものを検証する。この「計画と成果物を分けて、成果物を検証する」姿勢が、動画という壊れやすいアウトプットの信頼性を支えています。そして「最大3回」という上限は、直らない問題を延々と再試行してトークンとコストを浪費しないための、明確な停止条件です。
video-useの自己評価ループは、当サイトでも繰り返し取り上げてきた「Maker/Checker分離」「Evaluator-Optimizer」の発想そのものです。LLMが出力を作りっぱなしにせず、レンダリング結果を自分で評価し、合格するまで直す。動画という壊れやすい成果物でこれを回すことで、「気づいたら音が割れていた」「字幕が見切れていた」といった事故を、人間に見せる前に潰せます。最大3回という上限（暴走防止の停止条件）まで含めて、堅実な設計です。
4. セットアップと使い方
video-useの導入は、エージェントに「セットアップして」と頼むだけの方法と、手動の方法があります。
video-useには、エージェント自身にセットアップを任せる方法と、手動で構築する方法の2通りがあります。最も手軽なのは、公式が用意するセットアッププロンプトをエージェントに貼り付ける方法です。Claude Code・Codex・Hermes・Openclawなど、シェルアクセスを持つエージェントに次のような指示を渡すと、クローン・ffmpegの配線・スキル登録・ElevenLabs APIキーの設定までを代行してくれます。エージェント自身が環境構築を行うという、現代的なオンボーディングです。
手動でやる場合は、リポジトリをクローンしてエージェントのスキルディレクトリにシンボリックリンクを張り、依存をインストールします。
# 1. クローンしてエージェントのskillsディレクトリにリンク
git clone https://github.com/browser-use/video-use ~/Developer/video-use
ln -sfn ~/Developer/video-use ~/.claude/skills/video-use # Claude Code
# 2. 依存をインストール
cd ~/Developer/video-use
uv sync # または pip install -e .
brew install ffmpeg # 必須
brew install yt-dlp # 任意（オンライン素材のDL用）
# 3. ElevenLabs APIキーを設定
cp .env.example .env
$EDITOR .env # ELEVENLABS_API_KEY=...
セットアップ後は、動画素材のフォルダにエージェントを向けて、セッションの中で自然言語で指示します。
cd /path/to/your/videos
claude # または codex, hermes など
そして、こう伝えるだけです。
これらをローンチ動画に編集して
video-useは素材を棚卸しし、編集戦略を提案し、あなたのOKを待ってから、素材の隣の edit/final.mp4 を生成します。すべての出力は <videos_dir>/edit/ に収まり、元素材やスキルのディレクトリは汚れません。生成物が一箇所にまとまる設計は、何度も編集を試行錯誤するうえで地味に効く配慮です。常時稼働でVPSやTelegramから編集したい場合は、エージェントを「Browser Use Box」経由で動かす運用も用意されています。
なお、文字起こしにElevenLabsのAPIキーが必要な点は、導入前に押さえておくべきコストです。動画編集の頭脳はLLM、文字起こしはElevenLabs、レンダリングはローカルのffmpeg——という役割分担になっています。
5. 設計原則と「12のハードルール」
video-useは、編集の品質を担保するために、明文化された設計原則を掲げています。これは、AIに創造的な作業を任せる際の「どこを自由にし、どこを縛るか」という線引きの好例です。
| 原則 | 内容 |
|---|---|
| テキスト＋オンデマンド視覚 | フレームのダンプはしない。文字起こしが情報の表面 |
| 音声が主、視覚が従 | カットは発話境界と無音ギャップから決める |
| Ask→confirm→execute→self-eval→persist | 戦略の承認なしにカットに触れない |
| コンテンツ種別を仮定しない | まず見て、訊いて、それから編集する |
| 12のハードルール、それ以外は自由 | 制作上の正しさは絶対、センスは自由 |
特に最後の原則——「12のハードルール、それ以外は芸術的自由」——が示す思想は重要です。「プツ音を出さない」「字幕を見切れさせない」といった制作上の正しさ（production-correctness）は一切妥協しないが、色味の好みや構成のセンスといった領域は縛らない。AIに任せる作業で「絶対に守るべき品質基準」と「創造性に委ねる部分」を明確に分けることは、再現性のある成果物を得るうえで決定的に効きます。
そして「Ask→confirm→execute→self-eval→persist（訊く→確認→実行→自己評価→永続化）」というワークフローは、エージェントが暴走せず、かつ人間の意図を外さないための型です。戦略の承認を得てから実行し、出力を自己評価し、セッションの状態を project.md に残す。この「人間との協調」と「自律的な品質管理」の両立が、video-useを実用ツールたらしめています。
6. browser-useエコシステムの中での位置づけと、誰に向くか
video-useは、AIブラウザエージェントの代表格 browser-use チームの作品です。browser-useが「LLMにWebを操作させる」ためにDOMという構造化された表現を与えたように、video-useは「LLMに動画を編集させる」ために文字起こしという構造化された表現を与えました。同じ設計哲学が、まったく異なるドメインに横展開されている点は、エンジニアリングの観点で非常に示唆的です。当サイトでも browser-use 本体を扱っており、あわせて読むと、この一貫した思想がよく見えてきます。
video-useが特に向くのは、次のような人々です。
第一に、動画コンテンツを量産する個人・チームです。YouTuber、技術解説者、プロダクトのマーケター——「撮った素材を、毎回手作業でフィラー除去・字幕付けするのが苦痛」という人にとって、会話で編集が終わる体験は革命的です。特にフィラー除去と字幕付けは、編集時間の大半を占めながら創造性とは無縁の単純作業であり、ここを自動化できるインパクトは大きいでしょう。
第二に、すでにコーディングエージェントを使っている開発者です。Claude CodeやCodexを日常的に使っているなら、スキルを1つ足すだけで動画編集能力が手に入ります。新しいアプリの操作を覚える必要がありません。
第三に、AIのコンテキスト設計を学びたいエンジニアです。「巨大なデータをそのまま渡すのではなく、意味のある構造に圧縮して読ませる」という video-use の手法は、動画に限らず、あらゆるAIアプリ設計に応用できる普遍的な教訓を含んでいます。PDF、ログ、データベース、3Dシーン——「そのままLLMに食わせると爆発するが、適切に構造化すれば読める」対象は無数にあります。video-useは、その思考の型を動画という具体例で鮮やかに示してくれます。
第四に、動画編集の自動化パイプラインを構築したいチームです。video-useはスキルとして組み込めるため、CIやサーバー上で「アップロードされた素材を自動で編集してプレビューを生成する」といったワークフローへの発展も視野に入ります。公式が「Browser Use Box」経由でのVPS・Telegram運用に触れているのも、その方向性を示唆しています。
一方で、留意点もあります。文字起こしにElevenLabsのAPIキー（＝従量課金）が必要なこと、ffmpegというローカル依存があること、そして「音声が主」という設計上、セリフのない映像作品（BGMだけの映像美モンタージュ等）では強みが出にくいことです。とはいえ、トーク主体のコンテンツが大半を占める現代の動画事情を考えれば、適用範囲は十分に広いと言えます。また、AIによる自動編集である以上、最終的な仕上がりは人間が確認すべきで、ブランドの世界観が問われるような重要作品では、video-useでラフを高速に作り、細部は人間が詰める——というハイブリッドな使い方が現実的でしょう。「下準備の9割を任せて、最後の1割に集中する」という分業こそ、この種のツールの最も賢い使い方です。
video-useは、「コーディングエージェントで動画を編集する」という新しい体験を、100%オープンソースで実現したプロジェクトです。その核心は「LLMは動画を見ずに読む」というコンテキスト設計——browser-useがDOMでWebを攻略したのと同じ発想を、文字起こしで動画に適用しました。フィラー除去・色補正・字幕・自己評価までを会話で完結させ、12のハードルールで品質を守りつつ、センスは自由に委ねる。動画を量産する人、コーディングエージェントを使う人、そしてAIのコンテキスト設計を学びたい人——いずれにとっても、一度触れておく価値のある一作です。
まとめ
本記事では、browser-useチームが公開した「コーディングエージェントで動画を編集するOSS」video-use を解説しました。
video-useの本質は、動画編集という視覚的・職人的な作業を、LLMが扱える形に翻訳したことにあります。鍵は「見ずに読む」——ElevenLabsの単語単位文字起こしを主たる情報源とし、視覚コンポジットは判断点でのみ参照する2層設計。これにより、4,500万トークン相当のノイズを、12KBのテキストと数枚のPNGに圧縮しました。
処理は Transcribe → Pack → Reason → EDL → Render → Self-Eval の一本道で流れ、自己評価ループ（最大3回）が品質を担保します。「12のハードルールは絶対、それ以外は自由」という線引きと、「訊く→確認→実行→自己評価→永続化」のワークフローが、エージェントの暴走を防ぎつつ人間の意図を守ります。
そして何より、browser-useのDOM思想を動画へ横展開したという事実が示すのは、優れたAI設計の原則はドメインを超えて通用するということです。「巨大な生データをそのまま見せるのではなく、意味ある構造に圧縮して読ませる」——この教訓は、動画編集に限らず、これからAIアプリを作るすべての人にとっての指針になります。素材フォルダとClaude Codeがあるなら、まずは「これを編集して」と話しかけるところから始めてみてください。
よくある質問（FAQ）
Q1. video-useとは何ですか? browser-useチームが公開した、コーディングエージェント（Claude Code等）で動画を編集する100%オープンソースのスキルです。素材フォルダを渡して指示するだけで、フィラー除去・色調補正・字幕焼き込み・自己評価までを行い、final.mp4を返します。Python・MITライセンス・GitHub約11,000スター。
Q2. なぜ「LLMは動画を見ずに読む」のですか? 動画をフレーム画像でLLMに渡すと膨大なトークン（公式試算で4,500万トークン相当）になり非現実的だからです。video-useは音声の単語単位文字起こしを主情報とし（約12KB）、視覚コンポジットは判断点でのみ参照することで、コストと精度を両立しています。browser-useがDOMでWebを扱うのと同じ発想です。
Q3. どのエージェントで使えますか? シェルアクセスを持つコーディングエージェントなら使えます。公式はClaude Code・Codex・Hermes・Openclawを挙げています。スキルとして登録して動かします。
Q4. 何が必要ですか（前提）? ffmpeg（必須）、文字起こし用のElevenLabs APIキー（従量課金）、任意でオンライン素材ダウンロード用のyt-dlpです。動画編集の頭脳はLLM、文字起こしはElevenLabs、レンダリングはローカルのffmpegという役割分担です。
Q5. 勝手に編集が進んで意図とずれませんか? ずれにくい設計です。video-useは「Ask→confirm→execute→self-eval→persist」の原則に従い、編集戦略を提案してユーザーの承認を得てから実行します。さらにレンダリング結果を自己評価し、合格してから初めてプレビューを提示します。
Q6. どんなコンテンツに向いていますか? トーキングヘッド、モンタージュ、チュートリアル、旅行、インタビューなど幅広く対応します。設計上「音声が主」のため、セリフのある動画で特に強みを発揮します。逆にBGMのみの映像作品では強みが出にくい点に留意してください。
参照ソース
・video-use（browser-use/video-use 公式リポジトリ） — 本記事が解説した一次情報。機能・設計思想・パイプライン
・browser-use（関連プロジェクト・公式リポジトリ） — video-useの設計思想の源流となったAIブラウザ自動化OSS
・ElevenLabs Scribe（音声文字起こしAPI） — video-useが文字起こしに使う音声AI
