AIエージェント開発の必須知識：RAGとVector DBの基礎

はじめに

「自社の膨大なマニュアルやナレッジベースの内容を、ChatGPTのように対話形式で手軽に引き出したい」「開発中のAIチャットボットに、社内規定や顧客との過去のやり取りを正確に回答させたい」「でも、機密情報を含む自社データを、外部のAIサービスに学習データとして渡すのはセキュリティ的に絶対に避けたい」

AI、特に大規模言語モデル（LLM）の活用を検討する多くのエンジニアや開発担当者が、このような課題に直面しているのではないでしょうか。LLMは非常に強力ですが、その知識は特定の時点までのものであり、自社の独自データについては何も知りません。

この課題を解決するために「ファインチューニング」を検討するかもしれません。しかし、ファインチューニングには大量の教師データと高い計算コストが必要な上、情報の更新があるたびにモデルを再学習させるのは現実的ではありません。さらに、AIがもっともらしい嘘をつく「ハルシネーション」という問題も依然として残ります。

本記事では、これらの課題をエレガントに解決する技術として、今、AIエージェント開発の現場でデファクトスタンダードとなりつつある**RAG（Retrieval-Augmented Generation：検索拡張生成）**というアプローチを徹底的に解説します。

RAGは、LLMに自社データを「学習」させるのではなく、必要な情報を「検索」して外部から与えることで、LLMの能力を最大限に引き出す画期的な手法です。そして、その中核を担うのが**Vector DB（ベクトルデータベース）**です。

この記事を読み終える頃には、あなたは以下のことを理解し、自社のAIエージェント開発に活かすための一歩を踏み出せるようになっているはずです。

LLMが抱える根本的な課題（知識のカットオフ、ハルシネーション）
なぜファインチューニングだけでは不十分なのか
RAGがどのようにしてこれらの課題を解決するのか、その具体的な仕組み
RAGの心臓部であるEmbeddingとVector DBの役割
PythonとLangChainを使ったRAGの基本的な実装方法

それでは、AIエージェント開発の新たな扉を開く、RAGとVector DBの世界へご案内します。

なぜRAGとVector DBが重要なのか？ LLMの限界と従来の課題

RAGの重要性を理解するためには、まずLLMが単体で抱える限界を知る必要があります。

LLMが抱える3つの大きな壁

知識のカットオフ（Knowledge Cut-off） GPT-4のような最先端のLLMでさえ、その知識は学習データが収集された特定の日時で止まっています。例えば、GPT-4の初期モデルは2021年9月までの情報しか持っていません。そのため、それ以降の出来事や、新製品の情報、最新の社内規定について質問しても、答えることができません。ビジネスの世界では情報の鮮度が命であり、この「知識の壁」は致命的な欠点となります。
ハルシネーション（Hallucination：幻覚） LLMは、事実に基づかない情報を、あたかも真実であるかのように生成することがあります。これをハルシネーションと呼びます。特に、学習データに含まれていない専門的な内容や、社内情報のようなクローズドなドメインについて質問された場合に、この現象は顕著になります。顧客サポート用のAIが誤った製品情報を伝えたり、社内アシスタントが架空の規定を案内したりする事態は、企業の信頼を著しく損なうリスクをはらんでいます。
情報セキュリティとプライバシー 自社の機密情報や顧客の個人情報を扱う場合、それらを外部のLLM提供企業のサーバーに学習データとしてアップロードすることには、非常に大きなセキュリティリスクが伴います。一度学習データとして取り込まれてしまうと、他のユーザーへの回答に利用されてしまう可能性もゼロではなく、データのコントロールを失うことになります。

従来の解決策「ファインチューニング」とその限界

これらの課題を解決するアプローチとして、以前は「ファインチューニング」が主流でした。これは、既存の学習済みモデルに対して、自社データを含む追加の教師データセットを与えて再学習させる手法です。

ファインチューニングは、LLMに特定の文体や口調を真似させたり、特定のタスク（例えば、要約や感情分析）への性能を特化させたりするのには有効です。しかし、「知識を注入する」という目的においては、いくつかの大きな課題があります。

高いコスト: ファインチューニングには、大量の高品質な教師データ（質問と回答のペアなど）の準備と、モデルの学習を実行するための高価な計算リソース（GPU）が必要です。
知識の更新が困難: 新しい情報（例えば、週次レポートや新しいマニュアル）を追加したい場合、その都度ファインチューニングをやり直す必要があります。これは時間的にも金銭的にも非効率です。
透明性の欠如: ファインチューニングされたモデルが、なぜその回答を生成したのか、どの情報を根拠にしているのかを追跡することは非常に困難です。ハルシネーションが起きた場合の原因究明も難しくなります。

