Claudeの​記憶を​仕事に​生かす──Anthropicが​示した​メモ・検索・Wikiの​設計

社内AIに、前回決めたことを毎回説明している。一方で、覚えさせた古い情報を、いつまでも使われるのも困る。Claudeのメモリを業務で使うとき、この二つはセットで考えたい課題です。

Anthropicは2026年11月6日、AIエージェントの記憶をどう残し、使い、見直すかをまとめた「The components of agent memory」を公開しました。会話ログ、短いメモ、Wikiを使った検証を通じて、情報を大量に保存するだけでは十分ではないことを示しています。^[1]

この記事では、その考え方を社内業務の設計に置き換えます。残す・探す・見直すの三つをつなぐと、どこから試すべきかが見えてきます。

情報は2026年11月7日時点。公式研究の評価結果とCAGが考えた業務設計例を分けて紹介します。CAGがManaged AgentsやDreamingの性能を実測した記事ではありません。

ここでいう記憶は、ある仕事で得た情報を、別の作業や会話でも使えるように残す仕組みです。モデル自体を再学習することとは違います。会話が続いている間だけ見えている履歴とも、分けて考えます。

例えば、見積書を作るAIに「この取引先は、納品日と請求日を分けて記載する」と教えたとします。次の見積もりでも使ってほしいなら、その決まりを後から読める場所に残す必要があります。

Anthropicの整理を参考にすると、置き場所は次の四つに分けられます。右の業務例はCAGが作成したものです。

すべてを毎回読ませると、今の仕事に関係のない情報も増えます。逆に、短いメモしか残さなければ、後から「誰が、なぜ決めたのか」をたどれません。

実務では、要点は短く、根拠はたどれるようにするのが出発点です。顧客の決まりを一行で書き、その確認日と元の記録を添える。詳しい経緯が必要になったときに、ログや原本を開ける形にします。

一度使った情報が、すべて次回も役立つとは限りません。「この顧客は簡潔な文章を好む」は繰り返し使えますが、「今日の担当者は外出中」はすぐに古くなります。

残すかどうかは、保存できる量よりも、次の仕事で何を判断するために使うのかで決めます。以下は、問い合わせ対応AIを想定した設計例です。

例えば「値引きできるはず」とAIが推測しただけなのに、「この顧客は値引き対象」と記憶されると、次の回答の前提が変わってしまいます。記録には、結論だけでなく、確認できた範囲を添えたいところです。

Anthropicの研究でも、誤った推測を残す問題や、目の前の状況から読み取れる情報を記憶に重ねて書く問題が扱われています。また、記憶の書き方を細かく固定すれば、いつでも良くなるわけではありません。^[1]

社内AIで最初に決めるなら、「何でも覚える」より、覚える対象を絞る方が運用しやすくなります。顧客別の表記ルール、社内で承認した回答方針、繰り返し間違えた手順など、次にも使う理由が説明できる情報から始めます。

記憶は、一度書けば完成するものではありません。間違った情報が混ざることもあれば、その後の決定で古くなることもあります。

Anthropicは、作業の合間にログやメモを振り返り、訂正・整理する処理を「Dreaming」と呼んでいます。AIが休むという意味ではなく、次の仕事に向けて記憶を整える工程です。研究では、ゲーム中に残した誤ったメモを元の記録と照合して直す例などが紹介されています。^[1]

社内業務に置き換えると、次のような流れです。以下はCAGによる架空の例です。

旧メモ：「A社の納品は、毎回紙で対応する」

元の記録：「今回は紙でお願いします。次回以降はデータ納品です」

訂正後：「今回分は紙。次回以降はデータ納品。依頼の記録を参照」

大切なのは、短くまとめ直すことだけではありません。「毎回」という解釈が原本にあるかを確かめ、適用する範囲を直すことです。

公式の実装例では、終了した会話を読み取り、Wiki形式のメモリに整理して、次の作業では読み取り専用で利用する流れを紹介しています。確認して使う処理と、書き換える処理を分ける参考になります。^[3]

なお、公式資料にある「Dreams」はManaged Agentsの研究プレビューです。同じ考え方を自分で組むCookbookの例とは、更新先などの動作が異なります。すべてのClaude利用者に、同じ自動整理機能が一斉に追加されたという発表ではありません。^[3]

社内で運用するなら、訂正を受け付ける窓口と、更新内容を確認する担当者も必要です。毎晩まとめ直すべきか、仕事の終了時に行うべきかは、情報が変わる頻度と費用を見て決めます。顧客との約束が変わったときは、定期処理を待たずに更新できる導線があると安心です。

Wikiは、複数の資料にまたがる関係を整理するのに向いています。「この契約の例外条件は、どの商品と手順に関係するか」といった問いでは、資料を一つ見つけるだけでは足りないからです。

ただし、Wikiにすべてを移せば、元の資料を探さなくてよくなるわけでもありません。Anthropicは、Stainlessの社内資料を対象とした25問の評価で、検索だけ、Wikiだけ、両方を使う場合を比較しました。^[1]

数値は、特定の資料と25問に対する採点基準の充足割合です。一般的な業務の正答率や、どの会社でも得られる改善率を示すものではありません。Wikiの作成・更新にも処理と費用がかかります。

研究では、単一の資料から答えを探す課題では明確な改善が見られない例や、Wikiが元の資料より大きくなった例も紹介されています。^[1]

この結果を業務設計に生かすなら、Wikiを「関係と要点をつかむ入口」、検索を「根拠や現在の情報を確かめる手段」として組み合わせる考え方が使えます。

公式のKnowledge Wikiサンプルも、変化の少ない資料群に対して繰り返し質問する用途を想定しています。出典を残し、資料間の食い違いを勝手に解消しない作りです。^[4] 商品説明の共通部分はWikiにまとめ、現在の価格や在庫は業務システムから取得する、といった役割分担が考えられます。

最初から全社の情報を覚えさせる必要はありません。問い合わせの一次回答、定例資料の下書き、見積書の確認など、同じ前提を繰り返し使う仕事を一つ選びます。

例えば、問い合わせの一次回答なら、「承認済みの説明と顧客別ルールは残す」「価格と在庫は毎回調べる」「新しい約束は人が確認してから反映する」というところまで決めると、試す範囲が明確になります。

実装の選択肢として、Managed Agentsのメモリストアには、読み取り専用での利用や、変更ごとの版を残す仕組みがあります。2026年11月7日時点でベータの機能です。^[2] こうした仕組みを使う場合も、担当範囲と更新の責任を先に決めておくと、訂正が必要なときに動きやすくなります。

試す際は、普段の質問だけでなく、「前回の決定が変わった」「元のメモが間違っていた」という場合も用意します。検索だけの場合と比べて、根拠を探す時間、回答を直す回数、古い情報が混ざった件数を記録すると、残すべき記憶を見直せます。

Claudeに何を覚えさせるかは、その会社がどの情報を信頼し、いつ更新するかを決めることでもあります。まず一つの仕事で、要点を残し、根拠を探せて、間違いを直せる流れを作る。記憶を増やす判断は、その運用で役立った情報を見てからでも遅くありません。