RAGとは？生成AIの精度を劇的に上げる技術を実装経験から解説
RAGって、結局なんなのか
「RAG」という言葉、最近やたら目にするようになりましたよね。ChatGPTやClaudeを使い始めた会社が次のステップとして検討するのが、だいたいRAGです。
うちのところにも「社内のデータをAIに学習させたい」「自社のナレッジをAIで検索できるようにしたい」というご相談がよく来るんですが、そういう要望に対して最初に提案するのがこのRAGです。
RAG（Retrieval-Augmented Generation）を日本語に訳すと「検索拡張生成」。名前だけ聞くと難しそうですが、仕組みそのものはそんなに複雑じゃない。
一言で言うと「AIが回答を生成する前に、関連情報を検索して参照する仕組み」です。
普通のChatGPTやClaudeは、学習済みの知識から回答を生成します。でもRAGを使うと、回答生成の直前に「自社のドキュメント」「最新のデータ」「社内FAQデータベース」などから関連情報を取ってきて、それを踏まえて回答を生成できる。これがRAGの本質です。
---
なぜRAGが必要なのか — 生成AIが抱える2つの問題
RAGが登場した背景には、生成AIが持つ根本的な課題があります。
問題1：ハルシネーション（幻覚）
生成AIは「もっともらしいウソ」をつきます。これをハルシネーション（幻覚）と呼びます。
例えば「わが社の規定では有給休暇は何日取れますか」と汎用のChatGPTに聞いても、当然ながら正確な答えは返ってきません。学習データに入っていないので、一般的な話をするか、最悪の場合は「らしい」回答を作り上げてしまう。
医療情報、法的な内容、数値データなど、正確さが求められる場面でのハルシネーションは深刻です。実際うちが支援したある会社では、汎用AIに社内ルールを質問したら全然違う回答が返ってきて、社員が混乱したというケースがありました。
問題2：学習データのカットオフ問題
大規模言語モデルには「知識のカットオフ」があります。学習データの収集を締め切った時点以降の情報は持っていない。
GPT-4の場合は2023年末あたり、Claudeも同様に比較的最近の情報までしか持っていない。でもビジネスの現場では「今日の製品情報」「今月の社内規定改訂」「今週の価格表」を参照したいわけです。
この2つの問題を解決するのがRAGです。自社のデータを検索して参照しながら回答するので、ハルシネーションが大幅に減り、最新情報にも対応できる。
---
RAGの仕組み — 3ステップで理解する
技術的な話が苦手な方でも分かるよう、できるだけ平易に説明します。
ステップ1：ドキュメントのベクトル化（エンベディング）
まずRAGを使うには、参照させたいドキュメント（社内マニュアル、FAQ、契約書など）を「ベクトル」という数値の羅列に変換します。これをエンベディング（Embedding）と呼びます。
「ベクトルって何？」ってなりますよね。簡単に言うと、文章の「意味」を数値で表現したものです。「犬」と「猫」は意味が似ているのでベクトル空間上では近い位置に置かれる、「犬」と「車」は遠い位置に置かれる、というイメージです。
このエンベディング処理に使うのが、OpenAIのtext-embedding-ada-002やtext-embedding-3-small、あるいはCohereのEmbeddingモデルなどです。
ステップ2：ベクトルデータベースへの保存
変換したベクトルデータは「ベクトルDB（ベクトルデータベース）」に保存します。
主なベクトルDBとしては：
- Pinecone：クラウドネイティブで使いやすい。スタートアップや中小規模に向く
- Weaviate：オープンソース。オンプレでも動かせる
- Chroma：ローカル環境でのプロトタイプに便利
- pgvector：PostgreSQLの拡張機能。既存のDB環境を活かせる
- Qdrant：高速でスケーラブル。本番環境向き
うちの案件ではPineconeかpgvectorを使うことが多いです。既存のPostgreSQL環境があるならpgvectorが追加コストなしで使えて便利。
ステップ3：検索→生成のフロー
ユーザーが質問すると、以下の流れで処理されます：
イメージとしては、試験会場で「参考資料持ち込みOK」になった感じ。AIが自分の記憶だけで答えるのではなく、関連資料を引いて答えられるようになる。
この検索の精度が、RAGシステム全体の品質を決める重要な要素です。
---
実際の導入事例
うちが実際に関わったケースや、よくある導入パターンを紹介します。
事例1：社内FAQチャットボット（製造業、社員200名）
課題：人事・総務への問い合わせが多く、担当者が対応に追われていた。よくある質問は決まっているのに、毎回同じ回答をしなければならない。
対応：就業規則、社内規定、よくある質問集（約300件）をRAGの検索対象として構築。Slackから質問できるチャットボットを実装。
結果：人事・総務への問い合わせが導入前比で約65%減少。残った問い合わせは本当に個別対応が必要なものだけになり、担当者の業務質が上がった。
ポイント：最初は「AIが間違ったことを言うのでは」という懸念があったが、回答の根拠となったドキュメントのリンクを一緒に表示する設計にしたことで、社員が自分で確認できるようになり、信頼度が上がった。
事例2：法律事務所の契約書検索システム
課題：過去に作成した数百件の契約書から、類似する条項や判例を探す作業に弁護士・パラリーガルが多くの時間を使っていた。
対応：契約書データをRAGに投入。「この条件に似た免責条項が過去の契約書にあれば探して」という自然言語での検索を可能に。
結果：類似条項の検索時間が従来の手作業と比べて約80%短縮。新しい契約書作成時の参考資料探しがゼロから始めなくて良くなった。
ポイント：機密性の高いデータを扱うため、クラウドサービスを使わずに自社サーバーにDeployする構成にした。ここはセキュリティ要件によって設計が変わる重要な判断ポイント。
事例3：ECサイトのカスタマーサポート自動化（小売業）
課題：注文状況、返品ポリシー、配送について同じ質問が繰り返されていた。サポートチームへの負担が繁忙期に集中していた。
対応：製品カタログ、FAQページ、配送ポリシーを検索対象にしたRAGを構築。チャット窓口に組み込み、初回対応をAIが担当。
結果：問い合わせの約70%をAIが自己完結で対応。サポートチームへのエスカレーション数が大幅に減少。
うちの場合は
Swaaabでも、自社のナレッジベース整理にRAGを活用しています。過去のプロジェクト事例、使ったライブラリの知見、クライアントからよくある質問への回答集などをRAGで検索できるようにしていて、新しいメンバーが過去の知見をすぐ引き出せる環境になっています。
これが意外と効いていて、「あのプロジェクトでどう解決したっけ」という調査時間がかなり短くなりました。
---
RAGの構築方法と技術選定のポイント
実際に構築する際の技術スタックと、選定で気をつけるべきポイントです。
主なフレームワーク
LangChainとLlamaIndexが現在の主流です。
- LangChain：汎用性が高く、エコシステムが豊富。複雑なチェーン処理を組みやすい。ただしアップデートが頻繁で破壊的変更も多い。
- LlamaIndex（旧GPT Index）：ドキュメントの読み込み・インデックス化に特化。RAGに特化した機能が充実していて、シンプルな構成ならLlamaIndexの方が学習コストが低い。
うちではLlamaIndexを使うことが多いです。RAG専用ならLlamaIndexの方が余計なことを考えなくていいので。
チャンキング戦略が肝
「チャンキング」とは、ドキュメントを検索しやすいサイズに分割することです。これがRAGの精度に大きく影響します。
固定長チャンキング（500トークンごとに分割）がシンプルですが、文章の途中で切れてしまう問題があります。意味のある単位で区切る「セマンティックチャンキング」の方が検索精度が上がりますが、実装コストも上がります。
最初は固定長で試して、精度が出なければセマンティックチャンキングを検討するのが現実的なアプローチです。
Re-rankingで精度を上げる
ベクトル検索で上位を取ったドキュメントが必ずしも最適とは限りません。Re-ranking（再ランキング）というステップを加えることで、検索結果をさらに絞り込めます。
Cohereのre-rankモデルや、BGE-rerankerなどが使えます。本番環境での品質を上げたい場合は検討する価値があります。
マルチモーダル対応
最近はテキストだけでなく、PDFの図表、画像内のテキストもRAGで検索できるようになってきました。設計書や製品カタログを検索対象にする場合は、GPT-4 Visionなどのマルチモーダルモデルとの組み合わせを検討する価値があります。
---
RAG導入でよくある失敗と対策
実際に構築してみると、いくつか「あるある」な罠があります。
失敗1：ゴミデータをそのまま入れる
「とりあえず社内の資料を全部入れよう」というアプローチは危険です。古い情報、誤った内容、未更新のドキュメントが混在していると、それを参照した回答も当然おかしくなります。
対策：インデックス化する前にデータクレンジングを行う。更新日でフィルタリングする。定期的に古いデータを削除または更新する仕組みを設計段階から組み込む。
失敗2：チャンクサイズが適切じゃない
チャンクが大きすぎると、関係ない情報も一緒に取得されてノイズになる。小さすぎると、文脈が失われて意味不明な断片が返ってくる。
対策：対象ドキュメントの種類によってチャンクサイズを変える。短いFAQ形式なら1質問・1回答を1チャンクにするのが自然。長文のマニュアルなら段落単位、あるいはセクション単位で切る。試行錯誤が必要な部分ですが、最初は500〜800トークンあたりを基準にすることが多いです。
失敗3：ハイブリッド検索を忘れる
ベクトル検索だけだと、製品コードや固有名詞の完全一致に弱いことがあります。「商品コード：ABC-12345の仕様を教えて」という質問に対して、ベクトル検索だけではうまく引っ張れないケースがある。
対策：ベクトル検索とキーワード検索（BM25など）を組み合わせた「ハイブリッド検索」を実装する。多くのベクトルDBがこれに対応しています。
失敗4：メタデータを活用しない
「2024年以降の資料だけを参照して」「営業部門のドキュメントのみ検索して」というフィルタリングをしたいなら、メタデータの設計が重要です。
対策：ドキュメントをインデックス化する際に、日付・部門・ドキュメント種別・バージョンなどのメタデータを付与する。検索時にこれらでフィルタリングできるようにする。最初から設計しておかないと後から追加するのが大変。
失敗5：評価の仕組みがない
「精度が上がった気がする」という感覚的な評価では、改善サイクルが回せません。
対策：RAGASやTruLensなどの評価フレームワークを使って、定量的に精度を測定する。回答の正確性（Faithfulness）、検索結果の関連性（Context Relevancy）、回答の網羅性（Answer Relevancy）を指標として追う。
---
ファインチューニングとの使い分け
よく混同される「ファインチューニング」との違いと使い分けを整理します。
そもそも何が違うのか
ファインチューニングは、ベースモデル（GPT-4やClaudeなど）をさらに自社データで追加学習させる方法です。モデルそのものが変わります。
RAGは、モデルを変えず、回答生成時に外部から情報を与える方法です。モデルは変わらず、プロンプトに情報を追加する形。
RAGが向いているケース
- データが頻繁に更新される（規定の改訂、価格表の変更など）
- 検索した情報の出典を示したい
- 特定のドキュメントを参照した回答が必要
- コストを抑えたい（ファインチューニングは高コスト）
- まずプロトタイプを素早く作りたい
うちの判断基準としては、まずRAGで試してみる、というのが基本方針です。 RAGで解決しない問題（特定の話し方・スタイルを身につけさせたい、特定ドメインの深い知識を持たせたいなど）に対してファインチューニングを検討するイメージ。
ファインチューニングが向いているケース
- 特定の口調・スタイルを一貫して使いたい
- ドメイン固有の専門知識を深く持たせたい（医療、法律など）
- レイテンシをとにかく下げたい（検索ステップがないので速い）
- 参照ドキュメントが変わらない静的な知識を扱う
実務的には、RAGとファインチューニングを組み合わせるのが最も強力な構成です。ファインチューニングでドメイン知識とスタイルを持たせ、RAGで最新情報を補完する。ただしコストと複雑さが上がるので、実際に使う用途に合わせて判断が必要です。
GraphRAGという新しい選択肢
最近注目されているのがMicrosoftが提案したGraphRAGです。ドキュメントをそのまま検索するのではなく、ドキュメント間の関係性をグラフ構造として持つことで、より複雑な質問に答えられるようになります。
「AさんとBさんの関係は？」「この製品群に共通する問題点は？」といった、複数ドキュメントにまたがる推論が必要な質問に強い。まだ実装コストが高めですが、複雑なナレッジベースを扱う場合は検討する価値があります。
---
RAGを始める前に確認すること
実装の話に入る前に、整理しておくべき点があります。
1. 何を検索対象にするか：すべてのドキュメントを入れればいいわけではありません。ユーザーがよく尋ねる内容に関連するドキュメントを優先する。
2. セキュリティ・権限設計：誰がどのデータにアクセスできるか。営業が財務データを参照できてしまう、というのは困る。ユーザーロールに応じた検索範囲の制限が必要になることが多い。
3. データ更新の運用：ドキュメントを更新したらRAGのインデックスも更新する必要がある。この運用フローを誰が、どのタイミングで行うかを最初に決めておく。
4. ユーザーへの期待値設定：RAGを導入しても、完璧な回答が返ってくるわけではありません。「根拠となった資料を確認してください」という文化も合わせて作らないと、かえって混乱を招く場合があります。
---
まとめ
RAGは、生成AIを「汎用ツール」から「自社専用AIアシスタント」に変えるための核となる技術です。
ハルシネーションの削減、最新情報への対応、社内ドキュメントの活用——これらの課題を持っている会社にとって、RAGは現時点でもっとも現実的で費用対効果の高いアプローチだと思っています。
ただし「RAGを入れた」で終わりじゃない。データ品質の維持、チャンキング戦略の改善、評価サイクルの運用——継続的な改善が精度を決めます。最初のプロトタイプは比較的素早く作れますが、本番品質に持っていくには相応の設計と運用が必要です。
広島でAI・DX推進を検討されている方、RAGの導入を具体的に進めたい方は、ぜひSwaaabにご相談ください。技術選定から実装、運用設計まで、一緒に考えていきます。
Written by
Swaaab編集部
広島を拠点に、AI開発・DX支援・Web制作を手がけるSwaaab株式会社の編集チーム。現場で得た知見をもとに、実践的な情報を発信しています。