· updated

【初心者向け】RAGとは｜社内検索を組む実装者がたとえで解説

ChatGPT は便利だけれど、社内の業務マニュアルや昨日決まった社内ルールを聞くと「分かりません」と返してくる——そんな歯がゆさを感じていませんか。実際、ラッコキーワードの実測（2026 年 5 月時点）でも「RAG とは」は月 1.5 万人以上が検索しており、私自身も現職で社内ドキュメント検索の RAG を業務システムに組み込んで日常運用しています。

結論から言うと、RAG は LLM に「社内資料を見ながら答える目」をつける仕組みで、ChatGPT が知らない最新情報や社内固有データを回答に反映させる定番アプローチ——というのが筋です。本記事では、RAG とは何か、データの流れ、ベクトル DB の役割（業務で触っている FAISS／Chroma／Weaviate の整理含む）、Python の最小サンプル、業務での落とし穴まで、社内 RAG を業務で組んでいる現役の生成AIエンジニア視点で整理します。

結論：RAGは「AIに、社内資料を見ながら答えてもらう仕組み」です

要点を3行で：

  • RAG（ラグ） は、ユーザーの質問に対して社外・社内の文書を検索し、その結果をAIに渡して回答を生成させる仕組みです。
  • 通常の ChatGPT への質問だけでは「AIが学習した範囲の知識」しか使えませんが、RAGなら社内ドキュメント・最新情報・自社固有のデータを回答に反映できます。
  • 私は現職で社内ドキュメント検索の RAG を業務システムに組み込んで運用しています。本記事はその実装現場の感覚を踏まえて整理しました。

業務での RAG 適用が、他の AI 活用事例とどう並ぶかは、別記事 AI 業務効率化 事例 の 5 領域 × 5 職種マトリクス（議事録／資料／RAG／コードレビュー／非エンジニア展開）で整理しました。RAG が「全社推進の中でどの位置にくるか」が見えると、本記事の技術解説が業務イメージに落ちやすくなります。

「ベクトルDB」「埋め込み」のような単語が初耳でも、各章のはじめに用語の噛み砕き解説を置いたので、止まらず最後まで読めるはずです。

まずは名前の意味から：RAG＝「検索＋AI回答」の英語頭文字

📖 この章で使う用語

  • R（Retrieval、リトリーバル）：検索のこと。
  • A（Augmented、オーグメンテッド）：補強・拡張のこと。
  • G（Generation、ジェネレーション）：生成のこと。
  • LLM（エルエルエム、大規模言語モデル）：ChatGPT / Claude / Gemini の正体。膨大な文章を学習した「文章を予測する装置」。

「RAG」は Retrieval-Augmented Generation の頭文字を取ったものです。直訳すると「検索で拡張された生成」。営業時代の言い方で例えると、『顧客リストを横に置いて提案を作る』のと、『記憶だけで提案する』の違いに近いです。

3つの構成要素を順番に見ていきましょう。

R: 検索（Retrieval）

ユーザーの質問に関連する文書を、外部の保管庫から引っ張ってくるフェーズです。具体的にはこんな流れです：

  1. ユーザー質問を、「意味の数値表現」（埋め込みベクトル） に変換する
  2. 文書保管庫の中から、意味が近い文書を取り出す（だいたい上位3〜10件）
  3. 取り出した文書を「参考資料」として手元に置く

A: 拡張（Augmented）

取り出した文書と、ユーザー質問を1つの指示文（プロンプト）にまとめるフェーズです。

ざっくり言えば「以下の参考資料を踏まえて、ユーザーの質問に答えてください」というテンプレートに、文書と質問を埋め込むイメージです。

G: 生成（Generation）

組み立てた指示文を LLM（Claude / GPT-4 / Gemini）に投げ、回答を生成させます。

このとき、回答に「どの文書を参考にしたか」を明示させると、ユーザーの信頼性確認に役立ちます（後述）。

LLM 自体の入門（5 系統の代表と業務での使い分け）は別記事の LLM とは で日常のたとえを使って整理しています。RAG は LLM の応用形なので、土台が曖昧な方は併読をおすすめします。

なぜ普通のAIだけではダメなのか

📖 この章で使う用語

  • モデルカットオフ（学習の打ち切り日）：LLM が「いつまでのデータで学習を終えたか」の日付。それより新しい情報は知らない。
  • トークン：AI が言葉を扱う最小単位。タクシーのメーターのように、長く話せば話すほど料金が上がる。

「ChatGPTにそのまま質問すればいいのでは？」と感じる方は多いと思います。営業時代の私もそう思っていました。実際、Webで完結する一般知識はそれで十分です。

