「社内の規程やマニュアルをAIに聞けるようにしたい」というご相談は、ここ数年で最も多いテーマのひとつです。実際に作ってみると、デモの段階では驚くほどうまく答えます。ところが運用を半年ほど続けたあたりで、こんな声が出てきます。「去年廃止した手当の金額を答えてくる」「旧フォーマットの申請書を案内してくる」。
このとき多くの現場では「AIの精度が悪い」「もっと良いモデルに変えよう」という議論になりがちです。しかし原因の大半は、モデルでも検索アルゴリズムでもなく、文書が更新されたときにAI側のデータをどう追従させるか、という設計が最初から入っていなかったことにあります。この記事では、その仕組みと、受注開発の要件定義で押さえるべき観点を整理します。
なぜ古い情報を自信満々に答えるのか
社内文書検索AIの多くはRAG（Retrieval-Augmented Generation／検索拡張生成）という構成を取ります。これは、質問が来たときに社内文書の中から関連しそうな部分を検索し、その本文を生成AIに渡して回答を書かせる仕組みです。AIが知識を記憶しているのではなく、毎回「参考資料」を渡して読ませていると考えると分かりやすいでしょう。
このとき検索対象になるのは、元のファイルそのものではありません。事前に文書を数百文字程度の塊（チャンク）に分割し、意味の近さを数値化したベクトルに変換して、専用のデータベースに格納しておきます。つまりAIが読んでいるのは「ある時点で取り込まれた文書のコピー」です。
ここが問題の核心です。元のファイルサーバー上で規程が改訂されても、取り込み済みのコピーを更新する処理が走らなければ、AIはいつまでも旧版を正解として参照し続けます。しかも生成AIは、渡された資料が古いかどうかを判断できません。渡された内容を前提に、自然で説得力のある文章を書いてしまう。これが「自信満々に古い情報を答える」正体です。
更新の遅れが生まれる4つの地点
「古い情報を答える」と一口に言っても、詰まっている場所は複数あります。設計時には、どこで遅れが生じうるかを分けて考えると漏れがなくなります。
| 遅れが生じる地点 | 具体的に起きること | 対策の方向性 |
|---|---|---|
| 原本の更新 | 改訂版が別フォルダに置かれ、旧版も残ったまま | 原本の置き場所を一本化し、正本の定義を決める |
| 取り込み（インデックス） | 初回に一括取り込みしたきり、再取り込みの仕組みがない | 差分取り込みの自動化、更新検知の設計 |
| 削除の反映 | 原本を削除しても、ベクトルデータベース側に残り続ける | 削除同期の実装、定期的な突き合わせ |
| 回答時の判断 | 新旧両方がヒットし、どちらを使うかAI任せ | 有効期限や版数をメタデータで持ち、絞り込みに使う |
経験上、見落とされやすいのは3番目の削除同期です。追加と更新は意識されても、削除の経路が設計から抜け落ちているケースは珍しくありません。原本が消えた文書がAIの中だけ生き残る状態は、廃止された規程を案内してしまうという最も危険な形で表面化します。
設計に組み込むべき「鮮度」の仕組み
更新への追従は、後付けの運用ルールではなく、最初から設計要件に入れておくべきものです。実装の選択肢としては次のようなものがあります。
1. メタデータを必ず持たせる
チャンクを格納する際、本文だけでなくメタデータ（付帯情報）を一緒に保存します。最低限、次の項目は検討対象になります。
- 原本のファイルパスまたは文書管理番号
- 版数（第3版、Rev.2 など）
- 制定日・最終改訂日
- 有効期限または次回見直し予定日
- 所管部署・文書責任者
- 公開範囲（閲覧できる部署や役職）
これらを持っておくと、検索時に「有効期限を過ぎた文書は除外する」「同じ文書番号なら最新版だけを使う」といった絞り込みが可能になります。メタデータなしで構築してしまうと、後から入れ直すには全文書の再取り込みが必要になり、手戻りが大きくなります。
2. 更新トリガを決める
どのタイミングで取り込み直すかには、いくつかの方式があります。
| 方式 | 内容 | 向いているケース |
|---|---|---|
| 定期バッチ | 夜間などに更新分を検知して取り込む | 文書量が多く、即時性より確実性を重視する場合 |
| イベント駆動 | 文書管理システムの承認完了などを契機に取り込む | ワークフローが既に電子化されている場合 |
| 手動実行 | 担当者が管理画面から取り込みを指示する | 改訂頻度が低く、対象文書が限られる場合 |
中小企業の場合、最初から全自動を目指すよりも、定期バッチと手動実行を併用し、改訂が多い文書群だけイベント駆動に寄せるという段階的な設計が現実的です。
3. 回答に出典と日付を必ず付ける
技術的な完璧さよりも、実務上の効果が大きいのがこれです。回答の末尾に「出典：就業規則 第3版／最終改訂 ○年○月」のように表示させれば、利用者が自分で鮮度を判断できます。仕組み上どうしても取りこぼしは残りますから、人が最終確認できる材料を回答に添えるという発想が安全側に働きます。
実装で詰まりやすい箇所
実際に手を動かすと、次のような論点にぶつかります。
- 更新日時が当てにならない：ファイルサーバー上の更新日時は、誰かが開いて保存し直しただけで変わることがあります。内容が変わったかどうかは、本文のハッシュ値（内容から計算される固定長の値）を比較して判定する方が確実です。
- 同じ内容が別ファイルで複数存在する：「規程_最新.pdf」「規程_20XX改訂版.pdf」が併存していると、どちらも取り込まれて競合します。これはシステム側だけでは解けません。原本の管理ルールを同時に整える必要があります。
- 部分更新でも全体の再処理が必要になる：1条だけ改訂された場合でも、チャンク分割の境界がずれると前後のチャンクも作り直しになります。文書単位で削除してから入れ直す実装にしておくと、整合性のトラブルを避けやすくなります。
- 埋め込みモデルを変更すると過去データが使えなくなる：ベクトル化に使うモデルを別のものに切り替えると、既存のベクトルとは比較できません。全件再処理が必要になるため、処理時間と費用をあらかじめ見積もっておきます。
- 権限変更が反映されない：人事異動で閲覧権限が変わったのに、AI側の公開範囲が古いままだと、本来見えないはずの文書が回答に混ざります。権限は取り込み時に固定せず、検索時に最新の権限情報で絞り込む設計が望ましい領域です。
たとえば次のような場面です。経理部が稟議の金額基準を改訂し、新しいPDFを共有フォルダに追加した。しかし旧版を削除せず別名で残したため、AIは新旧両方を参照し、質問の仕方によって異なる金額を答えるようになった——こうした想定は、設計段階のレビューで洗い出しておきたいパターンです。
運用の体制まで含めて要件にする
更新の仕組みは、技術だけでは閉じません。次の3点は、発注側で決めておくと開発がスムーズに進みます。
- 正本の置き場所を一本化する：AIが参照する原本の場所を明確に定義し、そこ以外のコピーは参照対象にしない。
- 文書ごとに責任者を決める：改訂時にAIへの反映まで含めて確認する担当を、文書単位で紐づけておく。
- 定期的な棚卸しを回す：四半期または半年に一度、有効期限切れの文書を一覧化して確認する運用を組み込む。
なお、文書の版管理や保管について社内ルールを整理する際は、品質マネジメントシステムの規格であるISO 9001の文書管理の考え方が参考になります。また、取り扱う文書に国税関係書類が含まれる場合は電子帳簿保存法、個人情報が含まれる場合は個人情報保護法の要請を確認する必要があります。生成AIの業務利用全般については、総務省・経済産業省が公表しているAI事業者ガイドラインも、社内方針を検討する際の出発点になります。いずれも要件は文書の種類や業種によって異なるため、適用範囲は個別にご確認ください。
まとめ
社内文書検索AIが古い情報を答える問題は、精度の問題に見えて、実態はデータのライフサイクル設計の問題です。整理すると、押さえるべきポイントは次のとおりです。
- RAGが参照しているのは「取り込み時点の文書のコピー」である。原本の更新は自動では伝わらない
- 追加・更新だけでなく、削除の同期を設計に入れる
- 版数・改訂日・有効期限・公開範囲といったメタデータは、構築時から持たせる
- 更新トリガは定期バッチ・イベント駆動・手動を組み合わせ、文書の性質に応じて使い分ける
- 回答に出典と日付を表示し、人が鮮度を判断できる余地を残す
- 正本の一本化と文書責任者の明確化という、運用側の整備を並行して進める
導入前の要件定義で「更新されたらどうなるか」を一度通しで確認しておくだけでも、運用開始後のトラブルはかなり減らせます。既に稼働しているシステムで心当たりがある場合も、メタデータの追加と削除同期の実装から段階的に手を入れることは可能です。現状の構成を拝見したうえでの改善提案も承っていますので、お気軽にご相談ください。