RAG（検索拡張生成）は、生成AIに社内ドキュメントやナレッジを検索させ、その結果を根拠に回答させる仕組み。モデルを学習し直す（ファインチューニング）よりも速く・安く・安全に「自社向けAI」を作れるのが魅力です。本ガイドは、データ設計から検索・評価・運用までを実務目線で、図とともに整理します。
FIG.1 RAG ＝「検索（Retrieval）」＋「生成（Generation）」の2段構え
ポイントは、LLMが“知ったかぶり”をしやすい領域（規程・製品仕様・契約・FAQ・手順書）ほどRAGが効くこと。逆に、社内データに存在しない情報まで正確に当てる用途には向きません。
01標準アーキテクチャの全体像
典型的なRAGは「取り込み → 利用 → 改善」の3フェーズ・9工程で動きます。各段の質が積み上がって最終品質になります。
FIG.2 取り込み（1–5）→ 利用（6–8）→ 改善（9）の標準パイプライン
つまずきやすいのは前半の前処理・チャンク化（地味だが効く）と、後半の検索（精度のボトルネックになりやすい）。以降で要所を掘り下げます。
02ユースケースは「質問の型」で決める
RAGは万能ではないので、最初に質問の型を定義すると成功率が上がります。まずは「検索型」から始めるのが鉄板です（評価しやすく、社内の信頼も取りやすい）。
検索型
該当箇所を探して要約。例：経費精算のルールは？ 最初の一歩に最適。
手順型
社内手順をステップ化。例：障害時の一次対応は？
判断支援型
規程や仕様を根拠に条件分岐。例：このケースは返品対象？
03データ整備は“やりすぎない”
「完璧にクレンジングしてから…」とやりがちですが、RAGでは価値の高いデータから小さく始めるほうが進みます。優先順位の目安は次の通り。
- FAQ・問い合わせ履歴（質問文がそのまま検索キーになる）
- 規程・マニュアル（根拠が明確で評価しやすい）
- 製品仕様・リリースノート（更新頻度が高いほどRAGが効く）
- 議事録・チャットログ（ノイズが多いので後回し推奨）
PDFが多い場合はOCR品質がボトルネックになります。スキャンPDFが混じるなら、まずは文字が取れる状態かを確認しましょう。
04チャンク設計：地味に効く要所
チャンク（文章断片）の切り方で検索精度は大きく変わります。次を出発点にすると扱いやすいです。
FIG.3 見出し・条項で区切り、段落をまたぐ参照のため少し重ねる
- チャンク長：300〜800トークン程度（日本語は概ね600〜1600文字から検討）
- オーバーラップ：50〜150トークン（段落をまたぐ参照のため）
- 単位：見出し（h2/h3相当）や条項（第○条）で区切るのが強い
構造のある文書は、見出し＋条項番号＋改訂日などをメタデータに持たせると、後段のフィルタが効いて一気に賢くなります。
05検索品質を上げる
RAGの精度が出ないとき、原因はだいたい検索です。まず押さえたいのは、ベクトルとキーワードの得意分野の違いです。
| ベクトル検索 | キーワード検索 |
|---|---|
| 言い換え・表記ゆれに強い | 型番・条文番号など一致が重要な情報に強い |
| 意味の近さで拾う | 完全一致で確実に拾う |
両者を組み合わせるハイブリッド検索が定番。さらに再ランキングで「広く拾って、厳しく絞る」と精度が安定します。
FIG.4 上位20件 →（再ランキング）→ 上位5件に絞ってLLMへ
加えてメタデータフィルタ（部署・製品・年度・文書種別）でノイズが激減します。人事規程なら適用会社・改訂版を必ず持たせたいところ。
06プロンプト設計：根拠を読ませる書き方
検索で取れた文書をただ貼るだけだと、LLMが都合よく補完してしまいます。次の方針が要です。
- 根拠以外で断定しない（根拠にない場合は「不明」と言わせる）
- 引用（どの文書のどの部分か）を必須にする
- 意図確認が必要なときは追加質問を返す
RAGの品質は、モデルではなく「根拠の渡し方」で決まる。
プロンプト例（方針部分）
あなたは社内ナレッジに基づき回答するアシスタントです。提示された「根拠」からのみ結論を作り、根拠にない推測はしないでください。回答には根拠の引用（文書名・セクション）を必ず含めてください。根拠が不足する場合は、不足情報と確認質問を返してください。
07ツール選定：まず“作れる速度”を優先
フルスクラッチでも可能ですが、選択肢は豊富です。よく使われる構成例（自社要件で取捨選択でOK）。
- オーケストレーション：LangChain / LlamaIndex
- ベクトルDB：Pinecone / Weaviate / Milvus / PostgreSQL（pgvector）
- 検索（キーワード）：Elasticsearch / OpenSearch
- 評価：RAGAS、独自テストセット＋自動採点
- 監視：プロンプト・検索クエリ・ヒット文書・回答・コスト・遅延のログ基盤
小規模ならpgvector＋シンプル実装でも十分戦えます。規模が増えたら専用ベクトルDBへ移行する流れが多いです。
08評価：テスト問題集が最強の資産
改善を回すには、社内の質問に近い評価用Q&Aセットが必須です。まずは30〜100問でも十分価値があります。見る指標は次の3つに絞ると迷いません。
- Retrieval品質：正しい根拠が上位K件に入るか（例：Top-5 hit率）
- 回答品質：結論が合っているか、過不足はないか
- 根拠整合：引用が結論を本当に支えているか（捏造引用の検出）
Security & Access Control
一番怖いのは「見えてはいけない情報が見える」こと
社内RAGで現実的に怖いのは、幻覚よりも権限を超えた情報露出です。検索の段階でユーザー権限に応じて対象を絞るのが鉄則。下図のように、権限フィルタを通して“見える文書だけ”を根拠にします。
FIG.5 検索に ACL を反映し、見える文書だけを根拠にする
あわせて、個人情報・機密番号のマスキング（取り込み前）とログ管理（誰が何を聞き何が返ったか）を入れます。「取り込み時点で誰でも読めるベクトルデータができる」設計は事故のもと。文書単位の権限メタデータを必ず持たせましょう。
09よくあるつまずきと処方箋
- 答えがふわっとする：チャンクが短すぎ／引用必須でない → チャンク設計見直し＋引用強制
- 関係ない文書を拾う：メタデータが弱い／ハイブリッド未導入 → 種別・部署・製品でフィルタ＋キーワード併用
- 最新が反映されない：更新パイプラインがない → 差分取り込み＋改訂日メタデータ
- コストが高い：拾いすぎ／長文コンテキスト → Top-K削減、再ランキングで絞り、要約して投入
10最短で成果を出す4週間ロードマップ
対象業務とデータを決める
問い合わせが多い領域を1つ選ぶ（例：社内ITヘルプ）。データを50〜200本集める（FAQ＋手順書が理想）。
最低限のRAGを動かす
チャンク化＋埋め込み＋ベクトルDB格納。Top-5で検索→LLM回答を引用付きで返す。
検索精度を上げる
ハイブリッド検索、メタデータ整備。評価セット30〜50問を作り改善を可視化。
運用の土台を作る
権限（ACL）とログ、更新パイプラインを整備。社内クローズドで試験運用し、質問ログを次の改善材料に。
11まとめ
RAG構築は、モデル選び以上にデータ設計・検索設計・評価設計が勝負です。小さく始めて、質問ログと評価セットを育てるほどAIは賢くなります。まずは「よく聞かれる質問」をひとつ選び、引用付きで答えられるところから進めましょう。
