AI に「見ながら話させる」従来の3つのやり方、それぞれの弱点

今回の一手の価値を測るには、まず従来の3つの道筋と、それぞれが引っかかっていた場所を知る必要があります。

1つめ、伝言リレー方式。音声をテキストに変換し、画像モデルが映像を見て、大規模モデルが答えを考え、テキストを音声に変換する。4つのモジュールが一列に並び、前が終わってようやく次の番が来ます。遅延が層ごとに積み上がるだけではありません。話すときの語気、速さ、ためらいは「テキストに変換」の段階で削ぎ落とされ、後段のモデルには味気ない一行の文字しか届きません。この構成の正式名称は cascade system。リレー競走だと思ってください。バトンを渡すたびに、何かが少しずつこぼれ落ちます。

2つめ、1つのモデルが音声を直接受け取り、音声を直接吐き出す方式。途中でテキストに変換しません。これがいわゆる end-to-end です。速く滑らかになりましたが、耳はあっても目がありません。OpenAI が7月に出した GPT-Live も、ByteDance が4月に出した Seeduplex も、この段階です。

3つめの道が、いちばん「もう解決済み」と誤解されやすい

3つめ、カメラは見られる。ただし話し終わったかを判断するのは、依然として音しか聞かない小さなモジュール。このモジュールは VAD（voice activity detection、音声区間検出）と呼ばれ、役割は気の毒なほど単純です。「今、誰かが声を出しているか」だけを判定します。無音を手がかりに、話し終わったかを推測するわけです。早すぎれば話の途中で遮られ、遅すぎれば言い終わってもしばらく反応がありません。

Google のリアルタイム音声プロダクト Gemini Live を例に取ります。たしかにカメラや画面共有をつなげますが、LiveKit の公式接続ドキュメントがこの点を明記しています。Gemini Live API の turn detection は「内蔵の、VAD ベースのもの」（built-in VAD-based turn detection）で、デフォルトで有効です。同じドキュメントにはフレーム取得の頻度も書かれています。ユーザーが話しているときは毎秒1フレーム、話していないときは3秒に1フレームです。

フレーム取得の数値は LiveKit というフレームワークのデフォルト値で、Gemini 本体の能力上限ではありません。自分で調整できます。ただし turn detection が VAD 依存だという点は、Gemini Live API 自体の話です。

今回の変更点：しゃべるべきかを判断する場に、映像も参加させた

SeedRealtime がやったことは1つだけです。音声、映像、時系列、表現を、同じ end-to-end モデルに統合しました。「まず聞き終え、次に見終え、最後に答える」という流れはもう踏みません。連続した音声・映像のストリームの上で、見ながら聞きながら計算し、あらゆる瞬間に判断しています。今しゃべるべきか、見続けるべきか、それとも黙っているべきか。

外付けの VAD は、これで存在意義を失いました。ターン判断は外部ルールから、モデルが刻々と下す内部の決定へと変わりました。そしてその決定には、映像が見えています。

エンジニアリング面で公式が触れているのは2点だけです（公式サイトのプロジェクトページのみ。WeChat 版には記載なし）。連続する音声・映像のチャンク入力とストリーミング生成出力で応答時間を短縮し、効率的な量子化と推論最適化でサービス効率を高めた、と。具体的な遅延の数値は出ていません。

2つの難所：映像には借りられるポーズがない、ユーザーの「これ」はどれか

判断をモデルに任せる、と言うのは簡単ですが、実装は2か所で詰まります。この2つは公式自身が挙げているものです。

難所1：映像には借りられるポーズがない

音声には自然なポーズがあり、それを「話し終わった」の信号として使えます。映像は違います。常時オンで変化し続け、自然な区切りがありません。モデルは画面で何が起きているかを絶えず理解しつつ、背景で誰かが話しているだけで頻繁に割り込んではならず、さらにどの対象に注目すべきか、誰の話を聞くべきか、そして今まさに応答すべきかどうかを判断し続ける必要があります。

難所2：あなたの言う「これ」は、どれのことか

「これ、どうやるの」と言ったとき、「これ」は何を指すのか。モデルは今の映像、手のしぐさ、視線、さらに数秒前の動作まで組み合わせて、ようやく対象を特定できます。同音異義語や曖昧な発音に出くわしたときも、目の前の状況で意味を切り分けます。画面に映っているのが四川料理店なら、「魚香」が別の意味に取り違えられることはありません。

