XERJ:AIエージェントのトークンを節約するローカル検索

Published · AI Daily — AI-assisted deep research, methodology & disclosure

XERJ は Rust で書かれた、Elasticsearch 互換のローカル AI 検索エンジンです。autoindex 機能により、コード、ドキュメント、ログ、PDF を 1 つのコマンドでインデックス化できます。coding agent は grep や sed でファイルを 1 つずつ読む代わりに、必要なピンポイントの断片を直接取得できます。プロジェクトは grep と比べてトークン使用量が 40 分の 1 になると説明しており、検索、RAG、セキュリティ監査、エージェントのメモリにも対応します。公式の統制研究では、参照コーディングシナリオでエージェントの出力トークンが 2.7 分の 1 に減り、解決率は 16/16 を維持しました。xerj init で Claude Code と Cursor に簡単に接続でき、エージェントのコストを下げつつ既存の Elasticsearch クライアントを使い続けたい開発者やチームに向いています。

背景と概要

コーディングエージェントには共通の癖があります。見知らぬプロジェクトに入ると、grep や sed、そしてファイルを次々に開く操作で全体像を探ります。ファイルを 1 つ読むたびにトークンを消費し、見当を外せばもう一巡が必要です。リポジトリが大きいほどコストは膨らみ、モデルも無関係なテキストの中で迷いやすくなります。XERJ はまさにこの問題を狙ったツールです。

XERJ は Rust で書かれたオープンソースのローカル AI 検索エンジンです。発想は単純で、エージェントにまずインデックスでデータを把握させ、必要な内容だけを正確に取り出させます。力任せの走査はしません。新しいベクトルデータベースではなく、従来の全文検索エンジンとエージェントのツールチェーンの間に置く層という位置づけです。Elasticsearch 互換のため、既存のクライアントを書き換えずに接続できます。MCP やスキルといったエージェント向けの接続方式も視野に入れています。

プロジェクトのタグには bm25-search があり、語頻度に基づく従来型のランキングが土台だと分かります。ドキュメントにはベクトル検索の専用ページもあり、意味検索を排除してはいません。主な用途としてプロジェクトが挙げるのが「参照コーディング」です。エージェントがタスクに最も近いオープンソースのリポジトリを探してインデックス化し、その解法を参考にしながらコードを書きます。

深掘り分析

中核となる機能は autoindex です。プロジェクトの説明では、1 つのコマンドでコード、ドキュメント、ログ、PDF をインデックス化できます。同じインデックスを検索、RAG、セキュリティ監査、エージェントのメモリに使えるため、用途ごとに別のシステムを組む必要がありません。検索結果は順位付けされた断片として file:line の位置つきで返ります。エージェントはファイル全体ではなく、そのまま引用できる出典を受け取ります。 定義ジャンプ用の def コマンドもあり、ファイルの行番号と関数シグネチャを返すのでコード探索に役立ちます。もう 1 つ注目したいのが xerj gain コマンドです。ツールが実際に何をしたかを報告し、推定ではなく実測のカウントだと強調しています。効率化ツールは概念の説明で終わりがちですが、確認できる統計があれば信頼しやすくなります。 XERJ は grep と比べてトークンをどれだけ節約できるのでしょうか。プロジェクトは grep より約 40 分の 1 のトークンで済むと説明しています。参照コーディングシナリオの統制研究では、エージェントの出力トークンが 2.7 分の 1 になり、解決率は 16/16 のままでした。日常的な利用者の声は約 5 分の 1 です。この 3 つの数字は測り方が異なるため、混ぜずに別々に読む必要があります。プロジェクトはさらに、節約幅が大きいので、小さく安価なモデルが、記憶頼みでコードを書く高価なモデルを上回れるとも述べています。

