はじめに
この記事では、RAGに関心はあるものの、「どこから実装を始めればよいのか」と迷っているエンジニアに向けて、実務で整理しておきたいポイントをまとめます。
扱うテーマは、RAGの基本構成、権限設計、そして精度改善の進め方です。
そもそもRAGとは
RAGとは、ユーザーの質問に対して関連する独自データを先に取得し、その情報をコンテキストとしてLLMに渡したうえで回答を生成させる仕組みです。
LLMにそのまま回答を任せるのではなく、あらかじめ参照する情報を絞り込むことが前提になるため、実装ではこの検索設計が重要になります。
この点が、「質問して、そのままLLMが答える」使い方との大きな違いです。
基本構成
RAGの流れは、とてもシンプルです。
まず、ユーザーが自然な言葉で質問します。
次に、その質問に関連する情報を独自データの中から探し、見つかった内容をLLMに渡します。
LLMは、その情報をもとに答えを組み立て、ユーザーへ回答を返します。
メダルゲームで考えるとわかりやすい
RAGは、ゲームセンターのメダルゲームで考えるとイメージしやすくなります。
台の中に入っているメダルが、社内文書やFAQなどの「情報」です。
そして、質問に合わせて必要なメダルを取りにいくクレーンアームが、RAGの検索にあたります。
取ってきたメダルをもとに、最後に景品が出てくるように、RAGも先に集めた情報を使ってLLMが回答を返します。
このたとえで大事なのは、どれだけ優秀なクレーンでも、台の中に入っていないメダルは取れないということです。つまりRAGの強みは、AIそのものが急に賢くなることではなく、どの情報を見せるかをこちらでコントロールできることにあります。
RAGで最初に考えるべきこと
RAGというと、「検索の精度をどう上げるか」や「どのモデルを使うか」に意識が向きがちです。
もちろんそれも大切ですが、実務ではその前に決めるべきことがあります。
それは、誰がどの情報を見てよいのかということです。
たとえば、同じ社内向けの仕組みでも、全員に見せてよい資料と、一部の人だけが見られる資料は違います。
この境界が曖昧なままRAGを作ると、検索の前提そのものが不安定になります。
だからこそ、RAGは「とにかく検索して答える仕組み」として考えるより、最初に見せてよい範囲を絞って、その中から探しにいく仕組みとして考えるほうが現実的です。
メダルゲームでいえば、最初から台の中に何でも入れてしまうのではなく、その人が触れてよいメダルだけを台に入れておく感覚に近いです。
1. NotebookLM / ChatGPTのプロジェクト機能と RAG の違いを、最初に整理しておく
ここは私も最初に混乱したポイントでした。
NotebookLMやChatGPTのプロジェクト機能も、過去に入れた情報を参照して回答できますし、見た目の体験はRAGとかなり似ています。
ただし、仕事で実装するときは「どこに責務があるか」が決定的に違います。
同じように見える理由
どちらも流れとしては、
「質問する → 情報を参照する → 回答する」
という形で動きます。
そのため、ユーザー視点では「アップロードした情報を使って答えてくれる仕組み」と見えやすく、違いがわかりにくいのも自然です。
NotebookLM / ChatGPTのプロジェクト機能はRAGを使っているのか
実務上は「RAG的な取得処理を内部で使っている可能性がある」と考えるのが自然です。
ただし、NotebookLM / ChatGPTのプロジェクト機能の内部実装詳細を本記事の情報だけで断定はできません。利用者側からは内部実装を制御しないマネージド機能として扱うため、自前RAGとは責務の位置が違います。
そのため「中でRAG的な処理が使われること」と「自分でRAGを設計運用すること」は分けて理解する必要があります。
実装上の違い（ここが重要）
NotebookLM / ChatGPTのプロジェクト機能は、便利な機能を利用する側です。
それに対してRAGは、検索・権限・評価の設計まで含めて、自分たちで体験を作る側になります。
たとえば、共有範囲やアクセス制御も、マネージド機能ではプランや設定に依存する部分があります。
そのため、利用機能として使う場合は、まずそのサービス側の共有仕様を確認する必要があります。
一方、自前のRAGでは、誰がどの情報を見てよいかを、アプリ側で明示的に設計しなければなりません。
つまり、似た体験に見えても、RAGは「使う仕組み」ではなく「作る仕組み」として考えるほうが、実務には合っています。
2. 本番RAGで先に決めるべきは「権限境界」
本番運用のRAGで、最初に壁になりやすいのは検索精度そのものではありません。
実際には、誰がどのデータを見てよいのかという線引きのほうが、先に重要になります。
そのため、ベクトル検索の前に、通常のリレーショナルな絞り込みを入れておく構成が重要です。
先に role / user_id によってアクセス可能なdocument_idを限定し、そのうえで検索に進む、という考え方です。
role / user_idで先にアクセス範囲を決める
「この role / user_id はどの情報にアクセスできるのか」を先に決めます。
そのうえで、Relational DBでアクセス可能な document_id の一覧を取得します。
ドキュメント側にも document_id や role などの metadata を持たせておくことで、Vector DBの検索時に 「見えてよいドキュメントの集合」だけを対象にした検索ができるようになります。
実装の流れ
流れとしては、次のように考えるとわかりやすいです。
- リクエスト時に
user_idとrole を受け取る - Relational DBでアクセス可能なドキュメントIDを先に取得する
- Vector DBへ送るクエリに、document_id を metadata filter として渡す
- metadata filterで候補を絞ったうえでベクトル検索する
- 返却前に結果を再度Relational DBで照合する（ダブルチェック）
このように、事前に絞る → RAGで検索する → 最後に再確認するという流れにしておくと、不要な推論コストを抑えつつ、権限漏れのリスクも下げやすくなります。
このあたりは、AIの実装というより、むしろWebアプリ側の設計に近い論点です。
RAGだけで完結する話ではない、という視点を持っておくと、設計の優先順位を整理しやすくなります。
3. 精度改善は「まず一本通す」から始める
RAGはデータ特性やドメインで効き方が変わるため、初手から完全設計を狙うより、まず最小構成で一本通す方が速いです。
まずはas-isで実装し、実際の結果を見ながら、うまくいかなかった部分を少しずつ直していく。この進め方のほうが、地味ではあっても再現性があります。
最初の進め方
初手では、次のような進め方が現実的です。
- まずはそのまま実装して、リクエストとレスポンスを確認する
- いきなり全ユーザーへ出さず、限定ユーザーや内部環境で検証する
最初から広く出すより、まず小さく試して挙動をつかむほうが、改善点を見つけやすくなります。
精度が出ない場合の次ステップ
期待した精度が出ない場合は、単にモデルを変える前に、周辺の設計を見直す余地があります。
- 元データを一度LLMに通して、構造を整理し直す
- metadataを追加して、permissionsベースの絞り込みを強める
- 評価するポイントを分解し、それぞれの評価方法を設計する
改善速度は評価設計に依存します。
何を良しとするかが曖昧なままだと、改善できたのかどうかも判断しにくくなります。
4. データ整備で意識しておきたいこと
RAGは検索の仕組みだけでなく、元データの整え方でも使いやすさが変わります。
そのため、初期段階からデータをどう揃えるかも意識しておくと、後の改善が進めやすくなります。
まずはMarkdownに寄せる
元データがExcel/CSV/Docsでも、まずはMarkdownへ寄せると構造を保ちやすくなります。
形式をある程度そろえておくことで、投入パイプラインをシンプルにしやすくなり、改善サイクルも回しやすくなります。
Chunkingは「サイズ」より「意味のまとまり」
Chunkingは、文書を検索しやすい単位へ分解する処理のことです。
このとき、文字数だけで区切るよりも、意味のまとまりで分けたほうが、取り出したときに解釈しやすくなります。
ただし、細かく分けすぎると文脈が欠けてしまうため、意味のわかりやすさと文脈の残し方のバランスが大切です。
5. AWSで組む場合の最小構成
AWSでRAGを組む場合は、最初から大きくしすぎず、役割を分けた最小構成で考えると整理しやすいです。
- Vector DB: OpenSearch（kNNによるベクトル検索）
- 権限管理と事前絞り込み: RDSなどRelational DB
- embeddingモデル: AWS系でも十分、最新性より安定性と一貫性を優先
- RAG向けagent: 特定の最強解はなく、retrieval精度とinstruction追従の安定性で判断
この構成の利点は、検索責務と権限責務を分離して運用しやすいことです。
一方で、構成要素が増える分だけ監視ポイントも増えるので、運用負荷を見積もりながら段階的に入れていくのが安全です。
まとめ
今回の学びは、RAGの成否を分けるのは「モデル選定」だけではなく、検索前の権限絞り込みと改善プロセス設計だという点です。
自分なりに整理すると、まず Relational DBで role / user_id に基づくアクセス制御を設計し、取得可能な document_id を絞り込み、最小構成で一本通した後にmetadataとデータ構造を改善する順番が再現しやすいと理解しました。
この順番なら、精度と安全性を同時に検証しやすくなります。
あわせて読みたい
RAGの考え方をもう少し身近に感じたい方は、筆者の個人ブログ「RAGって何？どうやって作る？」もおすすめです。ゲームセンターのメダルゲームにたとえながら、RAGの流れをやさしく整理しているので、よければこちらもぜひご覧ください。( note.com )
