ベクトルデータベースか既存の検索か｜探させる土台の選び方

「社内文書をAIに探させたいのですが、専用の保存先を用意しないと駄目でしょうか」「見積りに保存先の構築費が入っていて、要るのかどうか判断がつきません」——AI導入の検討でよく詰まる場所です。ここには誤解が1つ混ざっています。意味で探す仕組みを使うことと、そのために専用の保存先を建てることは、同じことではありません。本当は置き場の選定は、件数と応答時間と作り直しの頻度で決まる話で、社内文書の多くはいま動いている仕組みの延長で足ります。この記事では、意味で探すとは何をしているのかを押さえたうえで、既存の全文検索で足りる場面、専用の保存先が要る条件、両方を併せる形、そして選定の本当の難所である権限の持たせ方までを整理します。

「専用の保存先が必要」という前提は、いつの話か

この前提は間違いというより、少し古いだけです。意味の近さで探す機能が世に出た当初、その機能は既存のデータベースや検索製品には入っていませんでした。使いたければ専用の製品を別に建てるしかなく、だから「意味で探すなら専用の保存先」という組み合わせで語られてきました。いまはこの前提が崩れています。

2026年7月に公表された整理では、意味で探す機能が入った既存側の例として、広く使われている関係データベースの拡張機能、大手のデータベース製品の新版、表計算に近い形の管理システムのベクトル型、クラウドの各種データベース、そして全文検索の製品が並べられています。つまりいま動いている仕組みに機能を足すという選択肢が、正面から候補に入るようになりました。

この変化は、判断の形も変えます。かつては「意味で探すかどうか」を決めれば置き場も決まりました。いまは探し方と置き場が別の判断になったので、2つを分けて考える必要があります。以下では、まず探し方の中身、次に置き場の選び方という順で見ていきます。

意味で探すとは、何をしているのか

文章を、意味の近さを計算できる形に置き換えます。具体的には、1つの文の塊を数百から数千個の数の並びに変換し、その並びが近いものを近い意味とみなします。よく使われる大きさは1,536個の数で、1件あたりの生の大きさは約6キロバイトです。問いの文も同じやり方で数の並びに変え、近い順に取り出す。これが意味で探すという処理の全体です。

この方式の強みは、語が一致しなくても引っかかることです。「解約したい」と書いた問いに対して「契約終了の手続き」という見出しの資料が返ってきます。言い換え、同義語、別の言い方で書かれた資料が拾えるので、社内文書のように書き手が揃っていない資料群で効きます。

弱みは裏返しです。近い意味を拾う仕組みなので、その語でなければ駄目なものを外します。型番、規程の番号、人名、日付、金額。これらは「近い」では困る対象です。次の節で見るように、この弱みは思っているより大きく出ます。

語の一致は、いまでも大差で勝つ場面がある

大手クラウド事業者の検索サービスが2023年9月に公表し、2024年1月に更新した検証があります。顧客の4つのデータ群に対して、語の一致だけ、意味の近さだけ、両方の併用、併用したうえで上位を並べ直す、の4つを比べたものです。順位の良さを0から100で表す指標（上位3件を見る形）で、全体の成績はこうなりました。

探し方	全体の点	語そのものを探す問い	長い問い
語の一致だけ	40.6	79.2	42.7
意味の近さだけ	43.8	11.7	41.6
両方を併用	48.4	—	48.1
併用＋上位を並べ直す	60.1	—	59.4

注目すべきは真ん中の列です。語そのものを探す問いでは、語の一致が79.2、意味の近さが11.7。差は67.5ポイントで、勝ち負けというより別の道具です。同じ検証では、抜き書きの一致を探す問いで意味の近さが41.5、短い問いで38.8と、いずれも語の一致に負けています。逆に言い換えを探す問いは59.6、事実を探す問いは63.4、綴りを誤った問いは54.6と、併用して並べ直した形が伸びています。

実務にそのまま効く読み方は1つです。いま社内で「型番で探す」「規程番号で探す」が回っているなら、それを意味で探す仕組みに置き換えてはいけません。置き換えではなく足す。2023年の検証なので個々の数字は動いているはずですが、語と意味が別の得意分野を持つという構造は変わっていません。

併せると上がる。順位を束ねるという考え方

