RAG（検索拡張生成）は、社内の文書を検索し、その内容をもとにAIが回答する仕組みである。導入時には最新の文書を取り込むため、当初は正しい回答が返る。しかし社内の文書は止まっていない。規程は改定され、マニュアルは追記され、古い手順書は廃止される。RAGがこれらの変化を取り込まなければ、回答は徐々に現実とずれていく。

本記事は、文書の更新・追加・廃止をRAGへどう反映するか、その運用フローと体制を、発注者の視点で整理する。読者として想定しているのは、中小企業の経営者、DX担当、情シス担当、事業責任者である。技術の細部ではなく、「誰が、いつ、どの文書を、どうやって反映するか」を発注前に決めておくための観点として読んでいただきたい。RAG導入を「作る」だけでなく「保つ」視点で見ると、運用フローの設計が欠かせないことが分かる。

結論：更新を反映する仕組みと責任者を、発注前に決める

RAGの回答品質は、取り込んだ文書がどれだけ最新かに左右される。作った時点が品質のピークで、あとは放置すれば劣化する、という状態は避けたい。GXOが運用フローの設計で重視するのは、次の3点である。

  • 文書が更新・追加・廃止されたとき、RAGへ反映する手順をあらかじめ決めておく
  • 反映の頻度と、自動連携・手動運用のどちらで行うかを業務に合わせて選ぶ
  • 更新の責任を持つ担当者（オーナー）を決め、廃止文書の削除まで運用に含める

これらは技術というより運用設計の論点である。だからこそ、開発が終わる前に決めておきたい。仕組みを作る段階で運用フローを織り込めば、引き渡し後に「誰も更新していない」状態を防げる。

なぜ更新の反映が問題になるか

RAGは、取り込んだ時点の文書をもとに回答する。文書が現実で更新されても、RAGに反映されなければ、古い内容のまま回答し続ける。これが運用上の最も大きなリスクである。反映が滞ると、次のような問題が起きる。

  • 古い情報が回答に残る：改定前の規程や、廃止された手順を、あたかも現行のものとして回答してしまう。
  • 追加した文書が検索されない：新しいマニュアルを作っても、RAGに取り込まれていなければ、回答の根拠に使われない。
  • 廃止文書が生き続ける：使わなくなった文書を削除しないと、古い情報が回答に混ざり続ける。

問題が厄介なのは、RAGの回答は一見もっともらしく返ってくる点である。古い情報でも、文章として自然なため、利用者は誤りに気づきにくい。だからこそ、文書の更新を確実に反映する運用が、回答の信頼性を支える土台になる。元となる文書の品質をそろえる考え方はRAG導入前のデータ品質マネジメントでも扱っている。

更新トリガと対応を整理する

更新の反映を運用に乗せるには、「どんなときに、何をするか」を整理しておくとよい。文書に起こる変化は、おおまかに更新・追加・廃止の三つである。それぞれにRAG側の対応がある。

更新トリガ文書側で起きることRAG側の対応反映を怠ると
更新規程・マニュアルの改定、追記該当文書を再取り込み（再インデックス）改定前の内容で回答する
追加新しい文書・手順書の作成新規文書を取り込む新しい内容が回答に使われない
廃止文書の廃止・統合・置き換え対象文書をRAGから削除廃止済みの情報が回答に残る

ここで見落とされやすいのが「廃止」である。新しい文書を取り込むことには意識が向きやすいが、古い文書を削除する運用がないと、現行版と廃止版が両方検索される状態になる。更新・追加・廃止の三つをセットで設計しておきたい。

再インデックスとは何か

文書をRAGが検索できる形に変換して取り込む処理を、インデックス（索引付け）と呼ぶ。文書が更新されたら、その文書を変換し直して取り込む必要があり、これを再インデックスという。再インデックスを全文書に対して行うのか、変わった文書だけに行うのかは、運用負荷に関わる論点である。変わった分だけを反映できる設計だと、更新のたびに全体を作り直さずに済む。

更新頻度と、自動・手動の使い分けを決める

更新をどのくらいの頻度で反映するかは、文書の性質によって変わる。毎日のように変わる文書と、年に数回しか変わらない文書を、同じ頻度で扱う必要はない。

  • 更新が多い文書：問い合わせ対応の参照資料など、頻繁に変わる文書は、反映の頻度を上げる、あるいは自動連携を検討する。
  • 更新が少ない文書：社内規程など、改定が年に数回程度の文書は、改定のタイミングで手動反映でも足りる場合が多い。
  • 重要度の高い文書：間違うと影響が大きい文書は、頻度に加えて、反映後の確認も含めて運用する。

反映の方法には、自動連携と手動運用がある。それぞれに向き不向きがある。

方法向いている場面注意したい点
自動連携更新が多い、対象が明確仕組みの構築・保守コスト、誤った文書も自動で反映される
手動運用更新が少ない、確認を挟みたい担当者が反映を忘れると古いまま残る

最初から全文書を自動連携にする必要はない。更新が多く、反映の確実性が重要な文書から自動化を検討し、それ以外は手動運用で始めるという段階的な進め方が現実的である。どの文書をどちらで扱うかを発注前に整理しておくと、開発範囲と運用負荷の見通しが立つ。

