タグ: バックアップ

社内文書を検索できる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点をそろえ、別フォルダや別端末で一度だけ戻してみると、足りない情報が見えます。

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

関連リンク

• ローカルLLM・RAG環境構築の相談
• RAGへ入れる文書を棚卸しする方法
• RAG文書の追加・差し替え・削除ルール
• RAGの評価質問と採点ルールを作る
• RAGの閲覧範囲と権限を設計する

FAQ