Rust Glancerとは — RAM使用量をrust-analyzerの1/100に抑える実験的LSP

Rust Glancerは、2026年8月19日に開発者@popzxcが公開した実験的なRust用LSP（Language Server Protocol）実装です。開発元は「低メモリ使用量とほぼ瞬時のエディタ再起動に最適化した実験的LSP実装」と位置づけており、標準的な選択肢であるrust-analyzerの完全な置き換えは狙わず、日常利用の約90%をカバーすることを目標に掲げています。最大の主張はRAM使用量がrust-analyzerの1/100（2桁少ない）で済むという点で、非力なマシンで作業する開発者やRAM削減のために一定の機能的な妥協を受け入れられる開発者に向いています。

Rust Glancerは、日常的なコーディングで使う中核的なLSP機能をひととおりサポートしています。

- 定義ジャンプ（goto definition）
- ホバー表示
- インレイヒント
- コード補完
- 型推論
- トレイト解決
- 基本的なマクロ展開

一方で、メモリ効率と再起動速度を優先するために、意図的に対応範囲から外している機能があります。

- ビルドスクリプト（build.rs）の実行
- 手続きマクロ（proc macro）の実行による展開
- nightly Rustの高度なサポート（先送り）
- 新トレイトソルバへの移行（先送り）

公式ブログでは、2種類のマシンでRust Glancerとrust-analyzerのインデックス速度を比較した実測値が公開されています。

メモリ面では、現実的な規模のプロジェクトで100MB未満に収めることを目標に掲げており、公式デモを通してこの水準を維持しています。RAM使用量がrust-analyzerの1/100という主張の核はここにあります。

利用方法は大きく2通りあります。1つはVS Code拡張機能としてマーケットプレイスからインストールする方法、もう1つはGitHubリポジトリからソースをビルドする方法です。詳細な手順は公式ドキュメントに掲載されています。

rust-analyzerは、rowanによる構文木をメモリ上にすべて保持し、編集の都度その差分を計算する方式を取っています。これにより高精度なリアルタイム解析が可能になる一方、プロジェクトが大きくなるほどメモリを消費します。対してRust Glancerは「frozen workspace（凍結ワークスペース）」という方式を採用し、解析結果をファイルシステムに退避できるようにすることでメモリ常駐量を抑えています。具体的には、ファイルを保存するとインデックスを一度無効化してから再構築する仕組みになっており、タイピング中は現在編集しているbodyだけを浅く解析し、直前の完全なインデックスを再利用して補完やホバー情報を返します。メモリ効率化のためにアロケータにjemalloc、型検査にchalkを利用している点もこの設計思想と整合しています。エディタ側の再起動体験を最適化するアプローチという点では、以前紹介したZed Deltaのようなエディタ側の取り組みとも問題意識が近い部分があります。

この設計にはトレードオフが伴います。最も実務に影響するのは、ファイルを保存するまで新しいimport・構造体・トレイトがインデックスされない点です。タイピング中は直前の完全なインデックスを流用する仕組みのため、保存前の変更はエディタ上の補完やジャンプに反映されません。また、ビルドスクリプト（build.rs）とproc macroの実行を行わないため、serdeのDeriveマクロのようにproc macroに大きく依存するクレートを多用するプロジェクトでは、マクロが生成するコードに対する補完・型推論・定義ジャンプの精度が限定的になります。基本的なマクロ展開には対応していますが、proc macroの実行結果までは再現しないため、フル機能のIDE的な体験を期待する場面では物足りなさを感じる可能性があります。

Rust Glancerとよく併せて検索されるのがrust-analyzerです。rust-analyzerはRust公式のLSP実装として広く使われており、完全性とキーストローク単位の正確さを重視する設計になっています。両者の違いを整理すると次のようになります。

IntelliJ Rust（RustRover）はLSPではなく独自の解析エンジンを持つ商用IDE寄りの選択肢で、Rust Glancerやrust-analyzerとは前提が異なります。比較表からわかるとおり、Rust Glancerが優れているのは主にメモリ使用量と再起動の軽さであり、正確さや網羅性、成熟度の面ではrust-analyzerに分があります。作者自身も、完全性とキーストローク単位の正確さを重視するプロジェクトでは引き続きrust-analyzerが既定の選択肢であり、Rust Glancerは非力なマシンの人やRAM削減のために妥協を受け入れられる人向けだと整理しています。

選択の目安はマシンスペックとプロジェクトの性質です。RAMに余裕のあるマシンで、proc macroやbuild.rsに依存する大規模プロジェクトを扱うなら、実績と網羅性に勝るrust-analyzerが引き続き無難な選択です。一方、RAMが限られたマシンで作業している、エディタの再起動やIDEのもたつきがストレスになっている、あるいは中核機能だけで日常の9割が事足りるという開発者にとっては、Rust Glancerを試す価値があります。なお開発者自身がコード生成に大きくLLMを活用したことを明言しており、コードの所有と品質維持は自分が担うとしています。2026年8月時点でGitHubスターは364前後とまだ小規模ですが、Hacker Newsのフロントページで417ポイントを獲得するなど話題性は高く、今後の機能拡張次第では選択肢の幅が広がりそうです。

Rust Glancerは、rust-analyzerの完全な代替ではなく、メモリ制約のある環境や再起動の軽さを重視する開発者向けに、日常利用の約90%をカバーすることを目標にした実験的なLSPです。frozen workspace方式により解析結果をファイルシステムに退避できる点がRAM使用量を1/100規模まで抑える鍵になっている一方、保存するまで新しい定義がインデックスされない点やproc macro・build.rsを実行しない点は、実務での使い勝手に直結するトレードオフです。公開されたばかりの実験的プロジェクトである点を踏まえつつ、自分の開発環境やプロジェクトの性質に照らして、rust-analyzerとどちらが合うかを見極めるとよいでしょう。オープンソースのツールチェーン刷新という点では、Mojoの完全OSS化のような動きとあわせて、開発者向けツールの選択肢が広がっている流れの一つとして捉えられます。