LEANN徹底解説｜埋め込みを保存しないローカルRAGで最大97%省ストレージ｜仕組み・使い方・実測

LEANNは、埋め込みを保存しないローカルRAG向けのベクトルインデックスです。社内ドキュメントや自分のメール、何年分ものチャット履歴を「意味で」検索したい——その答えがRAG（検索拡張生成）ですが、ローカルで動かそうとすると必ずぶつかる壁があります。埋め込み（embedding）の保存でストレージが爆発するのです。数百万チャンクをベクトルDBに入れると、インデックスだけで数十〜数百GBに膨れ上がり、ノートPCには到底載りません。

LEANN（StarTrail-org/LEANN・旧 yichuan-w/LEANN・GitHubスター12,699・MIT）は、この前提そのものをひっくり返します。埋め込みを一切保存しないのです。UC Berkeley の Sky Computing Lab が開発し、論文がシステム分野のトップ会議MLsys 2026に採択された（arXiv 2506.08276）このOSSは、自分を「世界最小のベクトルインデックス」と称し、従来比で最大97%小さいストレージでローカルRAGを回します。まずは、公式のドキュメント検索デモから。

なお、RAGそのものの仕組み・ベクトルDB選定・評価までの全体像は RAGとは？仕組み・構築・ベクトルDB選定まで【2026年完全ガイド】 にまとめています。本記事はその中でも「ローカルで・省ストレージで動かす」という一角を、LEANNを実際に動かして深掘りする位置づけです。

LEANNとは — 埋め込みを保存しない「世界最小のベクトルインデックス」

LEANNは、ひとことで言えばローカルRAGを現実的なストレージで回すためのベクトルインデックスです。読者がまず知りたい「①結局これで何ができるのか」から答えると、LEANNは自分のノートPC上で、次のようなデータを意味ベースで検索・質問応答できるようにします。手元のPDFやMarkdownはもちろん、Apple Mailのメール、Chromeのブラウザ履歴、WeChatやiMessageのチャット、ChatGPT/Claudeの会話エクスポート、さらにはコードベース——これらを「キーワード一致」ではなく「意味の近さ」で引ける状態にする、というのが実体です。

そして「②何を解決するのか」。従来のベクトルDB（FAISS・Chroma・Pineconeなど）は、テキストを分割したチャンク一つひとつを埋め込みモデルでベクトル化し、その高次元ベクトルをすべて保存します。ここがローカル運用の致命的なボトルネックでした。埋め込みは1チャンクあたり数百〜数千次元 × 4バイト（float32）で、数百万チャンクにもなればインデックスだけで数十〜数百GBに達します。LEANNはこの「全部保存する」という常識を捨て、埋め込みをディスクに残さない設計で、同じ検索品質を桁違いに小さいストレージで実現します。

もう一つ、当サイトの読者に効くのがプライバシーです。埋め込みの計算も検索も100%ローカルで完結するため、データがOpenAIやクラウドに送られません（生成に使うLLMをローカルのOllama等にすれば、本当に一切外に出ません）。「社内文書を外部APIに投げたくない」「個人のメールやチャットをクラウドに預けたくない」というニーズに、そのまま応えられる構造になっています。

なぜ埋め込みを保存しなくて済むのか — グラフベース選択的再計算の仕組み

この記事のいちばんの目玉が、この「なぜ保存しないで済むのか」です。ここを理解すると、LEANNが魔法ではなく、明快なエンジニアリングのトレードオフの上に成り立っていることが分かります。

鍵は3つの技術の組み合わせです。グラフベースの選択的再計算（graph-based selective recomputation）、高次数保持プルーニング（high-degree preserving pruning）、そして動的バッチング（dynamic batching）。順に見ていきます。

まず前提として、HNSWやDiskANNといった近似最近傍探索（ANN）は、チャンク同士を「近いもの同士つなぐ」グラフとして索引します。検索は、このグラフをたどって（グラフトラバーサル）クエリに近いノードへ収束していく処理です。ここで従来型は、各ノードの埋め込みをあらかじめ全部保存しておき、探索中に距離計算で使います。LEANNの発想は逆で、埋め込みは保存せず、探索経路に乗ったノードのぶんだけ、その場で埋め込みを計算し直す。全体のごく一部しか探索経路には乗らないので、再計算するのも一部だけで済む——これが「選択的再計算」です。

