AI エージェントとエージェント型システムにおけるメモリへの注目

最新の AI システムにおいてエージェントのメモリが重要な理由

人工知能（AI）がアプリケーション開発の最前線に立つ中、ソフトウェア開発は著しい変革を遂げました。埋め込み LLM で構築されたシステムは単にデータを処理するわけではありません。その機能とパフォーマンスは、コンテキスト情報、モデルの推論能力、パラメトリックな知識に大きく依存しています。

狭義で反応型のアーキテクチャから、マルチモーダル入力を処理し、複雑な推論を示し、目標指向の動作を行う高度な AI システムへの進化が見られます。アプリケーションには現在、高度な自然言語理解、複雑な問題解決ワークフロー、そしてわずか数年前には不可能だった複数ステップのタスク実行が組み込まれています。

これらの高度な機能にもかかわらず、アプリケーションは基本的にステートレスのままです。インタラクションをまたいで持続するメモリがないため、前のエンゲージメントから知識を蓄積できず、各リクエストを分離して加工する必要があります。

エージェントのメモリがない場合、いくつかの重大な制限があります。

• 会話の継続性を維持できない - 以前の対話に基づいて構築したり、以前の対話を参照したりできない
• 行動適応なし - ユーザーフィードバックから学んだり、アプローチを調整したりできない
• 永続的な目標の欠如 - セッション間で目標を維持できない
• パーソナライズの欠如 - ユーザー固有の嗜好や理解を開発できない
  

研究はこの制限を裏付けています。Microsoft と Salesforce の調査「LLMs Get Lost in Multi-Turn Conversation」では、LLM は拡張された会話でパフォーマンスが大幅に低下することがわかりました。これは主に、LLM が早い段階で時期尚早な仮定を行い、それらの仮定が誤りであることが判明したときに修正できないためです。これは、先に述べた会話の継続性の問題を直接的に示しています。

この研究は、LLM が特に「複数ターンに分散した情報」に苦戦することを示しており、コンテキスト情報を効果的に統合、整理、抽出できるメモリシステムが不可欠であることを直接裏付けています。LLM が文脈を見失った場合に新しい会話を開始する、または再試行前に情報を手動で統合するといった本論文で提案された回避策は、適切に設計されたメモリシステムによって解消されるべき、まさにその種の信頼性の問題を表しています。この研究は、高度なメモリアーキテクチャが本番環境の AI エージェントにとって重要である理由を明らかにしています。解決策は、これらの制約のそれぞれに直接対処する包括的なエージェント型メモリシステムを実装することにあります。

さまざまなフォームファクタでよりパーソナライズされた AI システムを構築するにつれて、エージェント型メモリが重要になります。ユーザーの記憶を維持する能力により、以前の各対話を通じて適応型学習が可能になり、エージェントは個々の嗜好、コミュニケーションスタイル、行動パターンを理解できるようになります。過去の会話から得られるデータへのアクセスがなければ、どんなに高度なエージェントでも、ユーザーが AI システムに期待するパーソナライズされた体験を提供できません。

データ取得はエージェントメモリのアーキテクチャにおける基本的な要素ですが、その実装は単純なデータベースクエリをはるかに超えます。効果的なデータ取得システムは、膨大なユーザーメモリと過去のデータの保存場所から、関連するコンテキストをインテリジェントに抽出する必要があります。これには、前の会話のどの要素が現在のインタラクションに最も関連するコンテキストを提供するかを特定できる高度なアルゴリズムが必要です。これにより、時間の経過とともに蓄積される真の適応型学習が可能になります。

これらの高度なシステムに必要なのは、従来の意味でのデータだけではなく、人間の認知プロセスを模倣する、より高度な情報の検索、組織化、保持の形態、すなわち現在ではエージェントメモリとして認識されているものです。これは、ステートレスアプリケーションから、各インタラクションを通じて学習、適応、進化できる真にインテリジェントなエージェントへの根本的な転換を表しています。

データはいつメモリになるのか

AI アプリケーション開発、特にエージェントエンジニアリングでは、「データ」と「メモリ」が同じ意味で使用されることがよくあります。しかし、AI エージェントを効果的に構築するには、両者の概念的な違いを理解することが不可欠です。メモリはデータそのものであるため、単にデータと呼んでも差し支えありません。

