【論文解説】StateLM「The Pensieve Paradigm」〜LLMが自分のコンテキストを管理する時代へ〜

論文の概要

今回ご紹介するのは、2026年2月に公開された論文「The Pensieve Paradigm: Stateful Language Models Mastering Their Own Context」です。

タイトル: The Pensieve Paradigm: Stateful Language Models Mastering Their Own Context
著者: Xiaoyuan Liu, Tian Liang, Dongyang Ma, Deyu Zhou, Haitao Mi, Pinjia He, Yan Wang
arXiv: 2602.12108v1
公開日: 2026年2月12日
キーワード: StateLM, コンテキスト管理, 状態管理, メモリツール, 長文処理

この論文では、StateLMという新しいクラスの基盤モデルを提案しています。従来のLLMは外部から与えられたコンテキストを受動的に処理するだけでしたが、StateLMは自らコンテキストを能動的に管理できるモデルです。ハリー・ポッターに登場するダンブルドアの「憂いの篩（Pensieve）」にたとえて、モデル自身が記憶を整理・検索・削除する能力を持つという革新的なアプローチを提案しています。

実験では、長文ドキュメントQAで一貫した精度向上を達成し、チャットメモリタスクで10〜20%の精度改善、さらにBrowseComp-Plusリサーチタスクでは従来モデルの約5%に対して52%の精度を達成するなど、劇的な性能向上を示しています。

背景と課題

従来のLLMの限界

現在の大規模言語モデル（LLM）は、基本的に「ステートレスな自己回帰モデル」として動作しています。つまり、入力されたコンテキストをそのまま処理するだけで、自分自身でコンテキストを編集したり、不要な情報を削除したりする能力を持っていません。

この設計には、いくつかの根本的な問題があります。

固定コンテキストウィンドウの制約: LLMが一度に処理できるトークン数には上限があります。128Kトークンに対応するモデルでも、それを超える長さの文書を扱う場合は外部ツールに頼る必要があります。

外部依存のコンテキスト管理: RAG（Retrieval-Augmented Generation）などの手法では、どの情報を取得してモデルに渡すかを人間が設計したパイプラインが決定します。これは脆弱で、タスクごとにカスタマイズが必要になります。

コンテキストの単調増加: 従来のLLMでは、会話が進むにつれてコンテキストが蓄積される一方で、不要になった情報を削除する手段がありません。数式で表すと $s_{t+1} = s_t | (a_t, o_t)$ という形で、状態が単調に増加していきます。

既存アプローチの課題

これまでにもコンテキスト管理に取り組む研究はありましたが、それぞれ限界がありました。

RAGシステム: モデルは受動的に検索結果を受け取るだけで、検索プロセス自体の制御権を持ちません
エージェント型メモリ（MemGPT, MemOS等）: OS的なメモリ階層を提供しますが、メモリ操作のワークフローは人間が事前に設計する必要があります
学習可能なアプローチ（Context-Folding, ReSum）: モデルが適応を学習しますが、やはり人間が定義したルーティンに従う形です

つまり、これらのアプローチはいずれも「モデルの外側」でコンテキスト管理を行っており、モデル自身が主体的にコンテキストを操作するという発想には至っていませんでした。

提案手法

StateLMの核心：状態を自ら管理するLLM

StateLMの最も重要な革新は、インタラクション状態を追記のみのログから変更可能なオブジェクトに変換したことです。

従来のモデルでは状態遷移が単調増加でしたが、StateLMではこれを以下のように変更します。

$$s_{t+1} = s_t | (a_t, o_t) \quad \text{（従来：単調増加）}$$

$$s_{t+1} = F(s_t, a_t, o_t) \quad \text{（StateLM：可変状態関数）}$$

これにより、コンテキスト使用量は線形に増加するのではなく、のこぎり歯状（sawtooth）のプロファイルを描きます。必要に応じて情報を取得し、要約をメモに残し、元のテキストを削除するというサイクルを繰り返すことで、コンテキストウィンドウを効率的に活用します。

メモリツールスイート（「Spellbook」）

StateLMには、4つのカテゴリに分かれたメモリツールが搭載されています。

