homulaエージェントを本番に出した企業が、しばらくして気づく欠陥がある。「昨日学んだことを、今日は覚えていない」。セッションをまたぐと、前回つまずいた手順も、現場で通じる固有の呼び名も、きれいに忘れている。コンテキスト窓を広げれば直る話に見えるが、窓は「一度の会話に持ち込める作業机」であって、長期の記憶ではない。homula もエージェントの実装でこの壁に何度もぶつかってきたが、2026年11月6日、Anthropic が記憶という曖昧な概念を設計可能な部品に分解する技術記事を公開した（The components of agent memory、著者 Lance Martin）。本稿はこれを、企業のエージェント設計という視点で読み解く。
「記憶」をコンテキスト窓と切り分ける
まず定義を押さえる。Anthropic は agent memory を「Claude が経験から得て、セッションをまたいで後から読める文脈として保存される知識」と位置づける。ここから明確に外されているものが3つある——学習（重みの変化）、インコンテキスト学習（一度の会話内の知識）、そしてコンパクション（古い発言を要約で置き換える処理）だ。
この線引きは実務的に重要だ。コンテキスト窓を広げる、要約で圧縮する、といった施策は「一度のセッションを長く回す」ための工夫であって、記憶ではない。記憶とは、セッションが終わっても外部に残り、次回読み込める知識を指す。Anthropic が公開した記憶ツールも、この発想に立つ——Claude がファイルを作成・読取・更新・削除でき、そのディレクトリが会話をまたいで永続する仕組みだ（context management）。記憶は魔法ではなく、書いて・残して・読み返すという素朴な操作の積み重ねである。
記憶の4層——どこに何を置くか
記事の核心は、記憶を下から上へ4層に積む階層モデルだ。
| 層 | 中身 | 役割 |
|---|---|---|
| ① トランスクリプト | 作業の全イベントを記録した検索可能なログ | 「何が起きたか」を遡れる土台 |
| ② メモリノート | セッション中に書き留める重要な気づき（ファイル群） | 顕著な事実・失敗・ルールを残す |
| ③ メモリ表現 | wiki のように相互リンクした構造化ページ | 断片を主題ごとに整理した知識 |
| ④ 注入コンテキスト | 毎セッションの冒頭に必ず読み込む材料 | 常に効かせたい最小限の前提 |
下層ほど生で網羅的、上層ほど凝縮され常時効く。注意すべきは、上層は小さく保たねばならないという制約だ。注入コンテキストに誤りが混じれば全セッションに伝播し、指示文が長くなるほど遵守率は落ちる。Anthropic 自身の例では、Claude Code の自動メモリは MEMORY.md の先頭200行（または25KB）だけを読み込み、そこを索引として使う。詳細は下の層に押し下げ、上層にはリンクだけを残す——これが設計の勘所になる。
「ドリーミング」——眠っている間に記憶を整える
4層をただ積むだけでは、記憶は失敗やノイズを溜め込んで腐る。そこで導入されるのがドリーミング（dreaming）だ。人間が睡眠中に経験を長期記憶へ定着させるように、エージェントもオフラインでトランスクリプトと既存の記憶を振り返り、誤りを正し、ノートを作り、表現を組み立て、何を注入層に昇格させるかを整える。複数セッションを横断して共通パターンを見つけることも、特定の目的に向けて調整することもできる。ドリーミング自体は2026年前半に Claude の Managed Agents 向けに先行導入されており、今回の記事はその設計思想を体系化したものだ。
ドリーミングの効き目を、記事は具体例で示す。Mt. Moon（ポケモン赤での検証）では、Claude が「ポケモンセンターの位置」を誤って記録し、一方通行の崖に3度落ちて先へ進めなかった。ドリーミングがそのノートをトランスクリプトと照合して訂正した結果、洞窟に戻って目的地へ到達できた。訂正しなかった走行は、最後まで山を越えられなかった。記憶は書けば終わりではなく、間違えたら直す工程までが記憶だという示唆だ。
記憶は「予測」である——何を書き、何を書かないか
記事が繰り返し強調するのは、記憶を書く行為は「これは後で役に立つ」という予測だという視点だ。だから何でも書けばよいわけではない。別のポケモン検証では、Sonnet 3.7 が225フォルダに413個のメモリファイルを量産したがバッジは1つ、対して Claude Fable 5 は global.md などわずか約10個に絞ってバッジ4つを得た。画面に映っている揮発的な状態を書き残すのは冗長で、戦略や検証済みのルールこそ書く価値がある——人間が「覚えておくべきこと」を選ぶのと同じ判断だ。
効果はベンチマークにも表れる。データベース課題（CL-Bench 1.0）で記憶の学習ループ（失敗を記録→仮説を立て→検証→ルール化）を回すと、平均報酬は Opus 5.5 で0.655→0.838へ上がった。興味深いのはsteering（誘導）の塩梅だ。Anthropic は「記憶が何のためかは伝えてよいが、どう使うかまで固定すると逆効果」と報告する。「失敗だけ記録せよ」といった硬い規則は強いモデルの伸びを削り（Opus 5 は0.234低下）、一方で旧世代の Sonnet 4.6 は「まず記憶を読み、仮説を明示的に検証せよ」と促すと0.364→0.641とほぼ倍増した。記憶の与え方はモデルの成熟度で変える、という実装上の教訓になる。
RAGの延長ではない——wikiという「社員の成長」
企業がまず気になるのは「それは RAG と何が違うのか」だろう。記事の wiki 検証が答えになる。コードベース（Stainless、約35万ファイル・約4.2億トークン）に対し、128回のドリーミングで wiki を育てると、wiki 単独の正答は**13%→48%**へ伸びた。さらに **wiki＋検索は61%**に達し、検索単独の53%を上回りつつ、1問あたり約2万トークンを節約した。Anthropic はこの成長を「新入社員の知識が、経験を積んだ社員へ育つようなもの」と表現する。
ただし万能ではない。法務文書の検証（Harvey LAB）では、wiki が効いたのは複数文書を横断する問い（87% 対 検索73%）で、単一文書の単純な参照にはほとんど効かなかった。あるケースでは wiki が元コーパスの1.77倍に膨らみ、リンクのない孤立ページを抱えた——「現実と同じ大きさの地図」という寓話そのものだ。記憶は検索を置き換えるのではなく、検索の上に重ねる層であり、横断的な理解が要る業務ほど効く、という使い分けが見えてくる。
RAG（都度の検索）と記憶（蓄積された知識）は競合ではない。トランスクリプト検索を土台に置き、その上に整理された表現を重ねる——「検索＋記憶」の二段構えが、トークンも節約しながら精度を上げる現実的な構成だ。
企業にとっての含意——記憶は『統制対象』になる
ここから先が、homula が企業に強調したい論点だ。記憶を持つエージェントは、裏を返せば「組織の知識を勝手に書き溜め、全セッションに効かせる仕組み」でもある。だから記憶は、精度の話であると同時に統制（ガバナンス）の話になる。記事の検証はその勘所を具体的に示している。
- 注入層は小さく、監査可能に：全セッションに効く上層に誤りが混じれば被害は全体に広がる。ここは最小限・索引化し、何が常時効いているかを可視化する。
- 共有テーブルへの書き込みは壊れる：契約条項の課題では、複数の書き込みが同じ表を上書きし合い、57件中**41件（72%）**しか残らなかった。契約ごとに1ページ・原文を逐語で引用する設計に変えると57件すべてが残り、基準網羅は100%になった。「誰の記憶が、どこに、どう書かれるか」の分離設計が品質を決める。
- 記憶は書き換わり続ける：予測が外れ、環境が変われば記憶は古びる。変わりやすい情報に絞ってドリーミングを回し、アクセス頻度に応じて更新頻度を調整する運用が要る。
つまり記憶は「置けば賢くなる機能」ではなく、誰が・何を・どこに書き、いつ訂正し、何を全体に効かせるかを設計・監査し続ける対象だ。データ主権や権限分界の観点でも、記憶に何が蓄積されるかは監査ログと同じ重みを持ち始める。
homulaの観点：記憶を『統制付きの層』として実装する
homula はエンタープライズ向けの AIエージェント・インテグレーターとして、n8n / Dify / LangGraph や MCP を使い、企業システムにエージェントを安全につなぐ設計を手がけてきた。今回の4層モデルは、私たちが実装で重視してきた「生で残す層と常時効かせる層を分け、昇格と訂正を運用で回す」という考え方とそのまま重なる。重要なのは、記憶を便利機能として足すのではなく、統制できる形で層を設計することだ。
接続基盤の Agens（MCP を活用し、200以上のツールと構築ゼロで接続）が、トランスクリプトや業務データという「下の層」をエージェントの手の届く範囲に広げる。そして Agens Control が、記憶の統制側——誰がどの記憶を書き・読めるかの権限（RBAC）、不可逆な更新への承認、そして5年分の監査ログ——を押さえる。記憶を「どこかに溜まるブラックボックス」にせず、書き込みと昇格を統制レイヤーの上で可視化しておくことが、記憶を事故なく育てる前提になる。
進め方としては、(1) まずトランスクリプト（検索可能なログ）を土台として確実に残す、(2) メモリノートは「失敗・ルール・固有の呼び名」など予測価値の高いものに絞る、(3) 注入層は最小の索引に留め、訂正（ドリーミング相当）を運用に組み込む——という順序が現実的だ。自社のどの業務から記憶を蓄積させるべきか判断しづらい場合は、業務棚卸しからプロトタイプ構築・ROI試算までを3〜5日で回す AIエージェント・ブートキャンプで、小さく記憶の層を立ち上げながら見極めるのが近道になる。
まとめ：記憶とは、書いて・直して・小さく効かせること
Anthropic の今回の記事は、「エージェントが賢くなる」という抽象論を、トランスクリプト→ノート→表現→注入という積める部品と、ドリーミングという訂正工程に分解してみせた。コンテキスト窓を広げる話でも、RAG を置き換える話でもない。記憶とは、予測価値のあるものを書き、間違えたら直し、常時効かせる層は小さく保つという運用の設計だ。
そして企業にとって、記憶は精度向上の機能であると同時に統制対象でもある。何が全セッションに効き、誰がそれを書き換えられるのか——そこを設計・監査できる形で記憶を層に分けておけば、エージェントは「昨日を忘れる道具」から「経験を積む社員」へと育っていく。新入社員が熟練へ育つのに時間と仕組みが要るように、エージェントの記憶もまた、設計された層と訂正の運用があってはじめて資産になる。
自社のエージェントに、どの業務から記憶を持たせ、どう統制するか。記憶の層と訂正・監査の設計から、一度棚卸ししてみませんか。