LEANN 検証：埋め込みを保存せず再計算するベクトル索引

何を削るための道具なのか

通常のベクトル検索は、文書をチャンクに割り、各チャンクを埋め込みベクトルに変換して、そのベクトルをまとめて保存する。この保存分がそのまま索引のサイズになり、文書が増えれば増えるほどディスクを食う。LEANN が削るのはこの部分で、README は「graph-based selective recomputation」と「high-degree preserving pruning」という二つの言葉で説明している。要は埋め込みを全部持つのをやめ、グラフ探索の途中で必要になったノードの埋め込みだけをその場で計算し直す。対象として README が挙げているのは、ファイルシステム上の PDF やテキスト、Apple Mail のメール、ブラウザ履歴、WeChat や iMessage の履歴、ChatGPT や Claude の会話ログ、Slack や Twitter のブックマーク、コードベースといった個人データだ。クラウドに送らず、ノート PC の中で完結させることを前提にしている。

埋め込みを捨てても検索が壊れない理由

埋め込みを保存しないなら、検索のたびにモデルを呼び直すことになる。素朴に考えれば遅くなるだけだが、LEANN はグラフ構造の側を工夫して探索の候補を絞る。README の説明では、高次数のノードを保つようにグラフを刈り込み、そのうえで探索中に必要な埋め込みだけを再計算する。グラフ自体の保存にも CSR 形式を使い、隣接情報のオーバーヘッドを抑えるとしている。ここで重要なのは、削減の対象が埋め込みであってグラフではないという点だ。グラフは残るので、探索の道筋をたどるための構造はディスク上に存在し続ける。README は 6,000 万チャンクを 201GB ではなく 6GB に収めたという比較を掲げているが、これは特定の条件での測定値であり、埋め込みモデルの次元数やチャンク長を変えれば比率も動く。数字そのものより、保存するものと再計算するものの切り分け方を理解しておくほうが実務では役に立つ。

uv で入れて最初の索引を作るまで

README の導入手順は uv を前提にしている。まず uv 自体を入れ、リポジトリを clone して仮想環境を作り、PyPI から leann を入れる。

curl -LsSf https://astral.sh/uv/install.sh | sh git clone https://github.com/yichuan-w/LEANN.git leann cd leann uv venv source .venv/bin/activate uv pip install leann

対応プラットフォームは README のバッジによれば Ubuntu、Arch、WSL、macOS の ARM64 と Intel、Windows。Python は 3.10 から 3.14 までが示されている。ここで注意したいのは、埋め込みモデルの選択が利用者側に委ねられている点だ。埋め込みを保存しない設計では、索引を作ったときと検索するときで同じモデルを使う必要がある。モデルを差し替えれば、保存済みのグラフと再計算されるベクトルが噛み合わなくなる。手順そのものは短いが、モデルを固定する運用ルールを先に決めておかないと後で作り直しになる。

Claude Code に差し込む MCP の位置づけ

README は Claude Code との連携を前面に出している。Claude Code が標準で持つのは grep 系のキーワード検索で、意味的な近さでは引けない。LEANN は MCP サービスとして動き、その検索部分を置き換える。設定手順は packages/leann-mcp/README.md に分離されているので、本体のインストールとは別に読む必要がある。README は ContextBench の 30 タスクで BM25 と比較した結果として、関連コードの初回再現率が 24.2% 対 11.4%、探索後のカバレッジが 38.4% 対 25.8%、トークン使用量が 3.22M 対 3.51M という数値を挙げている。ただし同じ節に、モデル、エージェント、ツール、検索予算を固定した条件での macro-averaged な指標であり、コンテキストへのアクセスが良くなっても issue が解決するとは限らない、という注記が付いている。この注記ごと読むべきで、数値だけを引用すると過大な期待につながる。

再計算方式が裏目に出る場面

最大の制約は、検索のたびに埋め込み計算が発生することだ。保存を削った分のコストは計算側に移る。GPU を持たないノート PC で大量のクエリをさばく用途や、レイテンシが厳しく決まっているサービスには向かない。README が想定しているのは個人が自分のデータを検索する場面で、同時実行数の多いサーバーではない。もう一つ、データを頻繁に更新する用途も相性が悪い。グラフの刈り込みは文書集合の分布に依存するので、追加や削除のたびに索引を作り直す頻度が上がる。さらに、埋め込みモデルを固定できない実験段階では、モデルを変えるたびに索引の再構築が必要になる。ストレージが潤沢でレイテンシを最優先するなら、埋め込みを全部持つ従来型のベクトル DB のほうが素直だ。

FAISS や Chroma との設計上の違い

比較対象として分かりやすいのは FAISS だ。FAISS はベクトルをメモリまたはディスクに置き、近似最近傍の探索に集中したライブラリで、埋め込みの生成は利用者の仕事になる。索引はベクトルそのものを前提に組み立てられる。LEANN は逆で、ベクトルの集合を索引の前提にしない。グラフと再計算の手順を索引として持ち、ベクトルは探索時に生成する。この違いは、ストレージとレイテンシのどちらを犠牲にするかの選択として現れる。Chroma のような組み込み型のベクトル DB も永続化を前提にする点では FAISS 側と同じ系統だ。LEANN を選ぶということは、検索時の計算コストを受け入れてディスクを空けるという取引を選ぶことに等しい。トピックに faiss や llama-index、langchain が並んでいるのは、これらと併用する導線があることを示しているが、置き換え関係にあるのは保存方式の部分だ。

MIT ライセンスと更新の追い方

ライセンスは MIT で、商用利用を含めて扱いやすい条件だが、これは法的助言ではないので自組織の規約に照らした確認は別途必要になる。リリースは v0.3.5 が 2025 年 11 月、v0.3.6 が 2026 年 1 月、v0.3.7 が 2026 年 3 月と、おおよそ二か月間隔で続いている。0.x 系である以上、マイナー更新で索引フォーマットや既定の挙動が変わる可能性は残る。README には v0.4 に向けたコミュニティ調査への導線があり、GPU 対応か連携先の拡充かを投票で決めるという案内と、テレメトリを一切取っていないという記述がある。更新コストを見積もるなら、索引を作り直す手間を前提に置くこと。埋め込みモデルとデータ量を固定して、リリースごとに再構築の所要時間を測っておけば、上げるかどうかの判断材料になる。

編集部の結論

LEANN が向くのは、手元のノート PC や個人用マシンでメール、ブラウザ履歴、チャットログ、私的なファイル群を扱いたい人です。データを外部に出したくない、あるいはクラウドのベクトル DB に月額を払いたくないという動機がはっきりしている場合に意味があります。逆に、ミリ秒単位のレイテンシが要件の高トラフィックなサービスや、埋め込みモデルを固定できず頻繁に差し替える用途には向きません。埋め込みを保存しない設計は、検索のたびに計算をやり直すことを意味するからです。導入前に確認すべきは、自分の環境で Python 3.10 以降と uv が使えること、使う埋め込みモデルを自分で決めて固定できること、そして手元の文書量で索引構築が現実的な時間に収まることです。README に載っている 60M チャンクで 6GB という数値は特定のモデルとデータでの測定結果であり、自分のデータにそのまま当てはまる保証はありません。まず手元の文書を数百件程度で索引化し、検索品質と応答時間を測ってから本番のデータ量に広げるのが現実的な進め方です。

公式情報源

1. License: MIT
2. Project website
3. README
4. Releases
5. StarTrail-org/LEANN on GitHub