Nunchi AI memory ecosystem architecture

AIエージェントはツール利用がどんどん上手くなっています。ウェブを検索し、APIを呼び、コードを書き、ファイルを管理できます。ですが、先週何を話したか、プロジェクトをまたいでどんな意思決定をしてきたか、好みがどう変わってきたかを尋ねると、何も返ってきません。

ツール層にはMCPがあります。協業層にはA2Aがあります。メモリ層にはまだ何もありません。どのエージェントも、どのセッションもゼロから始まります。

Nunchi AIは、その欠けている層を作るために存在します。

問題を一文で言うと

あなたのAIの記憶は、一つのツール、一つのセッション、一つのベンダーの独自フォーマットに閉じ込められていて、コンテキストを切り替えた瞬間に消えてしまいます。

これは小さな不便ではありません。メモリこそが、汎用AIを あなたのAI に変えるものだからです。永続的で可搬なメモリがなければ、どんなエージェントも、同じモデルアクセスと同じツール統合を持つ競合に簡単に置き換えられます。メモリが moat です。

そして今、この問題を解こうとするほとんどすべての試み、Claudeの組み込みメモリ、ChatGPTのメモリ、Mem0、Zep、MemPalaceは、知識を一つのプラットフォームの中に閉じ込めます。ツールを変えれば履歴を失い、モデルを変えればやり直しです。これはデータサイロで何度も見てきたロックインの再来ですが、今回閉じ込められているのは あなたが蓄積した知性 そのものです。

五つのコンポーネント、一つのアーキテクチャ

Nunchi AIエコシステムは、シンプルな確信の上に立っています。メモリは単一製品の機能ではなく、インフラであるべきだということです。

このエコシステムは、四つのレイヤーにまたがる五つのコンポーネントで構成されています。それぞれが一つの仕事を担います。合わせると、どの単一製品も端から端まで独占しない完全なメモリスタックになります。

Layer 1: Synapsis Engine — 基盤

どんなメモリシステムも、まず一つの問いに答えなければなりません。散らかって長い会話を、どうやって構造化された知識に変えるのか。

Synapsisはその問いに答えるatomizationエンジンです。生の会話を、type、confidence、temporal scope、domain、そして他のatomとの関係リンクを持つ離散的な知識単位、atomへ分解します。一つの会話からは例えばこんなatomが生成されます。

これは生の会話テキストをそのまま保存して後で検索するのとは根本的に違います。Raw storageは retrieval、「authを議論した会話を探せ」に最適化されます。Atomizationは 理解 に最適化されます。「今のauth providerは何で、なぜそうしたのか」

Synapsisはこのエコシステムの三つのバックエンドすべてを支えています。どの製品を使っていても、一貫した知識表現を保証する共通基盤です。

広範なベンチマーク、LongMemEvalの6回イテレーションを通じて、三つの設計法則が見えてきました。

  1. Atomは決して削除しないこと。temporal markerで無効化すること
  2. Atomの順序は決して入れ替えないこと。挿入順そのものが暗黙の時間信号になる
  3. Retrieval scoreに非類似度シグナルを注入しないこと。Recall経路はきれいに保つこと

これらは理論上の原則ではありません。実運用テストから出てきた経験的な知見です。

Layer 2: AMCP — 契約

AMCP（Agent Memory Continuity Protocol）は、ハーネスとバックエンドのあいだに置かれるオープン標準です。Apache 2.0ライセンスで、次を定義します。

核心となる洞察はこうです。メモリは 製品 ではなく プロトコル であるべきだ。MCPが、どのエージェントでもどのツールでも使えるようにツール接続を標準化したように、AMCPは、どのハーネスでもどのメモリバックエンドでも使えるようにメモリ接続を標準化します。

つまり:

AMCPは portability 問題への答えです。メモリはツールベンダーのものではなく、あなたのものです。

Spec: github.com/goldberg-aria/amcp

Layer 3: 三つのバックエンド、三つの利用者

三つのバックエンドはすべてAMCPを実装し、Synapsis上で動いています。ですが、それぞれ異なるユーザーと異なるニーズを担当します。

Nexus はエージェントと開発者のためのリファレンスバックエンドです。Atomization pipeline、recallアルゴリズム、ベンチマークが最初に走る場所です。永続メモリが必要なエージェントを作るなら、接続先はNexusです。AMCP endpoint（/v1/amcp/remember, /v1/amcp/recall, /v1/amcp/export, /v1/amcp/import）を公開し、atom保存、relation管理、scope-aware retrieval の複雑さを引き受けます。

