企業RAGで本当に難しいのはモデルではない：マルチテナント・アーキテクチャの設計

企業RAGで最初に問うべきはモデル品質よりデータ境界

企業RAGで問うべきなのは、どのモデルが最も流暢に答えるかだけではありません。テナント境界、権限、検索、運用証跡を検証可能にする必要があります。

モデル品質は回答の上限を決めますが、データ分離、監査可能性、安全な進化の仕組みが、検証環境を本番サービスへ移せるかを決めます。

Headless RAGアーキテクチャは何を接続するのか

Headlessアーキテクチャは、client experienceを再利用可能なknowledgeとAI serviceから分離しつつ、identity、authorization、audit、data scopeを一つのgovernance layerで統制します。

どのマルチテナント・データアーキテクチャを選ぶべきか

分離強度が高いほど、インフラ、アップグレード、運用のコストは通常増加します。

分離モデルはどのように選ぶべきか

分離レベルは、機密性、カスタマイズ、バックアップと復元、データ所在地、運用コストから選びます。唯一の正解を前提にしません。

PostgreSQL RLSでテナント分離をどう実現するか

PostgreSQL Row-Level Securityは、現在のDB Transactionにあるテナント条件で読み書きを制限できます。アプリケーションがtenant filterを漏らした場合のDB側の追加防御になります。

1CREATE EXTENSION IF NOT EXISTS vector;
2
3CREATE TABLE knowledge_chunks (
4  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
5  tenant_id UUID NOT NULL,
6  document_id UUID NOT NULL,
7  content TEXT NOT NULL,
8  embedding vector(1536),
9  created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
10);
11
12ALTER TABLE knowledge_chunks ENABLE ROW LEVEL SECURITY;
13ALTER TABLE knowledge_chunks FORCE ROW LEVEL SECURITY;
14
15CREATE POLICY tenant_select_policy
16ON knowledge_chunks FOR SELECT
17USING (tenant_id = NULLIF(current_setting('app.current_tenant_id', true), '')::uuid);
18
19CREATE POLICY tenant_insert_policy
20ON knowledge_chunks FOR INSERT
21WITH CHECK (tenant_id = NULLIF(current_setting('app.current_tenant_id', true), '')::uuid);

RLSで守れるものと、置き換えられないもの

connection poolとroleでRLSを有効に保つには

RLS Policyだけでは信頼できるテナント境界は作れません。各リクエストでtenant contextを設定し、同じ明示的Transaction内で、RLSを回避できないruntime roleにより検索・読み書きを実行します。

1BEGIN;
2SET LOCAL app.current_tenant_id = 'tenant-uuid';
3
4SELECT id, content
5FROM knowledge_chunks
6ORDER BY embedding <=> :query_embedding
7LIMIT 8;
8
9COMMIT;

SET LOCALは現在のTransaction内だけで有効です。Transaction poolingはBEGIN、SET LOCAL、全クエリを同じTransactionに保持する場合に利用できますが、statement poolingは利用できません。superuserとBYPASSRLSロールは常にRLSを回避し、table ownerもFORCE ROW LEVEL SECURITYがない限り既定で回避します。

Headless RAG APIはどのように設計するべきか

Headless APIはstatelessに保ち、信頼できるcredentialsからtenantとpermission scopeを導出します。clientがtenant_idを選択または上書きしてはいけません。

文書アップロードAPI

1POST /api/v1/documents
2Authorization: Bearer <access_token>
3Content-Type: multipart/form-data

1{
2  "document_id": "d3b07384-d113-4956-a5cc-9c60012443d3",
3  "status": "processing",
4  "message": "文書は解析とindexingのqueueに登録されました"
5}

会話と検索API

1POST /api/v1/chat/completions
2Authorization: Bearer <access_token>
3Content-Type: application/json

1{
2  "messages": [{ "role": "user", "content": "年次有給休暇はどのように計算されますか？" }],
3  "stream": true
4}

企業向け応答には、source document、version、updated time、Request ID、根拠なしまたは権限不足時の明確なstateを含めます。

文書はどのようにRAGナレッジベースへ入るのか

解析、OCR、chunking、embeddingが元のHTTP requestを占有しないよう、ingestionは非同期にします。

Chunkingは固定文字数ではなく文書構造に従う

heading、clause、semantic boundary、文書種別を使い、sourceとversionの追跡性を保つchunkを作ります。

Embeddingモデル変更時に次元をどう進化させるか

vector(1536)は固定次元のデータ契約であり、将来の任意モデル向けの仮置きではありません。新モデルは意味空間と出力次元の両方を変えるため、model nameとversionの記録だけでは移行計画になりません。

