AI自己進化・記憶制御アーキテクチャ設計書 (v2026.05 rev4)

2026-04-22 初稿 → 2026-05-08 改訂（monChat2設計メモと統合）
この設計書は僕がClaudeへ考えを伝え、壁打ちしたのち清書してもらいました。
綺麗にまとまっているのはClaudeのおかげです。
途中の難しそうなDreamingの話はClaude君の理解です！

はじめに

この記事は、個人開発のチャットアプリ「monChat2」の記憶システム設計をベースにした、
「育つ相棒」としてのAI設計の構想メモです。

monChat2とは：AIペルソナを複数切り替えながらチャットできるPythonベースのアプリケーションです。ローカル（Ollama・LM Studio）とGemini APIを目的に合わせて切り替えながら使います。

この設計の核心は一言で言うとこうです。

記憶とは評価の記録ではなく、その人が何をよく語ったかの蒸留です。
「すき焼きが好き」ではなく、「すき焼きの話をよくする。割り下はやや甘め派らしい」という粒度。
ユーザーの言葉でできた、その人の像です。

ただし、LLMに直接system promptを書き換えさせるのは危険です。
そのため記憶はSQLiteで管理し、フラッシュ時にLLMが整理・更新し、
組み込む時だけsystem promptに展開する構造にします。
リアルタイムでは処理負荷が大きすぎるため、情報整理は手動フラッシュ時にまとめて行います。
これがこの設計における「AIが語りを読み返し考える時間」です。

2026年5月7日、AnthropicがClaude Managed Agentsに「Dreaming」機能を発表しました。
エージェントが過去セッションを振り返り、パターンを抽出して自己改善するという仕組みです。
この記事はその一週間以上前に書いた初稿を、さらに深めた改訂版です。

Anthropicの解法は「パターン抽出・ルーブリック評価」という工学的アプローチ。
この記事の解法は「性格・好み」という人間的アプローチ。目指す場所が違います。

1. 核心コンセプト：「育つ相棒」のための記憶設計

AIを単なる道具から育つ相棒へ変えるため、以下の2軸を中心に設計する。

• 忘却の設計 — 全てを覚えようとしない。記憶を研ぎ澄ます。

• 性格による記憶の重み付け — 人間が性格によって覚えることが異なるように、AIにも記憶専用の性格を持たせる。

思想の導出過程

「AIを会話しながら育てる」
→「成長とは自律的なプロンプト更新」
→「更新の材料をどう作るか」
→「重みの根拠は何か」
→「人間なら性格だ」
→「記憶専用人格を設ける」

LLMで記憶が難しい本質的な理由は、コンテキスト長でも検索精度でもなく、「何を覚えるかを決める主体（性格）がない」こと。

既存のAI記憶システムはほぼ全て「情報をどう構造化するか」の問題として扱ってきた。
チャンクの区切り方、ベクトル検索の精度、要約の圧縮率。
感情スコアを重みに使うアプローチもあるが、それも情報の属性として扱っているに過ぎない。

人間の記憶は違う。同じ出来事でも、人によって全く異なるものが残る。
それは構造の違いではなく、その人の性格・関心・気分による。
グルメな人は食事の記憶が鮮明で、エンジニアは技術の議論が残る。

ならば、AIにも記憶専用の性格を持たせればいい。それが裏人格（Filter Agent）というアイデア。

2. 記憶レイヤー構造

Layer 1  ベースプロンプト（永続・動的更新）
└ ユーザーの価値観・好み・趣向の濃縮要約
└ 頻度の高い記憶が自然昇格する「永遠の好み」

Layer 2  昨日プロンプト（12〜24時間）
└ 裏人格が拾った記憶の抜粋
└ 熱量・進行中の課題・直近の感情

Layer 3  生ログ・ウィンドウ（直近12時間）
└ スライディングウィンドウ管理
└ 「さっきのランチ」等の些細な事実を維持

Layer 1への昇格ロジック（重要）

Layer 2に繰り返し昇格した記憶・傾向は、自然にLayer 1へマージされる。
これが「ユーザーの永遠の好み」として定着する仕組み。

