GitHubで公開から1週間ほどで1万スターを超えた「QMD（Query Markup Documents）」というプロジェクトが、技術者の間で話題になっている。Markdownドキュメントを対象に、BM25による全文検索、ベクトル検索、そしてLLMによる再ランキングを組み合わせた、いわば“ローカルで動く検索エンジン＋RAG用リトリーバ”のような構成を持つツールだ。
正直に言えば、これは万人向けのソフトではない。
常駐させて気軽に使うユーティリティというより、「検索を本気でやる人のための道具箱」に近い。構成も決して軽量ではなく、SQLite、埋め込みモデル、再ランカーまで含めた“フル装備”に近い。
それでもここまで注目を集めた理由は、QMDそのものの便利さというよりも、今のAI開発者たちがどこに困っているかを、非常に正直に映しているからだと思う。
多くの人がすでに気づいているように、RAG（検索拡張生成）の品質は、LLMの性能よりも「検索の前処理」と「チャンク設計」でほぼ決まる。
雑に分割したテキストをベクトルDBに突っ込んでも、答えはだいたい雑になる。結局のところ、
- どの単位で文書を切るのか
- どういう塊を「意味の単位」とみなすのか
- キーワード検索と意味検索をどう組み合わせるのか
このあたりの地味な設計が、RAGの出来を左右する。
QMDが面白いのは、対象をMarkdownに限定することで、ここをかなり真面目にやっている点だ。
見出し、段落、コードブロック、リストといったMarkdownの構造をスコア化し、「どこで切れば意味を壊さずに済むか」を基準にチャンクを作る。これは派手さはないが、検索品質に直結する、かなり工学的にまっとうなアプローチだ。
この“Markdown限定”という割り切りも、今の空気をよく表している。
実務でも、AI界隈でも、ドキュメントの中間表現としてMarkdownを使うケースは明らかに増えている。人間にも読めて、差分管理もしやすく、機械処理もしやすい。リッチなフォーマットをそのまま扱うより、一度Markdownに正規化したほうが運用が楽、という判断は、すでに珍しくない。
QMDのスター数が示しているのは、「みんながこれを今すぐ使いたい」というよりも、
「この問題設定は、まさに今みんなが詰まっている場所だよね」という共感に近い気がする。
実際、QMDはMCP経由でClaudeなどのLLMと連携できる文脈でも語られている。
社内ドキュメントやナレッジベースをそのまま食わせるのではなく、ちゃんと検索で絞り込み、意味のある塊だけを渡したい。そのための“前段の検索エンジン”が欲しい。そういう需要は、今かなり強い。
一方で、これは一般ユーザー向けのトレンドではない。
どちらかといえば、RAGを組んでいる人、検索品質に悩んでいる人、LLMとナレッジの接続で現実と格闘している人たちの世界の話だ。
だからこそ、QMDは「便利ツール」というより、今のAI開発のボトルネックがどこにあるかを可視化した存在として見るほうがしっくりくる。
LLMが賢くなるほど、「何をどう渡すか」が重要になる。
その手前にある検索と前処理の層は、これからますます地味に、しかし決定的に重要になる。
QMDの急速な注目は、その現実をかなり分かりやすく物語っている。
流行り物として消費するには、少し渋すぎる。
でも「技術の空気」を読む材料としては、かなり正確な風向計だと思う。
