RTFM：coding agent のためのローカル多領域検索レイヤー
AI coding agent はローカルリポジトリを読むのがかなり上手くなった。ただ、別の種類の問題にはまだ弱い。プロジェクトの重要な context は、いつも source code にあるわけではない。Architecture decision は Markdown にあり、要件や規制根拠は PDF や XML にあり、研究メモは Obsidian にあり、前回の session で整理した判断は memory file に散っている。モデルがコードだけを何度も grep しても、本当に必要な段落を見落とすことがある。
今日取り上げる roomi-fields/rtfm は、この隙間を埋めようとしている。RTFM は “Retrieve The Forgotten Memory” の略で、AI agent 向けの open retrieval layer という位置づけだ。プロジェクト内の code、docs、PDF、legal/regulatory text、research material、data、memory file をローカル SQLite に索引し、CLI と MCP server から検索、展開、履歴確認を提供する。agent は巨大な directory dump ではなく、小さく、追跡可能で、必要に応じて展開できる context を先に受け取れる。
GitHub repository page、README、Releases、Tags、LICENSE、pyproject.toml、公開 git history、changelog を 2026-07-25 時点で確認すると、roomi-fields/rtfm は 20 stars、5 forks。GitHub page と project metadata で確認できる主要言語は Python、ライセンスは MIT。GitHub page の埋め込みデータで確認できる repository 作成時刻は 2026-02-20 21:37:42 UTC。公開 git history の最初の commit は 2025-12-31 15:03:14 UTC の Initial commit: biblirag v0.1.0。現在の default branch の最新 commit は af82038、時刻は 2026-07-25 09:00:45 UTC、message は Merge feat/single-supervisor: mutualised worker (0.25.0)。GitHub Releases と Tags の先頭 version は v0.25.0 で、release 時刻は 2026-07-25 09:01:49 UTC。pyproject.toml では PyPI package name が rtfm-ai、version は 0.25.0、Python 要件は 3.10+ と示されている。
プロジェクト概要
| 項目 | 内容 |
|---|---|
| リポジトリ | roomi-fields/rtfm |
| 位置づけ | AI agent 向けのローカル多領域検索レイヤー |
| Stars | 20 |
| Forks | 5 |
| 主要言語 | Python |
| ライセンス | MIT |
| GitHub 作成時刻 | 2026-02-20 21:37:42 UTC |
| 最初の公開コミット | 2025-12-31 15:03:14 UTC、Initial commit: biblirag v0.1.0 |
| 現在の main コミット | af82038、2026-07-25 09:00:45 UTC |
| 最新 release | v0.25.0、2026-07-25 09:01:49 UTC |
| PyPI package | rtfm-ai 0.25.0 |
| Python 要件 | 3.10+ |
| キーワード | MCP、local-first、SQLite、FTS5、semantic search、knowledge graph |
コードだけを索引する道具ではない
RTFM の面白いところは、agent が context を見つけられない問題を、code search だけの話として扱っていない点だ。README では、プロジェクトは code だけではなく、spec、PR、architecture decision、research paper、PDF、regulation、vault note も含む、と繰り返し説明している。これらは実装判断を左右するが、普通の code indexer からは見えにくい。
RTFM は project material を検索可能な chunk に分け、ローカルの .rtfm/library.db に維持する。default では full-text search を使い、必要なら embeddings を入れて semantic/hybrid search も使える。agent は最初に少量の metadata を見て、その後 rtfm_expand のような tool で本当に関係する section を広げる。この progressive disclosure は agent workflow と相性がよい。まず 300 tokens 程度で方向を決め、それから正確な範囲を読む。ファイル全文をいきなり context に流し込むより扱いやすい。
README にある format coverage も広い。code と Markdown は基本として、PDF、LaTeX、EPUB、DOCX、ODT、RTF、XLSX、MOBI、XML/regulatory text なども optional dependencies や parser system で扱える。小さな Web app だけなら重く感じるかもしれないが、LegalTech、FinTech、HealthTech、research-heavy project、ドキュメントの多い enterprise repo ではここが痛点になる。
接続は local と MCP 寄り
RTFM には主に二つの入口がある。もっとも簡単なのは Claude Code plugin だ。
/plugin marketplace add roomi-fields/claude-plugins
/plugin install rtfm@roomi-fieldsREADME によると、plugin は project 初回利用時に .rtfm/library.db を作り、検索 instruction を注入し、MCP tools の permission を事前に許可し、最初の prompt で project を索引して、その後は incremental update する。Claude Code plugin を使わない tool では、手動でも入れられる。
pip install rtfm-ai
cd /path/to/your-project
rtfm initその後 MCP client を rtfm-serve に向ける。つまり RTFM は単なる CLI searcher ではなく、agent が直接呼び出せる local context service でもある。no cloud、no API costs を強調し、index file も手元の machine に置く。この点は、資料を外部 retrieval service に出せない team では重要だ。
向いている場面
一つ目は、document と code が強く結びついている project だ。税務、医療、金融、compliance system では、根拠が regulatory PDF、XML article、internal decision doc、code implementation に分散している。agent が source code だけを見ると、根拠に合わない実装を作りがちだ。RTFM の価値は、agent が先に該当する regulation や design note を見つけ、それから code に戻れることにある。
二つ目は、長期的な project memory だ。RTFM には memory mode があり、Claude Code の memory files を project 横断で ~/.rtfm/memory.db に索引し、version history も残せる。複数 project、複数 session で agent を使う人には、長くなり続ける note file より扱いやすい。たとえば “OAuth はなぜこの設計にしたのか” を検索して、過去 session で整理した結論に戻れる。
三つ目は、personal knowledge base と NotebookLM result の再利用だ。README には Obsidian vault mode があり、notebooklm-mcp との組み合わせも説明されている。citation-backed Q&A を Markdown と JSON sidecar として保存し、RTFM が local に索引すれば、後で offline に検索できる。この角度は少し niche だが、agent、PKM、project material を一つの local retrieval layer に載せたい人には刺さる。
v0.25.0 が示すもの
今日の最新 release v0.25.0 は、単なる document update ではない。changelog では、これまでの per-project daemon fleet を shared supervisor に置き換えたと説明されている。単一 process が登録済み project を bounded thread pool で処理し、同じ project に対して同時に二つの job を走らせない。release notes は旧 model の問題として DB corruption、load spikes、複数 process がそれぞれ embedding model を読み込むことを挙げている。
これは、作者が local indexing の実運用上の問題にぶつかっているサインでもある。SQLite と background indexing を扱う tool では、worker model、single-writer constraint、DB quick_check、corrupt DB quarantine、log rotation がかなり重要になる。RTFM はまだ早期だが、README demo だけで止まっている project ではなさそうだ。
注意点
第一に、project はまだ alpha だ。pyproject.toml の classifier は Development Status :: 3 - Alpha で、star 数もかなり少ない。試す価値はあるが、検証なしで production-critical workflow に入れる段階ではない。
第二に、複雑な format は optional install になる。core plugin は dependency-free に寄せているが、PDF、embeddings、Office、EPUB などを使うと追加依存とサイズが増える。README では pdf-full が CPU-only torch を含み、約 1.5 GB になる可能性も示している。導入前に、本当に必要な parser を絞ったほうがよい。
第三に、local parser は project 側の code を実行する。.rtfm/parsers/*.py のような project-local parser は柔軟だが、trust boundary は “その repository の code を実行する” に近い。不信な repository でそのまま有効にするのは慎重にしたい。
第四に、小さな project では過剰かもしれない。README の benchmark でも、1000 files 未満の code repo では普通の grep で十分なことが多いと認めている。RTFM が向くのは、context が分散し、document が重く、regulatory/research material が多く、session memory を長期再利用したい project だ。
まとめ
roomi-fields/rtfm が面白いのは、agent の問題を単にモデルの賢さ不足として扱っていないところだ。多くの場合、agent は推論できないのではなく、正しい段落、正しい document、正しい過去の判断を先に見つけられていない。
あなたの project が code だけなら、rg、IDE search、普通の code indexer で十分かもしれない。ただ、agent が source、spec、PDF、regulatory text、research material、Obsidian、NotebookLM result、session memory を行き来しながら根拠を探す必要があるなら、RTFM は watch list に入れてよい。まだ若い project だが、方向は明確だ。忘れられた project context を、agent の作業経路に戻すための道具である。