· updated

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

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

結論から言うと、RAG は LLM に「社内資料を見ながら答える目」をつける仕組みで、ChatGPT が知らない最新情報や社内固有データを回答に反映させる定番アプローチです。本記事では、RAG の定義、データの流れ、ベクトル DB の役割、Python の最小サンプル、業務での落とし穴までを、現役の生成AIエンジニア視点で整理します。「ベクトルDB」「埋め込み」が初耳でも、各章のはじめに用語の噛み砕き解説を置いたので止まらず読めるはずです。

RAGの正体｜「AIに社内資料を見ながら答えてもらう仕組み」と、なぜ普通のAIでは足りないか

📖 この章で使う用語

  • R（Retrieval、リトリーバル）：検索。A（Augmented）：補強・拡張。G（Generation）：生成。
  • LLM（大規模言語モデル）：ChatGPT / Claude / Gemini の正体。膨大な文章を学習した「文章を予測する装置」。
  • モデルカットオフ：LLM が「いつまでのデータで学習を終えたか」の日付。それより新しい情報は知らない。
  • トークン：AI が言葉を扱う最小単位。タクシーのメーターのように、長く話すほど料金が上がる。

要点を3行で：

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

業務での RAG 適用が他の AI 活用とどう並ぶかは、別記事 AI 業務効率化 事例 の 5 領域 × 5 職種マトリクスで整理しています。RAG が「全社推進の中でどの位置にくるか」が見えると、技術解説が業務イメージに落ちやすくなります。

名前の意味：RAG＝「検索＋AI回答」

「RAG」は Retrieval-Augmented Generation（検索で拡張された生成）の頭文字です。営業時代の言い方なら、『顧客リストを横に置いて提案を作る』のと『記憶だけで提案する』の違いに近い。3つの構成要素はこう分かれます。

  • R: 検索（Retrieval） — 質問に関連する文書を外部の保管庫から引っ張る。質問を「意味の数値表現」（埋め込みベクトル）に変換し、意味が近い文書を上位3〜10件取り出して「参考資料」にする。
  • A: 拡張（Augmented） — 取り出した文書と質問を1つの指示文（プロンプト）にまとめる。「以下の参考資料を踏まえて答えてください」というテンプレートに文書と質問を埋め込むイメージ。
  • G: 生成（Generation） — 組み立てた指示文を LLM（Claude / GPT-4 / Gemini）に投げて回答させる。回答に「どの文書を参考にしたか」を明示させると信頼性確認に役立つ（後述）。

LLM 自体の入門は別記事の LLM とは で日常のたとえを使って整理しています。RAG は LLM の応用形なので、土台が曖昧な方は併読をおすすめします。

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

Webで完結する一般知識なら ChatGPT 単体で十分です。営業時代の私もそう思っていました。ただし業務で次の要件が出ると成立しなくなります。

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

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

RAGの仕組み｜データの流れと、ベクトルDB・埋め込みの正体

📖 この章で使う用語

  • インデックス：本の巻末の「索引」のような、検索を高速化する事前準備データ。
  • チャンク：長い文書を検索しやすいサイズ（500-1000字程度）に切り分けた断片。議事録を見出しごとに分けるイメージ。
  • 埋め込み（embedding）：テキストを「意味を表す数字の並び」に変える操作。「カレー」と「シチュー」を地図上で近くに置く変換。
  • ベクトル：「数字の並び」。「身長, 体重, 年齢」のような組も一種。
  • ベクトルDB：たくさんのベクトルを保存して「近いものを高速で見つけられる」DB。本屋の「ジャンル別の棚」に近い。

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

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

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

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

「埋め込み」と「ベクトルDB」をたとえで理解する

身構える単語ですが、業務で使う分にはざっくり次の理解で十分です。

  • 埋め込み：テキストを「1000個くらいの数字の並び」に変換したものが埋め込みベクトル。意味が似たテキストは「位置」が近く配置される（「営業」と「セールス」は近い／「営業」と「天気」は遠い）。変換は OpenAI / Anthropic / Google などの埋め込みAPI を呼ぶだけで済み、自分で計算する必要はない。
  • ベクトルDB：大量のベクトルを保存し、「あるベクトルに近いものを高速取得できる」DB。

ベクトルDBの用途別の選択肢：

規模・用途候補
個人・最小構成（自PCで動く）FAISS（メタ社製 Python ライブラリ）
小規模本番Chroma、pgvector（PostgreSQL 拡張）
大規模・サービス利用Pinecone、Weaviate、Qdrant Cloud
クラウド純正AWS OpenSearch、Vertex AI Vector Search

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

実装する｜Python 20行の最小サンプルと、主要フレームワーク

📖 この章で使う用語

  • パッケージ（ライブラリ）：他の人が作って公開している「便利な機能の詰め合わせ」。本記事では anthropic、sentence-transformers を使う。
  • 内積（ないせき）：2つのベクトルがどれくらい「同じ方向を向いているか」を表す数字。営業の「お客様との温度感の一致度」みたいなもの。
  • フレームワーク：RAGを組み立てるための「型」「設計図セット」。
  • マネージドサービス：自分でサーバを管理せず、お金を払って使うクラウドサービス。

実際に動くサンプルを置きます。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 に「参考資料」として渡して回答を作らせる——の4ステップです。

この最小サンプルから、文書数を増やす・FAISS で検索を高速化する・上位3〜10件で取得すると段階的に拡張すれば、業務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のリアル｜実装現場・向き不向き・未経験からの最初の一歩

📖 この章で使う用語

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

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

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

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

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

RAG を「エージェント化」する具体手順は、別記事の AIエージェント 作り方 で扱っています。

費用の感覚も補足すると、最小サンプルは手元の PC や API の無料枠だけでも十分に試せます。区切りが来るのは「作った RAG を 24 時間動かしたい」「常時アクセスできる場所に置きたい」と思った段階で、そこで月数百円〜千円台の VPS（自分専用の仮想サーバ）が現実的な置き場所になります。あくまで「常時公開したくなったら」の選択肢です。

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

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

RAGが向いている

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

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

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

「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で効くのは「データの質」と「評価設計」。入れれば全部解決、という万能ツールではない
  • AIエージェントは RAG を内包しつつ、「複数ステップで自律的に動く」次の段階

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

関連記事

出典

PR

この記事に関連するサービス

ConoHa VPS
手元の Mac で重いなら、GPU 付き VPS という手

ローカルLLM や自作 MCP サーバーを「常時動かす／重いモデルを回す」段階になると、手元マシンの限界が見えてきます。時間課金の VPS なら、必要なときだけ GPU を借りて検証できます。申し込み前に、料金プランとスペックだけ見比べてみてください。

まず料金とスペックを見てみる →
Xserver VPS
安定運用したいサーバー用途に

検証から一歩進めて「外から叩けるエンドポイントとして常時公開したい」段になったら、安定したVPSが要ります。RAG の社内検索 API や MCP サーバーの本番置き場の候補です。申し込み前に、プラン内容と料金だけ確認できます。

プランと料金を見てみる →
新しい記事のお知らせを受け取る → 登録（準備中）