ai-memory：Claude Code や Codex 間で長期記憶を共有

背景と概要

いまのコーディングエージェントには、たいてい何らかの記憶機能が付いています。Claude Code はメモを取り、Cursor も一部の事柄を覚えます。ほかのプラットフォームも同様の機能を足し続けています。ただ、これらの記憶には共通の限界があります。メモは 1 台のマシンの中にあり、1 つのエージェントにしか属しません。ツールを替えたり、作業を同僚に渡したりすると、メモは視界から消えてしまいます。そのたびに、アーキテクチャの説明、すでに失敗した方法、未解決の問題を最初から話し直すことになります。

ai-memory は、まさにこの隙間を狙ったプロジェクトです。Rust で書かれたオープンソースで、rust-toolchain.toml、リリース版、公式サイト aimemory.sh、オープンソースライセンスを備えています。GitHub のスターは一万に迫っています。新しいエージェントになろうとはせず、あらゆるエージェントの下に置く共有の長期記憶という立ち位置です。

目標は明快です。タスクの途中で Claude Code を終了し、同じディレクトリで OpenAI Codex を起動します。すると Codex は、説明し直さなくてもそのまま作業を続けられます。この場面がプロダクトの中心にあります。

深掘り分析

ai-memory はどのようにして Claude Code と Codex に 1 つの記憶を共有させるのでしょうか。答えは 4 つの要素にまとめられ、それぞれに設計上の理由があります。 1 つ目はエージェント横断の対応範囲です。Claude Code、Codex、Cursor、Gemini CLI、OpenCode、Grok、Devin、Kimi、Kiro など 20 以上のハーネスが、同じ記憶に情報を集めます。進捗は型付きの引き継ぎプロトコルで渡されます。引き継ぎにはそれぞれ所有者が付き、引き受けられるのは一度だけです。前のエージェントがどこまで進めたか、何が失敗したか、何が未解決かが記録されます。一度しか引き受けられない仕組みのおかげで、2 つのエージェントが同じ作業を誤って同時に拾うことはありません。

2 つ目は `ai-memory run` です。エージェントを起動するとき、要約だけでなくセッションそのものを運びます。たとえば Claude Code を終えたあと `ai-memory run codex` を実行すると、Codex は共有ワークフローに加えて、Claude から見えていたネイティブ履歴の、私的で一時的なローカル投影を受け取ります。この投影は、起動バンドルでは削られてしまう正確な細部を補います。リモートサーバーが受け取るのはハーネスとセッションの識別子だけで、ローカルの転写ファイルのパスも本文も届きません。 3 つ目はデータの形です。記憶の正本は git 管理の wiki で、すべてふつうの .md ファイルです。grep をかけたり、Obsidian で開いたり、手で編集したり、rsync で複製したりできます。データベースは派生インデックスにすぎず、ファイルからいつでも再構築できます。保守が必要なベクトルストアはなく、バイナリの中に閉じ込められた内容もありません。 4 つ目は静かな収集です。ライフサイクルフックがプロンプト、ツール呼び出し、セッションの境界を記録します。型付きのプライバシー境界でデータを整えてから保存し、サーバーが読めるページに仕上げます。既定の経路では LLM 呼び出しがゼロで、収集、検索、引き継ぎに API キーは要りません。記憶は調整可能な段階的スケジュールで減衰し、この処理も LLM に頼りません。

業界への影響

想定される使い方は 4 つあります。いちばん典型的なのは、作業の途中でツールを替える場面です。Claude Code で作業の半ばに、利用枠や好みの問題にぶつかったとします。そこで Codex に切り替えると、次のエージェントが引き継ぎメモをそのまま受け取ります。 2 つ目はプロジェクトをまたぐ設定です。よく使うパッケージマネージャー、テストの置き方、設計の癖を記した小さな個人プロファイルが、新しいリポジトリのセッション開始時に届きます。優先度は各リポジトリの規則ファイルより低く、あくまで既定値として働きます。単独利用では最初から有効で、共有サーバーでは自分で有効にする必要があり、人ごとに分離されます。詳細は docs/cross-project-profile.md にあります。

3 つ目はマシンをまたぐ作業です。記憶は自分で動かすサーバーに置かれます。同じノート PC でも、自宅のサーバーでも、別の場所でもかまいません。デスクトップで止めたプロジェクトを、ノート PC で同じ知識と同じ未解決の問題を持ったまま再開できます。 4 つ目はチーム共有です。全員が同じサーバーを指すと、1 人のセッションで得た知見をすべてのエージェントが検索できます。知識はプロジェクト単位で共有され、個人の引き継ぎは非公開のままです。複数ユーザー認証、個人ごとの帰属、監査ログは組み込み済みで、有料プランの機能ではありません。 業界全体で見ると、意味は「記憶の持ち主が変わる」ことにあります。記憶は特定ベンダーの私的機能ではなく、エンジニアリングチーム自身が握る基盤になります。エージェントが増えれば乗り換えは日常になり、1 社に縛られたい人はいません。正本をプレーンテキストと git に置けば、記憶はレビューでき、持ち運べ、既存のバージョン管理に組み込めます。追跡可能性を重んじるチームには魅力的です。 プライバシー設計も評価できます。型付きの境界と、run モードで識別子だけを送る仕様は、機微なコード文脈を扱う際に欠かせない抑制です。

今後の展望

注意したい点がいくつかあります。20 以上のハーネスに対応するということは、各社のフックやセッション形式を追い続ける必要があるということです。互換性の維持コストは小さくありません。チーム共有モードでは、どの内容を検索可能にし、権限をどう分けるかを利用者自身が見極める必要があります。また、ここで紹介した README の内容は機能の一部にとどまり、減衰ポリシーなどの詳細は公式ドキュメントで確認すべきです。

次に見ておきたい点は 2 つあります。1 つは、引き継ぎプロトコルがより多くのツールに事実上の標準として認められるかどうかです。もう 1 つは、LLM を使わない既定の経路が、大規模リポジトリの検索でどこまで通用するかです。ベクトルストアなしで、プレーンファイルの検索が規模に耐えられるかが問われます。複数のコーディングエージェントを使う個人やチームにとって、ai-memory は説明し直しの手間に対する、具体的で中身を確かめられる答えです。真価が出るのは日々の利用の中で、2 番目のエージェントが 1 番目の仕事を説明なしで本当に続けられる回数に表れるでしょう。