AIエージェントの長期記憶設計とは、会話セッションをまたいで業務文脈をエージェントに保持・活用させるためのアーキテクチャ設計のことです。

標準的な RAG やコンテキストウィンドウだけでは、数週間・数ヶ月にわたる業務の流れを記憶し続けることは困難です。本記事では、UC Berkeley 発の MemGPT と Microsoft Research の GraphRAG を組み合わせ、長期的な文脈保持を実現する設計パターンを解説します。

対象読者は、AIシステムの開発・運用に携わるエンジニアや、エージェントのコンテキスト管理に課題を感じているアーキテクトです。記事を読み終えると、次の内容を習得できます。

セッションが終わると、AIエージェントはすべてを忘れる——そう聞いて、業務利用に不安を覚えた経験はないでしょうか。

コンテキストウィンドウには物理的な上限があり、会話が長くなるほど古い情報から順に押し出されていきます。単発の質問応答ならそれで十分ですが、複数日にまたがるプロジェクト管理や、顧客ごとの対応履歴を踏まえた提案といった業務では、「前回話したこと」を引き継げないエージェントはすぐに限界を露呈します。

長期記憶の設計とは、このウィンドウの外側に情報を蓄積し、必要なタイミングで呼び戻す仕組みを作ることです。何をどこに保存するか、いつ参照するかを適切に設計しなければ、記憶は増えるだけで使えないノイズになります。以降では、短期記憶との構造的な違い、実際の業務シナリオへの当てはめ方、そして記憶の分類という三つの観点から順に掘り下げていきます。

コンテキストウィンドウは、LLMが一度の推論で参照できるテキストの上限です。MemGPT論文（Table 1）によると、llama-2で4,000トークン、GPTで8,000トークン程度が当時の上限として示されており、これを超えた情報はそのセッション内では参照できません。

「コンテキストを長くすれば解決する」と最初は考えがちですが、ウィンドウ長を伸ばすだけでは数週間・数ヶ月にわたる業務の経緯を保持することはできません。会話セッションが終わると記憶はリセットされ、次のセッションでは白紙の状態から始まるからです。

短期記憶と長期記憶の違いは、保持期間だけの話ではありません。短期記憶はトークン数の上限に縛られますが、長期記憶は外部ストレージに書き出すため実質的に容量の上限がなく、セッションをまたいで永続的に保持されます。更新の仕組みも異なり、短期記憶が会話の流れで自動的に上書きされるのに対し、長期記憶は明示的なトリガーで書き込みや更新を制御できます。検索においても、短期記憶がウィンドウ内の全文を一括参照するのとは違い、長期記憶は必要な断片だけを選択的に取得します。

業務システムでは、顧客との過去のやり取りや意思決定の経緯が後の判断に直結します。それらをセッションをまたいで活用するには、短期記憶の延長ではなく、外部ストレージと連動した長期記憶の仕組みが不可欠です。

長期記憶の必要性は、業務の継続性と複雑性によって変わります。単発の質問応答なら標準的なRAGで十分ですが、数週間・数ヶ月にわたって同一プロジェクトを追跡する場合は、セッションをまたいだ文脈保持が不可欠です。

以下のようなシナリオでは、長期記憶の設計が特に重要になります。

• カスタマーサポートの引き継ぎ: 顧客が過去に報告した不具合や対応履歴をエージェントが記憶していないと、毎回同じ説明を求めることになり、顧客体験が著しく低下します
• プロジェクト管理アシスタント: スプリントをまたいで意思決定の経緯や変更理由を追跡する場合、過去の議論の文脈がなければ一貫したアドバイスができません
• 社内ナレッジ蓄積: 特定の担当者しか知らない業務ノウハウを、エージェントが対話を通じて継続的に学習・蓄積するユースケースでは、セッション間の記憶連携が前提となります
• 法務・コンプライアンス対応: 契約交渉の経緯や過去の判断根拠を参照しながら新たな案件に対応する場面では、単なるドキュメント検索では不十分です

業務の複雑度が低く、問い合わせが独立している場合はコンテキストウィンドウの範囲で対処できますが、複数ステークホルダーが関与し、判断が過去の経緯に依存する業務では長期記憶アーキテクチャが必要です。

こうした業務シナリオに共通するのは、「過去の文脈が現在の判断品質に直接影響する」という点です。

