お問い合わせ
2026 / 09 / 08 ベストプラクティス

ひな形フォルダを整える — RAGが旧版を返さないために確認したい場面

Lead

RAGが3年前の旧版ひな形を返してしまう場面に備えて、メタデータ・改正前後のフォルダ分離・引用元表示・定期棚卸しを業務の流れに置く運用例をご紹介します。

共有ドライブでは、同名のひな形ファイルが世代別に並んでいる光景に出会うことがあります。契約書_最新版.docx、 契約書_最新版_v2.docx、 契約書_最新版_確定.docx、 契約書_最新版_最終_これで提出.docx — どれが現行版なのかは、 作成された方ご本人にしか分からない、 という状況です。改正前の条文を含む版、 退職された方の下書き、 別の顧問先向けに調整したまま残った版が、 同じフォルダに並んでいることもあります。

人間がフォルダを目視している間は、 「不便ですが業務は回る」 という範囲で収まることが多いようです。ところが、 所内RAG (= 社内文書を検索して回答する仕組み) に 「契約書のひな形を出してほしい」 と問い合わせた瞬間、 状況が変わります。RAGは質問文と文書の類似度で候補を取り出し、LLMは受け取った文書を根拠に整った回答を組み立てます。文書側に 「最新版」 「廃止版」 「改正前」 を区別する属性が無ければ、 もっともらしい体裁で旧版が返ってくる、 ということが起こります。

新旧の判別をAI側に任せるのは、 仕組み上どうしても難しい部分が残ります。AIは渡された文書を真面目に扱うだけで、 「これは旧版だから外そう」 という判断材料を持っていません。文書管理側で新旧の手がかりを残しておく考え方に立ち戻ると、 メタデータ・法改正対応・引用元表示・棚卸しといった場面ごとに、 業務の流れに確認を置きやすくなります。

古い文書が検索結果に混ざる場面

RAGは「検索 → コンテキスト挿入 → 生成」 の流れで動きます。古い文書が混ざる場面のほとんどは、 最初の検索の段階で起きています。検索で旧版が候補に入ってしまえば、LLMはそれを正しい根拠として扱うことになります。

現場でよく見るパターンを並べてみます。世代を別ファイルで残す運用 (= 最新版_v2.docx / _v3.docx のような形) では、 検索インデックス上は全世代が等価に並びやすくなります。法改正で廃止になった様式や、 退職された方の作業中ファイルを 「念のため」 残し続けると、 現役で使えないファイルがインデックスに乗ったままになります。改正前後で同じファイル名を使い、 版情報を文書の冒頭にだけ書いている設計では、AIが版情報を読み取り損ねる場面が出てきます。特定の顧問先向けに調整した版が共通ひな形フォルダに紛れ込んでいると、 別の顧問先への回答にA社固有の条項が混ざる、 という流れになります。

これらはAIを入れたから初めて起きたというより、 文書管理側にあった揺らぎが、AIによる横断検索で表に出てきた、 という形に近いように思います。

文書メタデータを業務の流れに置く

文書メタデータは、 まず3項目から始めるとよさそうです。

  • ステータス: current (= 現行版・参照可) / superseded (= 後継版あり) / deprecated (= 廃止版) / draft (= 作成中) / restricted_template (= 特定顧問先専用)
  • 有効期限: effective_from (= 適用開始日) / effective_until (= 適用終了日) / next_review_date (= 次回見直し予定日)
  • 版: version / supersedes (= 旧版にした対象ファイルID) / superseded_by (= 置き換えた後継ファイルID)

ファイル名規則に書き込む運用でも一定の効果は出ますが、SharePointやGoogle Drive、Boxなどのカスタム列・メタデータプロパティに分けて持たせるほうが、RAG側から構造的に参照しやすくなります。Microsoft LearnのAzure OpenAI On Your Dataの解説では、 検索インデックスのフィールドマッピングで Title を引用元のタイトルに、 File name を引用元のファイル名表示に紐付ける設計が示されています。同じ仕組みでステータスや有効期限を独自のフィールドとして持たせ、 検索結果の絞り込みや並び替えに使う、 という設計が組めます。

