ベクトルデータベースとは？生成AI・RAG活用で変わるDB負荷と運用・監視のポイント

生成AI（Generative AI）やLLM（Large Language Models：大規模言語モデル）の業務活用が進むなか、AIアプリケーションを支えるデータベースやインフラの設計・運用も重要な検討事項となっています。

なかでも、RAG（※）などで活用されるのが「ベクトルデータベース」です。一方、生成AIの活用では、ベクトルデータベースだけでなく、既存のリレーショナルデータベース（以下、RDB）や周辺基盤への負荷も考慮する必要があります。

この記事では、ベクトルデータベースの基本と生成AIにおけるデータベースの使われ方を整理し、負荷・コスト・キャパシティに備えるための運用・監視について解説します。

※RAG（Retrieval-Augmented Generation：検索拡張生成）とは、生成AIが外部のデータベースや文書などから関連情報を検索し、その内容を参照して回答を生成する技術のこと。

なお、データベースのクラウド運用でのコストを抑える手がかりを知りたい方は、こちらの資料も併せてご覧ください。

生成AIで活用される「ベクトルデータベース」とは

ベクトルデータベースとは、文章や画像などのデータを数値の並びである「ベクトル」として保存し、ベクトル同士の近さに基づいて検索できるデータベースです。

キーワードが一致しているかだけでなく、意味や特徴が近いデータを探せるため、生成AIを利用した検索やRAGなどで活用されています。

ベクトルデータベースの役割

RAGは、LLMが回答を生成する前に外部のデータソースから関連情報を検索し、その情報を参照させる仕組みです。

一般的な構成では、文書を一定の単位に分割し、Embedding（埋め込み）モデルによってベクトルへ変換します。ユーザーから質問を受けた際にも質問内容をベクトル化し、近いベクトルを検索することで関連情報を取得します。

例えば、社内規程について質問する生成AIシステムであれば、質問と意味的に近い規程やマニュアルを検索し、その内容をLLMへ渡して回答生成に利用するといった構成が考えられます。この検索部分を担う選択肢の一つがベクトルデータベースです。

従来のRDBとの違い

RDBは、顧客IDや商品コード、受注日などの構造化されたデータを表形式で管理し、条件に合うデータをSQLで検索する用途に適しています。

一方、ベクトル検索は、文章や画像などの意味や特徴の近さから、関連するデータを探す用途で利用されます。

ただし、RDBとベクトル検索が別々のデータベースで提供されるとは限りません。

例えば、PostgreSQLではpgvectorを利用したベクトル検索が可能です。Oracle Databaseにもベクトルを保存・検索する仕組みがあり、既存の業務データとベクトルデータを同じデータベースで扱う構成も選択できます。

そのため、生成AIを支えるデータベースを検討する際は、既存データの配置や検索要件に応じて、それぞれの役割を組み合わせる視点が必要です。

生成AIでベクトルデータベースが利用される理由

生成AIを企業内で利用する場合、LLMが学習済みの情報だけでは、自社独自の規程や商品情報、顧客情報などを回答に反映できないケースがあります。

そこで活用されているのが、自社が保有するデータから関連情報を検索し、LLMへ渡すRAGです。RAGでは、ユーザーの質問に関連する情報を大量の文書から探す必要があるため、キーワードの一致だけでなく、意味の近さから検索できるベクトル検索が利用されています。

こうしたベクトル検索の基盤として、ベクトルデータベースが選択肢の一つとなっています。専用のベクトルデータベースに加え、ベクトル検索に対応した既存のデータベースや検索サービスを利用する構成もあります。

生成AI活用でデータベース全体の使われ方はどう変わるか

生成AIを業務システムへ組み込むと、新たなベクトル検索やデータ更新が加わるだけでなく、既存のRDBへのアクセスも変化する場合があります。

そのため、生成AIの運用では、AI向けに新しく構築した基盤だけを見るのではなく、既存DBを含めてデータアクセスや負荷の変化を確認することが重要です。

ベクトル検索やRAGによって新しい処理が加わる

RAGでは、利用者から質問を受けるたびに関連情報を検索します。また、参照元のデータを更新する際には、Embeddingの生成やインデックス更新などの処理も発生します。

こうした処理によって、従来のシステムとは異なるタイミングや頻度でDBへのアクセスが発生する可能性があります。

RAGの元データを持つRDBにもアクセスが発生する

RAGで参照する情報は、ベクトルデータベースだけに保存されているとは限りません。顧客や商品、契約、在庫などの業務データが既存のRDBに保存されているケースもあります。

生成AIの導入によって、検索やデータ更新など、従来とは異なる処理が加わります。また、構成によっては既存のデータベースから業務データを取得するため、AI向けの基盤だけでなく、周辺DBへのアクセス状況も確認する必要があります。

Text-to-SQLによるRDB活用については、関連記事でも詳しく解説しています。

DB・基盤に積み上がる負荷とコスト

生成AIの利用が広がると、DBAやインフラ担当者にとって、将来の負荷や必要なリソースを事前に見積もることが難しくなる場合があります。

PoCでは問題なく動いていても、本番展開によって利用者や問い合わせが増えると、想定以上の処理が発生する可能性があります。

利用状況によって負荷が変化する

従来の業務システムでは、営業時間やバッチ処理の時間帯などから、ある程度の負荷傾向を予測できる場合があります。

一方、生成AIアプリケーションでは、利用者が任意のタイミングで質問でき、質問内容によって検索する情報量や処理内容も変わります。必要なリソースは、例えば次のような条件に左右されます。

• AIアプリケーションの利用者数

• 1人当たりの問い合わせ回数

• RAGで取得するデータ量

• ベクトル検索の方式やインデックス

• データ更新やEmbedding再生成の頻度

