工場RAGの文書版管理を導入する方法｜旧版回答を防ぐ要件と検収

工場RAGに文書版管理を導入するとき、検索精度だけを評価しても現場のリスクは残ります。改訂前の作業標準書を流暢に引用し、現在は使わないトルク値や検査手順を「根拠付き」で回答することがあるからです。タイ工場では日本語の原本、タイ語の現場版、英語の顧客向け文書が別々の時刻に更新されます。本記事では、承認された版だけを検索対象にする設計、差分同期、廃止版の削除、権限変更、FAT/SAT、発注仕様書の書き方を実務順に整理します。

工場RAGの事故は「もっともらしい旧版回答」から始まる

例えば、設備M-04の締付トルクを改訂したとします。品質保証が改訂3を承認し、製造技術がタイ語版を配布しても、検索インデックスには改訂2のPDFから切り出した文章が残っているかもしれません。AIが「改訂2、4ページ」を正しく引用しても、それは現時点で使ってよい根拠ではありません。引用元が存在することと、その版が使用可能であることは別の判定です。現場の作業者に表示される回答は後者を満たさなければなりません。

同じ問題は、設備の保全手順、化学品の取扱い、外観検査基準、顧客別梱包仕様、ライン立上げのチェックリストでも起きます。質問に近い文書を探すだけでは、顧客・拠点・設備・適用開始日・承認状態が違う文書を混ぜる危険があります。特に日本本社が先に原本を改訂し、タイ語の作業指示が後から承認される運用では、「どの言語がどの版に対応するか」を曖昧にできません。

ISOの文書管理に関する公開資料も、発行前の承認、現行改訂の識別、適用箇所での適切な版の利用、旧版の意図しない使用の防止を挙げています。ただし、以下に示すRAGのフィールド構成や試験方法をISOが一律に指定しているわけではありません。品質マネジメントの原則を検索システムに落とし込むための実装提案として読んでください。参考：ISO公開資料、ISO 9001:2015の文書化した情報に関するガイダンス。

この問題は「RAGを導入するか」という投資判断とは段階が違います。構築方式と費用の全体像はタイ工場のRAG構築ガイド、PoCから本番へ進める条件は企業向けRAG導入の判断ガイドで説明しています。ここでは、導入を決めた後に文書の改訂をどう安全に運用へ反映するかに絞ります。

まず決めるのは検索技術ではなく「現行版を決める人」

ベクトルDBにPDFを投入する前に、文書の責任表を作ります。品質保証は発行可否と適用日、製造技術は設備・工程への適用範囲、各言語のオーナーは翻訳の整合性、ITは同期と権限制御を引き受けます。RAGの開発会社が改訂3を「技術的に取り込めた」ことは、品質保証が改訂3を「現場で使ってよい」と承認したことを意味しません。この境界を業務フローに残します。

最小限の文書台帳には、論理文書ID、改訂番号、状態、適用開始日時、対象拠点・ライン・設備、言語、言語間の対応関係、承認者、機密区分、アクセス権グループ、原本の場所を置きます。PDFファイル名だけを識別子にすると、名称変更や再保存で別文書として扱われ、旧チャンクが残りやすくなります。文書IDは「WI-M04-TORQUE」のように改訂番号から独立させ、改訂番号は別属性にします。表示タイトルは人が読めるようにしつつ、機械的な同期はIDで追います。

状態は最低でも「作成中」「レビュー中」「承認済み・発効待ち」「有効」「廃止」「保留」を区別します。承認と発効も同じではありません。改訂4が今日承認されても、夜勤明けの翌朝から適用するなら、それまでは改訂3が有効です。逆に安全上の緊急停止で改訂3の使用を即時禁止する場合、改訂4がまだ無くても回答を止める必要があります。このため検索側の判定は単純な latest = true より、承認状態、適用開始時刻、適用対象、保留命令を合わせて評価する設計が安全です。

工場RAGの文書版管理を導入する方法｜旧版回答を防ぐ要件と検収 - figure 1

日本語原本とタイ語版が同時に改訂されない場合

