--- title: "長く動くエージェントは「記憶」より「今の理解」：信念状態の論文" description: "2026年10月1日に公開された論文「Beyond Memory」は、長いタスクで迷走するエージェントに、履歴の要約ではなく「今の世界の理解」と「未解決の課題」を明示して持たせる方法（PoS）を提案しています。論文の中身と、Claude Codeのような日常のエージェントへの指示に置き換えるとどうなるかを整理しました。" url: https://udon-dev.com/notes/belief-state-agents/ lang: ja published: 2026-10-03 updated: 2026-10-05 topic: [ai] tags: ["ai-agent", "claude-code", "llm", "paper"] --- # 長く動くエージェントは「記憶」より「今の理解」：信念状態の論文 - 2026年10月1日公開の論文「Beyond Memory」は、長時間動くエージェントに、履歴を要約して渡すのではなく「今の世界の理解（信念状態）」と「まだ分からないこと・まだ達成していないこと」を明示して持たせる手法PoSを提案している - 4つのベンチマークと3つのモデルで、比較した既存手法を全て上回った。履歴の圧縮や整理は、生の履歴を渡すより悪くなる場合もあった - 代償は費用。RCA-100の例では、1回あたりのトークンが生の履歴の約5倍になった - Claude Codeのような日常のエージェントには、「確認済みの事実」「未確認のこと」「今の焦点」を書いたメモを更新させ、同じ操作の繰り返しを検知したら止める、という指示に置き換えられる。ただし、これは論文の外にある読み替えで、論文が検証したものではない - 同じ方向の実践論として、開発者のKevin Liaoは、記憶プラグインより、エージェント自身が読み書きするMarkdownの文書群のほうが有効だと主張している。ただしこれは自作ツールの1年の利用に基づく主張で、比較実験はない エージェントに長い作業を任せると、途中から同じ場所をぐるぐる回ったり、とうに直したはずの前提で作業を続けたりすることがあります。会話が長くなるほど、「何が確認できていて、何がまだ分かっていないのか」が履歴の中に埋もれていくためです。2026年10月1日にarXivへ公開された論文[「Beyond Memory: Harnessing Long-Horizon Agents with Explicit Belief States」](https://arxiv.org/abs/2610.01415)は、この問題に「履歴をどう覚えさせるか」ではなく「今の理解をどう持たせるか」で答えています。論文の中身を確かめた上で、日常で使うClaude Codeのようなエージェントに置き換えるとどうなるかまで考えます。 ## 履歴を整理しても、今の理解にはならない エージェントに長い履歴を渡す方法は、大きく2つあります。履歴をそのまま渡す方法と、要約や圧縮、重要な部分の選び出しをして渡す方法です。論文はどちらも「過去の証拠の記録」であって、「今の世界はこうなっている」という理解ではないと指摘しています。履歴の中では、操作で変わってしまった前提と、変わっていない前提が混ざります。どれがまだ成り立っているのかを、エージェントは毎回読み直して推測することになります。 論文が挙げる例は、ロボットが電子レンジを「開いている」とも「閉じている」とも記録してしまう場面です。マグカップを入れる前に扉を開けるべきかどうかが、記録からは決められません。 ## 提案されたPoS：理解と未解決の課題を明示する 論文が提案するPoS（Progression of States）は、モデルの追加学習を必要としない、推論時の枠組みです。エージェントは毎ステップ、次の4つを持ちます。 - **世界の状態**: 作業に関係する物（Entity）、その現在の状態（State）、それらのつながり（Relation）。状態と関係には、根拠と確信度が付く - **目的**: タスクの目標と完了の条件 - **知識の穴**: まだ分からない、または根拠が足りないこと - **達成の穴**: 目標の状態と現状の差で、行動して埋めるもの 「知りたいこと」と「やるべきこと」を分けているのがこの手法の特徴です。穴が複数あるときはいま最も価値のあるものを1つ「焦点」に選び、そこから行動を決めます。全体の理解は捨てずに、注意だけを絞ります。 行動のたびに新しい観測が入るので、エージェントは信念を更新します。ただし、更新は自分で書いたものなので、思い込みや幻覚が混ざり得ます。そこでBelief Sentinel（信念の番人）が、更新案を検査します。同じ物に両立しない状態が付いていないか（内部の矛盾）、最新の観測と食い違っていないか（外部の矛盾）を見て、指摘をエージェントに返します。エージェントは証拠に照らして直してから、信念を確定します。 ## 迷走を「Belief Trapping」として検知し、型別に抜け出す もう1つの柱は、論文がBelief Trapping（信念の罠）と呼ぶ状態への対処です。信念が矛盾していなくても、エージェントが同じ無駄な行動を繰り返したり、同じ状態を巡ったり、目標に関係のない情報を集め続けたりして、進まなくなることがあります。 PoSは直近の数ステップについて、次の3つを測って罠を検知します。 - **穴の持続**: 最初にあった穴が、期間中ずっと残っている割合 - **進捗の停滞**: 進捗がなかった遷移の割合 - **信念の再帰**: 焦点に関係する世界の状態が、同じ形で繰り返し現れる頻度 罠を検知すると、原因を2つの軸で診断します。1つは動き方で、状態が全く変わらない「静止」、同じ状態を周期的に巡る「循環」、状態は変わるが焦点が前進しない「ずれ」に分けます。もう1つは止まっている穴の種類（知識の穴か、達成の穴か）です。回復では2つの制約を組み合わせて、次の行動の選択に加えます。動き方に応じた制約は、無効な行動の抑制、循環の遮断、焦点への再固定のどれかです。穴の種類に応じた制約は、新しい決め手になる証拠を求めるか、状況を変える行動を求めます。 ## 結果：全部で勝ち、履歴の整理は常に有利ではなかった 評価に使ったベンチマークは4つです。実行タスクのALFWorld（家庭内の作業）とLOCA-Bench（長い環境説明のなかで進める作業）、診断タスクのRCA-100（障害の根本原因）とClinDiag（臨床診断）です。モデルはQwen3.7-Plus、Kimi-K3、GLM-5.3の3つを使っています。 比べた既存手法は次の5つです。 - 生の履歴（Raw Trajectory） - 圧縮するACON - 関連度に応じて履歴の粒度を変えるPACE - サブゴール単位で整理するHiAgent - 監査付きのタスク記録を持つLongHorizon-Harness 論文の表1では、PoSは12の組み合わせの全てで最高の値でした。例えばQwen3.7-Plusでは、ALFWorldの成功率が生の履歴の62.69%に対してPoSは88.81%（最も強い既存手法は72.39%）、RCA-100の正答率は24.27%に対して38.83%でした。 注目したいのは、既存の「履歴の整理」が安定して効くわけではない点です。PACEはLOCA-Benchで生の履歴を大きく下回りました。GLM-5.3のClinDiagでは、比較した既存手法のどれも生の履歴（46.85%）を上回れませんでした。長い文脈を扱える最近のモデルでは、圧縮による情報の欠落が、冗長さを減らす利点を打ち消すことがある、というのが論文の見方です。 PoSの部品を外した実験でも、効いている場所が分かります。矛盾の検査を外すと、Qwen3.7-PlusのALFWorldは73.88%まで下がりました。罠の診断と回復を外すと、RCA-100は33.98%でした。信念を持たせるだけでなく、検査と回復があって初めて結果が出た、という結論です。 LOCA-Benchで環境の説明を8Kから256Kトークンまで伸ばした実験では、PoSは96Kから256Kまでおおむね安定していました。履歴を読み直して状況を再構成させるより、現在の理解を更新し続けるほうが、文脈の長さに強いという解釈です。 ## 代償：使うトークンは約5倍 費用は軽くありません。論文の表2では、RCA-100（Qwen3.7-Plus）の1回あたりのトークンは、生の履歴の約35.6万に対して、PoSは約180万でした。作業を担当するエージェント自身の消費は約28.1万に減っていますが、信念の構築と維持（約69.7万）と番人の検査（約82.2万）が上乗せされています。論文は、番人の検査や罠の診断を外すと全体のトークンは減るものの、作業側の消費は増えて精度も落ちるとして、「トークンを最小にすることより、信念の維持に計算を割くことに価値がある」と結論づけています。 ## 日常のClaude Codeに置き換えるなら ここからは論文の外にある私の読み替えです。PoSは研究用のベンチマークで評価された仕組みで、Claude Codeにそのまま入れる方法は論文にありません。ただ、仕組みの要点は、指示の出し方に置き換えられます。 **1. 「今の理解」を、会話ではなくファイルに書かせる** 長い作業の最初に、作業メモ（例: `PROGRESS.md`）を作らせます。履歴を読み返さなくても、このファイルだけで現在地が分かる状態にするのがねらいです。 ```text 作業を始める前に PROGRESS.md を作り、次の4つの見出しで保つこと。 作業のたびに更新し、次の手を決めるときはこのファイルを先に読むこと。 ## 確認済みの事実（根拠つき。コマンドの出力、ファイル名と行など） ## 未確認のこと（推測で進めない。確かめる方法も書く） ## まだ達成していないこと（完了条件との差） ## 今の焦点（上の2つから1つだけ選ぶ） ``` PoSの「世界の状態」「知識の穴」「達成の穴」「焦点」に対応します。根拠を必須にするのは、論文が各状態に根拠と確信度を付けていることに倣ったものです。 **2. 更新したら、矛盾を点検させる** 自分で書いたメモには自分の思い込みが入ります。論文の番人に当たるものとして、更新のたびに次を頼みます。 ```text PROGRESS.md を更新したら、確定する前に次を確かめること。 - 同じ物について、両立しない記述がないか - 直前のコマンドの出力やテストの結果と食い違う記述がないか 食い違いがあれば、出力を根拠に直してから先へ進むこと。 ``` 大きな作業では点検だけを別のサブエージェントに任せる手もあります。ただし、論文でも番人の検査は費用の大きな部分でした。毎回やるか、節目だけにするかは、作業の重さで決めることになります。 **3. 迷走の合図を、先に決めておく** 罠の3つの測り方はそのまま「止まる条件」の書き方になります。 ```text 次のいずれかに当てはまったら、作業を止めて報告すること。 - 同じコマンドか同じ修正を3回試しても、結果が変わらない（静止） - 直前の数手が、同じ状態の往復になっている（循環） - 作業は進んでいるが、「今の焦点」が一度も前に進んでいない（ずれ） 報告には、どの型か、止まっている穴が「分からないこと」か「できていないこと」かを書くこと。 ``` 「3回」という数字は目安で、論文の値ではありません。 **4. 回復の指示も、型に合わせる** 止まったあとに「もう一度頑張って」と言うより、型に合わせた指示のほうが筋が通ります。論文でも一般的な「回復してください」という指示より、型に応じた制約のほうが全ベンチマークで良い結果でした。 - 分からないことで止まっているとき: 「次の手は、原因の候補を絞り込める証拠を取るものに限る」 - できていないことで止まっているとき: 「次の手は、状況が実際に変わるものに限る。同じ操作は禁止」 - 循環しているとき: 「いま試した手は使わない。別の経路を提案する」 ## 同じ考えの実践版：記憶より文書 論文とは別に、開発者のKevin Liaoが2026年10月3日に公開したブログ記事[「Agents Don't Need Memory. They Need Documentation.」](https://liao.gg/blog/agents-dont-need-memory)も、似た結論を出しています。ここでの「記憶」は、会話から断片を作ってベクトルデータベースに入れ、プロンプトごとに類似度の高い数件を差し込む、記憶プラグインの典型的な作りを指します。記事は、この作りに次の弱点があると述べています。 - 類似度で選ぶだけなので、どれが正しいか、今も有効か、何が欠けているかが分からない - コードは毎日変わるのに、過去の断片が真実として扱われる - エージェントは自分が知らないことを検索できない - 保存された断片のどれが古いか、誤っているかを監査できない 代わりに提案しているのが、エージェント自身が読み書きするMarkdownの文書群です。仕様、決定、調査、索引を文書に残させ、作業の前に読み、作業のあとで古くなった箇所を更新させます。流れは「依頼→作る→忘れる」から「依頼→文書を読む→作る→文書を更新する」に変わる、という説明です。筆者はこの考えをプラグイン[Operator Memory](https://github.com/aerovato/operator-memory)として公開していて、READMEによると、ベクトルデータベースも埋め込みも使わず、文書はGitで管理してチームで共有できます。 論文のPoSと重なるのは、履歴を後から掘り返すのをやめて、「今の理解」を明示した文書を更新し続ける点です。違いは、PoSが1つの作業の中で毎ステップ信念を更新するのに対し、こちらは作業のあいだ（セッションをまたいで）残る知識を文書にする点です。 注意したいのはこの記事の根拠の弱さです。筆者は1年ほど自分の作ったツールを使ったと書いていますが、他の方法と比べた数値は示していません。ベンチマークで検証された論文とは違い、「記憶プラグインは役に立たない」という言い切りは、この記事の主張にとどまります。 Claude Code自身も、2つの仕組みを分けています。[公式ドキュメント](https://code.claude.com/docs/en/memory)では、人が書く指示のファイルCLAUDE.mdと、Claudeが自分で書くメモの自動メモリーが、どちらもセッションの開始時に読み込まれると説明されています。どちらも普通のMarkdownで、自分で開いて編集・削除できます。自動メモリーは先頭の200行か25KBまでしか読み込まれず、公式は、これらが強制される設定ではなく文脈として扱われるとも書いています。文書に書いても、エージェントが必ず従うとは限らない、ということです。前の節の作業メモ（`PROGRESS.md`）は1つの作業のためのもの、CLAUDE.mdは長く残る決まりのためのもの、と使い分けると整理しやすくなります。 （図: Claude Codeの公式ドキュメントの画像。「Claude Code Docs」のロゴと「How Claude remembers your project」の見出し） 出典：[How Claude remembers your project（Claude Code Docs）](https://code.claude.com/docs/en/memory) ## 試す前に押さえておきたいこと - 論文の結果はプレプリントの段階のものです。評価はベンチマークの上で、モデルも研究用の設定です。Claude Codeで同じ改善が出るとは限りません - 費用は増えます。短い作業にメモと点検を足すと、かえって遠回りになります。数十手を超えて迷走しやすい作業から試すのが妥当です - 論文は限界として、信念の維持にかかる費用と、領域や課題についての知識への依存を挙げています。何を状態として書くかが分からないタスクでは、メモの質も上がりません エージェントの精度は、モデルの賢さだけでなく「いま何が確かで、何が未解決か」を毎回はっきり持たせられるかにも左右されます。指示の1行目に書く内容を、「何をするか」だけでなく「何がまだ分かっていないか」にも広げることから始められます。