10月9日、Minghao Liらが「FlowState: Execution State as Memory for Long-Horizon LLM Agents」と題した論文をarXivに投稿した。長時間にわたるタスクをこなすLLMエージェントが、実行状態をメモリとして保持・再利用することでコストを削減しながら精度を高める手法「FlowState」を提案している。
※なお、本論文のarXiv ID「2609.34565」は通常の「YYMM.NNNNN」形式と照合すると連番部分が大きく、アクセス時に404エラーとなる可能性がある。元記事URLは著者公表のものをそのまま掲載しているが、アクセスできない場合は著者名・論文タイトルでの検索を推奨する。
問題の核心：長時間タスクでLLMエージェントがつまずく理由
LLMエージェントに複数ステップにまたがる複雑なタスクを任せると、すぐに「文脈の管理」という壁にぶつかる。過去のやりとりをすべてコンテキストに含め続ければトークンコストが爆発する。かといって圧縮すると、後になって重要だとわかる情報が失われる。さらに厄介なのは、「どの過去情報が重要か」はタスクが進むにつれて初めてわかるケースが多い、という点だ。
従来のアプローチとして広く使われてきたのは、大きく2つに分類できる。ひとつはRAG（検索拡張生成）による外部メモリ化で、MemoryBankやMemoryOSといった研究がこの系譜にあたる。もうひとつはサマリーによる文脈圧縮で、LangGraphやAutoGenといった実装フレームワークでも採用されている一般的な手法だ。前者は検索精度に依存し、後者は「後から重要になる情報」を圧縮時点では判断できないという根本的な限界を抱える。
FlowStateはこの問題に対し、「実行状態そのものをメモリとして扱う」というアプローチで挑む。
FlowStateの仕組み：2つのコアメカニズム
FlowStateは、意味的に型付けされた状態ノード（semantically typed state nodes）とそのノード間の関係、そして生のツール出力への参照を保持する。「永続的な保持」と「必要時のオンデマンドアクセス」を分離している点が設計の肝だ。
「意味的に型付けされた状態ノード」とは、エージェントの実行過程で生じる情報を「どのステップで」「何の目的で」「どういう種類のデータとして」生成されたかを明示的に紐づけて管理するデータ構造のことだ。たとえば「ユーザーの意図」「ツール呼び出しの結果」「中間的な推論の結論」といった区分を型として持たせることで、後の推論ステップでどの情報が参照に値するかを機械的に判断しやすくなる。
この構造の上で、2つのメカニズムが動作する。
ISU（Incremental State Update：インクリメンタル状態更新）
単一の実行ループ内で、新しい入力やフィードバックをもとに現在の状態を更新し続ける。全履歴を積み上げるのではなく、差分的に状態を管理する。たとえば10ステップ目で得た情報が3ステップ目の判断を覆す場合、ISUはその変化を状態に反映させたうえで後続の推論に引き渡す。
PSA（Progressive State Access：プログレッシブ状態アクセス）
推論中に必要に応じて過去の状態と根拠（supporting evidence）を段階的に引き出す。タスクが進んで「やはりあの情報が必要だった」となった時点で、参照先の生データまで遡れる仕組みだ。サマリーを参照するのではなく生の出力まで辿れるため、圧縮による情報欠損が起きない。
この2つが組み合わさることで、エージェントは新しい情報に照らして過去の判断を見直し、次の行動を調整できる。
実験結果：精度とコストの両立
比較対象は同じDeepSeek-V4-Flashモデル（論文内での呼称。2026年10月時点でのDeepSeek公式製品ラインとの対応は論文内の記載に依拠する）を使ったフルコンテキストベースライン（過去のやりとりをすべてコンテキストに含める方式）だ。
| ベンチマーク | 改善幅 | トークン削減率 |
|---|---|---|
| MemoryArena（平均成功率） | +4.55ポイント | -43.2% |
| τ³-Bench（平均パス率） | +13.95ポイント | -40.6% |
タイトルに掲げた「**+14ポイント」はτ³-Benchにおける+13.95ポイントを四捨五入した値であり、MemoryArenaでの改善幅は+4.55ポイント**に留まる点は留意が必要だ。ベンチマークによって改善幅に差があるものの、いずれのケースでもトークン消費が4割以上減っている点は共通している。
- MemoryArena：長期記憶を伴う対話タスクの評価ベンチマーク
- τ³-Bench（tau-cubed bench）：長時間の複数ステップタスクを評価するベンチマーク
精度が上がりながらトークン消費が4割以上減るというのは、単純な「コンテキスト削減によるコストカット」ではなく、必要な情報を必要なタイミングで取り出す設計が機能していることを示す。
どこが面白いか
FlowStateが面白いのは、RAGによる外部メモリ化とサマリー圧縮という二項対立の外側に解を置いている点だ。生データへの参照を切り捨てずに保持しながら、アクセスはオンデマンドに抑えるという中間的な立場を取ることで、検索精度への依存も圧縮時の情報欠損も回避しようとしている。
LangGraphやAutoGenのように実行グラフを明示的に管理するフレームワークとの親和性も高く、状態管理の層としてFlowStateのアーキテクチャを組み込む実装パターンは現実的な応用として検討しやすい。MemoryOSやMemoryBankといった先行研究が「何を記憶するか」の選別に注力してきたのに対し、FlowStateは「実行の流れそのものを型付きの状態として保存する」という設計思想の転換を提示している点で、長時間エージェント設計における一つの方向性を示す論文といえる。
詳細はFlowState: Execution State as Memory for Long-Horizon LLM Agentsを参照していただきたい。
