TiDBに関する雑多なアップデートを一週間分お届けするTiDB WEEKLY。今週のアップデートをお届けします。
すいません！前回お休みしてしまったので、直近2週間（6/9〜6/23）分まとめてお届けします！
製品アップデート
TiDB Cloud リリースノート
TiDB Cloud Starter で全文検索の対応リージョン追加（6/9）
TiDB Cloud Starter の全文検索（パブリックプレビュー）が、新たに AWS の N. Virginia（us-east-1）リージョンで利用可能になりました。これで対応リージョンは Tokyo・Oregon・N. Virginia・Frankfurt の 4つになりました。
TiDB Cloud Premium にバックアップ管理 API を追加（6/9）
TiDB Cloud Premium 向けに、新しいバックアップ API エンドポイントが 2 つ追加されました。稼働中のインスタンスと削除済みインスタンスをまたいでバックアップを横断的に管理でき、組織内の全バックアップ一覧の取得や、ID を指定した特定バックアップの削除がプログラムから行えます。
組織 SSO でドメイン検証が必須に（6/16）
TiDB Cloud の組織レベル SSO で、ドメイン検証（Domain Verification）が必須化されました。OIDC / SAML の自動プロビジョニング有効化時、または SAML の SCIM プロビジョニング有効化時に「Allowed Email Domains」フィールドが必須となり、ドメインを入力する前に所有権の検証を完了しておく必要があります。全プラン（Starter / Essential / Premium / Dedicated）が対象の GA 機能で、不正アクセス経路を減らすためのセキュリティ強化です。
公式ブログ等の更新
Database Branching for AI Agents: How TINE Solves the Schema Drift Problem（英語）
AI コーディングエージェントが共有データベースに対して試行錯誤を繰り返すと、「スキーマドリフト（部分的に失敗したマイグレーションでスキーマが壊れた状態になる）」「再現不能な状態（コミット・スキーマ・実行環境の組み合わせを復元できない）」「ロールバックの穴（実行済みマイグレーションのデータ・スキーマは元に戻せない）」という 3 つの問題が複合的に発生します。
この記事で紹介する TINE（TiDB Iterative Non-Destructive Environment） は、エージェントの各イテレーションを「Git のコミット SHA・TiDB のブランチ ID・サンドボックスのランタイム ID」の 3 つを束ねた Revision として扱うことで、完全な再現性を実現するアプローチです。イテレーションごとに TiDB Cloud のブランチを Copy-on-Write で払い出し、親のスキーマとデータを数分で引き継ぎつつ以降の変更を隔離します。失敗したマイグレーションは現在のブランチにしか影響せず、データの状態もコードと同等の「リビジョン成果物」として扱うのが特徴です。
Conway’s Law in Reverse: Why AI Agents Need One Database, Not Ten（英語）
「組織構造がシステム設計を規定する」というコンウェイの法則を逆向きに捉え、統合されたデータアーキテクチャを選ぶことが組織のフラット化を促すと論じたブログです。AI エージェントの 1 つの操作（状態の読み取り・メモリ取得・ファクトチェック・意思決定の書き込み）は、従来型アーキテクチャでは 6つの別システムにまたがり、6回のラウンドトリップと古いデータを読むリスクを生みます。「エージェントで古いデータを読むことは誤った意思決定を即座に下すことにもなる」と指摘し、これが数千インスタンスの並行実行で指数関数的に悪化すると述べています。
TiDB はトランザクション・キャッシュ・検索・分析・ベクトル・ドキュメントといった機能を 1つに統合し、一貫したデータを提供します。さらに TiDB X のコンピュート／ストレージ分離（共有オブジェクトストレージ）により、即時のブランチ作成とリバランス遅延のない高速スケーリングが可能になる、としています。
Build Persistent, Scalable AI Agent Memory with TiDB（英語）
「エージェントのメモリはモデルの機能ではなくインフラのパターンである」という立場から、TiDB を使って永続的でスケーラブルなエージェントメモリを実装する実践的なフレームワークを解説したブログです。どのメモリシステムも「情報を行として保存 → テキストをベクトル埋め込みに変換 → 意味的に近いベクトルを検索 → 関連結果を LLM のプロンプトに注入」という同じループを辿る、と整理します。
実装面では、テキスト・ベクトル埋め込み・メタデータを 1つのテーブルに統合し、ネイティブの VECTOR(1024) 型と HNSW インデックスを使います。生成カラムによる auto-embedding（Amazon Titan などのモデルで埋め込みを自動生成）、ベクトル類似度と BM25 全文検索を組み合わせた ハイブリッド検索、AUTO_RANDOM による書き込みホットスポット回避が紹介されています。pytidb SDKはこれらの詳細を隠蔽し、プレーンテキストを挿入して自然言語で問い合わせるだけで使えるようにします。
それではまた来週！