これに関連して、データは、未加工の入力を段階的に機能的なメモリ単位へと変換する5段階の変換パイプラインを通じてメモリになります。

メモリユニットは、情報だけでなく、エージェントの推論に役立つメタデータや関係も保持する構造化コンテナとして理解できます。すべての情報を平等にアクセス可能で静的であると見なす従来のデータストレージとは異なり、メモリユニットには、一時的なコンテキスト（情報がいつ学習されたか）、強度インジケーター（情報の関連性や信頼性）、連想リンク（他のメモリとの接続方法）、セマンティックコンテキストデータ（取り込まれた意味）、取得メタデータ（どのように、いつアクセスすべきか）などの属性が含まれます。さまざまなメモリタイプのメモリユニットの例については、このドキュメントの後半のセクションを参照してください。

メモリユニットはまた、メモリブロックとも同義で、これはエージェントのメモリシステム内の単一の構造化情報の断片を指すもので、ストレージ、検索、更新機能などの基本的な操作をサポートしつつ、現在のメモリユニット/ブロックのコンテキスト関係を他のメモリコンポーネントと保持する別の用語です。

より広く言えば、メモリユニットはデータだけでなく、インテリジェントな推論に不可欠な認知属性とメタデータをカプセル化します。eコマース Web サイトのカスタマーチャットボットを例に、データをメモリユニットに変換するステージを理解します。

• アグリゲーション：カスタマーのチャット入力、注文データベースのレコード、製品カタログの情報、以前の会話の履歴など、さまざまなソースからデータを収集します。この時点で、すべての情報は未加工データとして分類されます。
• エンコード：データを処理可能な形式に変換すること。チャットボットは、テキストメッセージをセマンティックな意味を捉えるベクトル埋め込みに変換するとともに、タイムスタンプや意図分類などのコンテキストメタデータを追加します。
• ストレージ：データとメモリの境界が生じる、最適化されたレイヤーにエンコードされたデータを永続化すること。情報のモデル化と保存の方法は、エージェントのコンテキストウィンドウ内での使用に直接影響します。ここで、AI エージェントおよびエージェント型システムのメモリプロバイダーとしての MongoDB の役割が明らかになります。MongoDB は、短期の会話コンテキスト、中期のインタラクションパターン、長期の行動データを単一のプラットフォームで取り扱うことができ、個別の専用データベースを維持する際のスケーラビリティの問題や技術の乱立を回避する統合データベースシステムです。この統合アプローチにより、本番環境の AI システムに不可欠なセキュリティ保証を提供しながら、階層型メモリアーキテクチャを構築します。
• 整理：モデリング、インデックスの作成、関係の設計に基づいたデータ構造化。会話履歴は時系列で整理され、製品情報はネストされたドキュメントで階層的に構造化され、複数のディメンションで製品注文データにインデックスが作成されます。
• 検索：高度なメモリ操作を通じて情報が実用的なメモリとなる、最も重要なステージです。 このチャットボットは、現代の AI アプリケーションに不可欠な中核的な検索手法、すなわち完全一致のための従来のテキスト検索、セマンティック類似性のためのベクトル検索、複雑な関係のためのグラフトラバーサルを採用しています。

実質的に、データは、受動的な情報から、抽出してエージェントの動作や推論に役立てることができる、能動的で意図的に永続化されたコンポーネントに移行するときに、メモリになります。この変換は、ストレージの時点で行われます。そこでは、時間をかけて適応と一貫したやり取りを可能にすることを目的として、データが収集・保存されます。

このデータからメモリへの変換を理解することで、特に AI エージェント内でメモリがどのように機能するかを検討するための基盤が得られます。情報がメモリになる仕組みの一般的な原則を見てきましたが、AI エージェントにおけるメモリシステムの実用的な実装には、より正確な定義とアーキテクチャ上の考慮事項が必要です。

エージェントメモリとは？

今日の AI アプリケーションでメモリを探索する際、LLM メモリ、エージェントメモリ、AI メモリといった用語によく遭遇します。その違いを理解することが重要です。

LLM メモリとは、大規模言語モデル自体の中にキャプチャされた情報と知識を指します。これは2つのプライマリレイヤーに存在します。

