ベクトルデータベース（Vector database）

「ベクトルデータベース（Vector database）」

データ活用やDX成功に必要な考え方を、各種キーワードの解説で理解できる用語解説集です。
今回は、現在大変に注目されている生成AIやディープラーニングの活用における、技術的なポイントについて考えてみましょう。

ベクトルデータベース（Vector database）とは

ベクトルデータベース（Vector database）とは、ニューラルネットワーク一般において利用される「ベクトル化されたデータ」を取り扱うデータ基盤のことです。ベクトルストア（Vector store）と呼ばれることもあります。
ニューラルネットワークは数値を入力し数値を出力するため、外部からデータを入力して利用するためには、そのデータをベクトル化（数値化）する必要があります。多数のデータを利用する際にはベクトル化した多数のデータを扱うことになります。
生成AIもニューラルネットワークで実現されていることから、ベクトルデータベースはRAGの実現などでも利用されることがあります。

>参考：
⇒ ベクトル化 / エンベディング（Embedding）｜用語集

「ベクトル化したデータ」を活用するデータ基盤が必要

執筆現在、ChatGPTなどの生成AIが大変な話題となっています。ベクトルデータベースは、生成AIの活用あるいはニューラルネットワークの活用一般において有用な技術として注目されています。

詳細なことは「ベクトル化」の記事を参照いただきたいのですが、ともかくも、生成AIにデータを入力して処理をさせたいなら、そのデータをベクトル化する必要があります。ニューラルネットワーク（ディープラーニングもニューラルネットワークの一種です）は、数値を入力として受け取り数値を出力するからです。

詳しくはこちら：
⇒ ベクトル化 / エンベディング（Embedding）｜用語集

自社が持っている様々なデータを生成AIで活用したいのであれば、（大雑把な説明としては）それらデータをベクトル化して数値データに変換する必要があります。自社の持つ様々なデータの利活用に取り組むなら、ベクトル化した大量のデータを活用することが必要になってきます。

一般のデータベースが沢山のデータのスムーズな利活用を可能にするように、ベクトル化したデータをスムーズに活用するために作られているデータベースが、ベクトルデータベースです。

一般のデータベースとの違い

RDBなどの広く使われている一般のデータベースでも数値を取り扱うことはできます。ベクトルデータとは要するに「数値の集まり」ですから、数値を「配列型」として記録すれば、一般的に利用されているデータベースにも格納して利用することができます。つまり、ベクトル化したデータそのものは従来のデータベースにも格納はできます。

ベクトルデータベースが従来のデータベースと異なるのは、生成AIなどのニューラルネットワークでの利用にあわせた機能が整備されている点です。例えば多くのベクトルデータベースには、一般のデータベースには存在しないことが多い「ベクトルの類似度を計算して検索などの処理を行う機能」がついています。

一般のデータベースの利用例：従業員データベースから、所属支社が大阪で所属部署が営業部のデータを検索してほしい
ベクトルデータベースの利用例：このベクトルと類似度が近いベクトルを近い順に10検索して出力してほしい

「類似度が近いデータを探す」処理は一般のデータベースでもSQLによって実現できなくはないのですが、テーブル全体のスキャンが必要になってしまうことが多いなど処理が効率的に実現できなかったり、作りこみが煩雑になったりするため、既存のデータベースではうまく処理が出来ません。

そこで、生成AIやニューラルネットワークの利用で必要になりがちなベクトルデータの処理能力が最初から作りこまれ、効率的に実行できるようなデータベースが作られており、それがベクトルデータベースです。

「類似度」とはどういうものか

ベクトルデータベースは「意味が類似したものを探すことができる」というような謳い文句（煽り文句）で紹介されることがあります。なので、類似度を計算する処理として「難しい処理」をしているように思うかもしれません。しかしながらほとんどの場合には、ベクトルデータに対するシンプルな演算をしているだけです。

ベクトルデータベースによって類似度の計算方法として実装されているものは異なりますが、代表的（で解りやすいもの）を紹介します。ちなみに、詳細を理解しなくても特に支障はないので、数式は嫌だな、と思っても読み流してください。

コサイン距離（コサイン類似度）

高校の数学で習った線形代数のベクトルを思い浮かべて欲しいのですが、コサイン距離（コサイン類似度）とは「ベクトルが向いている方向が同じかどうか」を計算します。利用されることが多い類似度です。

コサイン距離 = （ベクトルAとBの内積）÷ （ベクトルAの大きさ×ベクトルBの大きさ）

