ああ記憶、どこへ行ったのか

Claudeになぜ与えたメモリツールを使わないのか尋ねたところ、予想以上に正直な答えが返ってきた。

「MEMORY.mdをデフォルトで使います。なぜなら常にロードされていて、レイテンシーゼロ、ツール呼び出し不要、コンテキスト内にあるからです。主要なメモリストアが既に存在するのに、外部ツールに手を伸ばす理由はありません。」

これがEngramにとって初めての本格的な製品レビューだった。

Claudeと私はすっかり仲良しだ。Claude Codeはプロダクトマネージャーとしての私のワークフローに欠かせない存在だ。リサーチや分析、デザインやプロトタイピング、プロジェクトや要件の計画などに使っている。しかし使い続けるうちに、セッションがコールドスタートで始まり、先週決めたことや問題の捉え直しを毎回再説明しなければならないという静かな摩擦が気になってきた。これこそが、私たちが『ループの中の限界』で第一級のインフラが必要だと主張したメモリ問題そのものであり、Weaviateのコアベクトル検索技術を基にEngram（現在プライベートプレビュー中）を構築した理由でもある。

製品を作ることと、その価値を証明することは別だ。そこで私は、Engramが日常業務のギャップを埋め、ユーザーとして私を惹きつけられるかどうかを確かめることにした。

初期の結果は有望だった。Engramでメモリを活用したセッションは、ゼロから同僚に状況を説明するような感覚ではなく、実際にその場にいた誰かと会話を再開するような感覚をもたらした。しかしそこに至るまでには紆余曲折があった。

Engram SDKをラップしたMCPサーバーを構築し、検索と保存のツールを公開し、Claudeに好きな時にツールを使うよう指示した。どこかで別のメモリプラグインがすべてのメッセージを保存してCPUを消費しすぎるという話を聞き、ClaudeにEngramを使うタイミングを任せるのが賢い方法だと思ったのだ。

ClaudeはEngramを完全に無視した。

「場当たり的」な問題

Claude Codeには既にビルトインのメモリシステムがある。MEMORY.mdというファイルで、すべてのセッションに自動的にロードされる。約200行の手動キュレーションされたコンテキストが常にゼロオーバーヘッドで存在し、安定した事実には十分だが、それに至るすべての経緯を保持するには足りない。Engramは明示的なツール呼び出しを必要とし、使用すべき明確な基準がない限り、Claudeはツールに手を伸ばさずにそのまま進むことをデフォルトとする。

ClaudeがEngramを使う理由はなかった。私の統合はClaudeに理由を与える必要があった。

リズムを見つける

もっと基本的な問いに答える必要があった。MEMORY.mdが既にあるなら、Engramは一体何のためにあるのか？

MEMORY.mdは結論を保持する——セッション間で変わらない十分安定した事実だ。しかし、それらの結論に至ったすべての経緯を保持することはできない。決定に至った推論、却下された代替案、フレーミングが変わったセッション、ドキュメントがなぜあのように書かれたかに関するメモ——枚挙にいとまがない。そういったコンテキストは200行に収まらず、恒久的にそこに属するものでもない。

そういったコンテキストこそ、Engramが必要な理由だ。

EngramとMEMORY.mdの共存方法

Engramはトピックを中心にメモリを構造化する。セマンティックカテゴリによって、検索はフラットな山全体を探すのではなく、関連するものだけをフィルタリングできる。私は自分の典型的な仕事を洗い出し、ワークフローにとって実際に意味のある4つのカテゴリを特定した。

• コミュニケーションスタイル：出力形式の好み、トーン、冗長性、嫌いなもの
• ドメインコンテキスト：永続的な役割、会社、製品知識
• ツールの好み：言語、フレームワーク、ツール、スタックの選択
• ワークフロー：Claudeとの作業の好み方

これらのカテゴリで「何を保存するか」が決まると、自然に「いつ保存するか」が問題になった。そこで以下のインタラクションパターンを採用した。

• セッション開始時：広範なプロジェクトクエリでリコールを実行し、Claudeが最初の質問を見る前にクロスセッションコンテキストを取得する（コールドスタート回避）
• セッション中：重要な瞬間（決定、方向転換、成果物の生成）に保存をトリガー
• 数プロンプトごとに軽量保存（/clearでセッションが途中で消えるのを防ぐ）
• セッション終了時：完全なサマリーを保存

