AI手帖

映像AIは「頼まれる前」に動けるか:変わり続ける意図を追うStreamVibe

能動的な手助けとは「長い文脈を覚える問題」ではなく、「意図と作業の進み具合を状態として更新し続ける問題」である

「映像AIは「頼まれる前」に動けるか:変わり続ける意図を追うStreamVibe」をイメージした絵

ある瞬間だけを切り取って採点すると、Timing F1 は 63.5–75.6 に達します。ところがストリーミング型のモデルも加えて動画の最初から最後まで通しで走らせると、スコアは 12.1–28.2 まで急落してしまいます。論文「StreamVibe: Proactive Video Agents for Evolving User Intent」(arXiv 2610.34662)を読み解きます。映像を見ながら、言葉にされない意図や途中で変わる意図に応える力を測定。4.1K評価・85K学習の新ベンチマークと、SFT+局所RLで鍛えたモデルを提案。意図を状態として管理するHarnessにより、古い応答や余計な口出しが激減。

この記事の流れ

頼まれる前に手助けする映像AIを3点セットで作った

Google、カリフォルニア大学サンタバーバラ校、オックスフォード大学などの研究チームによる論文です。動画を見続けながら「いつ、何を言えば助けになるか」を自ら判断する映像言語モデル(ストリーミングの能動型エージェント)をテーマに据えています。

これまでの能動型モデルは、「ゴールが決まったら教えて」のようにはっきりと言葉で伝えられた依頼を主に扱ってきました。それに対しこの論文は、言葉にされない「暗黙の意図」や、やり取りの途中で変わる「動的な意図」にまで踏み込みます。そのために研究チームが用意したのは3つです。評価用ベンチマークの StreamVibe-Bench、学習済みモデルの StreamVibe-VL、そして意図を状態として管理する外側の仕組み StreamVibe-Harness です。

手助けの鍵は長い記憶より意図の状態更新にある

一言で言えば、能動的な手助けとは「長い文脈を覚える問題」ではなく、「意図と作業の進み具合を状態として更新し続ける問題」であるという捉え直しです。

これまでのストリーミングモデルも、長いやり取りの履歴を保持すること自体はできました。それでも著者らによれば、モデルだけでは最新の状態を保ちきれません。同じ発言を繰り返したり、古い依頼に応え続けたり、肝心な場面を見落としたりしてしまいます。そこでこの論文では、意図を「追加・修正・終了」できる独立した状態としてモデルの外に持たせました。そのうえで、応答するかどうかの判断自体はモデルに任せるという役割分担を採っています。

評価方法にも工夫が光ります。各時点の判断を独立して採点する方法(Pointwise)に加え、動画全体を自分の出力履歴を引き継ぎながら走らせる方法(Trajectory)でも性能を測りました。その結果、各時点では正しく判断できても、通しで走らせると一気に崩れてしまうという落差を数字で浮き彫りにしています。

これまでこの論文はっきり書かれた依頼に反応する暗黙の意図・途中で変わる意図も推し量る長い履歴をそのまま抱える有効な意図と進み具合を状態として更新する各時点を独立に採点する自分の履歴のまま全編を走らせても評価する

図1 能動型映像エージェントの前提の違い。既存の能動型モデルと StreamVibe の前提を、意図・状態・評価の3点で比べたもの。

余計な口出しが減り、案内役の映像AIに効きそう

この研究で新しく見えたのは、その場その場の判断が正しくても、長く続くやり取りでは性能が安定しないという事実です。付録の集計を見ると、Pointwise では 63.5–75.6 あった Timing F1 が、Trajectory では 12.1–28.2 にまで急落しました。さらに既存モデルを並べて比較し、明示的な意図よりも暗黙・動的な意図のほうがはるかに難しいことも実証しています。能動型モデルの評価を「その時点で正しいか」から「最後まで一貫しているか」へと一歩進めた研究だと言えます。