頻度という自然な淘汰圧が重要度の証明になる。
アルゴリズムで決めるのではなく、繰り返し選ばれたことそのものが重要度の根拠になる。

RAGのように「似たものを探す」必要がない。
入口で選別しているため、出口の検索が不要になる。

3. 裏人格（Filter Agent）設計

会話を担う表のペルソナとは完全に別の、記憶の取捨選択だけを担う人格。

• 表のペルソナは会話する

• 裏人格は記憶を選ぶ

• ユーザーからは見えない

表のキャラクターを変えても、裏人格が同じであれば蓄積された記憶は壊れない。
「自分のことを分かってくれている」感覚の連続性は、裏人格が守る。

組み合わせルール

| 枠 | 内容 |
|---|---|
| ベース人格（変更不可） | 汎用・取りこぼし防止網。全セッション共通。 |
| 固定枠 × 2（※仮） | ユーザーが指定。記憶の軸がブレない。 |
| ランダム枠 × 1 | セッションごとに自動選択。偶然性と多様性を生む。 |

完全ランダムにすると重要な人格が選ばれない日が続くリスクがあるため、固定枠を設ける。
ランダム枠があることで「今日はこの話題を覚えていた」という人間らしい揺らぎが生まれる。

ベース人格の役割

全セッション共通で動く、変更不可の汎用網。取りこぼし防止が目的。

ベース人格が拾う項目（概要のみ・詳細は拾わない）

• 今日の食事（例：「すき焼きを食べた」レベル）

• 健康状態

• 機嫌・感情

• 今日したこと（行動・出来事の骨格）

詳細は固定・ランダム人格が担う。ベースは「その人が今日どんな一日を過ごしたか」の骨格だけ。

固定・ランダム人格プール（例）

| 人格名 | 才能 | 主に拾うもの |
|---|---|---|
| ライフスタイル人格 | 日常 | 食事・買い物・体調・習慣の詳細 |
| プロジェクト人格 | 知性 | 専門知識・悩み・未解決課題・成長の詳細 |
| エモーショナル人格 | 感情 | 気分の振れ幅・話し方の癖・共通の笑い |

設計原則

• 特化してるから価値がある — 才能外はガン無視

• 各人格は「何を拾うか」より「何を拾わないか」を明示する

• 特化人格の記憶は繰り返しで自然強化 → 忘却しにくい

• ベース人格の記憶は時系列型 → 時間で薄れてOK

• 拾う件数に上限を設ける（例：3件まで）、なければ「なし」を許容

4. 処理パイプライン

毎ターン（軽量）

SQLite検索（記憶取得）
↓
system promptに記憶を追加
↓
LLMに投げる（1回のみ）

LLMへの呼び出しは1ターンに1回のみ。複数回呼び出しは禁止。

フラッシュ時（手動・低頻度）

会話ログ（6時間単位ファイル）
↓
裏人格（ベース＋固定2＋ランダム1）がLLMで判定
↓
閾値を超えた記憶 → Layer 2（昨日プロンプト）へ昇格
↓
繰り返し昇格した記憶・傾向 → Layer 1（ベースプロンプト）へマージ
↓
閾値未満の記憶 → 時間経過で希釈・消去（忘却）
↓
処理済みログは削除

ログ管理ルール

• ログは6時間単位のファイルで保存

• 3ファイル貯まったら → フラッシュ勧告表示

• 5ファイル貯まったら → チャット強制停止（品質とコストを守るため）

• フラッシュ完了 → チャット再開

自動処理ではなくユーザーが意識的にボタンを押す設計。
記憶の品質向上とLLM負荷の予測が容易になる。

5. 保存設計

| 項目 | 方針 |
|---|---|
| 記憶の保存先 | SQLite（消去しない・フル蓄積） |
| system promptに渡すもの | 圧縮・抽出した記憶のみ（軽量） |
| 生データ | DBに保持。渡すものと保存するものを分離 |
| RAG（embedding） | 採用しない。SQLite＋スコアベースで代替 |

SQLiteへの分離が必要な理由（安全性）

LLMに直接system promptを書き換えさせると以下のリスクがある。

• 暴走・意図しない上書き

• 人間が検証できない

• ロールバックが困難