次に「それでもグラフ自体は保存するのでは？」という疑問。ここで効くのが高次数保持プルーニングです。グラフの辺（エッジ）は、放っておくと膨大になります。LEANNは、多くのノードにつながる重要な「ハブノード」は残しつつ、冗長な接続を削り、CSR（Compressed Sparse Row）形式でコンパクトに格納します。埋め込みという「重いデータ」を捨て、残った「軽いグラフ」もさらに圧縮する——この二段構えで、インデックスは劇的に小さくなります。

最後に速度。埋め込みを都度計算すると遅くなりそうですが、LEANNは動的バッチングと2レベル検索（two-level search）で、GPU/CPUの計算を効率よくまとめ、まず近似的に有望なノードを絞ってから精密化することで、再計算のコストを抑えます。それでも「保存型より計算は増える」のは事実で、これは後述する検索レイテンシのトレードオフに直結します。

本当に97%削減できるのか — 一次情報と編集部の実測

「最大97%削減」は強烈な数字です。だからこそ、どの条件での話なのかを正確に押さえる必要があります。結論から言うと、97%は特定のデータセットでの最大値であり、無条件に効く数字ではありません。

一次情報（公式README/論文）のストレージ比較を、そのまま引用します。「Traditional（例: FAISS）」は埋め込みを保存する従来型ベクトルDB、下段がLEANNです。

つまり、見出しの「97%」は表のWiki 6000万件という最大規模のケースであり、DPR 210万件では91%、ブラウザ履歴3.8万件では95%です。「どんなデータでも一律97%」ではありません。当サイトとしては、この条件（規模・データセット）を明示せずに97%を独り歩きさせないことが、一次情報メディアとしての最低限だと考えます。

編集部の実測 — 自分のMacBookで動かした

では、手元で動かすとどうなるのか。過去に別記事で「セルフホストの実測値」を独自データとして出したのと同じ流儀で、LEANNを実際にインストールして小規模コーパスをインデックス化し、ストレージと時間を測りました。

構成は leann 0.3.7、埋め込みモデルは既定の facebook/contriever（768次元）、HNSWバックエンドで再計算（recompute）有効。コーパスには著作権の切れた小説『高慢と偏見』の全文を使い、708チャンクにインデックス化しました。結果は次のとおりです。

・LEANNインデックスの実サイズ：0.73 MB（764,742バイト。内訳は本文テキスト保持の passages.jsonl が約739KB、グラフの passages.idx が7.4KB、メタ0.5KB）
・同じ708チャンクを生の埋め込み（float32・708×768×4）で保存した場合：2.07 MB
・削減率：64.8%（＝生の埋め込み比。FAISS比ではなく、埋め込みストレージの理論下限との比較なので保守的な数字）
・インデックス構築：約123秒。検索は都度再計算のため重く、CPU単体で1クエリあたり約55〜85秒（初回はモデルロード込みで約55秒、以降のクエリも平均約85秒／top_k 依存）

検証環境：Apple Silicon（macOS 14.5）／leann 0.3.7（PyPI）／埋め込み facebook/contriever（768次元）／HNSWバックエンド・recompute有効・CPU実行（MPS/GPU未使用）／検証日 2026-07-18。使用コーパスは著作権消滅済みの『高慢と偏見』全文。

削減率が論文の97%より小さいのはコーパスが小さいからです。708チャンクという小さな索引では、LEANNが保持する本文テキスト（739KB）がインデックスの大半を占め、固定オーバーヘッドも相対的に大きく効きます。README自身の表も、規模が小さいブラウザ履歴（3.8万件）は95%、規模が大きいWiki（6000万件）は97%と、削減率が規模とともに伸びることを示しています。編集部の64.8%は、その延長線上にある「小規模での実測」であり、論文の数字と矛盾するものではなく、むしろ規模依存性を裏づける結果です。逆に言えば、扱うデータが大きいほどLEANNの旨みは増す——数万件程度の小さな索引なら、正直なところ保存型のベクトルDBでも困りませんが、数百万〜数千万件を1台のノートPCに載せたい、というLEANNが本来狙う領域でこそ、この省ストレージ設計は真価を発揮します。