両方を引いて、結果を1つに束ねる形が既定になりつつあります。全文検索製品の公式説明は、意味の側は意味で点を付け、語の側は文字の似方で点を付け、両方に当たった段落が最も上に来て、片方だけに当たったものが続くと書いています。束ね方には順位の逆数を足し合わせる仕組みが使われ、標準の機能として提供されています。

点の付け方が違うもの同士を足すために、点そのものではなく順位を使うのが要点です。意味の近さの点と語の一致の点は尺度が違うので、直接足すと片方に引っ張られます。順位に置き換えて足せば、どちらの引き方でも上位に来たものが自然に前へ出る。この一手だけで、先の検証では40.6と43.8だった成績が48.4になりました。

さらに上位だけを別の仕組みで並べ直すと60.1まで上がります。ここで大事なのは、並べ直しは上位の数十件にだけ掛けるという点です。全件に重い処理を掛けると費用と時間が跳ねます。粗く広く取ってから、上位だけ丁寧に見る。この2段構えが、費用と品質の折り合いを付ける定石です。

置き場の選択肢は4つある

ここから置き場の話に移ります。選択肢は大きく4つで、重さが順に上がります。判断は「どれが優れているか」ではなく「どこまでの重さを引き受けられるか」です。

1. いま使っている全文検索のまま、辞書と同義語と絞り込みを詰める。追加の部品はゼロ
2. いま使っている関係データベースに拡張機能を入れ、意味の近さの欄を1つ足す
3. クラウドの検索サービスの機能として使う。索引・併用・並べ直しが最初から揃っている
4. 専用の保存先を別に建てる。設計の自由度は最大で、運用する対象が1つ増える

1番と2番の差は小さく見えて実は大きいところがあります。2番は関係データベースの中で、意味の近さと通常の条件を同じ問い合わせで扱える点が効きます。部署が一致し、有効期限内で、意味が近いものを1回で取り出せる。この一体感は、置き場を分けた形では出しにくい特徴です。

3番は自社で索引を設計しなくてよい代わりに、細かい調整が製品の作りに縛られます。4番は逆で、索引の型や量子化の設定まで選べますが、監視・更新・当番・障害対応を持つ対象が1つ増えます。1本目の案件で4番から始める理由は、ほとんどありません。

規模の目安：どこから重くなるのか

件数の話を数で押さえます。1,536個の数の並びで1件が約6キロバイト。索引の分を含めた実運用では1件あたり20から25キロバイトに着地するという報告があります。この係数で読むと、100万件で数十ギガバイトの記憶領域、1,000万件で記憶領域の設計そのものが中心課題になり、1億件では保存だけで600ギガバイトを超えます。10億件を超えると、既存の関係データベースに寄せる形は最も簡単でも最も安くもなくなります。

分かれ目としてよく挙げられるのは5,000万件です。2026年7月の整理は、5,000万件未満なら既存の関係データベースと拡張機能で本番運用に耐え、それを超えると性能差が見えてくると述べています。同じ整理では、1,000万件を超えたあたりで応答が50ミリ秒から800ミリ秒に伸びるという観測も示されています。

この数字を社内文書に引き直すと、判断が一気に軽くなります。1つの文書を1,000字程度で区切ると、10ページの資料で10個から30個の塊になります。10万文書を抱えていても、塊の数は100万から300万。つまり多くの会社は分かれ目の何十分の一の規模にいます。専用の保存先が要るかどうかを議論する前に、自社の塊の数を数えるのが先です。

索引を作るところで、最初につまずく

運用で先に問題になるのは、探す速さではなく索引を作る側です。近い点を辿る型の索引は、作っているあいだ、点をつないだ図を作業用の記憶に載せます。拡張機能の公式説明は、図が索引作成用の作業記憶に収まると作成が大幅に速くなると書いており、収まらない場合は通知が出ます。収まらないと桁が変わる遅さになるので、初回の取り込みは業務時間外に回すのが安全です。

次元の上限も先に見ておきます。同じ拡張機能では、通常の型で2,000次元、精度を半分にして持つ型で4,000次元、ビット列で64,000次元、疎な形で非ゼロ要素1,000個までと決まっています。使う変換の出力が3,000次元を超えるなら、持ち方を先に決めておく必要があります。