そこで登場したのが、**RAG（検索拡張生成）**です。RAGは「学習」ではなく「検索」というアプローチで、これらの問題を根本から解決します。

具体的な解決策：RAGの仕組みとVector DBの役割

RAGは、その名の通り「検索（Retrieval）」でLLMの知識を「拡張（Augmented）」し、回答を「生成（Generation）」するアーキテクチャです。LLMを「非常に優秀だが記憶喪失のコンサルタント」、Vector DBを「完璧な記憶力を持つ外部の専門図書館」に例えると分かりやすいでしょう。

コンサルタント（LLM）は、質問を受けるたびに、まず図書館（Vector DB）へ行って関連資料を調べ（検索）、その資料を読み込みながら（コンテキストとしてプロンプトに含める）、質問に対する的確な回答を生成します。

この仕組みにより、LLMは常に最新かつ正確な情報に基づいて回答できるようになり、ハルシネーションを劇的に抑制できます。

RAGの全体像と処理フロー

RAGのシステムは、大きく2つのフェーズに分かれています。

データ準備フェーズ（Indexing）: 事前に自社ドキュメントを検索可能な状態にして、Vector DBに保存しておくフェーズ。
実行フェーズ（Retrieval & Generation）: ユーザーからの質問を受け取り、Vector DBから関連情報を検索して、LLMが回答を生成するフェーズ。

この流れを図で示すと以下のようになります。

graph TD
    subgraph "データ準備フェーズ（Indexing）"
        A[ドキュメント群<br>PDF, TXT, Markdown, etc.] --> B(Load<br>ドキュメント読み込み);
        B --> C(Split<br>テキストを適切なサイズに分割);
        C --> D(Embed<br>分割したテキストをベクトル化);
        D --> E[Vector DB<br>ベクトルと元のテキストを保存];
    end

    subgraph "実行フェーズ（Retrieval & Generation）"
        F[ユーザーからの質問] --> G(Embed<br>質問をベクトル化);
        G --> H{Vector DB<br>類似ベクトル検索};
        E --> H;
        H --> I[関連性の高い<br>テキストチャンク（コンテキスト）];
        F & I --> J(Prompt<br>質問とコンテキストを結合し<br>プロンプトを作成);
        J --> K[LLM (e.g., GPT-4)<br>回答生成];
        K --> L[ユーザーへの回答];
    end

それでは、このフローの各要素を詳しく見ていきましょう。

構成要素①: Embedding - テキストを「意味」のベクトルに変換する魔法

RAGを理解する上で最も重要な概念が**Embedding（エンベディング、埋め込み）**です。

人間は「犬」と「猫」が似ていて、「犬」と「車」はあまり似ていないことを直感的に理解できます。しかし、コンピュータは単なる文字の羅列としてしか認識できません。Embeddingは、この「意味の近さ」をコンピュータが扱えるように、テキストを高次元のベクトル（数値の配列）に変換する技術です。

例えば、以下のように変換されます（次元数は簡略化しています）。

犬: [0.8, 0.1, 0.3, ...]
猫: [0.7, 0.2, 0.4, ...]
車: [-0.5, 0.9, -0.1, ...]

このベクトル空間上では、意味的に近い単語や文章は、その距離も近くなります。OpenAIのtext-embedding-ada-002（1536次元）や、様々なオープンソースのモデルがこの変換を行うために利用されます。

RAGでは、事前にドキュメントの各部分（チャンク）をベクトル化しておき、ユーザーの質問も同じモデルでベクトル化します。そして、質問のベクトルと最も近いベクトルを持つドキュメントチャンクを探すことで、質問に最も関連性の高い情報を特定するのです。

構成要素②: Vector DB - 意味で検索する次世代のデータベース

Embeddingによって得られた大量のベクトルデータを効率的に保存し、高速に「意味の近さ（類似度）」で検索するための専用データベースがVector DBです。

従来のRDB（リレーショナルデータベース）がWHERE user_id = 123のように完全一致でデータを検索するのに対し、Vector DBは「このベクトルに最も近いベクトルを探して」という**近似最近傍探索（Approximate Nearest Neighbor, ANN）**を得意とします。

代表的なVector DBには以下のようなものがあります。

