AIエージェントの記憶は足し続けるより、何を残すかを人が決めて減らす

動画：まさおAIじっくり解説ch「【重要知識】Anthropicの語るAIエージェントの記憶を徹底解説！DreamingやLLM-Wikiなど重要概念も登場！」 YouTubeで観る

2026年9月15日の朝、私はまさおさんのnoteを参考に、記憶の仕組みの改善案をまとめてほしいとAIに頼みました。

AIが当時の環境を測りました。分かったのは、どこに何を聞けばいいかを示す1行が、どこにも無かったこと。取りに行く記憶はwikiに34件、メモの束に956件など、5か所に散らばっていました。毎回読まれる指示は29,373バイトで、MEMORY.mdは144行です。

まさおさんは、Anthropicの記事が記憶を4層に分けていると話します。毎回セッションの先頭に入る層、メモから組み立てたWikiのような層、Claudeが書く個別のメモ、そして作業の全記録。暇な時に記録を読み返して記憶を直し、下の層から上の層へ育てていく工程がドリーミングだそうです。スライドでは人の記憶と並べてあり、海馬で経験を素早く取り込み、寝ている間に一部を長期記憶へ固める形として描かれていました。元になった研究として、LettaとUC Berkeleyのsleep-time computeの名前も書かれています。

一番上の層について、まさおさんの言葉はこうです。

まさおさん（0:58）

ですねこのアンスロピック【Anthropic】の記事の中で記憶のレイヤーていうのをね4層に分けていますと。はいま先頭からあの毎回ねセッションの頭に入ってくるまクラウドMD【CLAUDE.md】であったりだとかメモリー.MD【MEMORY.md】のま先頭であったりだとかていうのを1番上のレイヤーとして持っていて

先頭の層に入るのは、CLAUDE.mdとMEMORY.mdの先頭。

あの時AIが作ったのは、wikiのフォルダで起動して、記録を根拠に答えの文だけを返すAIです。別のAIのチェックを通してから、9月16日までに取り込みました。毎回読まれる側に残したのは、宛先と聞き方を書いた4行だけ。

まさおさんは、記憶を何でも入る箱と見ずに層を引くと、どこに重みが要るか整理しやすい、とも話しています。層に名前があるから、先頭に置く物と、聞きに行けば足りる物を分けて話せるんですよね。整理は、そこからです。

私が仕組みを考える時の前提は、人格、記憶、スキル、実行権限、見た目を混ぜないことです。記憶もその中でさらに置き場ごとに名前をつけて分けます。散らばっていた5か所に足りなかったのは、中身ではなく、どこを開けばいいかの1行でした。

毎回読むのは4行、残りは聞きに行く先。

あなたのAIは、昨日伝えた前提を、今日また聞き返してきませんか？

まさおさんによると、Anthropicの記事は、メモを持たせたら本当に賢くなるのかを、CL-Bench 1.0というテストで確かめています。問い1に答えてメモを書き、正解が示されたら、新しいセッションの問い2へはメモだけを持ち越す。この輪を回し続けると、正答率が上がっていくそうです。

スライドには、モデルごとのメモの質が階段のように並んでいました。仮説を書くが検証しないSonnet 4.6から始まり、Opus 5で初めて学習ループが閉じ、Opus 5.5とSonnet 5.5もそこに並ぶ、という整理です。

その節目を、まさおさんはこう言います。

まさおさん（6:03）

どんどんね、そのメモの部分を引き継いで新しい問いに行くなやつなんですけれども一定ゾーン、つまりオーパス5【Opus 5】ぐらいのところから仮説をメモして確かめて次に使うみたいな学習ループがね、え、閉じたと。

仮説をメモして、確かめて、次に使う。輪をまたいで残るのはメモだけ、というのがこの実験の形でした。メモが主役です。

でね、私が引っかかったのは、正答率よりも、何を持ち越すかのほうです。

私の判断軸に、管理のボールの話があります。AIに委ねたいのは作業だけではなく、約束を覚えて期限まで運ぶ責任まで。私が進捗を思い出して催促したり、同じ品質基準を言い直したりした瞬間、ボールは私の手に戻ってきます。そうなると、本当に大事な判断や創ることに集中できません。