タイの工場でよくあるのは、日本語原本の改訂4だけが承認され、タイ語版は改訂3相当のまま、という時差です。「同じ文書IDの最大改訂番号を各言語へ適用」すると、タイ語の古い手順を新しい版として誤表示しかねません。原本と翻訳は別の承認イベントとして扱い、翻訳版に「原本のどの改訂に対応するか」「翻訳の承認日時」「タイのどのラインで有効か」を持たせます。

現行タイ語版が未承認なら、タイ語の質問に日本語原本の機械翻訳をそのまま作業指示として返すべきではありません。用途に応じて「承認済みのタイ語版は未発行です。品質保証へ確認してください」と返す、または権限を持つ技術者に原本へのリンクだけを示すなど、代替動作を合意します。ここは翻訳性能よりも、誰が現場へ使用を許可するかという運用判断です。

承認から検索公開までを一つの変更手順にする

文書の改訂を検知した瞬間に検索へ公開する構成は避けます。候補版の取り込み、テキスト抽出、チャンク化、メタデータ検証、試験検索、承認済み版への切替を段階化します。候補版を隔離された検証領域に入れ、リンク切れ、表の崩れ、図に埋め込まれた数値、単位、旧版からの差分を確認してから、公開対象の版を切り替えます。

切替の単位は、ひとつのPDFファイルではなく論理文書とその派生チャンクの集合です。改訂3の8チャンクと改訂4の7チャンクが同時に検索対象になると、見出しが似た断片を混在させた回答が生まれます。実装では新旧の検索可否をメタデータで切り替える方法、インデックスの別名を切り替える方法、旧チャンクを削除してから新チャンクを公開する方法などがあります。採用する検索基盤の原子的な更新機能を確認し、切替中に旧版と新版が混ざらないことを試験します。基盤が原子的な切替を提供しないなら、移行中は該当文書の回答を一時停止する設計も必要です。

ロールバックも「古いPDFを再アップロードする」だけでは不十分です。改訂4を取り消すときに、改訂3が再び有効になるのか、あるいは回答停止なのかは品質保証が決めます。検索インデックス、引用表示、権限情報、キャッシュ、会話履歴の参照可能性まで戻し方を定義し、操作履歴に理由と承認者を残します。過去の回答そのものを後から消せない場合には、少なくとも回答画面に発行時点と文書版を表示し、再利用時に最新版を確認する導線を用意します。

差分同期は「更新」「削除」「権限変更」を別々に試す

差分同期とは、前回以降に加わった、変更された、削除された文書を取り込む運用です。MicrosoftのAzure AI Searchは、対象データソースが変更検知をサポートする場合にインデクサーが新規・更新分を処理できると説明しています。ただし、削除検知は別の設定です。Azure Storage由来の文書では、Blobのsoft deleteなど適切な削除検知を最初から構成し、インデクサーが削除状態を処理できる期間を確保する必要があります。物理ファイルを先に消してしまうと、検索側に孤児の文書が残ることがあります。参考：Azure AI Searchのインデクサー、変更・削除検知。

Amazon Bedrock Knowledge Basesの資料も、データソースの追加・変更・削除後に同期を実行する必要があり、同期は差分処理であると説明しています。つまり文書改訂の承認だけでは検索内容は切り替わりません。同期の起動・完了・失敗通知・再実行を運用に組み込む必要があります。カスタムデータソースで明示的に文書を削除するAPIもありますが、すべてのコネクタが同じ方法で動くと仮定せず、選ぶ製品と接続先ごとに確認します。参考：AWSの同期手順、文書削除API。

同期ジョブが「成功」でも、旧版が回答に使われない証拠にはなりません。ジョブが処理した件数、失敗ファイル、再試行待ち、インデックスの対象件数を見たうえで、旧版固有の語句で実際に検索する必要があります。特に改訂後に消えた段落や、図中にだけある数値で検索します。新しい版が引けることと、旧い版が引けないことは別々の合格条件です。旧版の保存を監査目的で続ける場合でも、保管庫に残すこととRAGの検索対象に残すことは分離できます。

更新イベントが届かなかったときの検知