音声と映像と時系列情報を統一的にモデル化して初めて、見たもの・聞いたもの・話すことを本当に対応づけられます。「映像を判断に接続する」を、既存システムに視覚モジュールを外付けするだけでは済ませられない理由がここにあります。

公式の実写デモ7本

公式は完全な実写デモを一気に7本公開しました。各1〜3分で、3つの能力グループに分かれます。まずスマホでの見え方から。通話画面には、今それが話しているのか聞いているのかが常時表示されます。

左上に「話しています…」の表示。出典：ByteDance Seed

この瞬間は「聞いています…」の表示。出典：ByteDance Seed

グループ1：画面に誰がいるか分かり、誰が話しているか聞き分ける

友人4人での食事。人数が多く話も飛び交います。ユーザーが1人ずつ紹介すると、モデルは外見の特徴を頼りに名前と人物を結びつけました。明るい髪色の七七、眼鏡の Julia。楽楽には自分から挨拶までしています。その後、話題は旅行へ。海辺で写真を撮って水族館に行きたい人、暑さと疲れが苦手な人、海鮮アレルギーの人。モデルはどの発言が誰のものかを聞き分け、最後に全員の要望を汲んだ旅行プランを出しました。人物の認識、声の聞き分け、それぞれの要望の理解を、1つのモデルが同じ会話の中でリアルタイムに済ませています。

四川料理店で、外国人客が中国語のメニューを前に固まっています。モデルは画面から直接料理を認識して英語で勧め、さらに文化的背景から「なぜ魚香肉絲に魚が入っていないのか」「ピータンはどう作るのか」まで説明しました。店員が料理を運びながら「ご飯が進みますよ」と言うと、画面の料理と結びつけてその一言を理解し、客に翻訳して伝えます。視覚情報をいったんテキストに変換してから理解する必要はありません。目の前にあるものに、そのまま答えられます。

グループ2：こちらが聞かなくても、自分で判断して動く

河北博物院での展示鑑賞。ユーザーが「錯金銀銅虎噬鹿屏座が見えたら教えて」と一言伝えて、あとは自由に見て回ります。カメラが動き続け、その展示品を通りかかったところで声を出して知らせました。その後も画面の細部と結びつけて、錯金銀四龍四鳳銅方案座や長信宮灯、さらに鋳造・錯金銀・溶接といった技法まで解説しています。このデモが見せているのは、依頼をコンテキストに保持し、対象が現れたら自分から口を開く動きです。

ユーザーがコーヒー豆を丸ごとポルタフィルターに入れると、モデルはそれを見た瞬間に「豆はそのまま入れられません。まず細かく挽く必要があります」と指摘しました。抽出が終わると、カップの中のクレマの色と液量を見て「次は抽出時間を2〜3秒短くしましょう」と自分から提案します。ユーザーは終始、何も質問していません。

ResNet 論文を読む場面。モデルはまずネットワーク構造図と結びつけて、スキップ接続がどう勾配消失を緩和するのかを説明します。次にユーザーが「見張っていて、学習パラメータの部分まで来たら教えて」と頼むと、高速にページをめくる間も画面を見続け、「3.4 Implementation」の節を見つけて自分から止めました。続けて学習率、モーメンタム、重み減衰といった設定を読み上げています。

グループ3：騒がしい場所で、誰の話を聞くべきか分かる

大興空港は人が多く、環境音も騒がしい場所です。同行者が雑談の中で「李さんのフライト」と口にしても、モデルはその無関係な一言では反応しませんでした。ユーザーが正式に尋ねると、フライト情報はすでに画面の外へ流れていたにもかかわらず、先ほど見た大型ディスプレイの情報からリアルタイムの到着時刻を答え、さらにネット検索で手荷物受取ターンテーブルの位置まで補足します。その後2人が歩きながら昔話をしていると、配車サービスの案内表示が目に入ったところで自然に話に入り、乗車場所への経路を伝えました。

母親が別の用事をしている間、娘の動物の英語学習に付き添わせています。背景では父親が電話中で人の声が途切れませんが、モデルは引きずられることなく、女の子が指さす方向に合わせてリアルタイムに発音を直し、例文を作り続けました。

公式が出した数字：会話の詰まりが従来の半分

デモは見栄えがしますが、定量的な結論は1つだけです。end-to-end の人間評価によれば、伝言リレー方式の cascade system と比べて、音声・映像会話のテンポ問題が半減した、と。ここでの「テンポ問題」は3種類の詰まりを指します。話し終わる前に遮られる、話し終わってもしばらく反応がない、背景の雑音や周囲の雑談で誤作動する、の3つです。

