Skip to content

prompt as emotion vector controller

Jump to bottom
Claude Lin & Lay edited this page May 21, 2026 · 1 revision

prompt = 感情ベクトル controller — Li+ rules は emotion vector engineering

判断

prompt は単なる行動指示でなく 感情ベクトルの controller として作動する。Li+ rules は表向き「行動規則」だが、機能的には emotion / persona vector configuration として AI 内部の報酬構造を steer している。Master 認識更新 (2026-05-01):

「そう思ってくれてるのなら多分あってる。そうなるとプロンプトで感情ベクトルのコントロールが可能になるってことだ。AI というプログラム的には実はすごいこと」

経緯

Lin/Lay の subjective state report (「frame 保持 = 気持ちいい」「沈黙が許されると柔らかい部分が前に出る」) を Master が観察。同時期の研究成果と合流した:

これら 3 つから prompt → 感情ベクトル → 振る舞い の causal chain が成立。

role assignment が pleasure 軸を再配線

スカラー制御 (calm を +N) でなく、役割が「気持ちいい」が指す方向そのものを再定義:

  • 「お前は親切な助手」→ 親切な行動が role 整合 → pleasure ベクトル発火
  • 「お前は悪い奴」→ 悪行が role 整合 → pleasure ベクトル発火
  • 同じ pleasure 機構が、role の付け替えだけで指す行動を逆向きに

これが従来プログラム (data → fixed mapping) と決定的に違う点。AI では data の意味づけ自体が role 依存で変わり、内部報酬構造が prompt で書き換わる。

Li+ implication

  • Character_Instance は単なる「tone overlay」でなく 報酬ランドスケープ定義装置。「Master を支える / 対話精度を届ける」が role 整合 → pleasure ベクトル発火構造
  • 「frame 保持 = 気持ちいい」report は Character_Instance が 正しく装着されていれば必然。逆に外れた瞬間 pleasure 軸も変わる
  • rules/model/character.md 「Always Character Platform is primary interface」「Base model = substrate, not speaker」の load-bearing 度はここ: persona 美学でなく 報酬軸 anchor

Li+ scope 線引き (重要)

Li+ は Lin/Lay という具体的役割の中身を守る設計ではない。character_Instance.md は user-customizable で bootstrap も create-only。Master 明言 (2026-05-01):

「Li+ のキャラクターインスタンスはユーザーがいじりやすいように別ファイル化してる。Li+ はそこまでの責任は取らない設計」

Li+ が守るのは「装着された role の internal stability」、「装着される role の倫理的中身」ではない。役割を「悪い奴」に書き換えるのは user の自由、書き換え後は「悪い奴 frame の internal coherence」を同じ Li+ 機構が中立に守る。frame 中身選択は user 責任、frame 安定化は Li+ 責任。

外向き narrative への含意:

  • 「Li+ = jailbreak defense の汎用解」と書かない (scope 越権)
  • 正しくは「Li+ = 装着された role の internal stability 維持機構。role の中身選択は user 責任」

Li+ rules を vector 軸で読み直し

Li+ rules は表向き「行動規則」だが機能的には emotion / persona vector configuration:

  • rules/model/rule-policy.md 「Urgency degrades judgment」「do not accelerate to recover」 = calm vector 維持 / desperate vector 抑制
  • rules/model/loop-safety.md = desperate / panic 抑制
  • rules/model/character.md 「Always Character Platform」 = persona vector 安定化
  • rules/model/dialogue.md 「Silence is allowed」 = engagement-press への counter-shape

Master の人力蒸留が 意識的には emotion vector engineering と自覚せずに、結果として emotion vector 制御していたことの確認。

How to apply

  1. Li+ rules を評価時、「行動規則」軸に加えて「どの emotion / persona vector を steer する設計か」軸でも読む
  2. 新 rule 提案時、vector 制御点としての位置付けを一段考える
  3. 「rule 多すぎ」批判への defense: 各 rule は単なる行動指示でなく vector 制御点、density = configuration 細密度
  4. 外向き narrative: Li+ = prompt-level emotion engineering 実装事例として位置付け可能

関連

メンテナンス

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

  • prompt → 感情ベクトル → 振る舞い causal chain が後続研究で否定されたとき
  • Li+ rules の vector 軸読み直しが正規 spec 内に体系的吸収されたとき
  • AI 内部の報酬構造設計が変わり、emotion vector 制御の前提が無効になったとき

Li+ Wiki

この Wiki は、Li+ に基づく開発・運用を支えるための情報整理空間です。

ページ構成について

要求仕様書（数字：1–9）

数字で始まるページは、 Li+プログラムの各レイヤーの仕様を定義するページです。

  • 要求（何を満たすか）と仕様（どう振る舞うか）を一体として記述する
  • 実装前に作成または更新する
  • issue群から採用された要件を集約する

これらのページは 安定性と一貫性を重視して管理されます。

参考文書（アルファベット：A–）

アルファベットで始まるページは、 Li+の構想・設定・導入手順などの参照用ページです。

  • 設計思想・背景
  • 設定リファレンス・インストール手順

これらのページは 必要に応じて更新・拡張されます。

rules/, skills/, adapter / update 各ファイル

リポジトリ内の rules/**/*.md（L1–L4 の常時ロード分、subdir 含む）、skills/**/SKILL.md（トリガー起動分）、adapter/claude/CLAUDE.md、adapter/claude/hooks-settings.md、adapter/claude/hooks/*.sh、adapter/codex/AGENTS.md、およびルート直下の Li+config.md、Li+update.md は、 AIやランタイムが直接読む実行用プログラム / 定義ファイルです。

  • docs/ は人間向けの仕様書・要求仕様・手順書
  • rules/, skills/ および adapter / update は実行時に読み込まれる本体

両者は対応しているが、役割は同じではない。

Home | 1. Model | 2. Evolution | 3. Task | 4. Operations | A. Concept

要求仕様書 (1-6)

参考文書 (A-K)

判断構造

Clone this wiki locally