データ鮮度管理とは｜AI活用で「いつの情報か」を設計する

社内の情報をAIに聞くと、古い情報と新しい情報が区別なく混ざって返ってくる。心当たりのある方もいるかと思います。

「最近の状況を教えてください」と聞いているのに、返ってくるのは半年前や1年前の資料に基づいた回答です。
担当者は「これはいつの話なのか」「本当に今の状態なのか」と一つひとつ疑わなければならず、結局は自分で元の資料を探し直すことになります。

この状態の正体は、AIの性能ではなくデータの鮮度です。
データ活用の文脈の多くは「品質」を中心に語られていますが、AIがデータを直接参照して回答を組み立てるようになると、その情報がいつのものかという鮮度が、品質と同じ重さで必要になります。

本記事では、データの鮮度の定義と注目される背景を確認し、AI活用への影響を3つの観点から整理したうえで、データに鮮度ラベルを紐づける設計と、その運用の進め方までを扱います。

データ鮮度管理とは、データがいつの情報でいつ更新されたかを管理すること

データ鮮度管理とは、データ基盤に置かれた個々のデータについて、それがいつの情報で、いつ更新されたかを把握できる状態を保つ取り組みです。

鮮度は「用途に対して十分に新しいか」で決まる

鮮度に絶対的な基準はありません。判断の基準になるのは、そのデータを何に使うかです。

情報処理推進機構（IPA）内に設置されたAIセーフティ・インスティテュート（AISI）が公開している「データ品質マネジメントガイドブック」は、この特性を最新性と呼び、「データが想定用途に対して十分に新しいかを示す。古いデータは、時代遅れのインサイトや行動につながる可能性がある」と定義しています。

評価の観点として、データが最新の文脈と整合していること、時間的網羅性が適切であること、定期的更新が維持されていることを挙げています（出典: データ品質マネジメントガイドブック 第1.02版）。

なお、公的な定義では、データが十分に新しいかを示す「最新性」と、データが利用に間に合うタイミングで届くかを示す「適時性」を分けて整理することもあります。
本記事では、この2つをあわせて「鮮度」として扱います。

用途によって求める水準が変わる点は、日本の公的文書でも明記されています。
内閣府地方創生推進事務局のガイドブックは「同じデータでも、データを利用する目的が異なれば、最新性や精度など、必要となるデータの特性も異なるため、データの品質評価は目的ごとに変化します」と述べています（出典: データ連携基盤を通して提供されるデータの品質管理ガイドブック）。

月次の売上レポートは前月末時点の値で足りますが、在庫の引き当ては当日の値でなければ判断できません。求める鮮度は、同じ会社の中でもデータごとに違います。

「古いデータ」とは、更新されて現在の状態と違いがあるデータ

本記事で「古いデータ」と呼ぶのは、その後の変更によって現在の状態を表さなくなったデータを指します。逆に「新しいデータ」は、現在の状態を表しているデータを指します。

例えば、2020年に作成した就業規則が、その後改定されていなければ、いまも正しい情報です。
一方で、2024年に作成した価格表が2025年に改定されていれば、2024年版は古いデータになります。作成日の古さではなく、その後に更新されたかどうかが判断基準です。

したがって鮮度を管理する目的は、そのデータがいつの状態を表しているかを判別できるようにすることです。作成日で機械的に線を引くと、いまも有効な情報まで対象から外れてしまいます。

判別には日付が1つでは足りません。
「いつ更新されたか」と「どの頻度で更新されるか」を合わせて持っていれば、最終更新から想定の間隔を過ぎていないデータは現行のものとして扱えます。

AIの利用で問題になるのは、改定前の版と改定後の版が同じ場所に並んでいて、どちらが正しい情報か判別できない状態です。

データ品質の一項目から、AI活用の設計対象へ

データの鮮度が重要視されるようになったのは、データを読む側に変化があったからです。