Chroma: ローカル環境で手軽に試せるオープンソースのVector DB。プロトタイピングに最適。
FAISS: Facebook (Meta) AIが開発した、ベクトル類似検索に特化したライブラリ。
Pinecone, Weaviate, Qdrant: クラウドネイティブなマネージドサービスとして提供されることが多く、スケーラビリティや高度な機能（メタデータフィルタリングなど）が特徴。

Vector DBは、ベクトル化されたドキュメントチャンクと、その元となったテキスト本文のペアを保存します。検索時には、質問ベクトルに類似したベクトルを持つチャンクを複数個見つけ出し、その元テキストをLLMへのコンテキストとして渡します。

RAGの実装ステップ（PythonとLangChainによるコード例）

それでは、実際にPythonのフレームワークLangChainを使って、簡単なRAGシステムを構築してみましょう。LangChainは、LLMアプリケーション開発における一連の流れを抽象化し、簡単に実装できるようにしてくれる便利なツールです。

ここでは、架空の「社内副業規定.pdf」というドキュメントの内容について回答するAIエージェントを作成します。

前提: PDFファイルinternal_rules.pdfが手元にあるとします。内容は以下のようなものです。

第5条（副業・兼業）

社員は、会社の許可を得た上で、副業または兼業を行うことができる。

副業を希望する社員は、所定の申請書を人事部に提出し、事前の承認を得なければならない。

会社の競合他社での業務や、会社の信用を損なう可能性のある業務は許可されない。

ステップ1: 環境構築と準備

まず、必要なライブラリをインストールし、OpenAIのAPIキーを設定します。

1

pip install langchain openai chromadb pypdf tiktoken

1
2
3
4


import os

# 環境変数にOPENAI_API_KEYを設定
os.environ["OPENAI_API_KEY"] = "YOUR_OPENAI_API_KEY"

ステップ2: ドキュメントの読み込み (Load)

LangChainのPyPDFLoaderを使って、PDFファイルを読み込みます。

1
2
3
4
5
6
7


from langchain.document_loaders import PyPDFLoader

loader = PyPDFLoader("internal_rules.pdf")
documents = loader.load()

print(f"ドキュメントを {len(documents)} ページ読み込みました。")
# 出力例: ドキュメントを 1 ページ読み込みました。

ステップ3: テキストの分割 (Split/Chunking)

LLMが一度に処理できるテキスト量（コンテキストウィンドウ）には限りがあるため、また、検索精度を向上させるために、読み込んだドキュメントを小さなチャンクに分割します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


from langchain.text_splitter import RecursiveCharacterTextSplitter

# テキスト分割の設定
text_splitter = RecursiveCharacterTextSplitter(
    chunk_size=500,  # チャンクの最大文字数
    chunk_overlap=50   # チャンク間のオーバーラップ文字数
)

# 分割の実行
split_docs = text_splitter.split_documents(documents)

print(f"ドキュメントを {len(split_docs)} 個のチャンクに分割しました。")
# 出力例: ドキュメントを 3 個のチャンクに分割しました。

chunk_sizeとchunk_overlapはRAGの性能を左右する重要なパラメータです。chunk_overlapを設けることで、文の途中でチャンクが分断され、文脈が失われるのを防ぎます。

ステップ4: EmbeddingとVector DBへの保存 (Embed & Store)

分割したチャンクをEmbeddingモデルでベクトル化し、Chroma DBに保存します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


from langchain.embeddings.openai import OpenAIEmbeddings
from langchain.vectorstores import Chroma

# Embeddingモデルのインスタンス化
embeddings = OpenAIEmbeddings()

# Chroma DBにドキュメントを読み込み、ベクトル化して保存
# persist_directoryを指定すると、DBがディスクに永続化される
vectordb = Chroma.from_documents(
    documents=split_docs,
    embedding=embeddings,
    persist_directory="./chroma_db"
)

print("Vector DBの準備が完了しました。")

このコードを実行すると、./chroma_dbというディレクトリが作成され、ベクトルデータが保存されます。

ステップ5: 検索と生成 (Retrieve & Generate)

いよいよ、作成したVector DBを使って質問応答チェーンを構築し、実際に質問をしてみます。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


from langchain.chat_models import ChatOpenAI
from langchain.chains import RetrievalQA

# LLMモデルのインスタンス化
llm = ChatOpenAI(model_name="gpt-4", temperature=0)

# Vector DBをRetriever（検索機）として使用するQAチェーンを作成
qa_chain = RetrievalQA.from_chain_type(
    llm=llm,
    chain_type="stuff",  # 最もシンプルなチェーンタイプ
    retriever=vectordb.as_retriever()
)