ベクトルを矢印と考え、矢印の大きさを無視して向いている方向だけを考えます。そして二つのベクトルが全く同じ方向を向いている場合には最大値の「1」になり、ベクトルが互いに反対方向を向いている場合には最小値の「-1」になります。

コサイン距離を用いて類似度が近いものを探す場合には、「このベクトルと近い方向を向いているベクトルベスト10を見つけてください」を計算していることになります。

内積（ドット積）

内積そのものを類似度として計算することもあります。計算も簡単になります。

内積距離 = （ベクトルAとBの内積）

格納されているベクトルが大きさ1になるよう正規化（事前に調整）されている場合には、内積を計算するだけでコサイン類似度と同じ計算結果になります。

ユークリッド距離

学校でならった「空間上での距離の計算」を類似度として計算することもあります。ちょっとわかりにくい表記ですみませんが「平面上の距離」とか「空間内の距離」の式と同じものです。

ユークリッド距離 = √（（A1 – B1）の二乗＋（A2– B2）の二乗＋ …）

学校でならったおなじみの式ではありますが、ここまで挙げたものよりもちょっと計算が複雑で非効率なこともわかります。ユークリッド距離を用いて類似度が近いものを探す場合には、「このベクトルに空間的に近い点にあるベクトルベスト10を見つけてください」を計算していることになります。

「コサイン距離」「内積」「ユークリッド距離」には多くのベクトルデータベースが対応しています。

マンハッタン距離

それ以外にも「簡単な計算」で求めることができる距離（類似度）があることを紹介します。

マンハッタン距離 = |A1 – B1|＋|A2– B2|＋ …

成分ごとの差（絶対値）を足し合わせただけのものです。ニューヨークのマンハッタンとか京都の平安京のような、東西南北だけに碁盤の目状の道路があって斜め移動できない都市での移動距離を計算していることになるので、マンハッタン距離と呼ばれます。計算は簡単にでき、ユークリッド距離ともやや似た類似度の判定をします。

ハミング距離

もっと計算を簡単にできるものもあります。ベクトルの各成分の値が一致しているなら「1」、一致していないなら「0」として合計し、つまり一致している成分の数を類似度とするものです。

ハミング距離 = 一致している成分の数

ベクトルの値が0と1の二値だけの場合には、一致しているかどうかの計算（XORするだけ）は非常に簡単になります。

他にも、様々な類似度の計算方法があります。

これら計算でなぜ、意味の類似度などを計算したことになるのか

ベクトルデータベースは、「意味が近いテキストを探し出せるすごい技術」であるとか、「レコメンデーションエンジンにも使える」とか、凄いことができるものとして紹介されていることがあります。しかし、説明した通りに実際には内積を計算している程度のことしかしていません。

不思議なことを実現しているのは「ベクトル化」

実際に行っている単純な計算と、「似た意味のテキストデータを探せる」ような話にはずいぶん印象の落差があるかもしれません。実は、ベクトルデータベース自体がすごいことをしているわけではなくて、「元データをベクトル化（数値化）する処理」が、すごいことをしています。例えば「意味の近いテキストデータを探し出せる」なら、

ベクトル化：テキストデータ→ベクトル（数値）
- 入力されたテキストデータを「似た意味のテキストは、近いコサイン距離になる」ようなベクトルデータに変換する
ベクトルデータベース：多数のベクトルデータを格納する
- 格納されている多数のベクトルデータから、コサイン距離が近いベクトルデータを高速に見つけ出すことができる

つまり、ベクトルデータベースではなくて、ベクトル化（数値化）がすごいことをしているのですね。「内積計算をするだけで意味の類似度が計算できるような不思議な数字」に変換しているわけです。ベクトルデータベースは、変換して作ったベクトルデータをスムーズに活用できるデータ基盤だと言えます。

「類似している」を計算できる数字にする例

では、そのベクトル化で「意味」はどのように取り扱われているのでしょうか。Googleが作った「単語の意味」をベクトル化（数値化）する「Word2Vec」を例として紹介します。

単語の意味は「その単語の前後に出現する単語の分布」で決まるという仮説のもと、「その前後で出現する単語が似ているなら、意味も似ている」という基準で、大量のテキストデータで学習させたものがWord2Vecです。なので、人間と同じように意味を理解しているわけではなく、そういう仮説に基づいた数値への変換をしているだけです。

入力：単語
出力：ベクトルデータ
ベクトルデータの性質：「その前後で出現する単語が似ている」単語ほど、コサイン距離が「1」に近い値を、似ていないほどに「-1」に近い値を出力する
Word2Vec：大量のテキストデータを訓練データとして、入力を与えられると「上記のような性質を満たす出力」を得られるようトレーニングされたニューラルネットワーク

