AI時代のDBは、vector DBから「memoryの状態遷移管理」へ移っているのではないか

はじめに

最近、AIエージェント向けのデータベースについて考えていると、少し違和感があります。

多くの場合、AI時代のDBというと、まず vector DB が出てきます。

文章を embedding に変換する。
近いベクトルを検索する。
RAGでLLMに渡す。

これは非常に強力です。

ただ、長期的に動くAIエージェントを考えると、vector DBだけでは少し足りない気がします。

なぜなら、エージェントに必要な「記憶」は、単なる検索対象ではないからです。

記憶は増える。
古くなる。
矛盾する。
修正される。
忘れられる。
何度も参照されることで重要度が変わる。

つまり、AIエージェントのメモリは、静的なデータ集合というより、時間とともに変化する状態です。

この記事では、

AIエージェントに必要なのは、vector DBというより、忘却・修正・由来管理を持つ「推論用メモリDB」ではないか

という話を書きます。

vector DBは何を解いていたのか

まず、vector DBはかなり重要です。

従来のDBは、基本的に構造化されたデータを扱います。

id: 1
name: Alice
project: MemoryDB
deadline: 2026-07-01

一方で、LLMが読む情報は自然言語が多いです。

AliceさんはMemoryDBプロジェクトを進めていて、締切は7月1日らしい。

このような非構造データを扱うために、embedding と vector search が便利でした。

ざっくり言うと、vector DBは、

自然言語で書かれた情報を、意味的に近いものとして検索できるようにしたDB

です。

これは「AIが情報を探す」ためにはかなり良い仕組みです。

しかし、ここで問題があります。

vector DBは主に「検索」のための仕組みです。

もちろん、追加・削除・更新はできます。
しかし、それはDB操作としての更新であって、AIの記憶としての更新とは少し違います。

AIの記憶は、単なるrecordではない

たとえば、AIエージェントが以下の会話を記憶しているとします。

3月: プロジェクトAの締切は4月10日
4月: プロジェクトAの締切は4月20日に変更
5月: プロジェクトAは一旦停止

ここでユーザーが、

プロジェクトAの締切っていつ？

と聞いた場合、単純な検索では困ります。

「4月10日」もヒットするかもしれない。
「4月20日」もヒットするかもしれない。
「一旦停止」も関係しているかもしれない。

つまり、問題は「どのrecordが近いか」ではなく、

現在の状態として何が正しいのか

です。

ここが大事です。

AIエージェントのメモリでは、古い情報と新しい情報が同時に存在します。
そのとき必要なのは、単なる検索順位ではなく、

この情報は現在有効なのか
これは過去の情報なのか
何によって更新されたのか
どの情報と矛盾しているのか
なぜ忘れてよいのか

という管理です。

これは、もはや普通のRAGというより、状態管理の問題です。

「Is Agent Memory a Database?」が面白い理由

2026年5月に出た Is Agent Memory a Database? Rethinking Data Foundations for Long-Term AI Agent Memory という論文が、この問題をかなり綺麗に整理しています。

この論文の主張をかなり雑に言うと、

エージェントメモリの正しさは、個々のrecordの正しさではなく、memory stateの軌道の正しさで決まる

という話です。

普通のDBでは、recordが正しいか、transactionが正しいか、query結果が正しいかを考えます。

しかし、エージェントメモリではそれだけでは足りません。

なぜなら、メモリは時間とともに変化するからです。

論文では、既存のメモリシステムの失敗モードとして、だいたい以下のようなものが挙げられています。

1. 無制御にメモリが増える
2. 古い情報が意味的に修正されない
3. 容量都合で重要な情報まで忘れる
4. retrieval が read-only で、読まれても状態が変わらない

これは、かなり実感があります。

特に4つ目が面白いです。

普通のDBでは、readはreadです。
読んでもDBの状態は変わりません。

しかし、人間の記憶っぽく考えると、よく参照される情報は重要度が上がってほしい。
逆に、長く使われない情報は圧縮されたり、奥にしまわれたりしてほしい。

つまり、AIエージェントのmemoryにおいては、

retrieval = read

ではなく、

retrieval = read + state transition

であるべきかもしれません。

ここが、従来のDBとAIメモリDBの大きな違いだと思います。

CRUDではなく、ingestion / revision / forgetting / retrieval

普通のDB操作は、よくCRUDで説明されます。

Create
Read
Update
Delete

しかし、AIエージェントの記憶に対しては、この分け方が少し粗いです。

たとえば、新しい会話を保存する操作は、単なるCreateではありません。
既存の記憶と統合する必要があります。

昔の締切: 4月10日
新しい締切: 4月20日

このとき必要なのは、ただ新しいrecordを追加することではありません。

現在値: 4月20日
過去値: 4月10日
更新理由: ユーザーが4月に変更を伝えた

のように、意味的にrevisionすることです。

また、忘却も単なるDeleteではありません。

完全に消すのか。
圧縮するのか。
低優先度にするのか。
履歴として残すのか。
プライバシー上、本当に消すのか。

これらは全部違います。

そのため、AIエージェントのメモリDBでは、CRUDよりも以下のような操作が自然に見えます。

