ベクトルデータベースとは？RAGを支える仕組みと建設業での使い方

「社内の施工要領書をAIに読ませて、聞けば答えるようにしたい」——そう相談すると、必ず出てくるのがベクトルデータベースという言葉です。聞き慣れないうえに横文字なので身構えてしまいますが、正体は「AIが意味の近さで探せるように、資料を数値の形で並べておく置き場」にすぎません。この記事では、ベクトルデータベースとは何か、普段使っている表形式のデータベースと何が違うのか、なぜ大量の資料から一瞬で候補を出せるのかを、数式なしで整理します。そのうえで、建設会社が実際に導入を考えるときの選び方と、つまずきやすい運用の勘所までを扱います。

ベクトルデータベースとは

ベクトルデータベースとは、文章や画像を数値の並び（ベクトル）に変換したものを保存し、意味の近いものを高速に取り出すことに特化したデータベースです。Elasticの解説でも「意味的な類似性検索を可能にするために、高次元のベクトル埋め込みを保存、管理、検索する特殊なデータベース」と定義されています（出典: Elastic「ベクトルデータベースとは」）。略して「ベクトルDB」と呼ばれることもあります。

ひとことで言うと

資料を「意味の座標」に変えて置いておく倉庫であり、同時に「この座標に近い品物を持ってこい」と言える窓口でもあります。生成AIに自社資料を読ませるRAGという仕組みでは、AIが答えを書く前に必ずこの倉庫から材料を引き出しています。

順番を整理すると、こうなります。まず文章や写真を数値の並びに変換する工程があり、これをエンベディング（埋め込み）と呼びます。次に、変換した数値を保存して探せるようにしておく置き場が必要になります。この置き場がベクトルデータベースです。変換の技術と保管の仕組みは役割が別で、片方だけでは使いものになりません。

OpenAIのtext-embedding-3-largeが文章1かたまりごとに出力する数値の個数（次元数）。ada-002と3-smallは1,536個

3,072個

Microsoft Learn「ベクター検索用の Azure サービスを選択する」

この数字が、専用のデータベースが必要になる理由をよく表しています。要領書を段落ごとに5,000個の塊に切ったとすると、保存されるのは5,000×3,072個の数値です。しかも検索のたびに「質問の3,072個」と「保存済みの全部」を比べる必要があります。表計算ソフトの発想では手に負えない量で、だからこそ専用の道具が生まれました。

普段使っているデータベースとの違い

工事台帳や勤怠のシステムが使っているのは、行と列の表にデータを並べるリレーショナルデータベースです。ここでの検索は「工事番号が2024-118のもの」「工種が鉄筋のもの」といった条件の一致で、合うか合わないかの二択で答えが出ます。対してベクトルデータベースの検索は、条件の一致ではなく距離の計算です。近い順に並べて上位を返すため、結果には必ず「どれくらい近いか」という点数が付いてきます。

表形式のデータベース：条件に合う行を返す。同じ検索なら答えは常に同じ
ベクトルデータベース：近い順に上位いくつかを返す。何件返すかは利用者が指定する
表形式は「該当なし」があり得るが、ベクトル検索は必ず何かを返す。近さが低くても上位として出てくる
そのため「点数がこれ以下なら使わない」という足切りの線引きが運用上いる

この「必ず何かを返す」という性質は、実務では地味に効いてきます。社内に答えがない質問をされても、それらしい資料が上位に並び、それを材料にAIが自信満々の文章を書いてしまう。ハルシネーションの引き金が、実は検索側にあるという場面は珍しくありません。詳しくはハルシネーションの記事で整理しています。

仕組み：どうやって近いものを速く見つけるか