Norfolk は個人知識向けバックエンドです。Nexusがエージェントワークフロー向けに最適化されているのに対し、Norfolkは人間の生涯にわたる知識、ノート、会話、文書、そしてそのあいだのつながりに最適化されています。CLI-first構成で、サーバーが保存と検索を担当し、ウェブUIが閲覧と整理を担当し、モバイルが収集を担当します。Citation graphと provenance grading によって、あらゆる知識がどこから来たかを追跡できます。

MaaS（Memory as a Service）はエンタープライズ向け配備モデルです。Nexusと同じ atomization と recall 能力を提供しつつ、multi-tenant isolation、team-level scoping、enterprise knowledge API path を備えます。TravelSpeak（語学学習アプリ）や IndiePulse（AI運営の編集マガジン）のような製品がMaaS上で動いており、ユーザーは仕組みを意識しなくても、時間とともに良くなる持続的なメモリの恩恵を受けます。

三つの製品。一つのatom shape。一つのプロトコル。一つのエンジン。

Layer 4: 3122 — リファレンスクライアント

動くクライアントのないプロトコルは、ただのPDFです。3122はAMCPが実際に機能することの証明です。

3122は terminal-first で model-neutral なコーディングハーネスです。組み込みモデルはありません。Anthropic、OpenAI、OllamaなどをAPIでつなぐか、Claude CodeやCodex向けの認証済みアダプタを使います。残り、プロンプト、権限、ツール実行、セッション継続、バックエンド選択はハーネスが担当します。

3122における重要な設計判断は、二種類の状態を明示的に分けていることです。

Continuity Runtime State はハーネスにローカルで残ります。

Portable Memory はAMCPを通って流れます。

ハーネスは、どのコンテキストをプロンプトに含めるか、セッションが長くなったときにトークンをどう予算管理するか、compaction 時に何を残すか、といったすべての context management を決めます。しかし、その決定の 結果 は portable memory へ流れていきます。ワークスペースを消し、作り直し、同じバックエンドへ再接続しても、知識はそのままです。

3122 memory export --format amcp-jsonl --output my-knowledge.jsonl
3122 memory migrate --from local-amcp --to nexus-cloud

Repo: github.com/goldberg-aria/3122-harness

なぜこのアーキテクチャなのか

今の業界のエージェントメモリ論は、二つの立場のあいだで止まっています。

一方は、メモリはハーネスに埋め込まれていなければならない、context managementと切り離せないほど密接だからだと言います。Letta/MemGPT系の見方です。問題は、メモリがハーネスの選択と一緒に死ぬことです。

もう一方は、ハーネスをオープンソース化すればいいと言います。LangChain/Deep Agents系の見方です。問題は、オープンソースのハーネスでも独自メモリ形式を使っていることです。ハーネスを替えれば、カスタムETLを書いて、変換で何も失わないことを祈るしかありません。

Nunchi AIエコシステムは第三の立場を取ります。関心事を分離し、インターフェースを標準化する。

ハーネスは context management を持ち、メモリレイヤーは persistence と recall を持ち、AMCPがそれらをつなぎます。どちらも閉じたシステムではないので、どちらもロックインを作れません。

これはインターネットを作ったのと同じパターンです。HTTPはオープンソースのブラウザを要求しませんでした。どんなブラウザでも実装できるオープンプロトコルを要求したのです。AMCPはエージェントメモリにとってのそれです。

現在の状況

次に来るもの

ハーネスとメモリの分離は、すでに機能しています。次の段階は、この境界をより豊かにすることです。

Trajectory auto-promotion — ハーネスの中でうまくいった作業パターンを、自動で portable memory atom に昇格させる。

Budget-negotiated recall — ハーネスがメモリバックエンドに「予算は2,000トークンだ。最も重要なatomだけ返してほしい」と伝えられるようにする。

Compaction checkpoints — ハーネスがコンテキストを compact したとき、何を落としたかをAMCPに伝え、見えない判断を見える、回復可能なものにする。

Capability advertisement — AMCPバックエンドが接続時にサポート能力を宣言し、最小実装でも動きつつ、完全実装では高度機能を解放できるようにする。

この賭け

私たちは、メモリがエージェントスタックで最も重要な層になると見ています。ツールはすでにコモディティ化しています。どのエージェントでもどのAPIでも呼べる。モデルもコモディティ化しています。能力は収束しつつあり、価格で競争しています。コモディティ化していないものは 蓄積された理解 です。エージェントが数か月、数年の相互作用の中で、あなたや、あなたのプロジェクトや、チームや、好みについて築いていく知識です。

その知識はあなたのものであるべきです。モデル提供者のものでも、ハーネスベンダーのものでも、誰か他人のサーバー上の独自データベースに閉じ込められるものでもなく。

それを作っているのが Nunchi AI です。

---

AMCP: github.com/goldberg-aria/amcp 3122: github.com/goldberg-aria/3122-harness Nunchi AI: nunchiai.com