ただし、業務で次のような要件が出てくると、ChatGPT単体では成立しなくなります：

  • 最新情報を扱いたい：モデルカットオフより後のニュースや更新を AI は知らない
  • 社内固有データを扱いたい：自社の仕様書・議事録・FAQ は、そもそも AI が学習していない
  • 回答の根拠を示したい：「どの社内文書を参照したか」を明示しないと、業務利用は難しい
  • コストを抑えたい：全ドキュメントを毎回プロンプトに詰めるとトークン料金が膨れ上がる

これらの問題を**「検索を組み合わせることで」解決する**のが、RAGの本質です。

RAGアーキテクチャ：データの流れを図で

📖 この章で使う用語

  • インデックス：本の巻末についている「索引」のような、検索を高速化するための事前準備データ。
  • チャンク：長い文書を、検索しやすいサイズ（500-1000字程度）に切り分けた断片。長い議事録を見出しごとに分けるイメージ。

実装時のデータの流れを図にすると、こうなります。

[① 事前準備フェーズ（最初に1回やる）]
  社内ドキュメント
    → チャンクに分割（500〜1000字程度）
    → 「意味の数値表現」に変換
    → ベクトルDB（後述）に保存
       ↑ ここまでが「インデックス構築」

[② リアルタイム検索フェーズ（毎回の質問で動く）]
  ユーザー質問
    → 「意味の数値表現」に変換
    → ベクトルDB から、近い意味の文書を取得（上位3〜10件）
    → 取得した文書＋質問 → 指示文（プロンプト）に組み立て
    → LLM が推論
    → 回答（参照元の文書名つき）

ポイントは「事前のインデックス構築」と「毎回のリアルタイム検索」の2フェーズに分かれていることです。インデックスは一度作れば使い回せますが、ドキュメントが更新されたら作り直しが必要になります。

ベクトルDBと「意味の数値表現」をたとえで理解する

📖 この章で使う用語

  • 埋め込み（embedding、エンベディング）：テキストを「意味を表す数字の並び」に変える操作。「カレー」と「シチュー」を地図上で近い場所に置くような変換。
  • ベクトル：「数字の並び」のこと。「身長, 体重, 年齢」のような3つの数字の組も、ベクトルの一種。
  • ベクトルDB：たくさんのベクトルを保存して、「あるベクトルに近いものを高速で見つけられる」データベース。**本屋の「ジャンル別の棚」**に近い役割。

「埋め込み」「ベクトル」と聞くと身構えますが、業務で使う分にはざっくり次のように理解しておけば十分です。

「埋め込み」って結局なに？

  • テキストを「1000個くらいの数字の並び」に変換したものが「埋め込みベクトル」
  • 意味が似ているテキストは、ベクトルとしての**「位置」が近く**配置される
  • 例：「営業」と「セールス」は地図上で近い／「営業」と「天気」は遠い
  • この変換は OpenAI / Anthropic / Google などの 埋め込みAPI を呼ぶだけで済む（自分で計算する必要はない）

「ベクトルDB」って結局なに？

  • 大量のベクトルを保存し、「あるベクトルに近いベクトルを高速で取得できる」DB
  • 用途別の選択肢：
    • 個人・最小構成：FAISS（メタ社製、Python ライブラリ、自分のPCで動く）
    • 小規模本番：Chroma、pgvector（PostgreSQL に追加できる拡張）
    • 大規模・サービス利用：Pinecone、Weaviate、Qdrant Cloud
    • クラウド純正：AWS OpenSearch、Vertex AI Vector Search

※私自身、業務ではこの中の複数を場面に応じて使い分けています。選定の軸は「データのサイズ」「既存基盤との相性」「運用コスト」の3つで、最初の検証は手元で動く小規模なものから始めることが多いです。

動く最小サンプル：Pythonで20行のRAG

📖 この章で使う用語

  • パッケージ（ライブラリ）：他の人が作って公開している「便利な機能の詰め合わせ」。本記事では anthropic、sentence-transformers を使う。
  • 内積（ないせき）：2つのベクトルがどれくらい「同じ方向を向いているか」を表す数字。営業の「お客様との温度感の一致度」みたいなもの。

実際に動くサンプルを置きます。Python と Anthropic API キーがあれば、手元のPCで動きます。

# 最小RAG：3つの文書から、質問に近いものを選んで Claude に渡す
import numpy as np
from anthropic import Anthropic
from sentence_transformers import SentenceTransformer

# 1. ドキュメント（実務ではこの数千倍の規模）
docs = [
    "営業職から未経験エンジニアに転職する場合、最初の3ヶ月で勉強する内容は…",
    "RAGの最小構成は、文書チャンク・埋め込み・ベクトルDBの3点セットです。",
    "Claude Code は、CLIで動くAnthropic公式のコーディング支援ツールです。",
]