新規ファイルについては 「作成時にメタデータを必ず入れる」 という流れにしておくと、 最初から整った状態でインデックスに乗ります。既存ファイルは、 機密度・参照頻度の高いものから順に付与していく形が、 実際に手を付けやすいペースのようです。

法改正前後で気を付けたい場面

士業の業務で気づきやすいのは、 法改正の前後で起きるひな形管理の場面です。改正前のひな形を 「念のため」 残し、 改正後のひな形と同じフォルダに置くと、RAGは両方を等価に候補へ入れます。

実務での整理の置き方として、 いくつかの選択肢があります。

1.改正日を境にフォルダを物理的に分ける (例: 労務_2026年4月改正以降 / 労務_2026年4月改正前)。改正前フォルダはRAGのインデックス対象から外す 2.法定保存義務や引継ぎのために改正前ひな形を残す場合は、 ファイル単位で読み取り専用にしたうえで、 ステータスを deprecated / superseded にしておく。「経緯のために残す」 と 「現役で参照する」 を運用上分ける 3.改正後のひな形には、 改正日・根拠条文・施行日を文書の冒頭に明記し、 メタデータと文書内テキストの両方に同じ情報を置いておく 4.改正法が公布済みで施行待ちの状態にあるときは、 「改正前」 「改正後」 「施行待ち」 の3つを別ステータスで管理する

法改正への対応は頻度こそ高くありませんが、 一度の混入で影響範囲が広く出やすい場面です。改正のたびにフォルダ・メタデータ・インデックス対象範囲を見直す流れを、 所内の手順として書いておく事務所もあります。

引用元表示を一緒に使う

事故防止で効きやすいのは、 「引用元 (出典) 表示」 をセットで運用する形だと思います。回答に 「どの文書のどの箇所を根拠にしたか」 が併記されていれば、 利用された方は最新版かどうかを1ステップで確認できます。Microsoft LearnのAzure OpenAI On Your Dataの解説では、 検索インデックスのフィールドマッピングでTitle・File nameを引用元表示に使う設計が示されています。Microsoft 365 CopilotのEnterprise data protectionの解説では、Copilotが利用者のidentity / permissions / sensitivity labels / retention policiesを継承する設計が記述されています。製品仕様を活かすには、 文書側に 「タイトル」 「ファイル名」 「sensitivity label」 が整っていることが前提になります。

引用元表示の運用設計で押さえておきたい場面がいくつかあります。

  • 製品選定の段階で 「全回答に引用元を表示」 「引用元なしの回答は出さない」 設定にできるか
  • 引用元から原文 (またはプレビュー) に1クリックで飛べる設計を選ぶか
  • 引用元に current / effective_until 2026-03-31 のようなメタデータを併記できるか
  • 引用元のファイルが回答生成後に更新された場合、 警告表示がどう出るかを製品ごとに確認しておくか

機能が付いているだけでは混入を防ぎきれない場面もあります。「引用元を確認する手順」 「ステータスを確認する手順」 が業務の流れに置かれていて、 はじめて引用元表示が活きてくる、 という関係です。

棚卸しを業務カレンダーに置く

メタデータと引用元表示が整っていても、 時間が経つにつれて古い文書が再び混ざってきます。RAGのインデックスは 「文書側を更新すれば自動反映」 と 「明示的な再インデックスが必要」 に分かれます。Microsoft LearnのAzure OpenAI On Your Dataの解説では、Azure Blob Storageをデータソースにする場合、indexer scheduleで自動更新 (hourly / daily等) を設定でき、cadenceの半分の頻度でindexerが追加・変更分を再処理・再インデックスする挙動が示されています。

