Analyzegear
約4.8万語の用語辞典を運営していますが、サイト内検索は用語名の一致でしか引けませんでした。3か月分の検索ログを調べると、半数以上が0件。「じゅりょく」のような打ち間違い、「地球の直径は」という文章での問いかけ、「円高と円安の違い」のような2語の比較——記事は存在するのに辿り着けていない質問がそのまま0件になっていました。
これを、掲載済みの用語データだけを根拠に出典リンク付きで答えるAI検索（RAG）で解こうとした記録です。ベクトルDBは新規契約せず、既存の共用ホスティング（MariaDB）の上に載せました。決済者向けの要約版は 実績ページの事例（用語メディアのAI検索） にあります。この記事は、設計・計測・ハマりどころをエンジニア向けに掘り下げます。
先に結論を書くと、実ログから作った37問（答えが掲載されているもの）での到達率は、従来の用語名検索 73.0%（27/37）→ AI検索 100%（37/37）。ただし速度は平均11.4秒、費用は1問5.85円で、従来の検索を置き換えるものではありません。以下、なぜこの数字になったか、どこで測り方を間違えかけたかを順に書きます。
精度より先に「答えない」を作る
RAGで最初に作り込んだのは、検索精度ではなく「根拠が無ければ黙る」仕組みのほうです。生成AIの一番の弱点は、それらしい嘘を自信満々で書くこと。用語辞典が推測で数値を捏造したら、辞典としての信頼が終わります。
- スコアの足切り閾値を先に決め、候補が弱ければコンテキストに渡さない
- プロンプトで「渡した出典に無いことは書かない。無ければ『情報がありません』と述べる」を強制
- 構造化出力で
answer/used_sources/confidenceを受け取り、どの出典を使ったかを必ず記録
この土台を先に作ったので、精度を追う段階では「間違えるか」ではなく「黙るべきときに黙れるか」を安心して詰められました。実測でも、答えが存在しない5問すべてで「toha.jp には情報がありません」と明言し、事実の捏造は0件でした。
ベクトルDB無しで4.8万件を捌く
本番は Xserver の共用ホスティング、DBは MariaDB 10.5 でベクトル型が使えません。ベクトルDBを新規契約すればインフラ費用も運用対象も増えます。そこで、埋め込みを通常カラムに載せる方向で設計しました。
- 埋め込みは OpenAI
text-embedding-3-smallの 512次元 - float32 のままだと 1件2KB。int8量子化して1件512バイトで BLOB 保存（全4.8万件で約38MB）
- 全件の総当りは避け、カテゴリ重心1,364本で候補を粗く絞ってから再ランク。実際にコサイン比較するのは最大200件に抑える
4.8万件・約38MBなら、粗選 → 再ランクの2段でPHPからでも実用的な時間に収まります。ベクトルDBが要るのは規模の問題であって、RAGの前提条件ではない——この規模帯なら既存サーバで成立する、というのが持ち帰りです。インデックス構築は 48,382件・28.4Mトークンで 88円・約40分。ローカルで作って本番へダンプ投入しました。常駐プロセスもありません。
検索は「捨てない」ハイブリッド
埋め込み検索だけにすると、実は打ち間違いに弱い。「じゅりょく」のような表記のブレは、意味ベクトルより文字列側の処理のほうが強い。そこで既存の曖昧検索（カナ揺れ・編集距離補正）を捨てず、併用しました。パイプラインはこうです。
- 質問解析：
claude-haiku-4-5で意図・言い換え・カテゴリを推定。用語質問でなければここで打ち切り（0.10円） - 検索A：名前一致（カナ揺れ・編集距離） ── 既存資産
- 検索B：カテゴリ重心で粗選 → 近傍展開 → 埋め込みで再ランク
- 整形：上位8件＋出典メタを、掲載データのみを根拠にコンテキスト構築
- 回答生成：
claude-opus-5（effort=high）で出典番号付きに生成
安価な haiku を入口に置き、用語質問でないものを早期に落とすことで、高価な opus の呼び出しを本当に必要なときだけに絞っています。
同じデータで、なぜ結果が変わるのか
面白いのは、従来検索とAI検索が同じ用語データを見ている点です。差が出るのは質問の型ごとで、特に効くのは複数ページをまたぐ問いでした。「地球の直径は」に対し、toha.jp には「地球の直径」という項目が無い。あるのは別々の2ページです。
地球… 赤道半径は約6,378km直径… 直径 ＝ 半径 × 2
AI検索は「直径そのものの記載はありません」と断ったうえで、両方に出典を付けて約12,756kmを計算して示しました。従来検索では利用者が2ページを読んで自分で掛け算する必要があった箇所です。ほかにも、掲載名が「円安と円高の違い」（語順が逆）でも同じページに辿り着く、0件のときも近い用語を出典付きで案内する、といった帯でAI検索が効きました。逆に用語名が分かっている質問は、従来検索のほうが即時・0円で速くて安い。置き換えではなく併用が現実解です。
計測 ── 母数を揃えないと数字が嘘になる
ここが一番のハマりどころでした。設問は実際の検索ログから作りましたが、Before と After で母数が食い違う罠があります。toha.jp は未登録語を検索するとその用語が後から作られる流れがあり、当時のコーパス（Before）と今日のコーパス（After）では、そもそも答えの存在する集合が違うのです。
初期に「47.6% → 97.6%」という数字が出ましたが、これは母数が揃っていない値なので使いません。同じ今日のコーパスに対し、答えが掲載されている37問だけで測り直したのが下です。
| 答えに到達 | |
|---|---|
| 従来の用語名検索 | 73.0%（27/37） |
| AI検索 | 100%（37/37） |
母数の問題が無い、最も強い言い方をすると——現在も用語名では引けない10問すべてに、出典付きで回答できました。数値の裏取りは全50問を出典本文と機械照合し、49問で一致（残る1件も出典の値からの計算と明示されたもの）。比較質問10問は文単位で人手確認しました。実ログから設問を作る／数値は機械照合／文脈だけ人が見るの3段構えです。
速度と費用 ── 正直な弱点
到達率は良いですが、応答は平均11.4秒（p50）。公開デモとしては遅く、改善余地があります。費用は1問5.85円で、同一質問は24時間キャッシュ（0円）、月次上限3,000円で回答APIを自動停止、IP別レート制限も入れています。コストガードは精度と同じくらい先に作るべきで、全APIコールのトークンを記録し、上限で止まる設計を最初から入れておくと安心して公開判断ができます。
MCP対応 ── エージェント向けは「答えさせない」
Webの画面だけでなく、AIエージェント（Claude Desktop / Claude Code 等）から直接呼べる MCP にも対応させました。ここで分かったのは、エージェント向けには回答文を生成しないほうが良いということです。呼び出してくるのもAIなので、こちらでも回答を作るとAIが二重になり、遅く・高くなります。そこでエージェント向けは「検索して出典を返すだけ」を主役にし、判断は呼び出し側のAIに委ねました。
| 回答文まで生成 | 検索して出典を返すだけ | |
|---|---|---|
| 1回あたりAPI費用 | 5.85円 | 1件0.0001円未満 |
| 応答時間 | 平均11.4秒 | 0.6〜1.5秒 |
あとから入口を増やせたのは、安全装置を置いた場所が良かったからでした。月次・1日あたりの上限、ログ、出典の付け方は画面ではなく処理の中心にまとめてあり、MCPはそこを呼ぶだけ。Web用に作った制御が抜け落ちません。なお MCP の規格は動きが速く、2026年7月版で接続手順が大きく変わった（接続時のやり取りとセッションの廃止）ため、着手時に最新仕様へ合わせています。この窓口は社内検証のみで、外部提供の実績はありません。同じ仕組みは社内文書・商品DB・サポートFAQをAIツールから直接引く用途にも対応できます。
他の案件にも持っていける設計
- ベクトルDB無しのRAG。共用ホスティング・MariaDB でも、4.8万件規模なら int8量子化＋カテゴリ重心で成立する。
- 捏造させない仕組みを先に作る。足切り閾値＋
confidenceの記録＋「出典に無ければ言わない」プロンプト。精度はその上で追う。 - 既存の検索資産は捨てない。埋め込みは打ち間違いに弱く、従来の曖昧検索と併用して初めて実用になる。
- 母数を揃えて測る。Before/After でコーパスが動くなら、同一コーパスで測り直す。都合の良い数字を使わない。
数値の母数と、書いていないこと
誇大にならないよう、母数と条件を添えます。73.0% → 100% は「実ログ由来で答えが掲載されている37問」、捏造0件は「答えが存在しない5問」、数値一致49問は「全50問の機械照合のうち」、5.85円・11.4秒は実測値、MCPの0.6〜1.5秒は6クエリの実測（母数が小さい）です。埋め込み単価には一部仮定値を含みます。
そして、測っていないので書けないこと。「人が答えに辿り着くまでの秒数短縮」は書けません（到達率は測りましたが、秒数は測っていません）。一般公開していないため利用者満足度の評価はなく、売上・CTR・検索順位への影響も因果を測っていません。MCPは社内の1端末で検証しただけで、外部利用はゼロ。検索のみ構成の回答品質は比較しておらず、測ったのは費用と時間だけです。デモ（ai.toha.jp）は現在 Basic 認証下の非公開です。
まとめ
「記事はあるのに引けない」は、検索の枠組みそのものの穴でした。同じデータでも、意味で引ける入口を足すと到達率は 73.0%→100%（37問）まで動きます。ただし遅く・有料なので、従来検索の置き換えではなく併用が現実解。そして、精度より先に「答えない設計」とコストガードを、母数より先に「測り方」を固めておくこと——RAGを業務に載せるときに効いた順番は、だいたいこの逆でした。
事例の要約（非エンジニア・決済者向け）は 実績ページ に、AI活用の他の事例は AI活用ページ にまとめています。社内文書・商品DB・サポートFAQへの同様の導入のご相談は お問い合わせ から。
