SeaGOAT レビュー: ChromaDB と ripgrep を同居させたローカル完結型コード検索

grep では届かない「意味」をローカルで拾う

SeaGOAT が埋めようとしているのは、識別子を知らないと検索できないという grep 系ツールの穴である。README の例では gt "Where are the numbers rounded" という自然文クエリを投げている。丸め処理を行っている関数名を覚えていなくても、その意図に近いコードを探せるという主張だ。対象読者は、見知らぬリポジトリに参加した開発者や、数か月前に自分が書いたコードの在り処を思い出せない開発者になる。全文検索の代替ではなく、語彙が一致しない検索の補助という位置づけである。README は「SeaGOAT is not a code generator but a code search engine」と明言しており、コード生成や補完を期待するツールではない。

検索は 2 系統、サーバは 1 つ

仕組みは README の FAQ で説明されている範囲では、ChromaDB によるベクトル検索と ripgrep による正規表現検索の併用である。埋め込みの計算には ChromaDB の既定モデルを使い、テレメトリは既定で無効とされている。FAQ は「SeaGOAT does not rely on 3rd party APIs or any remote APIs」と述べており、処理はすべて手元のマシンで完結する。ここで重要なのは、この 2 系統が同じ CLI から出てくる点だ。正規表現やキーワードに一致する結果はファイルの処理状況に関係なく最初から表示され、ベクトル側の結果はインデックスが進むにつれて精度が上がる。つまり検索経路は 1 本ではなく、確実に効く経路と育っていく経路の重ね合わせになっている。ただし将来、任意機能として外部送信があり得ると README 自身が留保している点は記憶しておいてよい。

サーバを常駐させるという設計判断

SeaGOAT はコマンドを打つたびに完結するツールではない。seagoat-server start /path/to/your/repo でリポジトリごとにサーバを起動し、別のシェルから gt や seagoat で問い合わせる。FAQ はこの理由を「SeaGOAT heavily relies on vector embeddings and vector databases, which at the moment cannot be replace with an architecture that processes files on the fly」と説明している。ファイルを都度処理する構成では応答速度を確保できないという判断だ。副作用として、サーバの停止を忘れるとプロセスが残る。終了は seagoat-server stop /path/to/your/repo で行う。ポートは .seagoat.yml の server.port で指定でき、README の例では 31134 が使われている。同じマシンで複数リポジトリを扱うなら、ポートの衝突を自分で管理する必要がある。

導入は pipx と 2 つの外部依存から

前提は Python 3.11 以降と ripgrep である。bat は任意だが強く推奨されており、色が有効なときの表示に使われる。bat が無い場合でも pygments でハイライトされるが、README は bat の使用を勧めている。パイプラインの一部として使うときは grep 行形式の出力に切り替わるため、スクリプトに組み込む際は表示が変わることを前提にしておく。インストールは pipx install seagoat の一発である。設定はグローバルまたはプロジェクト固有の .seagoat.yml に YAML で書き、README が示す例は server.port の指定のみだ。設定キーの全量は README には載っておらず、詳細は公式ドキュメントの configuration ページに委ねられている。ここは記事の範囲では確認できない部分なので、実際に使うならそのページを直接読む必要がある。

対応拡張子はハードコードされている

README は「Currently SeaGOAT is hard coded to only process files in the following formats」と明記し、.txt、.md、.py、.c と .h、.cpp 系、.ts と .tsx、.js と .jsx、.html、.go、.java、.php、.rb を列挙している。これは設定で広げられる種類の制約ではなく、コード側に固定された一覧である。Rust、Kotlin、Swift、シェルスクリプト、Terraform の HCL などはこの一覧に無い。つまり対象リポジトリの主要言語がここに含まれていない場合、SeaGOAT は黙ってそれらを無視する。多言語リポジトリで一部の言語だけが検索対象になる状況は、結果の網羅性を誤解させる。導入検討の最初の作業は、自分のリポジトリの拡張子構成を確認することだ。加えてテキストファイルのみが対象で、バイナリは無視される。文字编码は UTF-8 が推奨で、他の多くのエンコーディングも動く見込みとされているが、断定はされていない。

遅いのは意図であり、欠陥ではない

大きなリポジトリでファイル処理が遅く、CPU もほとんど使わないという挙動について、README は「intentional design choice to avoid blocking/slowing down your computer」と説明している。バックグラウンドで控えめに処理を進め、作業中のマシンを占有しないことを優先している。処理中でもクエリは投げられ、未処理のファイルがある場合は結果の精度の推定値つきで警告が出る。正規表現ベースの結果は最初から出る。ここで注意したいのは、この警告を無視してベクトル検索の結果だけを読むと、インデックス未完了のリポジトリに対して「見つからない」という誤った結論を出しかねないことだ。設計上、検索結果の信頼性はインデックスの進行度に依存する。この点はツールの欠陥ではなく使い方の問題だが、チームで共有するなら周知が必要になる。

ripgrep 単体と比べて何が変わるか

比較対象として素直なのは ripgrep である。SeaGOAT 自身が内部で ripgrep を使っており、正規表現検索の部分は ripgrep の能力に依存している。違いは、ripgrep がパターンに一致する行だけを返すのに対し、SeaGOAT は埋め込みによる類似度でも候補を出す点にある。関数名や変数名を覚えていない検索では後者が効く。逆に、正確な文字列や正規表現で漏れなく列挙したい場合、ripgrep 単体のほうが速く、常駐プロセスも要らず、対応拡張子の制限も受けない。SeaGOAT を採用する意味が出るのは、語彙が曖昧な検索を日常的に行う場面に限られる。CI やワンショットのスクリプトのようにプロセスを残せない環境では、サーバ前提の設計そのものが適合しない。

ライセンスと保守の見通し

ライセンスは MIT で、リポジトリはアーカイブされていない。直近のリリースは v0.54.17 が 2025 年 5 月、リポジトリへの最終 push は 2026 年 9 月と記録されている。バージョン番号が 0.x 台で、パッチ番号が細かく上がる運用が見て取れる。0.x 系である以上、設定ファイルのキーや CLI の挙動がマイナー更新で変わる可能性は残る。MIT なので社内ツールへの組み込みや改変の制約は小さいが、同梱される ChromaDB とその既定埋め込みモデルは別コンポーネントであり、ライセンスも更新頻度も SeaGOAT 本体とは独立している。依存の追従コストは本体より下流で発生すると考えておいたほうがよい。README は FAQ の内容について「not a legal contract」と断っており、プライバシーや安全性の判断はソースを読むか issue を立てるよう促している。

編集部の結論

採用すべきなのは、Linux 上で Python 3.11 以降と ripgrep を用意でき、リポジトリを外部に送らずに「どこで数値を丸めているか」のような自然文でコードを探したい開発者である。Windows は README 上で help needed、macOS も partly tested と明記されているため、この 2 環境を主力にするチームは動くと決める前に自分のリポジトリで seagoat-server start を試すべきだ。逆に、拡張子が .py や .ts などに限定された資産を扱う場合や、CI のように常駐プロセスを置けない場面では ripgrep 単体のほうが確実である。導入前に確認するのは 3 点、対象リポジトリの拡張子が対応表に入っているか、初回インデックス中に gt を打ったときの精度警告が許容できるか、そして ChromaDB の既定埋め込みモデルを自チームのポリシーで許容できるかである。

公式情報源

1. kantord/SeaGOAT on GitHub
2. License: MIT
3. Project website
4. README
5. Releases