持ち越す価値は、次のセッションが同じ問いを私に言い直させないことにあります。私なら、持ち越すものを、何を言い直させたくないかから選びます。正解の数を増やす前に、聞き返されたくない前提を1行にしておく順番です。

メモリを層で分ける話は、前にClaude Codeのメモリに指摘を残して同じ間違いを防ぐ方法を整理した記事でも紹介しました。そこでもMEMORY.mdは、毎回のチャットの始めに読み込まれる1層目として出てきます。

持ち越す1行を選ぶ物差しは、正答率より手前にあります。

2026年9月、私の毎回読まれる説明書（CLAUDE.md）は約20KBありました。決まりのファイル6本と合わせて、セッションのたびに全部読み込まれる。起動するだけで使うトークンは58,175です。

その月、あるYouTube動画を参考に、仕組みをゼロベースで見直すようAIに頼みました。

まさおさんは、実験の中で記憶の仕方を縛ると、結果が良くならなかったと話します。失敗だけを記録せよ、のように縛った時、スライドではOpus 5の正答率の伸びが0.234減っていました。一方で、古いモデルほど手順の指示が効くそうです。Sonnet 4.6は、答える前に記憶を読む、仮説を検証する、を足すと0.364から0.641へ。Sonnet 5は指示なしでも、10回中9回は答える前に記憶を読む、という話でした。

運用への当てはめを、まさおさんはこうまとめています。

まさおさん（7:00）

ま、細かいルールっていうのはかえって邪魔になります、なるっていうようなね、え、実験結果が得られたみたいな教諭【教訓】がありました。なのでつまりはね、ま、運用へ当てはめていくんやったら、ま、クラウドMD【CLAUDE.md】っていうのは何のための記憶かみたいなのを書くけれども、やっぱハウ【How】の部分、使い方の手順は縛らないようにしましょうと

目的は書く、手順は縛らない。

AIは約5KBの短い版に作り直し、起動トークンは30,086に減りました。見張りの仕組み（hook）は足していません。AIが私に確認の質問を書く入口4か所に、同じ1行を入れただけです。

翌日、その質問が私の言葉に触れる率は、23%から74%（219件中148件）になりました！ ただ、上がったのは入口に入れた1行のほう。説明書を短くした話とは分けて見ています。動画の実験とも、測っている物差しが違います。混ぜません。

私の判断軸では、魂は渡すものではなく込めるもの。目的や守りたいもの、判断軸を磨いたあと、実行は委ねる。説明書で力を使うべきなのは、何のための記憶かを書く所で、手順を並べる所ではないんですよね。

20KBが5KBへ。

私の環境には、AIの記憶に入れる線引きがあります。判断、実測、文脈、失敗のどれかが1行でもあれば入れる。読めば分かる事実だけのものと、認証情報は入れない。

2026年9月28日の週の振り返りでは、1週間分の感情・行動・知識から候補を取り出し、私が選んだものだけを、AIが過去の私の指摘を引くための索引に入れました。ルール4本を入れて、769件が770件に。

まさおさんは、2世代前のモデルとの比べとして、ポケモンの実験を挙げます。スライドでは、Sonnet 3.7は大量のメモを参照しながらバッジ1個、Fable 5は量をぐっと減らしてバッジ4個。メモが約22倍多くても、ゲームは先へ進めなかったそうです。Opus 5.5は、目標と次の手を追う小さなフォルダを書き換え続けて、クリアまで行ったと紹介されていました。

この差を、まさおさんはこう受け止めています。

まさおさん（8:12）

ま、記憶の量が絶対的に多ければ多いほど言うわけじゃないというか、うん。ていうのは、ま、モデルの性能が2世代上がってるけれども1つ言え、あの、言えることなんじゃないかという形で、え、共有がありましたと。

スライドの仕分けは、台所の冷蔵庫の整理に近い感覚で読めました。残すのは判断、失敗から分かったこと、戦略・計画・ルール。書かないのは、READMEや設定ファイルを読めば分かる事実、画面にそのまま出ている状態、すぐ古くなる途中経過です。

で、ここで並べると、少し笑ってしまいます。量を減らしたFable 5が先へ進んだ話の隣で、私の索引は769件から770件へ、1件増えていました。減るどころか、増えたんです。

