Memmy はローカル常駐のメモリサービスでエージェント間の文脈を引き継ぐ

エージェントを乗り換えるたびに前提を説明し直す問題

Claude Code で設計を詰め、Codex で実装を書き、Cursor で細部を直す。ツールを変えるたびに、プロジェクトの背景、好みの書き方、前回どこまで進んだかを毎回説明し直すことになる。Memmy が狙っているのはこの往復の削減だ。README は Remember、Relay、Act という 3 つの語で機能を説明している。ローカルの AI とのやり取りを構造化された記憶として残し、ツールをまたいでプロジェクトの背景と進捗を運び、さらに自分自身もエージェントとして未完了のタスクを続けられる、という整理になっている。対象は個人開発者だ。チームの共有ナレッジを管理する製品ではなく、README の表現を借りれば「すべての AI エージェントのための個人向け AI エージェント兼ローカルメモリハブ」である。

メモリサービスとゲートウェイの 2 サービス構成

README から読み取れるアーキテクチャは、役割の異なる 2 つの常駐プロセスに分かれている。1 つは memmy-memory.service で、ローカルのメモリサービスとして動く。もう 1 つは memmy-gateway.service で、エージェントからの接続を受け持つゲートウェイだ。どちらも systemd --user のサービスとして、localhost に束縛された状態で動く。TUI やターミナルを閉じても動き続け、次のログインでも再起動する。インストーラは linger を有効にしないので、ログインしていない間まで動かしたい場合は自分で設定を足すことになる。メモリサービスは http://127.0.0.1:18960 を既定の接続先として公開しており、memmy-memory CLI はここに話しかける。ゲートウェイ側は memmy serve で OpenAI 互換 API を :18990 に立てる。つまり、メモリの読み書きとモデルへのルーティングが別プロセスに分かれ、エージェントは前者に CLI か HTTP で、後者に OpenAI 互換の口で触る形だ。

インストーラが systemd サービスを立ち上げる条件

Linux x64 または arm64、Node.js 22 以上、利用可能な systemd のユーザーセッション。この 3 つが揃っている場合のみ、次のコマンドがサービス管理まで面倒を見る。

curl -fsSL https://raw.githubusercontent.com/MemTensor/memmy-agent/main/scripts/install.sh | bash memmy

インストーラは memmy-memory.service をその場で有効化する。最初の memmy 実行は必要に応じてモデル設定ウィザードを開き、その後 memmy-gateway.service を有効化して起動を待ち、TUI に入る。README は、このサービス管理が働くのはインストーラ経由の起動だけで、ソースからビルドした Linux の CLI は従来の挙動のままだと明記している。ここは見落としやすい。git clone して npm run build した場合、同じバイナリでも常駐サービスの面倒は見てくれない。

状態確認は次の 2 つで行う。

systemctl --user status memmy-memory.service systemctl --user status memmy-gateway.service

なお、インストーラは Codex や Claude Code、Cursor などの設定には触れない。エージェント側に Memory Skill とフックを入れるのは明示的な操作で、memmy-memory init または memmy-memory init --agent <agent> を実行したときだけだ。

~/.memmy/config.yaml とゲートウェイ環境ファイル

設定の中心は ~/.memmy/config.yaml にある。README が示す最小の BYOK 構成はこれだ。

agents: defaults: model: openai/gpt-4.1 provider: openai timezone: "+08:00" providers: openai: apiKey: ${OPENAI_API_KEY}

モデル名はプロバイダ名を前置する形式で、apiKey は環境変数を参照できる。対話的にまとめて設定したい場合は memmy onboard、既定値で初期化したい場合は memmy onboard --defaults を使う。設定、モデル、プロバイダの状態は memmy status で確認する。単発のタスクは memmy agent --message "Introduce the current workspace" のように渡す。

もう 1 つ覚えておきたいのが ~/.memmy/systemd/gateway.env だ。ゲートウェイに接続する前、または再接続する前に、memmy はこのファイルをモード 0600 で書き直す。内容は設定から参照されている環境変数、一般的なプロバイダの資格情報、そしてターミナルの PATH である。値が変わっていれば、次に素の memmy を実行したときに新しい環境でユーザーサービスが再起動される。つまり API キーを切り替えた場合、設定ファイルを直すだけでなく memmy をもう一度起動する必要がある。

memmy-memory CLI が公開する操作

エージェント、スクリプト、デバッグの 3 つからメモリサービスに触るための口が memmy-memory だ。README に並んでいるのは次の操作である。

memmy-memory init memmy-memory health memmy-memory search "memory policies in this project" memmy-memory add "a piece of knowledge worth saving" memmy-memory get <id>