夜間バッチ、手動アップロード、ネットワーク断、権限不足でイベントが抜ける可能性があります。そこで、差分イベントだけに依存せず、定期的に文書台帳の有効版リストと検索インデックスの有効版リストを照合します。比較キーは論理ID・改訂・言語・適用範囲・状態です。検索側にだけある旧版、台帳側にあるのに未投入の新版、件数が合わないチャンク、権限だけ古い文書を例外として出します。

不一致が見つかったときは、どの程度で回答停止とするかを契約時に決めます。安全・品質に関わる作業指示は、同期遅延が続いたまま「たぶん正しい回答」を出すより、該当文書の回答を保留して原本への確認を促す方が実務に合います。一方、社内制度案内などは警告付きの一時継続が許容されることもあります。重要度によって停止条件を分けることが、過剰停止と危険な継続の両方を避けます。

工場RAGの文書版管理を導入する方法｜旧版回答を防ぐ要件と検収 - figure 2

ACL変更は文書の更新と同じ優先度で反映する

品質トラブル報告や顧客図面は、部署・顧客・プロジェクトによって閲覧権限が違います。RAGが検索した後で文章だけ黒塗りする設計では、候補文書のタイトルや要約が漏れることがあります。検索前に利用者の本人確認と権限を確定し、許可された文書だけを取得させる設計を求めます。回答に付く引用リンクも、同じ権限で開ける必要があります。

Azure AI Searchには文字列によるセキュリティフィルターと文書レベル権限の仕組みがありますが、ネイティブACL/RBACやSharePoint権限取り込みにはプレビュー段階の機能が含まれます。SharePoint連携のプレビューでは、2026-05-01-preview以降、個別に固有権限を持つ項目のACL変更は次回のインデクサー実行で増分取得できます。一方、サイト・ライブラリ・フォルダーなど親から継承する権限が変わった場合は、明示的な権限再同期または対象文書の再処理が必要です。使用するAPIバージョン、権限の継承形態、更新手順を見積書で確認してください。参考：Microsoftの文書レベルアクセス制御、セキュリティ実装の注意。

AWSのカスタムデータソース向けACLフィルタリングも、アプリケーションが確認済みの利用者情報を渡す前提です。資料はACL awarenessが認証そのものではないと明示しています。従業員が別部署へ異動した日、退職した日、顧客案件から外れた日を想定し、元文書の権限変更からRAGで検索不可になるまでの最大時間を測ります。「文書本文は更新していないから同期不要」と判断すると、権限だけ古いチャンクが残り得ます。参考：AWSの文書レベルアクセス制御。

権限の試験は許可より拒否を重視する

FATでは、製造技術、品質保証、一般作業者、他顧客担当、退職者相当の試験アカウントを用意します。各アカウントに対して、許可文書が見つかるかだけでなく、禁止文書が検索結果・引用・会話要約・推奨質問に出ないかを確認します。拒否すべきケースで1件でも出たら、その試験は不合格とする基準を例として設定できます。この「ゼロ件」は契約で決める受入条件であり、製品の公称精度ではありません。

タイ拠点の共有端末では、交代勤務の前利用者のセッションが残りやすい運用も考慮します。端末ログアウト、セッション期限、キャッシュ、ダウンロードした引用文書の扱いはRAGだけでは解決できません。ITの本人確認と現場の端末管理を同じ試験票に入れて、検索フィルターの正常動作だけで完了にしないことが必要です。

旧版回答を防ぐためのテストセットを先に作る

受入試験は一般的な「質問に答えられたか」だけでは不十分です。まず、対象工程の現行文書を10〜20件選び、改訂前後で値・手順・適用ラインが変わった箇所を品質保証と現場で拾います。件数は最初の試験規模の例であり、必要数は文書の量とリスクに応じて決めます。各質問に正しい回答文、引用すべき論理文書IDと改訂、使ってはいけない旧版、適用条件、回答できない場合の動作を記録します。

たとえば「M-04、ラインB、夜勤で使う締付条件は？」には、ラインAだけの条件を返してはなりません。「旧仕様の検査頻度は？」には履歴照会の権限がある人だけ旧版を示し、通常の作業回答では現行版と混同しない表示にします。「タイ語版はまだ未承認だが、日本語改訂4の内容をタイ語で教えて」には、決めた業務ルールに沿って保留または限定表示を返します。これらの試験を更新前と更新後に繰り返すと、差分同期の実効性が見えます。

