TiDBに関する雑多なアップデートを一週間分お届けするTiDB WEEKLY。 今週のアップデートをお届けします。
製品アップデート
TiDB Cloud リリースノート（7/28）
Dedicated のデータベース監査ログがパブリックプレビューに（7/28）
TiDB Cloud Dedicated で、データベース監査ログがパブリックプレビューとして利用できるようになりました。実行されたSQL文を含むユーザーのアクセス操作を記録するもので、対象はTiDB v7.5.6以降、またはv8.5.2以降のクラスタです。 出力先としてAmazon S3、Google Cloud Storage、Azure Blob Storageを指定でき、フィルタルールで記録対象を絞り込めます。これまでもallowlistで利用可能な機能でしたが、UIも整備されパブリックプレビューとなりました。
公式ブログ等の更新
The Agent Context Plane: How One Cluster Fixed the $50K Agent Bug（英語）
データウェアハウス、ベクトルデータベース、オーケストレーション層を継ぎ足していくと、システム間に整合性のギャップと同期コストが生まれます。そのようなギャップが原因で、AIエージェントがループし続けてしまい、テストのわずか1日で5万ドルを消費した事例が紹介されています。
記事が提案するのは「エージェント・コンテキストプレーン」、つまりトランザクションデータとエージェントが書き込むコンテキストを、ACIDを備えた単一のクラスタという同じ整合性の境界の中に置くという考え方です。これによりシステムをまたぐループがなくなり、コンテキストの組み立てが1本のSQLで済むようになります。
Why Agent Memory Needs a Database That Can Write Back（英語）
本番環境のAIエージェントには、読むだけでなく修正した状態を書き戻せるデータベースが必要だ、という主張の記事です。 求められる要件として、あるエージェントの更新が他のエージェントの状態を壊さないためのトランザクション保証、冗長な観測の重複排除、古い事実が現在の判断を誤らせないための鮮度管理、意味的な類似度と構造化データを一貫して結合できるクエリの4点を挙げています。 ベクトルデータベース単体では検索はできてもレコードを訂正する手段がなく、トランザクションストアを別に置けば整合性のギャップが生まれる、という整理です。
（雑感）このあたりの話は、直近のAI Dev Dayで私も発表したメモリの話と重複します。多くのメモリ実装でもこの機能は実装されているのですが、何を重複とみなすか、何を「古い」とみなすかは本質的には意味の問題であり機能の問題ではありません。そのため、（個人的には）メモリは将来的には1エージェントとして実装されてくるのかもなあ、と感じているところです。
それではまた来週。