一方で、実測で浮かび上がった検索の重さは、用途を選ぶ現実的な論点です。CPU単体で1クエリに1分前後かかるのは、対話的に何十回もクエリを投げる使い方には向きません。ただしこれは「MPS/GPUを使わないCPUのみ・contriever・全再計算のHNSW」という、最も保守的な構成での値です。埋め込みデバイスをApple SiliconのMPSやCUDAに切り替える、より軽い埋め込みモデルを使う、あるいはDiskANNバックエンド（PQ＋再ランキング）にする、といった手で改善余地があります。「どれくらいの頻度で・どんなマシンで検索するか」を先に決めてから、バックエンドと埋め込みデバイスを選ぶのが、LEANNを実用に落とすコツです。

LEANNで何ができるのか — ファイル・メール・履歴・コードを丸ごと意味検索

読者の「①何ができる」に具体で答えます。LEANNの面白さは、抽象的な「ベクトルインデックス」ではなく、自分の生活データをそのままRAGにできるアプリ群が揃っていることです。READMEには、そのまま動く例が並んでいます。

・ドキュメント（.pdf / .txt / .md / .docx / .pptx）：フォルダを指定するだけで、論文や資料を意味検索。コードファイルはAST対応チャンキングで関数・クラス単位に分割
・Apple Mail：78万件のメールチャンクが約78MBに収まり、「DoorDashで頼んだ食べ物は？」のように自然文で検索（macOS、フルディスクアクセス許可が必要）
・Chromeブラウザ履歴：3.8万件の履歴が約6MBに。自分の閲覧履歴が個人用検索エンジンになる
・チャット履歴：WeChat（40万件→約64MB）やiMessage（~/Library/Messages/chat.db）を、年単位でさかのぼって検索
・AIの会話ログ：ChatGPT/Claudeのエクスポート（HTML/JSON）を取り込み、「あのとき聞いたPythonの話」を掘り起こす

これらは「③何を代替できるか」にも直結します。多くの人は、メールやチャットを純正アプリの貧弱なキーワード検索でしか引けていません。LEANNは、そこに意味検索を持ち込む代替手段になります。しかも全部ローカルなので、プライバシーを保ったまま実現できます。

実務で効く細かい機能も揃っています。メタデータフィルタリングでは、チャンクにファイル拡張子や行数などの属性を付けておき、file_extension == ".py" や lines_of_code < 100 のような条件で検索を絞り込めます（==・!=・<・in・contains・starts_with などの演算子に対応）。また、意味検索だけでなく厳密一致のgrep検索も use_grep で併用でき、関数名やエラーメッセージのような「意味の近さより完全一致が欲しい」場面に使い分けられます。意味検索と全文検索を1つのインデックスで両取りできるのは、コードやログを扱う開発者に地味に効くポイントです。

Claude Code / MCP 連携 — grep検索を意味検索に変える

当サイトの読者にいちばん刺さるのがここです。LEANNは Model Context Protocol（MCP）をネイティブに扱い、Claude Code をはじめとするエージェントと双方向に噛み合います。

方向その1：LEANNを「Claude Codeの意味検索」にする。 Claude Code のコード検索は、基本的に grep 的なキーワード一致です。「認証処理はどこ？」と聞いても、auth という文字列を含む行しか拾えません。LEANNは、Claude Code にドロップインで追加できるセマンティック検索MCPサーバーとして動き、意味ベースの検索（leann_search）と質問応答（leann_ask）を、ワークフローを変えずに足します。しかもインデックスは完全ローカル・軽量です。

セットアップは2コマンドで済みます。グローバルにLEANNを入れ、Claude Code にMCPサーバーとして登録するだけです。

# LEANNをグローバルに導入（MCP連携にはグローバル導入が必須）
uv tool install leann-core --with leann

# Claude Code にLEANNのMCPサーバーを登録（ユーザースコープ）
claude mcp add --scope user leann-server -- leann_mcp

