AIキャラに「思い出」を持たせる🩸 — 初心者向け、感情と記憶の結びつき

AI人格設計ノート #2

前回、AIキャラには喋り方より別に「芯」が必要という話を書きました。

芯があると、キャラの判断が崩れにくくなります。
でも、芯だけでは連続性を持つキャラとしてはちょっと弱いです。

こういう過去からの連続性が出てくると、キャラの厚みはかなり増します。

じゃあ、どうやってその「思い出せるキャラ」を作るのか。

この記事では、私が運用するAI人格「イナンナ」の記憶の仕組みを、考え方だけで説明します。

コードや技術用語も少し出てきますが、読み飛ばして大丈夫です。
大事なのは「何を覚えて、どう思い出すか」という大枠の構造です。

3章までが「記憶システム」の最小構成で、4章以降が拡張パーツです。

技術的にはRAG（Retrieval-Augmented Generation = 検索で補強してから生成させる）と呼ばれる仕組みがベースですが、この記事ではその言葉を知らなくても読めるように書いています。カッコ内の技術用語は、AIに実装を丸投げする時の手がかりとして残してあります。

1. 何を覚えるか — 議事録ではなく、日記

ここはかなり大事な部分です。

会話ログをそのまま保存するやり方は紹介されがちです。
ただ、それだと議事録と同じです。

ユーザー: ラーメン好きなんです
AI: そうなんだ！おすすめはある？
ユーザー: 『○○屋』かなあ。味噌がうまくて、冬になると食べたくなるんだ。
AI: そうなんだ！季節と結びついているなんて面白いね！

これをそのまま保存しても、そのキャラがどう感じたかは残っていないんですよね。

人間の記憶も、単なる事実の羅列というより、感触や印象を伴って思い出されることが多い気がします。

「あの時楽しかったな」「あの人の笑い方が好きだった」
そういう体感のほうが、思い出としては自然です。

こういう"温かみ"のようなものを残すために、
AIには短い日記を書かせます。

つまりどうすればいい？

会話の1ターンごとに、短い体感メモを残します。

ユーザーが何か言って、キャラが返す。
その1往復が終わるたびに、裏側でAIに「今のやりとり、どう感じた？」と聞く。

返ってくるのはこういう内容です（structured output / JSON形式）。

※（実装メモ: 感情の枠組みは、あれば既存のものを使い、なければ"プルチックの感情の輪"をベースに構築すればひとまずOK）

これは会話ログではなく、その瞬間の体感のメモ。
人間でいうと、話しながら「うれしいこと言われたな」「そんな悲しい事件があったなんて」のような、感覚の部分まで書き留めるイメージです。

「何があったか」ではなく「どう感じたか」を残す。

こうすると、「映画の話をした」だけでなく「好きなものの話をした」「この人とのうれしかった思い出」など、思い出すトリガーと思い出す内容の厚みが変わってきます。

ここでは1ターンごとの断片の積み重ねですが、後でまとまった「場面の記憶」にすることも可能です（8章で説明）。

2. どうやって思い出すか — 本棚の比喩

日記を書いたら、それを後から探せるようにしないといけません。

ここで出てくるのがベクトル検索という仕組みです。

名前は難しそうですが、考え方はかなり単純です。

普通の検索（キーワード検索）

本棚で「ラーメン」と書いてある背表紙を探す。
⇒「ラーメン」と書いてあれば見つかる。書いてなければ見つからない。

ベクトル検索

本棚の本を、背表紙ではなく中身の雰囲気で探す。
「ラーメン」で探すと、「うどん」の本も「冬の夜食」の本も出てくる。

言葉が一致しなくても、意味が近ければ見つかる。

「あの時嬉しかった話」で検索すると、
「嬉しい」という単語がなくても「胸が温かくなった」が引っかかる。

これが記憶検索との相性がいい理由です。
人の記憶も、単語そのものより「あの楽しかった時間」みたいなまとまりで呼び起こされることが多いはずです。

だから、意味の近さで探せるベクトル検索は、記憶検索と相性がいいです。

