3. 台本・雑談・参加・ゲーム・コラボ

3.1 発話の所有者は一つではない

活動	進行の所有者	発話の起点	コメントとの関係
コメントへの返答	ChatGPTController	採用された入力	他の音声、台本ゲート、期限を待つ
台本の進行	ScriptRunner + MonologueController	ノード/話題ターン/固定台詞	応答窓と残り尺で割り込める範囲が決まる
自由会話	MonologueController + FreeTalkConversationState	無言、話題リスト、コメント由来の続き	新着コメントと質問受付を優先
自発ゲーム実況	MonologueController.GameReaction	freshな解析結果	最新イベントだけを保持し、発話権を予約
認証済みゲームイベント	CommentStock + ChatGPTController	拡張のイベント	専用優先レーン。前章参照
コラボ掛け合い	CollabDialogueOrchestrator	手動/コメント/ホスト返答/言及/無言	台本を止めて再開する方針を持つ
運営カンペ	OperatorCue経路	運営の指示	通常会話や台本の旧生成を中断・失効できる

「自律性があるか」を一つのboolで判断できない。生成内容の自由さ、発話を始める権利、番組構成を変える権利が分かれている。

3.2 台本は読み上げリスト以上のもの

ScriptNode / ScriptRunner に、以下の要素がある。

Core / Extension / Loop / Branch / Eventのノード種別。
topics、追加promptGuidance、opening/transition phrases、必須台詞。
scriptedLines と scriptOnlyMode によるLLMを使わない固定台詞。
目安尺、ループ間隔、時間・コメント数・手動・pacing・沈黙による遷移。
コメント受付のLegacy / Disabled / WholeNode / Tail、ノード内の返答数上限。
コメント率や残り時間等の条件分岐、ギフト/キーワード/外部イベント。
複数キャラの話者指定、コラボ、UIスロット表示、ASMR等のノード演出。
名前をまだ思い出せない→断片→確定名のような物語状態。
savepoint、停止/再開、ノード実行世代、発話の予約と確定。

PacingController は残り時間と必須ノードの見積もりから、余裕/通常/遅れ/危機を判断する。EndingController と合わせ、予定尺を守るための進行制御がある。

現在の強み: 配信が無限に脱線することや、コメント返答の途中で自動遷移して枠を消費することを避けるための実行管理が厚い。

機能の境界: 残り尺の判断と、観客の期待を作ってオチを回収する編集判断は同一ではない。前者の実装があることから、後者が自動的に保証されるとは言えない。

3.3 台本の話題展開

台本version 1.1以上では ScriptTopicTurnPlanner の決定的なターン計画を使う。topicsを具体的な話題単位として、予定尺と毎分2ターンの基準等から展開を組む。

切り口はフック、観察、場面、具体例、仕組み、比較、反対意見、トレードオフ、視点変更、実践、振り返り、小ボケ、あるある、視聴者に振る、前フリ回収、大げさ実況、転換。長いノードでは時間軸・条件変更・立場などのlensを追加する。

「小ボケ」「前フリ回収」はすでに存在する。機能追加を検討するときに未実装扱いしてはいけない。ただし、現在のCallbackは「先に出した言い回しや例を1つ回収する」というプロンプト指示であり、すべての伏線を構造化して成功を判定する仕組みを意味しない。

Reserve と Commit/Skip を分離するため、生成だけで消費済みにしない。ScriptUtteranceContinuity は直近発話、必須台詞カバー、重複、発話間隔等を扱う。意味記憶も加わるが、語の類似・消費キー・LLM要約はそれぞれ異なる近似である。

3.4 視聴者に質問し、実際に待つ

拡張された台本参加機能の有効条件は AudienceInteractionEnabled に明示される。

台本が実行中
AND node.audienceInteraction.enabled == true
AND commentWindowMode == WholeNode
AND scriptOnlyMode == false

さらにコメント由来の寄り道にはv1.1以上の決定的ターン計画と allowAudienceDetours が必要。関連設定がJSONに存在するだけでは有効とは限らない。

質問の状態は ScriptCommentWait と PendingQuestionTracker が管理する。

stateDiagram-v2
    [*] --> 質問の生成と配送
    質問の生成と配送 --> 回答受付: 質問の実再生が完了
    質問の生成と配送 --> 通常進行: 失敗・取消・配送期限切れ
    回答受付 --> 回答の処理: 安全な入力をmessage IDで受付
    回答の処理 --> 回答受付: 返答完了・受付時間は残す
    回答受付 --> 受付済み回答の開始猶予: 締切後も未開始回答あり
    受付済み回答の開始猶予 --> 通常進行: 猶予終了
    回答受付 --> 通常進行: 締切・未開始回答なし

