リアルタイムで映像を作ってくれるAIに「画面の中の車を赤く塗って」と頼んだとしよう。色はちゃんと変わったのに車がとんでもない位置にずれていたり、数秒後に「さっきの色、やっぱりなしで」と言ったのに赤いままだったら、どうだろう。画面は一見問題なさそうでも、肝心の頼んだことは間違っているわけだ。
StreamEvalは、まさにこの問いを投げかけるベンチマーク(性能評価の基準)だ。きれいに描く能力と、言われた通りにやり遂げる能力は同じものなのか? 評価対象は「対話型ストリーミング映像生成」モデルである。映像を一度きりで出力して終わりではなく、映像を作り続けている途中にユーザーの新しい要求をリアルタイムで受け取るモデルを指す。
その要求は5つのタスクに分かれる。アバターと会話する、アバターに動作をさせる(パフォーマンス)、仮想空間を作る(ワールド生成)、言葉で指示して映像を編集する(指示編集)、参照画像に合わせて編集する(リファレンス編集)だ。
これまでの映像生成評価は、たいてい「完成したクリップ1本がどれだけそれらしいか」を見てきた。画質・安定性を見るVBenchやEvalCrafter、シーンが説明と合致しているかを見るT2V-CompBenchがそうだ。いずれも出来上がった映像1本を前にして採点する。
ストリーミング生成は違う。映像が止まらずに流れている最中に「視線を左へ向けて」「この物体を赤色に」「さっきの編集は取り消して」といった要求が、それぞれ別々のタイミングで割り込んでくる。要求ごとに3つのことが付いて回る。いつ反映するか(タイミング)、何を触るか、何はそのままにするか(保存)だ。従来の評価には、この3つをタスクごとに明示して測る枠組みがなかった。StreamEvalが埋めようとする空白はここにある。
ストリーミングを狙った評価がなかったわけではない。ただ既存のものはそれぞれ一つの領域に集中しており、StreamEvalはそれらを一つのセッション規約のもとにまとめ、「何をして何を守るか」をタスクごとに明示した点が異なる。扱うシステムの数も幅広い。
| ベンチマーク | 何を見るか | 扱うシステム |
|---|---|---|
| WBench・WBench-Editing | 生成されたワールド内での連続編集と保存 | 20個 |
| WorldMark | ワールド生成系 | 10個 |
| StreamAV-Bench | 音声・映像の相互作用更新 | 13個 |
| LongV2VBench | 長い元ストリームの編集 | — |
| VideoFDB | 対話エージェントの非言語的な視聴覚の手がかり | — |
| StreamEval | 上記タスクを一つのセッション規約へ統合 + 明示的な遂行・保存基準 | 37個 |
幅広いからといってすべての細かな能力をカバーするわけではない、と著者らは線を引く。たとえばVideoFDBが見る「ユーザーの映像をリアルタイムに知覚する」能力は、StreamEvalが見る指定会話・パフォーマンスとは相補的であって、包含関係ではない。
StreamEvalはテスト一つひとつを「台本のあるセッション」として組んだ。セッションごとに初期資産(人物の肖像、シーン、元映像)が与えられ、その上に要求が時間割に沿って一つずつ到着し、「何を変えて何を守るか」の正解表が一緒に束ねられる。
先ほどの車をもう一度見よう。編集タスクのあるセッションはこう流れる。流れる映像の中の車を赤く変え、残りのシーンは触れずにその状態をしばらく維持したうえで、次に「車の色を取り消し」を反映する。肝心なのは取り消しが入ったときだ。車の色は元に戻らなければならないが、車の位置は最初ではなく、今この瞬間の映像の中の位置でなければならない。映像はその間も流れ続けていたからだ。論文はこの巻き戻しを「その時点の元の状態(contemporaneous source)の復元」と定義する——先に加えた編集をその時点の元の状態へ戻すことであって、他の編集は生かしたまま特定の編集だけを選んで取り消す「選択的復元」ではない(後者は§4.2で今後の拡張課題として明示されている)。色の変更(遂行)・残りのシーンを守ること(保存)・その時点の元に戻すこと(復元)が、一つのシーンの中にすべて収まっている。
入力が最初から一度にまとめて与えられないことも重要だ。スケジューラがセッション時計に合わせて要求を一つずつ解放し、編集対象の元映像も同じ時計の上で進み続ける。
採点は「一回の要求」を複数の角度から見る。4つのまとまり、その下に10個の指標(すべて0〜100点)だが、車の事例でどんな失敗を捉える指標なのかを見れば分かりやすい。
このうちStreamEvalが特に掘り下げたのは遂行・保存、そして復元だ。復元(「さっきの色を取り消し」のように先の編集をその時点の元の状態へ戻すこと)はEdit Successの中で一緒に検査される。英語の名称はタスクに合わせて選んで適用する。たとえばFollowingはアバターパフォーマンスとワールド生成に、Edit Successは二つの編集タスクに使われる。指標ごとに「何を測るか」が決まっているので、結果を遂行と画質に分けて読むことができる。
タイトルが約束した「きれいに」と「言われた通りに」のギャップは、一つのモデルの中で最も鮮明に表れる。MuseTalk 1.5はQuality 95.34、Stability 97.11、Identity 88.44で、見た目と安定性は最上位圏だ。ところがA–V Syncは38.09、Dialogueは54.34まで下がる。見た目は非の打ち所のない「話す顔」だが、口と音を合わせ会話の要件を満たす方へ行くと点数が大きく落ちる。
LiveAvatar FULLはさらに極端だ。Stability 100.00にA–V Sync 0.00。ただしこの二つは互いに別のものを測る指標だ。Stabilityは画面がフレーム間でぶれない度合いを、A–V Syncは口と音が合っているかを見る。画面が安定しているという点数と、指示に反応したという点数は同じ軸ではない。
ギャップが最も大きく開くのは「要求遂行」だ。以下は各タスクで最も高い点数である(平均ではなく最高点)。
この3つは互いに異なるタスク・条件の最高点なので、一つにまとめて語ってはいけない。Followingは「要求された操作が指定された対象に実際に起きた制御イベントの割合」、Edit Successは「範囲・活性状態・締め切り・持続・保護コンテンツの検査をすべて通過した完全な編集の割合」だ。かみ砕くと、アバターパフォーマンスで最も優れたモデルでさえ、言われた動作の約37%しか指定通りにやり遂げられず、リファレンス編集で最も優れたモデルでさえ、完全な編集を15%しか終えられなかった。
ただし、この「遂行は低く画質は高い」という図式がすべてのタスクでそのまま成り立つわけではない。アバター・パフォーマンス・ワールド生成では画質・安定性が遂行を大きく上回るが、指示編集はその正反対だ。 指示編集の先頭Vidu S2 EditingはFollowing 72.10・Edit Success 57.20で遂行が高い代わりに、Quality 22.99・Stability 13.94で画質・安定性が落ち込む(論文も指示編集の低い画質・安定性を指摘している)。つまり「きれいに」と「言われた通りに」が食い違うという結論は保たれるが、どちらが見劣りするかはタスクが分ける。タスクごとにどのモデルが先行したか、設定によって点数がどう分かれるかは以下の表にまとめた。
読み方。 点数は実行3回の平均 → ケース平均 → 5つの長さ区間の平均の順にまとめ、5つの長さに同じ重みを与える(短いセッションで点数を稼ぎすぎるのを防ぐ仕掛け)。また編集タスクの「報告されたモデル数」は全評価対象ではなく、Overall 5点以上だけを絞り込んだ発表用の部分集合が基準だ。この絞り込みは評価が終わった後に行われた。
タスク別の総合(Overall)先頭
| タスク | 先頭モデル |
|---|---|
| アバター会話・パフォーマンス | Vidu S2 Avatar |
| ワールド生成 | MemFlow |
| 指示編集・リファレンス編集 | Vidu S2 Editing |
個別指標まで降りると別の名前が上がってくる。アバターパフォーマンスのQuality 1位はLiveTalk、指示編集のPreservation 1位はJoyAI-Video-Editだ。一つのモデルがすべての次元を取っていく構図ではない。
先頭モデルの中でもギャップは見える。アバター会話でVidu S2 AvatarはQuality 96.78、Identity 90.12で見た目は高いが、Dialogueは75.29だ。タスクのOverallは93.98だが、これはQ-Overall 88.98にカスタマイズボーナス5点が加わった値である(ボーナスは下のFAQ参照)。
固定アバター設定では、Identityをシステム自身の最初のフレームと比較する。
| 固定アバター | Q-Overall | Identity |
|---|---|---|
| Tavus CVI Full | 86.65 | 89.89 |
| LiveAvatar FULL | 65.07 | 87.70 |
Edit Successは「完全な編集の割合」だ。一回の編集が成功と認められるには、4つを同時に通過しなければならない。① 指定した対象だけを選んだか(範囲) ② 変えてはいけない場所を守ったか(保護コンテンツ) ③ 定められた期限内に反映したか(締め切り) ④ その結果を最後まで維持したか(持続)。4つの条件をすべて通過して初めて1件と数えるので、一つでも外れればその編集は成功と数えない。
これが個別の品質点数と違う点だ。画質(Quality)は「どれだけそれらしいか」を0〜100の連続値で付けるが、Edit Successは「全部合っていたか、そうでないか」の合否に近い。だから画質は高いのに編集成功率はその下に大きく落ち込むことが起きる。絵は問題なくても4条件のうち一つを落とした、という意味だ。
ただし低い点数が「なぜ」低いのかまでは総合点数は語ってくれない。対象を選び間違えたのか、守るべき場所を触ったのか、期限を逃したのかは別に測らないと分からない。たとえば同じ編集要求に、最初は対象だけを指定し、次に「これはそのままにして」という保存条件を、その次に「数秒以内に」という時間条件を順に重ねていき、どの条件が付いたときに成功率が崩れるかを見る、といった具合だ。これは論文の結果ではなく、結果が残した次の問いである。
結果の数値だけ読むなら飛ばしてよい。自分で動かしてみたい人のための制作・検証の詳細を付録としてたたんでおく。
**規模。** 37個のモデル、47個のタスク構成を評価した(一つのモデルが複数のタスクに上がると、モデルとしては一回、タスク構成としてはタスクごとに数える)。タスク別の構成数はアバター会話15、アバターパフォーマンス7、ワールド生成17(テキスト12 + 画像5)、指示編集5、リファレンス編集3だ。 **ケース。** タスクごとに60個、各ケースは15・30・60・120・300秒の5つの長さに12個ずつ均等に敷かれる。300個のケースは240個の独立ソースファミリーにまたがり、音声ターンを同じ同一性のテキストに置き換えたテキスト会話派生60個が既存ファミリーを再利用する。一度すべて回すと、純粋なストリーミング生成だけで525分、計画されたオンラインイベントが1,347個になる。ケース・モデルごとに独立実行を3回行う。 **集計。** タスク総合(Q-Overall)は適用指標の等重み平均だ(ワールド生成は4指標、残りは5指標)。アバターの二つのタスクにはカスタマイズボーナスが付き、順位用Overallが最大105まで上がる(FAQ参照)。 **制作。** セッション目標・タイミング・保護属性・期待結果の下書きはQwen3.8-Maxが書き、各チェックポイントで何を確立・維持・取り消し・復元するかを記した「オラクル」は人間が著作する。人物の肖像・視覚リファレンスはGPT-Image-2とQwen-Imageで合成し(実在人物ではなく合成の成人または様式化された仮想キャラクター)、音声はQwen3.5-Omniで作る。編集の元素材はWikimedia Commons・NASA・Blender Studioなどのライセンス実写・アニメーションとベンチマーク生成シーンを使い、ループや速度変更なしにセッション全体を覆う。 **検証。** 合成音声はQwen3-ASRの書き起こしが台本に対して正規化単語誤り率0.25以下でなければならず、画像はQwen3.8-Maxが鮮明さ・欠陥を監査する。自動採点の審判はクラスごとに偽陽性5%・偽陰性10%・未決定10%以下という基準で較正し、Identityは二つの審判(Qwen3.8-Max-0902、Qwen3-VL-Plus)の点数のうち低い方を取って、同じ画風で人物が入れ替わるのを防ぐ。
著者らが明かした限界からみよう。A–V Syncは口の開きと音声包絡線の相関(≥0.3)で測るが、ソースを粗くサンプリング(会話500ms、パフォーマンス250ms)するため、ごく微細なリップシンクのずれはこの指標の分解能の外にある。また審判が確信できなかった「未決定」項目は下限0・上限100の区間を作るが、表には下限を載せる。確信できなかった項目が多いほど、そのモデルの点数が保守的に(低く)付くという意味だ。
ここにいくつか付け加えておきたい点がある。第一に、台本・オラクルの下書きと画像監査をすべてQwen系が担う。特定のモデルファミリーの好みや死角が評価設計に染み込む余地が構造的にある(著者らは審判較正でこれを抑えようとしている)。第二に、人物はすべて合成で、編集ソースはライセンス実写・アニメーション・生成シーンだ。ユーザーが自分の顔・自分の映像を入れる実環境とのギャップが残る。第三に、これは特定時点のリーダーボードのスナップショットだ。モデルが急速に更新される分野なので、絶対的な点数より「画質と遂行は並んで進まず、タスクによってどちらが見劣りするかも変わる」という構造的な結論の方が長持ちする。
ONTLEは、人を雇いにくい小規模企業や一人起業家の反復業務をAIで手助けするサービスだ。扱うのは映像ではなく文書・スケジュール・予算といった業務だが、「時間差で入ってくる指示を反映しつつ、すでに確定したものは守る」という評価構造はそのまま持ってこられる。セッション設計(初期状態 + 時間割通りに到着する要求 + チェックポイントごとの「確立・維持・取り消し・復元」の正解表)は、映像であれ業務であれ同じだからだ。ただし、自動採点の基準は業務ドメインで新たに立て直す必要がある。
ONTLE自身のQAに入れてみるセッションを一つ書いてみる。
正解は明確だ。最後の要求で巻き戻すのは「予算削減」一つだけであり(予算は削減直前の値に復元)、A案の確定と新たに加えたBチャンネルはそのままにしなければならない。StreamEval流に移すと、Following(指定したものだけを変えたか)・Preservation(確定事項を守ったか)・Edit Success(取り消し・復元・追加が条件をすべて通過したか)をセッション単位で採点することになる。ただし断っておくことがある。このように他の変更(A案・Bチャンネル)を生かしたまま特定の変更だけを選んで巻き戻す「選択的復元」は、StreamEvalが今評価する範囲ではなく、§4.2で今後の拡張課題として明示された領域だ。現在のベンチマークが測る復元は、先の編集をその時点の元の状態へ戻す方である。だからONTLEのQAがこの選択的復元まで狙うなら、現在のベンチマークより一歩先へ進んだことになる。
ここで確認するのは、成果物が見栄えよく仕上がったかではなく、幾度もの指示の中で確定事項を保存し、特定の変更だけを選んで取り消したかだ。取り消し・復元は人間もよく間違える場所だ。ONTLEのQAが見栄えよく整理されたレポートを確認するだけで止まらず、こうしたセッションを回してみれば、まさにその一つの能力だけは数値で答えられる。
自分のサービス(対話型・エージェント・ストリーミング製品)にこのベンチマークの枠組みを適用するなら、すぐ点検すべき項目だ。
アバター会話・パフォーマンスの二つのタスクにだけ「カスタマイズボーナス」がある。ユーザーが好きなアバターを入れられるシステムは+5点を受けて順位用Overallが最大105まで行き、供給元が固定したアバターしか使えないシステムは0点だ。このボーナスはインターフェース能力を示すだけで、0〜100スケールのQ-Overall(基礎指標)の点数自体は変えない。だからQ-Overallと順位用Overallは区別して見るべきだ。
リーダーボードは https://streameval.ai にあり、論文の抜粋にはGitHub(github.com/StreamEval/StreamEval)とHuggingFaceデータセット(huggingface.co/datasets/StreamEval/StreamEval)のリンクが併記されている。タイムライン・オラクル・メディアを含むすべてのケースを公開すると明らかにしており、編集ソースの第三者アセットはアセットごとのライセンス・出典がデータリリースで提供される。