次のコーディングエージェントは、ゼロから始めるべきじゃない

コーディングエージェントを乗り換えるときに一番高くつくのは、サブスクの料金じゃない。プロジェクトをもう一度説明し直す、あの 1 時間だ。

どのファイルが重要で、どのアプローチがすでに失敗していて、なぜテストがその構成になっていて、中途半端なブランチが何をしているのか。Claude Code は何も知らない。Codex も Cursor も Gemini CLI も同じだ。どれも空のコンテキストウィンドウと、丁寧な「お手伝いします」という態度から始まる。

ai-memory はそれを何とかしようとする Rust 製のバイナリで、その設計上の選択のほうが機能一覧より面白い。

記憶はひとつ、ハーネスはたくさん

売り文句は、20 あまりのエージェントハーネス——Claude Code、Codex、Cursor、Gemini CLI、OpenCode、Grok、Devin、Kimi、Kiro など——が 1 つの共有メモリストアから読む、というもの。ひとつで作業して、途中で止め、同じディレクトリで別のやつを開くと、前の続きから進めてくれる。

仕組みは型付きハンドオフだ。エージェントが生成して「たぶん正確だろう」と願う要約ではなく、オーナーを 1 回しか名乗れない明示的な記録。この最後の制約が肝で、2 つのエージェントが同時に「自分が続きをやっている」と思うことがなくなるし、放置されたハンドオフも黙って消えずに見えるようになる。

プロジェクトをまたぐ層もある。パッケージマネージャー、テストの配置、モジュールの組み方の好みといった作業設定が新しいリポジトリにも付いてくるので、clone したばかりの場所でも「どこでも成り立つこと」をゼロから始めずに済む。

真実の源は Markdown

ここが議論のしがいのある設計判断だ。

エージェント向けの記憶システムといえば、たいていは埋め込みベクトルだ。履歴を分割し、埋め込みにして、ベクトルデータベースに入れ、類似度で検索する。動きはするが、問題が 3 つある。読めない、diff が取れない、そして検索が不透明すぎて、間違った結果が返ってきたときに理由がさっぱり分からない。

ai-memory はそれを反転させる。真実の源はただの Markdown wiki で、git でバージョン管理されている。SQLite のインデックス——全文検索、エンティティ、埋め込み——は派生物で、再構築できる。データベースを消しても失うものはない。

この 1 つの選択がいろいろなものを買ってくれる。wiki を grep できる。Obsidian で開ける。間違った項目を手で直せる。rsync できる。diff を見て、火曜日にエージェントのアーキテクチャ理解が変わったことにも気づける。そして囲い込まれるベクトルストアもない。

記憶が監査可能になるという意味もあり、これはチームにとってでかい。「なぜエージェントは pnpm を使っていると思っているのか」という問いの答えが、ファイル 1 つで済む。

消さずに古びさせる

プロジェクトは記憶の老化システムを説明している。階層ごとの減衰、アクセスで重み付けした保持、重複排除、矛盾のフラグ立て。使われないノートは優先度が下がるだけで消えず、衝突する項目は黙って上書きされずに印が付く。

大事なのは、ハード削除が一切ないことだ。古いページは git に残り、restore コマンドで戻せる。エージェントの「古い」ノートが、ある判断がなぜ下されたかの唯一の記録だった、というのはよくある話だ。このデフォルトは正しい。

dreaming というオプション機能があり、アイドル時に LLM で冷えたノートの塊を書き直す。デフォルトはオフで、README も元の素材は決して削除しないと明言している。モデルにノートを書き換えさせるものは、デフォルトオフが正解だ。

セットアップは本当に短い

Linux か macOS ならコマンド 2 つ。SHA-256 チェックサムを検証する curl-to-shell のインストーラー、そして ai-memory setup。データディレクトリを作り、ユーザーレベルのサービスを起動し、検出したエージェントをつないでくれる。Windows 用の PowerShell 版もあり、AUR、RPM、Nix、Docker、そして Claude Code と Codex 向けのプラグインマーケットプレイスの項目もある。

日常の使い方は 1 つのラッパーが中心だ。claude の代わりに ai-memory run claude。初回実行で適切なフックと MCP サーバーを入れ、セッションを現在のプロジェクトに限定する。そこから ai-memory continue で直近の管理下チェックアウトを再開し、resume --search auth でワークフローを名前から選べる。

既存のプロジェクト履歴を一度に取り込む bootstrap コマンドもある。これが「実際に使い始めるツール」と「いつか使おうと思い続けるツール」の差だ。

居心地の悪いところ

ライフサイクルフックによる無言の記録は、作業中にプロンプト、ツール呼び出し、セッションの区切りを記録するということだ。これなしには機能しない——手で日誌をつける人はいない——が、そこは冷静に見ておきたい。クライアントのコードベースに対して打ったプロンプトの記録はセンシティブな素材で、しかもそれが git で管理されたディレクトリに入る。

緩和策は妥当だ。デフォルトでは loopback にしかバインドせず、setup は bearer トークンを生成して、エージェントの設定ではなくオーナーだけが読めるファイルに書き込む。ただし Docker のクイックスタートは認証なしで動き、README もローカル用途限定と明記している。TLS リバースプロキシなしでそのポートを外に出したら、作業履歴を公開したことになる。

チーム向けの話は、この若さにしては成熟していると思った。共有サーバー、プロジェクト単位の共有、プライベートなハンドオフ、マルチユーザー認証、帰属表示、監査ログ、しかも有料プランの外にある。実際の開発組織と接触して生き残れるかを決めるのは、この機能群だ。

サーバーを動かしたくないなら

もっともな反論がある。「自分のサーバー」という言葉を聞いた瞬間に、読者の半分が離脱する。

サーバーである必要はない。setup コマンドは同じマシン上にユーザーレベルのサービスを、loopback にバインドして起動する。それがデフォルトの道で、ホームラボも VPS も DNS もいらない。マシンをまたぐ機能やチーム機能は、欲しくなってから効いてくるもので、コアループとは切り離せる。

リポジトリからビルドする macOS のメニューバーアプリもあり、エディタよりブラウザで wiki を見たい人向けに読み取り専用の Web ビューもある。Docker の道は、もともとコンテナで考える人向けだ。

正直な導入の段階はこうだ。ノート PC に入れて、1 つのプロジェクトを記録させ、できあがった wiki を本当に読みたいと思うかどうかを見る。思うなら、あとはついてくる。wiki がノイズなら、チーム機能をいくら積んでも救えない。

見た目より大事な理由

エージェント市場はいまベンダーごとに分かれていて、ベンダーには離脱を楽にする動機がない。あなたのコンテキストがロックインそのものだ。乗り換えコストがサブスク料金から連想するより高く感じるのは、そういう理由だ。

その全部の下に座って、自分が所有する形式で記憶を持つツールは、ユーザー側による小さな標準化だ。ai-memory が勝つかどうかはほとんど本題じゃない。移植可能なプレーンテキストと再構築できるインデックスという解の形は明らかに正しく、どのプロプライエタリな記憶機能も、いずれこの形と競わされることになる。

しかもコアループに API キーが要らない単一バイナリだ。「記憶」がたいてい「もう 1 つサブスク」を意味するカテゴリでは、珍しい。