人が資料を開くときは、ファイル名や表紙の日付が自然に目に入ります。
「これは去年の資料だ」と気づけば、そこで判断を保留し、新しい版を探しにいきます。
この確認は、意識しないうちに毎回行われています。

AIに社内のデータを参照させる構成では、この確認が働きません。
日付がデータに付いていなければ、AIは新しい資料と古い資料を並べて、どちらも同じ確度の情報として回答に組み込みます。

品質の一項目として端に置かれてきた鮮度は、AI活用を前提にしたデータ基盤では、独立して設計する対象になります。

AI活用にデータの鮮度はどう影響するか

鮮度が落ちたときに何が起きるかは、回答精度、活用率、判断の即時性の3つに分かれて現れます。

回答精度｜古い文書が1件混ざるだけで精度が落ちる

古い情報が参照先に残っていると、最新の情報が正しく見つかっていても、AIの回答の精度は落ちます。

・検索の仕組みが文書の古さを見ていない

RAG（AIに社内資料を参照させて回答に反映する仕組み）で使われる検索は、質問と文書の意味がどれだけ近いかを見ています。いつの文書かは、明示的に指定しない限り判断材料に入りません。

古い情報がRAGに与える影響を測った研究では、日付で絞り込まずに検索した場合、上位5件に古い文書が入る確率は約88%、新しい文書が入る確率は約87%でした。
古い資料が、新しい資料とほぼ同じ確率でAIの手元に届いています。（出典: HoH benchmark（RAGに古い情報が混ざる影響を評価した研究））

・新しい資料があっても、古い資料が混ざると回答の質が落ちる

同じ研究は、AIに渡す情報を2件に固定して比べています。
片方は、正しい情報1件に「質問と似ているが正解を含まない情報」を足したもの。
もう片方は、正しい情報1件に古い情報を足したものです。

この研究の評価は、正しく答えられたら加点、明確に誤った答えを返したら減点、答えを避けた場合は0点として集計します。

結果、古い情報が混ざったほうは、この点数が2割以上低くなりました。

点数の内訳を見ると、何が起きているかが分かります。
正しく答えられる割合が下がるだけでなく、明確に誤った答えを返す割合そのものが増えています。

・AIが渡された資料を疑わない

6つの主要なAIモデルを対象にした別の研究では、モデルが正しい知識をあらかじめ持っている場合でも、誤った検索結果を渡されると3割から6割強の頻度で自分の知識を捨て、渡された内容を採用していました（出典: ClashEval（AIの内部知識と検索結果の衝突を測った研究））。

この研究は、モデルが自分の答えに自信を持てないときほど、渡された内容に従いやすくなることも示しています。
自社固有の規程や料率のように、AIが事前知識を持たない領域では、渡した資料の内容がそのまま回答になり得ます。

参照できる情報がない場合、AIは不確かさを示して控えめに答えますが、古い情報が渡されると、内容を疑わないまま自信のある口調で断言します。
先の研究はこれを、古い情報は雑音を足すのではなくAIを積極的に誤らせる、と表現しています。

古い資料をそのまま残しておくことは、AIから見れば「資料が何もない」より悪い状態なのです。

陳腐化による活用率の低下｜検証の手間が増えるとAIは使われなくなる

古い情報に基づく回答が返ってきても、画面上では判別できません。
AIは古い情報も新しい情報も同じ調子で提示するため、利用者は回答を受け取るたびに元の資料を開き、いつ時点の情報かを確かめることになります。

この確認が毎回必要になると、AIに聞いてから検証する手間と、最初から自分で探す手間が比較されるようになります。
検証の手間が自分で探す手間を上回った時点で、AIに聞くという選択は取られなくなります。

情報の正確性への不安は、AIそのものの誤答から生まれるだけではありません。
参照するデータが今の状態を表していない場合も、利用者の目には同じ「不正確な回答」として映ります。

リアルタイムな判断ができない｜夜間の定期更新では間に合わない業務がある

