エージェントメモリをめぐる議論が大きくなっていますが、私はその問いの立て方自体が間違っていると思っています。
最近、LettaのCTOであるSarah Woodersは「メモリはプラグインではない。ハーネスそのものだ」と書きました。続いてLangChainのCEOであるHarrison Chaseは、ハーネスを自分で持っていなければメモリも自分のものにはならないと主張しました。問題の診断としては、二人とも正しいです。ですが、解決策については二人とも間違っていると私は考えています。
彼らが見つけた問題
診断自体は正確です。AnthropicのManaged Agentsは、すべてをAPIの裏側に閉じ込めます。エージェントのメモリはそのプラットフォームにロックされます。OpenAIのCodexは、その生態系の外では使えない暗号化されたcompaction summaryを生成します。モデル提供者がメモリを所有するようになると、乗り換えコストは急激に高くなります。
Harrisonは象徴的な話を紹介しています。自分のメールアシスタントが誤って削除され、同じテンプレートから作り直したのに、体験が劇的に悪くなったという話です。学習された好み、文体、文脈がすべて消えてしまったのです。
これは現実の問題です。メモリこそが、エージェントを「自分のもの」にするものだからです。メモリがなければ、どんなエージェントも簡単に置き換え可能です。
私が同意しない点
Sarahの解決策は、メモリをもっと深くハーネスに埋め込むことです。Harrisonの解決策は、ハーネスをオープンソース化することです。
どちらも、メモリとハーネスは切り離せないという前提に立っています。私はそうは思いません。むしろ、責務の異なる二つの層を混同することこそが、ロックインを生む原因だと思っています。
Sarahがハーネスの「見えない決定」を挙げるとき、何がcompaction後に残るのか、どうやってコンテキストをロードするのか、何がqueryableなのかを語るとき、実際には二つのことを同時に語っています。
コンテキスト管理: 何をプロンプトに入れるか、トークンをどう配分するか、いつcompactionするか、ツール結果をどう提示するか。これは本当にハーネスの仕事です。
メモリの保存とrecall: セッションをまたいで知識を保存し、関連する履歴を取り出し、ツールやワークフローを越えて連続性を保つこと。これは別レイヤーにできるし、そうすべきです。
ハーネスは 何を記憶するか を決めます。メモリレイヤーは どう保存し、どう取り出すか を決めます。両者は関心もライフサイクルも異なります。
なぜ分離が重要なのか
ハーネスは一時的なものです。Claude Code、Cursor、Windsurf、Codex、Aider、景色は数か月ごとに変わります。もしメモリがハーネスに埋め込まれているなら、移行のたびに最初からやり直しです。Harrisonの削除されたメールアシスタントの話は、まだ軽い方です。もっと深刻なのは、企業が6か月分のエージェント知識をあるハーネスに埋め込み、そのハーネス自体が廃止されるケースです。
オープンソースのハーネスも、この問題を完全には解決しません。Deep AgentsはMongo/Postgres/Redisプラグインにメモリを保存しますが、メモリスキーマ、recallロジック、atom構造はすべてDeep Agents固有です。別のハーネスへ移るにはカスタムETLを書く必要があり、しかも移行先がその知識を解釈できる保証もありません。
本当に必要なのは、どのハーネスでも話せるメモリ契約です。
AMCP: メモリプロトコル
だから私はAMCP(Agent Memory Continuity Protocol)を作っています。ツールのためのMCP、エージェント協業のためのA2Aと並ぶ、エージェントメモリのための第三のインフラレイヤーとして位置づけるオープン標準です。
AMCPは、エージェントがメモリを保存しrecallする方法について、ベンダー中立の契約を定義します。一つのitem shape。一つのrecallインターフェース。一つのexport format。AMCPを話せるどんなハーネスでも、どんなAMCP互換バックエンドにも読み書きできます。
仕様はApache 2.0で github.com/goldberg-aria/amcp にあります。
3122: このアーキテクチャが成り立つことの証明
理論だけなら安く作れます。分離されたメモリが、埋め込み型メモリと同じくらい深く統合できることを証明するために、私はAMCPネイティブでモデル中立なコーディングハーネス3122を作りました。
3122は意図的に二つの層を分けています。
Continuity Runtime State(ハーネス所有、ローカルに残る):
- セッション transcript
- Trajectory state (goal -> attempt -> failure -> verification -> next-step)
- モデル切り替えのための handoff snapshot
- ファイル単位の working memory
- 繰り返しワークフローからの skill candidate detection
Portable Memory(AMCP所有、移動可能):
- すべてのバックエンドで一つのAMCP item shapeを使用
local-amcp: 手元のSQLitenexus-cloud: Nexusベースのホスト型バックエンドthird-party-amcp: 任意のAMCP互換サービス向け拡張スロット
ハーネスは、Sarahが挙げたすべてのコンテキスト判断を行います。何をプロンプトに入れるか、セッションが長くなったときにトークンをどう配分するか、compaction時に何を残すか。ですが、その判断の 結果 はAMCPを通って可搬なメモリitemとして流れていきます。
それによって可能になるのは次のようなことです。
# メモリを書き出す
3122 memory export --format amcp-jsonl --output my-knowledge.jsonl
# ホスト型バックエンドへ移す
3122 memory migrate --from local-amcp --to nexus-cloud
# ワークスペースを消して作り直しても、再接続すればメモリは残る
3122 memory recall 10
ハーネスのインスタンスは死んでもいい。メモリは生き残ります。
リポジトリは github.com/goldberg-aria/3122-harness にあります。
「深い統合」への反論
Sarahの主張の最も強い形は、分離されたメモリレイヤーは埋め込み型ほど深く統合できない、というものです。3122の設計は、まさにそこに対する反証です。
Trajectory-aware recall: 作業の途中では、recallは現在のtrajectoryに関係するatomを優先します。今触っているファイル、遭遇したエラー、走らせたverification手順が基準になります。これは単なるsimilarity searchではありません。ハーネスの運用文脈が、何をrecallするかを形作ります。
Budget-aware context: 長いセッションは段階的にdegradeします。コンテキスト予算が縮むと、3122はconversation recallを最初に落とし、次に古いmemory、その次にrecent history、最後にinstructionsを落とします。ここに参加するためにメモリレイヤーが埋め込まれている必要はありません。必要なのは予算シグナルを受け取ることです。
Handoff continuity: セッションの途中でモデルを切り替えると(/model claude-sonnet-4-20250514 -> /model gpt-4.1)、3122はhandoff snapshotを保存し、新しいモデルの最初のターンに一時的なコンテキストブーストを与えます。可搬メモリレイヤーはセッション間の連続性を提供し、ハーネスはセッション内の連続性を提供します。きれいに分離しながら、必要なものは全部カバーしています。
Compaction without loss: ハーネスがコンテキストをcompactionするとき、落としたものをメモリレイヤーへのシグナルとして送れます。何も静かには失われません。ハーネスの「見えない決定」は、見える決定になり、回復可能な決定になります。
ロックイン論を逆さにすると
Harrisonは、メモリがロックインを生むからオープンハーネスが必要だと言います。私は逆に考えます。メモリがロックインを生むのは、まさにハーネスと結びついているからです。
メモリをハーネスから切り離し、プロトコルを標準化すれば、ロックインは消えます。今日はClaude Code、明日はCursor、来週はCodexを使っても、積み上げた知識を持ち運べます。すべてのハーネスがオープンソースだからではありません。すべてがAMCPを話すからです。
これはウェブが機能したのと同じパターンです。HTTPはオープンソースのブラウザを要求しませんでした。どのブラウザでも実装できるオープンプロトコルを要求したのです。AMCPはエージェントメモリにとってのそれです。
エコシステム
現在のスタックはこうです。
| レイヤー | コンポーネント | 役割 |
|---|---|---|
| 標準 | AMCP | ベンダー中立のメモリ契約 |
| バックエンド | Nexus | エージェント/開発者向けリファレンスAMCPバックエンド |
| バックエンド | Norfolk | 個人の生涯メモリ |
| バックエンド | MaaS | エンタープライズ向けメモリインフラ |
| クライアント | 3122 | この契約が動くことを証明するリファレンスハーネス |
Nexusは最初のホスト型バックエンドです。ですがAMCPは、誰でもバックエンドを作れるように、またどのハーネスでもクライアントになれるように設計されています。目標はClaude CodeやDeep Agentsを置き換えることではありません。あらゆるハーネスに、それ自身より長く生きるメモリレイヤーを与えることです。
次に作るもの
分離は機能します。次のステップは、この境界をもっと豊かにすることです。
- Trajectory auto-promotion: 成功した作業パターンを自動でportable memory atomに昇格させる
- Budget-negotiated recall: ハーネスがメモリバックエンドに「予算は2000トークンだ。最も重要なatomだけ返してくれ」と伝えられるようにする
- Compaction checkpoints: ハーネスがcompaction時に何を落としたかをAMCPに伝え、見えなかったものを見えるようにする
- Capability advertisement: 最小実装でも動くようにしつつ、完全実装は高度な機能を使えるよう、AMCPバックエンドが自分の能力を宣言する
試してみる
- AMCP spec: github.com/goldberg-aria/amcp
- 3122 harness: github.com/goldberg-aria/3122-harness
- Nexus backend: まもなく nunchiai.com で公開
メモリはあなたのものであるべきです。ハーネスベンダーのものでも、モデル提供者のものでもなく、あなたのものです。