AIエージェントは「会話をまたいで何も覚えていない」という根本的な制約を抱えています。この問題を解消するために登場した記憶永続化の仕組みが、今まさに設計上の重要な選択肢として浮上しています。
「エングラム」とは何か
エングラム（engram）とはもともと神経科学の用語です。1904年にリヒャルト・ゼーモンが提唱した概念で、生物の神経組織に記憶が物理的な痕跡として残る様子を指します。AIエージェントの文脈では、エージェントが学習した一単位の情報を指します。具体的には「ユーザーの好み」「過去の修正履歴」「手順の記憶」などがこれに当たります。この情報をセッションをまたいで保持することで、エージェントは「初めて会う相手」として毎回振る舞う問題を回避できます。
エングラムを扱うライブラリとしては、Mem0・Letta・Cognee・Graphiti・LangMem・PLURといったプロジェクトが存在します。これらはいずれもGitHub上でApache-2.0またはMITライセンスで公開されています。しかし「ソフトウェアがオープンソースである」ことと「データ形式がオープンである」ことは、全く別の話です。
3階層で整理するオープン性のスペクトラム
シード記事はエージェント記憶エンジンを3つの層に分類しています。アーキテクチャの設計判断として、この分類を理解することが第一歩です。
第1層は「完全オープン」です。ソフトウェアのライセンスだけでなく、記憶データの形式も公開されており、利用者が自由に読み書き・移植できます。PLURがこの層に該当し、各エングラムをYAMLファイルとして保存します。id・statement・type・confidence・provenanceといったフィールドを持つ人間が読めるテキストであり、バージョン管理システムで差分を確認したり、削除の証明をしたりすることができます。
第2層は「オープンコア」です。ソフトウェア自体はオープンソースですが、クラウドホスティング版が提供するマネージドサービスではデータ形式が非公開・非移植になります。Mem0はGitHub上で約60,500スターを持ち、セルフホストが可能ですが、商用サービス（mem0.ai）では月額19〜249ドルのプランがあり、記憶データの実体はベクトルストアとエンティティリンクの組み合わせです。これは人間が直接差分を確認できない不透明な形式です。
第3層は「完全クローズド」です。記憶機能がモデルプロバイダーのインフラに組み込まれており、エクスポートの手段が存在しません。
データ形式のオープン性がアーキテクチャ選定に与える影響
この分類はエージェントシステムの非機能要件に直結します。特に可観測性・可監査性・移植性の3点から考えると、選択肢の差が明確になります。
可観測性の観点では、YAMLのような人間が読める形式は記憶の状態をログとして追跡できます。一方、ベクトルストア内部のembedding（テキストを数値ベクトルに変換した表現）は中身を直接解釈できません。問題が起きたときに「エージェントがなぜその判断をしたか」を追跡する難易度が、データ形式によって大きく変わります。
可監査性の観点では、GDPRや個人情報保護法への対応が設計段階から問われます。「特定の記憶を削除したことを証明できるか」という問いに答えられるのは、完全オープン層のみです。ベクトルストアや内部グラフ構造に埋め込まれた記憶を「確実に消した」と証明するのは技術的に難しい課題です。
移植性の観点では、ベンダーロックイン（特定のサービスに依存して乗り換えが困難になる状態）のリスクがあります。記憶データが特定のクラウドサービスに閉じている場合、エンジンを別のプロバイダーに移行しても記憶は引き継げません。エージェントの学習履歴を企業の資産として扱うなら、エクスポートが可能な形式かどうかは選定の条件になります。
LettaはGitHub上で約23,700スターを持つプロジェクトですが、マネージドの「Constellation」プラットフォームではエージェント状態がブロック形式で管理され、エングラム単位でのエクスポートはできません。Graphitiは時系列知識グラフ（時間軸に沿って関係性を管理するグラフ構造）を採用しており、Zepクラウドを通じて提供されますが、グラフの内部形式は公開されていません。
# PLURのエングラム形式の例（仕様に基づく構造）
id: eng-20240101-001
statement: "ユーザーはコードレビューのコメントを日本語で記述することを好む"
type: preference
domain: development
scope: user
confidence: 0.92
provenance: "2024-01-01T10:00:00Z / session-abc"このように形式が明示されていれば、Gitリポジトリで管理し、PRレビューのように変更を確認できます。
技術選定において「Apache-2.0だから安全」という判断は不十分です。ライセンスはコードの再利用に関する条件であり、データの所有権や移植性を保証しません。エージェントが蓄積する記憶を長期的に運用するなら、データ形式の仕様が公開されているか・セルフホスト時に完全なエクスポートが可能かを個別に確認する必要があります。
エングラムという概念はまだ標準化の途上にあります。PLURがApache-2.0で仕様（Engram Specification）を公開しているのは、この状況に対する一つの回答です。標準形式がなければ、「エングラム」という言葉自体がプロジェクトごとに異なる意味を持ち続けます。記憶の相互運用性を設計段階から考えるなら、どの仕様に乗るかの判断もアーキテクチャの一部です。