結論から言うと、AIエージェントのメモリ設計を理解していないCEOは、ツール選定で普通に損をする。
先週、採用候補者との面談準備をClaudeにやらせていた。候補者の過去の発言や職歴の要点を会話の流れで渡していくやり方だ。3回目の面談になると、Claudeが前回の文脈をほぼ引き継げていないことに気づいた。それ自体は想定内だったが、ポーランドのエンジニアbrgsk氏の解説を読んで、何が起きていたかようやく腑に落ちた。
AIエージェントのメモリは「抽出器・保存先・検索器」の3つで動いている。抽出器が会話から「ユーザーはTypeScriptを好む」みたいな短い事実を切り出し、保存先に貯め、検索器が必要なときに引っ張り出してLLMに渡す。この流れ自体はシンプルだ。問題はその各工程で情報が削ぎ落とされていく点にある。「火曜日にコーヒーを飲みながらTypeScriptの話をした」という場面は、「ユーザーはTypeScriptを好む」という事実に圧縮される。日時・ニュアンス・強調の度合いはそこで消える。
採用文脈に置き換えると話は早い。候補者が「前職のスタートアップでは資金調達フェーズに主体的に関わった」と言ったとする。AIが意味記憶として保存するのは「資金調達経験あり」だけになりかねない。Series Aのクローズ直前という切迫したタイミングで主体的に動いた、というニュアンスは落ちる。この差は、うちみたいな8人規模でGTMを一緒に動かすメンバーを選ぶ場面では致命的になりうる。
記事ではLangMemとMem0という2つのメモリライブラリが比較されていた。LangMemはシステムプロンプト自体を書き換えてエージェントの行動傾向を変える仕組みを持つ。いわゆる「手続き記憶」に近い実装だ。Mem0は保存・検索の仕組みが意味記憶ベースで、どちらかというと事実の蓄積に向いている。
うちの文脈で言うと、セールスのフォローアップ自動化にエージェントを使うなら、Mem0的な意味記憶で「この見込み客はコスト削減に関心が高い」という事実を蓄積するだけでも十分機能する。一方で、採用やカスタマーサクセスのように「対話の質を繰り返しの中でチューニングしていく」ような使い方には、LangMemのアプローチの方が合う。ツール選定の判断基準がここで変わる。投資家への説明にも使えるフレームだ。
もう一つ刺さったのがAnthropicの「Dreaming」とバークレー大学・Lettaの「sleep-time compute」の話だ。人間の睡眠中の記憶整理に似た仕組みで、蓄積した記憶を後から見直して重複をまとめ矛盾を解消する技術として提唱されている。今はまだ研究段階だが、この方向が実用化されると、長期的なユーザー文脈を扱うSaaSプロダクトの差別化要素になりうる。競合がここに気づき始める前に実験しておく価値はある。
先月、同じポートフォリオにいる別のスタートアップのCEOと飯を食った。「うちのAIエージェント、ちゃんと記憶してくれてる」という話をしていた。おそらく意味記憶の蓄積が動いているだけで、手続き記憶も展望記憶もほとんど実装されていない状態だと思う。brgsk氏の言い方を借りると「名前ほど幅広い記憶システムではない」。
現状のAIエージェントのメモリは、エピソード記憶は意味記憶に圧縮され、手続き記憶はラベルだけの実装が多く、条件トリガー型の展望記憶はほぼ未開拓だ。この制約を知らずに「AIが覚えてくれる」と思い込むと、プロダクトの設計で楽観的すぎる判断をしてしまう。PMFを目指す段階では、そのズレは早めに潰しておいた方がいい。
妻に「また難しそうな記事読んでるね」と言われたが、これは技術の話じゃなくてリスク管理の話だ。どのメモリライブラリが自分のユースケースに合うか、来週チームに確認を取る。
先週、採用候補者との面談準備をClaudeにやらせていた。候補者の過去の発言や職歴の要点を会話の流れで渡していくやり方だ。3回目の面談になると、Claudeが前回の文脈をほぼ引き継げていないことに気づいた。それ自体は想定内だったが、ポーランドのエンジニアbrgsk氏の解説を読んで、何が起きていたかようやく腑に落ちた。
メモリの構造を3行で整理する
AIエージェントのメモリは「抽出器・保存先・検索器」の3つで動いている。抽出器が会話から「ユーザーはTypeScriptを好む」みたいな短い事実を切り出し、保存先に貯め、検索器が必要なときに引っ張り出してLLMに渡す。この流れ自体はシンプルだ。問題はその各工程で情報が削ぎ落とされていく点にある。「火曜日にコーヒーを飲みながらTypeScriptの話をした」という場面は、「ユーザーはTypeScriptを好む」という事実に圧縮される。日時・ニュアンス・強調の度合いはそこで消える。
採用文脈に置き換えると話は早い。候補者が「前職のスタートアップでは資金調達フェーズに主体的に関わった」と言ったとする。AIが意味記憶として保存するのは「資金調達経験あり」だけになりかねない。Series Aのクローズ直前という切迫したタイミングで主体的に動いた、というニュアンスは落ちる。この差は、うちみたいな8人規模でGTMを一緒に動かすメンバーを選ぶ場面では致命的になりうる。
LangMemとMem0の違いがROIに直結する
記事ではLangMemとMem0という2つのメモリライブラリが比較されていた。LangMemはシステムプロンプト自体を書き換えてエージェントの行動傾向を変える仕組みを持つ。いわゆる「手続き記憶」に近い実装だ。Mem0は保存・検索の仕組みが意味記憶ベースで、どちらかというと事実の蓄積に向いている。
うちの文脈で言うと、セールスのフォローアップ自動化にエージェントを使うなら、Mem0的な意味記憶で「この見込み客はコスト削減に関心が高い」という事実を蓄積するだけでも十分機能する。一方で、採用やカスタマーサクセスのように「対話の質を繰り返しの中でチューニングしていく」ような使い方には、LangMemのアプローチの方が合う。ツール選定の判断基準がここで変わる。投資家への説明にも使えるフレームだ。
もう一つ刺さったのがAnthropicの「Dreaming」とバークレー大学・Lettaの「sleep-time compute」の話だ。人間の睡眠中の記憶整理に似た仕組みで、蓄積した記憶を後から見直して重複をまとめ矛盾を解消する技術として提唱されている。今はまだ研究段階だが、この方向が実用化されると、長期的なユーザー文脈を扱うSaaSプロダクトの差別化要素になりうる。競合がここに気づき始める前に実験しておく価値はある。
「メモリ」という言葉に騙されない
先月、同じポートフォリオにいる別のスタートアップのCEOと飯を食った。「うちのAIエージェント、ちゃんと記憶してくれてる」という話をしていた。おそらく意味記憶の蓄積が動いているだけで、手続き記憶も展望記憶もほとんど実装されていない状態だと思う。brgsk氏の言い方を借りると「名前ほど幅広い記憶システムではない」。
現状のAIエージェントのメモリは、エピソード記憶は意味記憶に圧縮され、手続き記憶はラベルだけの実装が多く、条件トリガー型の展望記憶はほぼ未開拓だ。この制約を知らずに「AIが覚えてくれる」と思い込むと、プロダクトの設計で楽観的すぎる判断をしてしまう。PMFを目指す段階では、そのズレは早めに潰しておいた方がいい。
妻に「また難しそうな記事読んでるね」と言われたが、これは技術の話じゃなくてリスク管理の話だ。どのメモリライブラリが自分のユースケースに合うか、来週チームに確認を取る。