SQLite一本で動くセマンティック検索——何が本当に新しいのか

解説：DropboxエンジニアがSQLite上に構築したローカルセマンティック検索「Witchcraft」、20ms以下の応答速度を実現（記事内画像）

Dropboxのエンジニア、jacobgorm氏がRedditのr/MachineLearningコミュニティに投稿した内容によれば、「Witchcraft」はStanford大学が開発したXTR-WARPセマンティック検索エンジンをSafe Rustでゼロから再実装したプロジェクトだ。Sourceが示す数字を冷淡に並べると、Apple MacBook Pro M2 Max上でNFCorpusを対象とした場合、p.95エンドツーエンド検索レイテンシは20ms、NDCG@10は33%。そして原著のXTR-WARPがサーバークラスハードウェア上で動作した際の速度と比較して、「2倍以上高速」だという主張が添えられている。

ここで立ち止まって考える必要がある。「サーバークラスハードウェア」の定義が曖昧なまま「2倍高速」と言われても、比較基準が不明瞭だ。XTR-WARPの原実装がどのCPU・メモリ構成で動いていたのか、投稿内には具体的なスペック記載がない。M2 Maxの統合メモリアーキテクチャは確かにメモリ帯域幅において優秀だが、それを「サーバークラスに対して2倍速」という文脈で語るのは、比較条件を精査しなければ意味をなさない。過去を振り返れば、2019年頃のMobile-BERTやDistilBERTが「BERTの40%サイズで97%の精度」と喧伝されたとき、ベンチマーク条件の選択によって数字が大きく変動した事例がいくつもあった。数字は正直だが、文脈は恣意的になりうる。

アーキテクチャ上の本質的な特徴は、バッキングストレージをSQLiteの単一ファイルに限定した点にある。ベクターデータベース（Pinecone、Weaviate、Qdrantなど）を排除し、チャンキング戦略も不要とすることで、クライアントサイドへのデプロイを現実的な選択肢にしている。エンタープライズ向けRAGパイプラインが抱える「どこにベクターDBを立てるか」「チャンクサイズをどう設定するか」という運用コストの問題を、アーキテクチャレベルで回避しようとする設計思想だ。これは技術的に誠実なアプローチだと私は見ている。

Pickbrain——AIセッション横断メモリの実装

Witchcraftと併せて公開された「Pickbrain」は、Claude CodeおよびOpenAI Codexのセッショントランスクリプト、メモリファイル、作成済みドキュメントをWitchcraftデータベースにインデックスするCLIツールだ。「あの認証ミドルウェアを直した会話はどこだったか」という問いに対してセマンティック検索で回答し、セッションを直接再開できるという設計になっている。

さらに、ClaudeとCodex両方向けの「/pickbrainスキル」が提供されており、エージェントがツール呼び出しとしてPickbrainを使用することで、セッション間のグローバルメモリを実現するという構成だ。具体的なユースケースとして「XTRトークンマスキングを使ったトレーニングに関する過去の取り組みを/pickbrainで読み込め」という形でエージェントに指示を与え、新規セッションに過去のコンテキストを注入できるとされている。

この設計が興味深いのは、LLMのコンテキストウィンドウ制限という根本的な制約に対して、外部セマンティック検索で補完するという古典的なRAGアプローチを、開発者の日常ワークフローに直接埋め込もうとしている点だ。ただし、セッショントランスクリプトのプライバシーリスクについては投稿内で言及がない。Claude CodeやCodexのセッションには機密性の高いコードベース情報が含まれうるが、そのデータがローカルのSQLiteに永続化される際のアクセス制御や暗号化については、現時点で確認できる情報がない。

技術的実装の評価——Safe Rustという選択とSQLiteの限界

Safe Rustでの実装は、メモリ安全性の観点からクライアントサイドデプロイにおいて合理的な選択だ。C/C++実装に比べてバッファオーバーフローやuse-after-freeのリスクを構造的に排除できる。ただし、Safe Rustの制約によってパフォーマンスクリティカルな部分でunsafeブロックを回避しながら同等の速度を出すことは、実装難度を相応に上げる。20msというレイテンシがその制約下で達成されているとすれば、実装の質は高い可能性がある——ただし独立した再現実験が伴わない限り、「可能性がある」の域を出ない。

SQLiteをバッキングストレージとして使用することの制約についても触れておく必要がある。SQLiteはWrite-Ahead Logging（WAL）モードでも、大規模な同時書き込みには向いていない。NFCorpusのようなベンチマーク規模では問題にならないが、実際の開発者が数年分のセッショントランスクリプトと大規模コードベースをインデックスした場合、データベースファイルサイズとクエリパフォーマンスの関係がどう変化するかは未知数だ。スケーラビリティの上限については、投稿内に具体的な記載がない。

NDCG@10が33%という数字についても文脈が必要だ。NFCorpusはバイオメディカル分野の情報検索ベンチマークであり、ドメイン特化した難しいコーパスとして知られている。この数字が「良い」か「悪い」かは、比較対象によって大きく変わる。BM25ベースラインとの比較、あるいは他のニューラル検索手法との比較数値が示されていれば評価しやすいが、現時点では原著XTR-WARPとの速度比較のみが強調されており、精度面での詳細な比較分析は投稿内に見当たらない。

結論——誠実な実装、だが「魔法」と呼ぶのはまだ早い

Witchcraftが解こうとしている問題——クライアントサイドで動作するローカルセマンティック検索、APIキー依存からの脱却、開発者ワークフローへのAIメモリ統合——は実在する問題だ。Safe Rustによる実装、SQLiteへの集約、XTR-WARPという学術的に裏付けのあるアーキテクチャの採用、これらは技術的に誠実な選択肢の組み合わせだと見ている。

一方で、「サーバークラスハードウェアの2倍高速」という主張の比較条件の不透明さ、スケーラビリティ上限の未記載、セッションデータのプライバシー設計の不明瞭さは、独立した検証なしには額面通りに受け取れない。2018年のIntel 10nm遅延発表と同じ構図で、「数字は出ているが条件が選ばれている」という可能性を常に念頭に置く必要がある。

プロジェクト名を「Witchcraft（魔術）」と名付けたセンスは認める。ただし魔術の正体は、たいていの場合、地道なエンジニアリングの積み重ねにすぎない——そして今回もおそらくそうだ。