といっても、足したのは私が選んだ分だけ。入れる基準は判断・実測・文脈・失敗で、動画が残す側に置いた物と向きはそろっています。違いが出るのは、件数ではなく、何を入れないと決めているかのほう。

AIに委ねて、人は積み減らして生き直す。この軸は、記憶にも当てはまります。書く・探す・直す作業はAIに委ねても、何を残すかの線は人が持つ。足す前に、これは読めば分かる事実ではないか、と問う。

AIが、42日前の資料を、今の私の話として使っていました。

2026年9月23日のことです。AIが自分の答えの材料を調べ直すと、使っていたのは8月12日更新の現在地のメモ。9月22日に作られた最新の親設計書には、前回の軸だった「ポータル」「田上」「79ステップ」が一度も出てこなかったんです。

そこで、ルールを2つ足しました。私の現在地は、最新の親設計書を先に読んでから語る。読む前に、更新日を見る。

まさおさんがこの章で話すのは、ポケモン赤の実験で起きた、同じ形の間違いです。まさおさんによると、Claudeはポケモンセンターの入口にある一方通行の段差を誤って記録し、その罠を無視して元のルートへ落ちてしまった。作業の全記録と誤ったメモを突き合わせるドリーミングをしたら、入口へ引き返せるようになった、と話します。

では、直さないまま読み続けたらどうなるのか。

まさおさん（11:12）

ここをね、定期的にじゃあ全体見ながら、あの、一貫性保っておかないと、ま、嘘が混じってたりだとかね、古い情報をそのまま読んでしまったりメタ認知が効かなくてね

まさおさんは、CLAUDE.mdやMEMORY.mdの先頭を読み続けるうちに、嘘が混ざり、古い情報をそのまま読み、メタ認知が効かなくなる、と続けます。だから鮮度を保つ仕組みが要る。

運用の案として挙げていたのは、週に1回、夜にClaude Codeの過去ログとMEMORY.mdを見比べさせ、説明書と記憶を直す形でした。トークンはかかる、とも話しています。

私の件は、ドリーミングではありません。古いメモを読んでいたと分かり、ルールを足したのは人の手です。でも、誤ったメモが毎回の答えに載り続ける形は、段差の罠とそっくりでした！

私なら、直す時も古いメモは消さずに、新しい見え方を上に重ねます。ドリーミングそのものは、今西さんの動画で「ドリーミング」（夜に自動で記憶を直す仕組み）を紹介した記事でも前に取り上げました。

直す時に、元の記録をどう扱うか。その続きは、あとのコラムで書きますね。

私のwikiでは、Resendの作業を聞くと「無い」という答えになる状態でした（9月30日の記録を除いて測った結果です）。

2026年9月30日、wikiの精度を直したいとAIに頼みました。AIが測ると、作業記録966件のうち、wikiが参照していたのは19件だけ。9月17日より前の787件は、そもそも取り込まれていなかったんです。

意味で探す検索を毎回あわせて使い、作業記録3件を補助に足す。その最小の形にすると、Resendの3問は「無い」から3問とも答えられるようになりました（9月30日の記録は除いて測っています）。80問のうち、正解の記録が材料に入った数は68から69へ。答えが分かっている10問の待ち時間は、27.9秒から57.8秒に延びています。

私は、外へは出さず、すぐ戻せる形で本体に入れる方を選びました。

Wikiの話は、動画でいちばん数字が大きい所です。まさおさんによると、Anthropicが買収した会社（スライドの記載はStainless社）の文書約35万ファイル・約4.2億トークン分から、Opus 5のエージェントが128セッションでWikiを作った。スライドでは222ページ・12,893リンクで、Wikiだけでクイズの正答率が13%から48%に上がっています。Wikiと検索を組み合わせると、複数の文章が要る質問で検索だけより強い、とも。KarpathyさんのLLM Wikiにも触れていました。

正直、ここは手放しにはほめないんですよね。

まさおさん（15:12）

ま、書き方誤ってしまうとね、ま、無駄な情報が膨らんだりだとか事実が消えたりだとか、あの、ま、古い情報がそのまま残ってしまったりだとかね、ま、いろんな問題があります。

スライドには、元の文書115KBが203KBに膨らんだ例（1.77倍）が載っています。4体のエージェントが1つのファイルprovisions.mdに書くと、57件の事実のうち41件、72%しか残らなかった。1ページの書き手を1体にすると57/57。MEMORY.mdも、役割ごとにnotes/のファイルを分けてMEMORY.mdから引く形にしたら事実が残った、とまさおさんは話します。

