Agent Memoryの二つの哲学 — Hindsightの認識論、Synapsis Engineの運用原則

同じ課題、異なる前提。2025年末から2026年初頭にかけて、agent memoryカテゴリに二つの明確な解答が現れました。一つは「記憶とは何か」という認識論的な問いから始まり、もう一つは「記憶をどう運用するか」という工学的な問いから始まりました。両者を並べて見ていきます。

プロローグ：カテゴリが分化した瞬間

2025年まで「AIメモリ」という言葉は、概ねRAGの延長線上にありました。ベクタDBにチャンクを格納し、クエリ時にtop-kで取り出し、プロンプトに付与する。この方式の限界は誰もが認識していました。長期セッションでは矛盾が蓄積し、時間軸がなく、意見と事実が混在します。しかし、もっともらしい代替案が出るまでは「少しだけ精巧なRAG」同士の競争でした。

2025年12月14日、Vectorize.ioがVirginia TechおよびThe Washington Postとの共同研究でHindsight論文（arXiv 2512.12818, _"Hindsight is 20/20: Building Agent Memory that Retains, Recalls, and Reflects"_）を公開し、状況が変わりました。同時期、韓国ではNunchi AIがSynapsis Engineを基盤にNexusおよびAMCP（Agent Memory Continuity Protocol）のオープンスペックを発表していました。

両システムは同じ課題、すなわちLLMエージェントがセッションを超えて一貫した記憶を持つという課題を解決しますが、その根本の問いが異なります。その違いが全体構造を決定します。

Part 1. Hindsightのアプローチ：認識論的分離

Hindsightの出発点はこの一文です。

_"Current memory systems blur the line between evidence and inference."_

Hindsight論文 abstract

事実（evidence）と推論（inference）の境界が曖昧なまま記憶が蓄積されると、エージェントは自分がなぜそう信じるのか説明できず、矛盾が生じた際にどちらを優先すべきか判断根拠がありません。Hindsightの答えは、記憶を認識論的に分離した4つのネットワークです。

4つのネットワーク

ポイントは、Opinionがconfidence scoreを持ち、その意見を生み出したevidence（raw memories）を遡及できることです。「なぜそう思うのか？」と問えば、エージェントが証拠チェーンを提示できます。

3つの演算：Retain, Recall, Reflect

メモリ上で動作する演算も3つに分化します。

• Retain：会話ストリームから事実単位（narrative fact）で抽出し、エンティティ解決、4つのネットワークのいずれかに分類。
• Recall：クエリに対し4-way並列検索（semantic＋BM25＋graph traversal＋temporal filtering）。Reciprocal Rank Fusionで統合し、cross-encoderで再ランキング。
• Reflect：検索された記憶＋behavioral profile Θ（skepticism, literalism, empathyなどの性向変数）で応答生成。この過程で意見ネットワークが進化します。

Reflectは特に印象的です。従来のmemoryシステムはretain/recallのみでした。つまり「保存」と「取り出し」だけでした。Reflectは記憶上で推論し、その推論が再び記憶を更新します。これが論文で「memory as first-class substrate for reasoning」と呼ばれる理由です。

一文要約

Hindsight = 「記憶を事実／経験／意見／要約に分割し、推論を一級市民に昇格させた認識論的メモリアーキテクチャ」

Part 2. Synapsis Engineのアプローチ：運用原則

Synapsis Engineの出発点は別の一文です。

_"Memory systems fail in production not because they lack sophistication, but because they violate operational discipline."_

Synapsis Engineの開発過程で確認された経験的事実はこうでした。構造が複雑になっても基本法則を破ればメモリは崩壊する。これは数ヶ月にわたり6回繰り返したLongMemEvalベンチマークで何度も確認しました。したがってSynapsis Engineの根本は「より精巧な構造」ではなく、「守るべき法則」から始まります。

3大設計原則

Synapsis Engineのコアに刻まれている三つの原則は以下の通りです。

1. アトムを削除しない（Never delete atoms） 記憶は矛盾しても上書きされません。古い情報はsuperseded_by関係でリンクされて残ります。なぜなら時間軸を失うとエージェントは「いつからそう考えたのか」を説明できなくなるからです。

