コメントが来ない配信を、AIに自分から喋らせて埋める

無人で動く AI アバターのライブ配信を作ると、真っ先にぶつかるのは「間」の問題です。誰も見ていないわけではない。むしろ視聴者はいる。それなのにアバターが黙り込んだり、コメントを書いても何十秒も無反応だったりする。人間の配信者なら無意識にやっている「場をもたせる」振る舞いが、AI にはごっそり抜けているのです。

この記事では、無人配信を退屈させないために取り組んだ2つの課題を、ひとつの流れとしてまとめます。ひとつは コメントが来ないときの沈黙をどう埋めるか。もうひとつは コメントが来たときの応答遅延をどう扱うか。前者は「入力がないときの振る舞い」、後者は「入力があってから反応までの時間」で、配信という同じ場の裏表の問題です。どちらも、素直な実装のままでは配信として成立しませんでした。

共通していたのは、力任せに「速くする」「賢くする」で解こうとすると外す、ということです。実際に長時間回して観察し、内訳を測り、優先度を設計し直す。地味な作業の積み重ねでした。

リアクティブなだけでは配信にならない

最初の実装は素直に「コメントが来たら応答する」でした。動作としては正しく、テストでも問題なく動きます。

問題は コメントが来ないとき でした。

無人の配信で、アバターが画面に映ったまま、何十秒も黙っている。瞬きはしている。でも何も起きない。配信としては事故に近い状態 です。しかも、始めたばかりのチャンネルではこれが通常状態になります。コメントが付くのは配信が育ってからで、それまでは無音がデフォルトなのです。

ここは設計思想の話でした。チャットボットとして作ると、AI は 入力があって初めて出力する 存在になります。Web のリクエスト/レスポンスと同じモデルです。

配信者は違います。誰も何も言わなくても、しゃべり続けるのが仕事 です。

なので、入力の有無と関係なく発話を作る仕組みが要ります。入れたのはこういうものです。

最後の発話が終わってから 75 秒、何も起きなかったら
  → 番組のテーマから、話題を1つ作って話す

無音の閾値をどう決めたか

75 秒という数字に強い根拠はありません。実際に配信を眺めながら決めました。判断の材料はこうです。

短すぎる（30 秒以下）: コメントを書いている人が投稿する前に、アバターが次の話題に移ってしまう。視聴者のコメントが「前の話題への返事」になって噛み合わなくなる
長すぎる（2 分以上）: 単純に間が持たない。視聴者が離脱する

もう一つ効いたのが、視聴遅延の存在 です。視聴者の画面は 15〜30 秒遅れているので、視聴者が「今の発言」に反応してコメントを書き、それが届くまでには相応の時間がかかります。閾値がこの往復より短いと、会話が成立しません。

この視聴遅延は、あとで応答速度の話でも支配項として再登場します。無音対策と応答速度は別々の機能に見えて、同じ「配信プラットフォームの遅延」という制約の上で設計しているのです。

無音の閾値は設定値にして、番組の性格で変えられるようにしています。

自発的な話題は優先度キューの最下位に置く

実装上は、発話を優先度付きのキューで管理していて、自発的な話題は いちばん低い優先度 に入れています。

優先度	種類
最優先	番組終了時の締めの挨拶
高	投げ銭・サブスクなどのイベント
中	視聴者コメントへの応答
低	沈黙を埋める自発的な話題

こうしておくと、自発的な話題を生成している最中にコメントが来た場合、コメントへの応答が先に立ちます。視聴者を待たせてまで独り言を優先する のは、配信として明らかに間違いなので。

「間を埋めるもの」は、常に他の何かに割り込まれてよい、という位置づけです。

何を話させるか

話題は番組ごとに設定した テーマ から作らせています。番組を登録するときに、キャラクター（人格）とテーマ（何について話す配信か）を指定する設計にしていたので、その情報をそのまま使えました。

ここで気をつけたのは、同じ話題を繰り返させない ことです。会話履歴を参照して生成しているので、直近で話したことは避けられます。長時間の配信では、履歴の保持量がそのまま「話題が一周する周期」になります。

検証は2時間回す

この手の機能は、短いテストでは検証になりません。無音が続く状況を人工的に作っても、実際の配信での挙動とは違うからです。

2 時間の連続配信で確認しました。

沈黙が続いた区間で、想定どおり自発的な話題が出る
コメントが来たときは、そちらが優先される
話題が枯渇したり、同じ話を繰り返したりしない
メモリの増加なし、53 ターンすべて計測

長時間回して初めて分かることが多い 機能でした。特に「話題が一周してしまう」問題は、10 分のテストでは絶対に出ません。

コメントへの返事が45秒かかっていた

沈黙を埋められるようになると、次に気になり始めるのは逆側、つまり コメントが来たときの反応の遅さ です。作った直後の体感がこうでした。

コメントを書く → 25〜45 秒後 にアバターが答える

対話としては明らかに遅い。ここで「LLM の生成を速くしよう」「TTS を軽くしよう」と手を動かしたくなりますが、その前に 内訳を測りました。結果、方針が変わりました。

区間	時間	こちらで削れるか
コメント投稿 → チャット取得	最大 5 秒（ポーリング間隔）	削れる（が下げすぎると API 制限）
発話キューの待ち	状況次第	一部削れる
応答の生成（LLM）	数秒	削れる
音声合成（TTS）	数秒	削れる
送出 → 視聴者の画面に届くまで	15〜30 秒	ほぼ削れない