データが正しくても、届くのが遅ければ判断には使えません。

在庫の引き当て、設備の稼働状況の確認のように、昨夜時点の値では判断できない業務があります。夜間にまとめて更新する仕組みでは、日中に発生した変化が翌朝まで反映されません。

AIエージェント（目的を渡すと自分で手順を組んで実行するAI）に業務判断の一部を任せる場面では、この遅れがそのまま判断の遅れになります。

データ基盤側がこの要求に追いついていない状況は、調査にも現れています。
データストリーミング製品を提供するConfluentが実施した調査では、AI活用を広げる取り組みが停滞している要因として、リアルタイムのデータ基盤の不足を挙げた割合が72%でした。

更新の間隔をどこまで詰めるかは、業務ごとに違います。
業務ごとに違う鮮度を基盤の側で扱うには、どのデータがいつ時点のものかを、データごとに判別できる状態が必要になります。

AI活用のためのデータに鮮度ラベルを定義する

鮮度をデータ基盤で扱えるようにする方法は、データそのものに、鮮度を示すラベルを紐づけておくことです。本記事ではこれを鮮度ラベルと呼びます。

鮮度ラベルとして持たせる4つの情報

鮮度ラベルとして持たせる情報は、次の4つに分かれます。

• いつの情報か：そのデータが対象としている期間

• いつ公開されたか：そのデータが最初に出された日

• いつ更新されたか：そのデータが最後に変更された日

• どの頻度で更新されるか：今後どの間隔で更新される予定か

この4つは、データカタログの語彙を定めたW3CのDCAT（Data Catalog Vocabulary）でも、それぞれ独立したプロパティとして定義されています。（出典: Data Catalog Vocabulary (DCAT) Version 3）

4つを別々に持たせるのは、それぞれが違う問いに答えるからです。
2024年に作られた資料が2026年に体裁だけ修正された場合、「いつ更新されたか」は2026年ですが、「いつの情報か」は2024年のままです。
この2つを1つの日付にまとめてしまうと、AIから見て古い資料が新しい資料に見えます。

更新頻度は、人が読む形と機械が読む形の両方で持たせておくと扱いやすくなります。
W3Cは、推奨事項として「データを最新の状態で利用できるようにし、更新頻度を明示すること」を挙げており、その実装方針の一例として、想定される公開頻度を人が読める文章で記載し、あわせて機械が読めるメタデータとしても頻度を示すことを挙げています（出典: Data on the Web Best Practices）。

ラベルを付けたあとに詰まりやすいのが、検索の設定側です。
日付を持っているデータでも、AIが参照する検索の設定に日付を受け取る項目を定義していなければ、日付は使われません。

AIの回答に「いつの情報か」が出てこない原因は、日付が取れないことではなく、日付を受け取る項目を作っていないことにもあります。

データレイクハウスのSilver層で鮮度を扱う

当社では、運用しているデータレイクハウスの中で鮮度ラベルを持たせています。

データレイクハウスとは、Excelのように行や列で整理されたデータと、文書・画像のようにそう整理されていないデータを、1か所に集めて扱う基盤です。

当社はこれをBronze層・Silver層・Gold層の3層で構成しています。生データをBronze層に置き、クレンジングと統合を済ませたデータをSilver層に、分析にすぐ使える業務レベルの集計データをGold層に置くことで、層を経るごとにデータの構造と品質を段階的に高めていく設計パターンです。

関連記事：メダリオンアーキテクチャとは

Bronze層では、いつ時点のデータかが同期の仕組みで決まります。

Bronze層はGoogleドライブ上に生データを集約する層です。Notion、Slack、顧客管理システムは各ツール側を正の情報源とし、Bronze層のコピーは同期した時点のスナップショットとして扱っています。

同期は日次で回しているため、Bronze層にあるコピーは最大で1日前の状態です。
ツール側で編集された内容は、翌日の同期で反映されます。