この成果からいちばん恩恵を受けるのは、映像を見ながらタイミングよく助言するアシスタントを開発している人です。改善幅は決して小さくありません。要旨によると、StreamVibe-VL は応答のタイミングと答えの質で他のベースラインを 10.7% 上回り、Harness を組み合わせると能動的なやり取りの性能が 12.3% 伸びました。付録の表でも、RL 版の汎用タイミング評価において、誤反応の率(FPR)が 44.94 から Harness ありでは 6.84 へと劇的に下がっています。余計な口出しが減ることは、使う人の快適さに直結します。

具体的な使いどころとしては、次のような場面が考えられます。

  • 料理や工作の手元を一人称カメラで映し、「詰まったら助けて」といった大まかな頼み方で手順を案内するアシスタント
  • 画面操作を見守り、ユーザーが迷った瞬間に次の操作を示すコンピューター操作の補助
  • 途中で「さっきの通知はやめて、代わりにこれを見て」と依頼が変わる、長時間の監視タスク

今日から試すなら、アプローチは2つあります。1つは、プロジェクトページ(stream-vibe.github.io)で公開物を確認することです。ただし、論文の本文にはコードや重みの公開について明記がありません。もう1つは、設計の考え方だけを自前の Harness に取り入れることです。有効な意図の一覧を持たせ、意図ごとに「一度だけか、繰り返しか、完了したか」を記録し、判断の前に毎回その表をモデルに渡します。筆者の見立てでは、既存の映像モデルや LLM エージェントにも組み込みやすい設計です。ただし後述する手元の小さな実験では、文字ログを使ったやさしい問題だったため差は表れませんでした。

一方で、向かない場面もあります。モデル自体は大量の学習データと SFT・RL による訓練を前提としており、必要な計算資源の規模も本文には書かれていません。また、動画を 1 FPS に変換して処理しているため、それより細かい動きを読み取るタスクでどこまで通用するかは未知数です。Trajectory 評価での Timing F1 も、提案モデルですらまだ高いとは言えず、そのまま本番環境を任せられる水準には達していないと考えられます。

2段階の学習と、意図を管理する外付けの仕組み

まずは問題の定式化から見ていきましょう。エージェントは、その時点までの映像・ユーザーの発言・自分の過去の応答だけを手がかりに、毎時刻「黙る」か「応答する」かを選びます。各意図には、手助けすべき瞬間を表す「証拠点」が1つ以上設定されており、それぞれに応答してよい時間の幅と正解の応答が紐づいています。時間内に意味の合った応答を返せば、その点を「カバーした」と判定する仕組みです。

ベンチマークは3段階の難易度で構成されています。明示的な意図が 600 件、暗黙の意図が 2,000 件(案内・学習・監視・ツール操作)、動的な意図が 1,500 件です。動的な意図はさらに、修正(Revision)、追加(Composition)、割り込み(Interruption)の3種類に分かれます。合計で 4,100 件、証拠点は 20,546 個、動画の総時間は 183.4 時間に及びます。素材には、料理や組み立てなどの一人称動画と、GUI 操作の動画が使われました。Gemini-3.8-Flash で手助けすべき瞬間の候補を作り、4人の確認者が全員一致で承認したものだけを残しています。

モデルの学習は2段階のパイプラインです。第1段階の「適応的ストリーミング SFT(教師あり微調整)」では、データ源ごとに異なる「黙る/話す」の比率に合わせて、判断トークンの重みを調整します。モデルが黙りすぎたり話しすぎたりする偏りを防ぐためです。第2段階の「局所軌跡 RL(強化学習)」では、動画全体ではなく、手助けすべき瞬間の前後だけで短い試行を生成し、GRPO(複数の試行を比べて相対的に良いものを強める手法)で最適化します。動画全体で最適化してしまうと、正しい行動と誤った行動の貢献度が混ざってしまうからです。報酬には、時刻と内容の一致度を見る「点ごとの報酬」と、重複や矛盾がないかを見る「流れ全体の報酬」を、0.7 対 0.3 の比率で組み合わせています。

