社内文書が更新されても破綻しないRAG運用のやり方：同期・再インデックス設計

社内文書が更新されるとRAGが「急に使えなくなる」理由

RAG（検索拡張生成）は「社内文書を探してから回答する」仕組みなので、元になる文書が変わると精度が落ちやすい特徴があります。たとえば、就業規則や稟議フロー、価格表、FAQ、手順書が更新されたのに、RAG側のデータが古いままだと「以前のルールで答える」「存在しない申請書を案内する」といった事故が起こります。現場ではこれが一番の不信感につながります。

なぜ破綻するのかを、専門用語を避けて整理すると原因は大きく3つです。

• 同期ズレ：SharePoint/Google Drive/Box/ファイルサーバー等の更新が、RAGの取り込み（同期）に反映されていない
• 再インデックス不足：文書を「検索しやすい形に加工して登録」し直していないため、検索結果が古い/欠ける
• 参照の不透明さ：回答に根拠（どの文書のどの部分か）が出ない、または古い版を参照している

ポイントは、RAGを「一度作って終わりのチャットボット」ではなく、社内文書のライフサイクルに合わせて運用する検索基盤として設計することです。社内文書は必ず更新されます。更新が前提なら、最初に「同期（取り込み）」「再インデックス（作り直し）」「版管理（どれが正か）」を決めておかないと、いつか破綻します。

この記事では、開発に詳しくない情シス・管理部門でも判断できるように、RAG運用の実務設計を「何を決めるか」「どう回すか」「よくある失敗と回避策」まで具体的に解説します。

まず決めるべき運用要件：更新頻度・正確性・責任範囲

同期・再インデックスの設計に入る前に、RAGの「運用品質」を数字と言葉で決めます。ここが曖昧だと、ベンダー/開発側も適切な方式を選べず、結果としてコストだけ増えたり、更新が追いつかなくなったりします。

更新頻度を「業務影響」で分類する

社内文書はすべて同じ扱いにしないのがコツです。文書の更新頻度と誤回答時の影響度でクラス分けします。

• クラスA（即時反映が必要）：セキュリティ規程、法務/労務のルール、価格・契約条件、障害対応手順など
• クラスB（当日〜翌日反映でよい）：社内FAQ、申請手順、プロジェクト標準、マニュアル類
• クラスC（週次でも可）：参考資料、過去議事録、ナレッジまとめ、研修資料

この分類があると「Aは差分更新＋即時再インデックス」「Cは夜間バッチでまとめて」など、方式を混ぜられます。

「正確性」と「根拠提示」を要件に入れる

RAGはLLMが文章を生成するため、根拠が曖昧だと不安が残ります。運用要件として、回答には参照元（文書名・更新日・該当箇所）を出す、参照できない場合は「分からない」と返す、といったルールを決めます。

• 参照を必須にする（引用表示、リンク、ページ/見出し名など）
• 古い版を参照した可能性がある場合は注意喚起を出す
• 高リスク領域（人事・法務・セキュリティ）は回答に免責文を添える、またはエスカレーション導線をつける

責任範囲：誰が「正」と判断し、誰が直すか

破綻しない運用の鍵は技術より体制です。RAG運用では最低限、次を明確にします。

• 文書オーナー：その文書の内容に責任を持つ部門（例：人事が就業規則、経理が旅費規程）
• ナレッジ運用者：同期・再インデックスの監視、失敗時の一次対応（情シス/ベンダー）
• 問い合わせ窓口：利用者の「違う答えが出た」を受け、修正に繋げる

「文書が更新されたのにRAGが反映しない」問題は、責任が宙に浮くと必ず放置されます。体制とSLA（例：クラスAは2時間以内に反映）を最初に握るのが重要です。

同期（取り込み）設計：どの変更をどう検知して取り込むか

同期は、社内ストレージ上の文書の変更を検知し、RAGのデータ側へ取り込む工程です。ここが弱いと、どれだけ検索や生成を工夫しても、古い情報を使うしかありません。同期設計で見るべきは「接続先」「変更検知」「取り込み単位」「失敗時の再実行」です。

接続先ごとの「変更検知」の現実