そしてもう1つ、見落とされやすいのが作り直しです。文章を数の並びに変換する仕組みを別のものに替えると、過去の全件をもう一度変換して索引を作り直します。100万件の作り直しに何時間かかるかを一度測っておくと、後の意思決定が速くなります。測っていないと、変換の仕組みを更新できないまま古い精度で運用が続きます。

絞り込みを掛けると、結果が静かに減る

ここが実務で最も事故になる箇所です。近い順を返す索引は、先に索引を引いて、そのあとで絞り込みを掛けます。順番が逆ではありません。だから10件欲しいと指定して索引が10件返し、絞り込みが9件を落とせば、返るのは1件になります。エラーは出ません。静かに減ります。

公式の説明には具体的な数字があります。探索の幅の既定値は40で、絞り込みが9割の行を落とす条件では、返ってくるのは約4件。多くの案件で「なぜか答えが薄い」という症状が出るのは、たいていこれです。対策として、足りなければ索引をさらに辿る設定が0.8.0で入りました。順序を厳密に保つ型と、少し緩めて速さを取る型の2つがあります。

• 絞り込みを掛けたまま件数だけを見て「資料が足りない」と判断する。索引の設定の問題であることが多い
• 返る件数が減ったことに気づかないまま、AIの答えが薄い原因をモデル側に求める
• 探索の幅を大きくして解決しようとする。応答時間が全体的に伸び、費用も上がる
• 絞り込みの条件を後から増やす。条件が1つ増えるたびに、返る件数の見積りが崩れる

権限を、どこで絞るか

選定の本当の難所はここです。社内文書には、見せてよい相手が決まっているものが混ざります。公開されている手引きが示す型は単純で、文書ごとに「閲覧できる集団の識別子」を並べた欄を1つ持たせ、問い合わせのときにその値で絞るというものです。欄は絞り込み可に設定し、結果として返さない設定にします。識別子そのものを利用者に見せないためです。

同じ手引きは重要な注意を1つ書いています。この識別子は認証でも認可でもなく、ただの文字列だという点です。つまり誰の権限で問い合わせているのかを渡す責任は、呼び出す側の仕組みにあります。ここを曖昧にしたまま作ると、全員が同じ権限で引く仕組みになり、後から直すのは索引の作り直しになります。

書き方による速さの差も明記されています。等号を並べて「識別子がこれ、または、これ」と書く形は、値が数百から数千になると応答が何秒も遅くなります。専用の絞り込み関数を使えば1秒未満で返ります。大企業では所属集団が数十から数百になるのが普通なので、この差は現実に出ます。

そして、ここはAIに判断させてはいけない場所です。この人にこの資料を見せてよいかを答えの生成側で判断させると、判断が揺れ、根拠も残りません。見せてよい範囲は索引を引く段階で絞り切り、生成側には絞り込んだ結果しか渡さない。異動や退職で権限が変わったときに文書側の識別子を更新する経路も、作る前に決めておきます。

更新の経路については、手引きに実務的な作りが示されています。文書の全体を入れ直すのではなく、識別子の欄だけを後から書き換える操作が用意されており、資料の本文を再度取り込まずに権限を差し替えられます。組織変更で数千件の権限が一斉に変わる場面を想定すると、この操作を前提に設計しておくかどうかで作業量が大きく変わります。

既存の全文検索のままで足りる4つの場面

何も足さない判断ができる条件を並べます。4つすべてに当てはまるなら、置き場を増やす必要はありません。まず設定を詰めることをおすすめします。

• 探し方の主役が語である。型番、規程番号、製品名、人名、日付で引くことが多い
• 塊の数が数百万まで。文書数で言えば数万から十数万の規模
• 応答は数百ミリ秒でよい。人が画面で待つ用途であり、機械が連続で叩く用途ではない
• 資料の入れ替えが月次から週次。毎日全件が入れ替わるわけではない

この条件で足りるのに置き場を増やすと、得られるものより失うもののほうが大きくなります。増えるのは検索の質ではなく、運用する対象の数です。既存の全文検索でも、同義語の辞書を整え、絞り込みの軸を足し、よく使われる語の言い換えを登録すれば、体感は大きく変わります。

実際に多いのは、探せない原因が置き場ではなく資料の側にある場合です。タイトルが「20260401_資料v3」で中身が推測できない、同じ規程が3世代分残っている、最新版がどれか分からない。この状態で置き場を替えても、返ってくるものは変わりません。

