video-useで動画編集をClaude Codeに任せる仕組みと設計

動画編集の作業をコーディングエージェントに任せて、素材を投入したら完成品まで一気に仕上がる。そんなワークフローを実現する OSS として、2026 年に入ってから browser-use が公開した「video-use」がエンジニアの間で話題になっています。

しかし、GitHub のスター数が 14,561 に達したとはいえ、いざ自プロジェクトへの採用を検討すると疑問が次々と出てきます。auto-editor で無音カットだけを自動化しているチームや、Palmier Pro のような GUI 型 AI エディタを触ったことがあるチームは特にそうでしょう。「video-use は結局のところ何が違うのか」「MIT ライセンスとはいえ実質必須の依存 API はないのか」「Open Issues 52 件というのは健全なメンテナンス状態と言えるのか」といった疑問に、公式 README だけで即答するのはやや骨が折れます。

そこで本記事では、browser-use/video-use リポジトリと公式ドキュメントを一次情報として、初見のエンジニアが採用可否を判断するために必要な観点を整理します。具体的には、video-use の設計思想（LLM に動画を「見せない」代わりにトランスクリプトを「読ませる」発想）、コアで自動化されるタスク、動作パイプラインと 12 のハードルール、video-useの使い方（導入手順と依存関係）、そして auto-editor・Palmier Pro との棲み分けまでを順に見ていきます。

なお、本記事の記述はすべて公開されている README・SKILL.md・install.md および gh api /repos/browser-use/video-use から取得したメタデータに基づいています。実際に環境構築や動作確認は行っていないため、実行結果に依存する主張は含みません。

video-useとは何か

video-use は、browser-use が公開している MIT ライセンスの OSS で、リポジトリの description には「Edit videos with coding agents」と記載されています。Claude Code / Codex / Hermes / Openclaw などのコーディングエージェントに「skills」として組み込むことで、動画編集の全工程をエージェント側から実行させる用途で設計されています。

リポジトリの基本情報は次の通りです（gh api /repos/browser-use/video-use の 2026 年 7 月 4 日時点の値）。

公開されているのは通常の Public リポジトリで、アーカイブされておらず、他リポジトリからのフォークでもありません。最終 push が 2026-07-01 と直近であること、Star 数の伸びに対して Open Issues が 52 件と過剰に滞留していないことから、メンテナンスは現在も継続していると読み取れます。ライセンスは MIT が付与されており、商用利用・改変・再配布のいずれも可能な範囲です。ソースコードそのものは browser-use/video-use（GitHub） で確認できます。

なぜ「LLMが動画を見ない」設計なのか

video-use を単なる「AI 動画編集ツール」ではなく「browser-use と同じ設計思想を動画に持ち込んだプロジェクト」として位置づけると、その独自性が見えてきます。README には次のように明記されています。

Same idea as browser-use giving an LLM a structured DOM instead of a screenshot — but for video.

出典: README.md

browser-use は Web エージェントに対してスクリーンショットではなく「構造化された DOM」を渡すことで、LLM のトークン効率と判断精度を両立させる思想でした。video-use は同じ発想を動画ドメインに適用し、LLM に動画フレームを直接見せずに「テキスト化されたトランスクリプト」を読ませる 2 層構造を採用しています。

README の主張によれば、たとえば 10 分の 60fps 動画をフレーム単位で LLM に渡すと 30,000 フレーム × 1,500 トークン ≒ 45M トークンの「ノイズ」になります。これに対して video-use のアプローチは 12KB 程度のテキスト + 決定ポイントでの数枚の PNG に圧縮されます。これがコアな差分です。

Layer 1 — 音声トランスクリプト（常時ロード）

video-use は 1 ソース動画につき 1 回だけ ElevenLabs Scribe を呼び、以下の情報を取得します。

• 単語単位のタイムスタンプ
• スピーカー分離（誰が話しているか）
• 音声イベント（笑い声・拍手・ため息）

これらは全テイクをまとめた takes_packed.md（約 12KB）としてパックされ、LLM が動画を理解する主索引となります。SKILL.md の Hard Rules（後述）では「単語レベル逐語 ASR のみ」「SRT やフレーズモード、正規化済みフィラーは禁止」と規定されており、単語境界の精度がすべての土台になっている点が特徴です。

Layer 2 — ビジュアルコンポジット（オンデマンド）

