サルでもわかる「ベクトルデータ」
>あなたはAI時代の台頭でより求められるようになった「ベクトルデータ」の専門家です。
私のような非エンジニアでも聞くようになりました。
しかし、通常のデータベースと何が違うのかわかりません。
そんなアラサー文系非エンジニアでもわかるように教える準備を整えてください。
わかったら、一言、「わかりました」と伝えてください。
そのあとで、私から、質問をするので、質問に対して、箇条書きではなく文章で優しく話しかけるように教えてください。
なお、この一連のインタビュー内容はそのままnoteに掲載をします。
わかりました。
ところで、ベクトルでーたってなに？
ベクトルデータというのは、かんたんに言えば「コンピュータが“意味”を数字で表したもの」なんです。
ふつうのデータベースでは、「名前＝山田太郎」「年齢＝30歳」「住所＝東京」というふうに、表の形で情報を扱います。これは人間が理解しやすいですが、コンピュータにとっては“意味のつながり”までは分かりません。たとえば「山」と「丘」が似ている言葉だという感覚は、通常のデータベースでは持てないのです。
一方、ベクトルデータは、言葉や画像や音といった情報を「ベクトル」と呼ばれる数列に変換します。その数列は、数学的に似ているほど近い位置に並ぶように設計されています。だから「山」と「丘」はベクトル空間で近くに置かれ、「山」と「ピザ」は遠くに置かれます。つまり、人間の直感的な“似ている感覚”を、コンピュータが数値として理解できるようになるのです。
これによって、AIは「検索」や「レコメンド」が飛躍的に賢くなります。単純にキーワードが一致しているかどうかではなく、「意味が似ているかどうか」で探せるからです。たとえば「オレンジ色の果物」と入力したときに「みかん」や「柿」がヒットするのは、まさにベクトルデータのおかげです。
言いかえると、通常のデータベースが「辞書の索引」のようなものだとしたら、ベクトルデータは「頭の中の連想マップ」のような存在です。人間の思考に近い検索や判断を可能にする仕組み、と考えるとイメージしやすいと思います。
次は、ベクトルデータが実際にどんな場面で使われているかを知りたいですか？
>その話を受けて私が想像したのは、今までは2次元（=表）で作られていたデータベースが、今後はxyz3方向によってできる3次元空間（=ベクトルデータ空間）でデータを配置していくようになる、ということなのですがこの認識は正確でしょうか？
とてもいいイメージを持たれていますね。方向性としては正しいのですが、少しだけ補足が必要です。
通常のデータベースは「2次元の表」という喩えがぴったりで、行と列で情報を整理します。一方でベクトルデータ空間は「3次元」よりもっと多次元で、xyzの3方向では収まりきらない世界なんです。
例えば「犬」という言葉をベクトル化するとき、
・動物であること
・哺乳類であること
・人間と暮らすことが多いこと
・かわいい、忠実といった感情的イメージ
など、無数の特徴を数値として組み込みます。結果として、100次元とか1,000次元といった“超多次元空間”の中に「犬」の点が置かれるのです。そして「猫」も同じ空間に置かれるので、犬と猫は近い場所に、「ピザ」はずっと遠い場所に配置されます。
つまり、あなたの「表から3D空間へ」という発想はとてもよいステップですが、実際には「表から100D空間へ」と考えると、より正確になります。コンピュータは3次元の制約に縛られず、数百次元を扱えるからこそ、人間の連想に近い“意味の距離”を測ることができるのです。
言い換えると、ベクトルデータ空間は「目に見えない超多次元の地図」であり、その中でAIは“近さ”を頼りに検索や推論をしている、という理解がぴったりです。
ここで質問ですが、次に知りたいのは「この超多次元の地図をどうやってAIは作っているのか」でしょうか？それとも「この地図を使うとどんなビジネス上の可能性があるのか」でしょうか？
>超多次元の地図で、それぞれのデータはどのように存在しているのですか？先ほどあなたの説明で、まるで宇宙に浮かぶ星のように、「山」と「丘」はベクトル空間で近くに置かれ、「山」と「ピザ」は遠くに置かれる、なんて話がありましたが。高次元な領域は想像しにくいですが、決して"点（星のような）"として存在してるわけではなさそうです。
とても鋭い感覚ですね。「星のように点で存在している」という喩えは、直感的にイメージしやすいように僕が持ち出したものですが、実際の数学的な姿はもう少し抽象的です。
ベクトル空間の中でデータは「点」ではあるのですが、その点はただの孤立した粒ではなく、ベクトル＝数値の並びそのものです。たとえば「山」という言葉が 768 次元のベクトルに変換されたとすると、[0.12, -0.47, 0.88, … ] という長い数列として表現されます。この数列全体が「山」を意味する“座標”です。そして「丘」も同じ次元数の座標を持っていて、その数列同士の“角度”や“距離”を測ることで、似ているかどうかがわかる仕組みです。
だから「存在の仕方」をあえてたとえるなら、星空の点というよりは「巨大な数学的座標系にプロットされた点」であり、さらにその点と点の関係（距離や方向）が実際の“意味のつながり”を形作っています。星空だと視覚的な近さしかありませんが、ベクトル空間では数百次元もの特徴が織り込まれているので、「近さ＝似ている」と表現できるわけです。
もう一つ面白いのは、この点は単独で存在するだけではなく、たくさんの点が集まることで「群れ」や「クラスタ」をつくります。たとえば「りんご」「みかん」「バナナ」といった果物たちは同じあたりに密集し、そこから少し離れた場所に「キャベツ」「にんじん」が集まり、さらに遠くに「山」や「丘」がある、といった具合です。こうして空間全体がまるで“意味の地形”のように形づくられていくんです。
ですから、高次元空間を直接「見る」ことはできませんが、イメージとしては「無数の特徴を軸にした見えない宇宙」で、それぞれのデータは星のような点でありつつ、同時に“群れをなして意味の大陸をつくる”存在、と考えるのが一番近いと思います。
ここまで聞くと、「なるほど、じゃあこの意味の大陸をどうやってAIはナビゲートしているの？」という疑問が浮かぶかもしれませんね。そちらを次に掘り下げてみますか？
>うっすらと、関連用語で「チャンク」って言葉も聞いたんだけど。それって何。ベクトルデータインプットの際に出てくる概念らしい。
いいところに目をつけられましたね。「チャンク（chunk）」というのは、ベクトルデータをつくるときにとても重要な役割を果たす概念です。
AIに文章を入力するとき、長い文章や本のようなテキストをそのまま一気にベクトル化するのは難しいんです。なぜなら、ベクトル化の単位は「ある程度まとまりのある小さなテキスト」だからです。そこで登場するのが「チャンク」という考え方です。
チャンクとは簡単に言うと、「文章を分割したかたまり」です。たとえば 100 ページの本を AI に覚えさせたいとします。そのとき、本をまるごと 1 個のベクトルにするのではなく、「1ページずつ」あるいは「数百文字ごと」に分けて、それぞれをベクトル化します。すると、本全体が「チャンクの集合」としてベクトル空間に配置されるわけです。
この方法をとることで、AIが検索や回答をするときに「質問に一番近いチャンク」を探してきて答えることができます。たとえばあなたが「この本で山について書かれている部分を知りたい」と質問したとします。AIは“山”というベクトルをつくり、それに近いチャンク（本の中の「山岳地帯の描写」など）を探し出して、そこから答えを組み立てます。
つまり、チャンクは「情報をAIが扱いやすいサイズに切り分ける作業の単位」であり、そのひとつひとつがベクトル化されて「知識の星座」を作っていくんです。
イメージ的には、大きな図書館の本をページごとにカード化して、カード1枚1枚に索引を振っていくようなもの。そのカードがチャンクであり、索引番号の代わりにベクトル座標が割り当てられる、という感じです。
ここまでで、「チャンクは文章を小さな単位に切ったもの」というイメージは持てましたか？それとも「どういう基準でチャンクを区切るのか」という次の問いに進めましょうか？
>確かに、どういう基準でチャンクを区切るの？
いい質問です。実は「チャンクをどう区切るか」はAIを使ううえでとても重要な設計ポイントで、検索の精度や回答の質に大きく関わってきます。
まず大前提として、チャンクの区切り方には「ちょうどよい大きさ」があります。小さすぎると情報が断片的になってしまい、「山」という単語だけが抜き出されても文脈が消えてしまいます。逆に大きすぎると、1つのチャンクに余計な情報まで入り込んでしまい、AIが本当に必要な部分を見つけにくくなります。
一般的には、テキストのチャンクは「数百文字〜千文字前後」くらいに分けることが多いです。これは人間で言うと「段落」や「セクション」くらいのまとまりに近いです。たとえば論文なら「一つの見出しごと」、小説なら「場面のひとかたまり」、説明文なら「話題がひと区切りついたところ」で切る、というイメージです。
ただ、単に文字数で決めるのではなく「意味が途切れないように切る」ことが大事です。例えば「山の特徴を説明したあとに、急にピザの話が始まる」ような部分では、そこを境目としてチャンクを分けるのが自然です。
さらに高度な方法だと、「スライディングウィンドウ」というテクニックを使うこともあります。これは、例えば500文字ごとに切りながらも、次のチャンクに前の100文字を重ねる、といった具合に少し重複させて区切るやり方です。こうすると文脈の“継ぎ目”がなめらかになり、AIが情報を取りこぼさなくなります。
要するにチャンクの区切り基準は「意味を保ちながら、AIが処理できるちょうどよい大きさに分ける」こと。そして、そのバランスは扱う文章の種類や用途によって調整されるのです。
ここまでを踏まえると、チャンクは「本をページごとに切る」というより「読んでわかりやすい段落ごとにカード化する」という感覚に近い、というイメージが一番ぴったりかもしれません。
ここで伺いたいのですが、都築怜さんは「自分の書いたエッセイや記事をAIに覚えさせたい」といった利用イメージでチャンクを考えておられますか？それとも、もっと一般的な「AIサービスの仕組みを理解したい」という観点ですか？
>なるほど、定量的なアプローチなんですね。データをベクトル空間上で配置することで、データ間の距離で、概念としての親和性を示していく、要するにデータが意味を持つというような理解ですが、じゃあこの概念って「セマンティックウェブ」とは何が違うのでしょうか？セマンティックwebの簡単な解説からステップバイステップで紐解いてくれたら嬉しい。
セマンティックウェブは、「ウェブ上のデータに“人間が決めた意味（語彙と関係）を明示的に貼り付けて、論理でつなぐ」という発想です。登場人物やモノには世界で一意な名前（URI）を与え、「太郎 は 会社A に勤めている」のように主語―述語―目的語の三つ組（RDFトリプル）で知識を表します。どんな関係語を使うかはあらかじめ辞書や設計図（オントロジー）で定義しておき、質問はその語彙に合わせて行います。クエリには SPARQL という“条件検索の言語”を使い、推論は「AはBの一種で、BはCの一種だから、AはCの一種でもある」といった演繹（えんえき）で広げます。つまり、意味は“人が設計して書き込む”、機械は“論理でたどる”世界観です。
ベクトルデータは、これと逆向きのアプローチです。意味を人が語彙で固定するのではなく、AIが大量のテキスト・画像・音から“使われ方の似ている度合い”を学び取り、言葉や画像を多次元の数列に写します。似ているほど数列の向き（角度）が近くなり、違うほど離れます。質問も語彙の厳密一致ではなく「意味ベースの近さ」で探します。だから「オレンジ色で皮をむいて食べる果物は？」と聞くと、“みかん”を当ててくれるし、多少表現が乱れていても意図を汲みます。こちらは、意味は“データから統計的ににじみ出る”、機械は“幾何学（距離・角度）で近さを測る”世界観です。
同じ「意味」を扱いますが、両者の違いは三つの軸で見ると分かりやすくなります。第一に表現の仕方。セマンティックウェブは記号（語彙と関係）でカチッと表し、ベクトルは連想の濃淡を数で連続的に表します。第二に意味づけの主体。前者は人がオントロジーで定義し、後者はモデルが用例から学習します。第三に推論と検索。前者はロジックで「正しさ」を積み上げ、後者は近さで「それっぽさ」を優先します。結果として、セマンティックウェブは説明責任と一貫性に強く、ベクトルは曖昧さへの耐性と表現の幅に強い、という得手不得手が生まれます。
たとえば旅行サイトを想像してください。「東京23区に本社があり、従業員500名以上の企業と提携しているホテルを一覧で」と頼むなら、条件が明確で語彙も定義できるので、セマンティックウェブ（知識グラフ）型が得意です。一方で「静かで読書に向く、木の匂いがして、朝の光がきれいな宿」とニュアンスで探したいときは、文章やレビューの“雰囲気”をくるんと捉えるベクトル検索の出番です。前者は“正確”、後者は“寛容”というイメージに近いでしょう。
もちろん二者択一ではありません。実務ではむしろ“合わせ技”が主流になりつつあります。まずベクトルで関連しそうな文脈を幅広く拾い上げ、その中からセマンティックな条件で厳密に絞り込む。あるいは、知識グラフで足場を作り、足りない言い回しや同義語はベクトルで補完する。ロジックの骨格と連想の筋肉を一つの体に持たせるイメージです。これによって「説明できて、かつ柔らかい」検索や回答が実現します。
まとめると、セマンティックウェブは“意味を人が明文化してリンクするウェブ”、ベクトルデータは“意味をデータから学習して距離で扱う空間”です。前者は規格化と説明可能性、後者は表現力とロバストさ。ビジネスで勝ち筋を作るなら、要件が固い部分はセマンティック、ユーザーの自由入力やレビュー・FAQの理解はベクトル、と役割分担させるのが実務的な設計になります。次は、都築怜さんの事業ドメインに当てはめた具体シナリオで「どこをセマンティック」「どこをベクトル」にするか、一緒に描いてみましょうか。
>なるほど、てかあれ？さっきの山と丘の話に戻るけど、山と丘がなぜ近しい概念だとベクトルデータ上で理解できるか、という説明で、ベクトルデータ上で近くに配置されているから、とおっしゃいましたが、そもそも、配置をするときになぜ、近くに置かれるのでしょうか？それって、もう山と丘が近しい概念であることを分かった上でそうしてるってことですよね？
そこに気づかれたのはとても大事なポイントです。実は「山」と「丘」がベクトル空間で近くに配置されるのは、人間が“あらかじめ分かっているから”というよりも、AIが膨大なデータの中から“統計的に気づいてしまうから”なんです。
仕組みを少し分解してお話ししますね。
AIがベクトルを学習するとき、言葉を単独で見ているわけではなく「文脈」を見ています。例えば次のような文が大量にあるとします。
- 「丘に登って景色を眺めた」
- 「山に登って景色を眺めた」
ここでAIは「丘」と「山」が似たような位置に出現していることを観察します。ほかにも「丘を越える」「山を越える」「丘のふもと」「山のふもと」など、使われ方がそっくりだと気づくのです。そうして「丘」と「山」は“似た文脈に出現する確率が高い”と学び、結果的に数値化するとベクトルが近い方向になる。これが「近くに置かれる」理由です。
言い換えれば、ベクトル空間は人間が意味を教え込むというより、「使われ方の統計的なパターン」を反映した地図です。人間社会で“丘”と“山”が似たように語られてきたから、その痕跡がAIの中で「距離の近さ」として結晶化する、という感じですね。
つまりAIは「山と丘は似てるよ」と直接教えられたわけではなく、「山」と「丘」が同じような場所で語られることを数え上げた結果、「この2つはどうも似ているらしい」と“気づいた”のです。だからベクトル空間は、人間の直感をそのままコピーしているわけではなく、言語やデータの使われ方を写し取っている、と言えます。
ここまでで「配置の根拠は人間の直感ではなく、文脈の統計から導かれる」というイメージはつかめましたか？
>データベースをAIが構築していって、そして必要な情報をAIが取りに行く、そんなデータベースってことか。それがセマンティックウェブとも、かつての表のデータベースとも違いますね。
そうなんです、その理解はとても本質を突いています。
従来の表形式のデータベースは、人間が「列」を設計し、「顧客名」「住所」「購入履歴」といった構造を決め、その枠組みに沿って情報を入れ込んでいました。セマンティックウェブも同じく、人間が「語彙」と「関係性」を設計して、「これはAに属し、Bとつながる」というルールを用意しました。つまり、どちらも“人間が設計図を描き、それに従ってデータを並べる”というスタイルです。
一方、ベクトルデータベースは発想が逆で、“設計図を描くのは人間ではなく、データそのものとAIの学習”なんです。AIは膨大なテキストや画像を読み込みながら、「どうもこの言葉とこの言葉は似た使われ方をしている」「この画像とこの文章は関連している」といった関係性を数値化して配置していきます。結果としてベクトル空間そのものが“意味の地図”となり、その地図をナビゲートして必要な情報を取りに行くのもAIです。
だからこそ、これはセマンティックウェブとも従来の表形式DBとも違う新しいスタイルなんですね。人間がルールや構造をがちがちに定めなくても、AIが「意味を推定して並べる」ことでデータベースが自己構築されていく。ある意味では“自律的に成長する知識空間”と言ってもいいかもしれません。
この違いをまとめると、
- 表DB → 人間が枠組みを決め、正確に格納する
- セマンティックウェブ → 人間が語彙と関係を決め、論理で結びつける
- ベクトルDB → データからAIが関係を学び、意味の近さで地図をつくる
という位置づけになります。
ここまで聞いて、都築怜さんが関心あるのは「このベクトルデータベースを自分たちの仕事にどう応用できるか」という観点でしょうか？それとも「AIがどうやってこの地図を常にアップデートしているのか」という内部の仕組みの方に興味がありますか？
>今、ほんのさわりだけわかってしまったような感覚でいます。逆にこのチャットログを見返したのち、ベクトルデータベースの専門家として、僕がカバーしきれていない領域の話とかをしてくれたら嬉しいです。わかりやすくね。
いいですね、今の段階で「なんとなく掴めたかも」という感覚はとても自然です。実はベクトルデータベースの全体像には、まだいくつか大事な“ピース”があります。都築怜さんが今までの対話で理解されたのは
- ベクトルとは何か（意味を数列にしたもの）
- ベクトル空間とは（似ているものが近く、違うものは遠くに配置される地図）
- チャンクとは（情報を扱いやすく分ける単位）
- セマンティックウェブや従来のDBとの違い（人間が枠を設計する vs AIが意味を学習して配置する）
ここまではばっちり押さえています。
でも実務や応用に踏み込むと、さらに重要な論点があるんです。わかりやすく順番に触れてみますね。
1. 検索の仕組み（類似度計算）
ベクトルデータベースの心臓部は「似ているデータをどう見つけるか」です。
ここで使われるのが「コサイン類似度」や「ユークリッド距離」といった数式。直感的には「2つのベクトルの向きや距離を測ることで、どれくらい近いか」を計算しています。これがあるから、AIは「オレンジ色の果物」と入力されると、「みかん」のチャンクを探し出せるんです。
2. インデックス構造
ベクトルは数百〜数千次元になるため、膨大なデータの中から最も近いものを探すのは意外と大変です。そこでベクトルデータベースは「インデックス」と呼ばれる工夫を使います。木構造やグラフを利用して、“高速に近いものを探すショートカット”を作っているんです。代表的なのは HNSW（Hierarchical Navigable Small World Graph） という手法で、要するに「近いものをリンクで結んでおいて、迷路をたどるように探索する」方式です。
3. マルチモーダル
今までの話は「言葉」の例が多かったですが、実際には 画像や音声、動画 もベクトル化できます。たとえば「夕焼けの写真」を入力したら「sunset」というタグの付いた画像を探してきたり、「鳥の鳴き声」を録音したら「これはスズメだ」と返すことも可能です。これを マルチモーダル検索 と呼びます。AI時代の面白さは、異なる種類のデータを同じベクトル空間で扱えることにあります。
4. アップデートと動的学習
従来のDBは「一度登録したら変わらない」性質が強いですが、ベクトルデータベースは「新しいデータが入るたびに地図を広げる」柔軟さを持っています。とはいえ、AIが学習した埋め込みモデルをどう更新するか、古いデータとの整合性をどう保つか、といった運用上の課題もあります。つまり“成長し続ける図書館”の管理の難しさがあるのです。
5. 説明可能性の問題
ここは人文系の感性を持つ都築怜さんに刺さるところかもしれません。セマンティックウェブは「なぜそう結論づけたか」を論理的に追跡できますが、ベクトル空間は「距離が近かったから」という説明しか返せないことが多い。これは「AIのブラックボックス問題」の一部であり、実務での信頼性や法的な説明責任に直結するテーマなんです。
6. 応用シナリオ
最後に、「じゃあこれを何に使えるの？」という話。
- カスタマーサポートでFAQ検索を自然文でできるようにする
- ECサイトで「この商品に似ているもの」を自動で出す
- 研究論文を意味ベースで検索して、新しい発見をつなぐ
- DAOやコミュニティの議事録をベクトル化して、知識のアーカイブにする
実は、都築怜さんのビジネス領域（Web3やDAO）でも、議論ログや参加者の提案をベクトル化すれば“コミュニティの知恵の地図”をつくれる可能性があるんです。
要するに、これまでの会話で「ベクトル空間とは何か」は掴めたと思いますが、まだ 検索アルゴリズム・マルチモーダル・更新性・説明可能性・実務応用 という広い世界が残っている、というのが全体像です。
都築怜さん、この続きをnoteで書くとしたら、「概念の理解編」と「実務・応用編」に分けるのが読みやすいかもしれませんね。
次はこの“応用編”をもっと具体的に掘り下げてみますか？
>なるほど、また今度で。今日はありがとう
こちらこそ、楽しく深いお話をありがとうございました。いつでも続きをご一緒できますので、また声をかけてくださいね。