2. アトムを再配列しない（Never reorder atoms） 時間順序はメモリの基本です。重要度で再配列した瞬間、時間推論が壊れます。優先順位は検索結果でのみ反映し、保存は常に時間順にします。

3. 検索スコアに非類似度シグナルを注入しない（Never inject non-similarity signals into retrieval scores） 「最近だから」「confidenceが高いから」といった二次シグナルを類似度スコアに混ぜるとretrievalがバイアスされます。時間や信頼度はフィルタとして使い、スコアには使いません。この原則は単純に見えますが、多くのRAGシステムはこれを破っています。

Atomと7つの関係

Synapsis Engineは記憶を単一タイプatomで扱い、atom間の関係をatom_relationsテーブルに7種類で明示します。Nexusはこの構造を保存・サーブするリファレンスバックエンドに近いです。

これらの関係は検索時にgraph traversalで活用されます。「Aliceは前回何と言った？」という問いに対し、Aliceエンティティのatomsをtemporal_sequenceで辿り、contradict/updates関係を解決する形です。

AMCP — 標準レイヤー

この構造で最も知られていないが最も重要な部分がAMCP（Agent Memory Continuity Protocol）です。これはSynapsis Engine内部構造というより、エージェント間のメモリ交換のためのオープンスペックです。Apache 2.0で公開され、MCPがツール層の標準となったように、AMCPはメモリ層の標準を目指します。

この選択は単なる技術的決定ではなく、市場ポジションの決定です。「我々がカテゴリを定義する」という宣言です。

一文要約

Synapsis Engine = 「アトムを守る三原則＋関係グラフ＋オープンプロトコルで運用規律をコード化したメモリエンジン」

Part 3. 違いの根本：二つの問い

技術構造の違いは、実は最初に投げた問いの違いから生まれます。

Hindsightは人間のように記憶するエージェントを目指しました。そのため認識論的区分、信念の進化、性格変数、反省（reflect）など認知構造の用語で設計されています。論文の随所に「biomimetic」「human-like」「epistemic」という言葉が登場します。

Synapsis Engineはプロダクションで壊れないメモリエンジンを目指しました。そのため「削除禁止」「再配列禁止」「シグナル注入禁止」など運用原則の用語で設計されています。6回のベンチマーク反復で得た経験則です。

どちらが正しいのか？ どちらも自分の問いに正確に答えています。問いが違うだけです。

Part 4. 互いに学ぶべきこと

率直に言えば、並べてみるとそれぞれの空白が見えてきます。

HindsightがSynapsis Engineに指摘すること

① 単一atomタイプでは不十分。 Synapsis Engineでは「ユーザー住所はソウル」（world fact）と「ユーザーはPythonを好む」（opinion）が同じ信頼度で扱われます。両情報は寿命も検証方法も矛盾処理も異なるべきです。atomにはtypeフィールドがありますが、opinion/world/experienceの区分はありません。認識論的分化が必要です。

② Evidence chainが弱い。 Synapsis Engineにはconfidenceフィールドがありますが、その信頼度がどのraw atomsから導かれたか遡及する構造がありません。「なぜそう信じるのか」に答えられなければ、監査可能なメモリとは言えません。

③ Reflect演算がない。 Synapsis Engineはretain＋recallに強いですが、意見が時間とともに進化するメカニズムはまだ弱いです。これは「memory that learns」という約束を半分しか果たしていません。

Synapsis EngineがHindsightに指摘すること

① 運用原則が明文化されていない。 Hindsight論文はアーキテクチャ設計は明確ですが、「絶対にしてはいけない」法則はありません。削除／再配列／スコア汚染などのfailure modeがどう扱われるか曖昧です。実装者ごとに解釈が分かれる余地が大きいです。

② システム間互換標準がない。 Hindsightは自社アーキテクチャがうまく動けばそれで完結です。しかしエージェントAの記憶がエージェントBに渡るときは？会社がエージェントプロバイダーを変えるときは？AMCPのような層がなければロックインされます。

