AIは「知らないこと」を知らない
ChatGPTやClaudeを使っていて、こんな経験はないですか。
もっともらしい回答が返ってきたので信じたら、実は存在しない論文を引用していた。架空の統計データを自信満々に語っていた。古い情報を最新のものとして提示していた。
これがハルシネーション（幻覚）です。AIが「嘘をつく」とよく言われますが、正確には「知らないことを推測で埋めてしまう」という表現の方が近い。LLM（大規模言語モデル）は学習データのパターンから「それっぽい」文章を生成するので、事実かどうかの判断はしていないんです。
この問題に対する現時点で最も実用的な解決策が、RAG（Retrieval-Augmented Generation / 検索拡張生成）です。
RAGの仕組み — 3ステップで理解する
難しそうに聞こえますが、やっていることはシンプルです。
ステップ1: 検索（Retrieval）
ユーザーが質問すると、まずAIが回答を生成する前に、関連する情報を外部のデータソースから検索します。社内文書、PDF、データベース、Webページなど、「正しい情報が入っている場所」から必要な部分を引っ張ってくる。
図書館で調べ物をするのと同じです。いきなり自分の頭で答えるのではなく、まず参考文献を探してくる。
ステップ2: コンテキストに追加（Augmentation）
検索で見つかった情報を、AIへの「プロンプト」に付け加えます。つまり、AIに「この資料を参考にして答えてね」と渡すわけです。
実際には裏側でこんなプロンプトが組み立てられています：
以下の参考情報をもとに、ユーザーの質問に答えてください。
参考情報に含まれていない内容については「わかりません」と回答してください。
【参考情報】
{検索で見つかった文書の内容}
【ユーザーの質問】
{ユーザーが入力した質問}
ステップ3: 生成（Generation）
AIが参考情報をもとに回答を生成します。自分の「記憶」（学習データ）だけでなく、今渡された「参考文献」を踏まえて答えるので、正確性が大幅に上がります。
これだけです。検索して、渡して、答えさせる。
「ベクトル検索」— RAGのキモ
ここからもう少し踏み込みます。RAGで「検索」と言いましたが、普通のキーワード検索とは違います。
たとえば「社員の有給休暇の取り方」を検索したいとき、文書の中に「有給休暇」という単語が含まれていなくても、「年次休暇の申請方法」「休日の取得手続き」のようなページを見つけてほしいですよね。
これを可能にするのがベクトル検索（セマンティック検索）です。
仕組みはこう：
- 文書をAI（エンベディングモデル）に通して、意味を表す「数値の列」（ベクトル）に変換する
- 質問も同じように数値の列に変換する
- 「数値の列」同士の距離（近さ）を計算して、意味的に近い文書を見つける
キーワードが一致しなくても、意味的に関連する情報を見つけられる。これがRAGを実用的にしている核心技術です。
RAGの実例 — 日常で使っているもの
実は、すでにRAGの恩恵を受けている人は多いです。
Google NotebookLM
Googleが提供しているツール。自分のPDFやドキュメントをアップロードすると、その内容をもとにAIが質問に答えてくれます。これは典型的なRAGの実装です。AIの回答には必ず出典（どの文書のどの部分）が表示される。研究や学習にかなり使えます。
Perplexity
「AIが回答する前にWebを検索する」検索エンジン。質問すると、まず関連するWebページを複数検索し、その内容を参照しながら回答を生成する。出典リンク付き。これもRAGの考え方そのものです。
ChatGPTの「Web検索」機能
ChatGPTがWeb検索をオンにしている状態も、RAGの一種です。最新のニュースや情報を検索してから回答するので、学習データにない最新情報にも対応できる。
企業の社内チャットボット
多くの企業が社内文書をRAGで検索できるチャットボットを導入し始めています。就業規則、マニュアル、過去の議事録。膨大な社内ドキュメントから必要な情報を瞬時に見つけ出す。
RAGの限界 — 魔法ではない
RAGは強力ですが、完璧ではないです。知っておくべき限界があります。
検索の質がそのまま回答の質になる
RAGの「R」（Retrieval = 検索）がまずいと、どんなに優秀なAIでもダメな回答しか出せません。検索で間違った文書を拾ってきたら、その間違った情報をもとに回答する。「ゴミを入れたらゴミが出る」という原則はRAGでも変わりません。
文書の分割方法が重要
長い文書をベクトル検索に使う場合、適切な大きさに分割（チャンキング）する必要があります。分割が細かすぎると文脈が失われ、大きすぎると関係ない情報がノイズになる。ここのチューニングが意外と職人芸です。
複数文書にまたがる推論が苦手
「AとBの文書の情報を組み合わせて推論する」タイプの質問は、まだ難しいことがあります。検索で拾えるのは個別の文書の断片なので、文書間の関係を理解するのが弱い。
ハルシネーションがゼロにはならない
RAGを使ってもAIが幻覚を起こすことはあります。参考情報の「解釈」の部分でズレが生じたり、参考情報にない部分を推測で補完してしまったり。減りはするけど、完全にはなくならない。出典の確認は引き続き大事です。
自分でRAGを組む方法
技術者向けの話になりますが、RAGを自分で構築する選択肢も増えています。
必要な要素
- エンベディングモデル: 文書をベクトルに変換する（OpenAIのtext-embedding-3、Cohereなど）
- ベクトルデータベース: ベクトルを保存・検索する（Pinecone、Chroma、Weaviate、pgvectorなど）
- LLM: 回答を生成する（Claude、GPT-4o、Geminiなど）
- オーケストレーション: 上記をつなぐ（LangChain、LlamaIndex、または自前のコード）
簡単に始めるなら
正直、2026年時点では自分でゼロからRAGを組む必要はあまりないです。NotebookLMに文書を突っ込む、ChatGPTやClaudeにファイルを添付する。これで十分な場面が多い。
自前で組むメリットが出るのは、大量の社内文書を扱いたい、検索精度を細かくチューニングしたい、データをクラウドに出せないセキュリティ要件がある、といったケースです。
RAG vs ファインチューニング — どっちを使うべきか
よく聞かれる質問です。
RAG: 「参考文献を渡して回答させる」→ データの追加・更新が簡単。事実ベースの質問に強い。
ファインチューニング: 「AIの脳そのものを追加学習させる」→ 特定の文体やフォーマットを覚えさせるのに向いている。データの更新は再学習が必要。
多くの場合、まずRAGを試すべきです。ファインチューニングは「RAGでは対応できない」ケースに限って検討する。コスト面でもRAGの方がはるかに安い。
RAGがもたらす変化
RAGの本質は「AIに最新の正確な情報を渡す仕組み」です。これによって：
- AIの回答の信頼性が上がる
- 自分だけの知識ベースをAIに接続できる
- 「AIは古い情報しか知らない」問題が解消される
- 組織の知識がAIを通じて民主化される
技術としては地味に見えるかもしれませんが、AIを「実際に仕事で使えるもの」にした立役者はRAGだと思っています。華やかなデモより、こういう地味な仕組みが世の中を変えるんですよね。
]]>