Stash - AIエージェントのための永続メモリ層
(alash3al.github.io)- セッションが変わっても対話と作業コンテキストを引き継ぐ永続メモリ層で、生の観測を episodes として保存した後、構造化知識として蓄積する
- モデル非依存アーキテクチャを採用し、Claude、GPT、ローカル LLM、カスタムエージェントまで同じメモリ層に接続でき、ストレージは PostgreSQL と pgvector を基盤として動作する
- RAG とは異なる役割を担い、文書検索にとどまらず、対話から新しい事実や関係、目標、失敗、仮説まで蓄積し、RAG と併用できる
- namespace と階層パスでユーザー、プロジェクト、エージェントの自己知識を分離し、consolidation パイプラインで facts、relationships、causal links、patterns、contradictions を継続的に合成する
- MCP ネイティブ統合と
/selfベースの自己モデル、反復的な研究ループまで含め、記憶を持たないセッション型エージェントを長期的な連続性を持つ作業主体へ変えようとしている
Stash 概要
- AI エージェントと外部世界の間に置かれる永続メモリ層で、セッションが変わっても以前のコンテキストを引き継げるようにする
- 生の観測を episodes として保存し、それを facts、relationships、patterns、goals、failures、hypotheses のような構造化知識として蓄積する
- モデル自体を置き換えるのではなく連続性を補強し、Claude、GPT、ローカルモデルなどどのようなエージェントにも接続できるよう設計されている
- ストレージ基盤として PostgreSQL + pgvector を使用する
- GitHub
メモリの構成方法
- namespace によってユーザー、プロジェクト、エージェントの自己知識のようなメモリを分離する
- 各 namespace は階層パスで構成され、
/projectsを読むと/projects/stash、/projects/cartonaのような下位パスもあわせて含まれる - 書き込みは 1 つの正確な namespace にのみ記録され、メモリ汚染を防ぐ
- ユーザー関連メモリ、プロジェクトメモリ、
/self配下の自己知識は互いに混ざらないよう維持される - 例として
/users/alice、/projects/restaurant-saas、/projects/mobile-app、/self/capabilities、/self/limits、/self/preferencesを配置する
RAG との違い
- RAG は文書から関連内容を見つけてくる検索層に近く、対話そのものを記憶したり学習したりはしない
- RAG は文書にすでに含まれている内容しか扱えず、対話から新しい知識を作ることはできない
- 目標追跡、意図把握、時間経過に伴う矛盾検出、原因と結果についての推論は RAG の範囲外とされる
- Stash は対話、意思決定、成功、失敗から自動的に学習し、知識グラフを積み上げていく
- 文書検索と経験記憶は異なる問題を扱うため、RAG と Stash は併用できる
既存の AI メモリとの違い
- Claude.ai や ChatGPT にもメモリはあるが、その機能は各自のプラットフォームとモデルに結び付いている
- Stash はモデル非依存で動作し、ローカルモデルやプライベートモデルにも接続できる
- データ所有権をユーザー側に置き、オープンソースとして提供される
- バックグラウンドでの consolidation、goals および intent の追跡、failures の学習、causal reasoning、agent self-model などを含む
- 比較表では ChatGPT Memory と Claude.ai Memory は “notepad”、Stash は “mind” と区別されている
解決しようとしている問題
- 現在の AI モデルは推論は得意でもセッション間の記憶がなく、ユーザーは毎回自分やプロジェクトの背景を説明し直す必要がある
- 長い対話履歴を毎回プロンプトに入れる方式は遅く高コストで、context window の限界も残る
- 失敗した試みを次のセッションで再び繰り返さないようにする教訓伝達の仕組みが不足している
- メモリ機能が一部プラットフォームの専用機能としてしか提供されず、カスタムエージェントやローカル LLM は最初からコンテキストなしで始めることになる
統合パイプライン
- バックグラウンドプロセスが経験を継続的に合成し、生メモリを構造化知識へ変換する
- Episodes 段階で観測を append-only で保存する
- Facts 段階で episode のまとまりを LLM で合成する
- Relationships 段階で fact 間のエンティティ関係を抽出する
- Causal Links 段階で fact 間の原因と結果のペアを結び付ける
- Patterns 段階でより高いレベルの抽象パターンを導き出す
- Contradictions 段階で自己修正と confidence decay を行う
- Goal Inference により、アクティブな目標に関する事実を自動追跡し、進捗状況と衝突を明らかにする
- Failure Patterns により、繰り返されるミスを検出し、新しい事実として抽出して同じ失敗の反復を減らす
- Hypothesis Scan により、新しい証拠が未解決の仮説を手動介入なしで確認または棄却できるようにする
MCP 統合
- MCP ネイティブで動作し、Claude Desktop、Cursor、OpenCode、カスタムエージェント、ローカル LLM、その他の MCP クライアントに接続できる
- SDK なしで接続でき、vendor lock-in なしにどこでも同じメモリ層を使えるようにする
- 合計 28 個のツールを提供し、remember、recall、forget、init から causal links、contradictions、hypotheses まで含む
./stash mcp execute --with-consolidationで stdio MCP サーバーと consolidation を同時に起動できる./stash mcp serve --port 8080 --with-consolidationでリモートエージェント向けの SSE サーバーを立ち上げられる
エージェント自己モデル
init呼び出し時に/selfnamespace の骨格を作成し、自己モデルの構築を開始する/self/capabilitiesにはエージェントが得意なことを記憶し、作業計画に活用する/self/limitsには失敗記録と弱点を保存し、同じミスの繰り返しを防げるようにする/self/preferencesには最もよく機能する運用方法を学習し、長期的に作業スタイルを形成する
自律学習ループ
- 5 分単位の research loop を回すと、過去のメモリから現在のコンテキストを把握し、自らテーマを選んで調査し、新しいつながりを作り、再統合した後に終了する
- Orient 段階で過去のコンテキスト、アクティブな目標、未解決の仮説、過去の失敗を呼び出す
- Research 段階でエージェントが自分で選んだテーマについて Web 検索を実行する
- Think 段階で現在知っている内容の中にある緊張、空白、矛盾を明らかにする
- Invent 段階で仮説、パターン、発見のような新しい成果物を作る
- Consolidate 段階でパイプラインを実行し、生の episode を構造化知識へ合成する
- Reflect + Sleep 段階でセッション要約を残し、次回実行のためのコンテキストを設定した後に停止する
- ループプロンプトを見る
モデルおよびインフラ互換性
- embedding と reasoning の両方に OpenAI 互換 API を使う単一の provider 構成を前提としている
- クラウド、ローカル、self-hosted 構成をすべてサポートし、vendor lock-in はないとしている
- OpenRouter をローカルで接続して使用していると記し、数百のモデルに 1 つの API キーでアクセスできるようにしている
- Ollama ともそのまま動作し、Qwen、Llama、Mistral などのローカルモデルでオフラインメモリ構成が可能としている
- vLLM、LM Studio、llama.cpp server、Together AI、Groq のように OpenAI API 形式を使うバックエンドもサポート対象として挙げている
- デフォルトの embedding モデルは
openai/text-embedding-3-smallで、その組み合わせではSTASH_VECTOR_DIM=1536を使用する STASH_VECTOR_DIMは初回実行前にのみ設定でき、初期化後に変更するとデータベース全体の再設定が必要になる
デプロイおよび利用情報
- Docker Compose で Postgres、pgvector、Stash をまとめて立ち上げる構成を提供する
- 実行手順は、リポジトリを clone し、
.env.exampleを.envにコピーした後、API キーとモデルを設定してdocker compose upを実行する 3 段階として示されている - 初回実行後は postgres + pgvector の準備、migration の適用、MCP サーバー待機、バックグラウンド consolidation 実行状態になることが想定されている
- プロジェクトは Apache 2.0 ライセンスで公開されている
- GitHub Repository
- alash3al.com
1件のコメント
Hacker Newsのコメント
Claude.aiのメモリシステムみたいなものをついにポータブルにしたのかと思って開いたが、全然そうではなかった
ここにあるのはただの
store/remember方式で、私がより良いと感じたのは、バックグラウンドモデルが チャット履歴を要約してメモリを作る方式だそちらはモデルが自分でメモリを書かなくてよいのでずっとよく機能していて、だからこれをClaude.aiと同じレベルのものとして紹介するのはやや misleading に見える
私も LibreChat のような環境へ移ろうとして同じ方式のメモリシステムをずっと探しているが、まだ見つかっておらず、今でもClaude.aiに残っているほぼ唯一の理由がその機能だ
ちなみにそのシステムはClaude.aiにだけあり、Claude Codeにはない
autoDreamというものがあり、ここでは background memory consolidation engine と説明されている: https://kuber.studio/blog/AI/Claude-Code's-Entire-Source-Code-Got-Leaked-via-a-Sourcemap-in-npm,-Let's-Talk-About-it私の経験は正反対で、私は https://github.com/flippyhead/ai-brain を主に自分のために作り、友人も数人使っている
これまでは
CLAUDE.mdを通じてAIに 関連メモリを探させ、いつどのように保存するかを考えさせる方式がかなりうまく機能してきたこの方式は優先順位に応じて構造を作れ、将来のためのノートも残せるので、単に全部を要約する方式とはかなり違って感じられる
メモリ生成は tool call でもかなりうまくいくし、コンテキスト圧縮時に自動でメモリを作る方式も悪くないと思う
ただし自動生成なら非同期の consolidation が必要で、それを dreaming と呼ぶのは少し大げさに感じる
私の実装はElroy.botにあり、いくつかのアプローチはここにまとめてある: https://tombedor.dev/approaches-to-agent-memory/
バックグラウンドでメモリを抽出すると、prefix cache とうまく合わせにくいのが問題だ
単純な2段階の
LOG.md（作業と学びの詳細ログ）+MEMORY.md（ログが切り詰められるときに昇格した項目を記録）+ ターン終了時に実行される stop hook だけでもかなり遠くまで行けるユーザーと会話するエージェントの後ろで補助要員たちが会話を聞き取り、重要な事実を記録したり、関連する事実をDBから探して
このメモリ X が関連していそうだと割り込んでくる構造のように感じるトークンが無料なら簡単そうだが、これを 効率的に 作るのはかなり面白い問題だ
実装方法をほとんど明かさないまま何かを約束するプロジェクトは、いつも 大きな red flag に見える
さらに掘ると、実質的には
pg_vectorにmcp、そしてrecall/rememberの2つの関数が付いた構造だ結局のところ RAG に近く、データ構造が重要だと主張することはできても、これまで出てきたこうしたメモリシステムはほぼどれも似たような動き方をしていた
まだ基本的な vector DB search より検索が良くなったと証明した例は見たことがない
memoryと書いてあり、LLMはひどいがこの製品は魔法のように解決すると見せている本当にそれができるのなら、結局は vectordb をもっともらしく包んだものに近い
すでにレビューがある: https://zby.github.io/commonplace/agent-memory-systems/reviews/stash/
他の多数の LLM memory systems もここにまとまっている: https://zby.github.io/commonplace/agent-memory-systems/
そして、こうしたシステムに求める点も整理してある: https://zby.github.io/commonplace/notes/designing-agent-memory-systems/
こうした agent memory systems は過剰設計に見える一方で、同時に設計不足にも見え、かなり袋小路のように思える
最新モデルが必要とするものとすぐにずれて腐らずに済む現実があまり想像できない
たとえば決済機能を一度作っただけで、
don't use stripeのようなメモリのせいで、その後の複数セッションがずっと決済方面に引っ張られるかもしれない完全に unproven memory layer で、実運用のスクリーンショットもなく、派手なマーケティングサイトに誇張した主張だけを載せたように見える
前提は単純だ。LLMがもともと知っている内容は引き続き知っているはずなので、LLMが話したことは保存せず、コード関連の内容はコードとコメントに残せばよい
その代わり、どちらにも当てはまらないのに絶対に拾われないものがある
何かを作るときは、実際にやったことよりも やらないと決めたこと のほうが重要なことが多く、このユーティリティはセッションの終わりに却下した代替案とその理由を拾って system knowledge として保存する
要するに、コードの grep だけでは見つからず、同僚の頭の中にしかない情報を残したいのであって、今のところかなりうまく機能しているが、まだ初期段階ではある
don't use stripeのようなメモリは、モデルが payment processing 関連の作業をするようプロンプトを受けたときにだけコンテキストに入るこういうものをずっと探していて、アカウントが LLMブーム以前 からソフトウェアを公開してきたことも見えてうれしい
ただ、各プロジェクトに
LLM使用履歴のようなものが付いているといいと思うLLMで生成したのか、したならどの程度か、どの段階で使ったのか、出力をどれだけ注意深くレビューしたのか、品質が一人で作った場合と少なくとも同等かそれ以上だと感じているのか、といった情報があるとよい
特定の個人を疑いたいわけではなく、すべてのプロジェクトに共通してあってほしいし、私自身もそうするつもりだ
誰かがこのプロジェクトを無理やり使えと言っているわけでもないし、コードを自分で読んでレビューした上で使うかどうか判断すればいい
設計もテストもほとんどせず、コード品質もあまり良くないと正直に認める人が多いとは思えない
むしろ、こうした質問に答えようとする第三者システムが必要かもしれないが、もちろんそれもLLMベースならかなり主観的になりうる
私は最近ほとんどのプロジェクトを複数の Markdownファイル 中心で回していて、AIで先に調査し、計画を立て、実装の進行を追跡している
実装は計画に従って段階的に進め、各段階でレビューも続けている
私のワークフローを文書化しろと言われたら、それらのファイルがまさにそれだ
コードの99%は生成されるが、自分が満足できる形で生成されるよう気を配っており、結果も一人で作ったときより良いと感じることがしばしばある
良いソフトウェア も悪いソフトウェアも、LLMなしでも、LLMと一緒でも作れる
大工にハンマーを使ったか nail gun を使ったか、屋根とデッキにはそれぞれ何を使ったかとは聞かない
信頼に基づく土台がないなら、結局は自分で品質を検証するか、そもそも自分で作るしかなく、それ以外は希望混じりの期待に近いと思う
まだ使い物になる memory を見つけられていない
ひとつは
agents.mdのように高レベルの要約だけを残す方式で、具体的な詳細、たとえばこの要素を修正したらあの要素を draft と表示しなければならないのような情報にはほとんど役に立たない逆に詳細すぎる方式は細部が多すぎて無視されるか、ある機能領域の詳細が別の領域の変更にまで悪影響を与える
結局、これまで一番うまくいったのは メモリなし で、そのセッション / プロンプトに重要なコンテキストだけを手動で選ぶ方式だった
リポジトリが何をしているか、何をすべきかの source of truth は結局 repo itself だ
今言っているのはむしろコードレビューのガイドラインに近く、そういうものは変更時点に合わせて明示的にコンテキストへ入れればよい
メモリシステムはそれに比べて複雑すぎ、精度も低い
いつかこうしたモデルが continual learning を持つようになるのか気になる
すでに十分賢いのに、本当のメモリがないせいで扱いづらく感じる
私にはいくつか単純なものがかなりうまく機能している。ツールは Codex を前提としている
Agent.mdのコーディングガイドラインに入れてある私の functional spec はエージェントにとって
Project.mdの役割を果たすそして毎回 agentic code review の前にプロジェクトのディレクトリツリーを作り、コードベースと合わせて単一ファイルにした上で、ファイル名に timestamp を付ける
これが意外に重要で、LLMが古いバージョンを参照するのを減らしてくれるし、gitを送らなくても素早く diff を見るのにも向いている
これまでのところ、大規模で複雑なコードベースでもこのシンプルなワークフローはかなりうまく機能してきた
トークン効率は良くないが、とにかくうまくいく
毎回コードベース全体を全部まとめる必要はなく、すでに終わった、テスト済み、あるいは今の作業に無関係なプロジェクトは外せる
それでも printed directory tree には含めて、エージェントが少なくともその存在を知り、必要なら特定のファイルを要求できるようにする
その 結合作業 をどうやっているのか気になる
手動なのか、変更ファイルだけを結合するのか、それともハイブリッドなのか知りたい
LLM memory は理論上は良さそうだが、実際には大きくなるほど、メモリなしで回すときと同じくらい散らかっていく
最初の画面例のように
自分のプロジェクトの続きをやってと言っても、現実にはプロジェクトを一つしかやっていないことは稀だ5つ、10つくらいはメモリに入りうるし、それぞれ保存時点ではどれも意味があったはずだ
結局
sassプロジェクトの続きをやってのように再度特定しなければならず、少しだけ詳細なコンテキストを得る代わりに LLM context を埋め、追加の MCP calls コストも払うことになるきちんと作られた実装なら、こうした限界を超えられるかもしれない
これは一人で作業する vibecoder だけのためのものなのではと思ってしまう
実際の人間と実際のプロジェクトで作業するなら、このシステムはプロジェクト全体のメモリを持てるわけでもないし、私自身も全体のメモリを持っているわけではない
他のPRがマージされれば私の記憶はすぐ古くなり、私が気にするのは自分のチケットだけだ
だから、こういうものはそういう種類の共同作業のためのツールではないのかもしれないとますます感じる
いまやソフトウェアを作るコストが事実上ほぼゼロに近くなったのに、それでもなおこういうものを vibe-coded なマーケティングサイト で売ろうとしているのには驚く
誰がこんなものを試して、数週間、数か月待ちながら本当に機能するか確認する時間があるのだろうか
サイトのどこにも RAG より優れているとか、単なるメモリファイルのフォルダと grep より優れているという証拠がない
それなのに空想的な主張ばかり並べていて、スクロールも14fpsでガクガクする
これは24時間前にコーディングしたレベルに見え、正直かなり手抜きに感じる