【2026年最新】RAGをオンプレミスで構築する方法｜構成・セキュリティ・運用を解説

定義と基本

オンプレミスRAGとは、検索・埋め込み・生成処理を自社管理基盤に置き、内部文書を根拠として回答を生成する仕組みです。

設計の起点は製品選定ではなく、データフローと信頼境界です。原本、抽出テキスト、ベクトル、検索結果、プロンプト、回答、ログの保存先と通信先を図示し、各地点の管理責任者、暗号化、保持期間、削除方法を決めます。文書単位またはチャンク単位で部署・役職・案件などのアクセス属性を保持し、検索フィルターを認証基盤の情報と連動させます。

導入工程は、要件定義、データ棚卸し、評価用質問の作成、PoC、脅威分析、容量設計、本番構築、受入試験、運用移管の順が基本です。精度評価では正答率だけでなく、根拠の適合性、権限違反、回答不能時の挙動、更新文書が検索可能になるまでの時間も測定します。

公式情報からわかる特徴

2026年8月9日に確認したQdrant公式Installationでは、自己管理かつクラウド接続なしの本番環境に、KubernetesとPrivate Cloud Enterprise Operatorを推奨しています。一方、コンテナ、バイナリ、Helm chartも提供されますが、コンテナやバイナリは主に試験・開発向けという位置付けです。必要CPU・メモリはベクトル数、次元数、ペイロードと索引、複製、量子化設定で変わるため、実データによる負荷試験が必要です。

永続ストレージにはPOSIX互換ファイルシステムへのブロックレベルアクセスが必要とされ、iSCSIは利用可能ですが、NFSなどのネットワークファイルシステムやS3などのオブジェクトストレージは非対応です。通信ポートはHTTP・監視用の6333、gRPC用の6334、分散構成用の6335が示されています。閉域でも全面開放せず、利用経路とクラスタ間通信だけを許可するのが編集上の推奨です。

Security公式資料は、自己ホスト版が初期状態では安全でなく、全インターフェースから認証なしで到達可能になり得ると明記しています。本番前にAPIキー、監査ログ、プライベートIPへのバインド、TLSを明示設定します。管理用、参照専用、コレクション単位の権限を使い分けても、社内文書の利用者権限が自動的に実現するとは限らないため、RAGアプリケーション側の認可設計が別途必要です。

Snapshots公式資料によれば、スナップショットは特定時点のコレクションデータと設定を含む一方、エイリアスは含みません。分散構成ではノードごとに作成が必要です。この仕様を踏まえ、バックアップ取得だけで完了とせず、エイリアスや周辺設定を含む復元手順、別障害領域への退避、定期的な復旧試験を運用要件にします。

比較と選定ポイント

閉域・オンプレRAGでは、検索精度だけでなく、外部通信の有無、文書単位の権限制御、監査証跡、バックアップ、担当者が運用できる技術基盤まで含めて選定します。ベクトルDB単体ではRAGは完成せず、文書取込、OCR、分割、埋め込みモデル、再ランキング、生成モデル、認証基盤、ログ管理も閉域要件に合わせる必要があります。

稟議前に実データで確認する項目

日本語文書では、意味検索だけでなく形態素解析によるキーワード検索との併用を評価します。社内略語、製品番号、表、旧字体を含む質問セットを作り、Recall、上位回答の根拠適合率、応答時間、同時実行数を比較してください。権限は検索後に除外するのではなく、検索時の部署・機密区分・有効期限による絞込みを基本とし、権限変更が索引へ反映される時間も測定します。

Qdrant公式資料では、必要CPU・メモリがベクトル数、次元数、payload索引、複製、量子化などで変わるとされています。また永続領域にNFSやS3は利用できず、ブロックストレージが必要です。これは公式仕様です。一方、どの候補が最適かは既存基盤、件数、検索方式、運用要員によるため、編集上は小規模でも本番相当データによる負荷試験を推奨します。

導入形態・料金・責任分界

完全閉域では、DBだけでなく埋め込みモデルと生成モデルもオンプレで稼働させます。OpenAIなど外部APIを利用する構成は、通信許可、送信データ、保存・学習条件、契約、障害時の代替手段を確認しなければ「閉域」とは扱えません。片方向の更新経路を設ける場合も、モデル、コンテナ、脆弱性情報の搬入・検証・承認手順を設計します。

料金はノード数、CPU・メモリ、GPU、保存量、複製数、サポート水準で変動します。固定額を前提にせず、公式見積りと最新の価格表を確認し、3〜5年分のハードウェア更新、電力、バックアップ領域、運用人件費までTCOに含めてください。

QdrantではHTTP・監視用の6333、gRPC用の6334、分散構成用の6335番ポートが公式に示されています。必要な通信だけを許可し、APIキー、private IPへのbind、TLS、監査ログを設定します。スナップショットは分散環境ではノードごとに作成が必要で、コレクションaliasは含まれません。取得だけでなく、隔離環境への復元試験、RPO・RTO、鍵とログの保管期間まで責任分界表に明記してください。公式情報は2026年8月9日時点で確認し、契約・導入時には最新版を再確認します。

