AIが自信満々に古い情報を答えるのは、なぜ？

ミドリ： タツヤさん、AIにあるツールの料金を聞いたら、はっきりした金額を答えてくれたんです。でも実際に公式サイトを見たら、まったく違っていて……。

タツヤ(nodding)： よくある事故だね。AIは「知らない」と「古い」を区別できないんだ。

ミドリ(confused)： どういうことですか？

タツヤ： AIにとって、学習した時点の情報は「事実」として頭に入っている。その後に変わったことは知らない。でも変わったことを知らない、ということ自体を知らない。

ミドリ(surprised)： だから自信満々なんですね。

タツヤ： そう。確信度と正確さが連動していない。ここが一番危険なところでね。今日は鮮度をどう担保するかを設計の話として整理しよう。

3つの鮮度を分けて考える

ミドリ： 鮮度って、一種類じゃないんですか？

タツヤ： 3つある。それぞれ対策が違うから、まず分けることが大事なんだ。

ミドリ(thinking)： 分けて考えると整理しやすいですね。

タツヤ： そう。多くの現場は①だけを気にして、実は③で一番事故っている。ここは後で詳しく話すね。

①モデルの知識 — 「いつ時点か」を意識する

ミドリ： モデルの知識の鮮度は、どうすればいいですか？

タツヤ： 根本的な対策は1つ。変化する情報をモデルの記憶に頼らない。

ミドリ： 頼らない、というと。

タツヤ： 価格・仕様・法令・組織・人事。この5種類は、モデルの知識だけで答えさせない。必ず一次情報を確認する工程を入れる。

ミドリ： 「概念の説明はよい」というのが救いですね。

タツヤ(nodding)： AIの本当の強みは、変わらない部分にあるんだよ。原理や考え方を分かりやすく説明させるのは非常に得意。変わるものを聞くから事故るだけなんだ。

ミドリ(thinking)： 用途を選べばいい、と。

タツヤ： そう。「これは変わる情報か?」と一度立ち止まるだけで、事故の大半は防げるよ。

②外部情報 — 検索させても安心ではない

ミドリ： 検索機能を使えば解決しますか？

タツヤ： 半分は解決する。でも新しい問題が生まれる。

ミドリ： どんな問題ですか？

タツヤ(thinking)： 検索で拾ってきた情報が、そもそも古いという問題。

ミドリ(surprised)： ……あ、そうか。

タツヤ： 検索上位に2年前の記事が来ることは普通にある。AIはそれを読んで「最新情報を確認しました」という顔で答える。検索したという事実と、情報が新しいことは別なんだ。

ミドリ： どう対策しますか？

タツヤ： 3つある。

• 一次情報を優先させる — 公式サイト・官公庁・調査元。まとめ記事は参考どまり
• 日付の明示を求める — 「その情報は何年何月時点か」を必ず出力させる
• 重要な数字は人が確認する — 価格・条件・法令は、最終的に公式ページを開く

ミドリ： 「何年何月時点か」を出させるのはいいですね。

タツヤ(nodding)： これが効くんだ。日付を書かせると、AI自身が根拠の弱さに気づくことがある。「時点が不明」と出てきたら、それは信頼できない情報だと分かる。

③自社データ — ここが一番事故る

ミドリ： 3つ目が本命だと言っていましたね。

タツヤ： そう。社内文書をAIに読ませる仕組みを作った会社で、一番多い事故がこれなんだ。

ミドリ： どういう事故ですか？

タツヤ： 古い社内文書を根拠に、AIが自信満々に答える。

• 2年前の価格表を読んで、旧価格を回答する
• 廃止された申請手順を案内する
• 前の組織体制の担当者名を答える

ミドリ(surprised)： これ、外部情報より深刻ですね。社内の人は信じてしまいます。

タツヤ(nodding)： そこなんだよ。「社内の資料に基づいています」と言われると、疑わない。外部情報なら「一応確認しよう」と思うのに。

対策は「文書側」に入れる

ミドリ： どう防げばいいですか？

タツヤ： AIの側ではなく、文書の側に仕掛ける。

ミドリ： 「旧版を検索対象から外す」が地味に重要そうですね。

タツヤ： 一番重要かもしれない。多くの現場では、旧版がフォルダに残ったままAIの参照対象に入っている。新旧が両方ヒットして、AIが古いほうを採用することが普通に起きるんだ。

ミドリ(thinking)： ファイル名に「_old」と付けて残していました……。

タツヤ(smiling)： どこの会社でもやってるよ。人間は「_old」を見て判断できるけど、AIは中身しか読まない。だから物理的に別の場所へ移す必要があるんだ。

出力に鮮度を書かせる

ミドリ： 使う側でできる工夫はありますか？

タツヤ： ある。回答に必ず出典と時点を書かせる形式にしておく。

【回答フォーマットの指定例】

回答:
(本文)

根拠:
- 参照した文書名 / 更新日
- 参照したURL / 確認時点

注意:
- この情報が古い可能性がある場合はその旨を明記すること
- 確認できなかった項目は「不明」と書くこと

ミドリ： 「不明と書くこと」を指定するんですね。

タツヤ(nodding)： これが大事でね。指定しないと、AIは空欄を埋めようとする。「不明でよい」と明示すると、素直に不明と書いてくれるようになる。

ミドリ(thinking)： 埋めなくていいと伝える。

タツヤ： そう。AIの誠実さは、指示で作れる部分があるんだ。

脱エンジニアの視点で考えると、「その情報は何日経ったら嘘になるか」を業務ごとに言えるかが分岐点になります。 経営理念は10年変わらない。価格表は1年で変わる。在庫数は1時間で変わる。この感覚は業務を知っている人にしかないからね。