「エージェントに何を覚えさせればいいのか、整理できていない」という疑問は、設計の初期段階でよく浮かぶものです。認知科学の記憶分類を参照すると、AIエージェントの長期記憶設計に必要な構造が見えてきます。

エージェントが保持すべき記憶は、大きく3種類に分類できます。

• エピソード記憶: 「いつ・誰と・何を話したか」という時系列の出来事の記録。例えば、先週の打ち合わせで決定した仕様変更の経緯や、ユーザーが過去に示した要件の優先順位などが該当します。セッションをまたいだ会話の継続性を支える基盤となります。

• 意味記憶: 業務ドメインに関する概念・ルール・用語の知識体系。「この顧客は月末締めの請求を好む」「製品Aは特定の規制対象外である」といった、文脈から切り離しても成立する事実の集合です。GraphRAGが特に強みを発揮する領域でもあります。

• 手続き記憶: タスクの実行手順やワークフローのパターン。「承認フローは上長→法務→経理の順」「エラー発生時はまずログを確認してから再試行する」といった、繰り返し実行される操作の定型化された知識です。

3種類を混在させたまま単一のベクトルストアに格納すると、検索時に記憶の種別が区別できず、的外れな文脈が呼び出されるリスクが高まります。設計段階でストレージを分離し、それぞれの記憶タイプに適したインデックス戦略を割り当てることが重要です。次のセクションで扱う標準 RAG の限界も、この分類を念頭に置くと理解しやすくなります。

「先週話した件、覚えてる？」——人間同士なら当然通じるこの一言が、AIエージェントには通じないことがあります。標準的なRAGは、質問に対して関連文書をベクトル検索で引っ張ってくる仕組みです。単発の参照としては十分に機能しますが、「先週の議論」「前回の判断の経緯」といった時間軸をまたいだ文脈は、そもそも保持する設計になっていません。

セッションが終われば記憶はリセットされます。次の会話では、また一から状況を説明しなければなりません。業務で使おうとすると、この制約はすぐに壁になります。以降では、RAG単体では埋めきれない三つの課題を順に掘り下げていきます。

ベクトル検索を導入すれば長期記憶の問題が解決する——そう考えて実装を進めると、しばらくして「意味的に近い断片は取れているのに、会話が噛み合わない」という壁にぶつかることがあります。

標準的なRAGが抱える問題の核心は、スコアリングが「チャンク単位の類似度」しか見ていない点にあります。各チャンクは独立して評価されるため、複数セッションにまたがる因果関係や時系列の流れは表現できません。「先週の打ち合わせで決まった方針」や「数か月前に変更された承認フロー」といった時間的な依存関係は、ベクトル空間上では近傍に現れないことが多く、コンテキストの断絶が生じます。加えて、関連チャンクを多数取得しようとすれば、それだけLLMのコンテキストウィンドウをすぐに圧迫します。MemGPT論文（arXiv: 2310.08560）が指摘するように、当時の主要モデルのコンテキスト長は数千トークン程度に限られており（例：llama‑1 = 2,000 tokens、llama‑2 = 4,000 tokens、gpt‑3.5‑turbo = 4,000 tokens、gpt‑4 = 8,000 tokens）、大量のチャンクを一度に渡す設計はそもそも現実的ではありませんでした。

さらに根本的な問題として、ベクトル検索は「何を取得するか」を決めるだけで、「いつ記憶を更新するか」「矛盾した情報をどう扱うか」という記憶管理のロジックを持っていません。その結果、古い情報と新しい情報が混在したまま検索結果に現れ、エージェントが誤った前提で回答するリスクが生じます。

業務ログが数万件規模になると、ベクトル検索の精度は想定より早く劣化する傾向があります。

原因の一つは意味的に近いが文脈が異なるエントリの混在です。たとえば「承認待ち」というフレーズは、稟議フローの承認と、システムアクセス権の承認の両方に登場します。ベクトル空間では両者の距離が近くなるため、無関係な文書が上位に混入しやすくなります。

大規模ログ特有のノイズ源を整理すると、以下のようになります。

• 重複・類似エントリの蓄積: 定型フォーマットで繰り返し生成されるログは、ほぼ同一のベクトルを大量に生成し、検索結果を均質化させます
• 古い情報の残留: 組織変更やプロセス変更後も旧ログが削除されずに残ると、矛盾した文脈が同時にヒットします
• 粒度の不均一: 詳細な手順書と一行メモが同一インデックスに混在すると、チャンクの重みが不均等になります