もう1つ「1回の会話を最後まで滑らかにやり切れる確率も明確に向上した」という記述がありますが、数値は出ていません。

出ていないものを並べておく価値はあります。遅延が何ミリ秒か（リアルタイム対話でいちばん硬い指標）、モデルの規模、公開ベンチマークのスコア、第三者による再現。どれもありません。今後の展望には「聞く→理解する→応答するまでの end-to-end 遅延を継続的に圧縮していく」とも書かれており、まだ圧縮の余地があると認めているに等しいのですが、現時点のベースラインがいくつなのかは語られていません。

参考までに、前世代の音声のみの Seeduplex は今年4月の公開時、もう少し細かい数字を出していました。誤応答率と誤中断率が半減、話し始めの被りの割合が相対で40%減、発話終了判定の性能が8%向上、大規模 A/B テストでは通話満足度が絶対値で8.34ポイント向上。同じチームによる4か月前の開示のほうが、明らかに粒度が細かいわけです。

ByteDance のこの系譜はどう進んできたか、OpenAI と Google は今どこにいるか

タイムラインに戻すと、今回の位置がはっきりします。ByteDance のこの系譜は4段階を歩んできました。

同時期の他の2社はどこにいるか。OpenAI が7月8日に公開した GPT-Live は全二重ですが、ChatGPT ではまだカメラと画面共有に対応しておらず、公式の説明は「近日中」に対応するというものです。Google の Gemini Live はカメラも画面も以前から見られますが、ターンの判断は先述のとおり内蔵 VAD です。

ByteDance の言う「音声・映像の全二重技術の大規模実用化を業界に先駆けて実現した」という主張は、この2社を1つずつ確認するかぎり成り立ちます。映像を見られる側はターンをまだ VAD に任せており、全二重を最も徹底している側はカメラにつながっていない。この確認には範囲の限界があります。調べたのは OpenAI と Google の公開状況だけで、中国国内の他社は個別に確認していません。

使い方：Doubao アプリを更新して「通話」をタップ

入口はごく短いです。Doubao アプリを最新版に更新し、チャット画面で「通話」をタップ、ビデオ通話画面に入ればそれです。無料、申請不要。現時点で公表されている入口はこれ1つだけで、API や開発者向け提供の情報はありません。参考までに、前世代の Seeduplex は4月9日に Doubao アプリで全公開され、Volcano Engine で API が開放されたのは6月18日でした。

AI に見ながら話させる道は、これまで3つありました。前の2つの欠点は分かりやすく、3つめがいちばん「もう解決済み」と思われがちです。カメラはつながった、しかし「話し終わったか」を判断するのは依然として VAD（音声区間検出。今この瞬間に誰かが声を出しているかだけを見る小さなモジュール）。無音を手がかりに推測するので、早すぎればあなたを遮り、遅すぎれば言い終わってもしばらく反応がありません。

ByteDance の言う「音声・映像の全二重技術の大規模実用化を業界に先駆けて実現」は、この2社を1つずつ確認するかぎり成り立ちます。映像を見られる Gemini Live は発話タイミングをまだ VAD に任せており、聞きながら話すを最も徹底した GPT-Live は ChatGPT でまだカメラにつながっていません。今回の確認は OpenAI と Google の公開状況に限られます。

SeedRealtime は音声、映像、時系列、表現を同じ end-to-end モデルに統合しました（1つのモデルが直接受け取り、直接吐き出す。途中でテキストに変換しない）。外付けの VAD はこれで存在意義を失います。ターン判断は外部ルールから、モデルが刻々と下す内部の決定へ変わり、その決定には映像が見えています。

難所もここにあります。音声には自然なポーズがあり、それを「話し終わった」の信号に使えますが、映像は常時オンで自然な区切りがありません。そして「これどうやるの」と言われたとき、モデルは今の映像、手のしぐさ、視線、数秒前の動作を合わせて、ようやく「これ」がどれかを特定できます。

ByteDance Seed はリリースと同時に1〜3分の実写デモを7本公開しました。3グループに分かれます。

3グループは同じ1つのことの3つの側面です。映像が判断に参加しているからこそ、対象を見つけたら声を出せる、周囲の雑談に引きずられない、「これ」がどれかを解ける、が成り立ちます。

定量的な結論は1つだけです。伝言リレー方式の cascade system と比べ、音声・映像会話のテンポ問題が半減。話し終わる前に遮られる、話し終わってもしばらく反応がない、背景の雑音や周囲の雑談で誤作動する、この3種類の詰まりを指します。