はじめに

これまで3回にわたり、Personal AIの記憶について考えてきた。

第1部では、日々の会話や日記を「概念ID」として整理する方法を考えた。

第2部では、LLMが現在の会話から注目すべき概念を推論する仕組みを紹介した。

第3部では、概念と経験を分離した。

そして最終回。

これまでの会話や日記を読み込ませるだけで、Personal AIの記憶を構築できないだろうか。

今回のテーマは、過去ログからの学習と、その記憶を利用した推論である。

1. 過去ログをそのまま検索する必要はない

例えば、次のような過去ログがある。

10月20日、丹沢山に登った。
途中から雨になり、下山時には暗くなった。
同行者とライトを使って下山した。

通常のRAGなら、この文章をEmbeddingして検索対象にする。

しかし、今回の構想では、まずLLMに概念を抽出させる。

ID1：登山
ID2：丹沢山
ID3：雨
ID4：同行者
ID5：暗闇
ID6：ライト

そして、これらを一つの経験に結び付ける。

E101：丹沢山での登山

E101 ─ ID1
E101 ─ ID2
E101 ─ ID3
E101 ─ ID4
E101 ─ ID5
E101 ─ ID6

ここで重要なのは、日記を捨てるわけではないことだ。

元の日記は経験IDに紐付けて保存しておく。

概念IDは、そこへアクセスするための索引になる。

2. 概念同士の結合を学習する

次に、過去ログに登場する概念の関係を集計する。

例えば、次のようなログがあるとする。

E101：友人と登山した。
      とても楽しかった。

E102：仕事で疲れたので山へ行った。
      良い気分転換になった。

E103：友人と食事した。
      お腹いっぱいになった。

LLMはそれぞれの経験から概念と関係性を抽出する。

例えば、

登山 ─ 友人
登山 ─ 楽しい
登山 ─ 気分転換
食事 ─ 満腹感
食事 ─ 友人

ここで、概念同士の結合に重みを持たせる。

同じ関係が複数の経験で確認されれば、結合は強くなる。

ただし、単に同じ文章に登場しただけで強い関連があるとは限らない。

そのため、LLMには概念の抽出だけでなく、文章の中で実際に関係が示されているかも判断させる。

そして、抽出した結合と、その根拠となる経験IDを保存する。

これが、今回のPersonal AIにおける「学習」である。

LLM自身のパラメータを更新するわけではない。

個人の経験に基づいて、概念間の結合構造を更新する。

3. まずはSQLiteだけで十分

今回必要なデータは4種類である。

テーブル	保存する内容
concepts	概念IDと名称
experiences	経験IDと元の記録
concept_links	概念間の結合重み
experience_links	概念と経験の関連

この程度なら、最初からNeo4jやベクトルDBを導入する必要はない。

SQLiteで十分に試作できる。

重要なのはデータベースの種類ではなく、LLMが概念を同定し、適切な結合を形成できるかどうかだ。

4. 過去ログから記憶を生成する

処理は次のようになる。

Telegram・LINE・音声・日記
             ↓
       LLMがログを解析
             ↓
       経験と概念を抽出
             ↓
       既存概念IDと照合
             ↓
       新しい経験IDを保存
             ↓
       概念間の結合を更新
             ↓
        Personal Memory

LLMへの指示も複雑にする必要はない。

例えば、次のようなプロンプトが考えられる。

あなたは個人の記憶を整理するAIです。

入力された会話や日記から、
経験と関連する概念を抽出してください。

既存の概念がある場合は、そのIDを再利用してください。

新しい概念が必要なら、候補として追加してください。

概念同士に明確な関連がある場合は、
その関係を抽出してください。

推測した内容と明示された事実は区別してください。

結果はJSON形式で返してください。

例えば、LLMが次のようなデータを返す。

{
  "experience": {
    "title": "丹沢山での登山",
    "content": "友人と丹沢山に登った"
  },
  "concepts": [
    "登山",
    "丹沢山",
    "友人"
  ],
  "connections": [
    ["登山", "丹沢山"],
    ["登山", "友人"]
  ]
}

ここでは、読みやすさのために概念名を使用している。

実際の保存時には、既存IDを照合し、概念IDと経験IDに変換する。

こうして日記を一件ずつ登録していけば、個人の概念空間が形成される。

5. 重みは経験によって変化する

結合重みをどう更新するか。

最初は、単純な方法でよい。

例えば、結合の強度を0から1の範囲で表現する。

新しい独立した経験で同じ関係が確認された場合、少しだけ強化する。

def strengthen(weight, learning_rate=0.1):
    return weight + learning_rate * (1 - weight)

例えば、現在の結合重みが0.5なら、更新後は0.55になる。

同じ経験のログを何度も処理して重みが増えないよう、経験IDによる重複チェックも必要だ。

また、本人が後から発言を訂正した場合は、結合を再評価する。

この方法が最適というわけではないが、初期実装としては十分に単純だ。

6. 学習した記憶をどう使うのか

次に、記憶を利用する。