精度低下の深刻度はログの性質によって異なります。構造化ログ（CSVや DB レコード）が中心の場合はチャンク分割の粒度調整で対処できる一方、非構造化テキスト（メール・議事録・チャット履歴）が混在する場合は前処理のノイズ除去ステップが不可欠です。

こうした問題は、単純にインデックスサイズを増やしても解決しません。むしろ検索対象が増えるほど、無関係なエントリがスコア上位に浮上するリスクが高まります。次のセクションで解説する MemGPT と GraphRAG の組み合わせは、この構造的な問題に対してアーキテクチャレベルで対処するアプローチです。

「標準的な RAG を入れたのに、なぜエージェントは先週の会議内容を覚えていないのか」と感じた経験はないでしょうか。その問いが、MemGPT と GraphRAG が解決しようとしている核心です。

両者はそれぞれ異なる弱点を補完します。

MemGPT が補完する領域

• コンテキストウィンドウの物理的な上限（論文 Table 1 では GPT-4 で 8,000 tokens）を超えた情報を、外部ストレージに退避・呼び出しする仕組みを提供します
• セッションをまたいだ「エピソード記憶」の保持に強みがあります
• ファンクションコールで記憶の読み書きタイミングをエージェント自身が制御できます

GraphRAG が補完する領域

• 大量の業務ドキュメントから「誰が・何を・どのプロジェクトに関係しているか」というエンティティとリレーションをグラフ構造で保持します
• ベクトル検索では拾いにくい「複数ドキュメントをまたぐ関係性」を、グラフクエリで横断的に検索できます
• Microsoft Research が 2024 年 2 月に公開した GraphRAG は、索引構築コストのうちグラフ抽出がおよそ 75% を占めるものの、複雑な推論クエリへの回答精度を大幅に向上させると報告されています

組み合わせることで生まれる効果

MemGPT が「いつ・誰と・何を話したか」という時系列の文脈を管理し、GraphRAG が「その人物や概念が組織内でどう繋がっているか」という構造的知識を提供します。

結論: MemGPT は OS のメモリ階層を模倣し、LLM のコンテキスト制約を超えた長期記憶を実現する設計を持つ。

MemGPT は UC Berkeley 等の研究チームが 2023 年に発表したフレームワークで、メインコンテキストと外部ストレージを分離することで記憶を管理します。以下の H3 では、アーキテクチャの構造・初期設定・ファンクションコールの制御手順を順に解説します。

MemGPT を初めて見たとき、「単なるメモリ拡張プラグインだろう」と捉えがちです。しかし実際には、OS のメモリ管理に着想を得た階層型アーキテクチャであり、その設計思想を理解することが長期記憶実装の核心となります。

MemGPT の論文（UC Berkeley ら、2023年10月）では、LLM を OS に見立て、コンテキストウィンドウを「メインメモリ（RAM）」、外部ストレージを「ディスク」として扱う構造が提案されています。論文中の比較表によると、当時の主要モデルのコンテキスト長は llama-1 で 2,000 tokens、GPT-4 でも 8,000 tokens にとどまっており、長期業務文脈を単一ウィンドウに収めることは構造的に困難でした。

アーキテクチャの主要コンポーネントは以下の 3 層です。

• メインコンテキスト（In-Context Storage）: LLM が直接参照できるアクティブな作業領域。システムプロンプト・直近の会話・重要サマリを保持する
• 外部ストレージ（External Storage）: ベクトル DB や KV ストアに格納された長期記憶。

MemGPT のセットアップは、ローカル環境か クラウド API かで手順が分岐する点に注意が必要です。ローカル LLM（LM Studio 等）を使う場合はモデルのダウンロードと API エンドポイントの設定が追加で必要になり、OpenAI API キーを使う場合は環境変数を設定するだけで最短で動作確認まで進めることができます。

インストール手順（OpenAI API を使う場合）

まず、Python 3.10 以上の環境を用意してください。

インストール後、以下のコマンドで対話型の初期設定ウィザードを起動します。

ウィザードでは次の項目を順に設定します。

• LLM プロバイダー: openai を選択（ローカル LLM の場合は local を選択）
• モデル名: 使用するモデルを指定
• 埋め込みモデル: デフォルトは OpenAI の埋め込みモデルを推奨
• 外部ストレージバックエンド: chroma（ローカル）または postgres を選択

