6. 調査根拠・テスト・再確認方法
6.1 調査の単位
関係するクラス名を列挙するだけでなく、入力の受付、キューの選択、生成要求、最終安全境界、音声再生、実配送後の状態確定まで呼び出しを追跡した。その上で、台本・自由会話・カンペ・ゲーム・コラボの分岐と、Admin/Functions/Unity間の設定適用を比較した。
コードのコメントや既存設計書だけを実装完了の根拠にしていない。たとえば、スパチャの「金額順」というコメントよりFIFOの実装を優先し、アバターinterfaceの古いPhase説明より現在のVRM/PSD実装を優先した。時系列改善計画は実装済み範囲と分けた。
証拠の強さ
| 表現 | この資料での意味 |
|---|---|
| 実装を確認 | 実行コード・呼び出し元・適用条件を静的に確認した |
| コード既定 | 宣言時の値やfallback値。Unityシーン/クラウドの実効値は別 |
| 配線を確認できない | 指定したコード範囲の呼び出し探索では確認できない。外部/シリアライズ配線の不存在証明ではない |
| 未確認 | 実装の一部、稼働状態、または体験品質を確認していない |
| 体験仮説 / 不足候補 | 実装上の制約から考えられる影響。実際の視聴結果による検証が必要 |
6.2 主要な追跡開始点
行番号は調査時点の作業ツリーに対する値。後の変更でずれる場合はシンボル名で検索する。source_manifest.json のSHA-256で同じファイル内容か確認できる。
| 調べたいこと | ファイル / シンボル | 調査時行 |
|---|---|---|
| 通常コメントの受付条件 | ChatGPTController HandleNewComment（trace付き） |
3391 |
| 採用・台本・ASMRの発話ゲート | 同上 ProcessNextComment |
3059 |
| 1件の生成から配送まで | 同上 ProcessCommentInternal |
805 |
| 次に拾う入力 | Commentstock DequeueNextSingleLocked |
1335 |
| 用途別優先値 | 同上 GetWorkPriority |
2160 |
| LLMの経路・retry分岐 | LLMController GenerateResponseInternal |
545 |
| 通常プロンプト | MainPrompt BuildPrompt |
16 |
| 人格の入口 | PromptSettings GetMindPrompt |
9 |
| 全体の文字予算 | Utilities GetMaxPromptCharsBudget |
119 |
| 演出の選択 | ResponseDirector DirectResponseWithTopicOwnership |
173 |
| 会話v2の失効条件 | ConversationExperiencePolicy CriticalFactKeys |
18 |
| 実発話の共通反映 | PromptContext NotifyCharacterSpoke |
198 |
| キャラの体験の投影 | CharacterExperience BuildCharacterExperiencePrompt |
108 |
| キャラの体験の確定 | 同上 CommitCharacterExperience |
214 |
| 台本寄り道の予約 | ScriptRunner.AudienceInteraction TryReserveAudienceDetour |
138 |
| 自由会話の有効条件 | FreeTalk IsFreeTalkConversationActive |
15 |
| 配送結果の契約 | TTSController SpeechPlaybackResult |
276 |
| 単発TTSの境界 | 同上 SpeakTextInternal |
963 |
| 話者の口パク制御 | 同上 BeginAvatarSpeakingRoute |
1437 |
| チャンクTTSの境界 | Chunking SpeakTextChunkedInternal |
74 |
| チャンク再生と先読み | 同上 PlayChunksSequentially |
694 |
| cloud設定→実行クラス | CharacterConfigSyncManager ApplyCloudConfigToLocal |
500 |
| 会話v2設定のAPI検証 | characterConfigFields validateConversationQualityConfig |
116 |
各章には、この表以外の記憶・台本・演技・安全・拡張・分析の実装へのリンクも記載している。
6.3 既存テストから読み取れる契約
下表はテストコードの確認であり、今回の作業でテストを実行して合格したという報告ではない。 また、ソース文字列の配線チェックは、実LLM・実音声・映像を通したend-to-endテストではない。
| テスト | 主に守る契約 | テストの性質・限界 |
|---|---|---|
| LiveChatFreshnessTest | 投稿/受信時刻、未来時刻補正、enqueue/dequeueの失効、課金の保持 | parser・状態・Unityコンポーネントの検証。実ネットワーク遅延とは別 |
| ChatResponseDeliveryContractTest | 最終検証→副作用/UI→TTS→配送後記憶の配線 | 主にソース文字列と処理順序の検査 |
| ScriptCommentWaitTest | 可聴完了からの待ち、猶予、古い配送、pause | 状態機械の時刻を指定した検証 |
| AudienceDetourStateTest | v2の配送後期限、2ターン、残り尺、scope、候補重複 | 純粋な状態遷移。未コミット変更を含む |
| CharacterExperienceTest | 安定ID、期限、接し方、約束想起、消去 | 状態/投影の例示検証。任意の自然言語の理解を保証しない |
| ConversationExperiencePolicyTest | reasoningの条件、重要Fact変更、配送sequence、時系列投影 | 新規未追跡ファイルを含む作業ツリー上のテスト |
| ViewerPiiPromptPolicyTest | 既定OFF、各予算、request scope、キャラ切替時reset | 純粋関数と配線契約の混在 |
| OperatorCueDirectTtsBoundaryTest | trim以外の改変拒否、辞書置換拒否、字幕の開始時刻 | コンポーネント検証とソース配線検証の混在 |
| TtsAvatarLipSyncRoutingTest | 単発/チャンクの同じ口パク経路、最後のleaseで閉口 | proxyによる呼び出し観測と配線検証。実モデルの映像品質とは別 |
その他、SpeechPlaybackLedger、SpeechDeliveryReceipt、SpeechAuditTrail、GameReaction、SelfReflection、FreeTalk、台本意味記憶などの関連テストも存在する。全テストスイートの最新実行状況・CI結果はこの資料の対象外。
6.4 再現性と作業ツリーの扱い
調査基準は main のHEAD 385ba573f5497d4abb26e4a018a69316a3bd01df と、その上の未コミット変更。とくに会話品質v2、台本寄り道期限、LLM経路、AivisCloud等の変更が含まれるため、HEADだけをcheckoutしてもこの資料と完全には一致しない。
source_manifest.json は、本文で明示的に参照した実装・テスト・設計資料について、repo相対path、byte数、行数、SHA-256、採取時のGit状態を記録する。ソースの複製や秘密情報の抽出は行わない。この一覧は参照先の同一性を確認する補助であり、リポジトリ全体を網羅したファイル一覧ではない。
本資料の作成では既存の実装変更を修正・commit・deployしていない。稼働中Playerのビルドがこの作業ツリーと同じかも未確認。
6.5 調査範囲と残る確認
| 範囲 | 今回の確認 |
|---|---|
| Unityの通常コメント応答、台本、自発発話 | 入力から配送後commitまでを重点的に静的解析 |
| 人格、記憶、状況、演出、会話v2 | 状態、投影、既定値、経路差を追跡 |
| TTS、表情、口パク、安全・復旧 | 応答に接続する境界とprovider差を解析 |
| Admin/Functions | 応答に関連する設定フォーム、検証、同期への接続を確認 |
| 参加型拡張、投票、BGM、シリーズ | 応答との接点と機能の存在を確認。各サブシステムの全面監査ではない |
| 現在の本番キャラの設定 | 未取得。キャラ別の実効値は断定しない |
| シーン/Prefabの実配置と起動順 | コードの解決方法を確認。実Playerの全配線は未検証 |
| 実providerとの互換性・速度 | 未実行。コード中のモデル名を現在の外部仕様の証明にしない |
| 視聴者が見る映像・聞く音声 | 未収録・未視聴 |
| 面白さ、離脱、再訪、関係形成 | 実測・人手評価なし。5章は今後の検証案 |
追加調査では、まず利用中キャラと配信モードの実効設定をこの仕様に重ねる。コードを再読する前に、どの経路が実際に使われたかを絞ると、機能不足と設定・接続・生成品質の問題を分けやすい。