title: "LLMに「睡眠」を与えるGoogleのSleepフレームワーク：継続学習の仕組みと、現時点で言えること"
emoji: "😴"
type: "tech"
topics: ["ai", "llm", "continuallearning", "google", "論文解説"]
published: true
---

背景と課題：デプロイ後のLLMは「学ばない」

運用中のLLMは、基本的に学習時点の知識で止まっている。新しい情報を取り込む方法は大きく2つあるが、どちらにも弱点がある。

文脈内学習（ICL）：プロンプトに情報を入れて使う方法。セッションが終わると情報は消える。
継続的なパラメータ更新：追加学習で重みを書き換える方法。新しい知識を入れるほど、古い知識を忘れる「破滅的忘却」が起きやすい。

Google ResearchのAli BehrouzとVahab Mirrokniは、2026年10月27日のブログで、この両者の間を埋める「Sleepフレームワーク」を紹介した（※1）。論文は2026年6月にarXivへ投稿され、同年7月に改訂されている（※2）。本稿は、ブログと論文の要旨に基づいて仕組みを整理し、現時点で何が言えて、何が言えないかを切り分ける。

なお、筆者はこの手法を実装・再現していない。公開されている実装も、ブログからは確認できなかった（※1）。以下の数値はすべて、著者らが報告した値である。

1. なぜ今注目されているのか

Hacker Newsでは、このブログが264ポイント・54コメントを集めた（2026-11-02時点、ダイジェスト経由・※3）。同日に1,700ポイントを超えるモデル公開が並ぶ中での数字であり、派手さはないが、研究系の話題としては目立つ位置にある。ポイント数は第三者ダイジェストから取っており、HN本体では再確認していない。

注目の理由は、実務側の悩みと一致しているからだろう。社内のナレッジ、日々変わる仕様、個人の作業履歴などを、モデルが「覚えたまま」使えるなら、RAGやメモリ層に頼っている現在の設計が変わる可能性がある。

2. 仕組み：覚醒と睡眠の2段階

図1：ブログの記述から筆者が作成した処理の流れ

人間の学習に着想を得て、モデルの動作を「覚醒（Active）」と「睡眠（Sleep）」に分ける。睡眠はさらに「記憶の固定化」と「ドリーミング」に分かれる（※1）。

2.1 覚醒フェーズ

入力を処理しながら、新しい情報を高速で更新される短期記憶に保存する。ここは、通常の推論に近い。

2.2 睡眠フェーズ（a）記憶の固定化

短期記憶を長期のパラメータへ移す段階である。ブログによると、3つの手順がある。

パラメータ拡張：あらかじめ確保しておいたMoEのメモリブロックを開放し、低ランクの新しい専門家を、低頻度で更新されるメモリへ統合する。これは「Hope」と呼ばれるアーキテクチャを使う。
知識のシーディング：短期記憶を、拡張した領域へ蒸留する。手法は一般化知識蒸留（GKD）に強化学習ベースの模倣学習を組み合わせたもので、教師が生成した接頭辞の続きを完成させる報酬（レーベンシュタイン距離に基づく）を使う。
シナプスの刈り込み：固定化が終わったら、一時的に使った高頻度パラメータをリセットする。

論文の要旨では、これを「小さなモデルの記憶を大きなネットワークへ移す上向きの蒸留」と表現している（※2）。容量を足しながら、既存の知識を保つ設計だと読める。

2.3 睡眠フェーズ（b）ドリーミング

固定化の後に、モデル自身が合成データを作って復習する段階がある。

ランダムな専門家選択：合成データを生成するとき、MoEのルーターが通常は選ばない専門家をランダムに活性化する。
選別つきの復習：生成したサンプルを、勾配に基づくデータ選択で絞り込む。
RLによる改良：評価の高いサンプルで教師ありファインチューニングを行い、下流の性能が上がるかを確認する。

人間の夢が、記憶の整理と汎化に関わるという見方になぞらえた設計である。ここで重要なのは、人手の教師データなしで復習のカリキュラムを自分で作る点だ（※2）。

3. 報告されている結果

図2：Sleepを適用したモデルの数学推論スコア（報告値）

ブログが挙げる結果は次のとおりである（※1）。

領域	評価	報告値
数学推論	AIME 24 / AIME 25 / HMMT 25	79.2% / 69.0% / 46.1%
事実知識	SQuAD（単一タスク）	48.9%
事実知識	継続的事前学習（CPT）	46.2%
長文脈	BABILong	10Mトークンまで近いスケーリングと記載
継続的翻訳	ManchuとKalamang	複数段階でも性能低下がほぼゼロと記載