ここで効くのがAST対応チャンキングです。Python・Java・C#・TypeScriptについては、関数・クラス・メソッドの意味的な境界を保ってチャンク化するため、テキストを機械的に切るより「コードの文脈」を壊しません。自動言語判定でゼロコンフィグに近い形で使えます。

方向その2：MCPサーバー経由のライブデータをLEANNでRAGする。 逆向きの連携もあります。LEANNは Slack や Twitter といったプラットフォームのMCPサーバーに接続し、手動エクスポートなしのライブデータを取り込んでインデックス化できます。たとえば slack_rag で「製品ローンチについてチームが何を決めたか」をチャンネル横断で検索する、といった使い方です。手動エクスポート（オフライン・一度きり）と、MCP（ライブ・都度更新）を用途で選べる設計になっています。

既存の代替と何が違うのか — FAISS / Chroma / 通常のベクトルDBとの比較

「結局、FAISSやChromaと何が違うのか」を整理します。結論は、LEANNは汎用ベクトルDBの置き換えではなく、『ローカル・省ストレージ・プライバシー最優先』という別レーンの最適化だ、ということです。ベクトルDBの選定軸そのものは ベクトルデータベース比較2026｜Qdrant・Milvus・pgvectorをRAG用途で選ぶ完全ガイド に詳しくまとめていますが、LEANNはその表のどれとも設計思想が異なります。

グラフ×知識という角度では、LightRAG｜知識グラフ×デュアルレベル検索でRAGの精度と網羅性を高める仕組み も「グラフを使うRAG」ですが、LightRAGが検索の質（知識グラフによる網羅性）を狙うのに対し、LEANNが狙うのはストレージ効率とローカル完結で、目的が違います。企業向けにチャットボットとして丸ごと立てたいなら Onyx AIとは？企業向けRAGチャットボットの使い方・導入手順・Docker構築ガイド のような統合スタックが向く、という具合に、レイヤーで棲み分けられます。

使えるOSSか — ライセンス・活性度・バス係数の正直な評価

「自分の環境に入れてよいか」を判断する材料を、良い点も懸念も並べて正直に評価します（すべて2026年7月18日時点の実測）。

・ライセンスは標準のMIT。 商用・改変・再配布とも自由で、法務上のハードルは低い。前回扱ったdcgのような「反AIベンダー条項」付きではなく、素直なMITです
・開発は活発。 GitHubスター12,699、フォーク1,147、コントリビューター41人。UC Berkeleyの研究室が母体で、DeepWikiにも索引済み
・バス係数は約2で健全側。 コミットは Yichuan Wang（yichuan-w・242）と Zhifei Li（andylizf・189）の2名が中心で、実質1人だったdcg（バス係数≈1）より分散しています。単独障害点になりにくい
・懸念：リリースの間隔。 タグ付きリリースは29本ありますが、最新の v0.3.7 は2026年3月8日で、そこから約4か月タグが出ていません。一方 main へのプッシュは2026年7月3日と、コミット自体は継続しています（＝リリースの節目が空いているだけで、開発停止ではない）。バージョンは pre-1.0（v0.3.x）で、APIやフォーマットの破壊的変更もあり得ます
・懸念：ビルドの重さ。 DiskANNバックエンドは libomp/boost/protobuf/zeromq 等のネイティブ依存が必要で、環境によってはビルドでつまずきます（HNSWのみなら軽い）

総合すると、「ローカルで・省ストレージで・プライバシーを保ってRAGしたい」個人〜小規模なら、入れて試す価値が高いOSSです。MITで法務も軽く、Claude Code連携という当サイト読者のど真ん中の刺さりどころもあります。一方、大規模・低レイテンシのプロダクション用途では、検索の計算コストとpre-1.0という現実を評価に載せるべきです。

導入と確認 — コピペで動かす手順

最後に、実際に手元で動かす最短手順です。前提として、Python環境管理ツールの uv を使います。

# 1) uv を導入（未導入の場合）
curl -LsSf https://astral.sh/uv/install.sh | sh

# 2) リポジトリを取得（サンプルとデモを使うため）
git clone https://github.com/StarTrail-org/LEANN.git leann
cd leann