多くの企業では、SharePoint/OneDrive、Google Drive、Box、社内ファイルサーバー、Confluence/Notion、Zendeskなどが混在します。理想はイベント通知（更新が起きたら即知らせる）ですが、実務では制約があります。イベント通知が難しい場合は定期ポーリング（差分確認）で現実解を作るのが一般的です。

• イベント通知型：更新があれば即時キューに積み、同期を走らせる（速いが実装/権限が必要）
• ポーリング型：一定間隔で更新日時・ハッシュを見て差分だけ取る（堅実だが反映に遅れ）

「クラスAだけイベント」「それ以外はポーリング」など、文書クラスで使い分けるとコストと品質のバランスが取れます。

取り込み単位：ファイル丸ごと vs 差分

同期の取り込み単位は、運用コストに直結します。更新が頻繁な文書を毎回丸ごと処理すると、再インデックス負荷が増えます。一方、差分同期は難易度が上がります。おすすめは次の判断軸です。

• Word/PDFなど「差分抽出が難しい」ものは基本は丸ごと。ただし更新頻度が高いなら文書を分割（章別ファイル）する
• Confluence/Notionのようなページ構造は、ページ単位で差分同期しやすい
• FAQのように小さな項目が多いものは、項目単位（1Q=1データ）にすると更新が軽い

メタデータを必ず持つ（更新日・版・公開範囲）

RAGで事故が起きるとき、原因調査に必要なのがメタデータです。取り込み時に最低限、次を付与します。

• source：元の保存先URL/パス
• doc_id：文書を一意に識別するID（ファイル名変更に強いものが望ましい）
• updated_at：最終更新日時
• version：版（可能なら）
• access_scope：閲覧権限（部署/ロール/個人）

「どの文書の、いつの版を見て答えたか」を追えることが、信頼性の土台です。情シス視点では監査対応にも効きます。

同期の失敗を前提にする：リトライと監視

API制限、ネットワーク断、権限エラー、ファイル破損など、同期は必ず失敗します。失敗時に人が気づけないと「一部だけ古い」状態が長期間残ります。最低限の仕組みは以下です。

• 同期ジョブのステータス（成功/失敗/処理件数/所要時間）を記録
• 失敗は自動リトライ（回数・間隔）し、それでもダメならアラート
• 「前回同期からN時間以上止まっている」を監視
• 処理キュー（未処理・処理中・完了）を持ち、再実行できる

ここまで整えると、同期は「回る」状態になります。次は、取り込んだ文書をRAGが検索できる形にし直す再インデックス設計です。

再インデックス設計：更新に強い分割・埋め込み・差分更新

再インデックスとは、取り込んだ文書を「検索に強い形」に整え直し、RAGが参照するデータベースへ登録し直すことです。一般には文書を適切な長さに分割し、意味を数値化したベクトル（埋め込み）を作り、検索できるようにします。ここでの設計次第で、更新時のコストと品質が大きく変わります。

「分割（chunk）」が運用の成否を決める

文書をどの単位で分割して登録するかは、RAG運用の要です。分割が大きすぎると検索が雑になり、分割が細かすぎると必要な文脈が消えます。目安としては、1つの塊が「1つの手順・1つの規定・1つのFAQ回答」になるようにします。

• 規程：章・条文ごと（例：第◯条単位）
• 手順書：ステップ単位（前提→操作→結果がまとまる単位）
• FAQ：1問1答を1単位

更新に強くするなら、分割単位は「更新される単位」に合わせます。たとえば、就業規則の一部だけ変わるなら条文単位にしておくと、変更箇所だけ再インデックスできます。

差分更新：全部作り直さないための実務ルール

文書更新のたびに全件を再インデックスすると、費用（計算量）と時間が増えます。そこで、次のような差分更新ルールを作ります。

• doc_id単位で削除→再登録：その文書に属するchunkだけ入れ替える（分かりやすく堅実）
• chunk_id単位で更新：変更検知が可能なら、変更したchunkだけ更新（効率的だが実装が難しい）

情シス・非エンジニアの観点では、まずは「doc_id単位で入れ替え」が管理しやすいです。ファイル名変更や移動が起きてもdoc_idを保てるよう、ストレージ側のIDやURLを利用する設計が有効です。

セマンティック検索だけに頼らない（キーワード検索併用）