回答待ちは質問の生成開始ではなく、可聴完了から開始。
台本の実効待ち時間は設定とYouTube側の最低回答窓を考慮し、5–60秒に制限。
配送段階自体のタイムアウトは120秒。締切後の受付済み回答の開始猶予は10秒。
最大32件の回答IDを追跡。最初の1人への返答で、まだ入力している人の受付時間を消さない。
一時停止は期限をずらす。ノード/配信scopeの変更では古い質問を閉じる。
回答は受信・採用・処理開始・実配送を分けて数える。

質問の末尾や手掛かりを検出するため、LLMが意図どおりの問いを出さなかった場合まで回答窓が必ず開くわけではない。質問が生成されたかより、最終的に聞こえた文と待ち状態の両方を見る必要がある。

3.5 コメントから台本を寄り道する

LLMcontroller.AudienceTopic は通常返答と同じ生成に、任意の補助JSONを付けさせる。

<audience_topic>{"pickedPhrase":"入力内の言葉", "expansionDirection":"広げる方向"}</audience_topic>

pickedPhraseは2–40文字で元の生コメント内に実在すること、directionは1–120文字などを検証する。タグ破損時も補助情報を音声へ漏らさない。挨拶・相槌・個人情報・敏感な相談では候補を無理に作らないよう指示する。

通常返答が実際に完了してから CommitAudienceTopicAfterReply が候補を台本/自由会話へ渡す。候補を生成できたことと、後続発話が始まることは別である。

AudienceDetourState と ScriptRunner.AudienceInteraction の境界は以下。

条件	現在値/挙動
候補キュー	最大3件、既知source最大32
追加発話	ノード内で合計最大2ターン。コメント1件ごとに2回ではない
予約可能な残り尺	15秒以上
旧方式の開始期限	元コメント時刻+60秒
会話品質v2の開始期限	元返答の可聴完了+15秒。元コメントの通常配送期限は変更しない
採用後の有効期間	寄り道開始から90秒
切り口	初回ConcreteExample、次回Reflection
取消	モデレーション、scope変更、終了処理等
状態報告	offered / reserved / expired / discarded / delivered等

この機能は「コメントによって話の内容が変わる」土台になっている。一方、候補は常に採用されず、残り尺・期限・コメント待ち・モード変更が一つでも合わなければ表に出ない。

3.6 自由会話は別の状態機械

LLMcontroller.FreeTalk の自由会話は、配信中・切替外・終了フェーズ外・台本なし・ASMR外・ゲームモード外・展示モード外・コラボ不在などが条件。

FreeTalkConversationState は次を実装する。

質問後に最低20秒待ち、配信側の条件で最大60秒まで確保する。回答開始の猶予は10秒。
次の問いかけを急がず、90秒の抑制方針をプロンプトへ出す。
返事がない場合も催促や同じ質問の言い換えをせず、具体例や別視点で続ける。
コメント由来の話題は返答後に登録され、4秒の間を置く。最大2追加ターン、90秒の候補寿命/次の受付間隔、各stepの試行制限を持つ。
話題履歴と実際に話した文を渡し、同じ導入・具体例・結論の繰り返しを抑える。

v2との非対称: 現在の自由会話候補の投入では、まだ元コメントの年齢が60秒未満かを確認する。台本の「可聴返答後15秒」の変更が自由会話にも同じ形で入った、と読んではいけない。

自由会話状態が候補を持っていても、実際に発話するにはMonologueControllerの有効化と実行条件が必要。返答本文に1文補足する encourageConversationFollowups（既定false）とも別機能である。

3.7 自発発話と意図した沈黙

MonologueController は事前WAV、AI生成一人語り、短い自発発言を持つ。コード既定では enableMonologue=false、enableSpontaneousUtterance=false。一人語り間隔300秒、初回30秒、自発の範囲120–300秒、長い無言の閾値120秒。実効値は保存設定/クラウド適用で変わる。

MonologueController.SituationContext は AutonomyPolicyEngine とSpeechIntentの予約を使う。

配信状態不明/終了中/不健康/発話中/コメント処理中/運営指示待ち/回答待ち/ゲスト発話中等では拒否。
台本中は allowSituationAutonomy 等に従う。
無言時間に加え、ギフトの集中、映像の注目イベント、台本の境界などをトリガーにできる。
発話候補にscope・期限・最大長を付け、新着コメントや世代変更で取消。
ポリシーの最小無言時間は既定30秒だが、既存のタイマーを短縮するものではない。複数条件の大きい側が実効条件になる。