# 質問を実行
question = "社員が副業を始めるには、どのような手続きが必要ですか？"
response = qa_chain.run(question)

print(f"質問: {question}")
print(f"回答: {response}")

実行結果の例:

質問: 社員が副業を始めるには、どのような手続きが必要ですか？
回答: 社員が副業を始めるには、所定の申請書を人事部に提出し、事前の承認を得る必要があります。

見事に、PDFの内容に基づいた正確な回答が生成されました。これはLLMが元々持っていた知識ではなく、私たちがVector DB経由で提供した情報に基づいています。これがRAGの力です。

RAGのメリットとデメリット

RAGは非常に強力な技術ですが、万能ではありません。そのメリットとデメリットを正しく理解し、ファインチューニングとの使い分けを考えることが重要です。

RAGのメリット

ハルシネーションの劇的な抑制: LLMは与えられたコンテキスト（検索結果）に基づいて回答を生成するため、事実に基づかない情報を捏造する可能性が大幅に低下します。
知識の更新が容易かつ低コスト: 新しい情報やドキュメントの更新があった場合、モデル全体を再学習する必要はありません。Vector DB内の該当データを追加・更新するだけで、即座に知識を最新の状態に保てます。
透明性と解釈可能性: RAGシステムでは、LLMがどのドキュメントチャンクを参考にして回答を生成したのかを追跡できます。これにより、ユーザーに出典を提示することが可能となり、回答の信頼性が向上します。
高いセキュリティ: 自社の機密情報を外部のLLMに学習させる必要がありません。データは自社で管理するVector DB内に保持し、実行時に必要な情報だけをプロンプトの一部としてLLMに渡すため、データ漏洩のリスクを最小限に抑えられます。

RAGのデメリットと課題

検索精度への依存: RAGの性能は、検索コンポーネントの精度に大きく依存します。ユーザーの質問に対して関連性の低いドキュメントしか検索できなかった場合、当然ながら回答の質も低くなります（Garbage In, Garbage Out）。
Chunking戦略の難しさ: テキストをどのように分割するか（chunk_size、chunk_overlap、分割単位など）は、試行錯誤が必要な職人芸的な側面があります。ドキュメントの構造を無視した不適切なChunkingは、検索精度を著しく低下させます。
システム構成の複雑化: LLM単体で完結せず、データローダー、テキストスプリッター、Embeddingモデル、Vector DBなど、複数のコンポーネントを組み合わせたパイプラインを構築・運用する必要があります。
レイテンシの増加: ユーザーからのリクエストごとに「検索」というステップが挟まるため、LLM APIを直接呼び出す場合に比べて、応答に時間がかかる可能性があります。

RAG vs ファインチューニング：どちらを選ぶべきか？

RAGとファインチューニングは対立するものではなく、補完関係にあります。目的によって使い分けるのが賢明です。

観点	RAG（検索拡張生成）	ファインチューニング
主な目的	外部知識の参照、事実ベースの回答、ハルシネーション抑制	特定のスタイル・口調の模倣、特定タスクへの性能特化
知識の更新	容易（Vector DBのデータを更新するだけ）	困難（モデルの再学習が必要で高コスト）
ハルシネーション	抑制しやすい（根拠となる情報が与えられるため）	抑制しにくい（モデル内部の知識に依存するため）
出典の明示	可能	不可能
適した用途	社内ナレッジQA、マニュアル検索、最新情報に基づく回答生成	特定のキャラクター模倣、メール自動作成、要約タスクの精度向上

使い分けの指針:

事実に基づいた正確な知識を扱いたい場合は、まずRAGを検討します。
LLMの**振る舞い（口調、文体、思考プロセス）**を特定の形に変えたい場合は、ファインチューニングが有効です。
両方を組み合わせる、つまりファインチューニングしたモデルをRAGの生成器（Generator）として使用することで、特定のスタイルで、かつ正確な情報に基づいた回答を生成する、という高度なアプローチも可能です。

現場で使える実践的なTips

基本的なRAGの実装は比較的簡単ですが、実運用で高い性能を出すためにはいくつかの工夫が必要です。