Silver層では、ファイル単位のラベルに作成日を持たせています。

Silver層は、Bronze層のファイル1つに対して、ラベルファイルを1つ作る層です。
ファイルごとのラベルには、会社・案件・種別・作成日・関係者・要約などを記録しています。
作成日がラベル側に入っているため、AIがラベル経由でファイルを探す段階で、それがいつの資料かが分かります。

Gold層では、時系列に並べることで最後の状態が分かるようにしています。

Gold層には、顧客企業ごとのタイムラインを置いています。
初回接点・提案・契約・更新・課題対応を時系列で一元管理しているため、同じ顧客について複数の資料がある場合に、どれが最後の状態を表しているかをタイムラインの側で判断できます。
Gold層の各項目は、Silver層・Bronze層のどこに由来するかのリンクを保持しています。

呼び出しは、AIの公式コネクタでGold層のフォルダを参照先に設定し、社内で共有しているスラッシュコマンドから行っています。
そして呼びたした際の回答の中にも、いつのデータを参照したかを記載するようにしています。

データ鮮度管理の進め方

データオーナーが更新頻度を決める

鮮度の水準は用途で決まるため、データ基盤を構築する側ではなく、そのデータを業務で使う側が決めることになります。

元データの品質に説明責任を負うのはデータオーナーであり、改善目標の設定はデータスチュワードと分担すべきものとされています。

関連記事：データガバナンスでAI活用を止めないために｜データオーナーとデータスチュワード

データオーナーは、そのデータの内容に責任を持つ業務側の担当者を指します。
データスチュワードは、データの整備・運用を実務として担う担当者です。

決める内容は、データごとに「誰が内容に責任を持つか」と「どの間隔で更新するか」の2つです。新しい役職を立てず、既存の業務担当者に紐づける形でも成立します。

公開を業務の成果物として位置づけ、その作業に責任を持つ個人を割り当てることが、データが古くなることを防ぐのに役立ちます。
担当が決まっていないデータは、誰も更新しないまま残っていきます。

重要なデータから始める

鮮度管理の対象は、重要なデータに絞ります。
最初に選ぶ対象は、AIへの質問が多く、かつ古い回答が業務判断に影響するデータです。

【例】

• 価格表：古い単価のまま見積もりが作られる

• 社内規程：改定前の版が判断の根拠として引かれる

対象を1つか2つに絞って運用を回し、ラベルの項目と更新の間隔が定まってから範囲を広げます。専任の体制を置かない規模でも、この順序であれば着手できます。

AIの回答に「いつ時点の情報か」を明記する

鮮度ラベルを持たせたら、AIの回答にもその情報を出します。

データがいつ収集されたものなのかを利用者に伝えることで、そのデータが対象とする期間が伝わり、利用者が自分が欲しい情報に一致しているかを判断できるようになります。

回答の中に「2026年3月時点の価格表によると」といつの情報かが記載されていると、利用者は元の資料を開かずに判断できます。
冒頭で挙げた「これはいつの話なのか」という確認作業が、AIの回答の中で完結します。

まとめ

データ鮮度管理とは、データ基盤に置かれた個々のデータについて、それがいつの情報で、いつ更新されたかを把握できる状態を保つ取り組みです。
鮮度に絶対的な基準はなく、そのデータを何に使うかによって求める水準が変わります。

AIがデータを直接参照して回答を組み立てる構成では、参照先に古い情報が残っているだけで回答の精度が落ちます。
利用者は回答のたびにデータの鮮度を確かめることになり、その手間が積み上がると、AIに聞くという選択そのものが徐々に取られなくなります。

だからこそ、AIのためのデータ基盤では、品質だけでなく鮮度も設計対象になります。
自社のどのデータに時点の情報を持たせ、誰が更新頻度を決めるのかを、基盤の設計に入る前に決めておくと、後から付け足す手間を減らせます。