社内文書を検索してAIが根拠付きで答える仕組み、いわゆるRAG（Retrieval-Augmented Generation、検索で得た情報を根拠にAIが回答を生成する手法）を、複数の部署や取引先が同じ基盤を共有する形で構築する検討をしている方に向けた内容です。デモ止まりのRAGと、複数テナント（利用組織単位）が安心して使える業務システムの間には、意外と大きな距離があります。その距離を埋める設計判断を整理します。
RAGのチュートリアルの多くは、文書を分割してベクトル化し、類似検索をして回答を表示するところで終わります。それは動作確認であって、社内で複数部門が同時に使う業務システムではありません。実際に多社・多部門で使うナレッジベースを構築する際に効いてくるのは、その先の設計です。
RAGパイプラインの4段階を分解する
RAGは「検索して渡すだけ」と説明されがちですが、本番運用を意識すると最低でも4つの工程に分かれます。
- 取り込み（Ingestion）: ファイルやURL、手入力の文書をチャンク（検索の最小単位に分割したテキスト片）にして保存する
- 検索（Retrieval）: 質問に対して本当に関連するチャンクを見つけ出す
- 根拠付け（Grounding）: 検索結果だけを材料にプロンプトを組み立て、AIの憶測を防ぐ
- 信頼担保（Trust）: なぜその回答になったのかを示す出典（ソース）表示
この4つは、それぞれが独立した機能として設計・テストされるべき対象です。ひとつのAPI呼び出しにまとめて「動いた」で終わらせると、後から見直すコストが跳ね上がります。
取り込み段階でとくに重要なのがチャンク分割の粒度です。チャンクが大きすぎると検索結果がぼやけ、小さすぎると文脈が失われます。目安として800文字程度のチャンクに200文字ほどのオーバーラップ（重なり）を持たせる実装が紹介されており、文の境界で意味が途切れるのを防ぐ狙いがあります。既存の社内Wiki や PDF マニュアルを移行する際、この分割サイズは文書の性質ごとに調整が必要です。契約書のような長文と、FAQのような短文では最適値が変わります。
マルチテナント化で設計が根本から変わる理由
単一ユーザー向けのRAGアプリと、複数組織が共存するSaaS（Software as a Service、月額課金などで提供されるクラウド型ソフトウェア）は、デモの段階を超えるとコードをほぼ共有できません。理由は、すべてのクエリ・チャンク・会話履歴が「どのワークスペース（利用組織の単位）に属するか」を常に意識しなければならないからです。
具体的には、検索処理そのものにworkspaceIdによる絞り込みを組み込みます。埋め込みベクトルの類似度がどれだけ高くても、別テナントのチャンクを取得できないようにデータ層で保証する設計です。アプリケーション側のif文でチェックするのではなく、データベースへの問い合わせ条件そのものにテナントIDを組み込む点がポイントになります。
データモデルとしては次のような階層が想定されます。
- Workspace: テナント（利用組織）そのものを表す入れ物
- WorkspaceMember: Owner / Admin / Memberといったロール（RBAC、役割ベースアクセス制御の考え方）
- KnowledgeSource / Document / DocumentChunk: RAGの実データ層で、常にワークスペース配下に紐づく
- Conversation / Message: チャットセッションもワークスペース単位で分離
- ApiUsage: トークン使用量をワークスペースごとに集計
この設計は、既存の業務システムでよく見る「テナントID列を全テーブルに持たせる」パターンと同じ発想です。マルチテナントSaaSの実装で広く使われるアプローチで、Salesforceのようなエンタープライズ製品も基本的にこの考え方を土台にしています。既存の社内システムに認証基盤（NextAuth.jsのようなライブラリや、社内でよく使われるKeycloak、Azure ADなど）がすでにある場合、そのロール管理とワークスペース単位の権限をどう対応付けるかが移行時の検討ポイントになります。
モデルを固定しないプロバイダ抽象化という考え方
OpenAIやGoogle Gemini、Anthropic Claudeのどれを使うかをコードに直書きせず、設定で切り替えられる薄い抽象化レイヤーを挟む設計も、業務システムとしては見逃せない判断です。AIProviderという共通インターフェースを定義し、各社のAPIをその実装として差し込む形にすると、契約するベンダーが変わってもアプリ本体を書き換えずに済みます。
これはエンタープライズ開発で馴染み深い「インターフェースを介した疎結合」の考え方そのものです。DBアクセスをORM（Object-Relational Mapping）で抽象化するのと同じ発想を、LLM（大規模言語モデル）呼び出しにも適用していると捉えると理解しやすくなります。
APIキーが未設定のときに動くモック（模擬）プロバイダを用意しておく設計も実務的です。デモ環境や結合テストで外部APIの鍵を配布せずに動作確認できる利点があり、社内のステージング環境やQA担当者への共有時に、コストと情報漏えいリスクの両方を抑えられます。
出典表示という「監査可能性」の要件
根拠のないAIの回答は、単なる推測でしかありません。回答をストリーミング（逐次配信、SSE=Server-Sent Eventsという技術で実現されることが多い）で返しつつ、その回答の根拠になったチャンクを合わせて提示し、元の文書にリンクできるようにする設計が紹介されています。
これは業務システムの観点では「監査可能性（Auditability）」の要件そのものです。金融・医療・法務など規制の厳しい業種では、AIの回答をそのまま業務判断に使う前に、根拠文書を人が確認できることが前提条件になる場面が多くあります。出典リンクを実装段階から組み込んでおくことは、後から監査ログ要件が追加された際の手戻りを減らす効果が期待できます。
自社導入を検討する際に確認すべきこと
実際にこの種の仕組みを社内に導入・自作する、あるいはベンダー製品を評価する場合、次の点を確認すると判断がしやすくなります。
- テナント分離の実装場所: アプリケーションコードのみで分離しているか、データベースのクエリ条件やRow Level Security（行単位のアクセス制御）まで踏み込んでいるか
- チャンクサイズと重なり幅: 自社文書の性質（契約書・マニュアル・議事録など）に対して初期値が適切か、調整可能な設計か
- モデルベンダーの切り替えやすさ: 特定ベンダーのSDKに直接依存していないか、抽象化レイヤーの有無
- 出典表示の粒度: 文書単位なのか、チャンク単位で該当箇所までジャンプできるのか
- トークン使用量の計測単位: ユーザー単位か、ワークスペース単位で集計・請求できる設計か
これらは実装を外注する場合の要件定義書にもそのまま転記できる項目です。既存のFAQボットやチャットボットを社内で運用している場合は、まず現状の仕組みがテナント分離をどう実現しているか、担当ベンダーやチームに確認してみるとよいと思います。
まとめ
RAGは検索とプロンプト生成だけで完結する技術ではなく、取り込み・検索・根拠付け・信頼担保の4工程として設計するとチェックしやすくなります。
マルチテナント化を見据えるなら、テナントIDによるデータ層での絞り込みと、ロールベースのアクセス制御を早い段階で組み込んでおくと後々の手戻りを避けられます。
モデルベンダーへの依存を薄くする抽象化と、回答の出典を追跡できる仕組みは、規制業種でなくても社内の信頼獲得に効いてきます。
自社での検討を始める際は、まず現行のチャットボットや検索ツールがテナント分離とチャンク設計をどう扱っているか、実装ドキュメントを確認するところから始めてみてください。