1. パラメトリックメモリ（重みとパラメーター）：事前学習、教師ありファインチューニング、アラインメント訓練（RLHF と指示チューニングを含む）などの訓練フェーズでモデルのネットワークパラメーターにエンコードされる知識。この形式のメモリは推論中は静的なままですが、ファインチューニングや継続的な事前学習などの追加の訓練手順によってアップデートできます。
2. コンテキストメモリ（コンテキストウィンドウ）：推論中にモデルがアクセスできる一時的な情報。これには、トークン制限内の現在の入力と会話履歴が含まれます。この情報は現在のセッション内でのみ保持され、セッションが終了したとき、またはコンテキストウィンドウの制約のために古いトークンが切り捨てられたときに失われます（外部に保持されている場合を除く）。

重要なのは、LLM メモリはエージェントメモリそのものではなく、その重要な構成要素であることです。

LLM は、より広範な AI エージェントのコンポーネントであり、認知エンジンです。LLM メモリの制限（制限されたコンテキストウィンドウやステートレス推論など）があるため、エージェントが真の連続性、適応性、そして本質的な学習を実現するには、より堅牢で永続的なメモリシステムが必要です。

ここで外部メモリが不可欠になります。最も単純な形では、外部メモリとは、AI エンジニアが RAG アプリケーションやパイプラインを実装する際に活用するものです。通常は、LLM の外部にあるデータベースから情報を取得し、推論を実行する前にユーザープロンプトと連結します。しかし、真にインテリジェントなエージェントを実現するには、基本的な検索をはるかに超え、真の学習と適応を可能にするメモリシステムが必要です。

ここで、AI エージェントそのものの定義について説明します。AI エージェントの定義をめぐっては議論がありますが、AI エージェントとは、複雑な問題解決の領域に踏み出す前に不可欠な機能を備える必要がある情報探索者であるという点では、合意が得られています。

AI エージェントを、その環境を認識し、以下の4つの中核的な能力を備えた計算エンティティとして定義します。

1. LLM を介した認知能力
2. ツールの使用によるアクション
3. 短期および長期にわたって情報を保持するためのメモリ
4. マルチモーダル入力による認識

これらの機能は、エージェントが実際の課題解決という複雑な状況を効果的に乗り切るために、一貫性を持って機能する必要があります。私たちは、エージェントが意味のある価値を提供するためには、長期メモリが不可欠であるという強い確信を持ち続けています。拡張メモリを持たないエージェントは単なる反射的エージェントであり、以前の反復やセッションから学習することなく、現在の入力にのみ反応します。

したがって、エージェントメモリを、LLM のメモリと、知識の蓄積および行動の適応を可能にする外部メモリマネジメントシステムの両方として定義した先ほどの定義に戻ると、この定義が、真の AI エージェントをステートレスなアプリケーションと区別する本質的な機能を包含していることがわかります。

エージェントメモリは、信頼性が高く、信憑性が高く、有能なエージェントを構築するために必要なコアコンポーネントです。

• 高い信頼性：正確な履歴コンテキストへの一貫したアクセスを通じて。
• 高い信憑性：ユーザーの信頼を築く、一貫した信頼性の高いインタラクションを通じて。
• 有能：タスクを完了するために、蓄積された知識とリソースを活用する能力を通じて。

LLM のコンテキストウィンドウが有限である限り、インテリジェントな外部メモリシステム（LLM の外脳）の開発は、研究の重要な最前線であり続け、次世代の AI システムの中核にメモリを位置付けます。

「AI メモリ」と「エージェントメモリ」の互換性は、ソフトウェアアーキテクチャの概念における根本的な変化を反映しています。インテリジェントソフトウェアの支配的なフォームファクタは主にエージェントベースになるという現実が業界でますます受け入れられるようになり、AI システムとエージェントシステムの区別は大部分がセマンティックなものになっています。

従来のソフトウェアアプリケーションは、推論、計画、複雑なワークフローの実行が可能な自律的なエンティティへと進化しており、実質的にデフォルトでエージェントとなりつつあります。この変革は、AI メモリシステムについて議論する場合、本質的にはエージェントメモリシステムについて議論していることを意味します。なぜなら、将来の AI アプリケーションは、受動的なツールとしてではなく、主にインテリジェントなエージェントとして動作するようになるからです。

これらの用語の収束は、単なる言語的な進化ではなく、ユーザーの目的達成に向けて、思考し、記憶し、行動する自律性をますます高めるソフトウェアへの根本的な転換を示しています。

