--- title: "スプレッドシートを簡易ベクトルDBにする｜FAQボットの精度を保つ三段構え設計" excerpt: "専用のナレッジベース機能を使わず、スプレッドシートでのデータ管理のみで回答精度を担保する構成を設計しました。埋め込みベクトル化 → コサイン類似度で候補抽出 → LLMで最終判定という三段構えと、スコア閾値による「返さない」判断の設計をまとめています。" author: "AI活編集部" author_username: ai-katsu-editorial published_at: 2026-05-17T00:00:00+00:00 verified_at: 2026-05-17T00:00:00+00:00 models: ["OpenAI API"] tools: ["Google Apps Script", "Dify", "LINE"] tasks: ["ナレッジ活用・RAG", "業務プロジェクト"] domain: "マーケティング" canonical_url: https://ai-katsu.jp/articles/chatbot-spreadsheet-embedding --- # スプレッドシートを簡易ベクトルDBにする｜FAQボットの精度を保つ三段構え設計 チャットボットのFAQを運用する現場では、しばしば矛盾した要件が出てきます。**「回答精度は上げたい。ただしデータはスプレッドシートで管理したい」**——専用のナレッジベース機能を使わずに、精度をどう担保するか。 この検証では、**スプレッドシートを簡易ベクトルDBとして使う**構成を設計しました。 ## この検証の概要 | 項目 | 内容 | | --- | --- | | 検証時期 | 2026年5月17日〜（検証中） | | やりたかったこと | 専用ナレッジベース機能を使わず、スプレッドシートでのデータ管理のみで回答精度を担保する | | 構成 | Googleスプレッドシート（データ管理＋簡易ベクトルDB）＋ GAS（差分検知・API呼び出し・ベクトル処理）＋ 埋め込みモデル ＋ LLM | | 方式 | **埋め込みベクトル化 → コサイン類似度で候補抽出 → LLMで最終判定**の三段構え | | 状況 | 設計合意・実装フェーズ | ## 結論：キーワード一致では足りない この設計の出発点は、明確な課題認識です。 **ユーザーの質問がスプレッドシート上の既存データと完全一致しないケースをどう判定するか。単純なキーワード検索では限界があります。** FAQは「登録した言い回し」で質問されるとは限りません。同じことを聞いていても、言葉が違えばキーワード検索では引っかかりません。 そこで**埋め込みモデル**を使います。 **埋め込みモデルはキーワード一致ではなく「意味の近さ」を数値で判定できるため、関連性の高い回答抽出に有効です。** ## 三段構えの設計 ``` ① 埋め込みモデルでベクトル化 ↓ ② コサイン類似度で上位候補を抽出（例：5件） ↓ ③ LLMで候補の適切性を判定 ↓ スコアが閾値（例：0.7）を超えた場合のみ回答を返す ``` この構成のポイントは**「返さない」判断ができること**です。 **マッチングスコアが一定を超えた場合のみ回答を返す**——閾値を設けることで、無関係な回答を返すことを防げます。 FAQボットで最も避けたいのは、見当違いの回答を自信満々に返すことです。**「該当する回答が見つかりません」と言えるほうが、信頼を損ないません。** ## スプレッドシートを簡易ベクトルDBとして使う この構成が成立する条件も整理しています。 **スプレッドシートを簡易ベクトルDBとして使い、数百行規模ならGASで運用可能です。** 専用のベクトルDBを立てると、インフラが1つ増えます。運用担当者が触れない場所にデータが移り、管理の手間も増えます。 **データ量が限られているなら、既に運用されている場所の上に載せるほうが定着します。** データ量が増えた場合は、本格的なベクトルDBへ移行する余地も残しています。**最初から大きく作らず、必要になったら移す**という設計判断です。 ## 更新はリアルタイムでなくてよい 運用設計上の重要な割り切りです。 **スプレッドシートの差分を監視し、埋め込みモデルでベクトル化して保存する構成。データ更新はリアルタイム不要で、1日1回等の定期実行、または運用担当者の手動実行で対応します。** FAQの内容が変わるのは、頻繁ではありません。**更新を即時反映する仕組みを作ると、その分だけ構成が複雑になり、API呼び出しも増えます。** **「どのくらいの鮮度が必要か」を先に確認すると、設計が簡単になります。** ## 二重課金という論点 この構成で残る課題です。 **埋め込みモデルとLLMは異なる軸で運用され、それぞれにAPI利用料が発生します。** | 方式 | 検索品質 | 管理の手間 | | --- | --- | --- | | LLM利用 | 上がる | 煩雑 | | キーワード検索 | 下がる | 容易 | **品質と管理容易性はトレードオフになります。**この検証では、埋め込み＋類似度＋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導入を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。