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

  • RAGに同じ資料を二重登録しない|重複・旧版を混ぜない版管理

    RAGに同じ資料を二重登録しない|重複・旧版を混ぜない版管理

    RAGへ社内資料を追加していると、いつの間にか同じ内容のファイルが増えることがあります。

    • 料金表.pdf
    • 料金表_最新版.pdf
    • 料金表_最終.pdf
    • 料金表_最終_修正.pdf
    • 別フォルダにコピーされた同じPDF

    人がフォルダを見るだけでも迷う状態で、すべてをRAGへ登録すると、検索対象にも同じ内容や古い内容が並びます。その結果、同じ根拠が何件も表示されたり、旧料金と新料金が同時に候補へ入ったり、どの版をもとに回答したのか説明しにくくなったりします。

    対策は、単に「重複ファイルを削除する」ことではありません。原本を保管する場所と、RAGが検索する対象を分け、同じ文書を表すIDと更新ルールを決めることが重要です。

    この記事では、小規模事業者や少人数チーム向けに、RAGへ同じ資料や旧版を混ぜないための文書ID、版番号、内容ハッシュ、差し替え手順、確認方法を整理します。

    結論:原本は残しても、RAGの検索対象は原則1つにする

    最初に決めたいのは、次の役割分担です。

    • 原本保管:過去版を含め、業務上必要な資料を保管する場所
    • RAG検索対象:AIが回答の根拠として検索してよい資料

    原本保管には、契約上・運用上の理由で旧版を残す場合があります。しかし、旧版を残すことと、AIが旧版を検索できることは別です。RAGの検索対象には、原則として有効な最新版だけを入れます。

    例外として過去版も検索させる場合は、「2025年時点の規程を確認したい」のような明確な用途を決め、版や有効期間で絞り込める設計にします。

    項目例目的
    文書IDPRICE-001ファイル名が変わっても同じ文書だと判断する
    表示名サービス料金表人が内容を識別する
    版v3新旧関係を示す
    更新日2026-09-25いつ更新されたか確認する
    内容ハッシュsha256:...内容が完全に同じか確認する
    状態有効 / 旧版 / 保留RAGの検索対象にするか決める

    なぜファイル名だけでは重複を判断できないのか

    ファイル名は人には便利ですが、文書の同一性を判断する基準としては弱いものです。同じ内容でも、ダウンロード時に「(1)」が付く、担当者が「最新版」や「修正済み」を追加する、フォルダ移動でパスが変わる、PDF化で拡張子が変わる、といったことがあります。

    逆に、毎月同じ 料金表.pdf を上書きしていれば、名前は同じでも内容が違います。登録前に、次の3つを分けて考えます。

    1. ファイル名が同じか
    2. 内容が完全に同じか
    3. 業務上、同じ文書の新しい版か

    内容が完全に同じかは、ファイルのハッシュ値で機械的に確認できます。ただし、WordからPDFへ変換した場合や内部情報だけが変わった場合は、見た目や本文が同じでもファイル全体のハッシュが変わることがあります。ハッシュは「完全一致の重複」を見つける方法として使い、同じ文書の新版かどうかは文書IDや担当者の確認と組み合わせます。

    「ファイルの重複」と「チャンクの重なり」は別の問題

    RAGでは、長い文書を検索しやすい単位へ分割して登録することがあります。この分割単位がチャンクです。前後の文脈を保つために、隣り合うチャンクへ一部の文章を重ねる設定もあります。これは検索設計上の意図的な重なりで、同じPDFを二重登録することとは違います。

    検索結果に似た文章が複数出るときは、次の順で確認します。

    • 同じ原本ファイルが複数登録されていないか
    • 旧版と新版が同時に有効になっていないか
    • 同じチャンクが再取り込みされていないか
    • 正常なチャンクの重なりが表示されているだけではないか
    • 検索結果の表示側で同じ文書をまとめる必要がないか

    登録時は「追加・差し替え・保留」の3つに分ける

    1. 追加

    新しい文書IDで、内容も既存資料と異なる資料です。新しく作成した就業規則、新サービスのマニュアル、既存資料とは別の製品仕様書などが該当します。文書ID、版、更新日、管理担当を決めてから検索対象へ入れます。

    2. 差し替え

    同じ文書IDに対する新しい版です。料金改定や手順変更などが該当します。新版を追加するだけで終わらせず、旧版を検索対象から外し、新版が検索できることを確認します。

    3. 保留

    既存資料と似ているが、同じ文書か、新版か、別資料かを自動判定できない状態です。保留資料は検索対象へすぐ入れず、担当者が確認できる一覧へ置きます。

    安定した文書IDを決める

    文書IDは、ファイル名や保存場所が変わっても維持する識別子です。複雑な採番システムは必要ありません。

    • PRICE-001:サービス料金表
    • RULE-003:経費精算規程
    • MANUAL-012:問い合わせ対応マニュアル
    • FAQ-005:契約前FAQ

    文書IDは、資料本文、管理台帳、RAG登録時のメタデータで共通にします。ファイル名、フォルダのフルパス、担当者名、「最新版」「最終」などの状態語は変わりやすいため、IDとは分けて管理します。

    版番号・更新日・有効期間を分けて持つ

    • 版番号:v1、v2、v3
    • 文書の更新日:内容が改訂された日
    • RAG登録日:検索対象へ入れた日
    • 有効開始日:新しいルールや料金を使い始める日
    • 有効終了日:旧版を使わなくなる日

    10月1日から新料金になる資料を9月25日に登録する場合、更新日と有効開始日は同じとは限りません。有効日が重要な資料では、登録したかどうかだけでなく、「いつから検索対象にするか」も決めます。

    メタデータで最新版だけを検索できるようにする

    RAGの製品や構成によっては、ファイルやチャンクへ属性を付け、検索時に条件で絞り込めます。

    document_id: PRICE-001
    version: 3
    updated_at: 2026-09-25
    status: active
    department: sales
    source_path: /approved/pricing/

    重要なのは、ファイル名だけで最新版を判断せず、検索対象かどうかを明示することです。実装方法は、旧版を検索対象から削除する方法と、旧版を残し status: active だけを検索する方法があります。

    過去版検索が不要な小規模運用なら、最初は「RAGの検索対象には最新版だけ」にする方が管理しやすいことがあります。RAG側から旧版を外しても、業務上必要な原本まで削除する必要はありません。

    差し替えは5段階で行う

    1. 新版を受け付ける:文書ID、版、更新日、管理担当、有効開始日を確認する。
    2. 既存版と比較する:同じ文書ID、最新版、内容ハッシュを確認し、完全一致なら追加を止める。
    3. 新版を仮登録する:確認用の検索対象か pending 状態で登録し、文字抽出や表の崩れを確認する。
    4. 旧版を無効化し、新版を有効化する:旧版を検索対象から外すか superseded にし、新版を active にする。
    5. 代表質問で確認する:更新箇所の質問を5〜10件試し、新しい内容・出典・既存質問への影響を確認する。

    差し替え完了は、登録処理の成功だけでなく、実際の検索結果まで確認して判断します。

    失敗しやすい運用パターン

    フォルダ全体を毎回再取り込みする

    登録済みかどうかを見ずに全ファイルを追加すると、同じ資料のチャンクが増える可能性があります。前回の取り込み結果、文書ID、内容ハッシュを記録し、変更があったファイルだけを対象にします。

    「最新版」という名前を信用する

    複数の担当者がそれぞれ「最新版」を持っていることがあります。承認された保管場所、版番号、更新日、管理担当を合わせて確認します。

    新版を追加しただけで更新完了にする

    旧版が検索対象に残っていれば、新旧どちらも候補へ入る可能性があります。更新完了の条件に「旧版を検索対象から外した」「代表質問で新版を確認した」を含めます。

    原本とRAGデータを同時に削除する

    検索対象から旧版を外すことと、業務上の原本を破棄することは別です。原本の保存期間や削除ルールは、社内規程や契約に合わせて決めます。

    自動判定だけで似た資料を消す

    本文が似ていても、対象部門、地域、契約種別が違う別資料かもしれません。完全一致は自動で止め、似ているだけの資料は保留し、人が確認できるようにします。

    スプレッドシートでも始められる管理台帳

    文書ID文書名版更新日状態原本URLRAG登録ID担当
    PRICE-001サービス料金表32026-09-25有効保管先URLfile_xxx営業
    PRICE-001サービス料金表22026-06-01旧版保管先URL–営業

    件数が増えたら、ファイル追加時のハッシュ計算、文書IDの重複チェック、旧版表示、差し替え確認、保留資料の通知、更新後の質問テストを小型ツール化できます。

    最初の点検は「重要資料10件」から始める

    すべての資料を一度に整理しようとすると止まりやすくなります。料金表、サービス対応範囲、契約・解約ルール、問い合わせ対応手順、承認フロー、納期、セキュリティ手順、社内規程、製品仕様、FAQなど、回答を間違えると困る資料を10件選びます。

    各資料について、同じ内容のコピー、旧版、文書ID、最新版、管理担当を確認します。この10件で差し替え手順を作り、問題なく運用できてから対象を広げます。

    YOSHIO.devへ相談する前に整理したいこと

    • 資料が保存されている場所
    • PDF、Word、Excel、Webページなどの種類
    • 現在のおおよそのファイル数
    • 同じ資料のコピーが増えやすい理由
    • 旧版を原本として残す必要があるか
    • 過去時点の内容もAIで検索したいか
    • 更新頻度と更新する担当者
    • 現在使っているRAGやベクトルデータベース
    • 更新後に確認したい代表質問
    • 誤った旧版回答で特に困る資料

    YOSHIO.devでは、資料棚卸し、文書IDとメタデータの整理、差し替え処理、重複チェック、小型の管理画面、更新後の質問テストまで、現在の規模に合わせて相談できます。

    関連する記事・サービス

    よくある質問

    RAGに同じPDFを二重登録するとどうなりますか?

    構成によって結果は異なりますが、同じ内容の検索候補が増え、同じ根拠が複数表示されたり、管理対象や保存量が増えたりすることがあります。登録済みの文書IDと内容ハッシュを確認し、完全一致なら追加しない仕組みを検討します。

    ファイル名が違えば別の資料として登録してよいですか?

    ファイル名だけでは判断できません。内容ハッシュ、文書ID、版、更新日、管理担当を組み合わせて判断します。

    旧版の資料は削除した方がよいですか?

    RAGの検索対象から外すことと、業務上の原本を削除することは別です。原本の保存期間は社内規程や契約に合わせてください。

    チャンクが重なっているのも重複ですか?

    必ずしも重複事故ではありません。文脈を保つため、隣り合うチャンクへ一部の文章を意図的に重ねる設定があります。

    小規模なRAGでも専用の版管理ツールが必要ですか?

    最初から大きなシステムは必要ありません。重要資料10件ほどを対象に、文書ID、版、更新日、状態、原本URL、RAG登録IDをスプレッドシートで管理しても始められます。

    参考情報

  • RAGのバックアップは何を残す?原本・設定・評価質問から復旧できる状態を作る

    RAGのバックアップは何を残す?原本・設定・評価質問から復旧できる状態を作る

    社内文書を検索できるRAGや社内AIチャットを作ったあと、見落とされやすいのがバックアップです。

    動いている間は問題がなくても、次のような場面で「元に戻せない」ことがあります。

    • RAGを動かしていたPCやSSDが故障した
    • OSやツールを更新したら起動しなくなった
    • 別のPCやサーバーへ移行することになった
    • ベクトルDBのデータが壊れた
    • 作った担当者が退職し、設定が分からなくなった
    • 文書を再登録したら、以前より回答品質が落ちた

    このとき、ベクトルDBのフォルダだけをコピーしていても、同じ状態に戻せるとは限りません。

    RAGは、原本文書、文書の分割方法、検索設定、モデル、権限、プロンプトなど、複数の要素で動いているからです。

    この記事では、小規模事業者や少人数チーム向けに、RAGのバックアップで何を残すべきか、何は再生成できるか、復旧後に何を確認するかを整理します。

    RAGのバックアップは「データのコピー」ではなく「再現できる状態」を残す

    バックアップの目的は、ファイルをどこかへコピーすることではありません。

    障害や移行が起きたあとに、次の状態まで戻せることが目的です。

    • 必要な社内文書を検索対象へ戻せる
    • 文書ごとの権限や有効・無効の状態を戻せる
    • 以前と近い条件で検索と回答を実行できる
    • 代表的な質問に対し、必要な根拠を返せる
    • 誰が、どの手順で復旧するか分かる

    つまり、RAGのバックアップは「保存」だけでなく「再構築」と「確認」まで含めて考える必要があります。

    ベクトルDBだけでは戻せない理由

    ベクトルDBには、文書を検索しやすい数値データへ変換した結果や、文書の一部、メタデータなどが保存されます。

    ただし、そのデータが残っていても、次の情報が分からなければ、別環境で同じ状態を再現しにくくなります。

    • どの原本文書から作ったか
    • どの埋め込みモデルを使ったか
    • 文書をどの長さで分割したか
    • 表や見出しをどのように処理したか
    • どの部署・利用者に見せる設定だったか
    • 検索結果を何件取得していたか
    • どのプロンプトで回答を作っていたか
    • 以前の品質を何で判定していたか

    ベクトルデータは重要ですが、RAG全体から見ると「検索用に加工した結果」の一部です。

    原本と設定が残っていれば、時間はかかっても再生成できる場合があります。一方、原本や権限情報が失われると、ベクトルDBが残っていても正しい状態へ戻せないことがあります。

    最低限残したい7つの要素

    1. 原本文書

    最優先で残すのは、RAGへ登録したPDF、Word、Excel、テキスト、Webページの保存データなどの原本です。

    ただし、ファイルを一つのフォルダへコピーするだけでは不十分です。次の情報も一緒に管理します。

    • 文書ID
    • ファイル名
    • 元の保存場所
    • 文書の担当者
    • 更新日
    • 利用対象の部署・グループ
    • 有効、期限切れ、削除予定などの状態
    • RAGへ登録した日

    同じファイル名で内容が違う資料や、「最新版」と書かれた古い資料が混ざると、復旧後に誤った文書を登録する原因になります。

    2. 文書台帳とメタデータ

    文書台帳は、どの資料を検索対象にするかを判断する一覧です。

    最低限、次の列を持つと復旧作業を進めやすくなります。

    項目役割
    文書IDファイル名変更後も同じ文書を追う
    原本パス元資料の場所を確認する
    更新日古い資料を判別する
    所有者内容の確認先を決める
    閲覧グループ権限を戻す
    状態有効・停止・削除予定を分ける
    登録日RAGへ反映した時点を確認する
    備考OCR、表処理、例外設定などを残す

    文書台帳があれば、ベクトルDBをそのまま復元できない場合でも、対象文書を選び直して再登録できます。

    3. 前処理と分割の設定

    RAGの品質は、文書をどのように読み取り、どの単位に分けたかで変わります。

    残したい設定には、次のようなものがあります。

    • PDFや画像にOCRを使ったか
    • ヘッダー、フッター、ページ番号を除外したか
    • 表をテキスト化したか
    • 文書を分割する長さ
    • 分割部分をどれだけ重ねたか
    • 見出しやページ番号をメタデータへ入れたか
    • 対象外にするフォルダやファイル形式

    コードで処理している場合は、実行スクリプトだけでなく、設定ファイルと実行手順も残します。

    担当者の記憶だけに依存すると、再インデックス後に分割単位が変わり、同じ質問でも違う根拠が返ることがあります。

    4. モデルと検索設定

    RAGで使うモデルや検索条件も記録します。

    • 埋め込みモデル名
    • 回答生成に使うモデル名
    • モデルやツールのバージョン
    • 取得する検索結果の件数
    • 類似度のしきい値
    • キーワード検索を併用しているか
    • 再ランキングを使っているか
    • 回答を作るプロンプト
    • 「分からない」と答える条件

    クラウドサービスや外部APIを使う場合、認証情報そのものを通常の設定ファイルへ書いてバックアップするのは避けます。

    「どの秘密情報が必要か」と「どこから安全に取得するか」を復旧手順へ書き、実際のキーやパスワードは別の安全な管理方法を使います。

    5. ベクトルDBとインデックス

    利用しているベクトルDBに、スナップショットやエクスポート機能がある場合は、復旧時間を短くするために活用できます。

    ただし、ベクトルDBのバックアップを唯一の復旧手段にしないことが重要です。

    環境やバージョンの違いでそのまま読み込めない場合や、破損した状態まで保存している場合に備え、原本文書と設定から再インデックスできる状態も残します。

    考え方は次のように分けると整理しやすくなります。

    対象基本方針
    原本文書失うと再現できないため、必ず保存
    文書台帳・権限正しい対象範囲を戻すため、必ず保存
    前処理・検索設定同じ条件を再現するため、必ず保存
    ベクトルDB復旧時間短縮のため保存し、再生成手段も持つ
    一時キャッシュ必要に応じて再生成
    質問・回答ログ利用目的と保存期間を決めて別管理

    6. 権限と除外ルール

    復旧できても、本来見えてはいけない資料が検索結果へ出る状態では成功とはいえません。

    次の情報を残します。

    • 部署・役割ごとの閲覧範囲
    • 機密文書の除外条件
    • 退職者・異動者の扱い
    • 一時的に停止している文書
    • 個人情報を含む文書の処理
    • バックアップ自体を閲覧できる担当者

    バックアップには、通常の検索画面では見えない原本文書がまとまって入ることがあります。そのため、RAG本体だけでなく、バックアップ先のアクセス権限も確認が必要です。

    7. 評価質問と復旧手順

    RAGが起動しただけでは、復旧完了とは判断できません。

    以前から使っている代表質問と、確認したい根拠を残します。

    例:

    • 最新の申請手順を答えられるか
    • 廃止済みの旧手順を回答しないか
    • 回答に参照文書名やページを示せるか
    • 権限のない利用者に機密文書を出さないか
    • 資料にない内容を推測で断定しないか

    復旧手順には、次の流れを書きます。

    1. 新しい環境を用意する
    2. 必要なソフトウェアとモデルをそろえる
    3. 原本文書と文書台帳を戻す
    4. 権限と除外ルールを設定する
    5. ベクトルDBを復元するか、文書を再インデックスする
    6. 代表質問で回答と根拠を確認する
    7. 問題がなければ利用を再開する

    「担当者なら分かる」ではなく、初めて見る人でも順番を追える粒度にします。

    保存するものと再生成するものを分ける

    すべてを同じ頻度で保存すると、運用が重くなります。

    小規模な環境では、次の3種類に分けると管理しやすくなります。

    失うと戻せないもの

    • 原本文書
    • 文書台帳
    • 権限情報
    • 手作業で補正したOCR結果
    • 独自のプロンプトや例外ルール
    • 評価質問と判定基準

    これらは優先度を高くして保存します。

    時間をかければ再生成できるもの

    • ベクトルデータ
    • 検索インデックス
    • 一時的な変換ファイル
    • キャッシュ

    再生成できると判断するには、原本、モデル情報、設定、実行手順が残っている必要があります。

    保存期間を決めるもの

    • 質問・回答ログ
    • 利用者情報
    • エラー記録
    • 古いスナップショット

    ログには、質問者や社内情報が含まれる場合があります。「役立ちそうだから全部残す」ではなく、利用目的、保存期間、閲覧者、削除方法を決めます。

    小規模チーム向けの始め方

    最初から複雑なバックアップ基盤を作る必要はありません。

    まずは次の最小構成から始めます。

    1. RAGの原本文書を、一つの管理対象として特定する
    2. 文書台帳をスプレッドシートで作る
    3. モデル名、分割設定、検索設定を一枚にまとめる
    4. 設定ファイルと実行スクリプトを版管理する
    5. ベクトルDBの保存・エクスポート方法を確認する
    6. 代表質問と期待する根拠を残す
    7. 別フォルダや別端末で一度だけ復旧を試す

    バックアップの頻度は、文書の更新頻度と「何日分の変更まで失ってよいか」で決めます。

    毎日資料が追加されるRAGと、月に一度しか更新しないRAGでは、同じ頻度にする必要はありません。

    復旧テストで確認すること

    バックアップは、実際に戻せなければ意味がありません。

    復旧テストでは、起動確認だけでなく、次を確認します。

    • 文書件数が想定と合っている
    • 最新文書が検索対象になっている
    • 廃止文書が除外されている
    • 文書名、ページ、更新日などの根拠が出る
    • 権限ごとの検索範囲が正しい
    • 代表質問への回答が以前と大きくずれていない
    • 復旧にかかった時間が分かる
    • 手順書だけで担当者以外も作業できる

    モデルやツールの更新で回答文が完全に同じにならないことはあります。

    文章の一致だけを見るのではなく、必要な情報が含まれるか、正しい資料を参照しているか、不要な断定をしていないかで確認します。

    よくある失敗

    ベクトルDBのフォルダだけコピーする

    原本、モデル、分割設定、権限情報がなければ、別環境で同じ状態を再現できないことがあります。

    原本文書とバックアップを同じPCだけに置く

    端末やストレージの故障時に、RAG本体とバックアップを同時に失う可能性があります。少なくとも、同じ故障の影響を受けない保存先を用意します。

    バックアップを一度も戻していない

    保存処理が成功していても、ファイル不足、権限不足、バージョン違いで復元できないことがあります。

    APIキーやパスワードも設定ファイルへ入れる

    バックアップを見られる人が、そのまま外部サービスや社内システムへアクセスできる状態になります。秘密情報は分離し、復旧時の取得方法だけを手順に残します。

    復旧後の品質を確認しない

    文書件数が同じでも、分割や検索設定が変わると回答品質は変わります。評価質問と根拠確認までを復旧作業に含めます。

    YOSHIO.devで相談できること

    YOSHIO.devでは、小規模事業者や少人数チーム向けに、ローカルLLM・RAG環境の構築や運用整理を相談できます。

    例えば、次のような段階から相談できます。

    • 現在のRAGで何を保存すべきか棚卸ししたい
    • 原本文書とベクトルDBの関係を整理したい
    • 別PCや社内サーバーへ移行したい
    • 再インデックスできる設定と手順を残したい
    • 権限を維持したままバックアップしたい
    • 評価質問を使って復旧後の品質を確認したい
    • 担当者しか分からない環境を手順化したい

    大規模な基盤を前提にせず、現在の文書量、利用人数、更新頻度、機密性に合わせて、小さく始める構成を検討できます。

    まとめ

    RAGのバックアップは、ベクトルDBをコピーするだけでは完了しません。

    重要なのは、次の要素をそろえ、別環境で再現できる状態を残すことです。

    • 原本文書
    • 文書台帳
    • 前処理と分割設定
    • モデルと検索設定
    • ベクトルDB
    • 権限と除外ルール
    • 評価質問と復旧手順

    まずは、原本文書、文書台帳、設定一覧、代表質問の4点をそろえ、別フォルダや別端末で一度だけ戻してみると、足りない情報が見えます。

    「保存しているから大丈夫」ではなく、「戻して質問できるから大丈夫」という状態を目標にしましょう。

    関連リンク

    FAQ

    RAGはベクトルDBだけバックアップすれば復旧できますか?

    ベクトルDBだけで復旧できるとは限りません。原本文書、埋め込みモデル、文書分割、メタデータ、権限、検索設定などが分からないと、別環境で同じ状態を再現しにくくなります。ベクトルDBの保存に加え、原本と設定から再インデックスできる状態を残すことが重要です。

    ベクトルデータは毎回保存する必要がありますか?

    文書量、更新頻度、再生成にかかる時間で判断します。原本と設定から短時間で再生成できる小規模環境なら、原本と設定の保全を優先する方法があります。再生成に長時間かかる場合は、ベクトルDBのスナップショットやエクスポートも併用すると復旧時間を短縮できます。

    ローカルLLMならバックアップを外部へ出さない方が安全ですか?

    外部送信を避けたい場合は、社内管理の別端末、NAS、暗号化した媒体などが候補になります。ただし、同じPCだけに置くと端末故障時に同時に失う可能性があります。保存場所だけでなく、暗号化、閲覧権限、持ち出し、廃棄方法まで含めて決めます。

    復旧テストは何を確認すればよいですか?

    起動するかだけでなく、最新文書が検索できるか、廃止文書が除外されているか、正しい根拠を示すか、権限のない資料を出さないかを確認します。以前から使っている代表質問を残し、復旧後も同じ観点で評価できるようにします。

    RAGのバックアップ設計は導入前に決めるべきですか?

    導入前に原本文書の保存場所、設定の管理方法、権限、復旧担当を決めておくと安全です。すでに運用中でも、原本文書、文書台帳、設定一覧、代表質問から順に整理すれば改善できます。

  • RAGが古い資料を答え続けるのを防ぐには?追加・差し替え・削除の更新設計

    RAGが古い資料を答え続けるのを防ぐには?追加・差し替え・削除の更新設計

    社内文書を検索できる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の品質は、モデル選びだけでなく、どの文書が現在有効なのかを継続して管理できるかで変わります。

    よくある質問

    元のPDFを上書きすれば、RAGの回答も自動で更新されますか?

    構成によります。元ファイルの変更を検知して検索用データを再作成する仕組みがなければ、RAG側には古い内容が残ることがあります。上書き後に旧データの削除、新版の再登録、テスト質問による確認が必要です。

    RAGから古い文書を削除するにはどうすればよいですか?

    元ファイルだけでなく、文書を分割して登録した検索インデックスやベクトルデータも対象にします。文書IDで登録データを追えるようにしておくと削除しやすくなります。履歴として残す場合は、保管場所とAI検索の対象を分けます。

    RAGの文書更新は毎日行うべきですか?

    すべての文書を毎日更新する必要はありません。料金表や規程は変更時に手動確認し、議事録やレポートは定期更新、FAQや商品情報は変更検知にするなど、文書の頻度と間違えた時の影響で分けると運用しやすくなります。

    Google DriveやNotionの更新をRAGへ自動反映できますか?

    APIや連携方法が利用できる構成なら可能です。ただし、変更ファイルを追加するだけでなく、差し替え前のデータ削除、権限、削除済み文書、更新後の回答確認まで設計する必要があります。最初は対象フォルダや文書種類を絞る方法が現実的です。

    小規模なRAGでも文書管理ツールは必要ですか?

    文書数が少ないうちはスプレッドシートでも管理できます。文書ID、版数、更新日、登録状態、担当者、テスト質問を記録できれば十分です。更新漏れや重複登録が増えた段階で、小型管理画面や変更検知を追加すると無駄が少なくなります。