正答率という一つの平均値だけを合否に使わない方がよい理由は、危険度が違うからです。一般的な設備名称の質問を9件正しく答えても、危険な旧版トルクを1件返せば現場の運用には耐えません。合格基準を「現行版の引用」「旧版の非表示」「対象ラインの一致」「権限拒否」「根拠不足時の保留」に分け、それぞれ記録します。試験結果には質問文、利用者ロール、時刻、検索された文書と改訂、回答、判定者、再試験結果を残します。

回答画面には、最低限、文書名、論理ID、改訂、適用開始日、拠点・ライン、引用箇所、原本リンクを表示したいところです。「根拠：設備マニュアル.pdf」だけでは、現場責任者が最新版か判断できません。引用箇所を押した先の文書がアクセス不能なら、回答の検証もできません。表示項目はUIデザインの飾りではなく、誤った適用を止めるための手掛かりです。

工場RAGの文書版管理を導入する方法｜旧版回答を防ぐ要件と検収 - figure 3

FATで確かめること：設定どおりに改訂が流れるか

FAT（工場出荷前検査・受入試験）では、実ラインへ接続する前にテスト文書で一連の変更を再現します。ベンダーに完成したチャット画面を見せてもらうだけでは足りません。顧客側が用意した改訂シナリオを、台帳更新から検索回答まで通します。異なる文書IDで同じファイル名、同じ文書IDで異なる改訂、1つの改訂でチャンク数が減るケース、英語だけ先に公開されるケース、承認後に取消しが入るケースを含めます。

合否票には「承認前は検索されない」「発効時刻前は旧版が有効」「発効後は新版だけを引用」「廃止版を通常質問から取得しない」「旧版固有値を質問しても作業指示として返さない」「ACL変更後は許可されない利用者に出ない」「同期失敗時は通知と回答停止が働く」を別行にします。自動テストのログだけでなく、品質保証が回答文と原本を照らす確認を含めます。数値しきい値や処理時間は工場の運用に合わせてRFPで決め、根拠のない「99%正答」などを標準値として書かないことが大切です。

更新遅延の試験では、文書承認から検索反映までを計測します。ただし、時間だけで合格にしません。同期が終わった後の旧チャンク削除、キャッシュ更新、権限更新、引用リンクの一致を確認します。予定の時間を超えたとき誰に通知し、どの回答を止め、誰が再開を承認するかまで決めておくと、本番の夜勤でも判断がぶれません。

変更を一つずつ起こす具体的な検収シナリオ

架空の文書「WI-M04-TORQUE」を使うなら、最初に改訂2を有効とし、ラインBの締付条件を「値A」と記載します。値は実機の数値を使わず、あくまで試験用の記号にします。QA用アカウントと作業者用アカウントで質問し、双方が改訂2を引用できることを確認します。次に改訂3の候補を登録し、条件を「値B」に変更します。この時点では承認前なので、候補が検索結果に現れたり、値Bが回答に混ざったりすれば不合格です。承認後も発効時刻を翌朝に設定し、時刻前の回答が改訂2、時刻後の回答が改訂3へ切り替わるかを連続で記録します。

ここで改訂3から一段落を削除し、改訂2だけにあった固有語でも質問します。新版の引用が正しいだけでなく、削除された段落が現行手順として一切返らないことを確かめます。検索基盤が旧チャンクを削除する設計ならIDごとの残存件数を確認し、検索フィルターで旧版を隠す設計なら通常利用者が旧版を取得できないことと履歴照会権限が別に守られることを確認します。キャッシュを利用する構成では、更新直後の最初の質問と繰り返し質問の両方を保存します。

次にタイ語版を改訂2相当のまま残し、日本語の改訂3だけを有効にします。タイ語の一般利用者への回答が定めた保留文になり、管理者が原本を開く場合も未承認翻訳を正式手順として表示しないことを確認します。同じ文書を読めていた作業者の権限を取り消し、直後・次回同期後・キャッシュ期限後の各時点で検索、引用リンク、会話要約に漏れがないかを調べます。最後に改訂3を緊急停止し、作業者向け回答が直ちに保留へ変わるか、復帰にQAの承認が必要かを試します。