専用の保存先が要る3つの条件

逆に、専用を建てる根拠になる条件は3つに絞れます。移す判断の基準として公表されているものと、実務で見る形はほぼ一致します。

• 塊の数が数千万から数十億。5,000万件が実務上の分かれ目として語られている
• 上位1%の遅さでも20ミリ秒未満を守る約束がある。機械が連続で叩く用途や、対話の途中で何度も引く用途
• 作り直しが頻繁で、古い版が溜まって膨らむ。毎日入れ替えるような使い方

3つのどれにも当たらないなら、建てません。ここを曖昧にしたまま「将来のため」で建てると、使われない性能のために毎月の費用と当番を払い続けることになります。将来必要になったときに移せばよく、移す作業は数の並びを作り直すだけなので、初回の構築ほど重くはありません。

なお2番目の条件は、応答時間の約束を実際に持っているかどうかで判断します。「速いほうがよい」は約束ではありません。何ミリ秒を、何パーセントの問い合わせで守るのかを書けるなら本物の条件です。書けないなら、まだその条件は存在していません。

両方を併せる形は3通り

併用と言っても実装は分かれます。3通りあり、必要な部品の数が違います。

形	やり方	向く場面
語で絞ってから意味で並べる	先に語の条件で候補を狭め、その中で近い順に並べる	部署や期間で必ず絞る運用
両方を引いて順位を束ねる	語と意味を別々に引き、順位の逆数を足し合わせる	問いの種類が混ざる社内検索
広く取って上位だけ並べ直す	粗く数十件取り、上位のみ別の仕組みで再評価する	答えの質を最優先する用途

多くの社内検索では2番目が既定です。問いの種類を利用者が選んでくれないので、どちらの引き方でも上位に来たものを前に出す形がいちばん外しません。1番目は絞り込みの条件が確実に効く運用向けで、前の節で見た「結果が静かに減る」問題に注意が要ります。

注意点は運用の重さです。語の側と意味の側を別の製品で持つと、索引の更新も監視も障害対応も2系統になります。同じ資料の反映がずれ、片方だけ古い状態が生まれます。1つの製品の中で両方を持てるなら、まずそれを選ぶのが実務的です。

自前で建てるか、外の仕組みを借りるか

建てると決めた場合の次の分岐です。判断材料は3つあります。外に出せない資料があるか、記憶領域と計算資源の費用を継続して払えるか、当番を置けるか。1つ目で決まる案件が最も多いので、ここから確認します。

持ち続ける費用の内訳は、計算資源、記憶領域、索引の作り直し、監視、そして当番の人件費です。提供側の整理では、中小規模なら既存のデータベースに寄せることで持ち続ける費用が4割から6割下がるとされています。これは提供側の主張として読む数字ですが、運用する対象が2つから1つに減る効果は確かに大きいのは実感と合います。

外の仕組みを借りる場合に確かめる項目は、保存される地域、削除の依頼から実際に消えるまでの期間、そして自社の資料が提供側の学習に使われないことの明記です。3つとも契約書か公開文書に書かれているはずのもので、口頭の確認では足りません。

自前で建てる場合に見落とされるのは、当番の設計です。索引は放っておくと劣化します。削除した文書の跡が残る、更新の反映が止まる、作り直しの途中で失敗する。これらに気づく仕組みと、気づいた人が直せる状態を作れないなら、建てても持ちません。運用の人員が1人しかいない案件では、既存側に寄せるか外の仕組みを借りるほうが現実的です。

決める手順：2週間で1つ作って比べる

以上を、着手前に踏む順番として並べます。関係者3人で、実働は2週間ほどです。順番を飛ばすと、たいてい規模の見積りだけで数週間が溶けます。

やってはいけない選び方

最後に、事故になりやすい進め方を並べます。どれも実際に見る形です。

• 性能の比較記事の数字だけで選ぶ。測っている条件が自社の件数と絞り込みの形と違う
• 意味で探す仕組みに全部を置き換える。型番や規程番号で引けていた検索が落ちる
• 将来の件数を10倍で見積もって専用を建てる。使われない性能に毎月払い続けることになる
• 権限の設計を後回しにする。全員同じ権限で作ると、直すときに索引の作り直しになる
• 見せてよい資料かどうかをAIに判断させる。判断が揺れ、根拠も残らない
• 語の側と意味の側を別の製品で持ち、更新の経路を1本にしない。片方だけ古い状態が生まれる
• 探せない原因を確かめずに置き場を替える。原因が資料の名前や重複なら、置き場を替えても変わらない