③ Self-host単一ノード前提はプライバシー重視企業には不十分。 HindsightはDocker一発で動く代わりに、raw dataとvector indexが同一ノードにあります。一方Nunchi AI側スタックはrawローカルとvectorサーバーをより分離できます。韓国や欧州のようにデータ主権が重要な市場ではこの差がより大きくなります。

交差点：収束は可能か？

技術的には可能です。両アプローチは補完的です。

• Synapsis Engineに認識論的atom分化（world/experience/opinion/observation）＋evidence chainを導入すればHindsightの強みを吸収できます。
• Hindsightに3大原則＋AMCP互換を導入すればSynapsis Engineの運用規律を得られます。

しかし戦略的には収束しないでしょう。両チームは異なる市場、Hindsightは英語圏Fortune 500、Nunchi AI側は非英語圏＋開発者コミュニティ＋標準を目指しているからです。競争というより並行進化が自然な結末です。

Part 5. 私たちの選択

Synapsis Engine開発者としてHindsightを数日かけて精読した後、私の結論はこうです。

① ベンチマーク数値競争はやめる。 Hindsightの91.4%は大きなbackboneを使った結果で、私たちがOpus 4.7で回しても超えられます。しかしHindsightも同条件ならさらに上を出すでしょう。この競争は意味がありません。同じbackboneでのアーキテクチャ貢献で数値を語るべきです。

② Synapsis Engineの空白を埋める。 次四半期ロードマップ：

• Atomタイプ分化（world/experience/opinion/observation）
• Evidence chain導入（atom derivation DAG）
• synapsis.reflect()プリミティブ追加
• Retrievalに4-way fusion拡張（現anchoringを5番目の戦略として含む）

③ 3大原則はさらに強く推進する。 Hindsightに私たちが吸収すべきものがあるように、私たちにもHindsightが吸収すべきものがあります。その中で最も明確な資産が3大原則です。これは今後も私たちの理論的アイデンティティとして持ち続けます。

④ AMCPはSynapsis EngineやNexusより大きなポジション。 Hindsightと競争するのではなく、HindsightもAMCPを実装できる構造にすべきです。MCPの成功公式、「Anthropicが作ったがOpenAIも使う」をメモリレイヤーで再現します。

⑤ オープンソース化する。 AMCPは既にオープンです。Synapsisコアもオープン化します（MIT）。エンタープライズ機能、MaaSのSSO/audit/SLA、Nexus Cloudのマネージド運用は商用で維持します。オープンコア戦略です。閉じている理由はありません。Hindsightが既に証明したように、オープンは実装複製リスクより信頼獲得の利益が大きい。

結論：二つの道

Agent memoryというカテゴリが分化する瞬間を私たちは生きています。

Hindsightは「記憶とは何か」を問い、認知構造の言語で答えました。 Synapsis Engineは「記憶をどう運用するか」を問い、運用原則の言語で答えました。

両者は同じ山を異なる側から登っています。頂上が同じか異なるかはまだ分かりません。ただ確かなのは、一方だけの答えでは不完全だということです。

Nunchi AIはこの二つの道の交差点で自分たちの役割を見出します。運用原則を守りつつ認識論的深みを加え、韓国語や非英語圏で標準を定義し、オープンソースでカテゴリリーダーシップを取ります。

長い目で見れば、私たち両者が敗れるシナリオは「closed RAG as-a-service」がこのカテゴリを覆い尽くす場合です。だからこそHindsightチームには競争よりも健全な競争への感謝が先立ちます。同じカテゴリで異なる答えを出すチームが存在すること自体、カテゴリそのものが生きている証拠です。

---

参考

• Hindsight論文: arXiv 2512.12818
• Hindsightコード: github.com/vectorize-io/hindsight (MIT)
• AMCPスペック: github.com/goldberg-aria/amcp (Apache 2.0)
• Nexus: nunchiai.com

---

_本記事はNunchi AIの視点で執筆されました。Hindsightチームの貢献に敬意を表し、両アーキテクチャを並列して考察します。_