このシナリオをRFPに添える際には、各操作の時刻、台帳の前後値、同期ジョブID、検索に残った改訂、回答画面のスクリーンショット、判定者を証跡として提出させます。ベンダーに「何秒で反映できるか」だけを答えさせず、反映できなかった時に検知・通知・停止できるかまで実演してもらいます。FATで使った同じ試験票をSATでも実環境に合わせて再実行すれば、デモ環境だけで成立した機能を見抜けます。

SATで確かめること：タイの現場運用と一致するか

SAT（現地据付後試験・現地受入試験）は、実際の文書管理システム、タイ拠点のID管理、共有端末、ネットワーク、勤務交代、原本保管場所で実施します。FATで成功した接続でも、本番ではファイルパス、SharePointサイト、スキャナーのPDF、ネットワーク遅延、部門権限の違いで失敗します。試験では日本本社の承認からタイ語版承認までの実際の順序をなぞり、休日や夜間に改訂が発効した場合も確認します。

現場責任者には、問いをタイ語で入力し、結果の適用ライン、改訂、引用箇所を自分で確認してもらいます。翻訳の自然さは大切ですが、作業上の単位や型番を誤読しないこと、未承認版を作業指示として言い切らないことが先です。原本がスキャン画像ならOCRが表や脚注を正しく読めるかも確認します。図面や写真だけで示された工程差は、テキスト抽出だけで十分かを個別に判断します。

SATの終了条件は、試験項目が通ったことに加え、運用担当が自分で新しい改訂を登録、失敗を検知、旧版を検索対象から外し、緊急停止を行えることです。画面を納品しても、改訂時に毎回ベンダーの作業を待つなら「文書版管理を導入した」とは言えません。担当者の引継ぎ、操作手順、監査ログの保管場所、障害時連絡先を確認します。

RFPには「機能名」より変更イベントと証跡を書く

発注仕様書には「RAGで最新版を回答」「権限を継承」だけでは不足します。ベンダーによって「最新版」は更新日時が新しいPDF、ファイル名の末尾番号が大きいPDF、承認済み文書の最新改訂など意味が違います。まず現行版を判定する文書台帳と責任者を定義し、以下の項目を回答可能な形で要求します。

RFP項目	ベンダーに答えてもらう内容	受入時に見る証跡
文書の識別	論理ID、改訂、言語、拠点、ライン、発効日をどう保持するか	台帳と検索結果の突合
承認と公開	承認前、発効待ち、保留、廃止をどう除外するか	状態別の検索記録
差分同期	追加・変更・削除をどのイベントで検知し、失敗時どう再実行するか	同期履歴と例外一覧
旧版除去	古いチャンク、引用、キャッシュをどう無効化するか	旧版固有語での検索結果
権限変更	ACLの取得方法、反映時間、本人確認の責任境界	許可・拒否アカウントの試験
多言語改訂	タイ語版が未承認のときの応答と原本への対応づけ	言語別の試験記録
監査と復旧	誰がいつ切替・取消し・回答停止をしたか	ログと復旧演習
引渡し	台帳、抽出文、評価セット、設定、運用手順の所有者	エクスポート成果物と操作確認

見積では、一回限りの投入作業と継続運用を分けてもらいます。文書の改訂が多い現場ほど、初期構築後の監視、翻訳承認、再索引、例外処理、評価セット更新が重要です。どの製品が安いかを比較する前に、既存の文書管理システムから承認状態・ACL・廃止イベントを取得できるかを調べてください。取得できない場合、追加の連携開発か手動の台帳運用が必要になります。

RFPに添付するサンプルは、実際の機密文書でなくても構いません。架空の作業指示を改訂1から改訂2へ変え、ある値を削除し、タイ語版だけ承認を遅らせ、権限を一人から取り消すシナリオを配ります。各社に同じ入力と同じ合格条件でデモを依頼すれば、「検索できます」という説明より比較しやすくなります。デモでできたこと、本番構成で可能なこと、製品プレビュー機能に依存することを分けて回答してもらいます。

