TiDB 2026年5月1日の公式ブログ解説: mem9 が示すエージェント記憶の作り方

PingCAP は 2026年5月1日、AIエージェント向け永続記憶サービス mem9 をどう作ったかを公式ブログで公開しました。TiDB Cloud を基盤に、記憶を単なる保存機能ではなく、検索、評価、信頼、運用を含むプロダクトとして扱う記事です。

要点

• mem9 は、2026年3月の顧客要望から始まり、短期間でプロトタイプからプロダクトへ進んだと説明されています。
• 初期構成には、Goサーバー、記憶API、TiDB Cloudのストレージ、検索、認証、レート制限、プラグイン連携が含まれます。
• OpenClaw、OpenCode、Claude Code などのエージェント環境へ対応を広げた流れが紹介されています。
• 記憶の本質は保存ではなく、正しい情報を正しい量で戻すことだと強調されています。
• mem9 は TiDB Cloud 上で動き、ベクトル検索とSQL的な正確な絞り込みを組み合わせる記憶レイヤーとして説明されています。

今回のブログ記事で語られていること

このブログ記事は、mem9 がロードマップから始まった製品ではなく、顧客の「エージェントに記憶させたい」という具体的な要望から始まったと説明しています。PingCAP は、重い計画よりも先に、価値が見えるプロトタイプを作って顧客の反応を確認しました。エージェントが通常なら忘れる情報を覚えている体験が見えたことで、単なる面白い機能ではなく、市場が求めるプロダクトとして動き始めたという流れです。記事では、最初の数日で Go サーバー、記憶API、TiDB Cloud を使ったストレージ、検索、認証、レート制限、最初のプラグイン連携を組み上げたと説明されています。

重要なのは、mem9 が「エージェント向けベクトルデータベース」を作ろうとしたのではなく、エージェントの振る舞いを改善する記憶を作ろうとした点です。保存できるかどうかだけなら多くの仕組みで実現できます。しかし、エージェントにとって本当に難しいのは、必要な情報が必要なタイミングで、過不足なく戻ることです。少なすぎれば重要な記憶を落とし、多すぎれば文脈が汚れます。記憶の精度が下がると、利用者はエージェントを信頼できなくなります。そのため、mem9 は永続化だけでなく、取り込み、抽出、照合、ランキング、検索、評価を含むシステムへ進んだと説明されています。

FAQでは、mem9 が永続記憶レイヤーであり、セッション、マシン、ユーザーをまたいで共有記憶を提供すると述べられています。ベクトル検索だけでは、どのセッションがその記憶を書いたのか、あるユーザーが直近1時間にどのツールを呼んだのか、といった正確な質問に答えにくいです。mem9 は TiDB Cloud 上で動き、ネイティブベクトル検索とACIDトランザクションを持つMySQL互換の分散SQLを基盤にしています。自分で状態層を設計したい場合は TiDB Cloud Zero、管理された記憶APIを使いたい場合は mem9 という使い分けも示されています。

背景にあるテーマ

エージェントの記憶は、会話履歴の保管だけではなく、プロダクト体験そのものに関わります。何を覚えるか、何を忘れるか、どれを信頼して文脈に戻すかを制御できなければ、長時間動くエージェントや複数ツールを使うエージェントは安定しません。mem9の記事は、その記憶品質をインフラとプロダクトの両方で扱う必要を示しています。

今回のブログ記事が関係する人

AIエージェントに永続記憶を入れたい開発者、Claude Code やOpenCodeなどの作業履歴をまたいで活用したいチーム、ベクトル検索だけでなくSQLによる正確なフィルタや監査を必要とするプラットフォーム担当に関係します。

どう読むと価値があるか

この記事は、mem9の機能紹介だけでなく、エージェント記憶の難しさを具体化する記事として読むと有用です。記憶APIがあれば解決するのではなく、取り込み、重複排除、ランキング、検索、評価、可視化をどう設計するかが問われています。自社で作るかマネージドAPIを使うかを考える材料になります。

実務へのつながり

記憶機能を検討するなら、保存先だけでなく、検索品質、評価方法、ユーザーが記憶を確認・修正できるか、どのハーネスから使うか、権限や監査をどう扱うかを確認しておきたいです。mem9 と TiDB Cloud Zero の使い分けは、記憶ロジックを自分で持ちたいか、管理APIに任せたいかで整理できます。

結局、今回のブログ記事をどう読むべきか

これは mem9 の開発記録でありながら、エージェント記憶をプロダクト化する難しさを説明する記事です。TiDB Cloud が単なる保存先ではなく、ベクトル検索とSQLの両方を支える状態基盤として使われている点を押さえると、記事の意味が見えやすくなります。