― 会話履歴・状態・知識・曖昧性を分離する
LLMを使ったシステムを作っていると、かなり早い段階で一つの問題にぶつかります。
「このAIに、どうやって記憶を持たせるのか？」
最初は簡単に見えます。
会話履歴を保存する。
必要な過去の会話を取り出す。
RAGで文書を検索する。
ベクトルDBにEmbeddingを入れる。
これで「AIの記憶」ができるように思えます。
しかし、実際にAIを長期間使い、複数のAgentを動かし、仕事を途中で止めたり再開したりしようとすると、少し違う問題が見えてきます。
例えば、
- 今の会話で一時的に覚えておけばよい情報
- 今日の作業を再開するために必要な状態
- 数週間後にも利用したい知識
- AIが「そうかもしれない」と推測しただけの情報
- 人間が確認して確定した事実
- 以前の判断が後から覆った履歴
これらは、全部「記憶」と呼べます。
しかし、本当に同じ種類の記憶でしょうか。
私たちはVERTEXを設計する過程で、ここに疑問を持ちました。
LLMの記憶を、一つの巨大なMemoryとして扱う必要があるのか？
そこで考えたのが、
記憶そのものをレイヤーとして分離する
という考え方です。
1. 「LLMに記憶を持たせる」とは何なのか
まず、LLMそのものについて考えてみます。
一般的なLLMは、少なくとも通常の利用形態では、人間のように会話を永続的に覚え続けているわけではありません。
セッションが終われば、その会話を自動的に次のセッションへ持ち越せるとは限りません。
そのため、
ユーザー
↓
LLM
↓
会話履歴
という仕組みを作り、
「過去の会話をもう一度LLMへ与える」
ことで、あたかも記憶しているように見せることができます。
しかし、これは本当の意味での「記憶」なのでしょうか。
例えば100万トークンの会話履歴を毎回LLMへ送れば、過去を大量に参照できます。
でも、それは、
記憶した
というより、
過去のデータをもう一度入力した
と考えることもできます。
ここから、記憶層を考える必要が出てきます。
2. 会話履歴と記憶は同じではない
例えば、今日こんな会話をしたとします。
ユーザー:
明日は10時から会議。
AI:
了解しました。
これは会話履歴です。
しかし、明日になって、
「今日の10時から会議だったよね」
と聞かれた場合に必要なのは、単なる会話ログではありません。
必要なのは、
予定:
日時 = 明日 10:00
種類 = 会議
という意味化された情報です。
つまり、
Conversation
↓
Meaning
↓
Memory
という変換があります。
ここで重要なのは、
会話そのもの
と
会話から抽出された記憶
は別物だということです。
3. 一つのMemoryに全部入れると何が起きるか
全部を一つのMemory Storeに入れることもできます。
例えば、
Memory
├─ 会話
├─ ユーザー情報
├─ 作業状態
├─ 知識
├─ 推測
├─ 仮説
├─ 設定
├─ 過去の判断
└─ ログ
という構成です。
一見すると簡単です。
しかし、しばらく使っていると問題が起きます。
例えば、
「昨日の会話でAIが推測していたこと」
と
「人間が確認した確定情報」
が同じ場所に存在するかもしれません。
するとAIが検索したとき、
推測
と
確定事実
の区別が曖昧になります。
この問題は、Impact DBで考えていたことと完全につながります。
4. 記憶には「確定度」がある
例えばAIが、
「Aである可能性が高いです」
と発言したとします。
これをそのまま長期記憶に保存すると、
Aである
と誤認される可能性があります。
しかし本当は、
候補 = A
状態 = 未確定
根拠 = X
確信度 = high
です。
つまり、記憶には、
内容
だけではなく、
その内容がどの程度確かなのか
という情報が必要になります。
ここで、
Memory
├─ Fact
├─ Hypothesis
├─ Candidate
└─ Observation
を分ける意味が出てきます。
5. 私たちが考えている記憶のレイヤー
VERTEXでは、現時点では記憶を一枚岩としてではなく、概念的に複数の層として扱う方向で考えています。
LLM Memory Architecture
┌─────────────────────────────────────┐
│ Working Memory │
│ 今考えていること・現在の文脈 │
└──────────────────┬──────────────────┘
↓
┌─────────────────────────────────────┐
│ Session / State Memory │
│ 作業途中の状態・Checkpoint │
└──────────────────┬──────────────────┘
↓
┌─────────────────────────────────────┐
│ Impact DB │
│ 仮説・候補・曖昧・未確定・影響 │
└──────────────────┬──────────────────┘
↓
┌─────────────────────────────────────┐
│ RDB │
│ 確定した事実・構造化情報 │
└──────────────────┬──────────────────┘
↓
┌─────────────────────────────────────┐
│ Knowledge Memory │
│ 長期的に再利用する知識・規則 │
└─────────────────────────────────────┘
ここで重要なのは、
全部を一つのMemory Storeに押し込まない
ことです。
それぞれの層に、違う役割を持たせます。
6. Working Memory
最初の層は、現在の作業に必要な情報です。
例えば、
今このユーザーが何をしているのか
直前の指示は何か
今どこまで作業が進んでいるのか
今の会話で何を参照しているのか
などです。
これは人間で言えば、
作業机の上に広げている資料
に近いものです。
必要な間だけ保持すればよい。
場合によっては数分、数時間で不要になります。
そのため、Working Memoryを長期保存する必要はありません。
7. Working Memoryは「頭の中」ではない
ここも重要です。
LLMが現在のコンテキストとして受け取っている情報と、外部に保存されているWorking Memoryは別です。
例えば、
External Memory
↓
Context Assembly
↓
LLM
とします。
つまり、AIの「今考えていること」を永続保存するのではなく、
必要な情報だけをその都度コンテキストへ組み立てる
わけです。
これにより、
- コンテキストサイズ
- 推論コスト
- ノイズ
- 不要な履歴
を減らせる可能性があります。
8. Session / State Memory
次が、セッションや作業状態です。
これはWorking Memoryとは少し違います。
例えば開発作業で、
Project = vertex_workstation
Task = Lane Manager
Stage = Verification
Human Gate = Pending
という状態になったとします。
その途中で、
- PCが再起動した
- Sessionが切れた
- AIとの通信が切れた
- 別のAIへ引き継いだ
としても、仕事そのものは失いたくありません。
ここで必要なのが、
会話の記憶ではなく、仕事の状態の記憶
です。
9. 「会話が残っている」と「仕事を再開できる」は違う
これはAI開発システムでは特に重要です。
例えば会話ログが全部残っていても、
どこまで実行したか
どのファイルを変更したか
何が検証済みか
何が未完了なのか
次に何をするべきか
が分からなければ、仕事は再開できません。
だから、
Conversation History
と、
Work State
は分けた方がよい。
これがSession / State Memoryです。
10. Checkpointという考え方
Session / State Memoryでは、Checkpointが非常に重要になります。
例えば、
Checkpoint 001
task accepted
Checkpoint 002
files analyzed
Checkpoint 003
modification applied
Checkpoint 004
verification started
Checkpoint 005
verification completed
というように、
仕事の節目で状態を保存する
ことができます。
こうすると途中で通信が切れても、
Last Known Good State
へ戻れます。
これは、VERTEX Session Portalで考えているResilienceともつながっています。
11. Sessionの復旧は「会話の復旧」ではない
AIシステムの障害復旧を考えるとき、
「チャット履歴が戻ったから復旧成功」
では不十分です。
重要なのは、
仕事の状態が戻ったか
です。
そのため、
Conversation
ではなく、
Work State
を中心に復旧する設計が必要になります。
これによって、
「AIの接続は切れた。しかし仕事は切れていない」
という状態を作れます。
12. Impact DB
ここで、先ほどの記事で説明したImpact DBが登場します。
AIが扱う情報には、
事実
観測
仮説
候補
推測
未確定
矛盾
懸念
があります。
これらをすべて確定データとして保存すると、情報が変形してしまいます。
そこで、
Impact DB
に、
まだ確定していないが、意味や影響を持つ情報
を保存します。
13. Memoryに不確実性を持ち込む
例えばAIが、
右前に違和感がある。
原因はまだ不明。
という情報を得たとします。
普通のMemoryでは、
右前 = 異常
などと簡略化されるかもしれません。
しかしImpact DBでは、
Observation:
右前に違和感
Cause:
Unknown
Impact:
Potentially significant
Status:
Pending
として保持できます。
つまり、
記憶の中に「分からない」という状態を保存する
わけです。
これはAIにとって非常に重要です。
14. 「記憶」と「真実」を分ける
ここで、Memory Architectureに一つの原則が生まれます。
記憶されていることと、真実であることは同じではない。
AIは、
以前そう言われた
ことを覚えているかもしれません。
しかし、
それが現在も真実なのか
は別問題です。
例えば、
Memory:
「Aらしい」
があったとしても、
Evidence:
「Bだった」
となることがあります。
このとき、
Aという記憶を消す
だけでは不十分です。
「以前Aと推測していた」という履歴にも価値があります。
15. Knowledge Memory
さらに長期的に保持したい情報があります。
例えば、
技術仕様
業務ルール
製品仕様
用語
過去に確定した知識
設計原則
組織固有のノウハウ
などです。
これは、
Knowledge Memory
として扱えます。
Knowledgeは、Working Memoryとは違います。
毎回の会話のために存在するものではなく、
長期間、繰り返し参照するための記憶
です。
16. KnowledgeとRDBは同じではない
「KnowledgeならRDBに入れればいいのでは？」
という疑問も出てきます。
もちろん、構造化された知識ならRDBで十分な場合があります。
しかし知識には、
文章
規則
関係
文脈
例
説明
概念
リンク
などもあります。
そのため、Knowledge Memoryは、
RDB
Document Store
Vector Index
Graph
など複数の技術を組み合わせる可能性があります。
重要なのは、
どの保存技術を使うかより、記憶の役割を分離すること
です。
17. Shared Brain
VERTEXでは、さらにAgent間で共有するKnowledgeという考え方があります。
例えば、
Agent A
Agent B
Agent C
が同じプロジェクトで働いている場合、
一人のAgentだけが知っていることと、
プロジェクト全体が共有すべき知識
は違います。
そこで、
Agent Memory
│
▼
Shared Brain
│
▼
Shared Knowledge
という構造を考えます。
これによって、
個人の記憶
と
組織の記憶
を分離できます。
18. 個人の記憶と共有の記憶
人間の組織でも、
個人が覚えていること
と、
組織として残すべきこと
は違います。
AI Agentでも同じです。
例えば、
Developer Agent:
「今このファイルを調査中」
は個人の作業状態です。
一方、
Project Rule:
「Production mutationは禁止」
は共有知識です。
これを同じMemoryに入れると、権限や寿命の違いが分からなくなります。
19. Memoryには「寿命」がある
ここからさらに重要な概念があります。
記憶には寿命がある。
例えば、
Working Memory
→ 数分～数時間
Session State
→ 作業完了まで
Impact Memory
→ 解決・確定するまで
Knowledge
→ 長期間
Permanent Fact
→ 長期保存
というように、寿命が違います。
これを全部同じストレージへ入れると、
- 古い情報
- 一時情報
- 確定情報
- 未確定情報
が混ざります。
そこで、
Memory Lifecycle
という考え方が必要になります。
20. Memory Lifecycle
概念的には、
Created
↓
Active
↓
Referenced
↓
Updated
↓
Resolved
↓
Archived
というライフサイクルを考えられます。
例えばImpact DBに入った候補が、
Candidate
から、
Confirmed
になったら、
RDBやKnowledgeへ移すことができます。
逆に、
Rejected
になった場合も、その履歴を保持できます。
21. Memoryには「信頼性」も必要
例えば、次の2つがMemoryに存在するとします。
「人間が確認した仕様」
と、
「AIが推測した仕様」
これを同じ重みで扱うと危険です。
そこでMemory Entryには、
source
authority
confidence
verified
timestamp
evidence
などの情報が必要になります。
つまり、
Memoryは内容だけでなく、Memoryの出所も記憶する
必要があります。
22. Provenance
これはAIシステムを長期間運用する上で非常に重要です。
例えば、
この情報はどこから来たのか？
を追える必要があります。
Human
↓
Observation
↓
Agent
↓
Inference
↓
Memory
なのか、
Document
↓
RAG
↓
LLM
↓
Memory
なのか。
同じ「Memory」に見えても、意味が違います。
だから、
Memory without provenance is dangerous
という考え方が重要になります。
23. 記憶の「確度」と「重要度」は別
Impact DBの記事でも書いたように、
確定している
ことと、
重要である
ことは別です。
例えば、
確度 = 低
影響 = 高
という情報があります。
これは、
「まだ分かっていないが、重要なので調べるべき」
という状態です。
逆に、
確度 = 高
影響 = 低
なら、
「ほぼ確定しているが、特に重要ではない」
かもしれません。
Memory Architectureでは、この二つを分離して考える必要があります。
24. 記憶は「検索する」だけではない
一般的なMemory Systemでは、
Query
↓
Search
↓
Relevant Memory
↓
LLM
という構造が多いと思います。
しかし、より高度なAIシステムでは、
どのMemoryを参照すべきか自体を判断する
必要があります。
例えば、
今のタスク
ならWorking Memoryを見る。
前回の作業状態
ならSession Stateを見る。
過去の未確定問題
ならImpact DBを見る。
プロジェクトの仕様
ならKnowledgeを見る。
つまり、
Memory Router
が必要になります。
25. Memory Routerという考え方
概念的には、
Query
│
▼
Memory Router
│
┌───────────────┼───────────────┐
↓ ↓ ↓
Working Session Knowledge
Memory State
│ │ │
└───────────────┼───────────────┘
↓
Impact DB
│
↓
LLM
という構造です。
重要なのは、
LLMに全部の記憶を読ませない
ことです。
必要なMemoryだけを取り出します。
26. これはコンテキストウィンドウ問題にもつながる
LLMのコンテキストウィンドウが大きくなっても、
「全部入れればいい」
という話にはなりません。
情報が多すぎれば、
- ノイズ
- 競合
- 古い情報
- 重複
- irrelevant context
が増えます。
そのため、
コンテキストサイズを増やすこと
と
記憶を賢く整理すること
は別問題です。
むしろ、Memory Architectureが成熟すれば、
必要な記憶だけを短いコンテキストに集約する
方向へ進める可能性があります。
27. MemoryとVXN
ここでVXNともつながります。
AI間通信をVXNで行うなら、Memoryも単なるDBだけではなく、
Agent
↓
Memory Request
↓
VXN
↓
Memory Layer
↓
VXN
↓
Agent
という形でアクセスできます。
つまり、
AIが記憶層と通信するための神経系
としてVXNを使うことも考えられます。
例えば、
MEMORY_QUERY
MEMORY_STORE
MEMORY_UPDATE
MEMORY_RESOLVE
MEMORY_INVALIDATE
のような意味を、VXNのDomain Profileとして扱える可能性があります。
28. MemoryとEvidence
さらにImpact DBとEvidenceを組み合わせます。
例えば、
Memory:
「Aかもしれない」
があり、
新しいEvidenceが、
Evidence:
「Bを支持」
だったとします。
すると、
A candidate
↓
weakened
となる。
さらに別のEvidenceが来れば、
A
↓
confirmed
になるかもしれません。
つまり、
Memoryは固定された情報ではなく、Evidenceによって更新される状態
として扱えます。
29. Memoryの更新は「上書き」ではない
普通のDBでは、
UPDATE value
SET value = B
で終わることがあります。
しかしAI Memoryでは、
なぜAからBへ変わったのか？
も重要です。
そこで、
A
↓
Evidence X
↓
B
という履歴を残せます。
これは監査だけではなく、
- 推論改善
- Knowledge改善
- Agent改善
- Prompt改善
にも使えます。
30. 「忘れる」ことも記憶設計
記憶について考えると、
「どう覚えるか」
ばかり考えてしまいます。
しかし、本当に重要なのは、
いつ忘れるか
です。
例えば、
一時的な作業メモ
を永久保存する必要はありません。
逆に、
重要な設計原則
を数時間で消してしまってはいけません。
したがってMemoryには、
TTL
Retention
Importance
Authority
Access Frequency
Resolution State
などが必要になる可能性があります。
31. Forgetting Policy
例えば、
Working Memory
→ 自動Expire
Session State
→ Project完了まで保持
Impact DB
→ Resolve後も履歴保持
Knowledge
→ 明示的変更まで保持
Permanent Fact
→ 厳格な更新ルール
というようなルールを考えられます。
つまり、
忘却もMemory Systemの機能
です。
32. 「全部覚えるAI」は、本当に良いAIなのか
ここで、少し根本的な問題に戻ります。
AIに全部覚えさせたら便利そうに見えます。
しかし、
古い情報
誤った情報
未確認情報
一時的な情報
重複情報
まで全部覚えていたら、かえって判断を邪魔する可能性があります。
人間でも、
何でも覚えていること
と、
重要なことを適切に思い出せること
は違います。
AIでも同じではないか。
ここから、
Memory Quality
という考え方が出てきます。
33. 記憶量より「記憶品質」
AI Memoryを評価するとき、
何件保存できるか
だけを見るのではなく、
必要な情報を取り出せるか
古い情報を除外できるか
不確実性を保持できるか
根拠を追跡できるか
更新履歴を維持できるか
を見る必要があります。
つまり、
AIの記憶力 = ストレージ容量
ではありません。
むしろ、
AIの記憶力 = 適切な情報を、適切な状態で、適切なタイミングに再利用できる能力
と考えた方が自然かもしれません。
34. Memory Architectureの全体像
ここまでの考えを一度まとめると、概念的には次のようになります。
VERTEX MEMORY
LLM
│
┌────────┴────────┐
│ Memory Router │
└────────┬────────┘
│
┌─────────────────────┼──────────────────────┐
│ │ │
▼ ▼ ▼
Working Memory Session / State Knowledge
│ │ │
│ │ │
└──────────────┬──────┴──────────────┬───────┘
│ │
▼ ▼
Impact DB RDB
│
▼
Evidence
│
▼
Confirmation
そしてAIや各Systemとの通信を、
VXN
│
┌──────────────┼──────────────┐
│ │ │
Agent Memory Runtime
という形でつなぐ。
この構造が、私たちが考えているVERTEXの方向性です。
35. この設計で何が変わるのか
この構造の大きな特徴は、
記憶を「一つの箱」ではなく「状態と役割を持ったシステム」として扱えること
です。
例えば、
今考えている
と、
今の仕事の状態
と、
まだ確定していない仮説
と、
確定した事実
と、
長期的な知識
を分けられます。
これだけでも、AIが記憶を利用する際の混乱を減らせる可能性があります。
36. AgentごとのMemory
さらにAgentが複数存在すると、Memory Architectureはもう一段面白くなります。
例えば、
Architect Agent
Developer Agent
Reviewer Agent
Research Agent
Consultant Agent
がいるとします。
各Agentに、
Private Memory
を持たせることができます。
その上で、
Shared Brain
を共有します。
概念的には、
Shared Brain
/ | \
/ | \
Architect Developer Reviewer
│ │ │
Private Private Private
Memory Memory Memory
という構造です。
37. Private MemoryとShared Memory
これによって、
誰が何を知っているのか
を明確にできます。
例えばDeveloper Agentが、
「このファイルは現在編集中」
と知っていても、
Architect Agentがそれを知る必要はないかもしれません。
一方、
「Production mutationは禁止」
は全Agentが知るべきでしょう。
つまり、
Memoryにはスコープがある
わけです。
38. Memory Permission
ここからさらに、
Read
Write
Append
Resolve
Delete
Promote
Share
などの権限が必要になる可能性があります。
例えば、
Agent
→ Working Memory: Read/Write
Agent
→ RDB: Read only
Agent
→ Impact DB: Read/Write
Human
→ Confirmation: Authoritative
というように、
記憶へのアクセスそのものをPermissionで制御する
ことができます。
これはAIシステムにとって重要な設計要素になります。
39. Human Memoryとの接続
AIだけでなく、人間もMemory Systemの一部になります。
例えば、
AI Observation
↓
AI Hypothesis
↓
Human Review
↓
Human Confirmation
↓
Knowledge
という流れです。
この場合、
Humanが確認した
こと自体が非常に強いEvidenceになります。
つまり、Memory Architectureの中にHuman Gateを組み込むことで、
AI Memory
+
Human Verification
という構造を作れます。
40. AI Memoryは「脳のコピー」ではない
ここまで来ると、
「AIに人間の脳みたいな記憶を持たせるのか？」
と考えたくなります。
しかし、そうではありません。
私たちが考えているのは、
AIが仕事を継続し、過去の情報を適切に再利用し、不確実性を保持しながら、確定した知識を蓄積できるシステム
です。
つまり、
Human Brain
を模倣するのではなく、
AIシステムに必要なMemory機能を工学的に分解する
というアプローチです。
41. まだ完成した設計ではない
ここまでの構造は、完成済みの標準仕様ではありません。
今後、
- Memory Entryのスキーマ
- Memory Router
- Memory Lifecycle
- Resolution Policy
- Evidence Link
- Provenance
- Permission
- Retention
- Shared Brain
- VXNとの通信仕様
などを具体化する必要があります。
さらに、
どの情報をどのMemory層へ置くべきなのか
という判断自体をAIに行わせる必要も出てきます。
42. 研究したいこと
この領域では、実際に比較実験をしてみたいことがたくさんあります。
例えば、
Memory Retrieval Accuracy
必要なMemoryを正しく取り出せるか。
Context Efficiency
不要な履歴を削ってコンテキストをどれだけ小さくできるか。
Memory Contamination
古い情報や誤情報が新しい判断へどの程度影響するか。
Resolution Accuracy
Impact DBの候補が適切なタイミングで確定されるか。
Recovery
Session切断後にWork Stateを正しく復元できるか。
Multi-Agent Sharing
複数AgentがShared Brainを使ったとき、どの程度効率が向上するか。
43. 「記憶できるAI」から「記憶を管理できるAI」へ
AI Memoryの議論では、
長期記憶を持つAI
という言葉がよく使われます。
しかし、私たちが目指しているのは少し違います。
重要なのは、
どれだけ覚えているか
ではなく、
何を、どこに、どの状態で、どの寿命で、どの権限で保存するか
です。
つまり、
Memory Capacity
ではなく、
Memory Architecture
が重要になる。
44. 記憶は「データ」ではなく「状態」
最終的には、ここが一番重要かもしれません。
Memoryを、
key = value
だけで考えるのではなく、
state
source
confidence
authority
timestamp
evidence
scope
lifecycle
を含む、
状態を持った情報
として扱う。
そうすれば、
Unknown
Candidate
Observed
Pending
Confirmed
Rejected
Archived
という状態を自然に扱えます。
45. VERTEXが考えるAI Memory
私たちの考えでは、AI Memoryは単純な「過去の会話保存」ではありません。
それは、
Working Memory
+
Session State
+
Impact
+
Confirmed Facts
+
Knowledge
+
Evidence
+
Provenance
+
Shared Brain
という複数層から構成される、
AIのための記憶システム
です。
そして、
VXN
がその間をつなぐ通信層になる。
46. おわりに
LLMは、非常に強力な推論エンジンです。
しかし、LLM単体だけで、
「長期間仕事を続けられるAI」
になるわけではありません。
必要なのは、
- 何を今覚えているのか
- 何を後でも覚えておくのか
- 何をまだ確定していないのか
- 何が確定事実なのか
- 何を誰と共有するのか
- どの証拠によって記憶を更新するのか
- いつ忘れるのか
- セッションが切れても何を復元するのか
を管理する仕組みです。
だから私たちは、
LLMに「記憶」を追加するのではなく、AIのために「記憶層」を設計する
という方向を考えています。
そして、その記憶は一つではありません。
今必要な記憶
↓
仕事を再開するための記憶
↓
まだ確定していない記憶
↓
確定した事実
↓
長期的な知識
それぞれを分けることで、
AIは「何でも覚える」のではなく、「意味のある形で覚える」
ことができるのではないか。
さらに、
曖昧なものを曖昧なまま保持し、Evidenceによって確定し、確定した知識を長期記憶へ昇格させる。
この循環まで含めて設計したとき、AIのMemoryは単なる履歴保存から、
AI自身が仕事を継続するための基盤
へ変わっていくのではないかと考えています。
AI Memory Research Series
今後は、このMemory Architectureについて、
- Working Memoryの実装
- Session / State Memory
- Impact DBとの統合
- EvidenceによるMemory Resolution
- Memory Router
- Shared Brain
- AgentごとのPrivate Memory
- Memory Permission
- Forgetting / Retention Policy
- VXN Memory Protocol
- Memory Benchmark
などを実装・検証していく予定です。
AIに「記憶」を持たせるだけではなく、
AIが、自分が何を知っていて、何を知らず、何を確定していないのかを管理できるようにする。
そこまで進んで初めて、AIの長期的な知性を支える「記憶層」になるのかもしれません。