AI エージェントにおける主要なメモリの種類

エージェントメモリの定義を確立し、LLM メモリと区別しつつ、AI メモリとの互換性を指摘した上で、エージェントメモリシステムを構成する主要なメモリの種類を検討していきます。

LLM のパフォーマンスは通常、コンテキストウィンドウ内のコンテンツ量が増加するにつれて低下します。研究によると、長いコンテキストの中間付近に配置された情報は抽出が特に困難であることがわかっています。これは、注意メカニズムが、広範な入力の奥深くに埋もれた関連トークンに優先順位を付け、焦点を維持するのに苦労するためです。この「Lost in the Middle」問題は、検索精度の低下とパフォーマンスの弱体化につながります。

MongoDB のチーフ AI サイエンティストである Tengyu Ma 氏は、これをよくライブラリに例えます。司書に適切な本を示してもらいたいからといって、その図書館に存在するすべての本の目次を把握していることを期待することはないはずです。

同様に、司書が情報を効率的に管理し、検索するためにカタログ、インデックス、参照ガイドを利用するように、効果的なエージェントの設計とエンジニアリングには、さまざまな種類のメモリを理解することが不可欠です。エージェント型システムにおけるメモリは、時間的特性（どのくらい持続するか）と機能的特性（何のためにあるか）によって区別され、各タイプは意思決定と知識の保持において特定の役割を果たします。

時間的な区別が単純なエントリーポイントとなります。

• 短期メモリ（STM） - アクティブな処理中に即座に使用するために保持される情報。例としては、作業メモリ、セマンティックキャッシュ、一時ファイルシステムなどがあります。
• 長期メモリ（LTM）- 長期間持続的に保存され、将来取得される情報。保存された会話履歴、エンティティメモリ、ナレッジベースなどがあります。

短期メモリの機能形式

短期メモリは、現在処理中または最近アクセスした情報の一時的なストレージとして機能します。短期間メモリ内のメモリユニットは、ユースケースや実装要件、アプリケーションモードによって数秒から数日と寿命が限られています。作業メモリと短期メモリは文献ではしばしば同じ意味で使われますが、明確に区別してみましょう。作業メモリは、タスク実行中に情報を能動的に操作するために設計された短期メモリの特殊な機能的サブセットを指すのに対し、短期メモリはさまざまな運用コンテキストにおける一時的な情報保持という、より広いカテゴリーを包含します。

作業メモリ

作業メモリは、タスク中のアクティブな情報操作のためのエージェントの「スクラッチパッド」と捉えることができます。これは、LLM のコンテキストウィンドウ内のパーティション化された領域、またはセッション中のみ存在する一時ファイルであり、チャット履歴を維持し、会話の進行に合わせてリアルタイムのメモリ操作でメモリブロックをアップデートできるようにします。一部の技術文献では、作業メモリはアクティブメモリとも呼ばれます。

MemGPT のような研究の取り組みでは、「作業コンテキスト」を実装して、このアクティブなワークスペースを体系的に管理します。たとえば、市場トレンドを分析するリサーチエージェントは、ワーキングメモリを使用して、検索結果を保持し、企業を識別し、生成しているレポートのメモを合成します。これにより、すぐに利用可能な情報に基づいたリアルタイムの意思決定が可能になります。さらに、外部メモリシステムがない場合、LLM のワーキングメモリはコンテキストウィンドウに実質的に制限されます。したがって、AI アプリケーションで見られるワーキングメモリの主なタイプは、セッションベース、一時ファイルシステム、LLM コンテキストウィンドウ依存です。

セマンティックキャッシュ

セマンティックキャッシュは、最近のプロンプトとそれに対応する LLM 応答を保存します。類似したクエリが到着すると、システムは再処理する代わりにキャッシュされた応答を抽出するため、時間と計算コストが節約されます。単なるキーワードの一致ではなく、ベクトル類似性を使用して、クエリのセマンティックな意味と一致します。パスワードリセットを担当するカスタマーサポートボットは、セマンティックキャッシュを使って「パスワードを忘れました」「ログインを思い出せません」「アカウントアクセスをリセットする必要があります」といった数十通りの異なる表現の同じ質問に即座に回答します。事前計算された応答を即座に抽出する動作は、心理学者のダニエル・カーネマンが『ファスト＆スロー』で説明している「システム1」思考（意識的な推論なしに即座に応答を提供する、高速で自動的、かつ直感的な認知プロセス）を反映しています。