逆に 「削除」 がインデックスにどう反映されるかは製品仕様によって変わります。廃止した文書をストレージから消せば自動で検索結果から消える、 と決めつけずに、 製品ごとに挙動を確認しておくほうが安全側で運用できます。

棚卸しの場面は、 業務のリズムに合わせて4つの階層に分けている事務所もあります。

  • 月次: 直近1か月の更新文書のメタデータ付与状況を15 〜 30分で確認する
  • 四半期: RAG利用ログから引用回数の少ない文書を 「現役か廃止か」 で見直す
  • 半期: 法改正の有無と関連ひな形の対応状況を一覧化する
  • 年次: 全文書のメタデータ整合性をひととおり確認する

「いつかやる」 でなく 「カレンダーに乗っている」 状態にしておくのが要点で、 決算期・繁忙期と重ならない時期に定例化すると続きやすいようです。

セキュリティ・コンプライアンスでつながる場面

旧版を参照してしまう場面は、 利便性の話だけにとどまりません。セキュリティやコンプライアンスにもつながる場面が出てきます。

個人情報保護法の整理では、 利用する必要がなくなった個人データは遅滞なく消去するよう努めるとされています。廃止したひな形に顧問先の個人データが残ったままで、RAG経由で別案件の回答に混ざる流れがあると、 消去努力義務との関係で論点になりやすい場面です。守秘義務 (= 弁護士法・税理士法・社労士法 等) の観点でも、A顧問先向けに調整したひな形が別の顧問先への回答に混ざる流れは、 義務との関係で気を付けたい場面と言えそうです。「特定顧問先専用テンプレート」 を restricted_template として汎用フォルダから物理的に分けておく設計は、 技術設計でありつつ、 同時にコンプライアンス設計でもあります。

個人情報保護委員会は2023年6月2日付で 「生成AIサービスの利用に関する注意喚起等について」 を公表していて、 利用する側が 「入力する情報の範囲」 と 「サービス提供者側でのデータ取扱い」 を理解したうえで利用することを促す内容になっています。RAGでは 「入力する情報」 が 「インデックスに乗せた文書全体」 に広がるので、 廃止した文書をインデックスに残し続ける運用は、 入力情報の範囲という観点で気を付けたい場面に当たります。

旧版引用の混入が起きた場合、 「どの回答で」 「どの文書を」 「どのユーザーに」 引用したかを後から追える監査ログがあると、 事後の対応が現実的に進みます。Microsoft 365 CopilotのEnterprise data protectionの解説では、Copilotが監査 (audit) を支援する設計が示されています。製品選定のときに、 引用元のファイルID・バージョンIDまで監査ログに残るかを確認しておくと、 後から振り返りやすくなります。

業務の流れに置きやすい確認観点

冒頭の 「最新版_v2_確定_最終」 が並ぶ共有ドライブの例のように、 ひな形フォルダの揺らぎはAIが入る前から事務所の中にあるものです。AIが入ったことで、 その揺らぎが回答という形で表に出てくるようになった、 と捉え直すと、 整える順序が決めやすくなります。

業務の流れの中に置きやすい観点を並べておきます。

  • メタデータ3項目 (ステータス・有効期限・版) を新規文書に必ず付ける流れにする
  • 法改正の境界はフォルダで物理的に分け、 改正前のフォルダはインデックス対象から外す
  • 引用元表示は仕様で保証された製品を選び、 ステータス併記と一緒に使う
  • 棚卸しのサイクルを月・四半期・半期・年に分け、 繁忙期と重ならないカレンダーに固定する

RAGの使い勝手は、 モデルや学習データよりも、 インデックスに乗せた文書群の整い具合で決まる場面が多いようです。自所のひな形フォルダの棚卸し状況や、 改正前後の管理・引用元表示の設計について論点を一緒に並べてみたいテーマがあれば、 状況をお聞かせください。

参考

Author · 著者

士業AI

Tags · タグ
ブログ一覧
Related · 関連記事

この記事を読んだ方は、次の記事も読まれています