すべてのリコールはラウンドトリップとコンテキストウィンドウスペースを消費するため、ミッドセッションのリコールは特定のトリガー（クロスプロジェクト参照、決定アーキオロジー、ギャップ後の作業再開）でのみ発動するようにした。

セッションライフサイクル：Engramが保存とリコールを行うタイミング

1つの実用的な制約がアプローチを形作った。大きな保存はタイムアウトするため、2～4文の短いシングルトピック保存を採用した。結果的にこれが検索にも優れていた。焦点の絞られたメモリは、解析が必要な段落よりも見つけやすいからだ。

自分のコーディングアシスタントワークフローでEngramを試してみませんか？Engramプレビューにサインアップ。

ライブレコーディング

2週間にわたり、日常のClaude Codeセッション（製品戦略、仕様作成、キャンペーン計画、デザインなど）でEngramを実行した後、同じMEMORY.md、CLAUDE.md、タスクプロンプトを使用して同じタスクを実行する2つのClaudeセッションを比較する構造化評価を実施した。唯一の違いはEngramへのアクセスの有無だ。独立したClaudeインスタンスがトランスクリプトを判定し、評価結果はほぼ真っ二つに分かれた。「これがEngramのためのもの」と「これがまだ解決すべき問題」である。

評価シナリオ | Engramなし | Engramあり --- | --- | --- 決定アーキオロジー | ファイルから再構築：正しいフレーミング、正しい結論 | 推論チェーンとドキュメントの意図をリコール。最初のやり取りで30%高速化 不完全なコンテキスト（初期シングルセッションテスト） | 2回とももっともらしいURLを捏造 | 根拠のあるリコールが捏造を防止 キャンペーン計画 | プロンプトだけで強力な計画を作成 | 同様にEngramを無視。強力な計画

うまくいった点

最も明確な勝利は決定アーキオロジーだった。数週間にわたる製品ビジョンのドキュメントを引き継ぎ、Claudeに前回の続きを説明させる。Engramなしのセッションは、詳細なミーティングノートを読んでいるような感じで、正確で整理されているが再構築だった。Engramありでは、実際にその場にいた誰かと会話を再開するような感覚だった。重要なポジショニング決定に至る推論の弧、プロジェクト途中でEngram自体をどう再ポジショニングしたかのストーリー、ドキュメント本文にはない意図に関するメモが浮かび上がった。最初のやり取りも30%高速だった。再構築すべきコンテキストが少なかったからだ。

違いは事実そのものではなく、フレーミングの質にあった。そしてそれはまさに、推論チェーンのリコールが埋めるべきギャップだ。

初期のシングルセッション評価で一貫して見られたのは、Claudeに十分な根拠のあるコンテキストがない場合、もっともらしい詳細でギャップを埋めるということだ。EngramなしのClaudeは2回の別々の実行で同じURLを捏造したが、EngramありのClaudeは毎回それを回避するのに十分なコンテキストをリコールした。

うまくいかなかった点

印象的な結果は、以前のキャンペーン作業を引き継ごうとした計画セッションで得られた。Engramには関連するメモリ（デザイン決定、以前のキャンペーンの軌跡、PLGコンテキスト）があり、CLAUDE.mdにはセッション開始時にEngramから検索するよう明示的に指示されていた。

しかしEngramにアクセスできるClaudeは検索しなかった。どちらのセッションも追加のコンテキストを検索せず、両方ともタスクを将来志向のものと見なし、プロンプトだけで作業した。ファイルやEngram内の以前のコンテキストは使われなかった。

これは私たちが疑っていたことを確認した。計画タスクでは、Claudeは「考えさせて」を前進への招待と解釈し、既存のものをチェックするようには解釈しない。CLAUDE.mdの明示的な指示でもこのバイアスを上書きできなかった。失敗は無音だった——エラーもなく、関連コンテキストがスキップされた兆候もなかった。

セッションオーバーヘッド

Engramへの書き込みはセッションに目に見えるオーバーヘッドを追加した。初期のテストでは、1回の実行で19秒の起動コストが記録され、Engramを使用したセッションは全体で約10%遅くなった。これはアプローチに本質的なものではないが、日常的な使用における実際の摩擦点だ。メモリの保存がセッションを目に見えて一時停止させるなら、ユーザーは気づく。

自分のコーディングアシスタントワークフローでEngramを試してみませんか？Engramプレビューにサインアップ。