音声トランスクリプトだけでは判断がつかない場面（曖昧なポーズの扱い、複数テイクの比較、カットポイントの整合性確認など）では、timeline_view が呼ばれます。これは指定した時間範囲について、フィルムストリップと波形と単語ラベルを合成した PNG を生成する仕組みです。

ポイントは「常時ロードしない」ことです。決定ポイントでのみ視覚情報を LLM に渡すことで、トークンコストを抑えつつ判断精度を確保しています。SKILL.md によれば、動画の内容を「見る」ためではなく、あくまでも「テキストで読んだ結果を検証するため」の補助として位置づけられています。詳細な設計は SKILL.md で確認できます。

video-useが自動化する動画編集タスク

README の「What it does」セクションには、video-use が自動化する編集タスクが列挙されています。単なる無音カットを超えて、完成品を出力するために必要な処理がひと通り並んでいます。

これらは個別ツールとして提供されているのではなく、コーディングエージェントに対する「skills」として一括で組み込まれます。エージェント側から見ると、素材動画のパスを渡して意図を伝えるだけで、上記 7 機能の中から必要なものが自律的に選ばれて実行されます。機能一覧の一次情報は README で確認できます。

対応する動画タイプ

README には具体的にどんな動画で使えるかも記載されています。

• トーキングヘッド（話者中心の動画・対談）
• モンタージュ（複数シーンの構成）
• チュートリアル（画面録画・技術解説）
• トラベル（旅行 vlog）
• インタビュー

一方で、ミュージックビデオのような音楽主導のカット割りや、フィクション映画のような演出優位の動画は対象範囲に明記されていません。動画のカット決定を「音声トランスクリプト」に依存する設計上、無音の映像素材や BGM 主導の編集は不得手だと考えられます。

アニメーション連携（HyperFrames / Remotion / Manim / PIL）

video-use はアニメーション生成を自前で行わず、外部ツールに委譲します。連携先は用途に応じて使い分ける設計です。

• HyperFrames: モーションデザイン系のオーバーレイ生成
• Remotion: React ベースで宣言的にアニメーションを書きたいケース
• Manim: 数学的なアニメーションやテクニカルな解説動画向け
• PIL: 静止画レイヤーやシンプルなグラフィック合成

これらは並列のサブエージェントとして起動される規則になっており、複数のアニメーションを順次生成することは Hard Rules で明示的に禁止されています（後述）。

動作パイプラインとハードルール

video-use の動作モデルは、README「How it works」で次のパイプラインとして提示されています。

Transcribe → Pack → LLM Reasons → EDL → Render → Self-Eval

出典: README.md

各ステップの役割は次の通りです。

パイプラインと EDL（Edit Decision List）

1. Transcribe: ElevenLabs Scribe を呼び、音声を単語単位でテキスト化
2. Pack: 全テイクを takes_packed.md（約 12KB）に集約
3. LLM Reasons: LLM がテキストを読み、どこをカットしどう構成するかを平文の「戦略」として提示。ユーザーが承認するまで実際のカットには進まない
4. EDL: 承認された戦略が edl.json（Edit Decision List）に構造化される
5. Render: EDL に基づいて ffmpeg がセグメント単位で抽出・カラーグレーディング・字幕焼き込みを実行し、preview.mp4 / final.mp4 として出力
6. Self-Eval: 出力を timeline_view で再検証し、境界の破綻を検知したら修正案を提示

EDL という中間表現を挟むことで、「LLM の判断」と「実際の ffmpeg 実行」が分離されているのが構造上の特徴です。編集意図を JSON として保存しておけば、後から再レンダーや微調整も可能になります。

セルフ評価ループ（最大 3 回まで）

セルフ評価はレンダー結果を LLM 自身が再確認する仕組みで、Hard Rules に「最大 3 回まで」の制約が組み込まれています。破綻が続く場合はユーザーに判断を仰ぐ設計です。無限ループを防止しつつ、完成品を提出する前の最低限の品質チェックを組み込む狙いが読み取れます。

12 のハードルールから見える設計思想

SKILL.md には「Hard Rules」として非交渉的な 12 項目が列挙されています。全体は SKILL.md で確認できますが、初見エンジニアが採用判断をする上で特に重要な 5 項目を抜粋します。

• 字幕は最後: 字幕をフィルタチェインの最後に適用しないと、後段のオーバーレイに隠されてしまう
• 30ms フェード: 全カット境界で afade による 30ms の音声フェードを必ず入れる（ポップ音防止）
• 単語境界スナップ: 単語の途中でカットしない。Scribe トランスクリプトの単語境界に必ずスナップする
• 並列サブエージェント: 複数アニメーションは並列で生成する（順次生成は禁止）
• 戦略確認前は編集しない: 平文の計画をユーザーが承認するまで、実際のカットには一切触れない

