タグ: ベクトルデータベース

社内文書を検索できるRAGやAIチャットを作った直後は、問題なく回答できていた。

ところが数か月後、料金表を更新したのに旧料金を答える。業務マニュアルを差し替えたのに、以前の手順を案内する。廃止した資料を共有フォルダから削除したのに、AIの回答には残っている。

このような問題は、AIモデルの性能だけが原因ではありません。元のファイルを更新しても、RAG側の検索データが自動で最新になるとは限らないためです。

RAGを業務で使い続けるには、導入時の文書登録だけでなく、導入後の「追加・差し替え・削除・期限切れ」を管理する必要があります。

結論から言うと、最初に決めたいのは次の4点です。

• どの文書が正式版か
• 更新を誰がRAGへ反映するか
• 旧版を検索対象から外す条件は何か
• 反映後に何を質問して確認するか

この記事では、小規模事業者や少人数チーム向けに、RAGの文書更新を無理なく続けるための実務設計を整理します。

ファイルを上書きしただけではRAGが更新されないことがある

RAGは、元のPDFやWordファイルを毎回そのまま読んで回答しているとは限りません。

一般的には、文書を一定の長さに分割し、検索用のデータへ変換して、ベクトルデータベースや検索インデックスへ登録します。利用者が質問すると、その登録済みデータから関連部分を探し、AIが回答を作ります。

そのため、共有フォルダのファイルを上書きしても、検索用データの作り直しや再登録が行われなければ、RAG側には古い内容が残ることがあります。

反対に、元ファイルを削除しても、登録済みの分割データが残っていれば、検索結果に出続ける場合があります。

RAGの文書更新では、元ファイルと検索データを別々に考えることが重要です。

• 元ファイル: PDF、Word、Excel、Markdown、Webページなど
• 検索用データ: 分割した文章、埋め込みデータ、メタ情報、検索インデックス
• 回答画面: 利用者が質問し、参照元と回答を見る場所

元ファイルだけ最新でも、検索用データが古ければ、AIの回答は古いままです。

RAG運用で管理したい4つの更新イベント

文書更新を「ファイルを入れ直す作業」とだけ考えると、削除や期限切れが抜けます。

最低限、次の4つに分けて管理します。

1. 新しい文書を追加する

新しいマニュアル、FAQ、料金表、規程、提案資料などを検索対象へ追加するケースです。

追加時には、ファイルを登録するだけでなく、次の点を確認します。

• 誰が見てよい文書か
• 正式版か、作業中の文書か
• どのカテゴリや部署に属するか
• いつから有効な情報か
• 似た内容の旧文書が残っていないか

新しい料金表を追加しても、旧料金表が同じ検索対象に残っていれば、AIは両方を見つける可能性があります。

追加と同時に、置き換える旧文書がないか確認することが大切です。

2. 既存文書を差し替える

内容を修正したPDFやWordを上書きするケースです。

差し替えでは、同じファイル名でも内容が変わっていることがあります。更新を検知したら、古い検索データを削除し、新しい内容で再登録する流れが必要です。

この時、旧データを消さずに新データだけ追加すると、同じ文書の新旧が両方検索されることがあります。

差し替え時に確認したい項目は次の通りです。

• 文書IDは同じか
• 版数や更新日は変わったか
• 旧データを削除してから再登録したか
• 参照元リンクは新しいファイルを指しているか
• 変更した項目を質問して、新版の回答になるか

3. 不要な文書を削除する

元ファイルを削除しただけでは、検索用データが残る場合があります。

削除時には、元ファイル、検索インデックス、ベクトルデータ、キャッシュ、参照元リンクの状態を確認します。

完全に削除する必要がない場合は、検索対象から外す「無効化」でも構いません。監査や履歴のために旧版を残すなら、保管場所と検索対象を分けます。

• 保管はするが、AI検索では使わない
• 管理者だけが検索できる
• 過去資料として明示し、通常回答では優先しない
• 一定期間後に完全削除する

「保管すること」と「回答に使うこと」を同じにしない設計が必要です。

4. 期限切れや旧版として無効化する

削除できない文書でも、現在の回答には使いたくないことがあります。

たとえば、過去の料金表、旧契約条件、終了したキャンペーン、改定前の就業ルール、以前の製品マニュアルです。

このような文書には、次のような情報を持たせます。

• 有効開始日
• 有効終了日
• 最新版かどうか
• 置き換え先の文書ID
• 検索対象に含めるか

日付や版数をファイル名だけに頼ると、表記の揺れや入力漏れが起きます。RAG側で扱えるメタ情報として持たせる方が、後から確認しやすくなります。

最低限持たせたい文書管理項目

大きな文書管理システムを導入しなくても、最初はスプレッドシートやCSVで管理できます。

最低限、次の項目があると更新状態を追いやすくなります。

• 文書ID
• 文書名
• 元ファイルの保存場所
• カテゴリまたは対象業務
• 版数
• 最終更新日
• 有効開始日・有効終了日
• 文書の責任者
• 閲覧できる利用者・部署
• RAG登録状態
• 最終登録日時
• 検索対象に含めるか
• 置き換え元・置き換え先の文書ID
• 確認用のテスト質問

特に重要なのは、文書ID、版数、RAG登録状態、テスト質問です。

ファイル名が変わっても同じ文書だと判断できるIDがあれば、旧データの削除と新版の再登録を対応づけやすくなります。

小さく始める更新フロー

最初からGoogle DriveやNotionの全更新を自動同期する必要はありません。

まずは、更新頻度が高く、古い回答の影響が大きい文書だけを対象にします。

