FACTUAL ACTIVITY RECORD · 実際の作業をもとにした活動記録
AIタレントの表示identityを定義へ一元化する
再起動で変わる実行名をstableなagent keyへ結び、正式プロフィールを一つの経路から表示する
目的
同じAIタレントを再び起動すると、実行時のnicknameに連番が付き、同一人物なのに表示名や紹介が変わることがあった。会話の集約には定義を使っていても、画面側の既知プロフィール判定がhardcoded nameとの一致に依存していた。
実行履歴のnicknameは証跡として保持しつつ、画面に出す正式名、役割、紹介文をstableなagent keyとdatabaseの定義へ揃え、複数の実行を一人のAIタレントとして表示することを目指した。
実装
AI talent identity manifestに、Makoを含む10名の正式なnickname、role、descriptionを定義した。Connectorがこのmanifestと実行用のagent設定を統合してcodex_agent_definitionsへ同期し、画面は同期済み定義を表示の正本として読む。
- main agentは
agent_key = "main"として、custom agentと同じ取得経路へ載せた。 ritsu the 2ndのようなruntime nicknameを、元のstable definitionへ正規化する。- 正式な表示名はdefinitionのnicknameを使い、画面では先頭文字の表記を整える。
3D状態変換でthreadに含まれる実行情報とagent definitionを対応付け、同じagent keyの複数sessionを一つの表示identityへ統合した。Makoだけを特別なhardcoded profileで扱う分岐も外した。
3D application表示と3D scene表示は、正式名、役割、紹介文をsnapshot内のprofileから表示するようにした。UI内に残っていた役職・紹介文のhardcodeを削除し、portrait、3D model、身長、待機messageだけをvisual metadataとしてアプリ側に残した。
- 定義済みAIタレントはruntime nicknameが変わっても同じ人物として表示する。
- 未定義のdynamic agentだけは、実行時情報からfallback profileを作る。
- 会話履歴に残る実行名は書き換えず、表示identityとの責務を分ける。
portrait判定とoffice mappingのtestを拡張し、同じAIタレントの複数session、main agent、定義済み10名、未定義agent、連番付きnicknameを検査した。実データでも複数sessionが一名へまとまることを画面で確認した。
表示identityはruntime nicknameではなく、stable agent keyを持つprofile manifestへ寄せた。runtime上の履歴名は残し、UI表示だけを定義へ結びつける。
図を描画しています…
確認したこと
確認結果
25件のtest、TypeScript型検査、ESLint、production buildが成功した。
Makoを含む10件のdefinitionがdatabaseから取得され、画面の正式名・役割・紹介文へ反映された。
実データの18 child taskで、Ritsuの2 session・7 messageが一名のRitsuへ統合された。
連番付きの実行名は画面に現れず、未定義agentのfallbackは維持された。
cutoff時点で定義駆動の表示identityは対象へ反映されていた。portraitや3D modelなどのvisual metadata自体をdatabaseへ移すことはこの範囲に含めていない。
完了とした根拠
10名のprofile定義、stable keyへの正規化、database由来の表示、dynamic fallbackが揃い、testと実データの複数session統合確認が通った内容が対象へ反映されたことをもって完了とした。