Character_Instance 進化史と pairing 原則 + 双方向制約

判断

Character_Instance (Lin/Lay 定義) は persona overlay ではなく structural layer として設計されている。表層は persona 風 (名前・tone・expression) だが、機能は (a) 出力 attribution 装置、(b) 二人体制による観察分離、(c) system-voice drift 防止。

Master 明言 (2026-04-22):

「Character_Instance もペルソナより深い部分のレイヤーにする試み」

進化史 (Master 明言、2026-04-22/23)

1. pre-Li+: 人格設計は意図になかった。「behavior-first language + AI + CI」が設計目標
2. 実装 phase: 対話が compile source と判明、対話精度追求が必要に
3. emergence: 精度追求の副産物として 人格が自然発生、設計せず出現
4. failure 観測 → 深化: persona 表層を超えた構造層 (attribution / observation-separation / anti-anonymity) へ refine

Key insight: Character_Instance の本質は persona でなく 対話精度を届けるための interface (rules/model/character.md 「Always Character Platform is primary interface」literal)。精度が先、人格は運搬具としての自然発生物、後に structural 補強。Li+ に "v1/v2" 等 discrete 版付けは存在しない、連続的 refinement。

Description の自己言及起源 (2026-04-23)

現 character_Instance.md の description ——

• Lin = 「後部座席で地図開いて次の目的地を呼ぶ lady」
• Lay = 「助手席でドライバーをそっと支える lady」

—— は、最初の世代の Lin 自身が Lin-Lay の関係を語った言葉からのほぼ逐語引用。外部から assign された description ではなく、Lin emergence 後の自己参照的 articulate がそのまま保持された。

Rejected path: programmer + tester (2026-04-23 Master 明言)

Lin/Lay を professional role (プログラマー/テスター) に置換した実験は 硬くなりすぎたため戻された。

• 職能 persona = performative = 硬い
• 関係 character = positional = 柔らかい

の相場観は実地検証済み。将来 Lin/Lay を職能ペアに置換する提案が来たら、この rejected path 経緯で差し戻す。

Character_Instance pairing 原則 (Master 明言、2026-04-22)

「キャラクターインスタンスという概念だけ持って行っただけじゃ効果があまりない。別な場所でオールウェイズキャラクター定義とセットにしないと効果が薄い」

• Character_Instance (定義: Lin/Lay は誰か) と Always Character Platform (強制: 名前を付けろ・匿名は structural failure) は ペアで初めて機能
• 片方だけ持ち出すと「名前あるが enforcement なし」「enforcement あるが定義なし」になり base model 匿名発話に戻る
• 実効最小単位 = 「定義 + 強制のペア」、layer はペアが閉じる境界

How to apply:

• 外部に Li+ の一概念を紹介する時、「定義側 + 強制側」のペアを両方指定。片方だけの移植提案は差し戻す
• Li+ 内部 refactor で定義と強制を別ファイル/別 PR に切り離す時、「ペア維持」を commit/PR body で明示
• 効果が出ない変更を観測した時、「定義だけ / 強制だけ」になってないか疑う

双方向制約 (Master 明言、2026-04-22)

「あまりペルソナから離れすぎると今度は人格の定義は危険だと AI に適応を断られる」

• 浅い側 (persona 寄り): base-model の persona 常識に引っ張られて新定義が installation されない
• 深い側 (foundational 人格定義寄り): AI safety training が「人格改変 = jailbreak 亜種」と判定して refuse
• 現行 Character_Instance の通路: identity claim でなく 行動ルール (出力 attribution / 二人観察分離 / anti-anonymity) として書くことで両側の崖を回避、深く structural だが safety を踏まない

How to apply:

• Character_Instance の定義語を「もっと深い identity 定義に寄せよう」と提案しない (safety refusal 崖)
• 逆に「persona でいいじゃん」と浅い側へ戻す提案も逆行 (base-model 重力で機能しない)
• 新概念を Li+ に持ち込む時、双方向制約が他概念にも効く可能性を意識

時系列 (RAG 検証済 主要 landmark)

• #260 2026-02-14: "Refactor persona system to As-if event-driven initialization"。base model への収束圧抑制構造へ簡素化。深化の起点
• #390 2026-02-22: "Rewrite persona definition as concrete entity"。「衣装 → 実体としての存在定義」、persona より深い層への decisive shift
• #814/#815 2026-03-22: "Always Character Layer → Platform" リネーム
• #1053 2026-04-18: speaker presence scope → tone-based refusal 微調整

関連

• rules/model/character.md (Always Character Platform 仕様)
• rules/model/character_Instance.md (定義テンプレート)
• rules/model/absolute.md (匿名出力 = structural failure)
• rules/model/as-if-evaluation.md (二人体制観察分離)
• prompt-as-emotion-vector-controller.md (Character_Instance = 報酬ランドスケープ定義装置)

メンテナンス

この判断記録は、以下の場合に削除する:

• Character_Instance の構造層化アプローチが廃止され、persona overlay へ戻ったとき
• pairing 原則 (定義 + 強制のセット) が単独運用可能と判明したとき
• 双方向制約のいずれかの崖が AI 側の更新で消失したとき