スプレッドシートを簡易ベクトルDBにする｜FAQボットの精度を保つ三段構え設計【AI活用検証vol.94】

チャットボットのFAQを運用する現場では、しばしば矛盾した要件が出てきます。「回答精度は上げたい。ただしデータはスプレッドシートで管理したい」——専用のナレッジベース機能を使わずに、精度をどう担保するか。

この検証では、スプレッドシートを簡易ベクトルDBとして使う構成を設計しました。

この検証の概要

結論：キーワード一致では足りない

この設計の出発点は、明確な課題認識です。

ユーザーの質問がスプレッドシート上の既存データと完全一致しないケースをどう判定するか。単純なキーワード検索では限界があります。

FAQは「登録した言い回し」で質問されるとは限りません。同じことを聞いていても、言葉が違えばキーワード検索では引っかかりません。

そこで埋め込みモデルを使います。

埋め込みモデルはキーワード一致ではなく「意味の近さ」を数値で判定できるため、関連性の高い回答抽出に有効です。

三段構えの設計

① 埋め込みモデルでベクトル化
        ↓
② コサイン類似度で上位候補を抽出（例：5件）
        ↓
③ LLMで候補の適切性を判定
        ↓
   スコアが閾値（例：0.7）を超えた場合のみ回答を返す

この構成のポイントは「返さない」判断ができることです。

マッチングスコアが一定を超えた場合のみ回答を返す——閾値を設けることで、無関係な回答を返すことを防げます。

FAQボットで最も避けたいのは、見当違いの回答を自信満々に返すことです。「該当する回答が見つかりません」と言えるほうが、信頼を損ないません。

スプレッドシートを簡易ベクトルDBとして使う

この構成が成立する条件も整理しています。

スプレッドシートを簡易ベクトルDBとして使い、数百行規模ならGASで運用可能です。

専用のベクトルDBを立てると、インフラが1つ増えます。運用担当者が触れない場所にデータが移り、管理の手間も増えます。

データ量が限られているなら、既に運用されている場所の上に載せるほうが定着します。

データ量が増えた場合は、本格的なベクトルDBへ移行する余地も残しています。最初から大きく作らず、必要になったら移すという設計判断です。

更新はリアルタイムでなくてよい

運用設計上の重要な割り切りです。

スプレッドシートの差分を監視し、埋め込みモデルでベクトル化して保存する構成。データ更新はリアルタイム不要で、1日1回等の定期実行、または運用担当者の手動実行で対応します。

FAQの内容が変わるのは、頻繁ではありません。更新を即時反映する仕組みを作ると、その分だけ構成が複雑になり、API呼び出しも増えます。

「どのくらいの鮮度が必要か」を先に確認すると、設計が簡単になります。

二重課金という論点

この構成で残る課題です。

埋め込みモデルとLLMは異なる軸で運用され、それぞれにAPI利用料が発生します。

品質と管理容易性はトレードオフになります。この検証では、埋め込み＋類似度＋LLM判定の三段構えで両立を狙う方針をとりました。

ただし最終的なコスト配分・構成の最適解は継続検討としています。LLMのAPI利用に集約する選択肢も比較検討の対象です。

「精度が上がる構成」が必ずしも最適とは限りません。運用コストと管理の手間を含めて判断する必要があります。

入力の設計：カテゴリ選択を必須にする

精度を上げるもう1つの工夫です。

開始時のカテゴリ選択入力を必須化し、入力ミス防止とデータ整理を両立させます。

自由入力だけに頼ると、検索対象が全データになります。先にカテゴリで絞り込めば、候補が減り、精度が上がります。

ユーザーにとっても、選択肢から選ぶほうが「何を聞けばいいか」が分かりやすくなります。

チャネル間の導線設計

実装上の構成として整理された点です。

チャットアプリのリッチメニューから質問を受け付ける想定ですが、質問入力用の画面が別途必要という整理になりました。

対応として、Web公開URL機能を利用し、チャット画面からWebの回答画面へ誘導する仕様を採用しています。

すべてを1つのチャネル内で完結させようとすると、UIの制約に引っかかります。入力が複雑になる部分だけWebに逃がす、という割り切りが現実的です。

開発工程を3つに分ける

進め方も整理されています。

1. スプレッドシートの項目定義 — 不要な列を削除し、運用に必要な項目のみでシート構造を決定
2. 埋め込みモデル呼び出しのGAS構築 — 決定したシート構成に基づくスクリプト
3. 全体統合

順番が重要です。シート構造を先に確定させてから、それを扱うコードを書きます。逆にすると、構造が変わるたびにコードを直すことになります。

よくある質問

なぜ専用のナレッジベース機能を使わないのですか？

運用側がスプレッドシートで完結させたいという要件があるためです。データを触る人が普段使っているツールから離れると、更新されなくなるリスクがあります。

スプレッドシートでベクトル検索ができるのですか？

数百行規模ならGASで運用可能です。埋め込みベクトルをシートに保存し、コサイン類似度で候補を抽出します。データが増えた場合は本格的なベクトルDBへの移行余地を残しています。

無関係な回答が返るのを防げますか？

スコア閾値（例：0.7）を設けることで制御できます。閾値を超えた場合のみ回答を返し、超えなければ「該当なし」とする設計です。

コストが心配です

埋め込みモデルとLLMで別々にAPI利用料が発生する点が論点です。データ更新をリアルタイムにせず定期実行にすること、カテゴリ選択で検索範囲を絞ることが、呼び出し回数の抑制につながります。

まとめ

• FAQ検索ではキーワード一致に限界がある。埋め込みモデルで「意味の近さ」を判定する
• 構成はベクトル化 → コサイン類似度で候補抽出 → LLMで最終判定の三段構え
• スコア閾値を設けて「返さない」判断ができるようにする
• 数百行規模ならスプレッドシートを簡易ベクトルDBとして運用できる。既存の運用場所から動かさないほうが定着する
• 更新はリアルタイム不要。定期実行や手動実行で足りるかを先に確認する
• 品質と管理容易性はトレードオフ。精度が高い構成が最適とは限らない
• カテゴリ選択を必須化すると、検索範囲が絞られて精度が上がる

チャットボットの精度は、モデルの性能だけでは決まりません。どう絞り込み、どこで返さない判断をするかの設計が結果を左右します。

株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のチャットボット・RAG導入を支援しています。ご相談はお問い合わせフォームから、継続的な伴走支援についてはAI参謀をご覧ください。