LOADING
本文へ移動

RAGで古い社内規程が回答されるときの直し方|改定日・施行日・廃止版の扱い

経費規程を改定したのに、社内AIが以前の上限額を答える。「最新の情報で回答して」とプロンプトに追記しても直らないなら、回答文の前に、どの版が検索へ渡ったかを確認します。

RAGは外部文書を検索して回答の材料にする仕組みです。原本を差し替えただけでは、取り込み済みの索引、文書の断片、キャッシュまで更新されたとは限りません。本稿では、RAG精度改善の全体像から、規程の版と適用時点に絞って扱います。

最初に、誤回答が生まれた工程を特定する

横に長い表は、左右にスクロールして確認できます。

調べる工程 見るもの 問題がある場合の対応
原本 正本の場所、承認状態、適用対象 文書管理者が正しい版と範囲を確定
取り込み 文書ID・版・取り込み時刻、断片の件数 更新漏れ、旧断片、削除伝播を修正
検索 実際に取得した断片と日時・組織の条件 有効期間と閲覧権限の条件を見直す
回答 引用した版、説明した適用日 適用条件を回答へ示し、曖昧なら確認する

誤回答の質問、利用者の権限、質問の対象日、検索で返った文書IDを同じ実行記録へ残します。利用者の個人情報や秘密情報を、調査用ログへ無制限に複製しないようにします。

改定日と施行日は別の列にする

次は架空の経費規程です。金額は説明用で、実在の会社の規程ではありません。

文書ID・版 公表日 有効期間 対象 宿泊費の上限
EXP-01 v1 4月1日 4月1日以上、10月1日未満 国内社員 10,000円
EXP-01 v2 9月15日 10月1日以上 国内社員 12,000円

9月20日時点でファイルの更新日が一番新しいのはv2ですが、その日の出張に適用するのはv1です。逆に、10月に9月の出張を精算する場合も、規程が出張日基準ならv1を参照します。申請日基準なのか、利用日基準なのかは業務側が決める事項です。

台帳には、文書ID、版、公表日時、有効開始・終了日時、対象組織、承認者、正本URL、置換先、アクセス区分、取り込み日時を残します。日時のタイムゾーンと境界も固定します。「10月1日まで」のような曖昧な表現より、開始を含み終了を含まない範囲にすると、境界日の重複を避けやすくなります。

検索対象を、質問の適用日で絞る

処理は、①質問の対象日・対象組織を確定し、②閲覧できる文書へ限定し、③有効期間に入る版を検索し、④版と根拠を付けて回答する、という順に設計します。

規程を選ぶ条件の例(特定製品の実行コードではありません)
対象者が文書を閲覧できる
かつ 文書の対象組織が質問に合う
かつ 有効開始日時 <= 質問の対象日時
かつ(有効終了日時がない、または 質問の対象日時 < 有効終了日時)
かつ 承認済みの版である

同じ範囲で二つの版が有効になっていたら、検索順位で一つを選ばず、台帳の矛盾として文書管理者へ戻します。対象日が曖昧な過去の相談は、日付を確認する回答を期待結果にします。

Azure AI Searchには、日付や論理条件で検索結果を絞るフィルターがあります。ただし、製品が社内規程の施行日を自動で理解するという意味ではありません。有効期間や対象組織を索引の項目として設計し、検索条件へ渡す必要があります。Microsoftのフィルター仕様

廃止版は、保存と検索利用を分ける

過去の判断根拠を調べる業務では、廃止版の保全が必要になることがあります。保管から削除するかどうかと、現行の質問に使うかどうかは分けて決めます。

現行業務だけを答える小さなFAQなら、承認済みの現行版だけを別の索引へ配布する方法があります。仕組みは単純になりますが、過去時点の質問は別の窓口へ送る必要があります。過去の回答も必要なら、有効期間付きで履歴を保持する方法が候補になります。その分、版の重複・検索条件・閲覧権限のテストが増えます。

原本の削除が索引の削除に直結するとは限りません。MicrosoftのBlob索引の資料でも、変更検出と削除検出には別の設定・条件があります。採用する取り込み経路で、旧版の全断片、キャッシュ、引用先まで確認します。変更・削除検出の仕様

改定前後の質問を、同じ評価表へ置く

先ほどの架空規程なら、次のような組み合わせを試します。金額を正しく答えるだけでなく、根拠の版と対象日も一致させます。

試す質問・状態 期待する扱い
9月20日の出張。国内社員 v1の上限10,000円を根拠付きで示す
10月1日の出張。国内社員 v2の上限12,000円を根拠付きで示す
「先月の出張」のみで日付不明 適用日を確認し、上限を断定しない
海外子会社の社員 国内向け規程をそのまま適用せず、対象規程を確認
文書の閲覧権限を失った利用者 回答だけでなく引用やキャッシュからも内容を返さない
v2を取り込み直す v1の不要な断片と混ざらず、v2の重複も生まれない

台帳が正しくても、検索結果が違えば回答は直りません。正解の文書ID、実際の検索文書ID、引用、回答、判定理由を並べ、工程ごとの失敗を区別します。

改定時の評価記録
変更した文書ID・版/変更理由:
公表日/施行日/対象組織:
取り込み前後の文書・断片の確認:
質問/利用者の権限/質問の対象日:
期待する根拠の版/実際に検索された版:
期待する回答/実際の回答:
引用先の到達・閲覧可否:
判定と証拠の場所:
反映責任者/承認者/戻す版:

更新の完了は、本番の質問で判断する

取り込みジョブの成功に加えて、施行日前後の質問と、権限の異なる利用者で確認します。保存済みの会話やキャッシュが旧版の回答を再利用していないかも見ます。失効後のキャッシュ破棄と再認可の条件は、業務の機密性に応じて決めてください。

文書管理者が施行日を確定し、基盤担当が索引へ反映し、業務担当者が回答を確認する。この責任分担を生成AIの社内ルールへ書いておけば、次の改定でも同じ手順を使えます。権限や停止を含む試験は受入テスト仕様書へ追加できます。

資料確認日:2026年10月7日。台帳・条件式・金額は本稿の説明用です。

コメント

トップへ戻る
Core
Dashboard
MyRide
Category
タイトルとURLをコピーしました