更新の責任者（オーナー）を決める

仕組みを作っても、反映する人がいなければ運用は回らない。RAGの更新で最もよくある失敗は、技術ではなく「誰の仕事か決まっていない」ことに起因する。

  • 文書ごとのオーナーを決める：その文書を更新したとき、RAGへの反映まで責任を持つ担当を、文書または領域ごとに決めておく。
  • 反映の確認を運用に含める：反映したつもりが取り込まれていない、という事故を防ぐため、反映後に確認する手順を決めておく。
  • 異動・退職時の引き継ぎを決める：担当が変わったとき、更新責任が宙に浮かないよう、引き継ぎの方法を想定しておく。

オーナーは専任である必要はない。多くの中小企業では、文書を管理している部署の担当者が、その文書のRAG反映も担う形が現実的である。重要なのは、「この文書を更新したら、RAGにも反映する」という流れを、誰の仕事として定義しておくことである。自動連携を入れる場合でも、連携の仕組みが正しく動いているかを見る担当は必要になる。

更新を運用に乗せる具体的な考え方はRAGのナレッジ保守に関するFAQでも整理している。RAGそのものの基本的な仕組みは社内ナレッジ活用のRAG・AI検索ガイドを参照されたい。

運用フロー設計でよくある失敗

更新の運用フローでは、次のような失敗が起きやすい。いずれも、発注前に方針を決めておけば避けられる。

  • 作って終わりにする：導入時の取り込みだけで、その後の更新フローを設計せず、回答が古くなっていく。
  • 廃止文書を消さない：新しい文書の追加には目が向くが、古い文書の削除運用がなく、廃止済みの情報が残り続ける。
  • 責任者を決めない：反映が「気づいた人がやる」状態になり、結局誰もやらなくなる。
  • すべてを自動化しようとする：更新が少ない文書まで自動連携を組み、構築・保守の負担だけが増える。

更新フローは、一度設計して終わりではなく、運用しながら見直すものである。どの文書をどの頻度で、誰が反映するかは、使い始めてから調整する前提で、最初の設計を軽すぎず重すぎず置いておきたい。

発注前チェックリスト

  • 文書の更新・追加・廃止それぞれについて、反映手順を想定したか
  • 廃止文書をRAGから削除する運用を設計に含めたか
  • 文書ごとに、更新が多いか少ないかを整理したか
  • どの文書を自動連携、どの文書を手動運用にするか方針を決めたか
  • 変わった文書だけを再インデックスできる設計か確認したか
  • 文書ごと、または領域ごとの更新オーナーを決めたか
  • 反映したことを確認する手順を運用に含めたか
  • 担当者の異動・退職時の引き継ぎを想定したか

開発会社に確認する質問

質問確認したいこと
文書が更新されたとき、どう反映する設計ですか更新フローの有無
変わった文書だけを再インデックスできますか反映の負荷と粒度
廃止した文書をRAGから削除できますか廃止文書の扱い
自動連携と手動運用のどちらも選べますか反映方法の柔軟性
反映が正しく行われたか確認できますか反映の確認手段
更新の運用は、引き渡し後に社内で回せますか運用の自走

「最新の文書を取り込んで構築します」という説明だけでは足りない。構築後に更新をどう反映し続けるかまで設計に含まれているかが、作って終わりにしないための分かれ目になる。

相談前に整理しておくとよい情報

  • RAGに取り込みたい文書と、それぞれの更新の頻度
  • 文書を管理している部署・担当者
  • 文書が改定・廃止されるときの、社内の流れ
  • 古い情報が回答に残ると、業務上どのくらい困るか
  • 文書が保存されている場所（共有フォルダ、文書管理システムなど）

これらが整理されていなくても相談は可能である。取り込みたい文書と、それが「どのくらいの頻度で変わるか」が見えていれば、更新を反映する運用フローと体制を一緒に設計できる。

関連記事

よくある質問

Q1. 文書を更新したら、RAGの回答にはすぐ反映されますか

すぐに反映されるかは、運用設計による。自動連携を組んでいれば短い間隔で反映できるが、手動運用なら担当者が反映するまで反映されない。どのくらいの遅れが許容できるかを業務に合わせて決め、それに合う反映方法を選ぶのが現実的である。

Q2. 廃止した文書を削除しないと、どうなりますか

廃止した文書がRAGに残っていると、検索の対象になり続け、古い情報や廃止された手順が回答に混ざる恐れがある。新しい文書の追加だけでなく、廃止文書の削除も運用に含めておきたい。削除の流れがあるかは、発注前に確認しておくとよい。

Q3. 更新の運用は、専任の担当者がいないと回りませんか

専任は必須ではない。多くの場合、その文書を管理している部署の担当者が、更新時にRAGへの反映も担う形で回せる。重要なのは人数より、「この文書を更新したら反映する」という流れを誰の仕事として決めておくことである。担当が曖昧だと、反映が滞り、回答が古くなっていく。

RAGの更新・運用フローを一緒に設計しませんか

GXOでは、文書更新の反映、再インデックス、更新責任者の決め方まで、RAGを作って終わりにしない運用設計をご支援します。

RAGの運用設計を相談する

※ 初回相談では、営業資料の説明よりも現状整理とリスク確認を優先します。