VWork バイブコーディングフレームワーク

数万件の技術資料PDFと過去の見積・報告書を「聞けば答える」ナレッジにした——買い切りのAIチャットボット×全文検索OSS「Namazu」×AI の組み合わせで成功した開発実績

2026年9月4日

名古屋でAIシステム開発の会社をやっています。今回は、自社の買い切り製品と、枯れたオープンソースと、AIの3つを組み合わせて短期間で実用になった開発実績を1つ書きます。全部を自作もせず、全部をSaaSに預けもしない。この「組み合わせ方」そのものが成果だと思っているので、構成の考え方を中心にまとめます。

何を作ったか

対象は、科学系の技術専門雑誌の数年分・数万ファイルのPDFです。これまでは「あの号のあの記事に書いてあったはず」を人が探していました。

作ったのは、次の2段構えです。

  1. Namazu が全文検索の役——数万PDFの本文を索引し、キーワードで該当箇所を返す
  2. AIチャットが回答の役——質問から検索語を組み立てて Namazu に問い合わせ、当たった技術情報だけを根拠に日本語で答える

利用者は検索語を考えなくてよく、「◯◯の条件で△△が起きる理由は?」と聞けば、該当記事の内容に基づいた答えと出典が返ります。「探す」が「聞く」に変わりました。

なぜベクトルDBではなくNamazuなのか

いま流行りの RAG はベクトルDBで意味検索をしますが、この案件では Namazu のほうが合っていました。理由は3つです。

つまり「検索は枯れた技術に任せ、AIは読んで答える役に限定する」構成です。AIの得意不得意をそのまま役割分担にしました。

成功の条件は「テキストのPDF」だった

正直に書くと、この構成が成功したのは対象が本文テキストのPDFだったからです。専門用語の本文が文字として入っていて、画像だけのページや手書きが無い。だから Namazu の索引に本文がそのまま入り、検索で当たったページをそのままAIに渡せました。

逆に言えば、スキャンしただけのPDFや手書きの図面が混ざる資料では、先にOCRの工程が要ります。「全文検索×AI」を検討するときは、まず資料がテキストとして読めるかを確かめるのが最初の分かれ道です。

営業部門向け——過去の見積と報告書もナレッジにした

技術資料だけでなく、営業部門向けには過去の見積と、成果物である報告書も Namazu で索引しました。

やりたかったのは、類似案件の引き合いが来たときに「前に似た案件をやっていないか」「そのときいくらで見積もったか」「成果物はどういう内容だったか」を、担当者の記憶に頼らず引き出すことです。引き合いの内容を入力すると、過去の類似案件を報告書の内容とともに提示し、当時の見積も含めて回答します

見積の根拠が過去の実績から出てくるので、担当者が変わっても提案の速さと精度が落ちません。技術資料の「探すを聞くに変える」と同じ仕組みが、営業のナレッジにもそのまま効きました。

土台にした製品——Kurage Light ChatBot

AIチャット部分は、当社が kappstore で販売している買い切りの Kurage Light ChatBot を土台にしています。PHP1ファイルで動き、知識を固定の順序で注入して価格や数値を正確に引用する設計、公開モードと合言葉モードの切替、ストリーミング表示、レート制限、質問ログといった「チャットボットに必ず要る部分」が最初から揃っています。

今回はその知識の取り込み口を「フォルダのMarkdown」から「Namazu の検索結果」に差し替えました。土台があるので、開発の中心は Namazu との接続と、質問から検索語を組み立てる部分、根拠の出典をつける部分に絞れました。製品を土台にすると、案件ごとに作るのは差分だけになります。

製品×OSS×AI、それぞれの役割

役割 担当 選んだ理由
会話の入口・ログ・制限・表示 自社製品(Kurage Light ChatBot) 買い切りで揃っている。案件ごとに作り直さない
数万PDFの索引と検索 OSS(Namazu) 専門用語に強く、説明でき、軽い。社内で閉じる
質問の理解と日本語での回答 AI(OpenAI互換API) 検索結果を読んで答える役に限定。根拠なしで書かせない

どれか1つで全部をやろうとすると、費用か精度か期間のどれかが破綻します。組み合わせると、それぞれの得意なところだけを使えます。

同じ構成が向いている会社

土台になる製品は kappstore で買い切りで提供しています。Namazu との接続や自社資料への合わせ込みは、名古屋市内なら AI導入お試し実験(初日3時間は無料) で、実際の資料を使って動くところまで試せます。