RAGの作り方｜Python実装サンプル付き・社内ナレッジ検索の構築手順【2026年版】

社内の議事録・マニュアル・仕様書が増えすぎて、どこに何が書いてあるか誰も把握できない。Q&Aチャットボットを作ってみたがハルシネーション（もっともらしい嘘）が多くて使い物にならない。こうした課題を解く現実解が RAG（Retrieval-Augmented Generation、検索拡張生成） です。本記事ではPython50行の動くサンプルを出発点に、チャンク分割・embedding・ベクトルDB・LLM呼び出しまでの実装手順を、自社SaaS『PigeonCloud』（300社導入）で本番運用しているAIファイル検索の3ヶ月拡張ログ付きで解説します。

RAG（検索拡張生成）とは？社内ナレッジ検索の仕組み

RAGは 「検索」と「生成」を組み合わせた仕組み です。3行で言えば次の通り。

LLM単体との違い3点

最小構成で動くRAGを作る｜Python 50行サンプル

まずは コピペで動く最小RAG を載せます。PostgreSQLにpgvector拡張を入れた前提で、ドキュメント読み込み→チャンク分割→embedding生成→ベクトル検索→LLM呼び出しまで50行前後で書き切ります。2026年7月時点のOpenAI SDKとAnthropic SDKを使用（コード中のモデルは現行ラインナップのまま動きます）。

必要ライブラリ

pip install openai anthropic psycopg2-binary pgvector tiktoken

CREATE TABLE docs (
  id SERIAL PRIMARY KEY,
  content TEXT NOT NULL,
  embedding VECTOR(1536)
);
CREATE INDEX ON docs USING ivfflat (embedding vector_cosine_ops) WITH (lists=100);

実装コード（50行）

import os
import psycopg2
from openai import OpenAI
from anthropic import Anthropic

oai = OpenAI(api_key=os.environ["OPENAI_API_KEY"])
claude = Anthropic(api_key=os.environ["ANTHROPIC_API_KEY"])
conn = psycopg2.connect(os.environ["DATABASE_URL"])

def chunk_text(text: str, size: int = 500) -> list[str]:
    """固定長チャンク分割（500字）。本番ではセマンティック分割も検討"""
    return [text[i:i+size] for i in range(0, len(text), size)]

def embed(text: str) -> list[float]:
    """text-embedding-3-small で1536次元ベクトルに変換"""
    resp = oai.embeddings.create(model="text-embedding-3-small", input=text)
    return resp.data[0].embedding

def ingest(docs_dir: str):
    """ディレクトリ内の.txtを読み込んでベクトルDBに格納"""
    cur = conn.cursor()
    for fname in os.listdir(docs_dir):
        if not fname.endswith(".txt"): continue
        with open(f"{docs_dir}/{fname}") as f:
            for chunk in chunk_text(f.read()):
                vec = embed(chunk)
                cur.execute(
                    "INSERT INTO docs (content, embedding) VALUES (%s, %s)",
                    (chunk, vec)
                )
    conn.commit()

def retrieve(query: str, k: int = 5) -> list[str]:
    """cos類似度 top-k件を取得"""
    qvec = embed(query)
    cur = conn.cursor()
    cur.execute(
        "SELECT content FROM docs ORDER BY embedding <=> %s::vector LIMIT %s",
        (qvec, k)
    )
    return [row[0] for row in cur.fetchall()]

def answer(query: str) -> str:
    """検索結果を文脈としてClaudeに回答させる"""
    context = "\n---\n".join(retrieve(query))
    prompt = f"以下の社内文書のみを根拠に回答してください。\n\n{context}\n\n質問: {query}"
    resp = claude.messages.create(
        model="claude-haiku-4-5",
        max_tokens=1024,
        messages=[{"role": "user", "content": prompt}]
    )
    return resp.content[0].text

if __name__ == "__main__":
    ingest("./docs")
    print(answer("有給休暇の申請方法は？"))

コードの要点

このサンプルはあくまで出発点です。実運用では次章の「8ステップ」で評価パイプラインと運用監視を足していきます。

RAG実装の技術ステップ8つ（エンジニア向け）

最小構成から本番運用レベルまでの流れを、エンジニアが手を動かす順番で並べます。

RAG設計で最初に決める4つの判断