既定の接続先は http://127.0.0.1:18960 で、--url、--token、--config、--source、--user-id でサービスと名前空間を指定できる。add と search と get という素朴な 4 文字の動詞に、init と health が加わる構成だ。検索がどのような方式で行われるか、記憶がどう構造化されるかは、この材料からは確認できない。名前空間を --user-id で切れることだけは読み取れる。エージェントごとに記憶を分けたければこの引数を使う、という設計意図までは README からは踏み込めないので、そこは自分で試して確かめる領域になる。

ソースから動かす場合と、そうしない場合

ソースからの手順は README に載っている。

git clone https://github.com/MemTensor/memmy-agent.git cd memmy-agent cp .env.example .env npm install npm run build bash scripts/dev-start.sh

README の記述はここで途切れているため、dev-start.sh が依存の導入とビルドのどこまでを担うかは、この材料からは判断できない。確実に言えるのは、この経路ではインストーラによる systemd サービス管理が働かないという点だ。開発用に手元で動かすなら問題にならないが、常用したいならインストーラ経由のほうが素直である。

もう 1 つの選択肢はデスクトップアプリだ。公式サイトか GitHub Releases から入手する。README はこちらを推奨としており、初回スキャンと最初のレポートという 2 つの画面が用意されている。登録するとエージェントタスク用のトライアルトークンが付き、残高と使用量はアプリ内に表示される。使い切ったら BYOK に切り替えて自分のモデル API を使う。つまり、無料枠で試してから自前のキーに移るという流れが想定されている。CLI とアプリのどちらが自分の用途に合うかは、TUI を常用するかどうかで決めればよい。

向かない場面と、代わりに検討するもの

Memmy が向かないのは、記憶をチームで共有したい場合だ。README の説明は一貫して個人向けで、名前空間の切り方も --user-id という単位になっている。複数人が同じ記憶を読み書きする権限モデルや競合解決については、この材料からは何も読み取れない。組織のナレッジ基盤を探しているなら、別のものを当たるべきだ。

同じ問題に対する別のアプローチとして、各エージェントの設定ファイルに直接指示を書き込む方法がある。CLAUDE.md や AGENTS.md のようなファイルにプロジェクトの前提を書いておけば、常駐サービスを増やさずに済む。違いは明確だ。ファイル方式は静的なテキストで、人間が編集し、git で差分を追える。Memmy はローカルのサービスがやり取りの履歴から記憶を組み立て、CLI 経由で検索と追加ができる。前者は「書いたことを忘れない」、後者は「話したことを覚えている」に近い。エージェントを 1 つしか使わず、前提も頻繁に変わらないなら、ファイル方式のほうが構成要素が少なくて済む。乗り換えの頻度が高い人ほど、Memmy の常駐サービスを維持するコストが正当化される。

もう 1 つの制約はプラットフォームだ。インストーラの手順は Linux 前提で書かれている。macOS や Windows での CLI の扱いについては、この材料からは確認できない。デスクトップアプリの配布は別経路なので、そちらを使うことになる。

MIT ライセンスと更新頻度から見えること

ライセンスは MIT で、アーカイブはされていない。MIT なので fork も改変も再配布もできるが、これは法的な助言ではない。同梱の LICENSE と、依存パッケージそれぞれのライセンスを自分で確認する必要がある。特に、メモリサービスがモデルプロバイダの API を呼ぶ構成である以上、プロバイダ側の利用規約のほうが実務上の制約になる可能性がある。

更新の頻度は高い。v1.1.2 が 2026-09-04、v1.1.3 が 2026-09-08、v1.1.4 が 2026-09-09 で、数日の間隔でリリースが続いている。活発である一方、この速度は設定ファイルや CLI の引数が変わりうることを意味する。~/.memmy/config.yaml や ~/.memmy/systemd/gateway.env の扱いが変わっていないか、更新のたびにリリースノートを見る習慣がないと、静かに壊れる可能性がある。逆に言えば、リリースノートを追う手間を許容できるなら、修正が早く届くということでもある。

編集部の結論

複数のコーディングエージェントを日常的に切り替え、そのたびに同じ説明を繰り返すことにコストを感じている個人開発者には、Memmy のローカルメモリサービスは検討に値する。Linux x64 または arm64 で Node.js 22 以上と systemd のユーザーセッションが使えることが前提で、それ以外の環境ではデスクトップアプリか、ソースからのビルドと scripts/dev-start.sh を自分で面倒を見る覚悟が要る。逆に、チームで共有するナレッジベースとして使いたい場合や、常駐サービスを増やしたくない場合は向かない。導入前に確認すべきは、systemctl --user status memmy-memory.service と memmy-memory health が通ること、そして ~/.memmy/config.yaml に自分のプロバイダの apiKey を書いた状態で memmy status が想定どおりのモデルを返すことだ。この 3 つが確認できるまで、エージェント側への init は実行しないほうがよい。

公式情報源

1. License: MIT
2. MemTensor/memmy-agent on GitHub
3. Project website
4. README
5. Releases