先週、メールの下書きを頼んだときに「今回は短めに」と伝えた。今週は詳しい報告書が必要なのに、AIは説明をどんどん削ってしまう。理由を聞くと、「簡潔な文章がお好みだと記憶しています」と答える。
抜け落ちたのは、「今回は」という条件だ。その場だけの注文が、いつの間にか今後も続く好みとして扱われている。
Anthropicの2026年11月6日の発表では、Stainlessの資料に関する25問の評価基準達成率は、検索とwikiの併用で61％、検索のみで53％。別のポケモン比較では、Sonnet 3.7とFable 5の記憶ファイルは413個と10個、バッジは1個と4個だった。モデルが異なり、各1回なので、記憶方法だけの因果効果は特定できない。
この研究をきっかけに考えたいのは、日々の使いやすさに直結する問題だ。AIが以前の情報を持ち越せるようになったとき、その記憶をどこまで信用してよいのだろう。
一度の選択がいつもの好みに変わる
たとえば、午後の会議に間に合わせるために、早朝の便を選んだとする。そこでAIが「朝早い便を好む」とだけ記録すると、次の休暇でも夜明け前の出発を勧めてくるかもしれない。
元の判断には理由があった。要約する途中で、その理由が消えてしまったわけだ。
仕事でも似たことは起こりうる。「この顧客は来期まで導入を見送る」という話が、「導入に関心がない」に変わる。旧バージョン向けの手順が、現在も通用する手順として残る。不具合の原因についての仮説が、確認済みの説明として扱われる。
長く使うメモなら、誰の情報か、いつの話か、どんな条件で成り立つのかを一緒に残してほしい。確認済みの事実と、まだ確かめていない推測も区別できたほうがよい。
読む手間は少し増える。それでも、間違った前提で話を進めてからやり直すより、ずっと扱いやすい。
AIはバックグラウンドで記憶をどう整理するか
Anthropicは、AIがバックグラウンドで記憶を整理することを「dreaming」と比喩的に表現している。人間のように夢を見ることや、AIのハルシネーション（幻覚）を指すわけではない。Dreamsのドキュメントによると、研究プレビュー中のこの機能は、過去の会話と既存の記憶を照合し、整理した結果を別のメモリストアに出力する。入力は変更されず、出力は採用前に確認することもできる。
仕事が一段落してから、引き継ぎメモを見直す場面を思い浮かべるとわかりやすい。作業中は気づかなかった食い違いや、後で変わった予定を整理する時間だ。
ただし、文章を読みやすく整えるだけでは、内容が正しくなったかどうかはわからない。
最初の議事録に日付の誤りがあったとする。それをきれいな要約に書き直すと、かえって確定した予定のように見えるかもしれない。
この仕組みを製品に取り入れるなら、変更前後を比べられることと、根拠になった情報へ戻れることを優先したい。証拠が足りない部分は、未確認のまま残してもよい。すべてをすっきりした文章にまとめる必要はない。
よいメモは次の仕事のどこを楽にするか
先ほどのwikiは、関連するページをリンクでつないだ資料集と考えるとよい。随時更新できる社内ハンドブックのようなものだ。
あるプロジェクトの要件は文書に、日程は表計算ファイルに、直近の決定はチャットに分かれているとしよう。「今週公開できるか」と聞かれたら、関連する情報を探し、それぞれが同じ版の話かどうかも確認しなければならない。
継続して更新されるプロジェクトメモがあれば、調べ始める場所を絞れる。対象のリリース、最終確認の担当者、まだ満たしていない条件がわかるだけでも、次の作業に入りやすくなる。
一方で、契約の例外規定や支払期限、特定の版だけに当てはまる技術的な制約は、短い説明では重要な部分が落ちやすい。判断する段階では、該当する原文まで戻れるようにしておきたい。
評価したいのは、メモが増えたことより、調べる負担がどう変わったかだ。根拠を探す時間は減ったか。未解決の点は見つけやすくなったか。情報が変わったとき、何か所を直せばよいのか。
元の資料を別の場所へ写しただけなら、更新しなければならない文書が一つ増える。その手間も含めて考える必要がある。
導入前に試しておきたい場面
AIの記憶機能を仕事で使うなら、普段の業務に近い、小さなテストを用意するとよい。
まず、予定を変更する。最初に公開日を伝え、その後で新しい日付に変更したと明示する。続けて、その日程に合わせた作業計画を作ってもらう。
次に、一度限りの指示を出す。あるメールは堅めの文体にし、その後は気軽なメッセージを頼む。前の指示が、別の場面にまで持ち越されないかを見る。
名前の似た二つのプロジェクトも試したい。条件が違うのに、片方の決定がもう片方へ混ざらないかを確認する。
最後に、一つの記憶を削除してもらう。同じ話題を別の言い方で尋ね、消したはずの前提が回答に残っていないかを調べる。
これらはテストの提案であり、この記事で実施した実験ではない。比較するなら、モデル、参照できる情報、課題の難しさをそろえ、何度か繰り返す。正確さだけでなく、時間と費用も記録したい。複数の条件を同時に変えると、何が改善に効いたのか判断しにくくなる。
利用者が記憶を直せることも大切
記憶機能には、オンとオフ以外の操作もほしい。
何気なく言った一言が長期的な好みになっていたら、その記録を見つけて「前回の作業だけ」と直せる。終わったプロジェクトの事情が、無関係な相談にまで出てこないようにできる。そうした使い勝手は、毎日のやり取りに響いてくる。
また、覚えていることと、実行してよいことは分けて扱う必要がある。いつも買うコーヒーを知っているだけで、注文や支払いまで任せたことにはならない。この境界は製品側で明確にしておきたい。
利用者が最初に気にするべきなのは、保存できる情報の量だけではない。間違いを指摘したら直るか。「今日だけ」と「いつも」を区別できるか。状況が変わったとき、古い判断をそのまま使わず確認してくれるか。
背景を毎回説明しなくて済むのは助かる。さらに、何か月も前の自分についての思い込みを毎回訂正せずに済むなら、AIの記憶はずっと使いやすいものになる。