1. コンテキスト認識ツール
– analyzeText: 入力のスケール（トークン数など）を推定します
– checkBudget: 残りのコンテキスト容量を報告します

2. 情報取得ツール
– buildIndex: 検索可能なインデックスを構築します
– searchEngine: キーワードベースの検索を実行します
– readChunk: 選択したテキストセグメントを読み込みます

3. メモリ管理ツール
– note / updateNote: 重要な事実をメモとして記録します
– readNote: 永続的なメモを参照します
– deleteContext: メッセージを削除し、スタブ（削除痕）に置き換えます

4. 終了ツール
– finish: 最終的な回答を出力します

典型的な推論ワークフロー

StateLMの典型的な処理パターンは、「検索 → 読み取り → メモ → 削除」のサイクルです。

analyzeTextで入力のスケールを分析
buildIndexで検索可能なインデックスを構築
searchEngineで関連する箇所を検索
readChunkで該当テキストを読み込み
noteで重要な情報をメモに記録
deleteContextで元のテキストをコンテキストから削除
必要に応じて3〜6を繰り返し
finishで最終回答を出力

このサイクルにより、非常に長い入力に対しても、コンテキストウィンドウをコンパクトに保ちながら処理を続けることができます。

学習アプローチ：2段階の訓練

StateLMの学習は2段階で行われます。

Stage 1: 教師あり微調整（SFT）

Claude Opus 4.1を教師モデルとして使用し、3,300件の完全な軌跡データを収集。これをフィルタリングして35,700件の訓練サンプルを作成しています。

品質管理のために3つのメカニズムが導入されています。
– 結果ベースの棄却サンプリング: 正しい最終回答のみを保持
– プロセスベースの棄却サンプリング: コンテキスト削減に失敗した軌跡や必要な読み取りをスキップした軌跡を除外
– アクションバランシング: 頻出操作（特にdeleteContext）のダウンサンプリングにより、特定の操作への偏りを防止

Stage 2: 強化学習（RL）

GRPO（Group Relative Policy Optimization）スタイルの目的関数を使用し、LongBench v2の488問題で訓練を行います。

報酬設計は以下のとおりです。
– 正解かつ適切なフォーマット: +1
– 不正解だがフォーマットは適切: -0.5
– フォーマット不備または未完了: -1

特筆すべきは「軌跡スナップショット」の仕組みです。コンテキスト編集アクションが発生するたびに状態のスナップショットを収集し、均一にサンプリングすることで学習バイアスを軽減しています。

実験結果

ベンチマーク1: Needle-in-a-Haystack（NIAH）

32Kから2Mトークンまでの長さで、コンテキスト中に埋め込まれた情報を検索するタスクです。検索ツールを無効にした状態での結果を示します。

モデル	128K	256K	512K	1M	2M
Qwen3-14B	88.33%	41.67%	23.33%	3.33%	1.7%
StateLM-14B	99.44%	97.78%	89.45%	95.00%	83.89%

従来のQwen3-14Bは256K以上で急激に精度が低下しますが、StateLM-14Bは2Mトークンでも83.89%の精度を維持しています。これは非常に印象的な結果です。

ベンチマーク2: 長文ドキュメントQA

NovelQA（約135Kトークン） の結果:
– Qwen3-4B（128Kコンテキスト）: 65.17%
– StateLM-4B（32Kコンテキスト）: 79.57% → 約14ポイント改善、しかも1/4のコンテキスト

∞-Bench（約189Kトークン） の結果:
– Qwen3-8B（128K）: 66.81%
– StateLM-8B（32K）: 70.16%

特に「マルチホップ推論」カテゴリで最大の改善が見られました。複数の箇所にまたがる証拠を統合する必要があるタスクで、StateLMの検索 → メモ → 削除サイクルが威力を発揮しています。

ベンチマーク3: チャットメモリ（LongMemEval-S）

マルチターンの会話で過去の情報を正確に想起するタスクです。

Qwen3-14B（128K）: 74.96%
StateLM-14B（32K）: 77.44% → 全モデルサイズで10〜20%の改善

ベンチマーク4: 深層リサーチ（BrowseComp-Plus）

552Kトークンの複雑なリサーチタスクで、最も劇的な差が現れました。

