AI / 検索基盤

FFFとは何か

作成日: 2026年6月14日

要点

FFF は、ファイル名検索と内容検索を、長生きするプロセスの中で何度も速く回すための Rust ベースの検索基盤です。
価値は検索アルゴリズムだけでなく、毎回の process 起動、`.gitignore` 解析、file tree 走査を再利用できる点にあります。
MCP server として使うと、AI エージェントが shell の `grep` や `find` を何度も叩く代わりに、`find_files`、`grep`、`multi_grep` のような専用ツールを使えるようになります。

何をするツールか

FFF の README では、human と AI agents 向けの file search toolkit と説明されています。Neovim plugin として始まったものが、今は Rust の検索コア、background watcher、frecency、MCP server を持つ検索基盤になっています。

リポジトリを一度 warm な状態にして、その後の検索を tool として再利用する流れです。

何がうれしいか

反復検索が軽い

毎回 shell command を起動し直さない前提で設計されています。

順位付けがある

frecency と git-aware annotation で、よく触るファイルを上げやすいです。

AIに渡しやすい

検索結果が構造化されて返るので、エージェント側での再パースが減ります。

`grep` や `rg` とどう違うか

単発の shell 検索なら、今でも `rg` は十分に強いです。ただ、AI エージェントは同じ repo に対して file search と content search を何度も繰り返すので、前処理の再利用が効いてきます。

違いの中心は検索文字列そのものではなく、前処理を使い回す設計かどうかです。

MCP server としての使い方

find_files: ファイル名、パス探索
grep: 内容検索
multi_grep: 複数パターンの OR 検索

この環境でも、repo の AGENTS 指示で「file/path discovery は `find_files`、内容検索は `grep`」という使い分けが前提になっています。つまり、FFF は見た目以上に AI エージェントの探索導線に入り込みやすいです。

内部の考え方

FFF repo の AGENTS では、性能クリティカルな処理は Rust 側、Neovim 固有の UI は Lua 側と分けています。主要な構成は、global file picker state、background watcher、frecency DB、query history DB です。

一度作った状態を維持しながら、順位付けと差分更新を続ける構成です。

CodeGraph と Graphify との違い

FFF: まず探すための道具。識別子、ファイル、文字列を速く当てる
CodeGraph: コード構造を理解する道具。caller、callee、impact を追う
Graphify: コードや文書をまたいだ知識全体を俯瞰する道具

実務では競合というより分業です。FFF で当たりを引き、CodeGraph で構造を追い、Graphify で全体像を見る、という並びが自然です。

使い始める流れ

MCP server をインストールする
Codex や Claude Code に `fff` を登録する
必要なら frecency DB と history DB を付ける
repo の AGENTS で `find_files` と `grep` を優先利用するよう明示する
healthcheck で base path や git repo 認識を確認する

導入の肝は、入れること自体よりも、エージェントに優先利用させるところまで含めることです。

まとめ

FFF は、単発の検索 CLI を置き換えるというより、AI エージェントの反復探索を軽くするための検索基盤です。特に MCP server として入れると、file search と grep を常駐状態つきの tool として扱えるので、セッション全体の探索コストを下げやすくなります。