比較対象は、SFT、GRPO、オンポリシー自己蒸留（OPSD）、SEAL、Cartridges、Titansなどである。ブログは「上回った」と書いているが、比較先の数値は載せていない。さらに、土台のモデル名も明記されていない（※1）。したがって、改善の大きさは、この記事からは判断できない。

継続的翻訳の結果は、特に面白い。ManchuやKalamangのような、事前学習データにほとんど含まれない言語を段階的に学ばせても、前の段階の性能が落ちにくいという報告である。破滅的忘却への強さを示す実験として、筋が通っている。

4. 既存アプローチとの比較

図3：概念整理の表。導入コストは筆者の推定であり、論文の値ではない

観点	ICL / RAG・メモリ層	継続的ファインチューニング	Sleep
知識の置き場所	モデルの外	パラメータ（上書き）	パラメータ（拡張した領域）
忘却	セッション終了で消える（ICL）。外部記憶は残る	起きやすい	起きにくいと報告
追加の学習が必要か	不要	必要	睡眠フェーズが必要
実装の難しさ	低い	中	高い（専用アーキテクチャ前提）
今日から使えるか	使える	使える	公開実装は未確認

最後の行が重要である。Sleepは「Hope」アーキテクチャとMoEの事前確保を前提にしているため、既存のLLMへ後から載せられるのかは、現時点で分からない。

5. 設計上のトレードオフと、読むときの注意

5.1 睡眠のコスト

睡眠フェーズは、蒸留、合成データ生成、選別、ファインチューニングを含む。つまり「いつ眠らせるか」「どれだけ計算を使うか」という運用上の問題が出る。ブログは、このコストを数値で示していない（※1）。

5.2 何を覚えさせるか

固定化の対象を選ぶ仕組みが重要になる。誤った情報、悪意ある入力、機密情報も、長期記憶に固定化されてしまう可能性がある。ブログに制約の記述はなく、安全性の議論は確認できなかった（※1）。実務で考える場合、固定化の前に検証や削除の手段が要る。

5.3 過大評価のチェック

比較先の数値が示されていない。
ベースモデルが不明で、再現条件が分からない。
公開実装を確認できない。
著者らの自己報告であり、第三者による再現が見当たらない。

これらは論文を貶める理由ではない。ただし、「GPT-4やTitansを上回った」という表現を、そのまま受け取るのは早い。

6. 実務への影響：今できること

Sleepそのものは、まだ試せない。それでも、設計の考え方は、今の実装に取り入れられる。

短期と長期を分ける。 会話中の情報（短期）と、確定した知識（長期）を、別の層で管理する。
固定化の前に選別する。 外部メモリに書き込む前に、重複排除と検証を入れる。
定期的に整理する。 「睡眠」に相当するバッチ処理で、メモリを要約し、古い情報を刈り込む。

たとえば、コーディングエージェントのメモリ層は、すでにこの方向で進化している。直近のGitHubトレンドには、セッション履歴を圧縮して再注入するOSSが並んでいる。外部で行う「疑似的な睡眠」と、パラメータ内部で行うSleepは、似た課題への異なる解答として並べて見られる。

6.5 実験結果の読み方：何が「強い証拠」で、何が「弱い証拠」か

報告された結果を、証拠の強さの観点で並べ直してみる。

比較的強い証拠になり得るもの。 継続的翻訳の実験は、事前学習にほとんど含まれない言語（ManchuとKalamang）を使っている。モデルがもともと知っている知識で正解してしまう可能性が低く、「新しく覚えたこと」を測る設計として筋が良い。複数の段階を通して性能低下がほぼゼロという報告が本当なら、破滅的忘却への耐性を示す明確な材料になる（※1）。

解釈に注意が必要なもの。 AIMEやHMMTのような数学推論の数値は、モデルの基礎能力や評価方法に強く左右される。Sleepの効果と、ベースモデルの強さを切り分けるには、同じベースモデルでSleepあり・なしを比べた数値が必要だが、ブログには比較先の数値がない（※1）。SQuADのスコアも同様で、48.9%という値は、比較対象がなければ高いとも低いとも言えない。

確認できていないもの。 長文脈のBABILongでは、10Mトークンまで近いスケーリングという記述があるが、具体的な数値は示されていない。ここは、論文の本文や付録で確認すべき点である。筆者は論文の全文を精読していないため、要旨とブログの範囲での判断にとどまる。