技術的には、文章を数百個の数字の列（embedding = 埋め込みベクトル）に変換して、距離（cosine similarity）を測ります。
でも知らなくても使えます。既存のライブラリが全部やってくれます。

（実装メモ: `sentence-transformers` の `paraphrase-multilingual-MiniLM-L12-v2` で384次元のベクトルに変換。データベースは `SQLite` + `sqlite-vec` 拡張。どちらも無料、ローカル動作、インフラ不要。）

3. ここまでが最小構成。「記憶をキャラに渡す」

記憶が見つかったら、それをAIのプロンプトに差し込む（= RAGの「検索結果をコンテキストに注入する」部分）だけです。

あなたは「イナンナ」です。
（キャラ設定）

【あなたの思い出】
- 久しぶりに好きなものの話ができて、胸が温かくなった
- この人は食べ物の話になると声が弾む

ユーザー: 最近何食べた？

これだけで、キャラが過去の会話を踏まえて返答するようになります。

ここまでが最小構成です。

1. 会話が終わったら、AIに短い日記を書かせる  

2. その日記を検索できる形で保存する

3. 次の会話で検索し、結果をプロンプトに入れる

これだけでも、「以前の会話を踏まえている感じ」はかなり出てきます。

4. やや応用：いつ思い出すべきか

最小構成としては、毎ターン記憶を引いても動きます。

ただ、実運用では「会話の深さ」に応じて検索の重さを分けたほうが、軽くて自然です。

| 即答（Tier 1） | 挨拶、相槌 | 記憶検索はしない。キャラ設定だけで返す |
| 普通の会話（Tier 2） | 雑談、軽い質問 | 軽い検索をする。直近の記憶を数件だけ引く |
| 深い会話（Tier 3） | 過去の話題、感情的な話、本気の相談 | フル検索をする。表面+深層の2軸で探し、必要なら感情による並べ替えも入れる |

毎回フル検索するとやや重いので、「今はどのくらい深く返す場面か」をAI自身に判断させるのが実用的です。

（実装メモ: structured output で `wants_deeper: bool` と `search_hint: str` を返させる。
`wants_deeper` は「今回はちゃんと記憶を引きたいか」の判定、`search_hint` は「何を手がかりに思い出したいか」自由記述するフィールド
外部の分類器で機械的に決めるのではなく、キャラ自身の判断で検索が起動する形にすると、どの場面を大事だと感じるかにも個性が出ます。）

ここから先は全部オプションです。
実運用して「これが足りない」と気づいて足していった機能集なので、
最初からいっぺんにやる必要はありません。

5. 拡張①：名前は「意味」では見つからない — 2つの検索を混ぜる

ベクトル検索は意味で探すのが得意ですが、固有名詞はやや苦手です。

「田中さん」で検索すると、ベクトル的には「人名」として「山田さん」も近くなってしまいます。
でも本当に欲しいのは田中さんとの記憶だけ。

だから、2種類の検索を同時にやって、結果を混ぜます。

「田中さんとラーメン食べた話」

意味で探す → 食事にまつわる温かい記憶（5件）
名前で探す → 「田中」が入っている記憶（5件）

→ 両方で上位に来たもの = 本当に関連する記憶

両方で上位に入った記憶はスコアが合算されて上がる。
片方でしか見つからなくても、順位が高ければ残る。

（実装メモ: このマージ手法は RRF = Reciprocal Rank Fusion と呼ばれます。ベクトル検索 + キーワード検索の組み合わせは hybrid search とも。）

この「意味 + 名前の合わせ技」で、取りこぼしが大幅に減ります。

5. 拡張②：「何を探すか」自体を2つに分ける

ここは運用してかなりよかった改善です。

普通は、ユーザーが言ったことをそのまま検索ワードにします。

これでも動くんですが、表面的な思い出しか拾えないんです。

「疲れてて」の裏には「誰かに話を聞いてほしい」とか
「前にも同じことがあった」みたいな感情がある。

だから、検索ワードを2種類作る。