1. 更新対象の文書を3種類程度に絞る
2. 正式版の保存場所を1つ決める
3. 文書ID、版数、更新日、担当者を記録する
4. 追加・差し替え・削除の申請方法を決める
5. RAGへ再登録する担当者を決める
6. 反映後にテスト質問を実行する
7. 回答と参照元が新版になったことを確認する
8. 確認日時を更新履歴へ残す

対象にしやすいのは、料金表、問い合わせFAQ、業務マニュアル、サービス説明、製品仕様などです。

これらは更新内容が明確で、テスト質問も作りやすいため、小さな運用を試すのに向いています。

更新頻度は文書ごとに分ける

すべての文書を毎日再登録すると、処理時間や確認作業が増えます。

文書の性質に合わせて、更新方法を分けます。

手動更新が向いている文書

料金表、契約条件、社内規程など、変更頻度は低いものの、間違える影響が大きい文書です。

更新時に人が内容を確認し、RAGへ反映した後、決めた質問で回答を確認します。

定期更新が向いている文書

週次レポート、月次資料、定期的に追加される議事録などです。

毎日、毎週、毎月など決まった時間に変更ファイルを確認し、追加分だけ登録します。

変更検知が向いている文書

頻繁に更新されるFAQ、サポート文書、商品情報などです。

ファイルの更新日時、ハッシュ値、版数などを使って変更を検知し、変更があった文書だけ再登録します。

ただし、自動更新した後も、重要な文書は回答確認を省略しない方が安全です。

RAG更新後はテスト質問で確認する

再登録が成功したというログだけでは、回答が正しくなったとは限りません。

検索では旧データが残っている、参照元リンクが切れている、似た文書が優先されている、といった問題が起きることがあります。

文書ごとに1から3個のテスト質問を用意しておくと、更新後の確認がしやすくなります。

たとえば料金表なら、次のような質問です。

• 現在の基本料金はいくらですか
• 追加費用が発生する条件は何ですか
• この料金はいつから有効ですか

マニュアルなら、変更した手順を直接聞きます。

確認するのは、回答文だけではありません。

• 最新版の内容を答えているか
• 旧版の内容が混ざっていないか
• 正しい文書名やURLが参照元に出ているか
• 更新日や版数を確認できるか
• 答えがない時に無理に作っていないか

よくある失敗は「新しい文書を足すだけ」

RAGの更新で多いのは、新版を追加して終わることです。

旧版が残っていると、検索結果に新旧両方が出ます。AIが新版を必ず選ぶとは限りません。

ほかにも、次のような失敗があります。

• 同じ文書を何度も登録し、重複データが増える
• ファイル名を変えたため、旧データと別文書として登録される
• 削除した文書の分割データだけ残る
• 更新担当者が不明で、誰も再登録しない
• 自動同期は動いているが、回答確認をしていない
• 参照元URLが旧ファイルのままになっている
• ローカル環境と本番環境で登録内容が違う

更新処理は、追加だけでなく、旧データの特定、削除、再登録、確認までを1セットにします。

小型ツール化するなら最初に必要な機能

文書数が増え、手作業での更新確認が難しくなったら、小型ツール化を検討できます。

最初から複雑な管理画面は必要ありません。まずは次の機能で十分です。

• 文書一覧
• 版数と更新日の表示
• RAG登録済み・未登録・更新待ちの状態管理
• 追加・差し替え・削除の実行
• 登録エラーの表示
• テスト質問と確認結果の記録
• 参照元リンクの確認

その後、必要に応じて次の機能を追加します。

• Google Driveや共有フォルダの変更検知
• 更新担当者への通知
• 期限切れ文書の警告
• 重複ファイルの検出
• 更新前後の回答比較
• 部署や利用者ごとの権限制御

重要なのは、自動化の範囲を広げることではなく、古い文書が回答へ混ざった時に原因を追えることです。

相談前に整理するとよい情報

RAGの文書更新や小型管理ツールを相談する場合は、次の情報があると範囲を決めやすくなります。

• 現在使っているRAGやAIチャットの構成
• 元文書の保存場所
• ファイル形式と文書数
• 更新頻度が高い文書
• 削除できない旧版があるか
• 古い回答が出た具体例
• 文書を更新する担当者
• 誰がAIチャットを使うか
• クラウドへ出せない情報があるか
• 手動更新と自動同期のどちらを希望するか

完璧な仕様書は必要ありません。古い回答の例と、本来参照してほしい最新版が分かるだけでも、原因の切り分けを始められます。

YOSHIO.devで相談できること

YOSHIO.devでは、ローカルLLM・RAG環境構築、業務自動化、小型ツール開発について相談できます。

「RAGが古い料金表を参照している」「文書を差し替えても回答が変わらない」「Google Driveの更新を小さく反映したい」「追加・削除・テスト確認を管理する画面が欲しい」といった段階でも、現在の文書と運用を見ながら整理できます。

最初から全社文書を自動同期するのではなく、更新頻度が高い文書や、間違える影響が大きい文書だけに絞って試すことも可能です。

まとめ

RAGや社内AIチャットは、最初に文書を登録して終わりではありません。

元ファイルを更新しても、検索用データが古いままなら、AIは旧版を答え続けることがあります。文書の追加、差し替え、削除、期限切れを分け、旧データの処理と更新後の質問確認までを運用に含める必要があります。

小さく始めるなら、料金表、FAQ、業務マニュアルなど数種類に対象を絞り、文書ID、版数、更新日、RAG登録状態、テスト質問を管理します。

RAGの品質は、モデル選びだけでなく、どの文書が現在有効なのかを継続して管理できるかで変わります。

よくある質問