コメントが来ない配信を、AIに自分から喋らせて埋める — 無音75秒ルールと応答速度

無人で動くAIアバターのライブ配信では、コメントが来ないあいだアバターが黙り込むという問題が起きた。コメントに反応するだけの素直な設計では、入力がない時間は何も話さない。そこで最後の発話から75秒何も起きなければ、番組のテーマから話題を一つ作って自分から話す仕組みを入れた。自発的な話題は優先度キューの最下位に置き、コメントが来ればそちらを先に返す。2時間の連続配信で、沈黙の区間で話題が出ること、コメント優先が守られること、話題の枯渇や繰り返しが起きないことを確かめた。 ここがこの記事の本体だと思う。チャットボットは入力があって初めて出力する、Webのリクエストとレスポンスと同じ発想で作られている。だが配信者は、誰も何も言わなくても場に居続けるのが仕事だ。「入力を待つ」を既定にしたままでは、この役割は果たせない。75秒という数字にも理論的な根拠はなく、実際に配信を眺めて決めた値だ。短すぎれば視聴者が書き込む前に話題が変わり、長すぎれば間が持たない。さらに視聴者の画面は15〜30秒遅れている。その往復より短い閾値では会話が成立しない。つまりこの数字は、プラットフォームの遅延という見えない制約から逆算された値なのだ。 応答の遅さも同じ構造だった。コメントへの返事が25〜45秒かかっていたため、まず内訳を測った。支配項は生成でも音声合成でもなく、プラットフォーム側の視聴遅延だった。生成を0秒にしても体感は20秒台に残る。そこで総時間を縮めるのをあきらめ、「なるほど」などの相槌を事前に音声合成しておき、コメントを拾った瞬間に先に鳴らす方式に切り替えた。総時間は1秒も縮んでいない。それでも「無視されている」が「聞いてもらえた」に変わる。この差は設計で作れるものだ。 中小企業の実務に置き換えるなら、店頭の案内、受付、展示、見守りのように場に居続けることが役割のAIを入れるなら、入力がないときの振る舞いを要件に最初から入れるべきだ。そして応答が遅いと感じたら、LLMを速くする前に遅延の内訳を測ること。直すべき場所が自社のシステムの外側にあることは珍しくない。