林さんは小さなネットショップで働いていて、常連客への発送の手配を AI アシスタントに頼んだ。AI は過去の会話からその客の住所を探し出した。書式は整っていて文面も自然で、打ち直す手間も省けた。問題は、客が今回の注文に新居の住所を書いていたのに、AI が使ったのは半年前の雑談に出てきた古い勤務先の住所だったことだ。

「AI が覚えている住所はもっともらしいか」と問うだけなら、答えはたぶん「はい」だ。本当に問うべきは、この箱の行き先を決めているのは何か、である。答えは今回の注文の配送先欄であって、AI の記憶ではない。だから住所、金額、予約の時間帯のように行動に使うデータについて、AI の記憶にできるのは「ここに住所が要る」と知らせることだけだ。値そのものは、行動の直前に、それを更新する責任を持つ正本から読み直す。両者が食い違ったら止める。

覚えていることと、いまも正しいことは別だ

記憶機能のおかげで AI は多くの質問を省けるので、覚えていることは信頼できると思いやすい。だが記憶が示せるのは、ある情報がかつて会話に出てきたということだけで、いまも当てはまるということではない。人は引っ越し、担当者は代わり、予算は承認し直される。記憶の中の値は、それに合わせて自動で更新されたりしない。

同じ会話の中で「住所は本当に合っている？」と念を押しても役に立たない。AI は同じ記憶から答えを探すので、記憶が自分で自分の証人になるのと同じだ。有効な確認には別の道が要る。ほかの誰かが責任を持って保守しているデータに戻ることだ。

データの種類ごとに正本を決める

同じ「覚えておいて」の裏には、四つの異なる保存の必要がありうる。置くべき場所はそれぞれ違う。

  • 答え方の好み：箇条書きが好き、レシピにパクチーを入れない、など。記憶に残してよく、内容の調整にだけ使う。間違えても直しやすい。
  • 今回の取引の値：配送先、支払額、予約の時間帯など。今回の注文、請求書、予約の記録に置く。どの取引をするなら、その記録を読む。
  • 変わり続ける業務データ：顧客の担当者、在庫、期限、承認済みの予算など。顧客管理システム、在庫システム、カレンダー、承認の記録に戻し、誰が更新するのか、最後にいつ更新されたかも残す。
  • 機微なデータや第三者のデータ：健康情報、他人の連絡先、同意の記録など。用途、権限、保存期間がすでに決まっているシステムにだけ置く。そういう場所がなければ、その場で権限のある人に確かめ、AI の記憶には別に保存しない。

あるデータが正本と言えるかどうかは、それがこの項目、この相手、この時点に責任を持っているかで決まる。古いサポートの会話より今回の注文のほうが配送先を決めるのにふさわしく、会話の中の「その日なら大丈夫そう」より確定したカレンダーのほうが会議の時間を決めるのにふさわしい。

広告

行動の前に正本から読み直す

発送なら、正しい順序はこうだ。AI は記憶から「この流れには配送先が要る」とわかる。次に、注文番号をもとに、今回の注文の配送先を読み取り専用で読み出す。プレビューには、その住所、どこから来たのか、いつ読んだのかを並べて表示する。人が確かめてから、初めて発送が実行される。発送を担うプログラムの部分は、記憶から直接来た住所を受け付けないようにしておく。

同じやり方はほかの動作にも当てはまる。予約の前にはいまのカレンダーを、支払いの前には承認済みの請求書を、通知の前にはその案件の連絡先一覧を読む。

読み直した結果にも停止条件が要る。記録が見つからない、権限がない、データの版が古すぎる、記憶の値と正本が食い違う、あるいは正本自体がまだ「要確認」になっている。こうした場合に出せるのは、下書きと人への確認事項だけだ。AI がどちらが新しいかを推測してはいけないし、利用者の一度きりの答えを、黙って恒久的な初期値として保存してもいけない。

これは二つの技術文書の注意とも一致している。Anthropic が開発者向けに提供する記憶ツールは、データをどこにどう保存し読み書きするかをアプリケーション自身に任せ、開発者に機微なデータの扱いや、長く使われていない記憶の定期的な削除を求めている。アプリケーションセキュリティに取り組むオープンなコミュニティである OWASP の AI エージェントのセキュリティ指針は、影響の大きい動作の承認を、具体的なツール、対象、パラメーターに結びつけるよう求めている。記憶は管理されるべきデータであり、モデルが自信ありげだからといって正しく保たれるわけではない。

正本がないとき

行動のたびに正本から読み直すには、正本が存在し、読めることが前提になる。小さなチームの多くは、顧客データが表計算、メール、チャットの記録に散らばっていて、はっきりした正本がない。その場合、最初の一歩は AI とは関係がない。よく使う数項目、たとえば配送先について、更新に責任を持つ場所を決めることだ。

誤ったデータを直すときは、順番も大事だ。まず正本を直し、それから記憶を消す。住所が違うと気づいた林さんは、まず今回の注文を直すべきだ。顧客情報の既定の住所も古いなら、権限のある人が更新する。AI の記憶や古い会話の始末はその後だ。正本を直さずに記憶だけを消せば、次に AI はまた別のところから古い住所を読むかもしれない。

次の一歩として、毎日実際に動いている発送、予約、通知の流れを一つ選び、行動に使われる各項目について、正本がどこにあり、何をもとに調べ、誰が更新するのかを書き出してほしい。説明できない項目があれば、その流れは下書きの段階にとどめる。AI が覚えているのがデータではなくあなたの過去の考えなら、心配すべきは別の問題だ。AI があなたの考えを覚えると、あなたに話を合わせやすくなるを参考にしてほしい。よく使うデータの正本を決めるやり方は、AI に社内の数字を調べさせるとき、正確さは定義を保守する人がいるかで決まるも参考になる。

AI 整理カード

発送、予約、支払い、通知を行う AI の流れが、AI の記憶にある古いデータをそのまま使って動いていないか確かめたい。
判断方法はこの記事による：https://boosterminiclass.com/ja/posts/ai-memory-verify-before-action/
記事の見方はこうだ。行動に使うデータ（住所、金額、予約の時間帯、連絡先）について、AI の記憶にできるのは「何が要るか」を知らせることだけで、値そのものは行動の直前に、更新に責任を持つ正本（たとえば今回の注文）から読み直す。正本が見つからない、権限がない、値が食い違うなら、プレビューで止める。

まず私に 3 つ質問してほしい：
1. それはどの流れで、最後にどんな動作（発送、予約、支払い、通知）をするのか；
2. その動作に使われる項目は何で、いま AI はそれをどこから得ているのか；
3. そのデータはふだんどのシステムにあり、誰が更新しているのか。

私の回答をもとに、次を出力してほしい：
- 項目ごとに一行：いまの取得方法／読むべき正本／照会の手がかり（注文番号など）／更新の担当者。わからないものは「要確認」とする；
- AI が実行前にどう読み直して照らし合わせるべきか、プレビューに何を表示すべきか；
- 下書きで止めるべき場面：正本が見つからない、権限がない、版が古すぎる、値が食い違う；
- データが誤っていたときの直す順番：まずどこを直し、次に何を消すか。
確認と提案だけにとどめ、私の代わりにデータや記憶を変更しないこと。実行するかどうかは、その流れに責任を持つ人が決める。
広告

Share

このミニクラスを共有

このミニクラスが仕事の詰まりをほどく助けになったら、AI の使い方を考えている人にも共有してください。

参考資料