適応的SFTで「黙る/話す」の偏りを抑えて学習助けるべき瞬間の周りだけで局所RL(GRPO)Harnessが有効な意図・進み具合・既出の応答を保持階層的な記憶から関係する履歴を取り出すモデルが応答するか、何を言うかを決める

図2 StreamVibe の学習と推論の流れ。2段階の学習でモデルを作り、推論時に Harness が状態と記憶を渡してから判断させる流れ。

推論時には、Harness がモデルを外側から支えます。Harness が状態として管理するのは、「有効な意図」「作業の進み具合と環境の状態」「これまでに出した応答」の3つです。意図は1つずつ独立して扱われ、繰り返し型の意図はそのまま残り、一度きりの意図は達成された時点で閉じられます。過去の記録は階層的な記憶へと整理されます。直近の出来事は細かく残し、古い記録は要点だけに圧縮していく仕組みです。たとえるなら、付箋(いま有効な依頼)と日誌(過去の経緯)を整理して机に並べてくれる秘書のような存在でしょう。判断の直前に、現在の状態と関連する記憶をセットにしてモデルへ渡します。もっとも、最終的にいつ何を言うかを決めるのはあくまでモデル自身です。

全編を走らせると崩れ、Harnessで動的意図が改善

実験からはまず、多くのモデルに共通する弱点が浮かび上がりました。各時点を独立に採点すれば、適切なタイミングをそれなりに当てられます。ところが、自分の出力履歴を引き継ぎながら通しで走らせると、性能が大きく崩れるのです。[引用1] の評価では、全サブタイプの Timing F1 が 12.1–28.2、Content-F1 が 2.7–11.1 にまで落ち込みました [引用2]。著者らはさらに、見落としを減らそうとすれば誤反応が増えるというトレードオフの難しさも指摘しています [引用4]。

本文の分析によると、StreamVibe-VL は StreamVibe-Bench においてオープンソースのベースラインを一貫して上回りました。Pointwise 評価では Content-F1 が最も高く、応答の質は商用モデルにも迫ると報告されています。学習手法を比べると SFT より RL のほうが優秀で、とりわけ動的な意図で大きく伸びました。サブタイプ別に見ると、RL によって Timing F1 が最も伸びたのは状態遷移(P)の +7.2 で、FPR が最も下がったのは監視(Monitoring)の −15.3 でした。一般的な動画理解ベンチマークでも元のモデルを上回っており、能動的な振る舞いを学んでも基礎的な映像理解力が損なわれないことを実証しています。

Harness の威力は、動的な意図でくっきりと表れました [引用3]。付録の表で RL 版を比較すると、動的な意図の Timing F1 が 13.28 から 19.96 へ、FPR が 17.11 から 5.68 へ、Content-F1 が 5.25 から 8.91 へと軒並み改善しています。SFT 版でも Timing F1 が 9.83 から 16.25 に向上しました。

SFT9.83SFT +Harness16.25RL13.28RL + Harness19.96

図3 動的な意図での Timing F1(Harness の有無)。付録の表13(Trajectory 評価、±2秒)で、動的な意図の Timing F1 を Harness の有無で比べたもの。

ただし、すべての指標が上向いたわけではありません。同じ表を見ると、明示的な意図の RL 版では Recall が 41.68 から 16.20 に下がり、Timing F1 も 22.91 から 19.53 に低下しています。Harness は無駄な発言を抑える方向に強く働くため、その裏返しとして見落としが増える場面もあると読み取れます。

LLM頼みの評価と表の食い違いに気をつけたい

著者ら自身が述べている通り、現実のやり取りでは意図の変化がさらに多様で、ユーザーの要求と環境の変化がより複雑に絡み合います。そうした「人間と環境が共に変化する」状況への対応は、今後の課題として残されています。

評価の枠組みにもいくつか注意点があります。正解候補の作成には Gemini-3.8-Flash が使われ、応答の質は Claude Sonnet 4.6 が 0–4 のスコアで採点しています。つまり、どちらも LLM に依存した評価です。また、動画はすべて 1 FPS に変換して扱われています。