並べてみると、私の件と動画の件は原因が別です。動画は、上書きで事実が消えた話。私のwikiは、材料がそもそも入っていなかった話でした。

だから数字も比べません。13%から48%と、68から69では、測った物が違います。

それでも、通じる線は1本あります。私なら、ファイルにも書き手にも、持ち主を一人決める。関連する話は、記憶の取りに行き方を、記録を探して答えだけ返す道具に任せる形に触れたObsidianの記事でも書きました。

毎回のセッションで、MEMORY.mdの後半が読まれていませんでした。

2026年5月、あるYouTubeを参考に環境の見直しをAIに頼み、MEMORY.mdを測ってもらった時です。74,442バイト・200行。読み込みの上限（先頭200行か25KBの早い方）の約3倍でした！ 私が最近書いたルール35項目が、毎回切り捨てられていたんです。

AIが1項目1行の索引に作り直して、10,853バイト（85.4%減）。進める前に、バックアップを取ってから、と私は頼みました。

まさおさんは、MEMORY.mdの先頭200行はClaude Codeが毎回自動で読み込む、と話します（まさおさん自身は、管理しにくいからとMEMORY.mdをオフにしているそうです）。載るのは200行だけなので、段階的に開く。先頭は索引にして、デザインはここ、デプロイ手順はここ、Wikiはここ、と指し示し、詳しいメモは別ファイルへ。スライドには、320行のMEMORY.mdを30行の索引と別ファイルに分けた例が載っていました。

では、その200行は誰が整えるのか。

まさおさん（17:32）

なんでま、ここの200行をね、え、どう作るかっていうのも実はドリーミングの役割だったりしますし、ま、ここがね、腐ってしまっていると、ま、ま、あの、モデルを惑わしてしまうとか

残る課題として、まさおさんは、いつ走らせるか、ずれた記憶の鮮度、トークンをどれだけ使うか、の3つを挙げます。最後のスライドの題は、運用で今日からやる3手。CLAUDE.mdとMEMORY.mdは索引だけにして、詳細は別ファイルへ。複数のエージェントに1つのファイルを同時に書かせない。READMEを読めば分かる事実は、MEMORY.mdに書かない。

先頭は索引に、という話。私は5月、その先頭に74,442バイトを詰め込んでいました。

で、5月で終わりではないんです。10月7日に自分の記事のために測ると33,157バイトに戻っていて、今日（2026年11月9日）は16,029バイト・147行。その記事には「方針を書くだけでは、短くは保てていません。」と書いています。数字は、戻っては減るを繰り返しているんです。増えて、減って、また増える。

全体を一つにまとめることと、全部を一つのファイルに押し込むことは、別物。先頭は、構造と参照先を持つ索引にする。変わり方や扱う人が違う中身は、別の正本に置く。10月7日の数字は、毎回読まれる入口ファイルを短く保つ公式ページを解説した記事で測ったものです。

16,029バイト・147行。これが今日の、私のMEMORY.mdの大きさです。

まさおさんの動画は、記憶を4層に分け、ドリーミングで下から上を育てる話から始まります。メモの持ち越しで正答率が上がる実験、手順を縛らず目的を書く話、量より何を残すかのポケモン実験。そこから誤ったメモを直す話、Wikiを育てる話と落とし穴へ進み、先頭の200行を索引にする3手で閉じます。

最後にまさおさんが挙げたのは、公式が概念を切って共有したことの大きさでした。

まさおさん（19:38）

で、大きかったのはここでね、わざわざWikiっていう概念を登場させたことですよね。うん。え、ま、Wikiをね、やっぱ使うのモデルうまいなと思っているんで

層に名前がつくと、どこに何を置くかを決められます。減らす線も引けるようになる。

私の手元でも、置き場が5か所に散らばっていたこと、説明書が約20KBあったこと、MEMORY.mdが上限の約3倍だったことがありました。

AIに委ねるのは、書く・探す・直す作業。何を残し、何を書かないかの線は、私が持ちます。

記憶は、足し続けるより、何を残すかを人が決めて減らす。それが、この動画を観て私が受け取った答えです。