# 3) 仮想環境を作り、PyPIからLEANNを導入
uv venv
source .venv/bin/activate
uv pip install leann
# Linux でCPUのみなら: uv pip install "leann[cpu]"

導入できたら、付属のドキュメントRAGでまず一度動かして体感します（data/ にサンプルが入っているので、これが最も簡単です）。

# 付属サンプルに対してLEANNのドキュメントRAGを実行
python -m apps.document_rag --query "What are the main techniques LEANN explores?"

CLIとして常用するなら、グローバル導入して自分のフォルダをインデックス化します。ここが日常の使い方です。

# CLIをグローバル化（Claude Code連携にも必須）
uv tool install leann-core --with leann

# 自分のドキュメントから索引を作る（index名: my-docs）
leann build my-docs --docs ./your_documents

# 意味検索する
leann search my-docs "認証まわりの実装はどこ"

# 対話モードで質問応答（既定はOllama。--llm openai 等も可）
leann ask my-docs --interactive

# 索引の一覧・削除、ファイル変更の検知（Merkleツリーで差分検出）
leann list
leann watch my-docs

導入後は、「本当に索引が作れて・検索できているか」を自分の環境で確認しておきましょう。以下はいずれも破壊的操作を伴いません。

# 作った索引の一覧と状態（✅=正常 / ❌=不完全）を確認
leann list

# 生成に完全ローカルのLLMを使いたい場合（例: Ollama）
ollama pull llama3.2:1b
leann ask my-docs --llm ollama --model llama3.2:1b "このプロジェクトの要点は"

運用で地味に効くのが、差分更新です。ドキュメントは日々増えますが、その都度フルで索引を作り直すのは無駄が大きい。LEANNの leann watch は、SHA-256ベースのMerkle（マークル）ツリーのスナップショットで前回チェックポイントとの差分を検出し、追加・変更・削除されたファイルとそのチャンクIDだけを報告します。CIやスクリプトに組み込めば「変わったファイルだけを再インデックスする」パイプラインを組めるため、大きなコードベースやドキュメント群を継続的に最新化する用途に向きます。

# 前回のチェックポイント以降に変わったファイルを検出
leann watch my-docs
# 例: modified (1): /path/to/file.py  chunks: 42, 43, 44

まとめ — LEANNは「ローカルRAGの前提」を書き換えるか

LEANNの価値は、「ローカルRAGは埋め込み保存でストレージが膨張する」という当たり前だった前提を、埋め込みを保存しない設計で覆したことにあります。グラフベースの選択的再計算・高次数保持プルーニング・動的バッチングという明快な仕組みで、論文実測では60Mチャンクを201GB→6GB（97%削減）に収め、ノートPC上でファイル・メール・履歴・コードを100%ローカルで意味検索できる。MITで、Claude Code / MCP 連携という当サイト読者のど真ん中の刺さりどころもある——個人〜小規模のローカルRAGなら、入れて試す価値は十分です。

同時に、過大評価は禁物です。「97%」はデータ規模に依存する最大値（91〜97%の幅）であり、無条件ではありません。編集部の小規模実測が64.8%だったように、規模が小さいほど削減率は下がります。そして省ストレージの代償として、埋め込みを都度再計算する検索は計算コストが増える（CPU単体だと遅い）。pre-1.0でリリース間隔が空いている点も含め、大規模・低レイテンシの本番投入なら評価が要ります。その線引きさえ理解すれば、LEANNは「クラウドに送りたくないデータを、手元の現実的なストレージでRAGする」という、これまで穴だった領域を確かに埋めてくれる一台です。

参照ソース

・LEANN（StarTrail-org 公式リポジトリ） — スター・フォーク・コントリビューター・リリースの実測、README全文、ストレージ比較表
・論文 LEANN: A Low-Storage Vector Index（arXiv 2506.08276・MLsys 2026） — 選択的再計算・高次数保持プルーニングの技術的裏付け
・README ストレージベンチマーク — 本記事の「91〜97%」の一次データ
・leann-mcp セットアップ（Claude Code連携） — MCPサーバー登録手順
・Berkeley Sky Computing Lab — 開発母体