COLUMN 技術コラム

AIの回答の15〜40%は既に古い——忠実性検証では防げない「前提の腐敗」に、事実台帳法という統治設計で挑む実測レポートです。

AIの回答の15〜40%が「もう古い」という現実

まず、外部の研究から1つ数字を紹介します。検索拡張生成（RAG）——社内文書をAIに参照させて回答させる、いま最も普及しているAI構成——について、時間的有効性を検証した研究があります。結論はこうでした。

標準的なRAGは、変化し続けるデータに対して15〜40%の頻度で、既に無効になった値を回答する。

理由は単純です。AIにとって「意味が似ている」ことと「今も正しい」ことは無関係だからです。18ヶ月前の料金表は、最新の料金表と意味的にはほぼ同じに見えます。だからAIは自信を持って、古い価格を答えます。エラーは出ません。警告も出ません。

これが、AIのPoC（試験導入）が本番に進めない隠れた理由のひとつです。デモでは正しく答えていたAIが、半年後には静かに間違い始める。しかも「間違い始めたこと」に誰も気づけない。

私たち自身の失敗談：たった一文が、1ヶ月間すべてを汚染した

弊社はAI事業の研究開発の中で、この問題を身をもって経験しました。

私たちの実験プロジェクトの初日、仕様書にこう書きました——「既存顧客はEC事業者が中心」。もっともらしい一文です。しかし、これは事実と違っていました。

AIはこの一文を約1ヶ月間、信じ続けました。その間に、この誤った前提は市場探索の方向を歪め、商品設計に伝播し、営業資料にまで染み込みました。無駄になった探索は12件。発見のきっかけは、人間がふと「そういえば、うちの顧客って本当にEC中心だっけ？」と口にしたことでした。

ここで重要なのは、AIは一度も「誤作動」していないことです。与えられた前提に忠実に、完璧に論理的に働き続けた。壊れていたのは前提のほうでした。

「忠実性の検証」では、この事故を防げない

AIのハルシネーション（もっともらしい嘘）対策は近年かなり進歩しました。出力が参照文書に忠実かを判定する専用モデル（Patronus Lynx、Vectara HHEMなど）や、応答を返す前に知識ソースと照合するガードレール（NVIDIA NeMo Guardrailsなど）が実用段階にあります。

しかし、これらの道具には共通の前提があります。「参照している知識ソースは正しい」という前提です。

私たちの失敗談に当てはめてみてください。仕様書の「顧客はEC中心」が知識ソースに入っていたら、忠実性検証は何と言うでしょうか——「出力はソースに忠実です。合格」。

忠実性は、真実性を保証しません。 ソースが間違っていれば、AIはソースに忠実に、間違い続けます。そして企業のAI活用で本当に怖い事故は、たいていこちら側で起きます。料金の改定、規約の変更、組織の変化、そもそも最初から間違っていた思い込み——。

事実台帳法：AIに「真実の保管」を任せない

この問題への私たちの答えは、突き詰めれば一行です。

AIに「何が真実か」を保持させない。真実は人間が台帳に書き、機械は鮮度を見張り、AIは求められたときだけ照合する。

具体的には、システムが依存する重要な事実を、1件ずつこう記録します。

- id: F2
  fact: "動画生成APIの実測単価は1.5クレジット/秒"
  source: "実測検算（AIの自己申告値は3回誤っていた）"
  verified_by: "代表者"
  verified_on: 2026-07-17
  expires: 2026-08-17   # 賞味期限。料金は変わるもの

ポイントは4つあります。

1. 人間が書く。AIが起案してもよいが、1行ずつ人間が承認したものだけが「正」になる
2. 署名がある。誰が・いつ保証したかが残る。既存ツールの「自動的な鮮度スコア」と違い、検証責任の所在が構造化される
3. 賞味期限がある。事実は腐ります。期限が切れたら機械が「再検証してください」と人間に通知する——機械は意味の正しさを検証できませんが、「検証の期限切れ」なら完璧に検知できます。ここが人間と機械の正しい分業線です
4. 保証できない事実は隔離する。実際に私たちの台帳には、担当者が「これは自分では保証できない」と判断して正から外した事実があります。以後、AIの応答がその事実に触れると警告が上がります

さらに、誤った前提がそもそも系に入らないよう、入口に3つのゲートを置きます。仕様書に事実を直書きするとき（台帳登録と人間検証を経る）、AIが申告した数値を使うとき（一次データで検算する）、根拠が単一ソースのとき（2つ目のソースを確認するか「単一ソース」と明示する）。

効果と限界を、実測で正直に言います

私たちは過去に起きた「誤った前提」の実例6件に対し、「この仕組みが当時あったら、いつ捕捉できたか」の追試を行いました。結果は次の通りです。

• AIの自己申告数値の誤り（料金など）: 初回使用時の検算で捕捉できた（確度高）
• 仕様書への誤前提の混入: 防止は保証できない——誤解が組織の「空気」になっている場合、人間の検証も通過し得ます。ただし明文化されることで後からの反証が可能になり、1ヶ月の潜伏が大幅に短縮された見込み
• 執筆・計算の中身の誤り、登録しようのない未知の事実: この仕組みの射程外です。別の対策（レビュープロセス等）の領域

つまりこの方法は万能ではありません。効くのは「事前に登録できる重要事実」の範囲です。——そして、この範囲を正直に言うこと自体が、この方法論の一部だと私たちは考えています。グラウンディング（事実への接地）を「ハルシネーションを防ぎます」と誇張した瞬間、その主張自体が検証されていない宣伝文句になってしまうからです。

実装は0円から始まる

大がかりな基盤は要りません。私たちの最小構成は、YAMLファイル1枚と、毎朝それを走査するスクリプト1本です（LLMは呼びません。日付比較だけなので実行コストはゼロです）。

次の段階として、社内のAI利用が通過するゲートウェイ（LiteLLM等）のフックに照合を組み込めば、全AIトラフィックに対して「期限切れ・未検証の事実への言及」を自動検知できます。私たちはこの構成を自社で実運用しており、本番前には「わざと壊して警報が鳴るか確かめる」避難訓練も行っています——鳴らない検知器は、無いのと同じどころか、あると思っている分だけ有害だからです。

まとめると、信頼できるAI応答には3つの層が必要です。

1. 事実台帳——誰が保証したか・いつまで有効か（人間の署名と期限）
2. 鮮度の監視——期限切れの機械検知（コストゼロ）
3. 忠実性の照合——出力が台帳・文書と一致するか（既存の判定モデルを活用）

既存のAIツールは3層目だけを提供します。1層目と2層目——説明責任の設計——は、ツールを買っても付いてきません。そしてPoCが本番に進めない理由の多くは、ここにあります。

おわりに

AIの導入で本当に難しいのは、モデルの性能ではなく「何が正しいかを、誰が、いつまで保証するか」という地味な統治の設計です。弊社は25年、企業のインフラ運用を預かってきた会社として、この地味な部分ごとAI運用をお引き受けしています。

「うちのAI、本当に正しいことを言っているんだろうか」——そう思ったことがあれば、一度ご相談ください。現状のAI構成に対する診断から始められます。