エージェントを眠らせて学ばせる — Anthropic ラミス・ムクタが示す、メモリの次に来る dreaming

AI Native DevCon London 2026 / 約 32 分

ラミス・ムクタ / Lamis Mukta · 02:20 「知能だけでは複利で積み上がらない。求められている特定のタスクをこなすには、そのための文脈が要るからだ」

Lamis Mukta - Learning while you sleep: Beyond memory to dreaming - AI Native DevCon June 2026

AI Native DevCon London 2026 でのラミス・ムクタ (Lamis Mukta) 講演、約 32 分。話者は Anthropic の技術スタッフで、研究・製品・市場投入の交点にある Applied AI チームに所属する。主題はコンテキストエンジニアリング —— 生のモデル知能を、持続する製品へ翻訳するための梃子である。講演はこの 1 年の系譜を辿り、本番環境で必要になる原則を示し、最後に dreaming という考え方に至る。

出発点にある観察が、講演全体の前提を作っている。新しいモデルは次々に出て、その都度賢くなる。だが組織やエージェントの環境に実際に配備すると、知能だけでは複利で積み上がらない。なぜなら、その組織で、その仕事をこなすための文脈が別に要るからだ。しかもその文脈は、モデルの知能とはおおむね直交している。最新のモデルであっても、特定の組織で何が成功なのかを箱から出してすぐ知っているわけではない。だからこそ文脈の設計に投資する価値がある、とムクタは言う。モデルが賢くなるほど、文脈はその知能を掛け算する働きをするからだ。

この 1 年の系譜 — 単純で効くものから始める

Anthropic の合言葉として紹介されるのが「単純で、効くことをやる」である。講演が辿る系譜は、わずか 1 年ほどの出来事だ。

出発点は CLAUDE.md だった。コードベースの歩き方、組織の事情、利用者の好みを書いた markdown を、セッション冒頭でモデルの文脈に流し込む。これがムクタの言葉では「不合理なほど効果的」だった。一方で限界も見えた。冒頭で丸ごと注入する方式では、大事な指示を書き足すほどファイルが長くなり、 context bloat (文脈の膨張) を起こす。それでも「人間が読めて、エージェントも人も書き込める単純な markdown」という形自体は、きわめて有効だと確認された。

次に試されたのがメモリツールである。エージェント自身に、いつ読み・書き・更新するかを委ねる。これはセッションの内側で起きる。自律性はよく機能した、というのが評価だ。

三番目が skills で、ここで progressive disclosure (段階的開示) という考えが入る。エージェントが常に見るのはファイル冒頭の数行だけで、本体にはいくら詳細を書き込んでもよい。深い詳細と、文脈を膨らませないことが両立する。ムクタはこれを本棚にたとえる。部屋に本棚があり、誰かが話しかけてくるたびに背表紙を眺めて、話題に関係しそうな一冊があれば抜き出して読む。フランス語で話しかけられたなら仏語辞典を引けばよく、学校で 7 年間フランス語をまじめに聞いていなくても、会話の途中で必要な文脈だけを手に入れられる。

そして現時点の到達点として示されるのが、ファイルシステム型メモリだ。メモリを特別な仕組みにせず、ただのファイルシステムとして扱う。 markdown で埋め、エージェントには Bash や Grep といった通常の道具で検索させる。読み書き専用のツールを細かく決め打ちしないほうが、エージェントはうまく使う。そして検索そのものが段階的開示の役割を果たす。まとめると、形式は markdown、メモリは大きくなってよいがすぐ索引して探せるようにする、書き込みには自律性を与える —— この 3 点になる。

着眼点

本番で壊れる場所と、 4 つの原則

きれいな設計は、規模を上げると別の問題に当たる。講演はここを率直に扱う。多数のエージェントが同時に働き、長時間走り、コードベースが複雑になる環境では、いくつもの問題が現実に起きてきた。複数のエージェントが同じメモリファイルへ同時に書こうとしたらどうするか。 1 体のエージェントが問題にぶつかり、組織全体が読んでいる共有の文脈へ書き込んでしまったら —— そこに誤りがあれば、それは全エージェントへ拡がる。人間とエージェントが一緒にメモリを育てるとき、何が起きているかをどう追うか。そしてメモリは古びる。過去に正しかったことが今は正しくないかもしれず、誤って書かれたかもしれず、プロンプトインジェクションによるメモリ汚染で悪意ある内容を書き込まれたかもしれない。

そのための原則が 4 つ示される。第一に versioning (版管理) 。版を保存して追跡と巻き戻しを可能にし、その更新がどの transcript に基づき、誰が行ったのかまで残す。第二に concurrency (同時実行制御) 。採用されているのはハッシュ方式で、エージェントは更新を書く前にハッシュを取り、差分を作り、書き込む直前にもう一度ハッシュを取る。 2 つが一致しなければ、その間に別の更新が入ったということなので書き込まない。メモリを取り直し、差分を作り直して、もう一度試す。封をする前と後で指紋を照合するようなものだ。