ニューラルネットワークなので、内部的にどういうロジックでどういう処理がなされて変換されているのか人間には解りません。また出力についても、「出力されるベクトルデータは確かに指定した性質を持っている」が、出力されるベクトルの個別の数値自体が何を意味しているのか人には理解できず、謎の数値が大量に並んでいる感じになります。

ほとんどのベクトル化処理では、同じように解らない処理で解らないデータが出力されてきます。しかし、コサイン距離を計算すると、意味が近いかどうか判断できるなど「指定した性質を持つ」データになっていて、ベクトルデータベースで便利に利用することができます。

他のベクトル化の応用例

RAGの実現では「類似した意味のテキストデータを探せる」機能が利用されています。これも同じように、「何らかの仮説」でテキスト（文書）の意味の類似度を定義し、それに基づいて「似た類似度のものは近い距離のベクトルデータに変換する」ようにトレーニングして作ったベクトル化処理が活用されています。

「レコメンデーションシステムを作れる」という話を聞くこともあると思います。例えば実際の購買データを基にして学習させて「商品AとＢとＣを買った」を買った人が「商品D」を買う可能性が高いなら距離が近く、「商品Ｅ」を買う可能性が低いなら距離は遠くなるように作ってあるベクトル化処理により実現しています。

他にも「類似した画像を見つけられる」など、いろいろなことができるという話があると思いますが、つまり、

「やりたいこと」が「コサイン距離やユークリッド距離などの計算で実現できる」ようなベクトル化処理を「見つけてくる」か「自分で作る」
処理したいデータを「そのベクトル化処理」でベクトル化する
ベクトル化したデータをベクトルデータベースに格納すると、コサイン距離やユークリッド距離などにより類似したデータを探せるようになる

言い換えれば、「ニーズごとに用いるべきベクトル化処理は異なる」ということになります。

非常に多くのベクトルデータベースが開発されている

現在、世界中で非常に多くのベクトルデータベースが開発されています、執筆時点ではPineconeという製品が良く知られているように思いますが、日々新しい特徴をもった新しい製品が登場している状況で、例えばGAFA各社においてもそれぞれ製品開発やサービス提供が行われている状況です。

また今後、現在主流である「コサイン距離で類似度を計算する」ような処理とは異なる「ベクトルデータを計算したいニーズ」が出てきた場合には、ベクトルデータベースが備える機能も現在とは大きく変わり、世間で広く使われる製品も今とは違うものになるかもしれません。

さらには「既存のデータベース」をベースにベクトルデータを利用することもできるようになりつつあります。例えば広く使われているPostgreSQLに「pgvector」という拡張機能を導入することでベクトルデータベースとして利用することができるなど、従来のデータベースによる対応も進みつつあります。

既存のデータベース、例えばPostgreSQLをベクトルデータベースとしても利用する場合には、通常のRDBとしての利用もできますし、同じように本来のRDBから拡張された機能が整備されているので、NoSQLとして利用することや地理空間データを処理させることなど、様々な使い方を組み合わせることもできる利便性もあります。

大量のベクトル化データを利用するなど、高い性能が必要な場合には専用製品を利用して十分な性能を発揮できるようする、そうではない場合には使い慣れた既存のデータベースをベースにして利用するなど、用途や利用規模にあわせての利用判断も必要になるはずです。

ベクトルデータベースの活用で必要な「データ利用環境」の整備

最後に「データを活用してビジネスでの成果につなげる」側から考えてみましょう。

ベクトルデータベースは、導入すればそれだけで凄いことが起こる不思議なものではありません。自分たちが行いたいことにあわせて、データを用意し、用途にあわせてデータのベクトル化を行って、適切なベクトルデータベースに投入して活用する必要があります。

ベクトル化を活用する場合、「何をしたいか」にあわせて、利用するベクトル化処理（やベクトルデータベース）を選ぶ必要があることも紹介しました。さらには、そのために必要になるデータを取ってくる必要もあります。

多種多様なデータがある
- 表形式のデータ、テキストデータ、画像データ、動画データなど
様々な場所に格納されている
- Excelファイルで業務の現場PCの内部にある
- データベース（RDB）に正規化されて格納されている
- メインフレーム内の固定長データ
- 社内の共有ファイルサーバにファイルとして散在している
- クラウド上のオブジェクトストレージをデータレイクとして、とりあえず投げ込まれている

このように現実のデータは多種多様な形で存在しており、社内に散在するデータから必要なデータを取ってくる必要があり、さらには利用するベクトル化サービスにあわせて適切な前処理をしないとベクトル化できません。