高度なChunking戦略: 単純な固定長分割ではなく、ドキュメントの構造を活かしましょう。MarkdownであればMarkdownHeaderTextSplitter、ソースコードであればCodeSplitterなど、LangChainには様々なスプリッターが用意されています。これにより、意味のあるまとまりでテキストを分割でき、検索精度が向上します。
Embeddingモデルの選定: OpenAIのモデルは高性能ですが、コストがかかります。Hugging Faceで公開されているオープンソースのモデル（例: intfloat/multilingual-e5-largeなど日本語性能が高いもの）をセルフホストすることで、コストを抑えつつ、特定のドメインに特化した性能を得られる場合があります。
ハイブリッド検索（Hybrid Search）: Vector Search（意味検索）は万能ではありません。特定の製品名や型番、人名といった固有名詞を含むクエリには、従来のキーワード検索（BM25アルゴリズムなど）の方が強い場合があります。この2つを組み合わせたハイブリッド検索を実装することで、検索の網羅性と精度を両立させることができます。多くのマネージドVector DBサービスがこの機能を提供しています。
Retrieverのチューニング:
- 検索ドキュメント数（k）の調整: retriever=vectordb.as_retriever(search_kwargs={"k": 5}) のように、一度に検索するチャンク数を調整します。多すぎるとノイズが増え、少なすぎると必要な情報が欠落します。
- Re-ranking: 最初に多めにチャンクを検索（例: k=20）し、その後、より軽量で高速なCross-Encoderモデルなどを使って、質問との関連性を再計算し、上位のチャンク（例: top 5）だけをLLMに渡す手法です。ノイズを減らし、コンテキストの質を高めるのに非常に有効です。
メタデータフィルタリング: ドキュメントをVector DBに保存する際に、作成日、カテゴリ、著者などのメタデータを一緒に格納します。これにより、「2024年以降に作成された、“技術部"カテゴリのドキュメントの中から検索する」といった、より高度な絞り込み検索が可能になります。これは実用的なアプリケーションを構築する上で必須の機能です。

まとめ

本記事では、AIエージェント開発における必須知識として、RAG（検索拡張生成）と、その中核をなすVector DBの基礎について、仕組みから具体的な実装例、実践的なTipsまでを網羅的に解説しました。

RAGは、LLMに自社のデータを「学習」させるのではなく、必要な情報をリアルタイムに「検索」して与えることで、LLMの持つハルシネーションや知識の陳腐化といった課題を解決し、ビジネスの現場で安全かつ効果的に活用するための強力なパラダイムです。

その心臓部であるEmbeddingとVector DBは、非構造化データであるテキストを「意味」で扱えるようにする革新的な技術であり、これからのAIアプリケーション開発においてますます重要性を増していくでしょう。

今日学んだことをまとめると、以下のようになります。

LLMの限界を克服するため、RAGは「検索」と「生成」を組み合わせる。
Embeddingがテキストを意味的ベクトルに変換し、Vector DBがそれを高速に検索する。
LangChainのようなフレームワークを使えば、RAGパイプラインを効率的に構築できる。
RAGは知識の注入に、ファインチューニングは振る舞いの調整に適している。
実用的な性能を出すには、Chunking、Hybrid Search、Re-rankingなどの高度なテクニックが鍵となる。

RAGはまだ発展途上の技術であり、日々新しい手法が提案されています。しかし、本記事で解説した基礎をしっかりと理解していれば、その進化にキャッチアップしていくことは十分に可能です。

まずは、あなた自身のPCで、身近なドキュメントを使って小さなRAGシステムを構築してみてください。自分のデータに基づいてAIが的確な回答を生成する体験は、きっと新たなインスピレーションを与えてくれるはずです。この記事が、あなたのAIエージェント開発の第一歩となることを願っています。

AIエージェント開発の必須知識：RAGとVector DBの基礎#

はじめに#

なぜRAGとVector DBが重要なのか？ LLMの限界と従来の課題#

LLMが抱える3つの大きな壁#

従来の解決策「ファインチューニング」とその限界#

具体的な解決策：RAGの仕組みとVector DBの役割#

RAGの全体像と処理フロー#

構成要素①: Embedding - テキストを「意味」のベクトルに変換する魔法#

構成要素②: Vector DB - 意味で検索する次世代のデータベース#

RAGの実装ステップ（PythonとLangChainによるコード例）#

ステップ1: 環境構築と準備#

ステップ2: ドキュメントの読み込み (Load)#

ステップ3: テキストの分割 (Split/Chunking)#

ステップ4: EmbeddingとVector DBへの保存 (Embed & Store)#

ステップ5: 検索と生成 (Retrieve & Generate)#

RAGのメリットとデメリット#

RAGのメリット#

RAGのデメリットと課題#

RAG vs ファインチューニング：どちらを選ぶべきか？#

現場で使える実践的なTips#

まとめ#