第三に permissioning (権限設計) 。メモリには階層がある。組織全体で共有する知識から、特定の組織や横断領域のもの、そしてエージェント個別の作業メモまで。 1 体のエージェントが組織全体の文脈を勝手に更新できるべきではないので、そこは読み取り専用にし、自分の作業メモには書き込みを許す。第四に portability (可搬性) 。手間をかけて育てた文脈は、複数の製品面や複数のシステムから使えるべきなので、きれいな API で外から扱える形にしておく。

セッションの内側では届かないもの

ここまでの仕組みが機能すると、実際に効果が出る。 2 回目に同じ仕事をするとき精度が上がる。何が失敗したかをメモリに書き留めてあるからだ。それが二次的に速度と費用にも効く。一度で仕上げられる割合が増え、使うトークンが減る。そして開発者の側は、エージェントが背後で学び続ける前提に立てるぶん、製品の仕事に集中できる。

それでも次の隘路が現れる。 in-band memory (セッション内メモリ) の限界である。理由は 2 つ挙げられる。 1 つは焦点と資源の分裂だ。エージェントには目の前の仕事を仕上げてほしいのに、同時に将来の自分を助けるためのメモリ整備にも投資してほしい。これは難しい最適化になる。試合中の選手に、プレーしながら次回のための練習メニューも書けと求めるようなものだ。

もう 1 つは可視性の限界である。エージェントに見えているのは自分のセッションの中だけなので、セッションをまたいだパターンが見えない。同じ誤りが何度も繰り返されて人間が苛立っていても、エージェントの側は毎回新しい文脈窓から始まるので、その苛立ちの理由が分からない。複数の環境で艦隊のようにエージェントを走らせている場合、他のエージェントがどんな失敗をしているかも見えない。

dreaming — セッションの外で、メモリ自体を育てる

そこで導入されるのが out-of-band (セッション外) の処理、すなわち dreaming である。講演では学校の比喩で説明される。多くの生徒が課題を提出し、教師が採点し、校長が全体を見る。この仕組みが現実に存在するのには理由がある。学びを助けることに専念できる人がいると効果的であり、全体を見渡してパターンに気づき、カリキュラム自体を修正できる立場の人がいるとさらに効果的だからだ。

仕組みはこうなる。既存のメモリ群と、一定期間のエージェントのやり取りの transcript 群を、まとめて 1 体のエージェントに渡す。そのエージェントは transcript を読み、メモリを照合し、改善できる箇所のパターンを探し、メモリの更新案を出す。重要なのは、見るのがエージェントと利用者のやり取りだけではないことだ。ツール呼び出しやその他のメタデータまで精査する。エージェントの性能を左右するのはそこだからである。

学校の比喩に戻すと、校長が全答案を読んで、地理の生徒全員が同じ問題を落としていることに気づく。メモリを調べると、その単元がカリキュラムから丸ごと抜けていた。だから翌日にはその情報が入っている。あるいは数学の答案が全員同じ形で間違っていて、度数で答えるべきところをすべて弧度で出している。電卓の設定を直す指示を配ればよい。エージェントの世界では、これは transcript の中でツール設定に問題があることに気づくのに当たる。艦隊全体・組織全体に効くものもある。全員がダッシュ記号を使いすぎているのが気に入らないなら、組織全体の文脈にその一項を足せばよい。

実装は、 orchestrator + sub-agent fleet の形をとる。統括役が下位エージェントの艦隊を展開して transcript を分析させ、返答をまとめて、メモリを変えるに値するだけ広く見られるパターンかを判断する。そして個別の変更案を出す。このとき、そのパターンが観測された transcript の実例と、どれくらい頻繁に起きているかの統計を添える。採否を決めるのは人間である。加えて、何を重要と見なし何を見なさないかを指示して、メモリづくりと dreaming の両方を組織に合わせて方向づけられる。

費用の懸念には、講演の中で答えが用意されている。追加の資源を投じることにはなるが、メモリが効いていればエージェントは一度で仕事を仕上げやすくなり、必要な情報を持って動けるぶん費用は下がる。このとき、セッション内のメモリと dreaming は並行して走る 2 つの過程になる。前者は反映が速く、後者は視野が広く専用の資源を持つ。

動画の構成

