browser-useチームが最近、video-useというプロジェクトをオープンソース化し、1日で約1000スターを獲得しました。
その内容はSFのように聞こえます。未編集の生素材をClaudeに渡すと、自動で口癖を削除し、カットポイントを調整し、字幕を追加し、色調補正を行い、最終的に完成した動画を出力します。
しかし、私が注目したのはその方法です。
AIが動画を編集することはもはや目新しいことではありません。重要なのはどのように編集するかです。
この動画編集AIは、最初から最後まで動画を見ていません。
フレームごとに画像を理解することもなく、動画をマルチモーダルモデルに与えることもなく、ほとんどの時間はわずか数十KBのテキストだけを扱っています。
これは手抜きではありません。
これは、現在最も賢いエージェント製品が共有する同じアプローチです。
これを理解することは、「また新しいAI編集ツールが出た」と知るよりもはるかに有益です。
仮に、10分の動画をモデルに理解させたいとします。
最も直感的な方法はフレーム抽出です。毎秒数フレームを抽出すると、全体で約3万フレームになります。各フレームをマルチモーダルモデルに渡すには約1500トークンが必要です。
掛け算すると、画像を一度見るだけで4500万トークンを消費します。
しかも、モデルが覚えるのはほとんどノイズです。1.2万フレーム目に誰かが話していることはわかっても、何を言っているか、どこをカットすべきかは、画像だけでは教えてくれません。
これは仮定の話ではありません。
今年5月の公開評価では、画面を見て操作するビジュアルエージェントが、同じタスクを完了するのに、直接APIを呼び出す場合の45倍のトークンを消費することがわかりました。
計算コストの問題だけでなく、さらに悪いことに、パフォーマンスも劣ります。スクリーンショットを見てボタンをクリックするエージェントは、しばしば位置を間違えたり、ポップアップに惑わされたりします。
モデルに生データを直接処理させるのは、高コストで非効率でエラーが発生しやすい方向性です。
video-useは別の問いかけをする
video-useは次のように問いかけません：
「このフレームには何がある？」
代わりにこう問います：
「この発言はどのように話されたか？」
まず、ElevenLabsの音声書き起こしを使用して、素材全体を単語単位のタイムスタンプ付き、話者識別可能、さらに「（笑）（間）」までマークされたテキストに変換します。
このテキストはわずか数十KBです。
Claudeが受け取るのはこれだけです。テキストの精度で推論できるスクリプトです。
編集とは結局、タイムライン上で決定を下すことです：
- どの部分が繰り返されているか
- どこで詰まっているか
- この部分を残すか削除するか
これらの判断はテキスト上で行う方が、画像上で行うより速く正確です。
モデルが読むとき：
「えーっと、その、今日はですね…」
すぐに削除すべき無駄な言葉だとわかります。顔を見る必要はありません。
では、画像はいつ使うのか？
確信が持てない重要なポイントだけです。
例えば：
- 両方とも良い代替クリップから1つを選ぶ必要がある場合
- ある間が言い間違いか意図的か判断できない場合
その時だけ、フィルムのサムネイル、波形図、テキストラベルを組み合わせた合成画像を一時的に生成し、確認します。
高コストな知覚は常時オフにして、詰まった時だけオンにします。
動画全体の編集で、テキストは数十KB、数枚の重要な画像だけで済み、4500万トークンの愚直な方法と比べると、ほとんど無視できるコストです。
このアプローチは、browser-useがすでに使っていた
見覚えがあるなら、それはbrowser-use自身が同じ手法で成功したからです。
AIにウェブページを操作させる場合、愚直な方法はスクリーンショットを見せて判断させることです：
「ログインボタンはどこ？どこをクリック？」
browser-useはスクリーンショットを撮りません。
代わりに、ページのDOM構造、つまりページ背後にあるタグツリーをテキストに整形してモデルに渡します。
モデルは構造化データを読み取るため、画像を見るステップ全体を省略できます。
効果は同じ方向です：
研究によると、構造化された要素の位置情報を使用することで、ページ全体のスクリーンショットと比較して90%以上のコンテキストを節約できます。
さらに、モデルは確定的な構造を読むため、スタイルやポップアップなどの視覚ノイズに惑わされず、初回クリックの成功率がはるかに高くなります。
振り返ってみると、近年実際に成功しているエージェントは、ほぼすべて同じことをしています：
- コードを書くエージェントは、テキストと構文木を読み、IDEのスクリーンショットは見ません。
- ブラウザを操作するエージェントは、DOMを読み、ウェブページの画像は見ません。
- 動画を編集するエージェントは、書き起こしテキストを読み、動画フレームは見ません。
扱う領域は大きく異なりますが、問題解決の考え方は同じです。
持ち帰れる判断フレームワーク
上記の線を抽出すると、繰り返し使える思考モデルになります：
強力なAIエージェントは、ほとんど決してモデルに生の世界を直接見せません。
まず、その領域をモデルが本来得意とする構造（テキスト、ツリー、シーケンス）に圧縮し、その構造上でほとんどの推論を行い、重要な決定点でのみ高コストな生の知覚を使用します。
動画は書き起こしテキストに圧縮されます。
ウェブページはDOMに圧縮されます。
コードは元々テキストです。
この低コストな構造表現を見つけることが、この種の製品が成功するかどうかの鍵です。
次に、完全自動のAIエージェントを名乗るものに出会ったら、デモを見るよりも、次の3つの質問で試してみてください：
第一に、領域を構造化された表現に圧縮しているか？
それとも、モデルに生データ（スクリーンショット、動画フレーム、ページ全体のHTML）をそのまま処理させているか？
後者は、遅く、高コストで、不安定であり、スケールが難しいことを意味します。
第二に、高コストな生の知覚は常時オンか、それとも重要なポイントでのみオンデマンドで使用されるか？
常時オンの場合、コストはタスクの長さに比例して爆発します。
デモは良く見えても、実際に使うとコストがかかりすぎます。
第三に、その構造表現自体は正確か？
video-useの弱点は書き起こしにあります。1文字間違えると、その後のすべての編集判断が誤った基盤の上に構築されます。
エージェントの上限は、モデルがどれだけ賢いかではなく、世界を構造に変換する際にどれだけ情報を失い、誤りを犯すかに依存します。
これらの3つの質問は、ツールを選ぶためだけでなく、自分の仕事を考えるためにも使えます：
AIに何かを任せたい場合、最初のステップは生の素材をそのまま詰め込むことではなく、まず次のことを考えることです：
このタスクには、モデルが思考できる、安くて正確な構造表現はあるか？
この層を理解することは、より大きなモデルに交換するよりも効果的です。
video-useは表面的には編集ツールです。
しかし、それが示しているのは、この世代のエージェントが世界を見る方法です：
生の画像をじっと見つめるのではなく、まず世界を自分が読める言語に翻訳してから、思考を始める。