実際のシナリオにおけるセマンティックキャッシュは、埋め込みモデルのセマンティック理解機能を活用して、よりインテリジェントで効果的なメモリシステムを作成することで、従来のキーワードベースのキャッシュシステムを大きく進化させます。MongoDB Atlas と LangChain を活用したセマンティックキャッシュの実装についてはこちらをご覧ください。以前には、Cisco のエージェントエンジニアとも対談し、MongoDB とセマンティックキャッシュを使用して本番環境向けのチャットボットとエージェント型プラットフォームをどのようにビルドしたかを議論しました。

長期メモリの機能形式

長期メモリはエージェントの基盤となるナレッジベースであり、長期間にわたる継続性と学習を可能にします。長期メモリには複数の機能的な形式があり、それぞれに固有のストレージおよび取得機能が求められます。MongoDB のような統合データプラットフォームは、セマンティックメモリのためのベクトル検索から連想メモリのためのグラフトラバーサルまでさまざまなLTMタイプの多様な要件を単一のシステム内で取り扱えるため、この場合に有利です。これにより、複雑性を軽減し、技術スタックの乱立を防止できます。

エピソード記憶

エピソード記憶は、特定のイベントやインタラクションに関するエージェントの記録であり、人間の自伝的記憶に相当します。会話履歴、主要なイベントの要約、またはメタデータ（タイムスタンプ、参加者）が付加された個別の出来事を保存します。カスタマーサービスエージェントは、エピソード記憶を使用して特定のユーザーの過去のサポートチケットを想起し、関連する事実にアクセスして、パーソナライズされ文脈を考慮したサービスを提供します。エピソード記憶の一般的なタイプには、会話タイプと要約タイプがあり、これらは観察とも呼ばれます。

• 会話メモリ：チャット履歴の保存、発話者ターンのある完全な会話トランスクリプトの維持、個別のメモリブロックとして保存されるコンテキストのメタデータに特化したエピソード記憶のサブセット。これにより、エージェントは会話の一貫性を維持し、以前の議論を参照し、特定のユーザーとの過去のやり取りパターンに基づいてコミュニケーションスタイルを適応させることができます。システムは新しい対話が発生するたびにメモリ操作を継続的に実行してメモリブロックをアップデートし、チャット履歴が常に最新の状態であり、コンテキストに関連していることを保証します。

• 要約メモリ：長い対話やドキュメントを圧縮して表現したもので、重要な洞察を維持しながら、ストレージと検索のオーバーヘッドを削減します。要約メモリは、重要な事実、決定、結果をキャプチャした完全なトランスクリプトの抽出バージョンを保持するため、エージェントは過去の対話の要点を、履歴レコード全体を処理することなく迅速に参照できます。

エージェントのエピソード記憶（会話型メモリと要約に対応）は、次のように機能します。システムは、エージェントと人間（またはツールやピアエージェントなどの他のワークフローエンティティ）との間の対話（ターンバイターン形式）を記録します。継続中の会話は定期的に圧縮されて簡潔な要約になり、専用の要約保存場所に保存されます。要約は、コンテキストウィンドウのトークン制限のしきい値、重要度のヒューリスティック、スケジュールによって起動できます。また、エージェントが独自の判断で呼び出せるツールとして公開することもできます。これは、入力を加工し、それを推論し、現在のコンテキストと環境に存在するシグナルに基づいて行動する LLM の能力を活用します。今後の記事では、要約手法や推奨されるベストプラクティスについて、より詳しく探っていきます。

セマンティックメモリ

セマンティックメモリは、特定のイベントとは独立して、事実、概念、関係に関する整理された知識を格納するエージェントのリポジトリと見なすことができます。これには、ナレッジベース、特定のエンティティに関する情報（エンティティメモリ）、およびエージェントを特定の行動に誘導する役割ベースの知識（ペルソナメモリ）が含まれます。セマンティックメモリは、エージェントが一貫して推論できるようにする構造化された「世界の知識」として理解できます。最も一般的な実装は RAG システムです。このシステムでは、実際のドキュメントのベクトル埋め込みが構造化された形式で保存および取得されます。

セマンティックメモリの一般的な形態は次のとおりです。

