社内AIエージェントやRAG型QAは、公開した瞬間から劣化が始まります。問題は「精度が出ない」ことより「古い情報を自信満々に返す」こと。鮮度を運用でどう担保するか、情報更新の設計から考えます。
社内文書を集めてRAG（検索拡張生成）で社内QAを立ち上げると、最初の数週間は驚くほどよく答えます。就業規則、経費精算のルール、製品仕様、過去の議事録——散らばっていた知識がひとつの窓口から引ける体験は強力です。ところが半年ほど経つと、様子が変わってきます。「その手当は昨年の改定で廃止されました」「その手順書はもう使っていません」——現場からそういう声が上がり始めます。精度が落ちたわけではありません。元になった文書が古くなったのに、AIはそれを疑わず、自信満々に引用し続けているのです。
これは技術の失敗というより運用設計の欠落です。多くの組織はRAGを「一度作れば動き続けるもの」と捉えがちですが、実際には公開した瞬間から情報の鮮度は劣化し始めます。規程は改定され、組織は再編され、担当者は異動し、製品はモデルチェンジする。ナレッジ基盤の中身は現実の変化に自動では追随しません。社内文書のRAG活用を始めた企業がつまずくのは、多くの場合ここです。
明らかに間違った回答なら、ユーザーは気づいて無視します。厄介なのは「昔は正しかった情報」です。書式も整い、根拠となる社内文書も存在するため、回答は極めてもっともらしく見えます。読み手が新人や他部署の人だと、その情報が失効していることに気づけません。結果として、古い経費ルールで申請してしまう、廃止された安全手順を参照してしまう、といった実害につながりうると考えられます。鮮度の劣化は静かに進み、事故として顕在化するまで見えにくいのが特徴です。
鮮度の問題を漠然と捉えると打ち手が定まりません。何が、どう古くなるのかを分解すると、対策の当てどころが見えてきます。劣化には少なくとも三つの層があると考えられます。
最も分かりやすい層です。規程改定、価格改定、組織変更、手順の変更によって、文書の中身が現実とズレていきます。厄介なのは、改定版が追加されても旧版が削除されずに残るケース。RAGは新旧両方を検索対象として拾い、どちらを優先すべきか判断できないまま、古い方を引用してしまうことがあります。
文書を作った人が異動・退職し、「この手順書、今も正しいのか誰も分からない」という状態です。内容が古いかどうか以前に、正誤を判断できる人がいない。ナレッジのメンテナンスは結局、その領域を分かっている人にしかできないため、所有者不在の文書は鮮度を保ちようがなくなります。これは技能伝承への活用とも地続きの、暗黙知の空洞化の問題でもあります。
個々の文書は正しくても、それらが前提としていた業務プロセスそのものが変わることがあります。使うシステムが刷新された、承認フローが変わった、といった構造の変化です。この場合、文書単位の更新では追いつかず、業務プロセスの文書化とコード化の観点で、プロセス全体を捉え直す必要が出てくると考えます。
鮮度管理を「定期的に全部見直す」という総ざらいに頼ると、量が多いほど破綻します。現実的なのは、鮮度が疑わしくなるイベント（トリガー）を定義し、そこに引っかかったものだけを棚卸しする方式だと考えられます。全数チェックではなく、変化のあったところに人手を集中させる考え方です。
たとえば「最終更新日から一定期間を超えた文書」「規程改定の通達が出た領域」「組織変更の対象部署が所有する文書」「参照回数が急増しているのに長期間更新されていない文書」——こうした条件を鮮度レビューのトリガーにできます。特に最後の「よく引かれるのに古い」文書は、影響が大きいのに見落とされやすく、優先的に拾う価値があると考えます。
トリガーを機能させる前提は、各文書に「最終更新日」「所有者」「有効期限（あれば）」「版数」といったメタデータが付いていることです。ここが空欄だらけだと、鮮度の自動判定はできません。逆に言えば、いきなり高度なRAGを組む前に、メタデータの整備状況を点検することが鮮度運用の土台になります。社内ナレッジ基盤やデータ集約基盤を設計する段階で、この項目を必須にしておくと後が楽になると考えられます。
更新の仕組みを考えるとき、多くの人は「どう最新に保つか」に注目しますが、それと同じくらい「どう古いものを退場させるか」の設計が効きます。RAGの弱点は、消し忘れた旧版を平然と引用してしまう点にあるからです。
旧版を物理的に削除すると、監査や経緯確認で困ることがあります。一方で検索対象に残すと誤引用の元になる。折衷案として、文書に「失効」の状態を持たせ、検索インデックスからは除外するが原本は保管する設計が有効だと考えられます。改定版を登録したら旧版を自動で失効扱いにする、といった運用ルールとセットにすると、旧版の取り残しを減らせます。
技術的に完璧な鮮度管理は難しいという前提に立つなら、AIの回答に「この情報の最終更新日」「出典文書名」を必ず添える設計が現実的な保険になります。利用者が自分で鮮度を判断できる材料を渡すわけです。古い可能性を完全には排除できなくても、「2年前の文書に基づく回答です」と示されていれば、受け手は裏取りの必要性を判断できます。透明性は、AIO時代における信頼設計の基本でもあると考えます。
すべての文書を同じ熱量で鮮度管理するのは非現実的です。誤りが実害に直結する領域（安全・法令・経理・品質基準）と、多少古くても影響が限定的な領域（過去の雑多な議事録など）を分け、前者に運用リソースを厚く配分する。鮮度管理は総花的にやると続かないため、影響度に応じたメリハリが継続の鍵になると考えられます。
鮮度運用の最大の難所は技術ではなく体制です。トリガーで「この文書、古いかも」と検知しても、それを確認して直す人がいなければ何も進みません。ナレッジ基盤は作った瞬間がピークで、あとは放置されて劣化していく——この典型パターンを避けるには、更新を回す役割を明示的に置く必要があると考えます。
運用モデルには大きく二つあります。ひとつは情シスやナレッジ管理チームが一元的に鮮度を管理する中央集権型。統制は効きますが、専門領域の正誤判断まで中央が担うのは無理があり、ボトルネックになりがちです。もうひとつは各文書の所有部署が自部署分の鮮度に責任を持つ分散所有型。現実的にはこちらが機能しやすいものの、放置を防ぐ仕掛け（トリガー通知やダッシュボードでの可視化）を中央が用意する、ハイブリッドが落としどころになると考えられます。
人手の負担を下げる方向として、社内AIエージェント基盤側に鮮度チェックの下ごしらえをさせる考え方があります。たとえば「本文中の日付や制度名から陳腐化の疑いを検出して所有者に確認を促す」「新旧文書の差分を要約して更新箇所の候補を示す」といった補助です。最終判断は人が担う前提ですが、確認対象の絞り込みと下書き生成を任せられれば、運用の腰は軽くなると考えられます。こうした仕組み自体の維持については、内製AIツールの保守の観点も併せて設計しておくとよいでしょう。
実際に運用を回そうとすると、想定していなかった壁に当たります。よく見られるものを挙げます。
鮮度設計を進める順序として、いきなり高機能なRAGを組むのではなく、自社ナレッジの現状把握から入ることをおすすめします。順を追うと次のようになると考えます。
まず、社内に散らばる文書群の「量・所在・所有者・最終更新日」を洗い出します。この時点で「所有者不明」「数年間未更新」の文書がどれだけあるかが見え、鮮度リスクの全体像がつかめます。地味ですが、ここを飛ばすと後の設計がすべて仮説の上に積み上がってしまいます。
洗い出した文書を、誤りが実害に直結する領域とそうでない領域に分けます。安全・法令・経理・品質など影響の大きい領域から鮮度管理の対象に据え、スモールに始めるのが現実的です。全部を一度に対象にすると、運用が立ち上がる前に息切れします。
優先領域に対して、更新トリガー（更新日超過・改定通達・参照急増など）と、確認・更新を担う役割を決めます。ここまで決めてから、社内AIエージェント基盤による下ごしらえや失効管理の自動化を段階的に組み込んでいくと、無理なく回り始めると考えられます。
私たちは元キーエンス画像処理事業部で「現物・現場・現実」を起点に検査精度を積み上げてきた経験を、ナレッジ基盤の設計にも持ち込んでいます。理想的な情報アーキテクチャを描く前に、まず現物のドキュメントがどんな状態かを見る。鮮度運用は、その客観的な棚卸しから始めるのが結局いちばん早い、というのが現時点での私たちの考えです。
RAGは検索対象の文書をそのまま根拠に回答するため、元文書が古くても、あるいは旧版が削除されずに残っていても、それを疑わずに引用してしまうことがあります。精度の問題ではなく、情報の鮮度と失効管理の設計不足が原因であることが多いと考えられます。追加と失効をセットにした運用ルールが有効だと考えます。
一律の頻度で全数を見直すより、更新トリガー（最終更新日の超過、規程改定、参照急増など）に該当した文書を優先的に棚卸しする方式が現実的だと考えられます。安全・法令・経理など誤りが実害に直結する領域は手厚く、影響が限定的な領域は緩やかに、と影響度でメリハリをつけるとよいと考えます。
専門領域の正誤判断は中央だけでは難しいため、各文書の所有部署が自部署分の鮮度に責任を持つ分散所有を基本にしつつ、放置を防ぐトリガー通知や可視化を中央が用意するハイブリッドが機能しやすいと考えられます。どちらか一方に寄せると、ボトルネックか放置のいずれかに陥りがちです。
監査や経緯確認のために原本は残しつつ、検索インデックスからは除外する「失効」の状態を持たせる設計が現実的だと考えられます。物理削除は後で困ることがあり、逆に検索対象へ残すと誤引用の元になります。改定版の登録時に旧版を自動で失効扱いにするなど、運用ルールと組み合わせると取り残しを減らせます。
陳腐化の疑いがある文書の検出、新旧の差分要約、所有者への確認促しといった下ごしらえは補助として任せうると考えられます。ただし最終的な正誤判断は人が担う前提が安全です。効果は自社のデータ状況で変わるため、現物での検証を経て段階的に組み込むことをおすすめします。
RAGや社内QAの鮮度問題は、理想の設計図より先に「今の文書がどんな状態か」を見ることから始まります。元キーエンス画像処理事業部の現場知見を持つチームが、ナレッジの棚卸しと更新運用の設計をご一緒します。まずは現物を見せていただくところから。
ナレッジ基盤の鮮度運用について相談する