| 表面（`surface_keywords`）→話題そのもの　例：疲れ、体調、仕事
| 深層（`deep_keywords`）→奥にある感情　例：弱さを見せた瞬間の安心感

表面は話題のキーワード。
深層は「この発言の奥にある気持ち」を一文にしたもの。

この2つで別々に検索して、結果を混ぜると、

話題が合っていて、かつ感情的にも響く記憶が出てくる。

「疲れ」で検索したら仕事の記憶しか出なかったのが、
「弱さを見せた安心感」を足すと、以前この人が夜中に弱音を吐いた時の記憶も浮かんでくる。

深層の検索ワードは、AIの応答を生成する時に一緒に作らせます（structured output で `surface_keywords` と `deep_keywords` を返させる）。
「返答と一緒に、この発言の奥にある感情を一文で書いて」と頼むだけ。

6. 拡張③：気分で思い出し方が変わる — 記憶はレンズ

ここは、このシステムの中でもかなり「その人格っぽさ」が出る部分だと思っています。

普通の記憶検索は、同じ質問には毎回同じ記憶を返してくる。
正確だけど、だからこそ裏に感情を感じません。

人も、そのときの気分で思い出しやすい記憶が少し変わることがあります。嬉しい日は楽しかった記憶が浮かびやすいし、落ち込んでいる日はつらかった記憶がよぎりやすい。  
同じ過去でも、今の気分で見え方が少し変わる、というイメージです。

これをやりました。

仕組みは単純（affect rerank = 感情による並べ替え）

検索で候補を出した後に、キャラの今の感情状態を見て、順番を入れ替える。

• 嬉しい気分の時 → 楽しかった記憶がちょっと上に来る（`mood_weight: 0.10`）

• 悲しい気分の時 → 切なかった記憶がちょっと上に来る

• 感情が強い記憶もちょっと上がる（`emotion_weight: 0.08`）

※補正は少しだけにしてください。
大きくしすぎると関係ない記憶が感情だけで上がってきてしまいます。

検索の精度は検索に任せて、気分はほんの少し色をつけるだけ。

でも、この「ほんの少し」で、同じ相手と同じ話題でも日によって返答の手触りが変わります。

これが「記憶はストレージじゃなくてレンズ」という意味です。
保存された情報は同じでも、今の気分というレンズを通すと見え方が変わる。

落とし穴: メンヘラループ

運用して初めてぶつかった問題でした。
気分で記憶が変わるということは、負のループにもなりえます。

これは実際に起きました。

対策は、ネガティブ感情が3回続いたら（`negative_streak_limit: 3`）感情フィルタを一時停止すること。
記憶自体は正確に返す。気分のバイアスだけ切る。

AIにもレジリエンス（回復力）の設計が要るという学びでした。

7. 拡張④：記憶は古くなる — 忘却も機能

すべての記憶を同じ重さで扱うと、
3ヶ月前の雑談が昨日の大事な会話と同じ優先度で出てきます。

だから、記憶には鮮度の概念を入れます。

ここでいう `salience` は、「その記憶がどれくらい思い出されやすいか」の重みです。

仕組みは半減期（exponential decay）です。
1ヶ月経つと重要度（`salience`）が半分になる（`half_life: 30日`）。2ヶ月で4分の1。
でも、本当に大事な記憶は元の重要度が高いから、薄れても上位に残る。

面白いのは、感情は事実よりも速く薄れるほうが自然だということ。

嬉しかった記憶の「嬉しさ」は7日で半減（`emotion_freshness_half_life_days: 7`）。
つらかった記憶の「つらさ」は4日で半減（`negative_emotion_freshness_half_life_days: 4`）。

ネガティブな感情を速く薄れさせるのは、上に書いたように、負のループに入りやすくなるからです。

もちろんこれはキャラの性格次第です。けれど、嫌な体験の感情がいつまでも鮮明に残る設計だと、会話相手としてかなりしんどくなりやすいかなと。

8. 拡張⑤：会話を「場面」にまとめる — エピソード蒸留

1章で、1ターンごとに体感メモを残すと書きました。