論文の数値を読む際にも注意が必要です。本文の表 2 にある Trajectory の数値の一部は、付録の表 7(Harness なし)ではなく、表 13 の「Harness あり」の行と一致しているように見受けられます。さらに、明示的・暗黙の列が入れ替わっているように見える箇所もあります。そのため本記事では、Harness の有無を比較する数値を付録の表 13・14 から引用しました。詳しく比較する際は、原文の表を直接確認することをおすすめします。

また、手法の再現には膨大なデータが求められます。学習には 85K 件(SFT 用 70K、RL 用 15K)のデータに加え、汎用ストリーミング動画 768K 件が使われました。ベースとなったモデルの名称や計算資源の規模、コードの公開先については、今回確認できた本文の範囲では見当たりませんでした。

なお、本記事は筆者が論文を読み解いて解説したものです。手元で動かしたのは次に紹介する小さな実験のみで、論文の実験結果そのものの追試は行っていません。

手元で試した結果

これは論文の追試ではなく、「意図を明示的な状態表で追跡すれば、古い意図への応答や重複、見落としが減る」という Harness の発想を、テキストだけで簡易的に試したミニ実験です。映像の代わりに、時刻付きの合成ログ10本(家事・GUI操作・スポーツ・実験をテーマに、意図の表明と出来事が約20行混ざったもの)を用意し、送るべき通知の合計件数を claude-haiku-4-5-20251001 に回答させました。条件Aではログをそのまま読ませ、条件Bでは1行ずつ意図の状態表を更新させてから件数を数えさせています。

結果は、条件Aが 10/10 問(100.0%)、条件Bも 10/10 問(100.0%)となり、正答率に差は出ませんでした。問題設定がやさしすぎたためです。違いが表れたのは出力トークン数だけで、平均出力トークンは条件Aの 3429.9 に対し、条件Bでは 5570.2 に増えました。もちろん、この実験では映像から証拠を見つける力や応答のタイミング合わせまでは検証できていません。問題数も少なく、プロンプトによる手順指示は論文の学習済み Harness とは別物です。

手元で試すなら

論文の本文にはコードの公開先が記載されていません。プロジェクトページとして stream-vibe.github.io/ が案内されているため、まずはそこでデータやコードの公開状況を確認するのが近道です。

原文からの引用

[引用1] Trajectory Evaluation runs the model continuously over the full video stream, with each decision conditioned on prior observations and self-generated interaction history.

(訳)Trajectory 評価では、モデルを動画全体にわたって連続して動かし、各判断はそれまでの観測と自分が生成したやり取りの履歴に条件づけられる。

[引用2] In contrast, Trajectory Timing F1 falls to 12.1–28.2 and Content-F1 to 2.7–11.1, revealing a substantial gap between local perception and sustained interaction.

(訳)対照的に、Trajectory では Timing F1 が 12.1–28.2、Content-F1 が 2.7–11.1 に落ち、局所的な知覚と持続的なやり取りの間に大きな隔たりがあることを示している。

[引用3] Figure 6(3) further shows that, with the policy fixed, adding the Harness continues to suppress unnecessary responses and improves content quality in most settings, with the clearest gains on Dynamic Intents.

(訳)図6(3)はさらに、方策を固定したまま Harness を加えると、不要な応答が抑えられ、多くの設定で内容の質が上がり、最も明確な改善は動的な意図で見られることを示している。

[引用4] Higher Recall often comes with more false triggers, suggesting that current methods cannot yet balance coverage against unnecessary responses.

(訳)Recall が高いほど誤った反応も増えがちであり、現在の手法はまだ網羅性と不要な応答の釣り合いを取れていないことを示唆している。

論文

確認日:2026年10月28日。この記事は、論文の本文をもとに AI(Claude)が下書きし、Gemini で日本語を整え、引用と数値を原文と機械で照合し、Codex が内容を確かめてから自動で公開しています。「手元で試した結果」は Claude Haiku で回した小さな実験で、論文の追試ではありません。