# 2. テキスト→ベクトルに変換するモデル（自分のPCで動く、API不要）
embedder = SentenceTransformer("sonoisa/sentence-bert-base-ja-mean-tokens-v2")
doc_vectors = embedder.encode(docs)

# 3. ユーザー質問と、検索処理
query = "RAGってどんな仕組みですか？"
q_vector = embedder.encode([query])[0]
similarities = doc_vectors @ q_vector  # 内積で「近さ」を計算
best_idx = int(np.argmax(similarities))
context = docs[best_idx]  # 一番近かった文書

# 4. Claude に「参考資料つき」で質問を投げる
client = Anthropic()
response = client.messages.create(
    model="claude-3-5-sonnet-20241022",
    max_tokens=512,
    messages=[
        {
            "role": "user",
            "content": (
                f"以下の参考資料を踏まえて、ユーザーの質問に答えてください。\n\n"
                f"参考資料：\n{context}\n\n"
                f"質問：{query}"
            ),
        }
    ],
)
print(response.content)

ここで起きていることは：

  1. 3つの文書を、それぞれベクトル（数字の並び）に変換する
  2. ユーザー質問もベクトルに変換する
  3. もっとも「向きが似ている」文書を選ぶ（実務では FAISS で高速検索）
  4. その文書を Claude に「参考資料」として渡し、質問への回答を作らせる

この最小サンプルから、文書数を増やす・FAISS で検索を高速化する・複数文書を上位3〜10件で取得する、と段階的に拡張すれば、業務RAGの土台になります。

主要なフレームワーク・ツール

📖 この章で使う用語

  • フレームワーク：エージェントやRAGを組み立てるための「型」「設計図セット」。
  • マネージドサービス：自分でサーバを管理せず、お金を払って使う形のクラウドサービス。

2026年5月時点で、RAG構築に使われる代表的なツール群です。

役割候補
フレームワーク（全体の組み立て）LangChain、LlamaIndex、Haystack
埋め込みAPIOpenAI Embedding、Cohere Embed、Voyage AI
ベクトルDB（自PCで動く）FAISS、Chroma
ベクトルDB（マネージドサービス）Pinecone、Weaviate、Qdrant、pgvector
LLMClaude 3.5 Sonnet、GPT-4o、Gemini
評価ツールRagas、TruLens、自前のNotion管理

私自身、業務ではフレームワークなしで Anthropic / OpenAI SDK を直接叩く実装と、LlamaIndex の高水準APIを使う実装の両方を場面で使い分けています。複雑な前処理が多いときはフレームワーク、シンプルな構成なら直接実装、というのが現状の使い分け基準です。

私が業務で組んでいるRAG（抽象レベルでの紹介）

私の現職では、社内ドキュメント検索のRAGを業務プロダクトに組み込んでいます。具体的な業界や社名は伏せますが、構成の輪郭はこんな形です：

  • 社内ドキュメント（数千件規模）を、定期実行のジョブで埋め込み・インデックス化
  • ユーザーは社内システム上から自然文で質問
  • RAG が関連3〜5チャンクを取得 → Claude / Gemini に渡して回答生成
  • 回答には参照元の文書リンクを併記（信頼性確保）

学びとして特に効いたのは、後述する「評価設計」を最初から仕込んだことでした。

※私自身、生成AI領域の実務として「API利用 / RAG・エージェント / コーディングアシスタント / 全社推進」の4領域を業務で扱っています。RAGはその中心的なテーマです。

RAG を「エージェント化」する具体手順（社内文書に対する自律的な検索→回答の組み立て、4 ルートの構築方法）は、別記事の AIエージェント 作り方 で扱っています。

RAGを使うべき場面 vs 使わない方がいい場面

📖 この章で使う用語

  • ファインチューニング：AIモデル自体を「追加で学習させる」こと。新人にゼロから話し方を覚えさせるイメージ。
  • ハルシネーション：AI が自信満々に間違った答えを返す現象。
  • レイテンシ（応答時間）：問い合わせを送ってから返ってくるまでの待ち時間。

RAGは銀の弾丸ではありません。「向いている場面」と「無理に使うと痛い場面」を整理しておきます。

RAGが向いている

  • 最新情報や独自データを回答に組み込みたい
  • 回答の根拠（参照元）を明示したい
  • データ量が多くてプロンプトに全部詰め込めない
  • データの追加・更新が頻繁で、ファインチューニングのコストが見合わない

RAGが向いていない / 注意が必要

  • 一般知識のQ&A（普通のAI単体で十分）
  • 数値計算や論理推論（RAGより、AIエージェントの「道具呼び出し」のほうが向く）
  • 文書が矛盾だらけ・古いまま（RAGは「正しい検索結果」が前提）
  • リアルタイム性が極端に重要（ベクトル検索の応答時間が問題になる）