• ナレッジベース：権威ある情報源から取り込まれた検証済みの構造化情報を含む、セマンティックメモリの正式に組織されたコンポーネント。ナレッジベースには、多くの場合、会社のポリシー、技術仕様、科学的事実など、エージェントの基盤となる真実として動作するための、ドメインの専門知識、ドキュメント、ポリシー、参照資料があらかじめ登録されています。
• エンティティメモリ：特定のエンティティ（人、組織、製品、概念）の属性、関係、過去のインタラクションなど、詳細なプロファイルを保持します。このメモリにより、AI エージェントのインタラクションにおいて、パーソナライズされたやり取りと関係を認識した応答が可能になります。
• ペルソナメモリ：一貫したな人格と専門知識を定義する、エンコードされた行動パターン、コミュニケーションスタイル、役割固有の知識を保存します。
• 連想メモリ：保存された事実間の関係をリンクおよびトラバースする能力。これにより、パターン発見と推論が可能になります。連想関数は、セマンティックメモリフレームワーク内のグラフのような構造を使用して実装されることが多く、エージェントが関連する概念間の「点と点を結ぶ」ことを可能にします。MongoDB のドキュメントモデルは、こうしたハイブリッドなセマンティックと連想の設計に適しています。

手続き型メモリ

これは、エージェントが学習した実力、ルーチン、デシジョンツリー、ワークフロー、複数ステップのプロセスのリポジトリです。これは、明示的な指示なしに複雑な複数ステップのタスクを完了するために必要なアクションのシーケンスを保存します。人間が自動的に自転車に乗る方法を学ぶのと同じように、手続型メモリを持つエージェントは、確立されたルーティンを実行できます。

手続型メモリの例としては、ツールボックスメモリ（利用可能なツールとその使用法に関する知識）や ワークフローメモリ（繰り返しプロセス用にキャプチャされたデータ）などがあります。ソフトウェア展開エージェントは、手続型メモリを使用してリリースプロトコルに自動的に従います。

以下のコードスニペットでは、`Toolbox` クラスがツールボックスのメモリコンポーネントとして機能します。これは、エージェントが Python 関数を検索可能なメタデータを持つ検索可能なツールとして登録できるようにするレジストリとして機能します。エージェントが手動で検索することなくタスク要件に基づいて適切なツールを自動的に見つけて実行できるように、実際の呼び出し可能関数はメモリに、その意味的な埋め込みは永続ストレージに保存されます。より具体的には、入力クエリや目的に一致するツールボックスメモリ内のツールの意味的に類似したサブセットを検索することで、エージェントシステムでのツール使用をスケールすることもできます。

メモリの種類の実装とコンテキストウィンドウのコンテンツのメモリユニットへの変換時に、AI エンジニアは LLM 実行応答内の特定のフラグを識別し、応答属性に基づいて重要な情報を抽出するためのプロセスを確立できます。

以下のコードスニペットは、この抽出プロセスの動作を示しています。各関数呼び出しの実行後、システムは結果をメッセージ履歴に追加してワークフローステップを自動的にキャプチャし、ツール ID、引数、結果、タイムスタンプ、エラーメッセージなどの重要なメタデータを抽出して、実行完了時に完全なワークフローの一部として保存される構造化されたメモリユニットを作成します。以下に、このアプローチがワークフローメモリと関連するメモリユニットにどのように応用されるかを示します。

ワークフロー抽出プロセス

1. LLM 応答処理：LLM がツール呼び出しをリクエストする場合、システムは完全な応答を待たずに各ツール呼び出しを直ちに加工します。
2. リアルタイムのワークフロー構築：各ツール実行の場合：
1. _id、引数、結果、タイムスタンプ、エラーを含むワークフローのステップを作成します。
2. 実行結果（成功/失敗）をトラックします。
3. ワークフローのメタデータをアップデートすします。

3. ステップデータ構造：各ワークフローのメモリユニットには、次のものが含まれます。

4. メモリストレージ：完全なワークフローは、セマンティック検索用の埋め込みとともにMemoryType.WORKFLOW_MEMORYに保存されます。

5. 将来の参照：保存されたワークフローは、実行コンテキストを提供し、過去の経験から学習するために、将来のクエリで抽出されます。

共有メモリ