そのため記憶はSQLiteで管理し、フラッシュ時にLLMが整理・更新、
組み込む時だけsystem promptに展開する構造にする。
人間がいつでも確認・修正できる状態を保つことが安全の条件。

記憶の粒度

記憶は短文の箇条書きで管理する。評価の記録ではなく、語りの蒸留。

× 「すき焼きが好き」（評価）

○ 「すき焼きの話をよくする。
   割り下はやや甘め派らしい。
   肉は関西風で卵につける」（語りの蒸留＋LLMの補完）

この粒度なら大量のデータを圧縮してsystem promptに収められる。
embeddingによるベクトル検索も不要。SQLiteの全件取得で十分。

RAGを使わない理由

裏人格が入口で選別しているため、「似たものを探す」処理が不要になる。
embeddingモデルの依存も不要。個人環境のリソース制約に優しい。

6. セッションログの記録項目

透明性と後からのチューニングのため、各セッションで以下を記録する。

• 選択された裏人格の組み合わせ（ベース＋固定2＋ランダム1）

• 各人格がスコアを付けた話題と重み

• 昇格した記憶の内容と昇格先（Layer 2 or Layer 1）

7. 設計の優位性

• Self-modifying prompt — LLM自身がユーザーの語りを読み返し、自分のsystem promptを育てていく。RAGの「外から注入」ではなく「内側から育てる」設計

• 文脈の連続性 — 「さっきの話」から「数ヶ月越しの好み」まで矛盾なく繋げる

• 深みの創出 — 裏人格が独自の哲学で選別するため、回答に一貫性と奥行きが生まれる

• 軽量化と進化 — 好みに特化して研ぎ澄ますことで、ローカル環境でも高精度なパーソナライズを実現

• 偶然性によるリアリティ — ランダム枠により「今日はこの話題を覚えていた」という人間らしい揺らぎが生まれる

• RAG不要 — 入口の選別で出口の検索を省略。シンプルかつ軽量

8. AnthropicのDreamingとの比較

| | Anthropic Dreaming | この設計 |
|---|---|---|
| 発想の軸 | パターン抽出・効率改善 | 好み・性格による選別 |
| 評価基準 | 完了率・ルーブリック | 繰り返し選ばれたこと |
| 対象 | エンタープライズ・エージェント | 個人のパーソナルAI |
| 記憶の主体 | アルゴリズム | 性格（裏人格） |
| 目指すもの | タスク最適化 | 育つ相棒 |

Anthropicの解法が工学的なら、この設計は人文的。どちらが優れているではなく、目指す場所が違う。

9. プロンプト肥大化について

Layer 1が育つほどsystem promptが膨らむ懸念があるが、実用上は以下の理由で問題になりにくい。

ローカル運用の場合
記憶の粒度は短文箇条書きのため、最大でも数千トークン程度に収まる見込み。
僕が利用しているGemma4 E4Bの128kコンテキストに対して余裕があり、速度への影響も誤差レベル。
コストはゼロなので金額的な懸念もない。

Gemini API利用の場合
フラッシュするまでsystem promptの内容は変化しないため、
GeminiのContext Cachingが自然に効く。キャッシュヒット時は90%割引。
チャットに限った個人利用レベルでは僕の場合月300円以下に収まる程度のコストであり、実質的な問題にならない。(Gemini 2.5 Flash-Lite使用時)

念のため上限件数（例：Layer 1は最大50件）を設けておくと安心ワン。

10. 未解決・要検討

• 裏人格プロンプトの具体的な設計（品質の核）

• 記憶のスコアリング基準

• SQLiteのスキーマ設計

• Layer 1とLayer 2の昇格ロジックの詳細

• 固定枠の最適な数（現在2は仮）

• ランダム人格プールの拡張方針

10. 実装指針

1. 段階的に始める — まず「12時間ログ＋ベース人格1つ」から

2. 裏人格のプロンプト設計が核 — ここの質が記憶の品質を左右する

3. ログ記録を最初から入れる — 後から検証・チューニングできるように

4. 人格プールを先に設計 — 選択UIはその後でよい

この設計はmonChat2の個人開発をベースにした構想です。
実装・検証を経て随時更新予定。