1
資料を扱いやすい大きさに切る
施工要領書やマニュアルを、見出しや段落ごとの塊に分けます。Microsoftの解説でも、思うような結果が出ないときはチャンクの大きさと重なりの設定を変えてみるよう案内されており、塊の前後に少し重なりを持たせて文脈を保つのが定石とされています。
2
数値に変換して保存する
切り分けた塊ひとつひとつを埋め込みモデルに通してベクトルに変換し、元の文章や出典情報と一緒にデータベースへ入れます。ここまでが仕込みで、資料が増えたら追加していく運用になります。
3
索引を作る
全件と突き合わせずに済むよう、ベクトルどうしのつながりを整理した索引を先に作っておきます。この索引の作り方が、後の速さと精度を決めます。
4
質問を変換して近い順に取り出す
利用者の質問文も同じモデルでベクトルに変換し、索引をたどって近いものを上位から取り出します。近さの物差しにはコサイン類似度、ユークリッド距離、ドット積などが使われ、文章の検索ではコサイン類似度が向くとされています。

索引の作り方には大きく二通りあります。ひとつは全件を総当たりで比べる方法で、完全kニアレストネイバー（Ek-NN）と呼ばれます。答えは常に正確ですが、件数が増えるほど遅くなります。もうひとつが近似最近傍探索（ANN）で、多少の取りこぼしを許す代わりに探索範囲を大きく削り、桁違いに速く答えを返します（出典: Microsoft Learn「ベクターの関連性とランク付け」）。実務で使われているのは、ほぼこちらです。

ANNの代表格がHNSWで、データを階層グラフに整理し、上の階層で大まかな見当をつけてから下の階層で細かく絞り込みます。高速な応答が要る用途に向く一方、全データをメモリ上に置く必要がある点は費用に直結します。ほかにIVFFlatやDiskANNといった方式もあり、Microsoftの比較記事ではIVFFlatはハードウェア資源が限られる環境や検索量が多くない環境で有効と整理されています。中小規模の社内検索なら、必ずしも一番速い方式を選ぶ必要はありません。

AI侍

総当たりは確かなれど遅うござる。ANNは近道を通す代わり、まれに取り逃がす。速さと確かさ、いずれを取るかは用向き次第にござる。

現場名や年度で絞り込むメタデータフィルタ

ベクトルデータベースは、意味の近さだけで探すわけではありません。保存するときに現場名・工種・年度・作成部署・公開範囲といった属性を一緒に持たせておき、検索時に絞り込むことができます。Elasticの解説では、絞り込みを検索の前に行うプレフィルタリングと、検索の後に行うポストフィルタリングの二通りが紹介されています。

建設会社では、この属性の設計が使い勝手をほぼ決めます。「2022年以降の改訂版だけ」「自社の標準仕様書に限る」「協力会社に見せてよい資料だけ」といった条件を後から足せるかどうかで、実務に耐えるかが変わるためです。最初にベクトルだけ入れて属性を付け忘れ、あとから全部入れ直しになる、というのはよくある手戻りです。

型番や図面番号にはハイブリッド検索

意味で探すのが得意なぶん、記号には弱い

ベクトル検索は「言い回しが違っても意味が近ければ拾う」のが持ち味です。裏返せば、意味を持たない文字列——製品型番、図面番号、規格番号などを一字一句で当てにいく用途には向きません。従来のキーワード検索と組み合わせ、両方の結果を混ぜて順位を付け直すハイブリッド検索が現実解になります。Microsoftのベンチマークでも、ハイブリッド検索と再ランク付けの組み合わせが一貫して最も関連性の高い結果をもたらしたと報告されています。

建設現場でのベクトルデータベースの使い方

ベクトルデータベースは単体で買って使うものではなく、社内検索やチャットの内側で動いています。建設会社の業務に当てはめると、次のような場面が候補になります。

施工要領書・社内標準への質問対応。「この納まりの標準は」と聞けば、該当箇所を根拠として示す
過去見積の参照。用途・構造・規模の近い物件の内訳を呼び出し、拾い漏れを確認する
安全書類とヒヤリハット。これから着手する作業に近い過去事例を、記憶に頼らず引き当てる
議事録と打合せ記録。「あの変更、どこで決まったか」を言い回しの違いを越えて探す
工事写真の整理。似た構図・似た部位の写真をまとめ、台帳づくりの下ごしらえにする
問い合わせ対応。同じ趣旨の質問に過去どう答えたかを、担当者不在でもたどれるようにする