マルチエージェントシステムで一般的に見られる共有メモリは、複数のエージェントが同時にアクセスできるコラボレーション領域を提供することで、連携を実現します。これにより、分散されたチームのエージェントについて、活動の調整、調査結果と計画の共有、システム全体での同期状態の維持が可能になります。共有メモリは、ユースケースやシナリオに応じて、長期または短期として構成できます。たとえば、プロジェクトの期間全体にわたって戦略的目標を保持する（長期）ことや、単一の研究セッション中に中間検索結果を保持する（短期）ことができます。たとえば、学術論文の検索を専門とするエージェント、引用の検証を専門とするエージェント、調査結果の合成を専門とするエージェントからなる研究チームは、共有メモリを活用して、作業の重複を避け、リアルタイムで互いの発見を積み上げていくことができます。

このメモリタイプでは、複数のエージェントが共有メモリスペースに対して同時に読み取りや書き込みを行う際、競合状態を防ぎ、データの整合性を確保するために、データベースレベルでの ACID コンプライアンス（原子性、一貫性、独立性、永続性）が極めて重要になります。これらの保証がないと、エージェントが互いの投稿を上書きしたり、古いデータで作業したり、システム全体の信頼性を損なう可能性のある整合性の取れない状態に遭遇したりする可能性があります。

これらのメモリタイプは人間の認知にヒントを得た概念的なブループリントであり、直接的な生物学的レプリケーションではないことを理解することが重要です。各メモリタイプは、AI エージェント内で異なる認知機能を提供し、それらの連携により、先ほど触れた信頼性、信用性、能力を実証するエージェントの能力が決定されます。これを AI エージェントの RBC と呼びましょう。

MongoDB でエージェントメモリを有効にする方法

ステートレスな AI アプリケーションから継続的な学習パラダイムを備えたステートフルな AI エージェントへと移行するにつれて、データベースの役割は根本的に進化しています。単純なデータストアから、インテリジェントなエージェント型システムの中核となるコンポーネントへと変化しています。データベースは、AI エージェントとエージェント型システムのメモリプロバイダーになりつつあります。

この変革は、これまで説明してきた AI エンジニアリング分野の進化、すなわちプロンプトエンジニアリングからコンテキストエンジニアリング、エージェントエンジニアリング、そして現在のメモリエンジニアリングへの進化と一致しています。各分野には、従来のデータベースが取り扱うようには設計されていない高度なデータマネジメント機能が必要です。

これらのアプローチの根本的な違いは、その中核となるアーキテクチャの意図にあります。

1. 従来のデータベースは、データの整合性と一貫性が最も重要となるトランザクションシステム向けに設計されました。これらは構造化情報の保存と複雑なクエリの実行に優れていますが、すべてのデータを同等に重要であり、時間の経過とともに変化しないものとして扱います。
2. 専用データベースは、高次元空間で意味的に類似した情報を検索するためのベクトルデータベース、効率的な関係のトラバーサルとパターン検出を実現するためのグラフデータベースなど、特定の問題を解決するために登場しました。これらは AI アプリケーションにとって大きな進歩を意味します。ベクトルデータベースは数百万の埋め込み全体で効率的な類似性検索を実現し、グラフデータベースはエンティティ間の複雑な関係や多ホップ接続の探索に優れています。しかし、それらは根本的には、ベクトル類似性やグラフ トラバーサルといった専門的な操作のみに焦点を当てた単一目的のツールに過ぎません。

この記事を通じて、エージェントメモリは単一のものではないことを示してきました。画一的なアプローチでは、異なるメモリタイプにはそれぞれ異なる要件があるため、うまく機能しません。コンテキストメモリには、タイムスタンプ付きの構造化ログが必要です。セマンティックキャッシュには、ハイブリッド検索のために、豊富なメタデータとともに効率的なベクトル検索が必要です。ワークフローの状態には、複雑なドキュメントの関係とグラフトラバーサル機能が必要です。

カスタマーサービスのシナリオを考えてみましょう。従来のデータベースでは、各インタラクションはタイムスタンプ付きの個別のレコードとして保存される場合があります。ユーザーの履歴を理解するには、すべての関連レコードをクエリし、手動で物語をつなぎ合わせる必要があります。どの情報が最も関連性が高いか、または好みがどのように進化したかについての固有の理解はありません。

