社内AI検索やRAG導入の提案書を受け取ったものの、見積の内訳に並ぶ「ベクトルデータベース」という項目が何のための費用なのか説明できずに困っていませんか。
生成AIが社内文書を検索して回答する仕組みがこの2年ほどで急速に実用化され、その検索を担う土台としてベクトルデータベースが提案書に組み込まれるケースが増えています。
この記事では、業務自動化の構築設計で使っている整理の仕方をもとに、通常のデータベースとの違い、見積の内訳が何に対する費用なのか、そして導入が向かない条件までを整理しています。
ベクトルデータベースと通常のデータベースは何が違うのか？
ベクトルデータベースは、文章や画像の意味の近さを数値で表して検索するためのデータベースです。
通常のデータベース、いわゆるリレーショナルデータベースは、決まった形式のデータを表にして、条件に完全一致するものを探し出す仕組みで、両者は保存するデータの形と検索の仕方がそもそも違います。
違いを理解するには、何を保存するか、どう検索するか、何に向いているかの3点で見るのが分かりやすい整理の仕方です。
何を保存するか
通常のデータベースは、氏名や金額、日付のように、あらかじめ列の意味を決めた表形式でデータを保存します。
一方のベクトルデータベースは、文章や画像をAIでembedding（埋め込み：文章や画像の意味を数値の配列に変換したもの）に変換し、その数値の配列をそのまま保存する仕組みです。
例えば社内マニュアルのPDFを社内AI検索に取り込む場合、ページごとの文章をembeddingに変換してから保存する形になります。
元の表形式のデータベースにそのまま入れる方式とは、保存の単位そのものが別物です。
どう検索するか
通常のデータベースは、取引先名が特定の文字列と一致するかどうかのように、条件への完全一致で検索します。
ベクトルデータベースは、質問文もembeddingに変換したうえで、保存済みの数値の配列と意味がどれだけ近いかを計算し、近い順に結果を返す方式です。
このため「返品の手続きを知りたい」という質問に対して、マニュアル内に「返品」という単語が一度も出てこなくても、「返送」や「交換」を扱ったページを意味の近さから探し出せます。
完全一致のキーワード検索では表記の違いだけでヒットしない場面を拾えるのが、この検索方式の実務上の利点です。
キーワード検索とベクトルデータベースによる検索の違いと、どちらを使い分けるべきかは次の記事で詳しく整理しています。
何に向くか
通常のデータベースは、顧客台帳や在庫管理、経理の仕訳のように、正確な一致と集計が必要な業務データの管理に向いています。
ベクトルデータベースは、社内マニュアルやFAQ、議事録のように、表現の揺れがある文章から意味の近い情報を探し出す用途に向いています。
在庫の残数を1個の誤差もなく数える業務にベクトルデータベースを使う必要はありません。
反対に、表現がまちまちな問い合わせ履歴から似た事例を探す業務を、通常のデータベースの条件検索だけでカバーするのも難しくなります。
業務データは通常のデータベース、文章の検索はベクトルデータベースという役割分担で使われるのが、実際の構成です。
文章をどのようにembeddingへ変換しているかは、次の記事で仕組みから整理しています。
なぜ社内AI検索やRAGにベクトルデータベースが使われるのか？
生成AIは学習した時点までの知識しか持たず、社内の最新文書や独自ルールを聞かれても答えられません。
そこで使われるのがRAG（Retrieval-Augmented Generation：検索拡張生成）です。
質問に関連する社内文書を検索して見つけ出し、その内容を生成AIに読ませたうえで回答させる仕組みを指します。
この関連する文書を検索して見つけ出す部分を担うのがベクトルデータベースで、生成AIの回答の精度は検索でどれだけ的確な文書を見つけられるかに左右されます。
文章をembeddingに変換する
RAGの最初の工程は、社内文書をあらかじめembeddingに変換してベクトルデータベースへ保存しておくことです。
質問を受け取ったときも同じ方法でembeddingに変換し、保存済みの文書と見比べられる状態にします。
変換の精度は使うembeddingモデルによって差があり、専門用語が多い業界のマニュアルでは、汎用モデルだと意味の近さをうまく捉えられず、狙った文書がヒットしない場合もあります。
ANNで高速に候補を絞り込む
保存された文書が数万件を超えると、質問のembeddingとすべての文書を1件ずつ照合する方式では応答に時間がかかりすぎるのが実務上の課題です。
そこで使われるのがANN（Approximate Nearest Neighbor：近似最近傍探索）で、厳密に一番近い1件を探すのではなく、ほぼ確実に近い候補を高速に絞り込む方式です。
社内文書が数千件程度の中小規模であれば、この高速化の恩恵は限定的で、素朴な全件照合でも実用上の速度に収まることが少なくありません。
このANNは商用サービスの中核技術にもなっており、Google Cloudは自社のベクトル検索エンジンを次のように説明しています。
Vector Search is a powerful vector search engine built on groundbreaking technology developed by Google Research. Leveraging the ScaNN algorithm, Vector Search lets you build next-generation search and recommendation systems as well as generative AI applications.
（訳）Vector SearchはGoogle Researchが開発した先進技術を基盤とする高性能なベクトル検索エンジンであり、ScaNNアルゴリズムを活用して次世代の検索・レコメンドシステムや生成AIアプリケーションを構築できる。
出典： Google Cloud「Vector Search overview」
引用中のScaNNは、前述のANNを高速に実行するためにGoogle Researchが開発したアルゴリズムで、大規模なベクトル検索がこの近似方式を土台に成り立っていることがわかります。
見つけた文書を生成AIに渡す
ベクトルデータベースが質問に近い文書を数件見つけ出すと、その文章をそのまま生成AIへの入力に添えて渡します。
生成AIは自分の学習知識だけでなく、渡された社内文書の内容を根拠にして回答を組み立てるため、社内にしかないルールや最新の情報についても答えられるようになります。
渡す文書の件数が多すぎると生成AIが要点を絞れなくなり、少なすぎると必要な情報が抜け落ちるため、何件を渡すかの調整も導入時に詰める設計項目のひとつです。
RAGの仕組み全体については、次の記事でさらに詳しく整理しています。
提案書のベクトルデータベースは何にお金がかかっているのか？
提案書のベクトルデータベースの費用は、大きく分けて、どう動かすか、どれだけ保存するか、どれだけ検索するかの3つで決まり、どこに重みがあるかで月々の費用も増減の仕方も変わります。
内訳を1行ずつ確認せずに合計金額だけで妥当性を判断すると、削れる部分と削れない部分の見分けがつかなくなるため、以下の3点に分けて確認するのが近道です。
マネージド型か自前構築かで運用工数の重みが違う
マネージドサービス（提供会社がサーバーの管理や更新作業を代行する契約形態）を使う場合、月額の利用料に運用の手間が含まれているため、初期費用は抑えられます。
その代わり、月々の利用料は保存量や検索量に応じて上がっていきます。
自社のサーバーにベクトルデータベースを構築する自前運用の場合、月額の利用料自体は発生しません。
ただし、サーバーの維持、障害対応、バージョンアップの作業を社内か委託先が担う必要があり、この運用工数が見積の人件費として計上されます。
情報システム担当者がいない、または他業務と兼務している会社では、運用工数を自社で吸収する前提の見積は現実的でなく、この工数分がマネージド型の月額費用として提案書に含まれています。
保存するデータの量に応じてインデックスの費用がかかる
ベクトルデータベースに保存する社内文書の量が増えるほど、embeddingへの変換にかかる処理と、検索のために保持しておくインデックス（検索用に整理したデータの索引）の容量が増える構造です。
見積書に「データ容量に応じた従量課金」という項目があれば、社内文書のページ数やファイル数が増えるほど費用が上がる設計になっていることを示しています。
対象文書を全社の全フォルダにするか、よく参照される一部の部署のマニュアルに絞るかで、この項目の金額は大きく上下します。
範囲を絞れないか検討する余地がある費用項目です。
検索する回数に応じてクエリの費用がかかる
質問を受け取るたびにembeddingへの変換とベクトルデータベースへの検索が1回ずつ発生し、この回数に応じた従量課金がかかる仕組みになっています。
社内AI検索を使う社員の人数と、1人あたりの1日の質問回数を掛け合わせると月間のおおよその検索回数が見積もれ、見積書のクエリ課金の妥当性を自社の使い方に当てはめて確認できます。
利用者を試験導入の一部門に絞ってスタートすれば、この項目の費用は絞った人数分に収まり、全社展開前に費用感を確かめられるのも利点です。
自社の見積でこの3つの内訳がどこまで書かれているか確認したい場合は、 個別相談 で一緒に棚卸しすることもできます。
ベクトルデータベースが向かない・不要なケースとは？
ベクトルデータベースは万能ではなく、扱うデータの量や種類によっては導入しても費用に見合う効果が出ません。
向かない条件を先に押さえておくと、提案書の中で削れる項目を見分けやすくなります。
判断の軸になるのは、検索対象の文書量、データの種類、更新の頻度の3つです。
検索対象の文書量が少ない場合
規模の目安として、社内文書が数十件から百件程度であれば、ファイル検索やExcelのフィルタ、Wordの全文検索といった標準機能で十分に目的の文書へたどり着けます。
ベクトルデータベースの利点は、数千件を超える文書の中から意味の近いものを探し出す点にあるため、対象が少量のうちは導入の費用が効果を上回りやすくなります。
まず標準機能で探しにくさを実感してから検討しても遅くありません。
検索対象が構造化データだけの場合
顧客名簿や在庫数、売上金額のように、あらかじめ列の意味が決まっているデータだけを検索したい場合は、通常のデータベースの条件検索だけで用が足ります。
ベクトルデータベースが強みを発揮するのは、文章のように表現の揺れがあるデータから意味の近さを探す場面で、数値や固有名詞の完全一致を求める検索には向きません。
取引先コードや受注番号を指定した検索が中心の業務であれば、ベクトルデータベースを足す必要はありません。
文書の更新頻度が高すぎる場合
社内文書を更新するたびに、変更箇所をembeddingに変換し直してインデックスへ反映する作業が発生します。
1日に何十件も内容が更新される文書を扱う場合は、この再変換の作業と費用が積み重なり、検索の精度を保つための運用負荷が導入前の想定を上回ることがあります。
更新頻度が高い文書群は対象から外して定期的な一括更新に切り替える、あるいは更新頻度が低い文書から先に対象を絞る、といった調整が現実的な落としどころです。
ベクトルデータベースの導入について相談してみませんか？
「見積の内訳のどこまでが妥当か判断できない」「マネージド型と自前構築のどちらが自社に合うか分からない」「社内にベクトルデータベースの要否を判断できる人材がいない」
少しでもお心当たりがあれば、お気軽にご相談ください。
現在、AI業務自動化に関するお悩みをお伺いする 無料の個別相談 を実施しています。
よくある質問
Q. 自社の社内文書が数百件程度でも、ベクトルデータベースは必要ですか？
数百件程度であれば、必ずしも必要ではありません。
ファイル検索や全文検索機能でも目的の文書に届く場合が多く、まずは標準機能で探しにくさが実際に発生しているかを確認するのが先です。
文書量が数千件を超え、表現の揺れで検索漏れが増えてきた段階で導入を検討する順序が現実的です。
Q. マネージド型と自前構築、どちらが費用を抑えられますか？
情報システム担当者を確保できるかどうかで結果が分かれ、運用工数を社内で吸収できるならマネージド型の月額利用料が丸ごと不要になります。
担当者がいない、または兼務の場合は運用工数を委託費として見積に計上する必要があり、結果としてマネージド型の月額費用と大きく変わらないことがあります。
Q. 導入したものの効果が出なかった場合、後から縮小できますか？
はい、対象とする文書の範囲や利用者の人数を絞ることで費用の縮小が可能です。
全社の全フォルダを対象にする前に、一部門の一部フォルダで試験導入し、検索精度と費用感を確認してから対象を広げる進め方であれば、効果が出なかった場合の縮小もしやすくなります。
Q. ベクトルデータベース以外に、社内AI検索の精度を左右する要素はありますか？
大きく影響するのは文書の整理状態です。
同じ内容のファイルが複数の場所に重複していたり、古い版が更新されずに残っていたりすると、検索結果に古い情報や矛盾する内容が混ざり込みます。
ベクトルデータベースを導入する前に対象文書を整理し、重複や古い版を減らしておくと、検索精度への影響を抑えられます。