生成AIを活用・利用する方針を策定している日本企業の割合（2024年度）。2023年度の42.7%から増加

49.7%

総務省「令和7年版情報通信白書」

総務省の令和7年版情報通信白書によると、生成AIを活用・利用する方針を策定している日本企業の割合は2024年度で49.7%と、前年度の42.7%から伸びています。同白書では課題として「実用的な活用方法がわからない」「既存規則との齟齬」「セキュリティリスク」「導入コスト」などが挙げられており、方針は決めたものの何から手を付けるか定まらない、という段階の会社が相当数あることがうかがえます。

建設業でも取り組みは出ています。竹中工務店は2023年10月、専門的な質問に答えるAIチャットボット「デジタル棟梁」の構築を明らかにしました。仕様書や技術ノウハウ集をAmazon S3に置き、検索エンジンのAmazon Kendraが探してきた資料をもとにClaude 2が回答する、というRAG構成です（出典: ITmedia NEWS、2023年10月4日）。ベテランの知識を部門やプロジェクトを越えて残し、全社で継承することが狙いだと説明されています。「探す」ところを起点に据えている点は、注目に値します。

どれを選ぶか：専用DB・既存DBの拡張・検索サービス

ベクトルを保存する先には、大きく三つの選択肢があります。ベクトル検索を主目的とした専用データベース、いま使っているデータベースに機能を足す方法、そしてベクトル検索を含む検索サービスをまるごと借りる方法です。

専用のベクトルデータベース：ベクトル検索に最適化されており、件数が非常に多い場合や細かな調整をしたい場合に向く
既存データベースの拡張：PostgreSQLにpgvectorを入れるなど。運用データとベクトルを同じ場所に置ける
検索サービスの利用：ハイブリッド検索や再ランク付けが最初から用意されており、自前で作り込む手間が少ない

pgvectorは、PostgreSQLにベクトル型と類似度検索を追加するオープンソースの拡張機能で、HNSWとIVFFlatの両方の索引に対応し、コサイン距離やL2距離などを扱えます（出典: pgvector GitHubリポジトリ）。Microsoftの選定ガイドでも、新しいサービスを増やせばコストと複雑さが増すため、既存のデータベースでのベクトル検索のほうが費用効率が高い場合があると明記されています。つまり、いきなり専用品を買う話ではありません。

中小の建設会社は、まず既製サービスで確かめる

ここまで読んで「うちで一から作るのか」と感じたなら、その必要はありません。社内文書検索やAIチャットの既製サービスは、内部にベクトルデータベースを持っています。仕組みを知っておく価値は、選ぶときに「どの索引か」「属性で絞り込めるか」「キーワード検索と併用できるか」を確認できる点にあります。自前で構築するかどうかは、既製品で効果を確かめてからで遅くありません。

メリットと注意点

「どこにあるか知っている人」に依存しなくなる

サーバーの奥や紙のファイルを当てもなく開いて回る時間は、日報にも工数表にも載りませんが確実に発生しています。意味で探せる仕組みは、その見えない時間を削ります。担当者しか場所を知らない資料を、他の人でも引き当てられるようになる点も見逃せません。

元の資料を直しても、自動では反映されない

ベクトルデータベースに入っているのは、変換した時点の資料の写しです。共有フォルダで要領書を差し替えても、登録し直さなければ古い内容が根拠として出続けます。廃止した資料を消す手順まで含めて、誰がいつ更新するかを決めてから始めてください。ここを決めずに走り出した仕組みは、たいてい半年で信用を失います。

資料の切り分け方で精度が大きく変わる。うまく探せないときは、まず切り方と元資料の状態を疑う
埋め込みモデルを入れ替えると座標系が変わるため、原則として全資料の変換をやり直す必要がある
HNSWは全データをメモリに置く方式のため、件数が増えると費用が上がりやすい
図面や手書きの帳票はそのままでは文字として読めない。先に文字を取り出す工程がいる
「近い資料」を出す仕組みであって、答えの正誤を保証するものではない。最終判断は人が持つ