(00:00) 導入、 Applied AI チームの立ち位置、スタートアップと働く場所から見えるもの
(01:12) 生のモデル知能を持続する製品へ翻訳する梃子としてのコンテキストエンジニアリング
(02:07) 知能だけでは複利で積み上がらない、文脈は知能と直交する
(03:23) 「単純で効くことをやる」、 CLAUDE.md から始まった 1 年の系譜
(04:08) 冒頭注入方式の限界 (文脈の膨張)、それでも markdown という形は有効
(04:41) メモリツール、エージェントに読み書きの判断を委ねる自律性
(05:30) skills と段階的開示、本棚と仏語辞典の比喩
(07:12) 現時点の到達点、メモリをファイルシステムとして扱う
(08:07) 学びの要点 3 つ (markdown / 大きくしてよいが索引と検索 / 書き込みの自律性)
(08:37) 本番規模で現れる問題 (同時書き込み、組織全体への誤り伝播、人間との協働、陳腐化とインジェクション)
(10:25) 原則 1 versioning、何に基づく更新か・誰が行ったかまで残す
(10:57) 原則 2 concurrency、書き込み前後のハッシュ照合と再試行
(11:55) 原則 3 permissioning、組織全体は読み取り専用・作業メモは書き込み可
(12:50) 原則 4 portability、きれいな API で複数の面から使えるように
(13:56) 実際に得られる効果 (精度、速度と費用、開発者の集中)
(15:05) 次の隘路 = セッション内メモリの限界 (焦点の分裂、可視性の欠如)
(16:55) セッション外での整備という発想、学校の比喩
(18:06) dreaming の定義 — メモリに対する二次的な過程
(18:36) 仕組み (メモリ群 + transcript 群 → パターン抽出 → 更新案)
(19:44) 具体例 (欠落した単元、弧度と度数、ツール設定の不具合、組織全体の文言)
(21:43) 実装 (orchestrator + 下位エージェントの艦隊、根拠の実例と統計を添えた提案、採否は人間)
(23:42) 2 つの過程の並走、費用は下がりうるという説明
(26:42) まとめ、単純なものから始めて規模に応じてガードレールを足す
(27:16) 質疑 (メモリ実装の選択肢、権限と dreaming の整合、「これはデータベースの再発明では?」)

関連リソース

ラミス・ムクタ

Lamis Mukta

Anthropic 技術スタッフ / Applied AI チーム — フロンティアでエージェントを作るスタートアップを支援

用語集

コンテキストエンジニアリング: モデルに与える文脈を設計・管理する技術領域。何を・いつ・どれだけ載せるかを扱う。モデルの知能とはおおむね直交しており、知能が上がるほど文脈がそれを掛け算する、という位置づけ。
CLAUDE.md: Claude Code とともに登場した、エージェントへの指示を書く markdown ファイル。セッション冒頭でモデルの文脈に注入される。単純だが「不合理なほど効果的」だった一方、長くなると文脈の膨張を招く。
progressive disclosure (段階的開示): 全部を最初から載せず、必要な時に必要な分だけ読み込ませる設計。 skills では冒頭の数行だけを常時見せ、本体は呼ばれた時に読む。部屋の本棚から、話題に関係する一冊だけを抜き出すのに近い。
ファイルシステム型メモリ: メモリを専用の仕組みにせず、ただのファイルシステムとして扱う方式。 markdown で埋め、 Bash や Grep のような通常の道具で検索させる。検索が段階的開示の役割を果たす。現時点の到達点として示される。
versioning (版管理): メモリの更新を版として保存し、追跡と巻き戻しを可能にする。その更新がどのセッション・どの transcript に基づくのか、誰が行ったのかも記録する。
concurrency (同時実行制御): 多数のエージェントが同一メモリを扱う際の競合対策。ハッシュ方式では、更新を書く前後でハッシュを取り、一致しなければ書き込まずにメモリを取り直して作り直す。
permissioning (権限設計): メモリの階層ごとに読み書き権限を分ける設計。組織全体の知識は読み取り専用、エージェント個別の作業メモは書き込み可、といった切り分けを行う。
portability (可搬性): 育てたメモリを複数の製品面・複数のシステムから使えるようにしておくこと。きれいな API を通じて外から扱える設計にする。
in-band / out-of-band: in-band はセッションの内側でエージェントがメモリを読み書きすること。反映は速いが、目の前の仕事と資源を奪い合い、他セッションが見えない。 out-of-band はセッションの外で独立した資源を割り当てて走らせる処理で、 dreaming がこれにあたる。
dreaming: メモリに対する二次的な過程。セッションの外で、まとめて非同期に走る。過去の transcript 群とメモリ本体を突き合わせ、繰り返される失敗やメモリの欠落・陳腐化を見つけ、更新案を出す。統括役が下位エージェントの艦隊を展開して分析させ、根拠の実例と頻度の統計を添えて提案し、採否は人間が決める。
プロンプトインジェクションによるメモリ汚染: 悪意ある入力によって、エージェントに誤った内容をメモリへ書き込ませる攻撃。メモリは後続の全セッションに効くため、汚染が持続的に効く。自律的なメモリを本番で運用するにはガードレールが要る理由の 1 つ。