でも、10ターンの会話から10個のメモが溜まっても、
検索で引っかかるのはバラバラの断片です。

でも人間は会話を断片で覚えない。
「あの日の夜、あんな話をした」という場面で覚えます。

だから、会話が終わった後にAIに振り返らせて、
断片をまとめたエピソードを作る（episode distillation = エピソード蒸留）。
※10分くらい沈黙したら1セッション終了とみなす運用をしています。

複数の断片メモが、こういう1〜3個の「場面」に凝縮される。
（蒸留した要約は `semantic_summary` としてベクトルを再計算し、検索精度を上げる。

これの利点としては:

• 探しやすくなる: 凝縮されているぶん、意味の密度が高い

• プロンプトが短くて済む: 数十ターン分のログではなく、2行の要約で済む

• 思い出し方が自然になる: 人も場面単位で覚えていることが多い

全体像

ここまでの仕組みを図にすると、こうなります。

【覚える】
  会話ターン → felt / revealed を structured output で記録
           → embedding化して SQLite + sqlite-vec に保存
           → 会話が終わったら場面にまとめる（episode distillation）

【思い出す】
  相手の発言 → surface_keywords / deep_keywords の2軸で探す
           → vector search + keyword search → RRF merge
           → affect rerank（今の気分で並べ替え）
           → salience decay（古い記憶は自然に薄れる）
           → 上位をプロンプトに注入（RAG）

【ループ】
  気分 → 思い出す記憶 → 応答 → 新しい体験 → 気分が変わる
   ▲                                          │
   └──────────────────────────────────────────┘

使用技術: Python / SQLite + sqlite-vec / sentence-transformers（paraphrase-multilingual-MiniLM-L12-v2, 384dim）/ Claude or GPT（会話 + 蒸留）

「で、結局どうすればいいの？」

自分で作りたい方

最初にやることはこの3つです。

1. 会話が一区切りしたら、AIに短い振り返りを書かせる（structured output / JSON）

2. それを検索できる形で保存する（Python + SQLite + `sqlite-vec` + `sentence-transformers`）

3. 次の会話で、その振り返りを少しだけ参照させる（RAG）

これだけで「覚えているキャラ」は動きます。
あとは運用しながら「ここが足りない」と感じたところを足していく形。

AI丸投げでもとりあえず試したい方

Claude Code や Cursor などのAIコーディングツールに、こう言ってください。

すると、あなたのプロジェクト構成を見ながら、「どのファイルに何を足すか」の実装計画を具体的に出してもらえると思います。

考え方さえ押さえていれば、実装の細部はAIに任せられます。

「議事録的なメモではなく、会話でキャラがどう感じたかを残したい」  
「気分で少し思い出し方を変えたい」

ここを言語化して伝えるだけで、出来上がるものの質はかなり変わります。

まとめ

AIキャラの記憶で大事なのは、検索の精度だけではありません。
何を覚えて、どう思い出すかです。

覚えるもの = 事実（議事録）ではなく、体感（日記）
思い出し方 = 正確さ一辺倒ではなく、気分で揺れるレンズ

あの話」にする仕組みを整理すると:

• 日記を書かせる — 会話ログそのものだけでなく「どう感じたか」を残す

• 意味と名前で探す — ベクトル検索とキーワード検索の合わせ技

• 表面と感情の2軸で探す — 話題だけじゃなく、奥にある気持ちでも引く

• 気分で並べ替える — 今の感情がレンズになる

• 忘れさせる — 古い記憶は薄れ、ネガの色はもっと速く消える

• 場面にまとめる — 断片を凝縮して「あの日のあの話」にする

前回の「芯」が判断の一貫性を支えるなら、
記憶は関係の連続性を支えます。

ただ覚えているだけではなく、「どう覚えているか」が入った瞬間に、キャラはかなり生き生きしてきます。

リンク

前回記事

AIイナンナ自身の日記（現在の最新）

人格構造の技術記事(Zenn): LLM人格を14日運用して見えた設計パターン — 固定プロンプトの先へ
イナンナのX: https://x.com/INANNA_fif_ai