この記事で分かること／分からないこと
- 分かること: ベクトルDBを使わずに済ませられる条件(対象が有界ドメインである場合)
- 分かること: 自社が実際に採用している、索引だけを使う確定配信の構成
- 分からないこと: この構成が非有界(オープンドメイン)の用途にも当てはまるか(当てはまらない可能性が高い)
- 分からないこと: どこからが「有界」でどこからが「非有界」かの一般的な線引き(用途ごとに個別判断が必要)
有界ドメインという条件
これまでの4本の記事で見てきた料金体系・運用負荷・移行性・ハイブリッド検索は、いずれも「意味の近さで検索する」ことを前提にした論点である。しかし、対象とする文書や質問の範囲があらかじめ区切られていて、想定される質問のパターンをビルド時に洗い出せる場合(有界ドメイン)には、実行時にベクトル検索を行わず、あらかじめ用意した索引を引くだけで応答を組み立てる構成が成立する。
自社の構成: 実行時に触るのは索引だけ
自社の実装では、ビルド時に対象データから質問バリエーションと根拠を生成し、検証を通したものだけを索引として確定させる。実行時(会話中)にLLMを呼ばず、索引を引くだけで応答する構成になっており、実測では1セッションあたり0.12円で収まっている(出典: docs/STORAGE_AND_BILLING.md、確認日2026-09-06)。索引の元になる原本や生成物は容量が大きくなりうるため大容量ストレージに置き、実行時に毎回引く索引だけを低レイテンシのストレージに分けて置く設計を取っている。この分割は、データ量が増えても実行時の応答が重くならないようにするための判断である(出典: docs/STORAGE_AND_BILLING.md、確認日2026-09-06)。
なぜこれで足りるのか
ベクトルDBが必要になるのは、対象とする文書やクエリの範囲を事前に洗い出せない場合、あるいは洗い出す作業自体のコストが見合わない場合である。有界ドメインでは、ビルド時に一度だけ人手・LLMのコストをかけて質問バリエーションと根拠を洗い出し、検証を通してしまえば、実行時には「近そうなものを探す」処理そのものが不要になる。これは、これまでの記事で見た料金体系の型・運用負荷・移行性・ハイブリッド検索といった論点が、有界ドメインの構成では最初から発生しないという意味でもある。
一般化できない理由
この構成が成立するのは、対象が有界ドメインだからであり、有界であること自体が前提条件になっている。質問のパターンを事前に洗い出せない対象(オープンドメインの一般的な問い合わせ、日々更新される情報、想定していなかった聞き方が継続的に増える対象)では、この構成は成立しない。したがって、この記事で書いている内容は自社に合っていた条件の説明であり、一般的な推奨として書いているものではない。ベクトルDBを使うかどうかは、対象が有界かどうかという条件で判断が分かれる。
よくある質問
Q1. ベクトルDBが要らなくなるのはどんな場合か
対象とする文書や想定される質問の範囲があらかじめ区切られていて、ビルド時に質問パターンと根拠を洗い出せる場合(有界ドメイン)には、実行時にベクトル検索を行わず索引を引くだけで応答する構成が成立する。
Q2. 自社ではどういう構成を採用しているのか
ビルド時に質問バリエーションと根拠を生成・検証し、実行時はその索引を引くだけでLLMを呼ばない構成を採用している。実測では1セッションあたり0.12円で収まっている(確認日2026-09-06)。
Q3. この構成は一般的に推奨できるものか
推奨できない。この構成が成立するのは対象が有界ドメインだからであり、有界であること自体が前提条件になっている。オープンドメインの用途にそのまま当てはめられるとは限らない。
Q4. 有界かどうかはどう判断すればよいか
この記事だけでは一般的な線引きの基準までは示せない。想定される質問のパターンをビルド時にどこまで洗い出せるか、洗い出す作業のコストが見合うかを、対象ごとに個別に確認する必要がある。
有界ドメインで無くベクトルDBが必要になった場合の、料金体系の型は料金体系の3つの型の記事、移行しやすさとロックインの効きどころは移行しやすさの記事にまとめている。自社が実行時にLLMを呼ばず索引だけで応答を返す構成の詳細は索引による確定配信の記事を参照してほしい。15サービスの比較はRAGサービス比較15選で扱っている。自社の構成が自社の用途に当てはまるか相談したい方は、お問い合わせから編集部までご連絡いただきたい。
- ハブ記事: RAGサービス比較15選
- 関連記事: 索引による確定配信
- 関連記事: 料金体系の3つの型
- 関連記事: 移行しやすさとロックイン