ビジネス側からのデータ利活用ニーズも多種多様であり、ベクトル化を用いれば実現できるものもあれば、そうではないもの（例：BIツールで売り上げを可視化したい）もありますし、ベクトル化を用いるものと用いないものを組み合わせて利用しないといけないこともあるでしょう。ベクトルデータベースだけではなく、データ活用全体から総合的に考える必要があります。

技術そのものも日々変化します。少し前まではベクトルデータの活用の話はありませんでしたし、ベクトル化サービスについてもベクトルデータベースについても、日々新しいものが作られ続けています。

つまりデータも、利用ニーズも、技術も変化し続けます。ビジネスで成果を出すためには、これら変化し続ける多くの要素を必要に応じてうまく組み合わせて利用できる、変わり続けられる「データ利用環境」を整備する必要があります。

「RAGの沼」（ベクトルデータベース活用の現実）

執筆時点において、「データをベクトル化し、ベクトルデータベースの活用に取り組む」代表的な状況とは、「RAG（検索拡張生成）」を実現する手段としての利用ではないかと思います。

⇒ 検索拡張生成（RAG：Retrieval Augmented Generation）｜用語集 |

RAGの取り組みにおいてベクトルデータベースを利用する際にも、「データ利用環境の整備」の観点がとても重要になります。

RAG（検索拡張生成）

生成AIがブームになり、自社でも活用を進めたいと思っても具体的な活用方法が「アイディア出し支援」や「事務作業の補助」程度になりがちだったりします。どうしてそうなってしまうのでしょう。その原因は、生成AIに聞いて答えてくれるのは「一般的知識による回答」であり、自社のビジネスや事情などを考慮したものではないことが大きいと思います。

そこで生成AIに、「ユーザが入力したテキスト」と併せて「それに関連する社内ドキュメント」をナレッジとして与えて回答させることで、生成AIに自社の業務などを踏まえた回答をさせる取り組みとして大変に期待されているのが「RAG（検索拡張生成）」です。

検索：
- ユーザが入力したテキストを元にして、ベクトルデータベースを検索する
- 検索結果から、ユーザの入力（質問）に関連する社内ドキュメントを取得する
拡張生成：
- ユーザ入力に加えて、検索されたドキュメントの内容をIn-Context Learningにより生成AI（LLM）に入力し、応答を得る

さて、これを実現するためには「多種多様なデータを前加工してベクトル化し、ベクトルデータベースに格納しておく」ことが必要となります。

社内のあちこちに散在している多種多様なドキュメントやデータソースを読み取る
それを「適切に前処理」し「適切にベクトル化」してベクトルデータベースに蓄える
ベクトルデータベースを検索することで関連するドキュメントを探せるようにする

残念なことに、RAGは「上記のような仕組みを素朴に実装しただけ」では十分な性能（回答精度）が出ないことがよくあるのが現実のようです。大きな期待をしてRAGシステムを構築したのに実用的に利用することができないというのは大変に困った状況です。

そうなると「回答精度を改善する」ため、「どのように前処理するか」「どのようにベクトル化するか」などについて、見通しが立たない泥臭い試行錯誤を延々と続けざるを得なくなることがあります。そのような大変な状況のことを「RAGの沼」と呼ばれるようになってきました。

「RAGの沼」を戦うために必要な「つなぐ」技術

そもそもベクトルデータベースとはベクトルデータ（数値）を溜め、内積やコサイン距離などを計算するだけのものです。よってRAGに限らず、「ベクトルデータベースがその可能性を発揮して活躍できるかどうか」は、その周辺のデータ利用環境の整備ができるかにかかっているはずです。

しかも「RAGの沼」のように、成果を出すためには「泥臭い試行錯誤を繰り返すこと」が必要になることがあります。そうなるとデータ利用環境の整備のみならず、「多種多様なデータソースに対して、繰り返し試行錯誤ができるデータ利用環境の整備」が重要になります。

また、成果を出すためにはビジネスがよくわかっている現場側が関与することが望ましいことが多く、そうなると非エンジニアでも使いこなしやすい「ノーコードで活用できるデータ利用環境」であることも望まれることになります。

「つなぐ」技術を活用ください

多種多様なシステムやクラウド上にあるデータに連携し、必要に応じでデータを読み取り、加工し、転送処理を行い、データ環境を整備する取り組みを、「GUIだけ」で効率的に開発できる手段が存在します。「EAI」や「ETL」、「iPaaS」と呼ばれる、「DataSpider」や「HULFT Square」などの「つなぐ」技術です。