「沈黙を避ける」と「視聴者の答えを待つ」「ASMRの間を守る」は異なる目的。無音秒数だけを短くすると後者を壊す可能性がある。

3.8 ゲーム実況・視覚理解

MonologueController.GameReaction は解析されたCurrentScene / CurrentAction / TensionLevel / NotableEvents / CommentarySuggestionから短い実況を作る。

GameReactionState の鮮度は20秒。最新1件を保持し、古いイベントを順番に喋らない。出来事の正規化キーで重複を抑え、実配送まで消費しない。候補のrevision・画像/解析元・発話権を再確認する。

通常のゲームリアクションは1–2文、上限は maxAIUtteranceLength と60文字の小さい方。生成待ちは10秒を目安に打ち切る経路がある。ゲーム観測から発話する機能であって、すべてのゲームの勝敗・因果・作戦を構造化した状態として理解している保証ではない。

ゲーム実況、一般コメントに付与する画面文脈、認証済みGameEventの固定画像付き応答は別経路。鮮度20秒とGameEventキューの15秒も同じ閾値ではない。

3.9 コラボは制限付きの順番制会話

CollabDialogueModels に手動、視聴者コメント、ホスト返答後、ゲスト言及、無言後などの開始モードがある。台本との関係はDisabled / ScriptOnly / BetweenNodes / CommentInterrupt / FreeTalkSegment。

CollabTurnPlanner は既定2ターン、1–5ターンに制限し、最初の指定話者/ゲストを選び、その後は直前以外で最も長く喋っていない候補を選ぶ。

CollabCharacterResponseGenerator は話者別の人物像・口調・語尾・NGを使い、ホストの人格をそのままゲストへ流用しない。生成失敗時の短いフォールバックも設定として存在する。

CollabDialogueOrchestrator はキュー投入成功ではなく、MultiCharacterの再生結果を待って会話履歴を確定する。台本を停止/再開する制御もある。

エンタメ上の境界: 掛け合いは実装済み。ただし今回確認したplannerは、ボケ役/ツッコミ役の役割計画、話題ごとの緊張関係、観客の反応によるコンビ芸の最適化を行う選択器ではない。主として話者の順番とターン上限を管理する。

別に CharacterRelationshipStore と MultiCharacterPromptInjector があり、キャラ間の好感度・交流履歴をプロンプトへ渡せる。「キャラ同士の関係が一切ない」とも言えない。この関係表現と、上記plannerの話者選択は別の責務である。

3.10 既存の分析・ハイライト

ScriptInteractionMetrics は質問数、受付/開始/配送数、未開始、猶予開始、寄り道ターン、重複抑止、要約の要求/成功/失敗を記録する。質問から最初の処理開始/配送完了までの時間もある。

BroadcastInsightsAnalyzer は過去の台本レポートから尺やコメント応答数等を集計する。EngagementClipDetector はコメント急増、課金、感情高揚をハイライト候補にする。

これは「観測が何もない」状態ではない。ただしコメント数や感情強度は面白さそのものではなく、炎上・困惑・定型感謝でも増え得る。確認した範囲では、これらの評価でResponseDirectorの重みやネタ構造を継続学習する閉ループまでは確認できない。

3.11 参加型企画・配信横断・BGMという周辺の土台

通常コメント処理だけを見て「参加型企画がない」と結論してはいけない。以下も応答体験に関係する。

機能	確認した実装	通常応答との違い
配信拡張	ExtensionHost	テナントで有効化された拡張を読み、capabilityと実接続を確認する
モザイク外し	MosaicRevealExtension	コメント採点、隠し正解、課金、確率・cooldownで開示し、speech.injectでリアクション
ゲーム投票	TaeruCraneGameExtension、YouTubeLiveController、Pollモデル	ゲーム連動の公式投票を要求・終了・検証する。通常雑談の質問待ちとは別
シリーズの継続	SeriesStateManager	台本変数、エピソード、セーブポイントをローカル/クラウドで継承
BGM	NativeBgmController	配置preset連動、TTS中の音量低下、ASMR中のmute。Native配信設定に依存

これらは企画や音楽の素材・実行基盤として存在する。現在の通常応答が観客の反応から企画を選び、導入→参加→結果→次の期待まで自動編成する共通機構がある、という根拠にはならない。また、拡張のコメント購読とChatGPTControllerの入口は別なので、通常返答で落ちる短文が、すべての企画でも無視されるとは限らない。