RAGの検索はベクトル検索（意味で探す）が中心になりがちですが、社内文書は「型番」「申請書名」「条番号」「エラーコード」など文字一致が強い場面が多いです。ベクトル検索＋キーワード検索（ハイブリッド）にすると、更新後の取りこぼしや誤ヒットが減ります。

• 「第12条」「稟議番号」「NW-401」などはキーワード検索が強い
• 「残業申請のやり方」など曖昧な質問はベクトル検索が強い

実務では、検索結果の上位に「改定日が新しいものを優先」「公式文書を優先」などのルールを足すとさらに安定します。

再インデックスのスケジュール：即時・準リアルタイム・夜間バッチ

再インデックスは頻度を上げるほどコストが増えます。文書クラスに合わせ、即時（数分）・準リアルタイム（1時間ごと）・夜間バッチを組み合わせます。

• クラスA：更新検知→キュー→即時再インデックス
• クラスB：1時間ごとに差分を処理
• クラスC：夜間にまとめて処理（業務時間外で負荷を吸収）

また、月末・年度末など更新が集中する時期は、処理待ちが増えます。ピーク時に備え、処理キューとスケール（同時処理数）の上限を決めておくと、運用が安定します。

「古い答え」を出さないためのガードレール：版管理・権限・引用提示

同期と再インデックスを整えても、利用者から見た品質が落ちる典型は「古い版を引く」「閲覧権限がない情報を混ぜる」「根拠が出ない」の3つです。ここではRAG運用のガードレールを、技術と運用ルールの両面で作ります。

版管理：最新版を優先し、古い版は参照しない

社内文書は「改定履歴が残る」ことが多く、ストレージ上に旧版が混在します。RAGが旧版を拾うと事故になります。対策はシンプルで、最新版フラグ（is_latest）をメタデータとして持ち、検索時に最新版だけを対象にします。

• ストレージ上で「最新版フォルダ」運用に寄せる（運用で解決）
• ファイル名に日付や版数が入る場合は、取り込み時に最新版判定ロジックを入れる
• 旧版も残すなら、RAGの検索対象から除外し、監査用途で別保管にする

特に規程・契約条件・価格などは、旧版参照が直接損害につながります。旧版は「検索で出ない」状態にして初めて安心です。

権限（アクセス制御）：部署ごとに見える情報を分ける

RAGで見落とされがちなのが、アクセス制御です。RAGが横断検索できるほど、閲覧権限の事故リスクは上がります。理想は、ストレージの権限を同期し、検索時にユーザーの権限でフィルタすることです。

• 文書ごとにaccess_scope（部署/ロール/個人）を付与
• RAGの検索クエリでaccess_scopeを必ず条件に入れる
• 共有リンクで誰でも見られる状態の文書は棚卸し対象にする

「まずは全社員共通の公開文書だけでRAGを始める」のも有効です。段階導入なら、権限設計の難易度を下げられます。

引用提示：利用者の不安を減らし、誤答を早く見つける

生成結果の本文だけ出すと、正しいか判断できません。回答には、参照した文書名・リンク・更新日・抜粋をセットで表示します。利用者が「根拠を辿れる」ことが、定着の条件です。

• 回答の最後に「参照：文書名（更新日）/該当セクション」
• 抜粋は必要最小限（情報漏えい・著作権・可読性に配慮）
• 参照が取れない場合は「該当資料が見つからない」と返し、問い合わせ導線を提示

引用提示は、精度向上だけでなく運用改善にも効きます。「この文書が古い」「この手順書が更新されていない」といった、文書管理の課題が見える化されるからです。

運用フローの作り方：監視指標・障害対応・改善サイクル

RAGの運用を「破綻しない」状態にするには、日々の監視と改善サイクルが必要です。ここでは、情シスでも回しやすいように、最低限のKPIと運用手順をテンプレ化します。

最低限見るべき指標（ダッシュボードの中身）

「動いているように見えるが、実は止まっている」が一番危険です。以下の指標は必須です。

• 同期ジョブ：成功率、失敗件数、平均処理時間、最終成功時刻
• 再インデックス：処理待ち件数、処理時間、対象文書数、失敗理由の内訳
• 検索品質：参照付き回答率（引用が付いた割合）、参照ゼロ率
• 利用状況：DAU/MAU、問い合わせ件数、フィードバック（役に立った/立たない）