業務別の鮮度要件

ミドリ： 業務によって必要な鮮度も違いますよね。

タツヤ： 違う。整理するとこうなる。

ミドリ： リアルタイムが必要なものは、仕組みが重くなりますね。

タツヤ(nodding)： だから「本当にリアルタイムが必要か」を先に確認する。在庫数を答える必要があるのか、それとも「在庫は基幹システムでご確認ください」と案内すれば済むのか。

ミドリ： 案内で済むなら、そのほうが安全ですね。

タツヤ： 答えないという選択肢を最初から用意しておく。これが鮮度設計でいちばん実務的な判断だと思う。

よくある失敗

ミドリ： つまずきやすいポイントも教えてください。

タツヤ： 4つある。どれも現場でよく見る。

• 「最新情報を調べて」と書けば新しくなると思っている — 検索するかどうかと、拾った情報が新しいかは別
• 文書に更新日を書いていない — AIが古さを判断する手がかりがゼロになる
• 一度作った参照データを更新していない — 半年前の状態で止まっている
• 回答が正しいかを月次で確認していない — 静かに間違い続ける

ミドリ(thinking)： 4つ目、気づけないですよね。

タツヤ(nodding)： 気づけないのが一番怖い。だから定点確認を仕組みにする。

ミドリ： どうやるんですか？

タツヤ： 代表的な質問を10個決めて、月1回投げて答えを保存する。前月の答えと見比べて、変わっていないか、間違っていないかを見る。

【定点確認の質問例】
- 「Aサービスの料金プランを教えて」
- 「経費精算の申請手順は?」
- 「○○の担当部署はどこ?」
- 「今期の重点方針は?」

ミドリ： 10分もあれば終わりそうですね。

タツヤ： 月10分で、社内AIが嘘をついていないかが分かる。これほど費用対効果の高い運用はなかなかないよ。

誰が確認するか決める

ミドリ： 担当は誰がいいですか？

タツヤ(thinking)： その情報の持ち主が確認するのが理想だね。経費精算の回答なら経理、人事制度なら人事。

ミドリ： 情シスがまとめてやるのではなく。

タツヤ： 情シスは正しさを判断できないんだよ。仕組みは作れても、「この回答が今の制度と合っているか」は分からない。内容の正しさは、業務の持ち主にしか判定できない。

ミドリ(thinking)： 役割分担ですね。

タツヤ(nodding)： 仕組みは情シス、中身は現場。ここを混ぜると、どちらも責任を持てなくなる。月10分を各部署に1つずつ持ってもらう、くらいの分担が現実的だと思う。

まとめ

タツヤ： 今日の要点を整理しよう。

• AIは「知らない」と「古い」を区別できない。確信度と正確さが連動していない
• 鮮度は①モデルの知識 ②外部情報 ③自社データの3つに分けて考える
• 価格・仕様・法令・組織・人事はモデルの知識に頼らない。概念や手順は頼ってよい
• 検索させても拾った情報が古いことがある。一次情報優先・日付明示・人の確認
• 一番事故るのは③自社データ。社内資料は疑われないぶん被害が大きい
• 対策は文書側に。有効期限・版と更新日・旧版の分離・期限切れ検知
• 「_old」は人間にしか通じない。旧版は物理的に参照対象から外す
• 出力に出典と時点を書かせる。「不明と書いてよい」と明示する

ミドリ(smiling)： 鮮度って、AIの性能の話だと思っていました。

タツヤ： そこが今日いちばん伝えたかったところ。鮮度は仕組みの問題なんだ。どんなに高性能なAIでも、古い資料しか渡されなければ古い答えを返す。逆に言えば、渡す情報を整えれば、今のAIのままで解決できるということでもあるよ。

次のアクション

ミドリ： 何から手を付けましょう。

タツヤ： 3つ。

1. AIに参照させている社内フォルダを開き、旧版を別の場所へ移す — 1時間。効果が一番大きい
2. 主要な社内文書に「更新日」と「有効期限」を入れる — まず10本だけでいい
3. 回答フォーマットに出典と時点の記載を追加する — 「不明でよい」の明示も忘れずに

タツヤ： Shimanto AI Solutionsでは、この設計を支援しているよ。

• 参照データの棚卸し — AIが読んでいる社内文書を洗い出し、旧版と現行を分離する
• 鮮度要件の定義 — 業務ごとに許容できる古さを決め、必要な連携範囲を見極める
• 出力形式と検証工程の設計 — 出典・時点の明記と、人の確認を挟む箇所を業務に組み込む

ミドリ： 旧版の分離からですね。

タツヤ： そう。掃除から始めるのが、いちばん効果が出やすい。新しい仕組みを足す前に、まず古いものをどけよう。

情報の時点について

本記事は執筆時点(2026年8月)における当社の運用に基づく整理です。モデルの学習時点や検索機能の挙動はサービスとバージョンで異なるため、実際の鮮度要件は利用中のサービスの公式ドキュメントで確認してください。本記事自体も、この原則に従って更新日を frontmatter に記録しています。

関連記事

• コンテキストエンジニアリング入門 — プロンプトより「何を渡すか」で精度が決まる
• AIハルシネーション対策：7つの実践テクニック
• RAG（Retrieval-Augmented Generation）の実装
• AIで作った「それっぽいだけ」を社内に溜めない — 品質基準のつくり方

シマント AI のサービス | 脱エンジニアの部屋 | AI戦略マップ 2025–2045