RAGの精度は コードの巧拙よりも設計判断 で8割決まります。2026年7月時点でプロジェクト着手前に決めておく4点を整理しました。

ベクトルDB比較表

実装に使う技術スタック（2026年7月時点の主流構成）

RAG実装で採用されている技術スタックを、LLM・embedding・フレームワークの3軸で整理します。2026年7月時点の情報です。実際、本記事の4月公開からの3ヶ月で3社とも主力モデルが入れ替わりました。この節は入れ替わりに合わせて更新しています。

LLMの選び方（3社×3軸）

回答生成に使うLLMは Claude・OpenAI・Google の3社を要件で使い分け るのが2026年時点の主流です。費用相場や総合比較は AI受託開発の費用相場2026年版 を参照してください。

embeddingモデル

検索精度の土台になるembeddingモデルは、2026年時点で以下が実用水準です。

フレームワーク選び（LangChain / LlamaIndex / 自前実装）

実装フレームワークは3択です。2026年7月時点の状況を比較表にまとめました。

弊社では 自前実装 で回しています。フレームワークの抽象化が新モデル対応で足枷になるケースが増え、薄いコードのほうが3社LLM切り替えや評価パイプライン追加が速いと判断したためです。

自社SaaS PigeonCloud の RAG 運用ログ｜3ヶ月で辿った段階的拡張

自社SaaS『PigeonCloud』（ロフタル運営・300社導入）にはAIファイル検索機能がRAGで組まれており、本番トラフィックで運用中です。着手から3ヶ月でどう拡張したか、時系列で残します。いわゆる完成形を一発で作ったわけではなく、評価パイプラインの数値を見て次の打ち手を決めていった記録です（ログ中のモデル名・数値は検証当時のものです）。

Month 1 — PoC段階（社内10名評価）

得られた知見は2つ。固定長800字だと社内議事録のように短文の集まりではチャンク境界が悪く、質問と関連する文が半分に割れるケースが散見された。もうひとつは「わかりません」の返し方で、閾値設定せずに top-5 を必ず渡す実装にしていたため、関係ない文書でも無理やり回答を作ってしまう挙動が出た。

Month 2 — 本番展開（対外公開）

top-5ヒット率が Month 1末の72%から85%へ改善。閾値を入れたことで「わかりません」回答が全体の約8%発生するようになったが、ユーザー評価では 嘘の回答より"わからない"のほうが信頼できる というフィードバックが多数で、採用を維持している。

Month 3 — 継続改善（3社LLM動的ルーティング）

単純検索の7割がHaiku 4.5で捌けるようになり、応答時間の中央値が3.2秒から2.1秒に短縮。筆者の経験では、3社LLMルーティングは 運用初月に入れるより、評価パイプラインが整ってから入れる ほうが判断根拠が明確になります。

裏を返すと、この規模の改善サイクルを回し続けるには評価データの整備とチューニングに継続的なリソースが要ります。社内に割ける人員がいない場合は、生成AIの受託開発のように外部の運用ノウハウごと借りる進め方も現実的です。

RAGの精度を上げる実践テクニック5選

最小構成で動いたあと、精度を継続的に上げる打ち手を5つ紹介します。どれも 評価パイプラインの数値で効果を測れる範囲 で導入します。

2026年のトレンドとしては、検索を1回で終える固定パイプラインではなく、LLMが必要に応じて検索を繰り返す Agentic RAG 構成への移行が進んでいます。ただし評価パイプラインなしにエージェント化しても精度改善の判断ができないため、本記事の8ステップを固めてからの発展形と捉えるのが現実的です。

よくある質問（FAQ）

まとめ｜RAG構築は最小構成から始めて段階的に拡張する

RAGはPython50行の最小構成で動作確認し、評価パイプラインの数値を見ながらチャンク・embedding・LLMを順に触って精度を上げる流れが現実解です。いきなり完成形を目指すとチューニングすべき変数が多すぎて収束しません。

本記事で扱った設計判断4つ（チャンク分割戦略・embeddingモデル・ベクトルDB・検索閾値）を先に決め、3社LLMのどれを主力にするかは評価パイプラインの数値が出てから選ぶ。この順序だけ守れば、PoCから本番運用までの道筋が見えます。

次に読む