「RAGを入れればなんとかなる」と思って入れると、データ品質と評価設計でつまずきます。

未経験から最初に触る一歩

📖 この章で使う用語

  • 写経（しゃきょう）：他人のコードをそのまま打ち込んで動かしてみること。最初の理解にはとても効く。
  • 環境構築：プログラムが動くように、PC に必要なものを揃える作業。

「私はエンジニアではないけれど、RAG を触ってみたい」という方向けの順序です。

  1. 環境準備：Python 3.11 以降を入れる
  2. APIキー取得：Anthropic または OpenAI で無料クレジット付きキー
  3. 最小サンプル写経：本記事のコードをそのまま実行（30分以内に動くはず）
  4. 文書数を増やす：3件 → 30件、自分のメモやブログ記事を使う
  5. FAISS で高速検索化：scikit-learn の処理を FAISS に置き換え
  6. LangChain / LlamaIndex の高水準APIを試す：フレームワークのありがたみを感じる
  7. 評価設計を入れる：手元で10〜20件の「正解パターン」を作り、合否を計測

ここまでで週末3回ぶんくらいです。API キーの取得まわりは、姉妹記事 ChatGPT 始め方 と Claude Code 始め方 でそれぞれ手順を書いています。

なお、RAG単体の上位概念として「AIエージェント」があります。エージェントは「検索→生成」の流れを自分で何度も繰り返す仕組みなので、RAGを理解した後の良い次の一歩です。詳しくは AIエージェントとは で扱っています。

よくある質問

Q1. RAGとファインチューニングは何が違うのですか？

A. RAGは「外部の文書を検索して回答に組み込む」アプローチ、ファインチューニングは「AIモデル自体を追加学習させる」アプローチです。最新情報や社内固有データの反映にはRAGが向いており、文体や振る舞いの変更にはファインチューニングが向いています。実務では両方を併用するケースもあります。

Q2. どんなデータでもRAG化できますか？

A. 原理的には文書化されたデータ（PDF / HTML / Markdown / 議事録など）なら可能です。ただし「データの質」が回答の質を直接決めます。古い情報・重複・矛盾を含むデータをそのまま入れると、RAGはむしろ精度が下がります。データクリーニングと評価設計が成否を分けます。

Q3. RAGを入れればハルシネーションは無くなりますか？

A. いいえ、無くなりません。RAGはハルシネーションを「減らす」効果が期待できますが、検索結果が不十分なときや、検索結果を誤って解釈したときに、相変わらず誤った回答が出ることがあります。「ハルシネーション対策の銀の弾丸」ではなく、「外部知識を参照させる仕組み」と捉えるのが正確です。

Q4. 個人で試すなら、いくらくらいかかりますか？

A. 最小サンプルなら無料枠で十分試せます。手元のPCにPython環境を作り、Anthropic / OpenAI の API キーを取得（無料クレジットあり）、FAISS や Chroma のような無料のローカル保存先を使えば、追加コストはほぼゼロで動かせます。本格運用に乗せると、ベクトルDBの利用料が月数百〜数千円から発生します。

Q5. 社内データを使うときのプライバシーは大丈夫ですか？

A. 使うAPIプロバイダーのデータ取り扱いポリシーを事前に確認しておくのが安全です。Anthropic / OpenAI / Google ともに、APIで送信したデータをデフォルトでは学習に使わない方針を公表していますが、契約形態によって異なります。さらに厳格な要件がある場合は、AWS Bedrock / Azure OpenAI のようなクラウド事業者経由か、自分のPC上で動かす方法（ローカルLLM）の検討が現実的です。

まとめ

  • RAGは「AIに、社内資料を見ながら答えてもらう仕組み」で、最新情報や社内データを回答に反映できる
  • 構成は 検索（Retrieval）+ 拡張（Augmented）+ 生成（Generation） の3要素
  • 「埋め込み」と「ベクトルDB」を組み合わせて、意味的に近い文書を取得する
  • 最小サンプルは Python で20行、無料枠で動かせる
  • 業務RAGで効くのは「データの質」と「評価設計」。RAGを入れれば全部解決、という万能ツールではない
  • AIエージェントは RAG を内包しつつ、「複数ステップで自律的に動く」次の段階

私自身、業務で社内ドキュメント検索の RAG を運用しています。実装現場の感覚を込めて整理しました。本記事に対する質問・誤りのご指摘は send@bon-bon-tools.com までお願いします。

関連記事

出典

新しい記事のお知らせを受け取る → 登録（準備中）