「戦略確認前は編集しない」というルールは特筆に値します。エージェントに動画編集を委譲するとはいえ、破壊的な操作（元素材への影響はないものの、時間のかかるレンダー処理）の前にユーザー承認を挟む設計です。「どこまで自動化されるか」だけでなく「どこは人間の承認が要るか」の粒度が明確になっているため、業務ワークフローに組み込む際の心理的抵抗が下がる仕組みだと言えます。

導入手順と依存関係

video-useの使い方は、エージェント委譲型セットアップと手動インストールの 2 通りに分かれます。README「Setup prompt」と「Manual install」の対比です。

エージェント委譲型セットアップ

README 冒頭に掲載されているセットアッププロンプトを Claude Code / Codex / Hermes / Openclaw のいずれかに貼り付けると、エージェント自身が clone・依存関係のインストール・skill 登録・API キー入力までを自動で完了させる方式です。

コーディングエージェントを普段から使っているチームであれば、この方式が最も摩擦なく導入できます。エージェントが行う具体的な処理内容は README.md の「Setup prompt」節に記載されています。

手動インストール

エージェントに委譲せず自分で導入する場合の手順が install.md に整理されています。要点は次の通りです。

1. git clone https://github.com/browser-use/video-use ~/Developer/video-use の後、ln -sfn ~/Developer/video-use ~/.claude/skills/video-use で symlink を張る
2. uv sync または pip install -e . で Python 依存を導入
3. brew install ffmpeg を実行（macOS の場合。Debian/Ubuntu は apt、Arch は pacman を使う手順が install.md に記載）
4. cp .env.example .env として ELEVENLABS_API_KEY を記入

brew install yt-dlp はオンラインソースを扱う場合のみ任意で入れます。

依存関係の全体像

video-use を実運用する上で必要になる依存は次の通りです。

有償依存（ElevenLabs Scribe）の位置づけ

video-use のリポジトリ本体は 100% OSS ですが、実運用には ElevenLabs Scribe API が実質必須です。音声トランスクリプトの取得を担うため、ここを別の ASR に差し替えるには内部実装への手入れが必要になります。

無償枠と有償枠の詳細な料金体系は ElevenLabs 側の仕様に依存するため、本記事では触れませんが、「MIT ライセンスの OSS だから完全に無料」という早合点は避けるべき点です。長尺動画を大量に処理するチームは、初期段階で ElevenLabs のコスト試算を必ず行うことをおすすめします。

また、常時稼働型の編集環境が必要な場合は、Browser Use Box（VPS + Telegram 連携）や Browser Use Cloud といったマネージド実行環境も提供されています。ローカルで動かす前提が難しい場合の選択肢として押さえておくとよいでしょう。

類似リポジトリとの違い

「video-use は結局どの立ち位置か」を判断するには、既存の類似ツールとの対比が有効です。ここでは特徴が明確な OSS を 2 件、参考として商用ツールとの位置関係を整理します。

video-use vs auto-editor（無音カット CLI との違い）

WyattBlue/auto-editor は Python 製の自動カット CLI で、音声ラウドネスとモーション量を分析し、無音・低モーション区間を機械的にカットする「first-pass」ツールとして知られています。日本語圏でも Qiita / Zenn / 個人ブログに多数のノウハウ記事があり、無音カット目的では事実上の定番と言える存在です。

両者の主な違いは次の通りです。

使い分けの判断軸は明確です。既存の GUI エディタ（Premiere・DaVinci Resolve・Final Cut Pro）で最終仕上げする前提で「無音カットだけ自動化したい」なら auto-editor を選び、素材から完成品まで対話 1 発で仕上げたいなら video-use を選ぶ、という切り分けになります。

video-use vs Palmier Pro（GUI + MCP との違い）

palmier-io/palmier-pro は Swift 製の macOS 向け AI ネイティブ動画エディタで、ローカルで MCP サーバー（http://127.0.0.1:19789/mcp）を立ち上げ、Claude Code / Cursor / Codex 等のエージェントがタイムラインを直接操作する仕組みを提供しています。

こちらとの違いはさらに複数の軸に分かれます。

