エージェント・メモリー: AIに記憶喪失がある理由と修正方法 (2026/02/19)
エージェント・メモリー: AIに記憶喪失がある理由と修正方法 (2026/02/19)
https://medium.com/oracledevs/agent-memory-why-your-ai-has-amnesia-and-how-to-fix-it-2af486c81293
投稿者：Casius Lee
重要なポイント
- 今日のAIエージェントは、会話の合間にすべてを忘れてしまいます。すべてのやり取りはゼロから始まり、あなたが誰なのか、以前に何を話したのかを思い出すことができません。
- エージェントメモリは、コンテキストウィンドウを大きくするものではありません。セッションをまたいで機能する、永続的で進化し続ける状態を指します。
- この分野では、人間の記憶の仕組みに直接対応する 4 つの記憶タイプ (作業記憶、手続き記憶、意味記憶、エピソード記憶) が注目されています。
- エンタープライズ規模のエージェントメモリの構築は、根本的にデータベースの問題です。ベクトル、グラフ、リレーショナルデータ、そしてACIDトランザクションが連携して動作する必要があります。
エージェント メモリとは何ですか? AI エージェントになぜ必要なのですか?
AIカスタマーサービスエージェントの構築に何週間も費やしました。苦情に対応し、返金手続きを行い、時折、適切なタイミングでジョークを飛ばすことさえあります。ところが、翌日、顧客から電話がかかってきたものの、エージェントは相手が誰なのか全く分かりません。昨日の会話は？消えてしまいました。先週2回も言われた好みは？全く思い出せません。すべてのやり取りがゼロから始まるのです。
これはコードのバグではありません。今日のAIエージェントの構築方法における根本的な設計上の問題です。
LangChainは的確に表現しています。「もし、あなたが話したことを全く覚えていない同僚がいて、その情報を何度も繰り返し伝えなければならないとしたらどうでしょう？」同僚のシナリオでは、それは非常にストレスフルなことです。そしてAIアプリケーションにとって、忘れっぽさは致命的な問題です。
Oracleは、AIアプリケーションを構築するお客様へのサポートを継続する中で、この問題に深く取り組んできました。そして、私たちが見つけた解決策は、コンテキストウィンドウを大きくしたり、プロンプトを詳細にしたりすることではなく、適切なメモリ基盤を構築することです。データベースが何十年も提供してきたような基盤です。
エージェントメモリは、システムコンポーネントとインフラストラクチャ層を組み合わせたもので、AIエージェントに会話やセッションを跨いで永続的かつ進化する状態を提供します。エージェントメモリは、エージェントが時間の経過とともに情報を保存、取得、更新、そして消去することを可能にします。具体的には、ユーザーの好みを学習し、過去のインタラクションのコンテキストを保持し、蓄積された経験に基づいて行動を適応させます。エージェントメモリがなければ、すべてのインタラクションはゼロから始まります。
この記事では、エージェントメモリとは何か、その仕組み、その基盤となるフレームワーク、そして本番環境向けに構築するためのガイダンスについて詳しく解説します。初めてのエージェントのプロトタイプを作成する場合でも、数千人のユーザーにスケールさせる場合でも、この記事は正しく構築するために必要な基礎となります。
コンテキストウィンドウを大きくしても解決にならない理由
コンテキストウィンドウの急速な拡大（現在では数十万から数百万トークンに及ぶ）により、業界全体に「これだけの容量があればメモリの問題は事実上解決され、検索ベースのメカニズムは時代遅れになる」という幻想が生まれています。しかし、この思い込みは誤りです。
業界ではこれを「記憶の錯覚」と呼んでいます。プロンプトにトークンを詰め込むことは記憶ではありません。それは付箋紙を大きくしたようなものです。落書きするスペースは増えますが、会話が終わればゴミ箱行きです。記憶とは、メモが残ることを意味します。この区別が重要なのは、次の点です。
コンテキストウィンドウはいっぱいになる前に劣化します。ほとんどのモデルは、宣伝されている上限よりずっと前に機能しなくなります。20万トークンを謳うモデルは、通常13万トークンあたりで信頼性が低下し、徐々に劣化するのではなく、突然パフォーマンスが低下します。
重要性の感覚がない。コンテキストウィンドウはすべてのトークンを平等に扱います。あなたの名前は、3週間前の取るに足らないコメントと同じ重みを持ちます。優先順位付けも、顕著性も、関連性によるフィルタリングもありません。
何も残らない。セッションを閉じると全て消えてしまう。すべての会話はゼロから始まる。
コストは線形に増加します。エージェントの長い寿命にわたって完全なコンテキストを維持するには、すぐにコストがかかります。トークンごとに料金が発生しますが、そのトークンのほとんどは無関係なノイズです。
メモリとは、チャット履歴を保存したり、コンテキストウィンドウにトークンを渡したりするだけではありません。外部システムに保存される永続的な状態を構築し、エージェントが行うあらゆるインタラクションに情報を提供し、たとえ数週間、数ヶ月の間隔を空けても、その状態が進化し続けることを意味します。
早期に対処すべきもう一つの誤解は、RAG（検索拡張生成）がエージェントの記憶であるというものです。RAGは推論時に外部知識をプロンプトに取り込みます。これは、文書から抽出した事実に基づいて応答を裏付けるのに非常に役立ちます。しかし、RAGは根本的に状態を持たないものです。以前のやり取り、ユーザーのID、現在のクエリが過去の会話とどのように関連しているかなど、何も認識しません。記憶は継続性をもたらします。簡単に言えば、RAGはエージェントの回答精度を向上させ、記憶はエージェントの学習と適応を支援します。この両方が必要なのです。
コンセプト：エージェントの記憶のためのメンタルモデル
これらすべてを理解するためのフレームワークをお教えしましょう。これは、あなた自身の脳の働きに直接対応しています。
2023年、プリンストン大学の研究者たちはCoALAフレームワーク（言語エージェントのための認知アーキテクチャ）を発表しました。このフレームワークは、認知科学と1980年代のSOARアーキテクチャに基づいて、4種類の記憶を定義しています。この分野のすべての主要なフレームワークはこの分類に基づいており、「AIエージェントに記憶を追加するにはどのような選択肢があるか」という根本的な問いに答えています。
┌──────────────────┬────────────────────────┬────────────────────────┬────────────────────────┐
│ メモリの種類 │ 人間に相当 │ エージェントの使用 │ 例 │
├──────────────────┼────────────────────────┼──────────────────────────┼──────────────────────────┤
│ ワーキングメモリ │ 脳のスクラッチパッド │ 現在のコンテキスト │ バッファ、スライディング │
│ │ │ 能動的な推論 │ ウィンドウ、要約 │
├──────────────────┼────────────────────────┼──────────────────────────┼──────────────────────────┤
│ 手続き型 │ 筋肉記憶 │ システムプロンプト │ プロンプトテンプレート │
│ │ 決定ロジック │ ツール定義 │
├────────────────────┼────────────────────────┼──────────────────────────┼──────────────────────────┤
│ セマンティック │ 一般知識 │ ユーザーの好み │
抽出された事実を含むベクトルストア │ │ │ │ 類似性検索 │
├──────────────────┼────────────────────────┼──────────────────────────┼──────────────────────────┤
│ エピソード │ 自伝的 │ 過去の行動 │ タイムスタンプ付きログ │
│ │ リコール │ 会話ログ │ メタデータ付き │
└──────────────────┴──────────────────────────┴──────────────────────────┴──────────────────────────┘こう考えてみてください。会議中、あなたの作業記憶は今議論されている内容を記憶しています。手続き記憶は、どのようにメモを取り、いつ発言すべきかを知っています。意味記憶は、サラのチームがメールよりもSlackを好んでいることを思い出させます。エピソード記憶は、前回この機能を提案した際に、副社長が予算の制約で却下したことを思い出します。
エージェントはこれら4つのタイプ全てが連携して機能する必要があります。今日のほとんどのエージェントは、現在のコンテキストウィンドウに収まるだけの作業記憶しか持ちません。これは、毎晩きれいに消されるホワイトボードだけを使って仕事をしようとするようなものです。
リリアン・ウェンの影響力のある公式は、全体像を簡潔に表しています。
エージェント = LLM + メモリ + 計画 + ツールの使用。
彼女の短期記憶はCoALAのワーキングメモリにマッピングされます。彼女の長期記憶は他の3つのタイプを包含します。
LangChain は、メモリ更新に対する 2 つのアプローチを備えた実用的なレイヤーを追加します。
- ホットパスメモリ：エージェントは応答前に明示的に何かを記憶することを決定します。これはChatGPTが行うことです。レイテンシは増加しますが、メモリの即時更新を保証します。
- バックグラウンドメモリ：会話中または会話後に、別のプロセスがメモリを抽出して保存します。遅延は発生しませんが、メモリはすぐには利用できません。
重要な洞察：記憶はアプリケーションに固有のものである。コーディングエージェントがユーザーについて記憶するものは、リサーチエージェントが保存するものとは大きく異なる。
Letta（旧称MemGPT）は、オペレーティングシステムの考え方を取り入れ、全く異なるアプローチを採用しています。コンテキストウィンドウをRAM、外部ストレージをディスクのように扱います。エージェントはこれらの層間でデータをページングし、無限に感じられる「仮想コンテキスト」を作成します。エージェントはツールを用いて自身のメモリを管理し、何を記憶し、何を更新し、何をアーカイブするかを決定します。
プログラムメモリ（開発者が保存内容を決定する）とエージェントメモリ（エージェント自身が決定する）の区別は重要です。この分野は後者へと移行しつつあります。エージェント自身がメモリを管理することで、新しいユースケースごとに開発者の介入を必要とせず、個々のユーザーに適応します。どのメモリ操作がプログラムでどのエージェントがトリガーされるかの判断は必ずしも明確ではなく、特定のユースケースやドメインでは様々なアプローチがうまく機能するのを見てきました。今後の投稿では、メモリエンジニアリングの一般的なパターンと設計原則について解説します。
この記事の冒頭で触れたカスタマーサービスエージェントの例に戻りましょう。カスタマーサービスは、本番環境におけるエージェントの最も一般的なユースケース（LangChainの2025年業界調査によると、導入の26.5% ）であり、4種類の記憶すべてが連携して機能することが求められます。エピソード記憶は過去のチケットややり取りを想起します。意味記憶は顧客の好みやアカウントの詳細を保存します。ワーキングメモリは、実際の会話を追跡します。手続き記憶は、解決ワークフローとエスカレーションルールをコード化します。これら4種類の記憶すべてが、チャットボットが継続的なタスクを効率的に実行し、新しい情報に適応することを可能にします。
現状：フレームワークとオープンソースライブラリ
エージェントメモリでよく使われるライブラリやオープンソースプロジェクトにはどのようなものがありますか？エコシステムは急速に成熟しています。ここでは、今日の開発者がエージェントメモリを構築する方法を形作っているプロジェクトをご紹介します。
┌───────────────────────┬──────────────────────────────────────────┬──────┐
│ プロジェクト │ 機能 │ OSS │
├─────────────────────┼──────────────────────────────────────────┼──────┤
│ LangChain/LangMem/ │ ホット パスと │ はい │
│ LangGraph │ バックグラウンド メモリの抽象化を使用したエージェント オーケストレーション │ │
├─────────────────────┼────────────────────────────────────────────┼──────┤
│ Letta (MemGPT) │ OS 風のメモリ階層。エージェント │ はい │
│ │ ツール呼び出しを介して自身のメモリを自己編集します │ │
├──────────────────────┼──────────────────────────────────────────┼──────┤
│ Zep / Graphiti │ 双一時的
モデリングと 200 ミリ秒未満の検索を備えた一時的知識グラフ │ はい │ │ │ モデリングと 200 ミリ秒未満の検索 │ │
├────────────────────────────────────────────────────┼──────┤
│ Mem0 │ 自動抽出による自己改善メモリ │ はい │
│ │ および競合解決 │ │
├───────────────────────┼──────────────────────────────────────────┼──────┤
│ langchain-oracledb │ Oracle DB 統合: ベクトル ストア、 │ はい │
│ │ ハイブリッド検索、エンタープライズ セキュリティ │ │
└──────────────────────┴────────────────────────────────────────────┴─────┘オーケストレーションライブラリは重要ですが、大規模環境ではストレージバックエンドの方がより重要です。これらのフレームワークのほとんどは、設計上、データベースに依存しません。問題はどのフレームワークを使うかではなく、その基盤となるデータベースです。
エージェントメモリの実際の仕組みを詳しく見る
エージェントメモリの一般的なストレージオプションにはどのようなものがありますか？今日の実稼働システムでは、3つのパラダイムが連携して動作しています。これら3つすべてを理解する必要があります。
意味記憶のためのベクトルストア
これは最も一般的なアプローチです。テキストを埋め込み（使用する埋め込みモデルに応じて通常128～2,048次元）に変換し、ベクターデータベースに保存します。検索は、HNSW（階層的ナビゲート可能なスモールワールド）でインデックス付けされたベクターに対してベクター検索によって行われます。通常、現在のクエリに意味的に最も近いメモリ（データベース内の埋め込み）を見つけます。
高速でシンプルですが、限界があります。ベクトル検索は意味的な類似性をうまく捉えますが、構造的な関係性は捉えられません。
関係記憶のための知識グラフ
ベクトル検索は、ユーザーがコーヒーについて言及したことを推測できます。しかし、特定のお店を好んで利用していること、先週の火曜日に注文したこと、いつもオーツミルクを注文していることは推測できません。こうしたつながり（人、好み、場所、時間、詳細）の連鎖はグラフ問題です。
ナレッジグラフは、事実をエンティティと関係性として保存し、エッジはそれらのつながりを捉えます。バイテンポラルモデリング（イベントが発生した時刻とシステムがイベントを学習した時刻の両方を追跡する）を追加することで、「私たちは何を知っているか？」だけでなく、「どの時点で何を知っていたか？」を問うことができます。
ZepのGraphitiなどのフレームワークはこのパターンを実装しており、 Deep Memory Retrievalベンチマークで94.8%の精度を達成しています。Oracle DatabaseはSQL/PGQを通じてプロパティグラフをネイティブにサポートしているため、グラフクエリはベクター検索やリレーショナルデータと同じエンジン内で実行されます。
事実記憶のための構造化データベース
リレーショナルデータベースは、ユーザープロファイル、アクセス制御、セッションメタデータ、監査ログといった構造化データを保存します。Cognee氏は次のように述べています。「ベクトルは再現率の高いセマンティック候補（似たもの）を提供し、グラフはエンティティや時間を超えた関係性（物事の関連性）をトレースするための構造を提供します。」リレーショナルテーブルは、これら両方を、実稼働システムが要求するトランザクション保証によって支えています。
統合データベースによって状況が変わるのはなぜでしょうか?
多くのチームは、これらを別々のデータベースで統合しています。ベクトルにはPinecone、グラフにはNeo4j、リレーショナルデータにはPostgresといった具合です。3つのセキュリティモデル、3つの障害モード、そして共有トランザクション境界はありません。1つの書き込みが失敗すると、エージェントのメモリは不整合な状態になります。
Oracle の統合データベースは、3 つのパラダイムすべてを単一のエンジン内でネイティブに実行します。
- 埋め込みストレージと類似性検索のためのAI ベクトル検索
- エンティティ関係にわたるプロパティ グラフ クエリ用のSQL/PGQ
- 構造化データ、メタデータ、監査証跡用のリレーショナル テーブル
- 柔軟でスキーマフリーなメモリオブジェクトのためのJSON ドキュメント ストア
これら4つはすべて、同じACIDトランザクション境界とセキュリティモデルを共有しています。行レベルのセキュリティ、暗号化、アクセス制御は、あらゆるデータ型に均一に適用されます。1つのエンジン、1つのトランザクション、1つのセキュリティポリシー。上記の3つのパラダイムは、同じ基盤データに対する3つのビューとなります。
4つの記憶操作
すべてのメモリ システムは、次の 4 つのコア操作に基づいて実行されます。
- 追加: 完全に新しい事実を保存する
- 更新: 新しい情報が既存の記憶を補足または修正したときに、既存の記憶を修正する
- 削除: 新しい情報が記憶と矛盾する場合に記憶を削除する
- スキップ: 情報が重複していたり無関係な場合は何もしない
現代の記憶システムでは、これらの決定を脆弱なif/elseロジックではなく、LLM自体に委譲します。抽出フェーズでは、コンテキストソース（最新のやり取り、ローリングサマリー、最近のメッセージ）を取り込み、LLMを用いて候補となる記憶を抽出します。更新フェーズでは、各新しい事実をベクトルデータベース内の最も類似したエントリと比較し、競合検出を用いて追加、マージ、更新、またはスキップのいずれを行うかを決定します。
検索：エージェントがどのように思い出すか
エージェントが遭遇するデータは異種の性質を持つため、プロダクション システムでは複数の取得アプローチを組み合わせます。
- セマンティック検索：意味に基づくマッチングのためのベクトル類似度（コサイン距離）
- 時間的検索: 双一時的モデルにより、ポイントインタイムのクエリが可能になります (「ユーザーは昨年 3 月に何を好みましたか?」)
- グラフトラバーサル: 複雑な推論のための知識グラフエッジをまたぐマルチホップクエリ
- ハイブリッド検索: キーワード（全文）検索とセマンティック（ベクトル）検索を単一のクエリで組み合わせたもの。これは、名前、日付、プロジェクトコードなどの特定の事実と概念的に関連する記憶を検索するために重要です。
忘れること：過小評価されている作戦
効果的な忘却は、ベクトル関連度スコアに減衰関数を適用することで実現できます。ベクトル検索の結果を分析することで、古くて参照されていない埋め込みはエージェントの注意から自然に消えていきます。これは、人間の生物学的記憶の減衰パターンを模倣したものです。データベースでは、これは単純明快です。最新性加重スコアリング関数は、意味的類似性に、最終アクセスからの時間に基づく指数関数的減衰係数を乗じます。その結果、最近思い出されていない記憶は、人間の記憶と同様に、徐々に重要性を失っていきます。
一部のシステムでは全く異なるアプローチが採用されています。古いデータは無効化されますが、破棄されることはなく、監査証跡の履歴の正確性は維持されます。適切な戦略はユースケースによって異なりますが、どちらも基本的にはデータベース操作です。
企業の現実：大規模に変化するもの
ここで、デモと本番環境の間に大きな隔たりが生じます。
KPMGが10億ドル以上の収益を持つ企業の経営幹部130名を対象に実施したパルスサーベイでは、2四半期連続で65%がエージェントシステムの複雑さを最大の障壁として挙げていることが明らかになりました。エージェント導入率は2025年第1四半期の11%から第4四半期には26%へと倍増していますが、それでも大企業の4分の3が導入に至っていないことになります。マッキンゼーはさらに厳しい状況を示しており、自社のAI導入が「成熟している」と回答したリーダーはわずか1%にとどまっています。
大規模に発生する問題はデータベースの問題です。これまでずっとデータベースの問題でした。
セキュリティと分離。メモリはユーザー、チーム、組織ごとにスコープを設定する必要があります。メモリポイズニングは現実的な攻撃ベクトルです。攻撃者はエージェントのメモリに悪意のある情報を注入し、将来の意思決定を妨害することができます。名前空間レベルの分離だけでなく、行レベルのセキュリティが必要です。
マルチテナント。複数の組織にサービスを提供するエージェントは、完全なデータ分離を必要とします。ベクター型データベースの多くは、名前空間レベルの分離を提供しています。これは、規制の厳しい業界で求められる行レベルのセキュリティとは異なります。OracleのネイティブPDB/CDBアーキテクチャは、マルチテナントの分離を本質的に実現します。
コンプライアンスはますます複雑化しています。GDPRの「忘れられる権利」は、明示的なエージェントのメモリストアに適用されます。しかし、EU AI法（2026年8月から完全適用）では、高リスクAIシステムに対して10年間の監査証跡の保存が義務付けられています。この緊張関係について考えてみてください。10年間の監査履歴を維持しながら、要求に応じて個人データを削除する必要があります。これには高度なアーキテクチャが求められますが、ほとんどのスタートアップ企業はこれに取り組み始めたばかりです。
ACIDトランザクションは重要です。エージェントのメモリ操作は、多くの場合、複数のデータ型を同時に操作します。ベクトル埋め込みの更新、グラフ関係の変更、リレーショナルメタデータの変更は、すべて成功するか、すべて失敗するかのどちらかです。アトミック性がなければ、部分的なメモリ更新によってエージェントは不整合な状態になります。
これらは理論的な懸念ではありません。企業の4分の3が依然としてパイロット段階に留まっている理由です。
実装：LangChainとOracle AIデータベースを使用したエージェントメモリの構築
実際に進めていきましょう。オーケストレーションフレームワークとしてLangChainを使用し、メモリバックエンドとしてlangchain-oracledbパッケージを使用したOracle AI Databaseを使用します。ゼロから実用的なメモリシステムを構築するまでのスピードをご紹介します。
pip install langchain-oracledb oracledb langchain-core接続してベクターストアを作成する
Oracle がサポートする本番環境対応のベクター ストアをセットアップするには、次の操作を行うだけです。
import oracledb
from langchain_oracledb.vectorstores import OracleVS
# Create a connection pool (production-ready)
pool = oracledb.create_pool(
user="agent_user", password="password",
dsn="hostname:port/service",
min=2, max=10, increment=1
)
# Initialise vector store for semantic memory
semantic_memory = OracleVS(
client=pool.acquire(),
embedding_function=embeddings, # any LangChain-compatible embeddings
table_name="AGENT_SEMANTIC_MEMORY",
distance_strategy=DistanceStrategy.COSINE,
)これがセマンティックメモリストアです。Oracleはベクトルインデックス、ACIDトランザクション、そしてセキュリティをネイティブに処理します。別途ベクトルデータベースは必要ありません。
記憶を保存し、取り出す
コアパターンはシンプルです。メタデータを使用してメモリを書き込み、類似性検索を使用してそれを取得します。
# Store a memory
semantic_memory.add_texts(
texts=["User prefers dark mode and concise responses."],
metadatas=[{"user_id": "user_123", "memory_type": "preference"}]
)
# Retrieve relevant memories
results = semantic_memory.similarity_search(
"What are this user's preferences?",
k=5,
filter={"user_id": "user_123"}
)
for doc in results:
print(doc.page_content)ここから、同じ Oracle インスタンスの下で、各メモリ タイプ (セマンティック、エピソード、プロシージャ) ごとに個別のベクター ストアを作成し、すべて同じセキュリティ ポリシーとトランザクション保証を共有できます。
さらに深く：完全なメモリエンジニアリングノートブック
上記のスニペットは構成要素を示していますが、本番環境のエージェントメモリシステムには、さらに多くの要素が必要です。この記事で解説したアーキテクチャ全体を実装した、実行可能な完全なノートブックをOracle AI Developer Hubで公開しました。このノートブックは、それぞれOracleがサポートする6つの異なるメモリタイプを備えた完全なメモリマネージャーを構築します。
┌────────────────┬──────────────────────────────┬────────────────────────┐
│ メモリタイプ │ 目的 │ ストレージ │
├────────────────┼────────────────────────────────┼────────────────────────┤
│ 会話型 │ スレッドごとのチャット履歴 │ SQL テーブル │
├────────────────┼────────────────────────────────┼────────────────────────┤
│ ナレッジベース │ 検索可能なドキュメントと事実 │ SQL + ベクトル │
├────────────────┼────────────────────────────────┼────────────────────────┤
│ ワークフロー │ 学習したアクションパターン │ SQL + Vector │
├──────────────────┼────────────────────────────────┼────────────────────────┤
│ ツールボックス │ 動的ツール定義 │ SQL + Vector │
├────────────────┼────────────────────────────────┼────────────────────────┤
│ エンティティ │ 人、場所、システム │ SQL + Vector │
├────────────────┼────────────────────────────────┼────────────────────────┤
│ 概要 │ 圧縮コンテキスト │ SQL + ベクトル │
└────────────────┴────────────────────────────────┴──────────────────────────┘また、コンテキスト エンジニアリング(コンテキスト ウィンドウの使用状況の監視、しきい値での自動要約、ジャストインタイムの取得)、セマンティック ツール検出(数百のツールに拡張しながら関連するツールのみを LLM に渡す)、すべてを結び付ける完全なエージェント ループについても説明します。
展望：今後の動向
以下は、私が考えている今後の展開と、まだ検討中のところです。
睡眠時間計算はゲームを変えるでしょう。アイデアはシンプルです。アイドル時間に「考える」（記憶の再構成、統合、洗練）エージェントは、クエリ時にパフォーマンスが向上し、コストも削減されます。OpenAIの内部データエージェントは、既にこのパターンを本番環境で実行しています。エンジニアリングチームは、テーブルの使用状況、人間による注釈、コード由来のエンリッチメントを単一の正規化された表現に集約し、それを検索用の埋め込みデータに変換する、毎日のオフラインパイプラインを説明しています。クエリ時には、エージェントは生のメタデータをスキャンするのではなく、最も関連性の高いコンテキストのみを取得します。
Lettaの研究はそれを数値的に証明しています。このアプローチを採用したエージェントは、クエリあたりの精度が18%向上し、コストは2.5倍削減されます。バックグラウンドで動作する「考えるエージェント」と、リアルタイムのインタラクションを処理する「サービングエージェント」の間に明確な分離が見られるようになるでしょう。これは、データベースが長年サポートしてきたパターン、つまりリアルタイムクエリと並行してバッチ処理を実行するというものです。
メモリは、単純なRAG実装を拡張します。その範囲は既に移行しつつあります。従来のRAGからエージェント型RAG、そして完全なメモリシステムへと移行しています。VentureBeatは、2026年にはエージェント型AIにおいてコンテキストメモリがRAGを上回ると予測しています。私もその通りだと思います。RAGはドキュメントを検索します。メモリはコンテキストを理解します。勝利するエージェントは両方を行いますが、メモリが差別化要因となるでしょう。
コンバージドデータベースはもはや譲れないものとなるでしょう。エージェントのメモリには、ベクトル、グラフ、リレーショナルデータ、そして時間的コンテキストが連携して動作する必要があります。それぞれのタイプごとに別々のデータベースをつなぎ合わせると、セキュリティ上の欠陥や一貫性の問題を抱えた脆弱なシステムが生まれます。この統合がどの程度の速さで実現するかはまだ正確にはわかりませんが、方向性は明確です。
未解決の問題が一つ残っています。それは、企業がパイロットから本番環境への移行をどの程度のペースで行うかということです。現時点では、この技術は明らかに成熟段階にあり、アーキテクチャ設計パターンは実証済みで、実戦でテストされています。一方、ガバナンス、インフラの近代化、部門横断的な連携を含む組織の準備は、根本的に異なる課題です。
明らかなのは、エージェントメモリは根本的にデータベースの問題であるということです。そして、ミッションクリティカルなワークロード向けのデータベース構築こそが、Oracleが50年近く取り組んできたことなのです。
よくある質問
AI システムで使用されるエージェント メモリの主な種類は何ですか?
この分野は、認知科学から導き出された 4 つのタイプに収束しています。
- 作業記憶（現在の会話の文脈）
- 手続き記憶（システムプロンプトと意思決定ロジック）
- 意味記憶（蓄積された事実とユーザーの好み）
- エピソード記憶（過去のやりとりのログと経験）。
すべての主要なフレームワークはこの分類法に基づいて構築されており、2023 年にプリンストン大学の CoALA フレームワークで初めて正式化されました。
AI エージェントにメモリを追加するにはどのようなオプションがありますか?
大きく分けて 2 つのアプローチがあります。
- プログラムによるメモリは、開発者が何を保存および取得するかを定義する場所です。
- エージェントメモリとは、エージェント自身がツール呼び出しを用いて、何を記憶し、更新し、何を破棄するかを決定するメモリです。Letta（旧称MemGPT）やLangChainのLangMem SDKなどのフレームワークは、両方のパターンをサポートしています。
この分野は、エージェントが開発者の介入なしに新しいユースケースごとに独自の状態を管理するエージェントメモリへと移行しています。
共通エージェント メモリ ストレージ オプションとは何ですか?
生産システムでは通常、次の 3 つのパラダイムが組み合わされます。
- 意味に基づく検索のためのベクトルストア（埋め込みの保存とコサイン類似度によるクエリ）
- 関係性を考慮した検索のための知識グラフ（エンティティ、エッジ、およびバイテンポラルモデリング）
- ユーザー プロファイル、アクセス制御、監査ログなどのトランザクション データ用の構造化リレーショナル データベース。
ほとんどのチームはこれらを個別のデータベースで統合しますが、Oracle などの統合データベースでは 3 つすべてを 1 つのエンジンでネイティブに実行できます。
AI エージェントが記憶を忘れたり選択的に消去したりできるようにする技術は何ですか?
最も一般的なアプローチは、ベクトル関連度スコアに減衰関数を適用するものです。これは、最新性加重スコアリング関数が、意味的類似度に、最終アクセスからの時間に基づく指数減衰係数を乗算するものです。最近思い出されていない記憶は、生物学的な記憶の減衰を模倣し、徐々に重要性を失います。別のアプローチでは、古い事実を破棄することなく無効化することで、監査証跡の履歴的正確性を維持しながら、能動的な検索からは除外します。
短期エージェントメモリと長期エージェントメモリの違いは何ですか?
- 短期記憶（ワーキングメモリとも呼ばれる）は、現在のコンテキストウィンドウ、つまりエージェントがこの会話の中で積極的に推論している内容を指します。これは高速ですが、不安定なため、セッションを閉じると失われます。
- 長期記憶は、セッションを超えて持続するすべてのものを包含します。意味記憶（事実や好み）、エピソード記憶（過去のやり取り）、手続き記憶（学習した行動や意思決定の論理）などです。長期記憶には、外部の保存と検索のための基盤が必要です。
エージェントメモリによく使用されるライブラリは何ですか?
エコシステムには以下が含まれます。
- LangChain/LangMem (抽出と統合を備えたホットパスとバックグラウンドメモリ)
- Letta/MemGPT（エージェントがツール呼び出しを介してメモリを自己編集するOSにインスパイアされたメモリ階層）
- Zep/Graphiti (200 ミリ秒未満の検索を実現する時間的知識グラフ)
- Mem0 (自動競合解決機能を備えた自己改善メモリ)
- langchain-oracledb (エンタープライズ グレードのセキュリティを備えたベクター ストア、ハイブリッド検索、埋め込みのための Oracle AI データベース統合)。
ベクトル埋め込みを保存およびクエリするにはどうすればよいですか?
コアパターンは単純明快です。テキストを埋め込み（通常128～2,048次元）に変換し、ベクトル対応データベースに保存し、コサイン類似度検索を使用して取得します。langchain-oracledbとOracle AI Databaseでは、ベクトルストアを初期化し、メタデータ（ユーザーIDやメモリタイプなど）を含むテキストを追加し、メタデータでフィルタリングされた similarity_search() でクエリを実行します。Oracleは、ベクトル索引付け、ACIDトランザクション、セキュリティをネイティブに処理します。
企業向けにベクトル検索機能を提供しているデータベースはどれですか?
現在、多くのデータベースがベクトル検索をサポートしていますが、エンタープライズ要件は基本的な類似性クエリにとどまりません。ベクトル操作に加えて、ACIDトランザクション、行レベルのセキュリティ、マルチテナンシー、コンプライアンス機能も必要です。Oracle AI Databaseは、統合アーキテクチャ内でネイティブのAIベクトル検索を提供します。つまり、ベクトルクエリはリレーショナル表、プロパティグラフ（SQL/PGQ）、JSONドキュメントストアと同じエンジンで実行され、すべてが単一のトランザクション境界とセキュリティモデルを共有します。
コメント
コメントを投稿