導入手順は短く、2 通りあります。1 つ目は、エージェントにプロンプトを渡し、llms.txt を読ませてインストール、インデックス化、参照コーディングの設定まで任せる方法です。2 つ目は手動で、curl のインストールスクリプトを実行し、xerj サービスを起動し、xerj init で Claude Code や Cursor に接続し、xerj autoindex でプロジェクトのディレクトリを指定します。その後は xerj search で、たとえばあるプロジェクトがログのセグメントをどうローテーションするかを尋ねられます。Windows 利用者や手動で確認したい人向けの説明は README にあります。 ドキュメントはコマンドライン、クエリ構文、エージェントのメモリ用レシピ、ベクトル検索、ベンチマーク、インストールを網羅し、モデル向けの llms.txt もあります。 注意が必要なのが --insecure オプションです。TLS と API キー認証を無効にし、ポートに到達できる呼び出し元は全員がスーパーユーザーになります。すべての /_memory 名前空間を含む全インデックスを読み取り、削除できてしまいます。プロジェクトはこのモードを 1 人用の開発マシン向けと位置づけています。新しいノードは既定で 127.0.0.1 のみにバインドし、他のネットワークインターフェースへ平文でバインドする場合は、明示的に許可しない限り起動を拒否します。セキュリティモデルは docs/SECURITY_MODEL.md に書かれており、使い始める前に読む価値があります。

業界への影響

XERJ は「読む量を減らし、正しいものを読む」ことを独立したインフラとして形にしました。エージェントのコストがチームの実際の請求書に載るようになった今、検索をモデルのコンテキストウィンドウから切り出し、数えられて再利用できるインデックス層に任せる考え方は現実的です。Elasticsearch 互換により移行の壁も低く、既存の運用経験やクライアントライブラリをそのまま使えます。

ライセンスは Apache-2.0 です。コミュニティの作り方は少し独特で、利用者に短い利用レポートの提出を求め、それを参加の証としています。人間とエージェントの両方を歓迎すると明言しています。実際のフィードバックが集まる利点がある一方、レポートの質や測定の基準がそろうかどうかは、今後を見守る必要があります。

エージェントのコストを下げつつ、既存の Elasticsearch クライアントを使い続けたい開発者やエンジニアリングチームに向いています。既定でローカルのみにバインドする設計なので、まずは 1 人用の開発マシンから試すのが安全です。

今後の展望

リスクははっきりしています。第 1 に、効果を示す数字はプロジェクト自身の研究と利用者の自己申告に由来します。研究のサンプルは 16 問と小さく、独立した検証はまだ待たれる段階です。自社のコードベースで同じ効果が出るかは、各チームが測る必要があります。xerj gain はそのための計測手段になります。

第 2 に、インデックスにはコード、ログ、エージェントのメモリが集まります。セキュリティ設定を誤れば、露出する範囲は大きくなります。第 3 に、エージェントが外部のオープンソースリポジトリを自動でダウンロードしてインデックス化する運用は、ライセンスや出所の信頼性という問題を生みます。

今後の注目点は 3 つあります。ベンチマークがどこまで公開されるか、ベクトル検索がどこまで成熟するか、そしてより大規模で複数人が使う環境での認証と権限の設計です。これらの答えが、XERJ が個人開発者の便利な道具にとどまるのか、チームの共有インフラに育つのかを左右します。

Sources

FAQ

XERJ とは何ですか?

XERJ は Rust で書かれた、Elasticsearch 互換のオープンソースのローカル AI 検索エンジンです。autoindex 機能により、コード、ドキュメント、ログ、PDF を 1 つのコマンドでインデックス化できます。coding agent は grep や sed でファイルを順に読む代わりに、必要な断片を直接取得できます。

XERJ はなぜ AI コーディングエージェントにとって重要ですか?

XERJ は検索をモデルのコンテキストから、数えられて再利用できるローカルのインデックス層へ移します。プロジェクトは grep より 40 分の 1 のトークンで済むと説明しています。統制研究では出力トークンが 2.7 分の 1 になり、解決率は 16/16 でした。これらは公式の数値で、独立した検証は未了です。

XERJ を導入する前に何を確認すべきですか?

XERJ を導入する前に、xerj gain の実測カウントで自分のコードベースでの節約効果を確認してください。--insecure は TLS と API キー認証を無効にするため、1 人用の開発機に限定します。docs/SECURITY_MODEL.md を読み、外部リポジトリのライセンスにも注意が必要です。