TiDB 2026年6月10日の公式ブログ解説: SQLとPythonで作るエージェント記憶

PingCAP は 2026年6月10日、公式ブログで Microsoft Build 2026 のセッション内容を紹介し、TiDBで永続的なAIエージェント記憶を作る流れを説明しました。SQL、Python、ベクトル列、BM25、pytidb を組み合わせる実装寄りの記事です。

要点

• 記事は、AIエージェント記憶をモデル機能ではなく、保存、埋め込み、検索、プロンプト注入のループとして説明しています。
• TiDBでは、テキスト、ベクトル、メタデータを同じテーブルに持ち、VECTOR(1024) とHNSWインデックスを使う例が示されています。
• TiDB Cloud の生成列と埋め込みモデル連携により、挿入時にベクトルを生成する流れが紹介されています。
• ベクトル検索だけでなく、BM25の全文検索を同じ問い合わせに混ぜるハイブリッド検索の考え方も扱っています。

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

この記事は、AIエージェント記憶を抽象論ではなく、データベース上の具体的な実装ループとして説明しています。基本は、記憶として残したいテキストを保存し、そのテキストを埋め込みベクトルに変換し、次回以降の問い合わせで近い記憶を検索し、見つかった内容をプロンプトに戻すという流れです。記事では、この一連の処理をTiDB上で作る例として、同じテーブルにテキスト、VECTOR(1024) のベクトル列、メタデータを保存する構成を示しています。書き込みが増える場面では AUTO_RANDOM を使ってホットスポットを避ける設計にも触れています。

TiDB Cloud の特徴として紹介されているのは、生成列を使った埋め込み生成です。記事では、TiDB Cloud上で提供される埋め込みモデル連携を使い、挿入時にテキストからベクトルを作る流れが示されています。これにより、アプリケーション側で毎回埋め込みAPIを呼び、結果を別のストアへ同期する構成に比べて、保存と検索の距離が近くなります。もちろん外部の埋め込みモデルを使う選択肢も示されており、TiDBを中心にしてモデル選択を差し替える余地がある点も読みどころです。

記事はベクトル検索の便利さだけで終わりません。たとえば「window seats」のような表現に対して意味的に近い記憶を探せる一方で、固有名詞、正確なキーワード、日付、製品名のような条件では、全文検索が効く場面があります。そこで BM25 を使った全文検索とベクトル距離を同じ問い合わせで組み合わせ、重みを調整して結果を混ぜる方法が紹介されています。ベクトル距離は小さいほど近く、BM25スコアは大きいほど強いという違いがあるため、スコアの扱いを意識する必要があります。

Python向けには pytidb SDK が紹介され、挿入や検索の処理をより少ないコードで扱える流れが示されています。記事全体として、専用ベクトルストアを別に置くのではなく、トランザクション、メタデータ、フィルタ、並べ替え、検索を同じデータベースで扱う利点を説明しています。AIエージェント記憶は、近い文を探すだけではなく、誰の記憶か、いつの記憶か、どのスコープで有効かを一緒に管理するため、SQLデータベース上で扱う意味が出てきます。

背景にあるテーマ

エージェント記憶の実装では、ベクトル検索だけが注目されがちです。しかし本番環境では、ユーザーやセッションのスコープ、権限、更新日時、削除、並べ替え、失敗時の再実行も同時に扱います。記事は、そのためにAI検索を既存のデータベース設計へ近づける見方を示しています。

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

AIエージェントに永続記憶を持たせたいアプリケーション開発者、RAGや検索基盤を作るデータエンジニア、Pythonでプロトタイプを作るAIチームに関係します。TiDB Cloudを使って、SQLとベクトル検索を同じ基盤で試したいチームにも役立ちます。

実務へのつながり

記憶用テーブルを設計するときは、テキストとベクトルだけでなく、ユーザー、セッション、プロジェクト、作成時刻、失効状態、出所も列として考えておきたいです。検索では、意味的な近さとキーワード一致のどちらを優先するかを用途ごとに決める必要があります。SDKを使う場合も、裏側でどのモデルが埋め込みを作り、どのスコープで検索しているかを確認しておくと安全です。

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

この記事は、TiDBをAIエージェント記憶の実装基盤として試すための入口です。ベクトル、全文検索、SQLメタデータ、トランザクションを同じ場所で扱えることが、エージェント記憶を本番寄りにするうえでの焦点になります。