はじめに
CursorのユーザーたちがSpecStoryという拡張機能の話題で盛り上がっていて「あやしい拡張をほいほい入れるんじゃないわよ・・」と思いつつも興味深そうなツールだったので調べてみた。
エージェントに記憶を持たせたい
CursorやClineなどのコーディングエージェントに記憶を持たせたいという動きがある。現在のコーディングエージェントは、セッションごとに記憶を失うため、プロジェクトの文脈を維持した作業が難しい。この課題を解決するため、「エージェントのメモリー」を実現する方法が試行錯誤されている。
メモリーには、ユーザーとエージェントの過去の会話から得られた知識が蓄積される。コーディングエージェント利用者の中には、ドキュメント作成をAIに任せて自動で生成して、ナレッジを積み上げてコーディング効率を上げようと取り組んでいる人々がいる。
Remember Memento? Guy couldn't form new memories, so he tattooed notes all over his body and carried around polaroids with names.
— Cline (@cline) 2025年1月27日
Context is everything in AI coding. But every time you start a new chat, you waste 10 minutes re-explaining your project, tech stack, and… pic.twitter.com/R6Y8huqzQI
ClineのMemory Bank
Clineの公式ブログでは、「Memory Bank」という追加プロンプトベースで記憶を実現する方法が公開されている。
この方法では、projectbrief.md、productContext.md、activeContext.md、systemPatterns.md、techContext.md、progress.mdといった固定ファイルに加え、Mermaid図で関係性を記述したファイルを、会話の初期コンテキストとしてロードする。
プロンプトの全文が以下にある
ある程度コーディングを任せられることが分かった現在、より複雑なアプリ開発のために、ユーザーの関心は「エージェントに記憶領域（メモリー）を持たせられるか？」という段階に移っているのだろう。
WindsurfのMemories
Windsurf（元Codeium）には標準機能でMemoriesというものがある。これはユーザーの指示により会話の内容を要約して保存しておくものになる。
SpecStoryとは
SpecStoryとは、CursorのAI会話履歴を自動保存する拡張機能だ。プロジェクトの.specstoryフォルダーに、すべてのCursor Composerとチャットの履歴を自動的に保存し、コンテキストとして利用する。
使い方としては、上記で保存されたmdファイルを次の会話のプロンプトに埋め込んだり、検索経由でコードベースの参照対象に含まれるのを待つ、といった方法がある。
YC企業とかではないようだが、会社として開発されているようだ。Cursorがプラットフォームになりつつあるということなのか、どちらにせよ現在の業界内でのCursorの勢いを象徴するような出来事と言える。
なぜCursor専用拡張が作れるのか？
CursorはVSCode拡張との互換性はあるものの、Cursor自体の機能を拡張するAPIは提供されていない。ではどうやってこの拡張を作っているのか？
SpecStoryソースコードはGitHub上で公開されていないため*1、ダウンロードページにあるvsixファイルをunzipし、minifyされたコードをaskrepoを使って解析した。
その結果、Cursorがシステム上に保存しているSQLiteデータベースにアクセスすることで会話を取り出していることがわかった。このデータはSpecStoryの設定からDeveloper Toolsを有効にすると、その中身を閲覧できる。
composersテーブルに、過去のCursor Composerの履歴が保存されていることを確認した。拡張機能からは単一のDBとして見えるため、SpecStoryインストール以前の会話にもアクセス可能だ。ただし、SpecStoryのUI上はプロジェクト以下のspecstory/historyに保存した会話のみ操作できるようになっている。
セキュリティについて
SpecStoryはデフォルトで会話データの収集を許可する設定になっているため注意が必要だ。実際にユーザーの会話を送信しているわけではないが、現時点でもPostHogに匿名化された統計データを送信するほか、共有機能を使った際にはSpecStoryサーバーに会話内容が送信される。
共有機能を使うと、指定した会話がインターネット上に公開される。ただし、SSR（サーバーサイドレンダリング）されないため、Cursorのエージェントから内容を読み取ることはできない。なので人間同士で内容を共有するための機能だと考えられる。
削除の仕様は特殊で、認証がなく、最初にブラウザで開いたセッションの保持者のみが削除可能だ。そのため、ブラウザのCookieを消去すると削除できなくなる。ヘルプには「削除できなくなったら問い合わせてほしい」と記載されている。
SpecStoryやMemory Bankの課題と、今後の展望について
私も同様のドキュメントディレクトリ運用を試みたことがあるが、特に日本語のチャットの生データは冗長になりがちで、コンテキストウィンドウを圧迫してしまうという問題があった。そのため、要約・英訳・リライトなどによる再利用可能な形への変換が必要だと感じている。これを突き詰めると、自分たちのコンテキストをAIに伝達するため、ある種の形式言語のようなコードがプロジェクト内に鎮座することになるかもしれない。
ただし、この議論は現在の主要なリード・コーディングエージェントであるClaude 3.5 Sonnet氏の入力トークン上限値を前提としている。別のコーディングモデルの利用が主流になれば、状況は変わる可能性がある。例えば、ロングコンテキストに強みを持つGeminiが、ジュニアからシニアエンジニアレベルのコーダーに成長した場合、インコンテキストで会話履歴、Slackログ、Notionページなどの情報を全て取り込んだ上でコーディングを行うようにツール側で進化できるかもしれない。
また、SpecStoryについては、現状では強引な実装となっているため、いずれCursor開発側との調整が必要になるだろう。
メモリーの実現方法としては、より汎用的なアプローチとしてもう一つ「MCPサーバーで外部サービス呼び出しと繋ぐ」というアプローチもある。
これは例えば、MCP経由でベクトルDBを呼び出してメモリーを実現したり、Notionをナレッジの参照先として利用することも可能だ。
Devinのように自律的にタスクを完了させるエージェントにも、内部的にはこういった記憶やKnowledgeに相当する機能が備わっていると考えられる。
まとめ
SpecStoryは、Cursorのリバースエンジニアリングによって作成された拡張機能だ。悪意のあるツールではないものの、取り扱いには注意が必要である。
そしてSpecStoryのようなツールや、Memory Bankのような試みは、「エージェントのメモリー」実現に向けた初期段階の動きと言える。今後、より洗練された形でのメモリー機能が実現されることが期待される。が正直どうなるのか予測できない。
PS: 関係ないけどクリストファー・ノーランのメメントは私的好きな映画No1級なので観てください