Qwen3-14B: 5.46%
StateLM-14B-RL: 52.67% → 約47ポイントの改善

従来モデルがほぼ対処不能だったタスクで、StateLMは半分以上を正解するという圧倒的な性能を示しています。

ツール使用パターンの分析

StateLM-14Bのツール使用パターンも興味深い結果を示しています。

NovelQA: 平均18.6ラウンド、メモリ操作4.3回、検索6.3回
BrowseComp+: 平均22.8ラウンド、メモリ操作4.1回、検索6.6回

注目すべきは、入力長が増加すると検索操作は増える一方、メモリ操作の回数はほぼ一定に保たれる点です。これは、モデルが効率的な情報圧縮を学習していることを示唆しています。

考察・インパクト

実務への影響

StateLMの研究は、実務のAI開発にいくつかの重要な示唆を与えます。

1. RAGパイプラインの簡素化

現在、多くの企業がRAGシステムの構築に多大な工数をかけています。チャンク分割の粒度、検索アルゴリズムの選定、リランキングの設計など、多くのエンジニアリング判断が必要です。StateLMのアプローチが一般化すれば、これらの「コンテキスト管理のためのパイプライン」の多くをモデル自身に任せられる可能性があります。

2. エージェントフレームワークの進化

現在のAIエージェントフレームワーク（LangChain, AutoGen等）は、メモリ管理を外部コンポーネントとして実装しています。StateLMの思想が普及すれば、エージェントの設計パラダイムが「オーケストレーション重視」から「モデル自律重視」へとシフトする可能性があります。

3. コスト効率の改善

StateLMは32Kコンテキストで128Kコンテキストのモデルを上回る性能を達成しています。これは推論コストの大幅な削減にもつながります。長いコンテキストを処理する際のAPI呼び出しコストは、コンテキスト長にほぼ比例するため、1/4のコンテキストで済むということは、コストも大幅に削減できることを意味します。

技術的な意義

「受動的予測器」から「状態認識エージェント」へ — この論文が提示するパラダイムシフトは、LLMの本質的な役割を再定義するものです。

従来のLLMは、与えられた入力に対して次のトークンを予測するだけの存在でした。しかしStateLMは、自分自身の推論プロセスを管理・最適化する能力を持っています。これは、LLMが単なる「言語モデル」から「認知アーキテクチャ」へと進化する一歩と言えるでしょう。

課題と制約

もちろん、まだいくつかの課題も残されています。

検索の限界: BM25ベースの検索は、言い換えや暗黙的な情報を見逃す可能性があります
フォーマットエラー: 長い推論ではツール呼び出しが不正な形式になることがあり、特に小規模モデルで顕著です
削除スタブの蓄積: 削除痕が蓄積し、タイミングの悪い削除でコンテキストが一時的にオーバーフローする場合があります

まとめ

「The Pensieve Paradigm」論文は、LLMの設計思想に新たなパラダイムを提示する重要な研究です。

主要な貢献

Pensieveパラダイム: コンテキスト管理を外部スクリプトからモデル自身のエージェンシーへと移行するフレームワークを確立
StateLM: 多様なシナリオ（長文QA、マルチターン対話、深層リサーチ）で自己コンテキスト管理を学習した初めての基盤モデル
実用的な成果: 特にBrowseComp-Plusでの47ポイント改善は、このアプローチの実用的な価値を強く示している

今後の展望

この研究の方向性はまだ始まったばかりです。今後は以下のような発展が期待されます。

検索メカニズムの高度化: BM25を超える意味検索の統合
マルチモーダル対応: テキスト以外のモダリティ（画像、音声）への拡張
商用モデルへの統合: GPT、Claude、Geminiなどの商用モデルへの本アプローチの導入
学習効率の改善: より少ないデータでの効率的な学習手法の開発

「LLMが自分自身のコンテキストを管理する」というアイデアは、一見シンプルですが、その影響は計り知れません。RAGの設計方法からエージェントアーキテクチャまで、AIシステム全体の構築方法を再考させる可能性を秘めた論文と言えるでしょう。

この研究に興味を持たれた方は、ぜひ原論文をチェックしてみてください。