• 比較は必ず自社の問い50件で行う。汎用の評価用データで良い成績が出ても、社内文書では順位が変わる
• 上位5件を人が読んで採点する枠を、選定の工程に必ず入れる。指標だけでは実用の可否が判断できない
• 候補の製品名ではなく、置き方（既存に足す／別に建てる）で先に絞ると議論が短くなる

よくある質問

結局、専用の保存先は要るのですか

多くの社内文書では要りません。判断は3条件で、塊の数が数千万を超えるか、上位1%の遅さでも数十ミリ秒を守る約束があるか、毎日のように作り直すか。どれにも当たらなければ、いま使っている関係データベースに拡張機能を入れる形か、クラウドの検索サービスの機能で足ります。10万文書を抱えていても塊は100万から300万で、分かれ目とされる5,000万件の何十分の一です。

意味で探す仕組みを入れれば、社内検索の不満は解消しますか

しません。2023年に公表された検証では、語そのものを探す問いで意味の近さの成績は11.7、語の一致は79.2でした。置き換えると、いま拾えている型番や規程番号の検索が落ちます。また探せない原因が資料の側にある場合、置き場を替えても結果は変わりません。タイトルから中身が分からない、同じ規程の古い世代が残っている、最新版が特定できないという状態は、先に片付ける対象です。

既存のデータベースに機能を足す形で、性能は足りますか

規模次第です。公表されている整理では、5,000万件未満なら本番運用に耐えるとされています。ただし1,000万件を超えたあたりから記憶領域の設計が中心課題になり、応答が50ミリ秒から800ミリ秒に伸びるという観測もあります。1,000万件が見えてきたら、量子化や区画分けの検討を始める合図と捉えてください。

権限の設定でいちばん間に合わないのは、どこですか

後から権限の単位を変えることです。部署単位で作ったあとに案件単位にしたい、という変更は、文書ごとの識別子の付け直しと索引の作り直しになります。着手前に単位を確定させてください。もう1つは、等号を並べる書き方のまま所属集団が数百になり、応答が何秒も遅くなる形です。専用の絞り込み関数を使えば1秒未満で返ります。

答えが薄いとき、まずどこを見ればよいですか

返ってきた件数を見ます。絞り込みは索引を引いたあとに掛かるので、10件を求めても絞り込みが9件を落とせば1件しか返りません。探索の幅の既定が40で、9割が対象外になる条件では約4件です。エラーは出ないので、件数を記録していないと気づけません。件数が減っていたら、足りなければ索引をさらに辿る設定を確認してください。

まとめ

ベクトルデータベースは、意味の近いものを速く取り出すための置き場です。必須の部品ではありません。意味で探す機能は既存のデータベースや検索製品に入ったので、判断は「専用か否か」ではなく「どこに置くか」に変わりました。探し方と置き場を分けて考えるところから始めてください。

探し方については、置き換えではなく併用が答えです。2023年に公表された検証で、語そのものを探す問いは語の一致が79.2、意味の近さが11.7。両方を引いて順位を束ねると全体が48.4、上位を並べ直すと60.1になりました。語と意味は競合ではなく別の道具だという構造を、設計の前提に置きます。

置き場については、数で決められます。1件が索引込みで20から25キロバイト。100万件で数十ギガバイト、1億件で600ギガバイト超。分かれ目として語られるのは5,000万件で、10万文書を抱える会社でも塊は100万から300万です。多くの案件は既存側に機能を足す形で足ります。

そして選定の難所は速さではなく権限でした。文書ごとに閲覧できる集団の識別子を持たせ、索引を引く段階で絞り切る。識別子は認証ではないので、誰の権限で引いているかを渡す責任は呼び出す側にあります。見せてよいかどうかの判断をAIに任せず、渡す前に絞り込みで確定させる。ここを着手前に決めておけば、後の作り直しはほとんど避けられます。自社の塊の数を数え、実際の問い50件を集めるところから始めてください。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。