初期エージェントの作成

設定完了後、以下のコマンドでエージェントを作成します。

初回起動時にはシステムプロンプト（ペルソナ・人物設定）と人物記憶の初期値を入力するよう求められます。

「MemGPT を導入したはいいが、エージェントがいつ記憶を書き込み、いつ読み出すかを制御できずに困っている」という声は開発現場でよく聞かれます。MemGPT では、この制御をファンクションコール（関数呼び出し）の仕組みで実現しています。

MemGPT のエージェントは、LLM の出力として通常のテキスト応答と並行して、以下のような専用関数を呼び出す形で記憶を操作します。

• core_memory_append: メインコンテキスト内の固定記憶領域に情報を追記する
• core_memory_replace: 既存の記憶エントリを上書き更新する
• archival_memory_insert: 長期の外部ストレージに情報を保存する
• archival_memory_search: 外部ストレージからキーワードや意味的類似度で情報を取得する

これらの関数はシステムプロンプトに定義として組み込まれており、LLM 自身が「どの関数を呼ぶべきか」を推論して判断します。たとえば、ユーザーが「今後この案件は担当者 A に引き継ぐ」と発言した場合、エージェントは core_memory_replace を呼び出して担当者情報を更新する、という流れになります。

実装時に注意すべき点は次の 3 つです。

結論: GraphRAG は業務ドキュメントからエンティティとリレーションを抽出し、知識グラフとして索引化することで、文脈をまたいだ深い検索を可能にする。

GraphRAG は Microsoft Research が 2024 年 2 月に公開したプロジェクトです。テキストをグラフ構造に変換し、エンティティ間の関係を保持したまま検索できる点が特徴です。

最初は「できるだけ多くのエンティティを抽出すれば精度が上がる」と考えがちですが、実際はエンティティの粒度を絞り込み、業務上の意味のある単位に限定するほうが検索品質が高まります。過剰抽出はグラフのノイズを増やし、クエリ時のパス探索コストを押し上げる原因になります。

エンティティ設計の基本方針

業務ドキュメントに対してエンティティ抽出を設計する際は、以下の 3 点を先に決めておくと後工程がスムーズです。

• 対象ドメインの列挙: 「顧客」「案件」「担当者」「製品」「日付」など、業務で繰り返し登場する名詞クラスを洗い出す
• 粒度の統一: 「株式会社 A」と「A 社」を同一エンティティとして正規化するルールを事前に定義する
• 除外ルールの設定: 一般名詞や頻出ストップワードはエンティティ候補から除外し、グラフの肥大化を防ぐ

リレーション定義のポイント

エンティティ間の関係（リレーション）は、動詞句ベースで定義するのが基本です。たとえば「担当する」「承認した」「依存する」のように、業務フローに沿った動詞を軸にすると、後のグラフクエリで意図した経路が引きやすくなります。

GraphRAG のドキュメントでは、テキストチャンクサイズを 50〜100 tokens に設定する例が示されており、チャンクが小さいほどエンティティの局所的な共起関係を捉えやすい反面、グラフ抽出コストが増大する点に注意が必要です。

リレーション定義は「双方向か単方向か」も明示しておくと、クエリ設計の一貫性が保たれます。

業務ドキュメントを GraphRAG に投入する際、パイプラインの設計が品質を大きく左右します。ドキュメントの種類や量に応じて処理ステップを適切に組み立てることが重要です。

基本的なパイプラインの流れは以下の通りです。

1. 前処理（チャンキング）: GraphRAG のドキュメントでは、テキストチャンクサイズの設定例として 50〜100 tokens が示されています。議事録や仕様書など文脈の区切りが明確なドキュメントは小さめのチャンクが有効で、長文レポートや契約書のように段落間の依存が強い場合はやや大きめのチャンクを設定するとエンティティの抽出精度が上がる傾向があります。
2. エンティティ・リレーション抽出: LLM を用いてチャンクからエンティティと関係を抽出します。この工程はグラフ索引作成コストのおよそ 75% を占めるとドキュメントに記載されており、処理量とコストのバランスを事前に見積もることが重要です。
3. グラフ構築・格納: 抽出結果をグラフ DB（Neo4j 等）または GraphRAG の内部ストレージに格納します。