• RDBへの追加問い合わせの有無

• AIアプリケーションとDBの接続方式

そのため、導入前の想定だけで性能を判断せず、本番運用後の実測データを確認しながら調整することが大切です。

クラウドDBの利用料金にも影響する

DBのCPUやメモリ、ストレージ、I/Oなどの使用量が増えれば、クラウド環境ではインスタンスのスケールアップやストレージ拡張が必要になる場合があります。また、生成AIシステム全体では、LLMのAPI利用料やEmbedding生成、ベクトル検索基盤などもコスト要因になります。

DBのリソース使用量が増えた場合でも、すぐにスペックを引き上げるのではなく、まず負荷の原因を確認することが大切です。特定のSQLやI/O待ちなどがボトルネックとなっている場合もあるため、負荷の発生箇所を把握したうえで、チューニングやリソース追加を検討します。

キャパシティ計画は継続的に見直す

生成AIシステムでは、PoCから一部部門、本番展開へと段階的に利用範囲が広がることがあります。利用者数だけでなく、ユースケースの追加によってRAGの検索回数やRDBへのアクセス量が変化する可能性もあります。

そのため、導入時にキャパシティを決めて終わりにせず、次のような指標を継続的に確認します。

• CPU・メモリの使用状況

• I/O

• 接続・セッション数

• クエリの実行時間・実行回数

• データ量・ストレージ使用量

これらの推移を確認しながら、実際の利用状況に応じてリソースや構成を見直していくことが重要です。

予測しにくい負荷に監視でどう備えるか

生成AIによる負荷の変化を事前に読み切ることが難しい場合は、運用後の変化を継続して把握できる状態を整えておくことが大切です。

クエリ・セッション単位で性能を確認する

CPUやメモリの使用率だけでは、負荷が増えた原因まで分からない場合があります。生成AIアプリケーションの公開後は、例えば次のような情報を確認します。

• SQLの実行回数や実行時間

• 同時接続数・セッション数

• 待機イベント

• CPU・メモリなどのリソース使用状況

既存業務と生成AIアプリケーションが同じDBを利用する場合は、DB全体の変化を確認し、負荷が発生している箇所を把握します。

監視データをキャパシティ計画に活用する

監視で蓄積したデータは、キャパシティやコストの見直しにも活用できます。生成AIサービスの公開前後でリソース使用量やSQLの実行状況を比較することで、既存DBへの影響を確認できます。その結果を踏まえ、SQLや構成を見直すのか、リソースを追加するのかを判断します。

実際の利用状況を継続して確認することで、必要以上のリソース増強を避けながら、運用環境を調整しやすくなります。

生成AI基盤の運用を支えるRDB・基盤側の可観測性

生成AIを安定して運用するには、利用するLLMやベクトル検索基盤だけでなく、既存のRDBやインフラを含めて、システム内部の変化を把握できる状態を整えておくことが大切です。

異常検知によって変化を早く捉える

通常時の性能傾向を継続して記録しておけば、普段とは異なる負荷や挙動が発生した際に、その変化を捉えやすくなります。

AIや機械学習を活用した監視では、過去の傾向と比較して異常候補を検知し、確認が必要な箇所を絞り込む方法もあります。ただし、異常検知だけで将来の負荷をすべて予測できるわけではなく、日頃から必要な観測データを蓄積しておくことが前提です。

AIを活用したシステム監視については、こちらの記事で解説しています。

関連記事：「AIを活用したシステム監視」

平時から詳細な観測データを蓄積する

障害が発生してから情報を取得しようとしても、直前の状態が残っていなければ正常時との違いを比較できません。

生成AIアプリケーションの導入前からデータを蓄積しておけば、導入後に負荷が変化した際にも、以前から発生していたものなのか、新たに加わったものなのかを確認しやすくなります。

CPUやメモリなどのリソース情報に加え、SQL、セッション、待機イベントなどを時系列で確認できる状態を整え、既存のRDBやアプリケーション、インフラで何が起きているかを把握できるようにしておくことが大切です。

exemONEでRDB・周辺基盤の状態を可視化する

日本エクセムの「exemONE」は、データベースやアプリケーション、インフラなど、システムを構成する各レイヤーの状態を可視化するオブザーバビリティプラットフォームです。

「exemONE DB Edition」では、Oracle Database、PostgreSQL、Microsoft SQL Server、MySQLなどのデータベースに対応し、SQLやセッション、各種メトリクスを時系列で確認できます。

生成AI基盤を監視する際は、利用しているデータベースやシステム構成に応じて、監視対象と対応範囲を確認する必要があります。

exemONEでは、既存のRDBやアプリケーション、インフラの状態を可視化できるため、生成AI導入後の負荷変化や性能状況を継続して確認する用途に活用できます。

関連資料：「AIがデータベースにもたらす変化と 企業が今すぐ備えるべきこと」

まとめ

ベクトルデータベースは、意味や特徴が近い情報を検索できる仕組みで、RAGなどの生成AIシステムを支える選択肢の一つです。一方、生成AIの処理はベクトル検索だけで完結するとは限らず、既存のRDBや周辺基盤へのアクセスが発生する場合もあります。

生成AIの利用状況によってDBへのアクセスや必要なリソースは変化するため、SQLやセッション、リソース使用状況などを継続して確認し、負荷の変化や原因を把握できる状態を整えておくことが大切です。

「exemONE」では、データベースやアプリケーション、インフラなど、システムを構成する各レイヤーの状態を可視化できます。また、「exemONE DB Edition」では、SQLやセッション、リソースなどの情報を時系列で確認し、データベースの性能監視や負荷分析を支援します。
生成AIの導入に伴い、既存DBを含めた監視体制やキャパシティの見直しを検討している場合は、日本エクセムへご相談ください。