AIが古い情報を使うのを防ぐ：会社の「現在の正解」と更新責任の決め方

AIが古い価格や過去の方針を答える原因は、記憶力よりも「どの情報を正式な答えとして使うか」が決まっていないことにあります。最初に必要なのは全社資料の整理ではなく、一つの業務について、現在の正解、更新する人、確認する時期、矛盾したときの停止条件を決めることです。

Kirirom（キリロム）でも、情報が更新されなかったことで実際に判断がずれました。2026年9月、あるイベントについて「中止」という記録が残った後、主催者が同日中に「延期」と訂正しました。しかし訂正が現在の運用情報へ反映されるまで間が空き、その間に中止を前提とした誤った指摘が生まれました。

後日の確認では、イベント名、開催時期、料金、申込条件を変更した後も、一部の公開ページや制作物に旧情報が残っていました。原文は存在し、決定も終わっていました。足りなかったのは、決定を正式な答えへ反映し、影響する資料を更新し切る責任です。

この記事では、この種の情報事故を「イベントの問い合わせへ返信する」という一業務に絞って直します。

まず、症状から原因を分ける

AIの回答が間違ったとき、すぐに指示文や検索機能を変えると原因を見失います。回答に使われた情報を見て、次のどれかに分けます。

情報量を増やしても、優先順位がないままなら矛盾は増えます。必要なのは「多く読ませること」ではなく、「この仕事では、これを正式な答えとして使う」と決めることです。

一業務の管理表から始める

会社全体の文書を棚卸しする必要はありません。まず、間違えると顧客へ影響する一つの業務を選びます。ここではイベントの問い合わせ返信を例にします。

この表で重要なのは、資料名を並べることではありません。一つの項目につき、正式な答え、更新する人、使う直前の確認、矛盾時の動作が決まっていることです。

たとえば料金表が複数あっても、「販売責任者が更新する現行条件だけを回答に使う」と決まっていれば、過去の提案書にある料金を拾って返す事故を防げます。逆に、最新版らしいファイルをAIに推測させるだけでは、事故の責任者も修正先も決まりません。

証拠・経緯・現在の正解は、使い道が違う

Kiriromでは会社情報を三つに分けています。分類自体が目的ではありません。AIが何を正式な答えとして使い、何を確認材料としてだけ使うかを分けるためです。

証拠は、言われたことを確かめるために使う

顧客の問い合わせ、契約書、請求書、責任者から届いた訂正文など、受け取った原文です。要約で上書きせず、後から文言と条件を確かめられる状態にします。

イベントの例では、「中止ではなく延期」という責任者の訂正文が証拠です。AIはこれを勝手に書き換えません。ただし、原文があるだけでは日々の返信は変わりません。正式な答えへ反映する工程が別に必要です。

経緯は、なぜ変えたかを理解するために使う

以前の開催案、変更した理由、採用しなかった選択肢、変更によって生じた影響を残します。経緯は、同じ議論を繰り返さないために役立ちます。

一方、過去に一度決めた内容が、いまも有効とは限りません。AIが経緯から日程や料金を直接回答しないようにします。

現在の正解は、仕事の答えとして使う

現在のイベント名、日程、料金、申込条件、承認者など、その仕事で今使う情報です。人が矛盾を裁定し、正式な答えとして採用した内容だけを置きます。

現在の正解には、少なくとも次を持たせます。

• どの業務で使う情報か
• 誰が内容を確定し、誰が更新するか
• 最後に確認した時点
• 次に確認する条件
• 未確認または更新待ちの項目

「公式ページだから正しい」とは限らない

Kiriromが2026年9月19日に自社の公開情報を点検した際、複数の公式ページで役職の表記が揺れ、延期・改名後のイベントについて旧名称が残っている箇所が見つかりました。

公式ページは、顧客が現在見ている情報を知るための重要な証拠です。しかし、更新待ちであれば、社内で確定した最新条件と一致しないことがあります。「公式」「新しい日付」「詳しく書かれている」といった見た目だけで、AIに優先順位を決めさせてはいけません。

食い違いを見つけたときは、次の順に処理します。

1. どの項目が食い違うかを特定する
2. それぞれの根拠と確認時点を並べる
3. その項目を決める責任者へ裁定を戻す
4. 正式な答えを更新する
5. 影響するページ、資料、返信文面を更新する
6. すべての反映を確認するまで、AIによる回答や送信を止める

責任者が決める前に、AIが「こちらの方が新しそうだ」と採用すると、推測が会社の公式見解に変わってしまいます。

情報が変わった日の更新を一つの仕事にする

イベントの変更時に必要だったのは、会議記録を残すことだけではありませんでした。変更を受けて、販売条件、申込先、公開ページ、告知物、問い合わせ返信をそろえて直し、旧情報が使われないことを確認する必要がありました。

変更が決まったら、次のまとまりを一つの更新作業として扱います。

1. 原文を保つ

誰が何を決めたかを、後から文言まで確認できる状態にします。口頭の要約だけで現在の正解を書き換えません。

2. 変更理由を残す

何が変わったかだけでなく、以前の案をなぜ採用しないのかを残します。古い資料が後から見つかったときに、再採用しないためです。

3. 正式な答えを更新する

日々の返信や作業でAIが使う情報を、責任者が確認した内容へ変えます。判断待ちの項目は空欄を推測で埋めず、「未確認」と確認先を示します。

4. 影響先を確認する

Webページ、申込画面、決済リンク、提案資料、メール文面など、変更前の情報を使う成果物を洗い出します。すぐ直せないものには「更新待ち」と利用停止を付けます。

5. 実際の表示と回答を確かめる

管理表を直しただけで完了にしません。顧客が見るページと、AIが作る返信の両方が新しい条件になったことを確認します。

AIへ資料を渡す前の5問

一業務について、次に答えられれば運用を始められます。

1. この仕事でAIが答える項目は何か
2. 各項目の正式な答えはどれか
3. その答えを更新する人は誰か
4. いつ、何が起きたら再確認するか
5. 矛盾や未確認があったら、AIはどこで止まるか

答えられない項目があれば、会社資料を増やす前に、その項目だけを決めます。必要な情報は業務によって違います。イベント返信の管理表を、そのまま契約レビューや経理へ広げる必要はありません。

長期記憶や検索だけでは解決しない

AIの長期記憶や社内検索は、必要な情報を見つける助けになります。しかし、古い価格と現行価格の両方を正確に記憶しても、どちらを使うべきかは決まりません。

Anthropicも、AIエージェントのコンテキスト設計を、限られた入力の中から必要な情報を選び、保ち、更新する仕事として説明しています。情報を検索できる状態と、その情報を会社の正式な答えとして使える状態は別です。

出典: Anthropic「Effective context engineering for AI agents」

AIカンパニーの会社知識は、文書を集めた量ではなく、一つの仕事で使う正式な答えと、更新責任と、止まる条件がそろっているかで評価します。

AIネイティブ企業の作り方では、この情報をAI部署、手順、検証、承認へ接続する方法を説明しています。経営全体での位置付けは、AIネイティブ経営の4段階で確認できます。