ドキュメント種別ごとの判断軸として、社内ナレッジ（FAQ・手順書）のように更新頻度が低い場合はバッチ処理で定期的に再インデックスする設計が合理的です。一方、日次で更新される業務ログや CRM メモのように変化が速い場合は、差分抽出パイプラインを用意してインクリメンタルにグラフを更新する構成が適しています。

「グラフを構築したはいいが、実際にどうクエリを投げれば業務文脈を取り出せるのか」——現場でよく聞かれる問いです。

GraphRAG では、構築した知識グラフに対して主に 2 種類の検索モードを使い分けます。

• Local Search: 特定のエンティティや関係を起点に、近傍ノードを辿る局所的な検索。「この顧客の過去の問い合わせ履歴」のような具体的な文脈取得に適しています。
• Global Search: コミュニティサマリを集約して広域の傾向を把握する検索。「先月の業務全体で何が課題だったか」のような俯瞰的な問いに向いています。

実装の基本フローは次のとおりです。

1. クエリ文字列をエンティティ候補に変換し、グラフ内の対応ノードを特定する
2. ノードから隣接エッジ・関連コミュニティを展開してサブグラフを取得する
3. サブグラフのテキスト表現を LLM のコンテキストに挿入して回答を生成する

チャンクサイズはドキュメントの公式設定例として 50〜100 tokens が示されており、細かく分割するほどノード粒度が上がり精度が向上しやすい一方、グラフ抽出コストも増加します。なお、グラフ抽出はインデックス作成コスト全体のおよそ 75% を占めるとドキュメントに記載されており、チャンクサイズの設定はコストと精度のトレードオフを意識して決める必要があります。

結論: MemGPT と GraphRAG を統合することで、セッション横断の記憶管理と知識グラフ検索を組み合わせた堅牢な長期記憶基盤が実現できる。

両者の役割分担を明確にしたうえで、書き込みトリガーや検索スコアリングを適切に設定することが統合成功の鍵となります。

MemGPT と GraphRAG を組み合わせる際、最初は「両者を並列に呼び出せばよい」と考えがちですが、実際には役割を明確に分離した階層設計のほうが安定した動作につながります。

統合アーキテクチャでは、各コンポーネントに次の責務を割り当てます。

• MemGPT（セッション記憶層）: 直近の会話履歴・ユーザーの作業状態・短期的な指示をメインコンテキストで管理し、容量超過時に外部ストレージへ退避する
• GraphRAG（知識グラフ層）: エンティティ間の関係・業務ルール・過去プロジェクトの構造化情報を保持し、意味的なつながりで検索可能にする
• オーケストレーター: ユーザーの入力を受け取り、MemGPT のコンテキストを参照した後、必要に応じて GraphRAG へクエリを発行して結果を統合する

データの流れは以下の順序で処理されます。

1. ユーザー入力 → オーケストレーターが意図を分類
2. MemGPT のメインコンテキストを確認し、セッション内で解決できるか判断
3. 解決できない場合、GraphRAG にエンティティ検索を発行
4. 取得した知識をメインコンテキストに注入し、LLM が回答を生成
5. 重要な情報は MemGPT の外部ストレージへ書き込み、次回セッションに引き継ぐ

この設計で特に重要なのは、GraphRAG への問い合わせを「必要な場合だけ」に絞ることです。

記憶への書き込みをいつ・どのように行うかは、長期記憶システムの品質を左右する核心的な設計判断です。

書き込みトリガーは、大きく以下の 3 種類に分類できます。

• イベントドリブン型: ユーザーが明示的に「覚えておいて」と指示した場合や、タスク完了・承認などの業務イベントが発生したタイミングで書き込む
• 推論ベース型: エージェントが会話内容を評価し、重要度スコアが閾値を超えた場合に自律的に書き込む
• 定期バッチ型: セッション終了時や一定時間ごとに、その期間の要約を生成して保存する

更新ポリシーの設計では、条件分岐の明示が重要です。同一エンティティに関する新情報が既存記憶と矛盾しない場合は追記（Append）、矛盾または陳腐化が確認された場合は上書き（Overwrite）と、ポリシーを明確に分けておく必要があります。

「GraphRAG で関連ノードを取得したのに、エージェントの回答がなぜかズレている」と感じたことはないでしょうか。原因の多くは、検索スコアリングの設計が実業務の重要度と一致していないことにあります。