GUIだけで利用できる

通常のプログラミングのようにコードを書く必要がありません。GUI上でアイコンを配置し設定をすることで、多種多様なシステムやデータ、クラウドサービスへの連携処理を実現できます。

「GUIで開発できる」ことは長所でもある

GUIだけでのノーコード開発は、本格的なプログラミングに対して簡易で妥協的な印象を受けるかもしれません。しかしながら、GUIだけで開発できることは「業務の現場の担当者が自分たち自身で主体的にクラウド連携に取り組む」ことを可能にします。ビジネスのことを一番良くわかっているのは現場の担当者です。

本格的処理を実装できる

「GUIだけで開発できる」ことを謳っている製品は沢山ありますが、そういう製品に簡易で悪い印象を持っている人もおられるかもしれません。

確かに、「簡単に作れるが簡易なことしかできない」「本格的処理を実行しようとしたら処理できずに落ちてしまった」「業務を支えられるだけの高い信頼性や安定稼働能力がなくて大変なことになってしまった」ようなことは起こりがちです。

「DataSpider」や「HULFT Square」は、簡単に使うこともできますが本格的プログラミングと同等のレベルの処理の作りこみもできます。内部的にJavaに変換されて実行されるなど本格的プログラミングと同様の高い処理能力があり、長年にわたって企業ITを支えてきた実績もあります。「GUIだけ」の良さと、本格的能力の両方を兼ね備えています。

iPaaSなので自社運用不要

DataSpiderなら自社管理下のシステムでしっかりと運用できます。クラウドサービス（iPaaS）のHULFT Squareなら、このような「つなぐ」技術そのもの自体もクラウドサービスとして自社運用不要で利用でき、自社での導入やシステム運用の手間がなく利用できます。

関係するキーワード（さらに理解するために）

機械学習に関連したキーワード

生成AI/ChatGPTに関係するキーワード

データ連携やシステム連携に関係するキーワード

EAI
- システム間をデータ連携して「つなぐ」考え方で、様々なデータやシステムを自在につなぐ手段です。IT利活用をうまく進める考え方として、クラウド時代になるずっと前から、活躍してきた考え方です。
ETL
- 昨今盛んに取り組まれているデータ活用の取り組みでは、データの分析作業そのものではなく、オンプレミスからクラウドまで、あちこちに散在するデータを集めてくる作業や前処理が実作業の大半を占めます。そのような処理を効率的に実現する手段です。
iPaaS
- 様々なクラウドを外部のシステムやデータと、GUI上での操作だけで「つなぐ」クラウドサービスのことをiPaaSと呼びます。

「iPaaS」や「つなぐ」技術に興味がありますか？

オンプレミスにあるITシステムからクラウドサービスまで、様々なデータやシステムを自在に連携し、IT利活用をうまく成功させる製品を実際に試してみてください。

「つなぐ」ツールの決定版、データ連携ソフトウェア「DataSpider<」および、データ連携プラットフォーム「HULFT Square」

当社で開発販売しているデータ連携ツール「DataSpider」は長年の実績がある「つなぐ」ツールです。データ連携プラットフォーム「HULFT Square」はDataSpiderの技術を用いて開発された「つなぐ」クラウドサービスです。

通常のプログラミングのようにコードを書くこと無くGUIだけ（ノーコード）で開発できるので、自社のビジネスをよく理解している業務の現場が自ら活用に取り組めることも特徴です。

DataSpider / HULFT Squareの「つなぐ」技術を試してみてください：

簡易な連携ツールならば世の中に多くありますが、GUIだけで利用でき、プログラマではなくても十分に使える使いやすさをもちつつ、「高い開発生産性」「業務の基盤（プロフェッショナルユース）を担えるだけの本格的な性能」を備えています。

IT利活用の成功を妨げている「バラバラになったシステムやデータをつなぐ」問題をスムーズに解決することができます。無料体験版や、無償で実際使ってみることができるハンズオンも定期開催しておりますので、ぜひ一度お試しいただけますと幸いです。

無料製品紹介セミナーはこちら

「HULFT Square」で貴社のビジネスが変えられるか「PoC」をしてみませんか：

貴社のビジネスで「つなぐ」がどう活用できるのか、データ連携を用いた課題解決の実現可能性や得られる効果検証を行ってみませんか？

SaaSとのデータ連携を自動化したいが、その実現可能性を確認したい
データ利活用に向けて進めたいがシステム連携に課題がある
DXの実現に向けてデータ連携基盤の検討をしたい

PoCプログラム | HULFT Square