特に「参照ゼロ率」が増えるときは、同期・権限・分割のどこかが壊れているサインです。

障害対応：止血の優先順位を決める

障害時にやりがちなのが、原因不明のまま再インデックスを全件走らせることです。コストが膨らみ、復旧も遅れます。手順を決めておくと迷いません。

1. 影響範囲の確認：特定のストレージだけか、全体か。クラスA文書に影響があるか
2. 同期の確認：最終成功時刻、失敗ログ（権限・API制限・ファイル形式）
3. 再インデックスの確認：処理待ちが詰まっていないか、失敗が連鎖していないか
4. 暫定対応：クラスAだけ優先処理、問題文書の除外、反映遅延の告知

利用者への案内も重要です。「現在、社内文書の更新反映に遅延があります。参照元の更新日をご確認ください」といったメッセージを出せるようにしておくと、信頼を損ねにくくなります。

改善サイクル：誤回答を「データ改善」に変える

RAGは導入後に育てるほど強くなります。現場の「違う」「探せない」を、改善チケットとして回収します。

• フィードバックボタン（役に立った/立たない＋理由）
• 誤回答時に「参照元が古い」「参照元が違う」「資料がない」を選べる
• 週次でトップ課題を棚卸し（文書不足、分割不適切、権限、同期遅延）

誤回答の多くはLLMの問題ではなく、文書側（整備・分割・最新版管理）で改善できます。情シスだけで抱えず、文書オーナーに戻す仕組みが重要です。

よくある失敗と、破綻しないためのチェックリスト

最後に、RAG運用で起きがちな失敗を「発生原因→対策」でまとめます。導入検討やベンダー提案の評価にも使えます。

失敗：更新が反映されない（いつの間にか古いまま）

• 原因：同期がポーリングのみで間隔が長い、失敗が検知できない、権限変更で同期が止まった
• 対策：クラスAは即時同期、ジョブ監視とアラート、リトライ、最終成功時刻の監視

失敗：新旧が混在し、旧版を参照してしまう

• 原因：旧版が同じ場所に残っている、最新版判定がない、検索時のフィルタがない
• 対策：is_latest付与、最新版のみ検索対象、旧版は別保管、文書命名規則の統一

失敗：検索は当たるが答えが的外れ（文脈が欠ける）

• 原因：分割が細かすぎて前提が欠落、逆に大きすぎてノイズが多い
• 対策：規程は条文単位、手順書はステップ単位、FAQは1問1答。必要に応じて前後の塊も一緒に渡す設計

失敗：型番・エラーコード・申請書名が見つからない

• 原因：ベクトル検索のみで文字一致に弱い
• 対策：ハイブリッド検索（キーワード＋意味検索）、メタデータ検索（文書種別/条番号）

失敗：情報漏えいが怖くて社内展開できない

• 原因：権限同期がない、閲覧範囲が曖昧、引用表示で機微情報が露出
• 対策：access_scopeで検索時フィルタ、段階導入（公開文書→部署限定→全社）、引用の出し方を最小限に

チェックリストとしては、以下を満たすか確認してください。

• 同期：変更検知の方式、失敗時のリトライ/監視、処理待ちの可視化がある
• 再インデックス：差分更新ができる（doc_id単位でも可）、分割方針が業務に合っている
• 最新版管理：最新版のみ検索対象にできる
• 権限：ユーザー権限で検索結果がフィルタされる
• 引用：参照元・更新日を表示できる

まとめ

社内文書が更新されても破綻しないRAG運用は、「同期」「再インデックス」「ガードレール」を最初に設計することが核心です。RAGは導入時のデモでは賢く見えますが、運用で更新が回らないと一気に信頼を失います。

• 文書を更新頻度×影響度でクラス分けし、反映SLAを決める
• 同期は失敗前提で、変更検知・リトライ・監視を仕組みにする
• 再インデックスは分割方針と差分更新でコストと精度を両立する
• 最新版管理・権限・引用提示で「古い答え」「漏えい」「根拠不明」を防ぐ
• 指標と改善サイクルで、RAGを育てていく

情シスや管理部門にとって重要なのは、技術の細部よりも「運用が回り続ける前提」を作ることです。社内文書は必ず変わります。変化に追従できるRAGこそ、現場に定着し、問い合わせ削減や教育コスト低減といった成果につながります。