夜間の管制室を思い浮かべてほしい。管制員はモニターを見つめながら、重要な場面が過ぎるたびに、横のノートへ時刻とともに一行ずつ書き留めていく。しばらく経って誰かが「さっきのあれ、何でしたっけ?」と尋ねると、映像テープを巻き戻す代わりに、いまの画面とそのノートを一緒に見る。ノートだけで過去の文脈がよみがえる。
南京大学などが公開したストリーミング(リアルタイムで途切れなく流れ込む)動画AI「OneStreamer」がやっているのは、まさにこれだ。観察した場面を自らタイムスタンプ付きキャプション、つまり「いつ何を見たか」を書いた短い説明文として残しておき、あとの質問にそのメモを取り出して使う。Qwen3-VL-4Bをベースにした40億パラメータの小さなモデルでありながら、ストリーミング動画理解の性能試験8つで比較対象をすべて抜き去った。小柄なのにここまでやれた秘訣は、この「メモ」一つにある。
リアルタイム動画AIの悩みは、思った以上に厄介だ。CCTVを見る警備員や、身につけるアシスタント機器を思い浮かべてほしい。目の前を今しがた通り過ぎた場面が、あとで重要になるかどうかは、その瞬間にはわからない。些細に見えた場面が、10分後に質問の核心的な手がかりになることもある。ところがその頃には、その場面はすでにモデルの狭い作業記憶、すなわちコンテキストから押し出されて消えたあとだ。
これまでの対処は大きく三つの方向に分かれ、それぞれに弱点があった。
一つ目、過去を取り出し直して使うやり方。 過ぎた動画を圧縮したり検索したりして呼び戻す。問題は、保持しておいた過去の動画の断片が、いま入ってくる場面と狭いコンテキストの席を奪い合う点だ。過去を多く握るほど、現在を見る目が曇る。
二つ目、推論をひたすら更新していくやり方。 動画が流れる間ずっと「いまの状況はこうだ」という考えを絶えず書き直す。だが「自分はこう判断した」という思考の痕跡と、「何がいつあったか」という事実の記録は別物だ。思考の痕跡は、あとでそのまま取り出せる事実の帳簿にはならない。
三つ目、特殊な信号で「答えるか否か」を制御するやり方。 ここにはデータの偏りという落とし穴がある。動画のほとんどの瞬間は「まだ静かに見守っている最中」であり、実際に何かを出力する瞬間はまれだ。これらの瞬間をすべて同じように学習させると、モデルは「沈黙」ばかりを過剰に学んでしまう。
核心の問いは一つに絞られる。入ってくる観察を、どうやって「取り出し直して使える事実の記憶」に変え、過去と現在の双方の証拠を使った時宜を得た応答へとつなげるか。
OneStreamerの設計は一文に要約できる。いつ口を開くかと、何を出力するかを、途切れずに流れる一本の流れの中でまとめて学ぶ。
ふつうAIが文を「生成」するといえば、ユーザーに見せる答えを作ることを指す。OneStreamerは同じ生成能力を、ユーザーには見えない「観察メモ書き」にも使う。過去を保存するために動画の断片を増やす代わりに、観察するその瞬間にあらかじめテキストで書き取っておく。検索ではなく記録だ。テキストは動画の断片よりずっと軽いので、席を取らない。
このメモ帳の役割を担う仕組みがPHCM(観察を書き留める階層型記憶)だ。二つの粒度で書く。短い区間を密に書き取る詳細記録と、完結した出来事をより粗い時間単位でまとめる疎い要約がある。各記録はそれを裏づける元区間の時刻に紐づいているので、「細部 ↔ 出来事の要約」という階層をなす。
巧みな点は、動画入力そのものは「直近の窓」に固定しておくことだ。先に入った場面から順に押し出される、直近の数場面だけを収める窓である。過去を抱え込むためにこの窓を広げたりはしない。過去はテキストメモとしてのみ持ち運ぶ。だから遠い過去の文脈を握りながらも、いまの場面を見る目は狭くならない。タイトルの「現在を曇らせずに」とは、まさにこの点、つまりいまの場面を見る視野を指している。応答速度そのものを指す言葉ではない。ただし本論文も応答遅延は測っている — 最初のトークンが出るまでの時間(TTFT、§5.3 表4)で、PHCMは0.124秒、FIFOは0.094秒と、過去動画を丸ごと抱えるFullの4.560秒よりはるかに速い。ただしこの数値は、あらかじめ書いておいたメモを取り出して使う応答段階だけを測ったものなので、観察から応答までの処理全体の遅延とは区別して見る必要がある。
二つ目の軸は、「いつ口を開くか」を教える方法だ。原理は一文で言える。ありふれた沈黙は一部だけを選んで教え、まれだが重要な行動 — メモを残すか、応答を始める瞬間 — は一つ残らず全部教える。 こうして沈黙の数的優勢を抑え、モデルが永遠に様子をうかがうだけになるのを防ぐ。
制御信号はこう使われる。記録も応答もせず静かに観察する、記憶メモを残す、「証拠は浮かんでいるがまだ答える準備はできていない」という待機、そしてユーザーに見える答え。この四つが同じ一本の流れの中で代わる代わる現れる。
この論文でいちばん興味深い結果は、総合スコアではなく、過去と現在の古くからのトレードオフを打ち破った点だ。 これまでは、過去を多く持つほど現在の場面判断が悪くなった。OneStreamerは過去を動画ではなくテキストに変えて持ち運ぶことで、そのトレードオフをかなりの部分かわした。
これをどう確かめたか。同じチェックポイントに同じ「直近16場面」の窓を固定しておき、ただ一つだけを変えて比較した — 観察中に書いたキャプションメモを後の予測に残すか残さないか。三つを突き合わせる。古いものから捨ててメモを残さないやり方(FIFO)、過去の動画を丸ごと保持するやり方(Full)、そして過去をキャプションメモとして持ち運ぶOneStreamerのやり方(PHCM)だ。
まず現在のほうから見よう。メモを持ったPHCMは、現在知覚のスコアをメモを持たないFIFOほども削らなかった。OVOBenchのリアルタイムが80.9から81.4へ、StreamingBenchのリアルタイムが86.3から前の表の86.9へと、むしろ上がった。過去のほうはさらに印象的だ。過去の場面をたどり直す正確度の指標(原文表記ASI)で、FIFOの63.5がPHCMでは71.6へ跳ね上がる。動画を丸ごと抱えていたFullの67.6よりも4.0ポイント高い。OVOBenchの総合もPHCMが最も高く(前の表の72.1)、Fullの70.9とFIFOの70.1をどちらも上回る。
正直に付け加えると、過去に関わるもう一つの指標(原文EPM)でだけは、PHCMの62.6がFullの63.0にわずかに及ばない。すべての過去タスクでメモが動画保持に勝つわけではない。
この土台の上に総合成績が出る。40億のOneStreamerが、ほぼ3倍大きい110億モデル(MOSS-VL-Realtime)をほとんどの評価で上回った。ベースモデル比で平均25.0%、各ベンチマークで最も強い競合手法と比べても6.1%高い。
| 区分 | ベンチマーク | OneStreamer-4B | Qwen3-VL-4B比 | MOSS-VL-Realtime(11B)比 |
|---|---|---|---|---|
| 知覚・記憶 | OVOBench | 72.1 | +13.3 | +1.9 |
| StreamingBench Real-Time | 86.9 | +5.1 | +4.0 | |
| OVBench | 66.8 | +11.4 | +13.1 | |
| ODVBench | 71.3 | +13.7 | +7.4 | |
| 能動応答 | ProactiveVQA | 48.7 | +14.4 | +1.5 |
| OmniMMI (ASR使用) | 36.6 | +7.2 | +3.9 | |
| OVO-Timing (F1) | 41.6 | +12.2 | +3.1 | |
| ViSpeak | 2.87 | (ベース 2.41) | (11B 2.48) |
「いつ口を開くか」を教える方法も、数字で結果を出した。状態表示の27.5%しか教えていないのに、すべてを密に教えるやり方と「量だけ同じに合わせたランダム選択」の両方を上回った。少なく教えたのによりよく学んだわけで、ありふれた沈黙を間引いて口を開く瞬間だけを残した選択が効いた、という解釈だ。
この設計の命運は「メモの質」にすべてかかっている。過去を動画ではなくモデルが書いたキャプションとして持ち運ぶので、キャプションが間違っていれば、その誤りがそのまま記憶に刻み込まれる。元の場面はすでに窓から押し出されたあとなので、巻き戻して確かめる術もない。誤って書かれた一行が、以降のすべての予測を汚染しかねない。
なぜこの問題が起きるのか。学習時は検証済みの「正解キャプション」で教えるが、実際に動かすときは横で検証してくれる人がいない。モデルは自分がたった今生成したメモをそのまま信じ、その上に積み上げる。学習環境と実環境のこの隔たりから、誤りの蓄積が芽生える。自分が書いた記憶の誤りをどう防ぐかは、さらに掘り下げるべき点だ。
評価がすべてベンチマークスコアだという点も指摘しておかねばならない。4Bが11Bを上回ったという結果が、この特定の試験紙に対する適合なのか、試験紙の外の実際のライブストリームでも保たれる優位なのかは、ベンチマークだけでは判別できない。これはこの論文だけの問題ではなく、この分野全体が抱える限界だ。
この原理を動画ではなく「業務協働」というストリームに移すとどうなるか。一日中、会議・チャット・作業ログが途切れなく流れるチームを傍らで見守るAIマネージャーを想像してみよう。人間のPMがついても、その人が一日中回るすべてのストリームを独りで見きることはできない。この点で論文の設計がつながる。重要なのは動画という題材ではなく、「ストリーム」というデータの形そのものを扱うやり方だ。
一つの場面を最後まで追ってみよう。火曜の午後、顧客がチャットで「納期を金曜から来週火曜に延ばしてほしい」と言う。チームは短く議論し、開発の順序を変えることにする。三日後、別の担当者が尋ねる。「あのとき、なぜ納期を変えたんでしたっけ?」
これまでのこうしたPM型エージェントの標準的な解法は、すべての会話を保存しておき、質問が来たら関連する断片を検索して引っ張ってくるやり方だった。OneStreamer流の絵は趣が違う。ストリームが流れるその瞬間に、エージェントが自ら「火曜15時、顧客の要請で納期を金→火に変更、根拠はこれ」と一行書き留めておく。三日後の質問には、ログ全体をたどり直す必要はなく、直近の文脈とそのメモ一行だけを見ればいい。
ONTLEのAI PMが扱うのも、動画ではなくこうしたテキストの業務ストリームだ。だから論文の技法をコードごと移植することはできない。だが「見ている間に決定の事実記録を残しておく」という設計原則は、題材を超えてそのまま使える。ここに、PMの感覚の二つがデータ設計へと翻訳される。一つ、ほとんどの瞬間は静かに見守るが、話しかける瞬間はまれだということ — 沈黙の事例だけで学べば、エージェントは永遠に様子をうかがうだけになる。二つ、証拠が十分になる最も早い時点で割って入るということ — 生煮えの報告で空振りもせず、終わったあとでようやく報告することもない、そのタイミングの感覚だ。
そして弱い環も一緒についてくる。エージェントが書き留めた「根拠はこれ」が間違っていたらどうするか。幸い、動画と違って業務ストリームは元のログがそのまま残る。メモと元ログを突き合わせる検証ステップを挟み込めるということだ。自分が書いた記憶の誤りを防ぎにくいという論文の弱点を、テキスト業務という環境がむしろ補ってくれるわけだ。
いいえ。GeminiとSeedは学習用の正解キャプションを作って検証するのにだけ使われました。実際にサービスするときは、OneStreamerが独りで自分のメモを書きます。まさにそのために、動かすときは横で検証してくれるモデルがおらず、自分の書いたメモを信じて積み上げるという弱点が生じます。
テキストメモは動画の断片よりずっと軽いので、同じ席にはるかに多く入ります。完結した区間は疎い要約で粗くまとめられ、密な詳細記録とともに「細部 ↔ 要約」の階層をなします。ただし論文は、詳細キャプションと出来事の要約をどちらもテキスト履歴に加えて積み上げるだけで、要約で詳細記録を消したり記憶サイズを制限したりする方針は置いていません。
論文はCC BY 4.0で、プロジェクトのホームページが公開されています。ただし学習規模が大きいため再現の難易度は高いです。具体的なリソース規模は上の「学習の詳細」を参照してください。