ポータブルエージェントメモリ：Claude Code、Cursor、Codex、Gemini間でコンテキストを持ち運ぶ

プロジェクトの途中でClaude CodeからCursorに切り替えると、エージェントはすべてを忘れてしまいます。先週下したアーキテクチャの決定、すでに修正したバグ、コミットの書き方の好み——コンテキストは移動せず、最初のツールの中に閉じ込められたままです。ポータブルエージェントメモリはこの問題を解決するパターンです。エージェントが共有する単一のメモリレイヤーを用意することで、ツールを切り替えるたびにゼロから始めるのではなく、コンテキストがClaude Code、Cursor、Codex、Gemini CLIをまたいで引き継がれます。

このガイドでは、ポータブルエージェントメモリとは何か、構築するための主なアプローチ、そのトレードオフ、そして再びロックインされないようにする方法を説明します。

ポータブルエージェントメモリとは？

ポータブルエージェントメモリとは、決定事項、修正内容、規約、事実といった永続的なプロジェクトコンテキストを保存するストアであり、特定のエージェントの外側に存在し、すべてのエージェントから読み取り可能です。各ツールが独自のサイロ化されたメモを保持する代わりに、エージェントが共有プールに対して読み書きを行います。

解決する問題はロックインです。組み込みメモリはコンテキストを1つのコーディングエージェントに縛り付け、ツールを切り替えると置き去りにされます。優れたCLAUDE.mdはCursorには何の役にも立たず、CursorのノートパッドはCodexには何の役にも立ちません。現在、ほとんどのチームが複数のエージェントを使用しているため、この取り残されたコンテキストは現実的かつ繰り返し発生するコストです。

ポータビリティには2つの意味があります：

• クロスツール： 同じメモリがClaude Code、Codex、Cursor、Gemini CLI、およびそれを読み取れるあらゆるツールで機能する。
• ベンダーロックインなし： ツールやメモリレイヤー自体を離れても、知識を再構築せずに済む。

ツールを切り替えるとコンテキストが取り残される理由

各エージェントは独自のフォーマットと場所にメモリを保存します。Claude Codeには独自のメモリシステムがあり、Cursorには別のシステムがあります。異なるエージェントが異なる情報を知っている場合、次のセッションではすでに回答した質問を再度尋ねたり、以前に犯したミスを繰り返したりします。

根本的な問題は、フラットなツール固有のメモリが複数のエージェントにまたがってスケールしないことです。あるクライアント向けに書かれたメモは、次のクライアントには見えません。それをツールの切り替えのたびに、新しいチャットウィンドウのたびに、異なる設定を使うチームメンバーのたびに掛け合わせると、同じコンテキストが何度も再構築されることになります。

ポータブルメモリの主なアプローチ

現在使われている大きなパターンは3つあります。主にコンテキストの保存方法とエージェントへの接続方法が異なります。

1. MCPベースのメモリサーバー

最も一般的なアプローチは、Model Context Protocol（MCP）を通じてすべてのエージェントにメモリサーバーを接続することです。MCPはあらゆるツールが任意のエージェントに接続するための標準的な方法を提供するため、1つのメモリレイヤーが同じプロトコルを通じて多くのクライアントにサービスを提供できます。

agentmemoryやMemorixなどのオープンソースプロジェクトがこのアプローチを採用しています。agentmemoryは、Claude Code、Cursor、Gemini CLI、Codex CLI、およびあらゆるMCPクライアント向けの永続メモリとして自身を説明しており、グローバルにインストールされMCPサーバーとして登録されます。MemorはローカルファーストのShared Memory（共有メモリ）レイヤーで、プロジェクトメモリを1つのチャットウィンドウやツールの内部ではなく、Gitプロジェクト配下に保持します。

メリット：一度セットアップすれば、MCP対応のすべてのエージェントが同じメモリを参照できます。 トレードオフは、実行中のサービスと各クライアントでのMCPサポートへの依存です。

2. フラットファイル・ベンダーニュートラルなボールト

より軽量なアプローチは、データベースとサーバーを完全にスキップします。Agent Memory OSは、プレーンなMarkdownファイルといくつかの小さなスクリプトで構築されたポータブルメモリシステムで、データベースも実行するサービスも不要です。ファイルを読み取れるClaude Code、Codex、Gemini CLI、Cursor、またはその他のツールで動作し、ツールを切り替えてもセットアップを再構築しなくて済むよう、意図的にベンダーニュートラルなIDファイルを保持します。

ここでの検索は通常、埋め込みベクトルではなく字句的なもので——ルーターがMarkdownメモをクエリと照合してランク付けし、最も関連性の高いものを返します。メリットはシンプルさ、ポータビリティ、インフラ不要であること。トレードオフは、大規模なナレッジベースではベクトルバックシステムほど高度な検索ができないことです。

3. ホスト型・プロトコルバックのメモリレイヤー

3番目のグループは、暗号化、検証可能なストレージ、SDKなどの機能を備えたマネージドメモリを提供します。これらはエージェントが接続する耐久性のあるポータブルレイヤーを目指しており、多くの場合SDKとMCPインテグレーションの両方を備え、アプリやセッションをまたいでコンテキストが移動できます。

メリットは運用作業の削減と豊富な組み込み機能です。トレードオフは、コンテキストを外部サービスに委ねることと、今度はメモリレイヤー自体での新たなロックインに注意が必要なことです。

選択方法——そして再びロックインされないために

ポータビリティの目的は自由に切り替えられることです。その自由を保つために：

• オープンフォーマットを優先する。 Markdownボールトとドキュメント化されたスキーマは、読み取り、移行、検査が容易です。プロプライエタリなバイナリはそうではありません。
• エクスポートパスを確保する。 採用するものが何であれ、メモリをエクスポートして別の場所に移動できることを確認してください。
• メモリをツールではなくプロジェクトにスコープする。 Gitプロジェクト配下に存在するメモリはリポジトリと一緒に移動し、ツールの切り替え、IDEの変更、新しいチャットウィンドウを生き延びます。
• 「3回目のルール」をシグナルとして扱う。 エージェントが同じミスを3回目に犯したとき、それはモデルの問題ではなく、メモリメモが不足しているサインです。繰り返す決定や修正を耐久メモリに吸収してください。
• シークレットを保存しない。 シークレットがどこに存在し、どのように使われるかを記録してください——値そのものは決して記録しないでください。

オプションを比較するための簡単な表：

今後の方向性

ポータブルメモリは、目新しい機能というよりも、基本的な期待事項として急速に定着しつつあります。チームが複数のエージェントを並行して実行するようになると——ターミナル作業用に1つ、IDE内に1つ、スクリプト用に1つ——メモリレイヤーはバージョン管理と同様の共有インフラになりつつあります。勝者となるのは、オープンで、ポータブルで、離脱しやすいレイヤーです。

記憶するマルチエージェントワークフローを構築する

ポータブルメモリは、複数のエージェントを同時に実行しているときに最も重要になります——それはまさにマルチエージェントワークフォースが行うことです。Eigentは、実際のワークフローでAIエージェントのチームを調整するオープンソースのローカル「Cowork」デスクトップアプリです。ユーザー、ワークスペース、またはセッションにスコープできるMemoryと、耐久性のあるマルチターン実行を追加することで、保持する価値のあるコンテキストが取り残されることなく意図的に引き継がれます。ツールを切り替えるたびにプロジェクトを再説明することに疲れたなら、Eigentをダウンロードして、エージェントに共有の記憶場所を与えてください。