中小企業のための、
現実的な RAG アーキテクチャ
全社ドキュメントを AI で横断検索できるようにする ── 言葉にすると魅力的ですが、実運用には「データ品質」「権限」「コスト」の壁が立ちはだかります。SMB 向けに Xiora が選んでいる、現実的な RAG アーキテクチャを公開します。
RAG が「使えない」と言われる本当の理由
RAG（Retrieval-Augmented Generation、検索拡張生成）は、社内のナレッジや SaaS データを LLM が引用できる形で参照する技術です。「ドキュメントを全部ベクトル化して、ChatGPT に答えさせる」というイメージで語られがちですが、実運用に乗せると、たいてい次の壁にぶつかります。
- そもそも社内ドキュメントが古い・断片的・矛盾している
- 同じ情報が複数の SaaS に散在しており、どれが正かわからない
- 権限のないユーザーに、機密情報が漏れる可能性がある
- 本気でやるとベクトル DB と埋め込みコストが想定外に高い
つまり、RAG のボトルネックはモデルではなく、「データの正しさ・新鮮さ・権限」です。多くの SMB 環境で最初にやるべきは、ベクトル化ではなく、データの棚卸しです。
SMB 向けの現実解：3 層構成
私たちが SMB 規模で繰り返し採用しているのは、次の 3 層構成です。
SMB 向け RAG アーキテクチャ
ソース → 正規化／インデックス → リトリーバ／LLM の 3 層。各層に「責任者」と「更新頻度」を必ず割り当てます。
Source
Notion / Google Drive
社内ドキュメント
Source
Slack / Email
過去のやり取り
Source
業務 SaaS
CRM · 会計 · 在庫
Normalize
ETL / Cleanup
Airbyte · GAS
Index
Vector + Metadata
pgvector · Pinecone
ACL
Access Policy
Row-level filter
Retrieve
Hybrid Search
Vector + BM25
LLM with Citations
Generation
Claude · GPT
UI
Slack / Web
出典付き回答
- 一般コンポーネント
- AI / コア
各層の設計判断
1. Source（情報源）の絞り込み
「社内の全てを検索可能に」は理想ですが、最初は無理に広げない方が成功します。最初は「対応するクエリの 80% をカバーする少数のソース」に絞るのが鉄則です。たとえばカスタマーサポート用なら、Notion の FAQ・契約書テンプレート・直近 6 ヶ月の問い合わせログ、の 3 つだけで十分なケースが多いです。
2. Normalize（正規化）を軽視しない
PDF をそのままベクトル化しないでください。最低限、次の処理を入れます。
- OCR を通し、テキスト化する
- 見出しに沿って 500〜1,000 字のチャンクに分割する
- 更新日・出典 URL・部署・公開範囲をメタデータとして付与する
- 重複・古い版を排除する
この工程をサボると、回答の精度は半分以下になります。
3. Index に Vector 専用 DB を選ぶか
ベクトル DB といえば Pinecone / Weaviate のような専用サービスが有名ですが、SMB 規模では最初からそこに行く必要はほとんどありません。Supabase の pgvector で十分です。理由はシンプルで、業務データもメタデータも同じ Postgres に置けるため、JOIN や権限フィルタが圧倒的に楽になるからです。
-- Supabase + pgvector の典型クエリ
select
d.id, d.title, d.url, d.updated_at,
d.embedding <=> query_embedding as score
from documents d
where
d.tenant_id = $1
and (d.acl_role = any($2) or d.acl_role = 'public')
order by score
limit 8;スケール要件が明確になってから、専用ベクトル DB に切り替えれば間に合います。
4. ACL（権限）はインデックス側に持つ
RAG で一番怖いのは、「権限のないユーザーに機密文書が返ってしまう」事故です。権限チェックは LLM プロンプトに依存させてはいけません。必ずインデックス側のクエリで row-level に弾く設計にします。
実装上は、ドキュメントに acl_role や visible_to のメタデータを付与し、検索クエリで強制フィルタする形が定番です。
5. Retrieval は Hybrid Search を初手から入れる
ベクトル検索だけだと、固有名詞や型番のような「単語そのものが重要」なクエリで弱くなります。ベクトル検索と BM25（キーワード検索）を組み合わせるハイブリッド検索を最初から入れておくと、精度のレンジが大きく広がります。
6. 生成は必ず Citation 付き
LLM の応答には、参照したドキュメントの ID と URL を必ず添えます。「出典を返せない RAG は、業務で使われません」。利用者が原典を 1 クリックで確認できることが、社内浸透の最重要要素です。
運用の現実：誰が、どの頻度で更新するか
技術より重要なのは、ここです。RAG は導入して終わりではなく、ナレッジの新陳代謝が運用の中心になります。
- ソースごとに「責任者」を 1 名割り当てる
- 更新頻度（リアルタイム / 日次 / 週次 / 月次）を決める
- 古いドキュメントは「アーカイブ」フラグでインデックスから除外する
- 月次で、回答品質と citation のクリック率をレビューする
RAG ダッシュボードには、最低限「回答数」「Citation クリック率」「未回答率」「ユーザーフィードバック」の 4 指標を載せておきます。これが運用改善のサイクルを支えます。
まとめ
SMB の RAG は、最先端モデルより、データ品質と権限設計で決まる。
ベクトル DB の選定や LLM のスコアより、「情報源を絞る」「メタデータを揃える」「権限はインデックス側で弾く」「Citation を必ず返す」 を徹底するほうが、最終的な体感品質は確実に上がります。
Xiora では、御社のドキュメントと SaaS 環境を踏まえた現実的な RAG 設計から運用設計までを一気通貫で支援しています。社内 AI の導入を検討している方は、30 分の無料相談からどうぞ。