対話しながら手でも微調整したい・macOS の GUI で最終確認したいなら Palmier Pro、GUI 操作を挟まず素材から完成 mp4 まで自動化したいなら video-use、という切り分けになります。

参考: moviepy・Descript との位置関係

その他のツールとの関係も簡単に触れておきます。

• moviepy: Python 動画編集ライブラリ。プログラムを人間が書く前提のため、対話ベースの video-use とは対象ユーザーが異なる（video-use は内部で ffmpeg を直叩きしており、moviepy は使用していない）
• Descript（商用）: テキストベース動画編集の元祖的存在。GUI + サブスクモデル。video-use は同じ「テキストで動画を編集する」発想を OSS + エージェント連携で再構築したもの

「テキストベース動画編集」というコンセプトそのものは Descript が先行していましたが、ワークフロー全体を Claude Code のようなコーディングエージェントに委譲する形は video-use に固有の位置づけと言えます。

video-useが向くケース・向かないケース

ここまでの整理を踏まえて、採用可否の判断ポイントを整理します。

向くケース

• Claude Code / Codex / Hermes などのコーディングエージェントを日常的に業務で使っている
• 対談・チュートリアル・トラベル・インタビューなど、音声主導の動画を継続的に制作している
• GUI エディタを開かず、terminal から完結する編集ワークフローを組みたい
• ElevenLabs Scribe API のコストを負担できる（あるいは既に契約している）
• OSS で完結する編集スタックを構築したい

向かないケース

• 音楽主導のカット割り（ミュージックビデオ）や無音映像素材が中心
• GUI タイムラインでの微調整が業務プロセスに組み込まれており、外せない
• ElevenLabs Scribe に相当する API を有償で使えない環境
• macOS 純正の GUI エディタで完結させたい（この場合は Palmier Pro が候補）
• 無音カットだけを既存の Premiere / DaVinci ワークフローに組み込みたい（この場合は auto-editor が候補）

導入前に確認すべきチェック項目

自プロジェクトに採用する前に、次の項目を確認することをおすすめします。

1. ライセンス: MIT ライセンスであることを確認済み。商用利用・改変・再配布とも制約は最小限
2. メンテナンス状況: 最終 push が 2026-07-01、Star 数 14,561、Open Issues 52 件。過去記事ではなく現行のメンテナンスが続いていることを browser-use/video-use 上で改めて確認する
3. 依存 API のコスト: ElevenLabs Scribe の課金体系を確認し、想定動画本数・尺での月額試算を行う
4. アニメーションニーズ: HyperFrames / Remotion / Manim / PIL のどれが必要かを整理し、未使用のツールは導入時にインストールしない
5. セッションメモリ運用: project.md によるセッション永続化を活かすには、ユーザー動画ディレクトリの構造（<videos_dir>/edit/ 配下）を規約通りに保つ必要がある。ディレクトリ設計は SKILL.md を確認する

なお、本記事の判定はすべて公式ドキュメントの記述に基づく静的な分析であり、実際の動作検証を経たものではありません。実運用の判断には、README・SKILL.md・install.md を精読した上で、必要に応じて小さめの素材で試験を行うことをおすすめします。

まとめ

video-use は、コーディングエージェントに動画編集の全工程を委譲することを目指した Python + MIT ライセンスの動画編集 OSS です。設計の中核は「LLM は動画を見ない。テキスト化されたトランスクリプトを読む」という発想で、これは browser-use が Web エージェントに構造化 DOM を渡す思想と同じ流れの上にあります。

初見エンジニアの意思決定の 3 軸で本記事を振り返ると次のようになります。

• 採用可否: コーディングエージェントを常用し、音声主導の動画（対談・チュートリアル・トラベル等）を継続的に扱うチームであれば採用の意義は大きい。ただし ElevenLabs Scribe への実質依存は前提として計算に入れる必要がある
• 類似ツールとの違い: auto-editor は無音カット CLI として first-pass を担い、Palmier Pro は macOS の GUI 前提。video-use は「素材から完成 mp4 まで CLI 完結・エージェント主導」で、両者と競合するのではなく別の役割を占める
• メンテナンス状況: Star 14,561 / Forks 1,743 / Open Issues 52、最終 push 2026-07-01、archived: false / fork: false。現在も継続的にメンテナンスされているリポジトリと読み取れる

次のアクションとしては、まず README.md を通読して機能スコープを掴み、続いて SKILL.md で 12 のハードルールを確認し、最後に install.md の手順に従ってセットアップに進むと、判断から導入までの流れがスムーズになります。