ingestion   : 新しい情報を既存状態へ統合する
revision    : 矛盾や更新を反映し、意味的に修正する
forgetting  : 重要度・鮮度・方針に応じて圧縮・退避・削除する
retrieval   : 推論に必要な形で取り出し、同時に重要度を更新する

この見方をすると、DBというより「メモリ状態機械」に近くなります。

AIが読みやすいDBとは何か

ここで、自分が以前から考えている「AIが読みやすいDB」という話に繋がります。

人間が読みやすいDBと、AIが読みやすいDBはたぶん違います。

人間にとって読みやすいDBは、表が綺麗で、正規化されていて、検索しやすいものかもしれません。

しかし、AIにとって読みやすいDBは、おそらくそれだけでは足りません。

AIが推論しやすいDBには、少なくとも以下が必要だと思います。

現在値
過去値
更新履歴
由来
矛盾関係
信頼度
重要度
忘却ポリシー
検索された履歴
関連する概念

たとえば、単に

deadline = 2026-07-01

と保存するのではなく、

concept: Project A deadline
current_value: 2026-07-01
previous_values:
  - 2026-06-15
source:
  - user message at ...
confidence: high
status: active
related:
  - Project A
  - submission task
salience: 0.82
forgetting_policy: keep_until_project_closed

のように保存する。

こうすると、LLMは単に近い文章を拾うのではなく、

現在何が有効で、なぜそれが有効なのか

を読みやすくなります。

これは「LLMに渡すcontextを作るDB」というより、

LLMの推論状態を安定させるためのDB

です。

Graph Memory系の流れ

最近のGraph Memory系の研究も、この方向に近いです。

単純なRAGでは、

query
→ 類似chunk検索
→ LLMに渡す
→ answer

という流れになります。

しかし、長期記憶を扱う場合、これでは足りません。

最初に見つかった情報から、別の情報へ辿る必要がある。
途中で不要な経路を切る必要がある。
推論しながら、どの記憶を読むべきかを変える必要がある。

つまり、memoryは静的にretrieveされるものではなく、推論中に再構成されるものだという見方です。

これはかなり重要だと思います。

なぜなら、AIエージェントの記憶は「検索結果のリスト」ではなく、

今の問いに対して、どの記憶をどう組み合わせるべきか

という構成問題だからです。

この発想は、vector DB単体よりも、graph、history、policy、retrieval feedback を組み合わせた設計に向かいます。

ICLDBという考え方

ここからさらに進めると、「ICLDB」という考え方もできそうです。

ICL、つまり In-Context Learning は、LLMに与えた文脈によって振る舞いが変わる現象です。

だとすると、DBの役割は単に情報を保存することではありません。

DBは、

LLMが望ましい推論状態に入るためのcontextを生成する装置

になります。

このとき重要なのは、検索精度だけではありません。

どの順番で情報を渡すか
どの粒度で要約するか
どの矛盾を明示するか
どの履歴を隠すか
どの情報を現在値として扱うか
どの情報を反例として渡すか

が重要になります。

つまり、AI時代のDBは、

保存するDB

から、

推論状態を設計するDB

へ変わっていくのではないか、ということです。

たとえば実装するとしたら

かなり雑ですが、推論用メモリDBを作るなら、こんな構成がありそうです。

MemoryUnit
- id
- topic
- current_summary
- fields
- value_history
- provenance
- confidence
- salience
- valid_from
- valid_to
- status
- related_units
- contradiction_edges
- forgetting_policy
- access_log

操作はこんな感じです。

ingest(input):
    関連するMemoryUnitを探す
    新規作成か既存更新か判断する
    矛盾があれば履歴に残す
    current stateを更新する

revise(unit):
    古い値と新しい値を統合する
    関連unitへ影響を伝播する
    provenanceを保つ

retrieve(query):
    関連unitを探索する
    current valueを優先する
    必要ならhistoryも出す
    読まれたunitのsalienceを更新する

forget():
    salience, age, policyを見て圧縮・退避・削除する

ここで重要なのは、検索アルゴリズムそのものよりも、

状態がどう変わるべきか

です。

この意味で、AI時代のDB設計は、インデックス設計だけでなく、状態遷移設計になっていく気がします。

まとめ

vector DBは、AI時代のDBとして非常に重要です。

ただし、それは主に「意味的に近い情報を探す」ための基盤です。

一方で、長期的に動くAIエージェントには、もう少し強い仕組みが必要になります。

それは、

記憶を追加する
記憶を修正する
記憶を忘れる
記憶を読むことで状態を変える
記憶の由来を残す
記憶の現在性を管理する

という仕組みです。

つまり、AI時代のDBは、

vector DB

から、

memoryの状態遷移管理

へ広がっていくのではないかと思います。

そしてその先には、単なるRAG用DBではなく、

LLMの推論状態を設計するためのICLDB

のようなものが出てくるのではないでしょうか。

個人的には、ここはかなり面白い研究・実装テーマだと思っています。

参考文献

• Is Agent Memory a Database? Rethinking Data Foundations for Long-Term AI Agent Memory, arXiv:2605.26252
• Memory is Reconstructed, Not Retrieved: Graph Memory for LLM Agents, arXiv:2606.06036
• Agent Memory: Characterization and System Implications of Stateful Long-Horizon Workloads, arXiv:2606.06448
• A-MEM: Agentic Memory for LLM Agents, arXiv:2502.12110