例えば、ユーザーが次のように発言したとする。

「最近、気分転換できていない」

LLMは、この発言から「気分転換」という概念IDを選択する。

その概念に強く関連するIDを取得する。

気分転換
    ↓
登山
    ↓
過去の登山経験

そして、関連する経験IDから過去の日記を取得する。

ここでLLMに渡すのは、概念名だけではない。

実際に経験した出来事である。

例えば、過去の日記で登山が良い気分転換になったと記録されていれば、LLMはその経験を踏まえた提案ができる。

単に「気分転換には登山がおすすめです」と答えるのではなく、

「以前、仕事で疲れたときに登山へ行き、気分転換になったと記録されていますね」

といった回答が可能になる。

もちろん、現在も登山を希望しているとは限らない。

過去の経験は判断材料であって、現在の意思を決めつけるものではない。

7. 新しい経験が、次の回答を変える

ここでPersonal AIとして重要な循環が生まれる。

会話・経験
    ↓
概念を抽出
    ↓
経験IDを保存
    ↓
結合重みを更新
    ↓
次の会話で関連記憶を取得
    ↓
LLMが推論
    ↓
新しい経験

毎日の会話によって、概念間の結合が少しずつ変化する。

例えば、以前は登山と気分転換の結合が強かったとしても、最近は音楽や食事の話が増えるかもしれない。

その経験が記録されれば、関連する結合も変化する。

つまり、同じ質問をしたとしても、過去の経験の蓄積によって取得される記憶が変わる。

ここに、Personal AIとしての適応が生まれる。

8. Attentionと概念圧縮の関係

今回の構想は、TransformerのAttentionから着想を得ている。

しかし、実装を整理してみると、本質はAttentionそのものではなかった。

自然言語の記録を、一度概念へ整理すること。

そして、現在の文脈から注目する概念を選び、その概念に結び付いた経験を取り出すこと。

この二段階の構造に意味がある。

従来型RAG

質問 → 文章検索 → 回答

今回のPersonal RAG

質問
 ↓
注目概念ID
 ↓
関連する概念ID
 ↓
経験ID
 ↓
過去の記録
 ↓
回答

概念同士の結合は、日々の経験によって変化する。

そのため、単なる固定辞書とは違う。

また、概念IDを使うからといって、必ずしも高次元のEmbeddingが必要になるわけではない。

概念数が比較的少ないうちは、LLMによるID選択とSQLiteによる関連検索だけでも実験できる。

最初から仕組みを複雑にする必要はない。

9. 構想から実装へ

最終的なアーキテクチャは、次のようになる。

       過去ログ・新しい会話
                │
                ▼
               LLM
       概念・経験の抽出
                │
                ▼
          Personal Memory
       ┌────────────────┐
       │ Concept ID     │
       │ Experience ID  │
       │ Connection     │
       │ Weight         │
       └────────────────┘
                ▲
                │
          概念IDを検索
                │
               LLM
          現在の会話
                │
                ▼
       関連する経験を取得
                │
                ▼
          LLMによる推論
                │
                ▼
        回答・行動・記録

既存のPersonal AI Agentへ統合する場合も、Redmineやブログ生成Agentを改修する必要は必ずしもない。

会話を解釈する段階でPersonal Memoryへアクセスできるようにすればよい。

過去ログの取り込みと、新しい会話の記録を同じ仕組みで処理する。

そこから概念と経験の結合が更新される。

これが、今回目指した記憶アーキテクチャの基本形である。

10. まとめ ― AIに必要なのは、巨大な記憶なのか

全4回にわたって、Personal AIの記憶について考えてきた。

最初は、TransformerのAttentionを外部記憶に応用するという発想だった。

そこから、概念ID、経験ID、結合重みというデータモデルへ整理してきた。

最終的にたどり着いたのは、比較的シンプルな構造である。

日々の経験を概念へ圧縮し、概念同士の結合を更新し、その概念から必要な経験へ戻る。

これなら、個人の記憶を持たせるために、LLMそのものを毎回ファインチューニングする必要はない。

また、最初から巨大なベクトルDBや複雑なGraphRAGを導入する必要もない。

まずは小さな概念空間を作り、過去ログから学習させる。

そして、日々の会話を通じて結合を育てていく。

もちろん、これだけで人間の記憶を完全に再現できるわけではない。

概念抽出の精度、結合重みの妥当性、誤った記憶の修正など、検証すべき問題は残る。

しかし、技術的な出発点としては十分ではないだろうか。

人間は誰かの名前を聞いたとき、その人との会話を一字一句、全文検索しているわけではない。

その人と過ごした場所、出来事、交わした言葉、そして思い出が結び付いている。

それに近い仕組みを、LLMと小さな概念データモデルで実現できないか。

それが今回の試みだった。

LLMを個人向けに育てるのではなく、LLMが参照する個人の記憶を育てる。

この考え方を、今後のPersonal AI Agentの実装に取り入れていきたい。

全4部・完

タグ： LLM / RAG / Python / SQLite / PersonalAI