結論：社内RAGを自作する場合、本番化後は少なくとも①文書更新・再インデックス、②権限・利用者、③バックアップ・復旧、④モデル・検索設定、⑤利用量・費用、⑥障害・セキュリティ、⑦削除・credentialの管理が続きます。自作の判断では開発工数だけでなく、「この7つを誰の定常業務にするか」まで決めることが重要です。
PoCで動くことと、本番で運用できることは別
RAGの基本は、文書を検索できる形にし、質問に関係する情報を取り出してLLMへ渡すことです。仕組み自体はシンプルに見えますが、MicrosoftのAzure AI SearchもRAG実装には、複雑な質問理解、検索品質、コンテンツ準備など複数の課題があると整理しています。
本番に入ると、さらに「継続して正常であること」が必要です。AWSの生成AI運用ガイダンスでは、本番監視をアプリ・システム状態、ビジネス指標、モデル品質の観点で捉え、遅延、エラー率、リソース、費用、回答品質、モデルやナレッジの版管理まで継続的に見る考え方を示しています。
自作RAGのコストは、最初の開発時間だけではありません。完成後も誰かが更新・監視・復旧・権限・費用・セキュリティを持つなら、その時間が継続原価になります。
PoC後に増える7つの運用作業
1文書更新・削除・再インデックス
規程、マニュアル、商品資料が変わるたびに検索対象へ反映します。追加だけでなく旧版削除、解析エラー、再インデックス失敗も確認します。
2利用者・権限・閲覧範囲
入社、異動、退職、部署変更に合わせてアクセスを更新します。人事・経営など限定資料がある場合は、検索段階から権限を一致させます。
3バックアップ・復旧
元資料だけでなくDB、設定、検索インデックス、暗号鍵など、何を復旧対象にするかを決めます。バックアップがあるだけでなく、実際に戻せるかを確認します。
4LLM・Embedding・rerank・検索設定の更新
モデル、SDK、検索方式、文書分割、プロンプトを変更すると挙動が変わります。変更前後を代表質問で比較し、問題があれば戻せるようにします。
5利用量・費用・容量監視
APIトークン、質問数、ストレージ、CPU・GPU・メモリ、転送量を確認します。利用増で遅延や予算超過が起きる前に上限・警告を設計します。
6障害・品質劣化・セキュリティ対応
API障害、indexer失敗、検索品質低下、依存ライブラリの脆弱性、OS更新などへ対応します。「動いているか」と「正しく答えているか」を別々に監視します。
7退職・解約・削除・credential rotation
ユーザー削除だけでなく、APIキー、秘密鍵、バックアップ、ログ、外部ストレージに残るデータまで、終了時の処理を決めます。
1. 文書更新：追加より「旧版をどう消すか」が難しい
RAGの知識は、元資料が変われば更新が必要です。新しいファイルを追加するだけでは、旧版が検索対象に残り続けることがあります。
本番では「追加 → 解析 → index更新 → エラー確認 → 代表質問で確認」までを一つの運用として考えます。Azure AI Searchもindexerの開始・終了時刻、エラー、警告を監視できる仕組みを用意しており、インデックス処理そのものが監視対象であることが分かります。
資料の正本・最新版管理については社内AIの資料更新・差し替え運用で詳しく解説しています。
2. 権限：検索結果の段階で守る
チャット画面で「答えないで」と指示するだけでは、権限制御の代わりになりません。一般社員が人事資料を検索できないようにするなら、検索対象やworkspace、データアクセスの段階で閲覧範囲を分ける必要があります。
OWASPのGenAI Security Projectも、RAGで使うvector・embeddingにアクセス制御が不十分な場合、機密情報の不正取得につながるリスクを挙げています。
入社・異動・退職時に誰が権限を変更するかまで決めておかないと、初期設定が正しくても時間とともにずれていきます。
3. バックアップ：ベクトルDBだけ戻しても復旧とは限らない
RAG環境は、元文書、DB、検索インデックス、アプリ設定、シークレットなど複数の要素で動きます。どこまで再生成でき、どこからバックアップが必要かを決めます。
検索インデックスを元文書から再構築できるなら、復旧時間との兼ね合いでバックアップ対象を減らせる場合もあります。逆に、元資料や設定が失われればindexだけ残っていても運用を戻せません。
「バックアップを取っている」ではなく、「障害時に何分・何時間でどこまで戻すか」を一度試すことが重要です。
4. モデル・検索構成：更新すると回答が変わる
LLMやEmbeddingモデルを変更すると、同じ質問でも検索順位や回答文が変わる可能性があります。reranker、chunk size、プロンプト、SDKの変更も同様です。
OpenAIのAPIドキュメントも、モデルsnapshot間ではprompting behaviorが変わる可能性があるため、一貫性が重要なアプリではモデルバージョンを固定し、evalを実装することを推奨しています。
更新のたびに全部を人手で確認する必要はありませんが、よく使う質問と失敗しやすい質問を評価セットとして残し、変更前後を自動・半自動で比較できるようにすると運用しやすくなります。
社内AIのPoC評価方法で、評価セットの作り方も整理しています。
5. 利用量・費用：使われた後の方が設計が効く
PoCでは数人しか使わなくても、本番では質問数、同時アクセス、文書量が増えます。LLM APIだけでなく、Embedding処理、ストレージ、検索基盤、CPU・GPU、バックアップ転送など複数の原価が発生します。
AWSは本番生成AIの監視指標として、latency、throughput、uptime、resource utilization、cost efficiencyなどを挙げています。利用量だけを追うのではなく、「利用増で遅くなっていないか」「1質問あたり原価が悪化していないか」も見る必要があります。
6. 障害・品質・セキュリティ：正常稼働と正しい回答は別
HTTP 200が返っていても、検索結果が空、古いindexを参照、特定ファイルだけ解析失敗、回答品質だけ劣化、といった状態は起こり得ます。
AWSは本番監視で、システムの可用性だけでなく、accuracy / relevance、hallucination、traceability、prompt / knowledge base versioningなども監視対象として挙げています。
そのため、最低限「サービスが応答するか」「検索処理が成功しているか」「代表質問が期待範囲で答えられるか」の3層を分けて確認すると原因を切り分けやすくなります。
7. 終了処理：作るときより忘れやすい
退職者、解約顧客、PoC終了環境では、アカウントを止めるだけでは不十分な場合があります。
- ユーザー・サービスアカウント
- APIキー・秘密鍵・Webhook secret
- 元資料・DB・vector index
- ログ・バックアップ
- 外部クラウド上のcredential
何日残すか、削除をどう確認するか、鍵をいつrotate / revokeするかをあらかじめ決めます。外部LLMを使う場合は、自社側の削除だけでなく外部API側の保持条件も把握します。
本番RAGで最低限モニタリングしたい項目
| 領域 | 見るもの | 異常例 |
|---|---|---|
| アプリ | 稼働率、HTTP error、latency | 質問画面は開くが回答timeout |
| 検索 | indexer成功、検索0件率、retrieval品質 | 更新資料だけ検索できない |
| 回答 | 代表質問、出典、未回答 | モデル更新後に回答品質が低下 |
| インフラ | CPU、memory、disk、storage | 文書増加でdisk逼迫 |
| 費用 | API usage、1質問原価、月額原価 | 利用増で予算超過 |
| セキュリティ | 認証、権限、patch、secret | 退職者権限が残る |
自作が向いている会社
- 開発・インフラ担当者がおり、継続運用も担当範囲にできる
- 独自連携や独自検索ロジックが競争力になる
- AI基盤のノウハウを社内資産として蓄積したい
- 障害・バックアップ・セキュリティ対応を自社で持つ方針
この場合、自作は自由度が高く合理的です。「誰かが面倒を見る」こと自体が問題ではなく、その仕事を会社として意図的に持つかどうかが判断軸です。
管理まで外に出す方が向く会社
- 目的はRAG開発ではなく、社内の質問・探索時間削減
- AI担当者を新しく置きたくない
- 社内資料Q&Aへ用途を絞れる
- 個社独自開発より標準構成を使いたい
- 開発後の更新・監視・backup・patchを通常業務へ追加したくない
ただし外注しても、「どの資料が正しいか」「誰に見せるか」「その回答で業務判断してよいか」という会社固有の判断は社内に残ります。外へ出しやすいのは、基盤構築・標準設定・更新・監視・障害対応など技術運用です。
Nexfila AIは「RAG開発代行」ではなく管理込みの標準基盤
Nexfila AIは、顧客ごとにRAGをゼロから受託開発するサービスではありません。15〜50名程度の会社向けに用途を社内資料Q&Aへ絞り、標準構成を再利用して、AI基盤の構築・標準設定・アップデート・稼働保守を提供します。
社員、資料、閲覧範囲、workspaceなど業務側の日常管理は利用企業が行い、VPS、DB、バックアップ、セキュリティ更新、標準AI設定等の技術運用をNexfilaが担当する役割分担です。
「自作できるか」ではなく、「自作した後の7つの運用作業を社内で持ちたいか」で比較してください。
よくある質問
社内RAGは一度作れば管理不要ですか？
いいえ。資料、利用者、モデル、依存ソフト、費用、セキュリティは変化するため継続運用が必要です。
PoCと本番で一番違うことは？
継続性です。本番では更新、異動・退職、障害、容量、費用、backup、patchなど「時間が経つと起こること」へ対応する必要があります。
モデル更新のたびに再評価しますか？
代表的な質問セットで変更前後を比較するのがおすすめです。モデルだけでなくEmbedding、reranker、prompt、chunkingの変更でも検索・回答が変わる可能性があります。
自作は避けるべきですか？
いいえ。自社固有の連携・ロジックが重要で、技術運用を継続して持てる会社には合理的です。運用担当を増やしたくない会社では管理込み型も比較対象になります。
外注すれば完全に管理不要ですか？
完全にはなくなりません。資料の正誤、閲覧対象、業務上の判断は利用企業が持つ必要があります。技術基盤の運用を外へ出すことで負担を減らす考え方です。
参考にした一次情報・公開情報
- AWS Prescriptive Guidance「Pillars of monitoring generative AI application performance in production」
- AWS「Performance monitoring and continuous improvement for generative AI applications」
- Microsoft Learn「Monitor indexer status and results」
- Microsoft Learn「Retrieval-augmented generation (RAG) in Azure AI Search」
- OpenAI API「Backward compatibility」
- OWASP GenAI Security Project「Vector and Embedding Weaknesses」