企業導入の設計・実装

オンプレRAGは、文書取込、解析・チャンク化、Embedding生成、Vector Database、検索API、LLM、認証基盤を分離し、データの流出経路と障害範囲を明確にして設計します。完全閉域では、EmbeddingモデルとLLMも社内GPU基盤へ配置するか、審査済みの中継ゲートウェイだけに外部通信を許可します。

推奨する構成とデータ設計

導入工程は、対象業務と回答禁止領域の定義、代表質問・正解根拠の作成、PoC、権限試験、性能試験、復旧試験、本番移行の順が実務的です。検索精度だけでなく、権限外文書の混入率、根拠到達率、無回答の妥当性、更新反映時間を合否条件に含めます。

公式資料で確認できる事実：Qdrantの必要資源はベクトル数、次元、Payloadと索引、ストレージ、レプリケーション、量子化設定に左右されます。永続領域にはPOSIX互換ファイルシステムへのブロックレベルアクセスが必要で、NFSやS3は保存先として利用できないとされています。HTTPは6333、gRPCは6334、分散構成では6335番ポートを使用します。

編集上の判断：Qdrantは専用のベクトル検索基盤を分離したい構成に適します。一方、既存のPostgreSQLで規模と運用を吸収できる場合はpgvector、全文検索・運用基盤を統合したい場合はElasticsearchやOpenSearchも比較対象です。NFSしか用意できない環境では、Qdrantを前提にせずストレージ要件から見直します。

日本語検索・セキュリティの実務

日本語RAGではベクトル検索だけに依存せず、表記正規化、キーワード検索、再ランキングを組み合わせます。英数字の全半角、Unicode、旧字体、略語、製品コードを正規化し、固有名詞や条文番号を扱う業務ではBM25等とのハイブリッド検索を検証します。

チャンク長の適正値はモデルと文書形式で異なるため、一律には断定できません。規程、FAQ、議事録、表を分けて評価し、長すぎて論点が混在するケースと、短すぎて主語・適用条件が失われるケースを確認します。上位件数や類似度しきい値も、質問セットに対する再現率と誤検索率から決定します。

権限Filterと閉域防御

認証後に利用者の所属、役職、案件、機密区分を取得し、検索時にPayload／MetadataのFilterへ必ず変換します。プロンプトで「権限外を答えない」と指示するだけでは不十分です。候補取得前にFilterを適用し、キャッシュ、再ランキング、引用表示にも同じ権限条件を引き継ぎます。退職・異動時の失効時刻と権限同期遅延も設計対象です。

公式資料で確認できる事実：セルフホスト版Qdrantは初期状態のままでは認証がなく、全ネットワークインターフェースから到達可能になり得ます。本番前にAPIキー認証、特定IPへのバインド、TLS、監査ログを明示的に設定する必要があります。読み取り専用キーと、コレクション単位で権限を絞るキーも案内されています。

編集上の推奨：APIキーだけを利用者認可の代替にせず、IdP連携する検索APIをQdrantの前段に置きます。Vector Databaseを端末へ直接公開せず、管理API、検索API、クラスタ間通信をセグメント分離し、秘密情報はVault等でローテーションします。監査ログには利用者ID、質問ID、Filter条件、参照文書ID、モデル版、結果件数を残し、質問本文や回答本文の保存は機密区分と保存目的に応じてマスキングします。

監視・更新・バックアップ

運用では、死活監視だけでなく検索品質、更新遅延、権限違反、容量、復旧可能性を継続監視します。APIのレイテンシとエラー率、ベクトル件数、ディスク使用率、Embedding失敗数、取込待ち件数、権限Filterなしの要求をアラート対象にします。

更新と再索引

原本の追加・変更・削除をイベントまたは定期差分で検知し、document_idと版を使って冪等に更新します。削除文書はベクトルとキャッシュの双方から除去します。Embeddingモデル、チャンク規則、正規化処理を変更する際は新コレクションへ再構築し、評価後にエイリアス等で切り替える方式が安全です。

バックアップと復旧試験

公式資料で確認できる事実：QdrantのコレクションSnapshotには、そのノード上のコレクション設定、ポイント、Payloadが含まれますが、コレクションエイリアスは含まれません。分散構成ではノードごとにSnapshotを作成する必要があります。

Snapshotは別障害ドメインへ暗号化して退避し、原本文書、取込設定、Embeddingモデル情報、エイリアス、API設定も別途保全します。RPO・RTOを稟議時に定め、四半期などの周期で空の検証環境へ復元し、件数、代表検索、権限Filter、引用元まで確認します。Snapshot作成の成功だけでは復旧保証になりません。なお、構成や機能は更新され得るため、上記の公式情報は2026年08月09日時点で確認し、採用バージョンの資料と実機試験で最終判断します。

導入手順

オンプレRAGは、対象業務と情報区分を定め、検索品質を検証してから、権限・監査・復旧を含む本番構成へ段階的に移行します。