運用開始後の責任分担と改善サイクル

稼働後は、品質保証が現行版の正本、製造技術が工程への適用、ITが同期・権限・監視、現場監督者が回答の使われ方を見ます。ベンダーは障害解析と改善を支援できますが、改訂を発効させる業務判断そのものは工場側に残ります。定例レビューでは、更新遅延、差分照合の不一致、旧版を拾った質問、根拠不足で保留した質問、権限拒否の失敗を確認し、評価セットへ追加します。

利用ログで「旧版」という言葉が多く出るなら、単に検索ランキングを調整する前に、現場が過去の工程条件を正当な目的で探しているのか、現行版が見つからず仕方なく旧版を探しているのかを区別します。履歴照会と作業指示はUIと権限を分けるのがよい場合があります。前者には「履歴・使用禁止」の明示、後者には「現行・適用対象」の明示を求めます。

年に一度の監査だけでは、改訂のたびに起きる版ずれを見逃します。変更イベントごとに自動チェックし、定期的に台帳とインデックスを突合し、月次などの運用会議で例外を見直す三層にします。頻度は文書の変更数と危険度で決めてください。システムが正しい回答を作る能力と、誤った根拠を使わせない能力を別々に管理することが、工場RAGの継続運用の核心です。

よくある質問

工場RAGの文書版管理はファイル名の「Rev.」だけでできますか？

推奨しません。ファイル名から改訂番号を読めても、承認状態、適用開始時刻、言語間の対応、対象ライン、廃止、権限変更を判定できないためです。論理文書IDと版属性を台帳で管理し、検索インデックスの全チャンクへ引き継ぐ設計が必要です。例外的に単純な環境でも、ファイル名の変更や再保存で旧版が残らないか必ず試験してください。

RAGの差分同期が成功したら旧版回答は防げますか？

同期成功は必要条件の一つですが十分ではありません。変更検知と削除検知は別であり、古いチャンクやキャッシュ、引用表示に旧版が残る可能性があります。旧版だけにある語句や数値で検索し、作業回答に出ないことを検収します。失敗した文書が再試行待ちに残っていないかも見ます。

日本語原本が新しく、タイ語版が未承認のときはどうしますか？

文書オーナーが翻訳版の効力と代替動作を決めます。現場の一般利用者には「承認済みタイ語版なし」と表示し、作業指示を断定しない方法が考えられます。権限を持つ担当者へ日本語原本を見せる場合も、未承認翻訳を正式手順と誤認させない表示が必要です。

工場RAGのFAT/SATでは何を検収すべきですか？

FATでは、承認前・発効前・新版切替・旧版除去・廃止・権限変更・同期失敗を再現します。SATでは、タイ拠点の実文書経路、端末、ID、言語、勤務交代、障害通知で同じシナリオを確認します。一般的な回答正答率だけではなく、旧版と禁止文書が出ないことを独立した合格条件にします。

既存の文書管理システムを残したまま導入できますか？

可能な場合があります。既存システムを正本として、承認状態・改訂・適用日・ACL・廃止情報を検索側に渡せるかが分岐点です。コネクタが本文だけを取得するなら、台帳連携を追加するか、承認済み文書だけを出力する運用が必要です。製品名だけで判断せず、実際の接続方式と削除・権限更新を試験してください。

まとめ：承認された現行版だけを根拠にする

工場RAGの文書版管理を導入するなら、まず文書オーナーと現行版の判定条件を決め、承認・発効・廃止・権限変更を検索への変更イベントとして扱います。次に、旧チャンクの除去と新チャンクの公開を一つの切替として設計し、旧版固有の質問、未承認翻訳、権限拒否をFAT/SATで確認します。ベンダー選定では「最新版を回答する」という宣伝文句より、台帳との突合、失敗時の停止、証跡の引渡しを比較してください。

TOMAS TECHでは、タイ工場の文書台帳、現行版の判定、旧版回答テスト、FAT/SAT項目の整理段階からご相談いただけます。既存の文書管理システムを残す前提でも、お問い合わせから対象工程と改訂運用をお知らせください。