1-- Example: a v2 model outputs 1024 dimensions
2CREATE TABLE knowledge_chunk_embeddings_v2 (
3  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
4  tenant_id UUID NOT NULL,
5  chunk_id UUID NOT NULL,
6  embedding_model TEXT NOT NULL,
7  embedding vector(1024) NOT NULL,
8  created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
9);
10
11CREATE INDEX CONCURRENTLY knowledge_chunk_embeddings_v2_hnsw
12ON knowledge_chunk_embeddings_v2
13USING hnsw (embedding vector_cosine_ops);

RAGはどのように検索し回答を生成するのか

各queryでは、hybrid retrieval、reranking、model generation、citation、audit loggingの前にidentityとtenant scopeを確立します。

企業知識にハイブリッド検索が適する理由

企業知識には意味的な質問だけでなく、製品型番、規制、条項番号、正確な数値が混在します。ハイブリッド検索はvector、keyword、metadata filter、rerankingを組み合わせます。

テナント削除後にvector indexをどう維持するか

テナントデータの完全削除はコンプライアンス要件ですが、高頻度の削除はindex workloadも変えます。特にHNSWでは、行の削除確認だけでなく、index size、latency、recall、maintenance timeを監視します。

1REINDEX INDEX CONCURRENTLY knowledge_chunks_embedding_hnsw;
2VACUUM (ANALYZE) knowledge_chunks;

企業RAGの本番稼働前に何を確認するべきか

もっともらしいDemoだけでは本番受入試験になりません。稼働前に次の統制の証跡を残します。

よくある質問

1. 企業RAGのマルチテナント・アーキテクチャとは何ですか？

複数組織が一つのRAGアプリケーションを使いながら、文書、vector、権限、検索結果をDB、storage、queue、cache、log、model inputまで分離する設計です。

2. PostgreSQLは企業RAGに適していますか？

多くの中小から大規模のRAG workloadに適しています。関係データ、metadata、全文検索、transaction、pgvectorを一緒に扱えるためです。最終判断は規模、latency、運用複雑性によります。

3. PostgreSQL RLSは何を守りますか？

RLSはTransaction scopedのtenant contextにより行を制限できます。application filter漏れのリスクを減らしますが、明示的Transaction、最小権限role、connection pool testと組み合わせる必要があります。

4. Shared Schemaは必ずデータ漏えいを起こしますか？

いいえ。主なリスクは誤ったrole、tenant contextの欠落、negative test不足です。RLS、least privilege、cross-tenant testがリスクを下げます。

5. Shared Schemaが適さないのはどのような場合ですか？

独立したbackupとrestore、data residency、異なるschema、高度なcustomization、厳格なcomplianceが必要な場合は、より強い分離を評価します。

6. なぜingestionを非同期にする必要がありますか？

解析、OCR、chunking、embeddingには数秒から数分かかることがあります。QueueとWorkerによりrequest timeoutを避け、retry、recovery、status trackingを改善できます。

7. RAGのchunk sizeはどの程度にすべきですか？

万能の固定サイズはありません。文書構造、意味境界、条項、実際の質問を使い、retrievalとanswer quality testで調整します。

8. ハイブリッド検索とは何ですか？

vector search、keyword search、metadata filtering、rerankingを組み合わせ、意味的質問と、正確な用語、型番、条項、数値の両方に対応する方法です。

9. RAGはhallucinationを完全になくせますか？

できません。検索はgroundingを改善しますが、retrieval failure、古い文書、prompt design、generation errorは残ります。citation、refusal condition、review controlが必要です。

10. Headless RAGの事業価値は何ですか？

検索と生成を統制されたAPIへ変え、Webサイト、アプリ、Bot、社内システムが同じdataとpermission modelを再利用できることです。

11. Embedding modelの変更では再ベクトル化が必要ですか？

通常は必要です。モデルにより意味空間と次元が変わるため、新しいtableまたはcolumn、parallel index、re-embedding、controlled read cutoverを計画します。

12. 企業RAGが本番準備完了だとどう判断しますか？

tenant isolation、pool transaction scope、role bypass、文書version、実問集合、citation、refusal behavior、performance、dimension migration、deletion-index operationの証跡を確認します。

結論：アーキテクチャは唯一の技術回答を選ぶことではない

多くのSaaS RAG製品では、Headless API、Shared Schema、PostgreSQL RLS、pgvector、非同期Workerが費用対効果の高い出発点になります。

重要なのは単一の技術を選ぶことではありません。システム全体が安全に分離され、安定運用され、隠れたデータリスクなしに進化し、各回答の根拠を提示できるかです。