この整理から言えるのは、「方向性は面白く、検証設計の一部は信頼できそうだが、効果の大きさを断定する材料は、まだ足りない」ということである。

6.6 エンジニアの設計に取り入れるなら

パラメータを書き換えられない立場の開発者でも、Sleepの発想は、外部メモリの設計に応用できる。次のような設計を考えてみてほしい。

書き込み経路を二段にする。 会話中の情報は、まず一時的なバッファ（短期記憶）に置く。そこから長期の記憶へ移すのは、検証を通った情報だけにする。
夜間バッチで整理する。 1日の終わりに、バッファの内容を要約、重複排除、矛盾の検出にかけて、長期記憶へ反映する。これが、疑似的な「睡眠」にあたる。
復習用のサンプルを作る。 長期記憶の内容から質問と回答の組を自動生成し、記憶が壊れていないかを定期的にテストする。ドリーミングの「自分で教材を作る」発想の応用である。
刈り込みを前提にする。 古くなった情報、使われない情報は、削除や圧縮の対象にする。記憶は増やすだけでなく、減らす仕組みも要る。

もちろん、これはパラメータ内部で行うSleepとは別物である。外部メモリは、内容を人間が見て直せるという大きな利点がある。パラメータに固定化された知識は、間違いを見つけても、取り除くのが難しい。この違いは、実務で採用を判断するとき、大きな意味を持つ。

6.7 RAG・メモリ層との使い分けをどう考えるか

Sleepが実用になったとしても、RAGや外部メモリが不要になるとは限らない。両者は、得意な領域が違うからである。

観点	外部知識（RAG・メモリ層）	パラメータへの固定化（Sleep）
更新の速さ	即時に反映できる	睡眠フェーズを経る必要がある
訂正のしやすさ	該当の文書を直せばよい	取り除く方法が難しい
出典の提示	参照元を示せる	示しにくい
推論時のコスト	検索と文脈の長さに依存	検索が不要になる可能性
向いている知識	頻繁に変わる事実、監査が必要な情報	繰り返し使う手順や、言語・ドメインの癖

つまり、変わりやすく、出典が要る情報は外部に置き、安定していて繰り返し使う知識だけを固定化する、という分担が自然だと考える。これは筆者の見立てであり、論文が示した結論ではない。

7. 今後の展望

注目点は3つある。第一に、公開実装と技術的な追試が出るか。第二に、Hopeアーキテクチャ以外のモデルへ適用できるか。第三に、固定化の安全性、つまり悪い知識を覚え込ませない仕組みが示されるかである。この3点が揃えば、RAGと並ぶ選択肢になり得る。逆に、どれも出てこなければ、研究の一例にとどまるだろう。

読者への問い：あなたのシステムに「睡眠」はあるか

最後に、手元のシステムを見直すための問いを置いておく。エージェントやチャットボットが、日々の対話から得た情報を、どこに、いつ、どんな基準で保存しているか。保存した情報は、いつ整理され、いつ捨てられるか。誤った記憶が入ったとき、誰がそれを見つけて直せるか。

多くの実装では、記憶は「足されるだけ」で、整理や検証の工程がない。Sleepは研究段階のアイデアだが、「覚えること」と「整理すること」を分けて設計する視点は、今日の実装にそのまま持ち込める。まずは、メモリ層に定期的な整理の工程を一つ足すところから始めてはどうだろうか。

まとめ

SleepフレームワークはLLMの動作を覚醒と睡眠に分け、短期記憶をMoEの拡張領域へ蒸留し、さらに合成データで復習する。数学推論、事実知識、長文脈、継続的翻訳で良い結果が報告されている。ただし、比較先の数値、ベースモデル、公開実装が確認できず、再現は未検証である。今は、設計思想を自分のメモリ層に応用しつつ、追試を待つのが妥当だと考える。

※本記事の記載内容は筆者個人の見解であり、所属する会社や組織の立場や方針とは一切関係ありません。

筆者情報

【Tomcat-周】｜AI/AX/AIセキュリティ専門家

AI戦略洞察、AI駆動開発の方法論設計と現場で回る仕組みづくりをしています。
noteで戦略洞察 / Zenn・Qiitaで技術・方法論を書いています。
AIセキュリティ・AIコンサル・AIエージェント開発・AI活用・AI駆動開発教育、AI人材育成サービスを一体で提供。

X: @ZY20240528
LinkedIn: tomcat-zhou
Facebook: zhou yi
note: tomcat-周

参考資料

タグ

AI LLM 継続学習 Google 論文解説 MoE メモリ 破滅的忘却