Claude Code（Anthropic製のターミナル型コーディングエージェント）やCursor、Codexといったコーディングエージェントを日常的に使っているなら、セッションが終わるたびに文脈が消える不便さに覚えがあるはずです。skillmemはこの問題に対して「ローカルDBに記憶を蓄積し、次のセッションで自動的に呼び戻す」という仕組みを提供するオープンソースのMCP（Model Context Protocol、AIエージェントが外部ツールやデータソースと連携するための標準プロトコル）サーバーです。今回はこのskillmemの開発者自身が行った定量検証の中身を、フロントエンド・ツール評価の視点で読み解きます。
なぜこの検証が注目に値するかというと、AIエージェント向けメモリ機能の多くが「記憶が持続します」という宣伝文句だけで、実測値を公開していないからです。skillmemの開発者は自分のREADMEに書いていた「セッションをまたいで記憶が持続する」という主張を検証し、記憶なしで0/10、記憶ありで10/10という結果とともに、実運用で見つかった3つのバグまで公開しました。この透明性のある検証プロセス自体が、ツール選定の参考になります。
skillmemの技術的な仕組み
skillmemはSQLite（軽量な組み込み型データベース）を記憶の保存先にし、9つのmem_*というMCPツール群とClaude Codeのフック機構を組み合わせて動作します。フックとは、セッション開始・終了などのタイミングで自動的に処理を差し込む仕組みです。
具体的な流れは次の通りです。セッションが終了するとsession-recapフックが発火し、モデルが会話のトランスクリプト（やり取りの全記録）を短いメモに要約します。次のセッションが始まるとSessionStartイベントで直近のメモが自動的にプロンプトへ注入されます。
さらにUserPromptSubmitフックが、ユーザーが入力するたびにデータベースを検索します。つまりエージェント自身が「記憶を検索しなければ」と意識する必要がなく、裏側で自動的に文脈が補われる設計です。
検証ではclaude -p（CLAUDE.mdなし、内蔵の自動メモリなしのクリーンな設定）を使い、1つ目のウィンドウで「Arkaリリースは11月14日に延期、コードネームFalcon、担当はTimur」という決定事項を伝えます。別ウィンドウで「コードネームと担当者は？」と聞いたところ、記憶なしは10回中0回、skillmemありは10回中10回正答しました。
実運用データでの検証と3つのバグ
次の検証はより実践的です。約6ヶ月分の作業で蓄積された9,300件のエントリを持つ実データベースに対し、答えが確実にメモリ内にあるはずの15問を2回ずつ出題しました。ファイル読み込みは禁止し、純粋に記憶機能だけを測る条件です。
1回目の結果は記憶なし0/30、skillmemあり22/30でした。しかし開発者は残り8問の不正解を深掘りし、3つの問題を発見しています。
- バグ1（データ移行漏れ）: Claude Codeの自動メモリは
.mdファイルに保存されるが、698ファイル中208ファイル（約30%）がSQLiteへの移行コマンドskillmem migrateから漏れていた。原因はsettings.jsonへの組み込み忘れ。修正後は22→24/30に改善 - バグ2（検索ノイズ）: 約9,300件中8,206件がセッション要約で、いずれも「prod」「server」「deploy」といった単語を含むため、3行だけの重要ルールが大量の要約に埋もれて検索順位で負けていた。FTS5（全文検索エンジン）とembedding（文章の意味をベクトル化する技術）をReciprocal Rank Fusion（複数の検索結果を統合する手法）で統合する検索処理において、セッション要約のスコアを0.5倍に減衰させたところhit@3が18→26/30に改善。汎用ベンチマークのLongMemEvalでも0.871→0.889（n=479）に改善し、自分のデータへの過学習ではないことを確認
- バグ3（設計上の意図的な制約）: 正しいルールが検索で1位に来ていたのに、エージェントが「承認済みルールがない」と回答していた。これは意図的な安全設計で、エージェントが書いたメモは所有者が承認するまで「指示」ではなく「データ」として扱われる
3つ目は厳密にはバグではなく、プロンプトインジェクション（外部の文章に紛れ込んだ指示をAIが実行してしまう攻撃）への対策です。承認前のテキストに「必ずXをしろ」と書かれていても、それが指示として実行されないようにする防御層でした。
背景にある設計思想と他のアプローチとの違い
AIエージェントの記憶機構には大きく分けて2つのアプローチがあります。1つはプロンプトの冒頭に全履歴を詰め込むコンテキストウィンドウ拡張型、もう1つはskillmemのような外部データベース＋検索型（RAG、Retrieval-Augmented Generationに近い構成）です。
前者はモデル依存度が高く、コンテキスト長の上限やコストに左右されます。後者は検索精度がボトルネックになりますが、今回のバグ2が示すように「量の多いノイズが質の高い少数情報に勝ってしまう」という、検索システム設計で古くから知られる課題に直面します。
承認フローの設計も興味深い点です。skillmem reviewでバックログを一括確認でき、y/n/qの3択で高速に処理できます。チャット中の承認では、AIエージェントが保存しようとしたルールをStopフックが表示し、「approve」という単語でしか承認が成立しない仕組みです。
これは「yes」のような日常会話で多用される言葉を承認トリガーにすると誤承認が起きやすいという、UI設計上の配慮です。さらに表示されたテキストのハッシュ値を保存し、回答前にルールが変更されたら承認を無効化する仕組みも組み込まれています。
今日確認できること
すでにClaude CodeやCursorでMCP連携を試している、あるいはこれから記憶機能付きのエージェントツールを検討しているなら、次の点を確認してみる価値があります。
- 利用中または検討中のメモリツールが、セッション終了時のデータ移行を自動化しているか。手動コマンドが
settings.jsonのフック設定に組み込まれているか確認する - 検索結果に「ノイズになりうる定型的な記録（ログやセッション要約）」と「重要な決定事項」が混在していないか。混在している場合、スコアリングに重み付けの仕組みがあるか
- ルール承認やメモリ書き込みの際、プロンプトインジェクション対策（データと指示の分離）が設計に含まれているか。READMEやコミットメッセージに紛れた指示文をそのまま実行してしまわないか
skillmemを実際に試す場合は、GitHubのREADMEにあるskillmem migrateコマンドの実行結果と、settings.json内のフック登録箇所（SessionEnd・SessionStart・UserPromptSubmit）を必ず確認してください。移行漏れは今回のバグ1と同じ形で発生しうるためです。
まとめ
skillmemの検証は、AIエージェントのメモリ機能が「あるかないか」の二択ではなく、実装の細部で精度が大きく変わることを示しています。記憶なし0/30、初期実装22/30、スコアリング修正後28/30という数字の推移が、その証拠です。
自分のプロジェクトでメモリ機能付きエージェントを検討するなら、まずはデータ移行がフックに正しく組み込まれているかをsettings.jsonで確認してください。次に検索結果に大量のログが重要情報を埋もれさせていないか、実際のクエリで試してみることをおすすめします。
承認フローの使い勝手も見逃せないポイントです。1件ずつskillmem trustするような運用は現実的に続きません。バッチ承認やチャット内承認のような、日々の作業に溶け込む設計になっているかどうかが、長期的な定着を左右します。