MemGPT と GraphRAG を統合した環境では、検索結果のスコアリングに次の要素を組み合わせることが有効です。

• 意味的類似度: ベクトル距離による基本スコア
• グラフ近接度: 対象ノードから参照エンティティまでのホップ数（近いほど高スコア）
• 鮮度重み: タイムスタンプを元に、古い記憶エントリのスコアを段階的に減衰させる
• アクセス頻度: 過去に参照された回数を加算し、実績ある記憶を優先する

これら 4 つを線形結合し、重みをタスク種別ごとに調整することで、業務文脈に即した検索順位を実現できます。

フォールバック戦略も同様に重要です。GraphRAG のグラフクエリが空の結果を返した場合、そのままエージェントに渡すと回答品質が急落します。推奨する 3 段階のフォールバックは以下のとおりです。

1. グラフクエリ — エンティティ関係を優先検索
2. ベクトル検索（標準 RAG） — グラフで見つからない場合に実行
3. MemGPT のサマリ記憶 — 上位 2 つが低スコアの場合に参照

フォールバック発動時はログにフラグを立て、後続のグラフ更新トリガーとして活用すると、記憶の空白を継続的に補完できます。

統合システムを本番環境に持ち込んだとき、設計段階でどれだけ念入りにレビューしても、実際の業務データが流れ込み始めると想定外の問題が顔を出す。以降では、現場で頻度高く踏まれる二つの失敗パターンと、それぞれの回避策を具体的に見ていく。

長期記憶を導入した直後、多くのチームは「記録できるものはすべて保存しておこう」という方針を採りがちです。しかし実際には、エントリ数が増えるほど検索レイテンシが線形以上に悪化し、応答速度がボトルネックになるケースが報告されています。保存量を絞り込む設計こそが、長期的なパフォーマンス維持の鍵です。

肥大化を防ぐ主な対策は以下の通りです。

• TTL（有効期限）の設定: エピソード記憶には保存期限を付与し、一定期間参照されなかったエントリを自動的にアーカイブまたは削除します。業務ログのように鮮度が重要なデータは、30〜90 日程度の TTL を目安に設計するとよいでしょう。
• 重要度スコアによる優先管理: MemGPT のファンクションコールで書き込み時に重要度スコアを付与し、低スコアのエントリは圧縮・要約して保存します。詳細な原文をそのまま蓄積するよりも、要約エントリに置き換えることでストレージと検索コストを同時に削減できます。
• GraphRAG 側のチャンクサイズ最適化: ドキュメントによれば、テキストチャンクサイズの設定例は 50〜100 tokens とされています。細かすぎるチャンクはノード数の爆発を招くため、業務ドキュメントの粒度に合わせた調整が必要です。
• 定期的なグラフ刈り込み: 孤立ノードや参照頻度の低いエッジを定期バッチで削除し、グラフの密度を一定範囲に保ちます。

これらを組み合わせることで、記憶の鮮度と検索速度のバランスを維持できます。

記憶エントリの矛盾は、同一エンティティに対して異なる時点の情報が別々に書き込まれたときに発生します。たとえば「担当者は田中さん」という記録と「担当者は鈴木さん」という記録が共存すると、エージェントはどちらを参照すべきか判断できなくなります。

矛盾の検出には、主に次の 2 つのアプローチが有効です。

• タイムスタンプ比較: 同一エンティティ・同一属性に複数のエントリが存在する場合、最新タイムスタンプを持つエントリを正として扱い、古いエントリに「obsolete」フラグを付与する
• 埋め込みベースの類似度チェック: 新規エントリ書き込み時にコサイン類似度が閾値（例: 0.90 以上）を超える既存エントリを候補として抽出し、LLM に矛盾判定を委ねる

解消ポリシーは状況によって使い分けが必要です。エントリの更新が明示的なユーザー発話（「担当が変わった」等）に基づく場合は古いエントリを上書きし、暗黙的な文脈変化の場合は両エントリを保留しつつ信頼スコアを付けて優先度管理するのが安全です。

GraphRAG を使っている場合は、ノード属性の変更履歴をエッジとして記録する設計が矛盾の追跡に役立ちます。MemGPT 側では、archival storage への書き込みファンクションに重複チェックロジックを組み込み、矛盾候補が検出された時点でエージェント自身に確認ステップを踏ませる実装が推奨されます。