もうひとつ見落とされやすいのが権限の扱いです。表形式のシステムなら「この部署はこの行まで」と分けられますが、ベクトルデータベースでは属性を付けて絞り込む設計を自分で用意しない限り、入れた資料は誰の検索にも引っかかり得ます。原価や個人情報を含む書類を入れるなら、誰がどこまで見てよいかを先に決めることが前提です。社外サービスに預ける場合の確認事項は情報漏洩対策の記事にまとめています。どの資料から手を付けるべきか判断がつかない場合は、AI番頭のサービスで業務の棚卸しからご相談いただけます。

導入の進め方

1
探す手間が多い書類を一種類だけ選ぶ
全社一斉ではなく、「毎回どこかから探している」書類が一種類あれば十分です。施工要領書、過去の見積、安全書類のいずれかから選ぶ会社が多いところです。
2
正とする資料を仕分ける
最新版はどれか、廃止版はどれかを人の手で仕分けます。地味な工程ですが、ここの丁寧さが最終的な使い勝手をほぼ決めます。
3
絞り込みに使う属性を決める
現場名、工種、年度、公開範囲など、後から絞り込みたい項目を洗い出し、登録時に一緒に持たせます。あとから足すと入れ直しになりがちな部分です。
4
小さく試して聞き方を持ち寄る
現場と事務の数人で二週間ほど使い、どんな聞き方なら望む資料が出るかを共有します。うまくいかない質問例こそ、改善の材料になります。
5
更新の担当と頻度を決める
資料が改訂されたら誰がいつ登録し直すのか、廃止版をどう消すのかを運用ルールとして書き残します。ここまで決めて、はじめて仕組みとして回り始めます。

自社の資料で使えるか無料で相談する

ベクトルデータベースについてよくある質問

QRAGとベクトルデータベースはどう違うのですか＋

RAG（検索拡張生成）は、社内資料を探してAIに読ませ、それをもとに回答を作らせる仕組み全体の呼び名です。ベクトルデータベースは、その「探す」部分を担う部品にあたります。RAGを作るなら基本的にベクトルデータベースが要りますが、ベクトルデータベース自体は検索や類似写真の抽出など、AIに文章を書かせない用途にも使えます。

Q小さな会社でも専用のベクトルデータベースが必要ですか＋

多くの場合は不要です。社内文書検索やAIチャットの既製サービスを使えば、ベクトルデータベースは内部に含まれています。自前で用意するのは、扱う資料が非常に多い場合や、既存システムと深く組み合わせたい場合です。Microsoftの選定ガイドでも、新しいサービスを増やすとコストと複雑さが増すため、既存のデータベースに機能を足すほうが費用効率が高い場合があると案内されています。

QExcelの台帳や共有フォルダのままでは駄目なのですか＋

駄目ではありません。ファイル名や工事番号で確実にたどり着けているなら、そのままで十分です。ベクトルデータベースが効くのは、「言い方が人によって違う」「どのフォルダにあるか分からない」「探せるのは特定の担当者だけ」という状態のときです。斫りとハツリ、養生と保護、手直しと是正のように、同じことを指す表記が社内で揺れているほど恩恵が大きくなります。

Q紙の図面や手書きの日報しかない場合はどうすればよいですか＋

先に文字として読み取る工程が必要です。スキャンした画像から文字を取り出すOCRを通し、テキストになった段階でベクトルに変換します。手書きの日報や古い青焼き図面は読み取り精度が落ちやすいため、まずは電子データで残っている資料から始めるほうが、効果を確かめやすくなります。

Q検索結果が的外れなときは何を直せばよいですか＋

順番としては、資料の切り分け方、取り出す件数、キーワード検索との併用の三つを見ます。Microsoftの案内でも、チャンクの大きさと重なりを変えて試すこと、AIに渡す検索結果の件数を増やすこと、ハイブリッド検索と再ランク付けを試すことが改善策として挙げられています。索引の方式やモデルの入れ替えを検討するのは、その後で構いません。