支配項は最後の行でした。 視聴者がコメントの返事を「聞く」のは、こちらが音声を送出してから 15〜30 秒後です。これはプラットフォーム側の配信遅延で、こちらの実装とは無関係です。無音対策のときに閾値を決める材料になった、あの視聴遅延と同じものです。

つまり、仮に生成を 0 秒にしても、体感は 20 秒台にしかなりません。

削れるところは削った

とはいえ、削れるところは削りました。

1. 低遅延モードを有効にする

配信枠を作るときに低遅延の設定を指定すると、視聴遅延そのものが縮みます。唯一、支配項に効く手段 なので必ず入れます。

2. ポーリング間隔

チャットの取得はポーリングなので、間隔がそのまま遅延に乗ります。短くすれば縮みますが、API のクォータとのトレードオフです。5 秒に置いています。

3. 応答を短くする

これは生成時間だけでなく、発話時間 に効きます。長い返答は、しゃべり終わるまで次のコメントに移れないので、後続のコメントの待ち時間が伸びます。

応答の指示に「2〜3 文で返す」を入れました。配信の対話としても、長広舌より短いやりとりのほうが自然です。制約が品質を上げた タイプの変更でした。

「速くする」から「待たせ方を変える」へ

削れる部分を削っても、20 秒台は残ります。ここで方針を変えました。

総時間を縮められないなら、無反応の時間を縮める。

人間の配信者を考えると、コメントを読んでから答えるまでの間、無言ではありません。「あー、なるほどね」「いい質問ですね」と、考えている最中も声が出ています。

そこで、相槌を先に返す 実装を入れました。

コメントを検知
  → 相槌を即座に発話（「なるほど」「いい質問ですね」など）
      ※ あらかじめ音声合成しておいたものを使うので生成待ちゼロ
  → その裏で本命の応答を生成
  → できたらそのまま続けて話す

相槌は決まったフレーズなので、音声を事前に合成してキャッシュ しておけます。生成の待ち時間がゼロになるので、コメントを拾った瞬間に音が出せます。

視聴者から見える体験はこう変わりました。

	変更前	変更後
コメント → 最初の反応	25〜45 秒（無反応）	すぐ（相槌）
コメント → 本題の応答	25〜45 秒	25〜45 秒（変わらず）

総時間は 1 秒も縮んでいません。 それでも体感はまったく違います。「無視されている」が「聞いてもらえた、考えてくれている」に変わるからです。

無音対策で入れた「間を埋める発話」と、この相槌は、実は同じ発想の変奏です。どちらも、待ち時間そのものを消せないなら、その時間を無音のまま放置しない、という考え方に立っています。

一般化: 「入力がないときの振る舞い」と「無反応の時間」を設計項目にする

この2つの取り組みから得た視点は、配信に限らないと思っています。

ひとつは 入力がないときに何をするか。対話型の AI を作るとき、これを設計している例は多くありません。ほとんどのシステムは「入力を待つ」が既定です。それが正しい場面も多い（チャットボットが勝手に話しかけてきたら怖い）のですが、放送・展示・受付・見守りのように、場に居続けることが役割 の場合は、待つだけでは要件を満たしません。「無音が N 秒続いたら」という条件は、その最も単純な実装です。

もうひとつは レイテンシは総時間だけの問題ではない ということ。ユーザーが体験しているのは総時間ではなく、「反応がない時間」 です。この 2 つは別物で、後者だけを縮める手が存在します。ローディング表示や楽観的更新が効くのと同じ理屈が、音声対話でも成立しました。

そして両方に共通する教訓として、最適化の前に内訳を測る、自分の系の外側に支配項があることがある の2点があります。今回は削減対象だと思い込んでいた LLM や TTS ではなく、半分以上がプラットフォームの視聴遅延でした。内訳を測らずに着手していたら、生成の高速化に時間を溶かして、体感はほとんど変わらなかったはずです。

まとめ

無音対策（入力がないとき）:

コメント駆動だけの AI 配信者は、コメントが無いと沈黙する。無人配信では事故に近い
無音が一定時間続いたら、番組テーマから自分で話題を出す
閾値は、視聴遅延を含む会話の往復時間より長く 取る（今回は 75 秒）
自発的な話題は 優先度キューの最下位 に置き、コメントに割り込まれてよいものとして扱う
検証は 長時間 回す。話題の重複は短いテストでは出ない

応答速度（入力があったとき）:

応答遅延 25〜45 秒の 内訳を測ったら、15〜30 秒がプラットフォームの視聴遅延 だった
削れるところ（ポーリング間隔・生成時間・応答の長さ）は削る。低遅延設定は支配項に効く唯一の手
それでも残る遅延は、「速くする」ではなく「無反応の時間を縮める」 で対処する
事前合成した相槌を即座に返す。 総時間は変わらないが体感は別物になる

黙っている AI は、壊れている AI と見分けがつきません。場に居続けることが役割なら、沈黙は仕様の穴です。そして「これ以上速くできない」と分かってからが、UX 設計の始まりでした。無人配信を退屈させないというのは、結局のところ、待ち時間を消すのではなく、待ち時間の埋め方を設計する ことでした。