ベクトルデータベースは、過去の会話の埋め込みを保存し、意味的に類似したやり取りを検索できます。これはキーワードマッチングよりも優れたコンテキストを提供しますが、「John preferred Italian food last month」（ジョンは先月イタリア料理を好んだ）と「John now prefers Thai food」（ジョンは現在タイ料理を好む）を区別できません。どちらの食の好みに関する表現も、ベクトル空間では同様にクラスター化されるためです。

エージェントメモリシステムは、これらを異なる強度属性を持つ、時間順に並べられた個別のメモリとして保持します。エージェントがジョンが継続的にタイ料理レストランを選択していることを観察すると、「イタリア料理の選好」のメモリは徐々に弱まり、「タイ料理の選好」のメモリは強くなります。システムはジョンが言ったことだけでなく、彼の好みがどのように進化したか、現在どの情報が彼の行動を最も正確に予測しているかを理解します。

PostgreSQL は技術的にはテキスト検索（tsvector を使用）、ベクトル類似性（HNSW を使用した pgvector を使用）、グラフの走査（再帰的な CTE または Apache AGE などの拡張機能を使用）を実行できますが、これらの機能には複数の拡張機能、クエリパターン、最適化戦略を調整する必要があります。セマンティック類似性、メタデータフィルタリング、関係のトラバーサルを組み合わせたハイブリッド検索パターンを迅速に実験する必要があるメモリエンジニアリングチームにとって、この断片化されたアプローチは不必要な複雑さを生み出し、開発サイクルを長期化させます。

さらに、エージェント型メモリアーキテクチャは実験的な性質を持つため、個々のドキュメントスキーマだけでなく、異なるメモリタイプ間の関係を再構築する必要があることが多く、大規模でインデックスが多用されているテーブルでは、依然として慎重な移行計画が必要になる場合があります。

PostgreSQL で説明したこの断片化されたアプローチは、MongoDB が LangGraph、Agno、Mastra など、主要な AI/エージェントフレームワークのメモリプロバイダとしてますます採用されている理由を正確に示しています。MongoDB Atlas は、制限のあるブラックボックス型のメモリソリューションを提供するのではなく、必要な機能をすべて提供することで、開発者がメモリエンジニアリングを深掘りできるようにします。

• マルチモデル検索メカニズム：従来のテキスト検索、ベクトル類似性検索、グラフ走査を統合されたクエリ インターフェイス内でサポート
• 柔軟なドキュメントモデル：MongoDB の JSON に似たドキュメントモデルは、会話のスニペットから複雑な手続き型知識に至るまで、多様で進化するメモリタイプをネイティブに保存します。開発者を所定の構造に固定するような厳格なスキーマはありません。
• 高度な最適化機能：効率的なベクトルストレージのための量子化、分離された操作のための専用検索ノード、インテリジェントなインデックスの作成戦略が含まれます。

MongoDB による Voyage AI の買収は、最先端の埋め込みモデルとリランカーをデータベースプラットフォームに直接取り込むという、大きな進歩を示しています。この統合により、RAG パイプラインとエージェント型アプリケーションのアプリケーションコードの複雑さが劇的に軽減されます。さらに重要なことに、MongoDB を開発者がデータを単に提供し、その対価として高度なメモリユニットコンポーネントと機能を受け取ることができるソリューションに変えます。

AI エンジニアが複数の専門的なデータベースを継ぎ合わせて複雑な埋め込みパイプラインを管理しなくても、MongoDB Atlas がデータの取り込みとベクトル化からストレージ、組織化、AI を活用した取得まで、データからメモリへの変換パイプライン全体を取り扱います。

これらのアプローチのどちらを選択するかは、最終的には情報システムを構築しているか、インテリジェントなエージェントを構築しているかによって決まります。

セマンティック検索を必要とする従来のアプリケーションの場合、ベクトルデータベースは優れた集中的な機能を提供します。学習と進化を行う適応型インテリジェンスを必要とするアプリケーション向けに、MongoDB はステートレスアプリケーションを真にインテリジェントなエージェントに変える認知アーキテクチャを提供します。

この統合アプローチにより、ここまで説明してきたメモリ エンジニアリングの専門化が可能になり、信頼性が高く、信憑性が高く、有能な AI エージェントを構築するために必要な技術的基盤が提供されます。メモリエンジニアリングをさらに詳しく調べるには、MongoDB Atlas を使用してメモリアーキテクチャを試すか、AI ラーニングハブで詳細なチュートリアルを確認してください。