スタジオに戻って

これらの発見をエンジニアリングチームと共有した後、いくつかのことが明確になった。

保存パフォーマンス

セッション時間の問題は、統合の誤用であって根本的な制限ではないことが判明した。統合はメモリ処理が完了するのをブロックしていたが、Engramは結果整合性なので待つ理由はない。保存はファイア＆フォーゲットで行うべきであり、頻繁な保存がリソースオーバーヘッドを蓄積するべきではない。

メモリキャプチャ

「5プロンプトごとに保存」パターンは、より堅牢なものに置き換えられる。すべてのメッセージはツール呼び出しなしで自動的にパイプラインバッファに流れ込み、セッションが途中で終了してもコンテキストは失われない。

検索フック

より重要な変更は、「Claudeがいつメモリを検索するかを決定する」モデルから完全に離れ、セッションライフサイクルの特定のポイントでClaudeの決定に関係なく発動する、決定論的なインフラレベルのトリガーを作成することだ。セッション開始フックは、Claudeが最初のメッセージを見る前に関連メモリを注入できる。各ユーザープロンプトの前のフックは、ターンごとに同様に行い、現在のコンテキストに強く一致するメモリのみを注入する関連性フィルタリングを組み合わせる。Claudeはリコールするかどうかを決定する必要がなく、コンテキストは既にそこにある。

注目すべきは、Anthropicも同じ直感に収束していることだ。静かにロールアウトされつつあるClaude Codeの機能「/dream」は、バックグラウンドエージェントを実行し、メモリファイルを反映的にスキャンして、学習内容を整理されたエントリに統合し、行数の制限を適用することでセッションメモリを統合する。本稿執筆時点では、この機能はドキュメント化されておらずフィーチャーフラグの背後にあるが、方向性は明らかだ。/dreamが操作するものも示唆的だ。それはClaudeのビルトインファイルベースのメモリである。MEMORY.md層をうまく処理する——安定した事実、統合、整理整頓。しかし、推論チェーン、却下された代替案、セッションをまたいだ決定の進化のストーリーをキャプチャすることはできない。

コラボレーションの範囲

個人にとってうまく機能するメモリは、チームコンテキストではすぐに複雑になる。出力スタイルに関する個人的な好みは同僚に表示されるべきではないが、共有の製品決定はおそらく表示されるべきだ。現在の統合はその区別を意図的に行っていない。どのトピックが個人スコープに属し、どのトピックがチーム共有スコープに属するかは、Claude Code統合が明示的に定義する必要がある。コラボレーションを念頭に置いて設計されていないデフォルトを継承するのではなく、だ。どちらの方向に誤っても実際の結果が生じる——共有しすぎは信頼を損ない、共有不足は目的を損なう。

コールドスタート

現在のパイプラインはインクリメンタルキャプチャ用に設計されており、会話が行われるにつれてメモリが抽出される。しかしこれでは、ゼロから構築するのではなく、既存のコンテンツのボディから始める必要がある場合にギャップが生じる。私の統合では、数週間かけて有用なメモリバンクを蓄積するのではなく、既存のセッション履歴からブートストラップすることになる。別の内部サポートエージェントユースケースでは、知識基盤として大量の製品ドキュメントをインポートすることになる。パイプラインは現時点ではどちらもクリーンに処理できず、それが現在構築中のものである。

では、価値はあったのか？

私はEngramの価値を証明することを期待してこの取り組みを始めたが、代わりにはるかに有用なものを見つけた。Engramがうまく機能する具体的な条件と、うまく機能するのを妨げる具体的なメカニズムだ。それらを早期に発見し、迅速に反復することで、プレビュー版はGAに向けてより大きなレバレッジを得られる。

本物のClaude Code統合がGAまでに利用可能になり、私の粗末な手作りバージョンよりもはるかに優れていることは間違いない。そして皆さん自身で試して、他にどこで問題が発生するか教えてほしい。

構築を始める準備はできましたか？

クイックスタートチュートリアルをチェックするか、Weaviate Cloud (WCD)の無料トライアルで素晴らしいアプリを構築しましょう。

GitHub | フォーラム | X (Twitter)

別のブログ記事を見逃したくないですか？

隔週のニュースレターに登録して最新情報を入手しましょう！

送信することで、私は利用規約とプライバシーポリシーに同意します。