1. 要件と閉域条件を定義する

   利用者、対象文書、同時接続数、回答時間、可用性、保存期間を数値化します。「オンプレ」が外部APIを許容するのか、完全閉域なのかも明記してください。完全閉域では、埋め込みモデル、生成LLM、再ランキングモデルを内部で稼働させる必要があります。

2. データと権限を棚卸しする

   ファイルサーバー、文書管理、社内Wikiなどの取得元ごとに、所有部署、機密区分、更新頻度、削除条件を整理します。検索時に原本の閲覧権限を継承できるよう、部署・役職・文書ACLをメタデータとして保持する設計が必要です。

3. 日本語検索方式を評価する

   社内略語、製品型番、表記揺れ、長い複合語を含む質問セットを作り、ベクトル検索だけでなくキーワード検索とのハイブリッド、再ランキング、チャンク長を比較します。編集上の推奨は、正解文書の検索順位と回答根拠の一致率を別々に測ることです。

4. インフラと製品を選定する

   ベクトル数、次元数、ペイロード、褚製、量子化を基にCPU・メモリ・容量を見積もります。Qdrant公式資料では、永続領域にPOSIX互換のブロックストレージが必要で、NFSやS3は利用できないとされています。比較時はMilvus、Weaviate、OpenSearch、PostgreSQL＋pgvectorなども、既存運用との親和性を含めて評価します。

5. PoCを実装する

   文書抽出、正規化、分割、埋め込み、登録、検索、プロンプト生成、出典表示までを一連で実装します。PoCでも実データを無制限に複製せず、匿名化データまたは承認済みの限定データを使用します。

6. セキュリティを本番化する

   ネットワーク分離、TLS、秘密情報管理、サービス認証、コレクション単位の権限、操作ログを設定します。Qdrantのセルフホスト版は初期状態のままでは認証がなく、安全な本番構成ではないと公式資料に明記されています。APIキーだけに依存せず、アプリケーション側でも利用者認証と文書ACL照合を行います。

7. 移行・監視・復旧試験を行う

   検索精度、遅延、エラー率、インデックス件数、ディスク使用率、同期失敗を監視します。Qdrantの分散構成ではスナップショットをノードごとに作成する必要があり、コレクションエイリアスは含まれません。取得成功だけでなく、別環境への復元とRTO・RPOの達成を確認してから公開します。

向くケース・向かないケース

オンプレRAGは、外部送信を制限したい組織や既存の閉域基盤を活用できる組織に向きますが、運用人員が不足する場合は必ずしも最適ではありません。

向くケース

• 設計図、契約書、研究情報、個人情報などを外部環境へ送信できない
• 工場・医療・公共系ネットワークなど、インターネット接続が不安定または禁止されている
• 認証基盤、SIEM、バックアップ、Kubernetesなどの社内運用基盤を利用できる
• 部門・案件・機密区分に応じた検索権限と監査証跡が必要である

向かないケース

• 小規模検証で、サーバー調達や保守の固定費が効果を上回る
• GPU、証明書、脆弱性対応、障害復旧を担当する体制がない
• 需要変動が大きく、短期間での自動スケールを最優先する
• 保存先がNFSまたはオブジェクトストレージに限定され、Qdrantの要件を満たせない

これらの場合は、機密部分だけをオンプレに置くハイブリッド構成、管理サービス、既存検索基盤の拡張も候補です。ただし、外部サービスへ送る本文・ログ・埋め込みの扱いは契約と情報管理規程で確認してください。

導入前チェックリスト

稟議前に、技術要件だけでなくデータ管理、責任分界、継続運用まで確認します。

1. 完全閉域、通信先限定、外部API許可のどれに該当するか
2. 対象文書の所有者、機密区分、保存期限、削除責任者が決まっているか
3. 原本のACLを検索結果と生成回答へ確実に反映できるか
4. 日本語の略語、型番、表記揺れを含む評価質問と合格基準があるか
5. ベクトル数、次元数、増加率、同時検索数から3年分の容量を試算したか
6. TLS、認証、秘密鍵の更新、管理ポート制限、監査ログ保管を設計したか
7. モデル、OS、コンテナ、ライブラリの更新手順と脆弱性対応期限があるか
8. バックアップ対象、世代数、保管先、RTO・RPO、復元試験日を決めたか
9. 誤回答、権限漏えい、同期停止が起きた際の停止権限と連絡経路があるか

結論

オンプレRAGの成否は、ベクトルDBの導入だけでなく、閉域条件、日本語検索、原本ACL、監査、更新、復旧を一体で設計できるかで決まります。Qdrantを使う場合は、対応ストレージ、必要ポート、セルフホスト版の初期セキュリティ、分散スナップショットの制約を設計書へ反映してください。

まず限定データで検索品質と権限制御を検証し、運用費を含む複数製品比較を行うのが現実的です。以上は2026年8月9日に確認した公式資料の事実と実務上の編集判断を分けて整理したものであり、導入時には採用バージョンの最新仕様を再確認する必要があります。

一次情報・参考リンク

• Qdrant Installation
• Qdrant Security
• Qdrant Snapshots
• OpenAI Embeddings Guide