5. エンタメとしての到達点・不足候補・検証の論点
この章は、実装を読み取った結果からの分析。改善案の実装仕様や、実配信の評価結果ではない。「未確認」は、リポジトリ全体のあらゆる経路に存在しないと証明した意味ではなく、本資料で追跡した応答経路では確認できないという意味で使う。
5.1 現在のシステムを一言で表すと
人格と記憶を持つキャラが、台本・コメント・ゲーム・運営の発話権を調整し、安全に声へ届ける仕組みは厚い。観客に生まれた面白さを測って、次の演出や番組構成を変える仕組みは、同じ密度では確認できない。
したがって、「応答できるか」「キャラらしいか」「番組が成立するか」「見続けたくなるか」を分けて評価する必要がある。機能数が多いことだけで、後の段階まで満たせるわけではない。
5.2 能力別の棚卸し
根拠の詳細は 入力・配送、人格・記憶、番組・参加、演技・運用 を参照。
| 視聴者に届けたい体験 | 現在の土台 | 実装から分かる境界 / 未確認事項 |
|---|---|---|
| 今のコメントにすぐ反応する | 優先キュー、相槌、鮮度検査、TTS先読み | 全文生成待ち。通常60秒期限が生成・待ち時間も消費。実測p95なし |
| 自分の言葉が拾われる | 安定ID、公平性、質問の回答窓 | 3文字未満・@始まり等の入口制約。全員/全課金への配送保証なし |
| 返事から会話が広がる | QuoteRiff / DeepDive、audience_topic、台本寄り道、自由会話 | 長さ上限・期限・残り尺・自発発話OFFで表に出ない可能性 |
| キャラの好みや意志を感じる | 人格、具体的な好み、目標/ためらい/判断軸 | 指示と根拠の注入が中心。長期目標を選び、行動で進展させる共通計画は未確認 |
| 前回の話を覚えている | 会話要約、関係、約束、配信横断記録、シリーズ状態 | PII公開既定OFF、予算、固定語彙、関連度、寿命による制約 |
| 一緒に話の流れを作る | 回答受付、寄り道、投票、参加型拡張 | 各機能の状態が別。通常会話全体で観客の選択→展開→結果回収を統一管理する経路は未確認 |
| ボケ・ツッコミで笑える | QuickQuip / QuoteRiff、台本の小ボケ・あるある・前フリ回収 | 指示テンプレートはある。笑いが成立したかの判定や、不発からの立て直しは未確認 |
| 声と動きが生きている | 感情タグ、ムード、TTS修飾、間、口パク、表情 | provider/モデル差がある。PhysicalActionの通常応答配線は未確認 |
| ゲームを一緒に見ている | 映像観測、最新イベント実況、GameEvent画像/ACK、投票 | 観測の正確さと因果理解は別。汎用の試合/出来事台帳は未確認 |
| キャラ同士の掛け合いが楽しい | コラボ順番制、人格、関係履歴、実発話commit | 役割に応じた応酬・対立解消・オチの共同設計はplannerで未確認 |
| 次も見たくなる | 約束、シリーズ変数、物語の記憶段階、台本の接続 | 次回への期待と実際の回収を、視聴者の理解まで含めて評価する仕組みは未確認 |
| 不調でも安心して見られる | 安全フィルター、重複抑制、取消、無音監視、fallback | 安全な代替文やフィラーが増えると没入感が下がる可能性。頻度・聴感は未測定 |
5.3 コードで確認できる制約と、体験仮説を分ける
A. 入力の豊かさが、生成より前に減る
確認事実: 通常応答の入口には3文字条件、@始まりの除外、固定句の除外がある。回答受付には例外がある。別の正規化イベントを購読する企画は同一条件とは限らない。
体験仮説: ライブらしい短い合いの手を、通常返答の素材として拾いにくい可能性がある。「モデルがノリを理解できない」と決める前に、そもそもモデルへ届いたかを確認する。
B. 会話を広げる機能が、時間・文字数の制約に負ける
確認事実: 目標80/最大120の例ではDeepの上限も約100文字。通常入力は元時刻から60秒。台本寄り道はノード合計2ターン・残り15秒以上等。自由会話は自発発話の実行条件を必要とする。
体験仮説: 毎回「共感→一言→終わり」になった場合、演出生成の弱さだけでなく、最終短縮・候補失効・自発発話OFFが原因になり得る。v2の台本期限変更だけで、自由会話まで同じ改善が得られるとは限らない。
C. 機能が存在しても、現在のキャラでは働かない
確認事実: 視聴者情報のLLM注入は既定OFF。会話品質v2はopt-in。台本参加はノード条件付き。cloud設定適用には対象コンポーネントが必要。音声・アバターの実装差もある。
体験仮説: 「記憶がない」「感情がない」という見え方の一部は、有効化・公開許可・素材不足・配線不足で説明できる可能性がある。新規機能を足す前に、実効設定と実プロンプト投影を照合する。
D. 運用の成功と、エンタメの成功がまだ同じ指標ではない
確認事実: 可聴配送、質問回収、寄り道、エラー、コメント増加、ハイライト、逸脱は観測できる。確認したResponseDirectorはルール・重み・履歴による選択で、視聴者が笑ったかを教師にした学習器ではない。
不足候補: 「この話はウケた」「この人にはこの返しが合った」「説明が長くて反応が落ちた」を、複数の根拠から判定し、次の選択へ使う共通の評価ループ。これは既存ログから自動的に得られる機能ではない。
E. 表現部品は多いが、演出の一体感は別途必要
確認事実: 感情、間、声、表情、字幕、BGM、物理アクション文字列が別々に存在する。字幕は音声完了前に出る。チャンクと非チャンクで動作差がある。物理アクション文字列の通常応答への接続は確認できない。
不足候補: 何を見せて、どこで溜め、いつ言い、どの反応を待つかを一体として評価する仕組み。機械的に演出を増やすだけでは、過剰な間や表情の細かな揺れになる可能性もある。
F. 継続性はあるが、物語としての成長は同義ではない
確認事実: 次回への発言、観客由来の結果、台本変数、キャラ間関係が保存される。約束抽出は固定語彙ベースで、想起にも期間・関連度制限がある。
不足候補: 未回収の期待を把握し、適切な回で回収し、その結果でキャラの判断・行動・関係が変わる共通の管理。保存件数を増やすだけで解決する課題とは限らない。
5.4 次の調査を始める順序
実装の優先度を決定したものではなく、原因を取り違えないための検証順。
| 調査順 | 調べること | まず必要な証拠 | 判断への効き方 |
|---|---|---|---|
| 1 | 今のキャラで何が実効ONか | キャラID、ビルドrevision、取得済み設定、現在モード/ノード、実行コンポーネント | 未実装と無効設定を分ける |
| 2 | 入力がどこで失われ/待たされるか | source ID別の受信→採用→生成→再生/破棄理由 | モデル変更より前の問題を特定 |
| 3 | 記憶・状況・演出が最終生成に残るか | 個人情報を適切に扱ったprompt診断、予算落ち、実モデル/経路 | 「材料がない」と「材料を使えない」を分ける |
| 4 | 視聴者が聞いた/見たものは何か | 実音声・映像、配送本文、provider、字幕時刻 | テキスト評価と配信体験の差を特定 |
| 5 | 既存機能だけでエンタメが成立するか | 下記シナリオを同条件で比較した人手評価 | 不足機能の仕様・優先度を決める |
今回、本番のキャラ設定取得、録画の採取、リハーサル実行は行っていない。上表は今後の検証手順であり、完了した作業ではない。
5.5 代表シナリオと観測項目
| シナリオ | 確認する既存機能 | 成立したとみなす観測 |
|---|---|---|
| 初見が「初見です」、常連が短い合いの手 | 入口、来訪、公平性、呼び方 | 受付/除外理由が分かり、拾った相手に適切な距離感で応じる |
| 同じ人が続けて「それは違う、こっち」 | 安定ID、直前往復、訂正、状況v2 | 対象を取り違えず訂正を取り込む。隣の人の話と混ぜない |
| 深掘りできるコメントが1件来る | DeepDive、audience_topic、自由会話 | 最初の答えに加えて具体例や新しい視点が出る。単なる同義反復ではない |
| AIが質問し、5–20秒後に複数人が答える | 質問完了起点、待ち、回答ID、締切猶予 | 答えを待ち、回収し、採用結果が次の発話に反映される |
| ノード残り10秒/30秒で良いコメントが来る | 期限、寄り道予算、pacing | 採用/見送りが仕様と一致し、途中で話が切れない |
| 待ち行列が混雑しLLMも遅い | 公平性、60秒鮮度、batch、fallback | 受信から初音声までの分布と破棄理由が追跡できる |
| ゲームの勝利直後に次の試合へ進む | 最新観測、scope、GameEvent、時系列v2 | 旧試合の出来事を今起きたこととして話さない |
| 前回「次は紅茶を試す」と言い、翌回来訪 | 約束、想起、PII公開、シリーズ状態 | 実発話だけを根拠に自然に触れ、解決した約束を繰り返さない |
| 悲しい相談の直後に冗談が来る | ムード、傾聴、好み、演出抑制 | 不自然な即時反転や、相談を茶化す演出を避ける |
| コラボで片方がボケ、もう片方へ渡す | turn planner、人物像、関係、配送履歴 | 同意の反復だけでなく役割差が聞こえ、双方の話がつながる |
| 同じ本文を各TTSとアバターで再生 | emotion、pause、表情、口パク、字幕 | 声/間/表情が意図と合い、口や表情が残留しない |
| 冗談が不発、または誰も答えない | 質問待ち、no-answer、話題転換、フィラー | 催促や同じ質問の反復に陥らず、自然に次へ進む |
最低限、通常返答/バッチ/台本/自由会話/ゲーム/カンペ/コラボを分けて記録する。全経路を混ぜた平均では、どの体験が悪いかが隠れる。
5.6 指標の定義案
以下は提案であり、現状で一式自動集計できるという意味ではない。既存の監査・台本metricsを再利用できる部分と、追加の相関・人手評価が必要な部分がある。
| 軸 | 記録するもの | 誤読を避ける条件 |
|---|---|---|
| 即時性 | 投稿/受信→最初の実音声のp50/p95、待ち理由 | 元投稿時刻が無い入力は受信基準を別集計。視聴端末遅延を分ける |
| 到達 | 入力数、採用数、実配送数、部分配送、失効・安全・取消理由 | 受付対象外と配送失敗を混ぜない。batchは人数と発話数を分ける |
| 会話の継続 | 質問→受付→実返答→内容を反映した次発話 | 返答タグやキュー投入だけでは成功扱いしない |
| 記憶の価値 | 必要な記憶の想起率、誤想起、他人との混同 | 記憶注入が許可された設定で評価し、公開範囲を保持する |
| 内容の質 | コメントへの応答性、具体性、新情報、重複、時系列の正確さ | 単に長い文章を高評価にしない |
| エンタメ | 笑い/驚き/共感/期待、自然な掛け合い、見続けたい度 | 正解一つの自動テストにせず、複数人の視聴評価を残す |
| 演技 | 声・間・表情の一致、字幕同期、聞き取りやすさ | provider・声・モデル資産を記録する |
| 長時間の品質 | 不要フィラー、同じ導入、未回収の質問/約束、過剰な常連優遇 | 数ターンだけで結論せず、複数の番組区間で見る |
改善仮説を比較する際は、同じ入力列・キャラ設定・番組状態で条件を固定する。生成の揺れがあるため1回の良い返答だけで成功とせず、通常設定の結果と複数回比較する。狙う配信ジャンルやキャラの芸風が未確定なので、この段階では面白さの合格点や数値目標を決め打ちしない。
5.7 改善仮説：返答前の状況整理と応答方針の判断
2026-09-22の追加検討。ユーザーの意図は、応答前に状況を整理する推論を行い、文脈に合った会話内容を作ること。以下は検証する価値のある改善仮説として記録する。実装変更・設定変更・効果検証はまだ行っていない。
狙いと現行実装との差
現状はSituationSnapshotで状況を集め、人格・記憶・演出指示と一緒にLLMへ渡している。ResponseDirectorによる返答モードの選択や、会話品質v2による時系列の指示もある。ただし、情報が入力に揃っていることと、モデルがその場に合った返しを選ぶことは別である。
改善の狙いは、発話を作る前に「今どんな場面で、このコメントに対してキャラとして何を返すべきか」を判断させること。状況判断は内部で行い、視聴者には自然なキャラの発話を届ける。
| 判断の観点 | 押さえたい内容 | 防ぎたい取り違え |
|---|---|---|
| 今の状況 | 起きた出来事、未実行の予定、誰との話の続きか、現在の質問・ゲーム・台本の状態 | 予定を実体験として話す、別の人や前の試合の話を混ぜる |
| コメントの意図 | 質問、訂正、冗談、共感の要求、合いの手など。曖昧な場合は断定しない | 合いの手に長い説明を返す、訂正を新しい話題として扱う |
| キャラとしての反応 | 人格・価値観・今の感情・相手との関係を踏まえて、どう受け止めるか | 無難な同意だけになる、相談や関係性に合わない茶化しを入れる |
| 今回の狙い | 答える、笑いにする、掘り下げる、観客に振る、話を締める等から場面に合う働きを選ぶ | 毎回同じ構成になる、質問待ちや台本の締めを壊す |
この4点は判断の観点であり、毎回4段階の思考文やJSONを出力させる仕様ではない。ResponseDirectorが決めた長さ・モードや、台本側の話題所有・回答待ちを判断材料に含め、既存の進行制約と整合させる。
期待する返答の例
仮の場面として、ゲームで失敗した直後に視聴者が「また落ちたｗ」と書いたとする。直前の失敗を確認できる状況なら、失敗への共感と軽いからかいを含むコメントとして受け取り、「悔しさを共有し、軽い自分へのツッコミから次の挑戦につなぐ」という応答方針が考えられる。
発話例: 「今の床、私のこと嫌いすぎない？ 次は足元見ていく……たぶん！」
これは説明用の創作例で、実モデルの生成結果ではない。実際の返答はキャラの口調と確認できた出来事に合わせる。落下の観測が無い場合に、この例のような場面や原因を推測だけで確定してはいけない。
最初に試す構成
まずは、既存の会話品質v2で少量の内部推論を使い、判断目的を明確にした1回の生成を検証する。 独立した状況整理LLMを前段に追加する構成は、必要性と追加待ち時間を確認してから検討する。
LLMcontroller.ConversationExperience のコード既定はversion 1・reasoning effort none。ConversationExperiencePolicy はversion 2かつ対応とみなすモデルの場合に none / low / medium を適用する。これは現行コードの条件であり、本番での有効化や実APIの動作確認を意味しない。
検証時は ExportConversationQualityStatus() の requestedEffort と effectiveEffort、実際の生成経路・モデルを確認する。通常返答・台本・補助要約・ゲスト生成等がすべて同じ推論設定になると仮定しない。適用範囲の現状は 2章 を参照。
推論モデルへの指示は、判断材料・制約・成功条件を簡潔に示す。内部推論を長文で説明させることや、段階的な思考文の出力を品質の条件にはしない。この方針は、簡潔な指示と明確な最終目標を推奨する OpenAI公式のReasoning best practices に沿う（2026-09-22確認）。ただし、この資料はVTuber会話での改善効果を証明するものではない。
比較方法と採否の判断
改善要因を分けるため、モデル・入力列・キャラ設定・Snapshot・生成経路・会話品質versionを固定し、次の順に比較する。
| 比較 | 変えるもの | 確かめたいこと |
|---|---|---|
| 判断目的の明確化 | 同じ推論設定で、上記の判断目的を指示に加える前後 | 必要な判断を明示するだけで改善するか |
| 推論量 | 同じ指示・version 2で none と low |
内部推論による追加の品質改善と待ち時間 |
| 追加検証 | 必要な場合だけ、同条件で low と medium |
残った取り違えが減り、追加待ち時間に見合うか |
評価対象は、文脈の取り違え、訂正の反映、返しの具体性、キャラらしさ、冗談や共感の適切さ、会話の継続性。発話開始までのp50/p95、期限切れによる未配送、不要な長文化も合わせて測る。複数回の生成結果と実音声を比較し、良い返答が1回出たことだけで採用を決めない。
推論を増やしても、受付で落ちたコメント、注入されなかった記憶、欠けている映像観測は補えない。推論中に場面が変わる可能性もあるため、既存の配送直前の鮮度・scope検査は引き続き必要となる。診断が必要な場合は採用した応答方針などの短い結果を扱い、内部推論全文の表示・保存を前提にしない。
5.8 自発発言にも状況整理と発話方針の判断を適用する
ユーザーの追加方針として、コメントへの返答だけでなく、自発発言でも発話前に状況を整理して推論する。§5.7と同じ考え方を、AI生成の独り言、自由会話の続き、コメント由来の話題展開、自発ゲームリアクションへ適用する。ここでは設計方針を記録し、実装・設定変更はまだ行っていない。
自発発言で判断すること
自発発言には直接の質問がないため、キャラ自身が「今話す意味」と「次に届けたい内容」を選ぶ必要がある。沈黙時間や話題リストだけを起点に文章を生成する場合より、その場の流れに合い、話が前に進む発言を目指す。
| 判断の観点 | 判断材料と狙い |
|---|---|
| 今、話すべきか | 視聴者の回答待ち、他キャラの発話、コメント待機、ゲームの進行、ASMR、台本の間を踏まえる。話す必要がなければ見送る |
| なぜこの話を始めるか | 直前の実発話、観測した出来事、未回収の話題、キャラの関心・目標から自然な起点を選ぶ。確認できない出来事や視聴者の気持ちを作らない |
| 何を新しく足すか | すでに話した導入・具体例・結論を確認し、具体例、別の視点、軽いボケ、次の行動への意志などを一つ加える |
| どうキャラとして届けるか | 人格と現在の感情に沿って、話し方・長さ・問いかけの有無・締め方を決める。質問を投げる場合は実際に回答を待てる場面か確認する |
例えば、直前に視聴者と「旅行は予定を詰め込む派か」を話した後なら、「旅行って楽しいよね」と再導入するより、余白のある旅という別視点へ進めることが考えられる。
発話例: 「じゃあ逆に、一日一か所しか行けない旅ってどうだろう。寄り道した瞬間、今日の予定が終わるけど！」
これは創作例であり、生成品質の実測ではない。前の話題が実際に配送されていることを根拠にし、別の話へ移った後や回答待ちの最中には無理に差し込まない。
現行の自発発話経路との接続
MonologueController.SituationContext には、実行条件、AutonomyPolicy、SpeechIntentの予約と有効性の再検査がある。これらの実行条件を満たした候補について、モデルが内容と発話の必要性を判断する。モデルの判断で、睡眠・回答待ち・発話競合・台本の許可等を解除する構成にはしない。
想定する処理順は、既存ゲートの確認と予約 → 状況・直近の実発話を使った判断と生成 → 最新状態の再検査 → 実再生 → 配送できた内容の確定。推論中に新着コメントや場面変更があれば、既存の取消・鮮度判定へ従う。発話を見送る判断は正常な結果として扱い、生成失敗や空応答とは区別できる契約を検討する。この見送り結果の契約は追加設計の対象であり、現行実装で完成しているとは扱わない。
LLMcontroller.Monologue の GenerateMonologueScriptAsync は、会話品質v2・ホスト用の生成・ScriptまたはAutonomousのSnapshot等の条件で、会話用モデルを使う分岐をすでに持つ。SendMonologueRequest は対応モデルの場合に推論設定を解決する。したがって、最初の検証はこの既存経路を使い、状況判断と自然な発話の生成を1回の要求で行う構成から始める。
ただし、この生成APIは分類・要約・ゲスト生成等にも共用されている。実際の呼び出し元、Snapshot、選ばれたモデル、実効推論設定を確認して適用範囲を分ける。台本のAI生成発話では、予約された話題ターン・必須内容・残り尺の中で判断する。固定台詞・事前録音・障害時の定型フィラーは、この自発的な内容生成とは区別する。
自発ゲームリアクションは MonologueController.GameReaction の最新観測・短い生成待ち・発話期限にも従う。推論を増やして古い場面の実況になる場合は、内容が良くても改善とは評価しない。
自発発言の検証項目
§5.7と同様、判断目的の追加と推論量の変更を分け、同じ状況・履歴・モデル・経路で比較する。まず少量の推論で、次を確認する。
| 場面 | 確認する結果 |
|---|---|
| コメントへの返答後に余白ができる | 同じ返答の言い換えをせず、具体例や別視点を自然に足せる |
| 視聴者への質問後、まだ回答を待っている | 自分で問いを回収せず待てる。催促や新しい質問を重ねない |
| コメントがしばらく来ない | キャラの関心と現在の文脈から話を始める。無反応だけで視聴者の退屈・不在を断定しない |
| 生成中にコメント到着・台本遷移・ゲーム状況変化 | 旧候補を適切に取消・見送りし、新しい進行を妨げない |
| 同じ話題で自発発言を繰り返す | 導入・例・結論の重複が減り、話題の進展または自然な終了がある |
| すでに番組が進んでいて発言の必要がない | 発話数を増やすために割り込まず、見送れる |
内容の具体性・キャラらしさ・新しさに加えて、不必要な割り込み、重複、質問の回収、発話開始までの時間、期限切れ、正常な見送りと生成失敗を別々に観測する。目標は、その場に合う自発発言が生まれること。発話数の増加だけを成功指標にはしない。
5.9 推論導入と合わせて進める追加計画
最新の実装・自動検証と、実環境評価/限定導入の未完了項目は9章に記録している。
ユーザーの指示により、以下の5点を§5.7・§5.8の計画に加える。共通の会話進行状態、取り違えからの立て直し、場面別の時間予算を基本要件とし、観客の反応による展開と、視聴者全体への伝わりやすさをエンタメ面の改善目標とする。2026-09-22に初期実装と、場面別予算・実際の観客反応の参照を追加した。実装範囲・検証・未達項目は7章と8章に分離し、以下の完了条件と区別する。本番設定の変更と実配信の効果検証は未実施。
1. 応答と自発発言で会話の進行状態を共有する【基本要件】
現在の話題、すでに話した内容、未回収の質問、観客から受け取った回答、次に広げられる方向、話題を締めたかを、応答・自発発言の双方から参照できるようにする。
既存のSituation、自由会話、台本の意味記憶、質問待ちを土台に、各状態の更新元と適用範囲を整理する。新しい状態管理を重ねて別々の正本を作るのではなく、両経路が同じ会話の進捗を読めることを要件にする。
「話した」「質問した」「回収した」は実際の配送を根拠に確定し、生成候補や次の展開案とは分ける。部分配送と全文完了の違いは既存の配送契約に従う。配信・キャラ・台本の切替では、引き継ぐ情報と失効する情報を明確にする。
確認例: コメントへ具体例付きで答えた直後の自発発言が、同じ具体例を再説明せず、その続きや別視点へ進める。質問の回答待ちは発話経路が変わっても維持される。
2. 取り違えたときに認識を修復して会話を続ける【基本要件】
「それじゃない」「さっきと違う」という入力を受けたら、どの相手・発言・出来事についての訂正かを特定し、修正した認識を次の返答と自発発言へ反映する。対象が曖昧な場合は短く確認し、謝罪だけを繰り返して話を止めない。
訂正内容は出典とともに扱い、視聴者の説明、キャラ自身の誤発言、ゲーム等の確定観測を区別する。関連のない人の記憶や、別の出来事まで上書きしない。
確認例: 「右じゃなくて左の話」と訂正されたら、対象を修正して話を続け、その後の独り言でも誤った対象へ戻らない。評価には初回の正答だけでなく、訂正後の回復と誤解の再発も含める。
3. 観客の反応に応じて話の続け方を変える【エンタメ目標】
コメントの量と内容、質問への回答、直前の実発話との関連を見て、掘り下げる、別の意見を取り込む、具体例を足す、話を締めるという展開を選ぶ。§5.8の自発発言にも同じ判断を反映する。
反応を観測する時間には配信遅延を考慮し、無反応だけで退屈や不在を確定しない。笑いを示す短文、困惑、訂正、話題への関心を区別して評価する。入力経路で拾えていない反応については、モデルの推論だけで補えると考えない。
最初は既存の観測を次の展開選択へ使い、その結果を検証する。モデルの再学習やResponseDirectorの重みの自動更新までを初期実装の前提にはしない。
確認例: 同じ導入に対して「詳しく知りたい」が来た場合と、別の意見が来た場合で、続く発話が適切に変わる。無反応の場合も催促や同じ問いの反復に陥らない。
4. コメントした本人と、見ている全員の両方へ届ける【エンタメ目標】
本人への返答を成立させた上で、必要な場合は初見・途中参加者にも分かる短い補足を入れる。常連との共有文脈や個別の話題を、ほかの視聴者も理解できる話へ自然に広げる。
毎回答で説明を付け直すことは避け、最近の配信内で説明済みかを共通の会話状態から判断する。過去の個人情報を説明のために余分に公開しないよう、既存の公開許可と予算に従う。
確認例: 常連との前回の続きでも、短い文脈補足で初見が話に入れる。元コメントへの答えが一般論に置き換わらず、本人にも返答が届いたと分かる。
5. 場面ごとの推論量と待ち時間の上限を決める【基本要件】
挨拶・相槌など即時性が大切な場面は素早く、訂正・複雑な文脈・話題展開の判断が必要な場面では推論に時間を使う方針とする。具体的な推論量と時間上限は§5.7の比較で決め、全場面で同じ強度を使うことを前提にしない。場面ごとに推論量を選ぶ処理は追加設計の対象であり、現行の設定値が存在することだけで実装済みとは扱わない。
時間予算はLLM単体だけでなく、入力の経過時間、待ち行列、台本の残り尺、TTSの合成待ちも含めて考える。期限を超えた場合の取消・見送り・既存fallbackへの移行条件を、発話用途ごとに決める。考え続けている間に、古い出来事への返答になることを避ける。
最初は状況判断と発話生成を既存の1回の要求にまとめる。追加のLLM要求には往復の遅延が発生するため、分割が必要な場合は品質改善と追加待ち時間を測って判断する。OpenAI公式の遅延最適化（2026-09-22確認）。
確認例: 単純な挨拶を不要に待たせず、訂正では認識を修復できる。混雑時も期限切れ・取消・正常な見送りが区別でき、古い発話を配送しない。
進め方と完了条件
まず1・2・5を、応答と自発発言に推論を導入する際の基本要件として具体化する。その土台の上で3・4を改善し、同じ入力列と状況を使った比較に、話題の進展・観客全体への伝わりやすさの評価を加える。
| 段階 | 確認すること |
|---|---|
| 基本要件の検証 | 応答と自発発言の間で内容・質問状態が一貫する、訂正が以後にも反映される、場面別の時間予算内で配送または適切に見送れる |
| エンタメ面の検証 | 観客の反応で話が変わる、本人への返答と全体への分かりやすさが両立する、重複や過剰な説明が増えない |
| 総合比較 | 最終的な実音声・映像で、文脈の正確さ、キャラらしさ、会話の継続性、待ち時間を確認する |
これらは計画上の完了条件であり、現在達成済みという記述ではない。内部推論の長さや発話数ではなく、視聴者に届いた会話を評価する。