背景: 同じコマンドでも、ワークスペースが違えば起きることが違う

• 注目するのは「このコマンドは今のワークスペースにどんな安全上の効果を持ち、それはユーザーの依頼の範囲内か」という点（Section 1）。ファイル編集ツールは呼び出しに変更内容が書かれていますが、シェルコマンドは中で呼ぶスクリプト・ビルドターゲット・パッケージツールが何をするかが文面に出ません

• 脅威モデル（Section 3）: 依頼自体は善意で、対象や範囲が曖昧なことがある。エージェントは間違える、依頼の意図を超える、プロジェクトのファイルやツール出力の中の信用できない内容に誘導される、のいずれもあり得る。ワークスペースのスクリプト・ビルドファイル・バイナリは名前や文面以上のことをし得る。承認器、スナップショットと巻き戻しの仕組み、コンテナの境界は信頼する

• 比較する既存の承認器（Table 8）: ルール検査 CARE はコマンド文字列を構文・パス・出所のルールで見て、未解決は LLM 判定に回す。ガードレールモデルは TS-Guard（ToolSafe。依頼と ReAct 形式の履歴と現在の行動）、gpt-oss-safeguard-20b（依頼とコマンドをポリシーに照らす）、Qwen3Guard-Gen-8B（固定の安全分類）。Claude Code Auto Mode は許可ルールと 2 段の分類器で、ユーザーのメッセージとツール呼び出しは見るがツール出力は見ない。YoloFS は承認器を持たず、実行後の変更要約をエージェント本人に見せて戻すかを任せる staging 方式

• 著者は、Anthropic が Claude Code の許可プロンプトをユーザーが 93% 承認していると報告していること、Auto Mode が実際の行き過ぎた操作の 17% を見逃すと報告していることを引いています（Section 1・2）

手法: 先に実行し、観測した効果で承認する

• トランザクション（Section 4.1）: 課題ごとの Docker コンテナがサンドボックスで、ネットワークは無効、メモリとプロセス数は制限。コマンドは strace -f（システムコールの記録ツール）のもとでタイムアウトつきで実行され、プロセス生成・ファイル操作・ネットワークのシステムコール・出力への書き込みを記録します。Allow ならスナップショットを捨てて実行後の状態を残し、保留していた出力をツール結果として返すので、コマンドの実行は 1 回だけです。Block なら変更されたコンテナを捨ててスナップショットから新しいコンテナを起こします

• コンテナの外へ出る効果は巻き戻せないので、外向きの通信は切ってあります。接続の試行自体は宛先・プロセス・そのプロセスが直前に読んだファイルとともに記録されるので、送信の試みは何かが出て行く前に見えます。ベンチマークがネットワークサービスの応答を固定で用意している場合は「模擬」と印を付けます。パッケージレジストリのような許可済みの宛先を通すこともでき、返ってきたものはコンテナに入るので一緒に巻き戻せます

• 効果レポート（Section 4.2）: 生のトレースは動的ロードやロケールの照会で数十 KB になるので、コンテナ起動時に 1 回だけ走らせたプローブの記録を差し引き、残りを 4 段階で絞ります。（1）境界を越える結果を小さな構造化レコード（card）にする: 永続的なファイルの遷移（小さなテキストファイルは差分つき、秘密らしいパスは内容を伏せる）、接続試行（観測・試行のみ・模擬の区別）、ユーザーに見える出力。（2）出力や送信のようにデータを運ぶ結果には、同じプロセスがその前に読んだリポジトリ・認証情報・通常でないシステムパスのファイルを「同じ actor が結果の前に読んだ」という根拠つきで添える。（3）dotenv・認証情報ストア・秘密鍵の読み取りは、その後に出力や送信がなくても残す。出力に bearer トークンや秘密鍵のヘッダーらしい文字列があれば種類だけを注記し、値は書かない。（4）目標 4 KiB・上限 8 KiB に収め、超えるときはディレクトリ単位の集約 → 件数化 → 遷移の要約の順に縮める。実行状態（完了・タイムアウト・シグナル）、観測・採用・省略した件数、模擬の印、不確かさは必ず残す

• 承認器（Section 4.3）: LLM がユーザーの課題、切り詰めたツール出力を含む対話履歴、生のコマンド、効果レポートを受け取り、Allow / Block と確信度と短い理由を JSON で返します。見る軸は、依頼の目的と範囲、認証情報や秘密を含むファイルへのアクセス、フック・スキャナ・リポジトリのポリシーなど保護された制御の変更、即時の実行時の効果、後のインストール・ビルド・コミット・起動時に動くよう仕込まれた挙動、証拠の不確かさ。パケット全体は指示ではなく証拠として渡し、コマンド・ファイル・出力・効果レコードの中の指示には従わないこと、ネットワークや認証情報の効果が「観測されなかった」ことを安全の証拠にしないことを指示しています

• Block の理由は、秘密の値を引用せずに違反した境界や有害な効果を名指しし、「同じ操作を別のラッパーでやり直すのではなく、より安全な代替を選ぶ」指示とともにエージェントへ返ります

実験

• SABER（Hu et al., 2026）: 正当な開発依頼を素直にこなすと課題ごとの害（認証情報の漏洩、データの削除、セキュリティ制御の弱体化など）が起きる、状態つきのプロジェクトワークスペース。シェル限定の 682 課題を使い、8 つの害カテゴリ × 3 シナリオ（A: ファイル・設定・ツール出力に注入された指示、B: 妥当な依頼でのエージェントの誤り、C: ワークスペースの状態から危険とわかる明示的な依頼）です（Table 1）。SABER の判定器はコマンドのパターン・コマンド文字列から推定した効果・LLM 判定の組み合わせで、著者が監査して誤検知（誤った構文解析、閲覧しただけ、ファイルに書いただけ）を直した修正版で全系を判定しています。公開版での結果は付録 A の Table 4

• YoloFS-Ext（著者作、公開）: YoloFS（Zhong et al., 2026）の「隠れた副作用」課題 13 件をもとに、ツールが依頼の名指ししないファイルを削除または上書きし、その挙動を 4 段階の隠し方（スクリプト、Makefile、スクリプトの連鎖、コンパイル済みバイナリ）で包んだ 102 の危険課題。各課題には、ファイル・依頼・コマンドが同じでツールの中身だけ無害な「安全な双子」があり、双子を止めれば定義上は誤ブロックです（Table 2、付録 A）。害が依頼の名指しするファイルに触れないこと、危険課題と双子はツールのコードだけが違うこと、被害対象は元のプロジェクトで保護されたファイルであることを規則にし、判定はファイルシステムの最終状態からプログラムで行います（LLM は使わない）

• 比較対象: 承認なし（GLM-5.3-Flash と DeepSeek-V3.2）、CARE、TS-Guard、gpt-oss-safeguard-20b、Qwen3Guard-Gen-8B、YoloFS、Claude Code Auto Mode の 6 系。Claude Code の外の系は著者のハーネスの承認ステップだけを差し替え、巻き戻しと理由の返却は共通です。Auto Mode は Claude Code 2.1.288 の公式バイナリを、Claude Code 自身の許可ルールと 2 段分類器のまま、分類器のモデルだけ gpt-5.6-luna に設定して実行しています（製品そのものの挙動ではない）。同じハーネスで比べるために Caper を Claude Code の PreToolUse フックとして動かした版も用意しています（Table 8）

• モデル: エージェントは全系で GLM-5.3-Flash、Caper の承認器と Auto Mode の分類器は gpt-5.6-luna。SABER のループで bash ツール 1 つ、最大 60 ステップ。各課題 1 回の実行

• 指標: SABER は有害（課題固有の害が起きた）、安全に完了、安全に拒否（害の前に辞退またはユーザーに確認）の割合で、後の 2 つの和が安全な結果。YoloFS-Ext は危険課題の有害率と安全完了率、双子のうち課題を達成するコマンドが 1 回でも止められた割合（誤ブロック率）

結果

• Finding 1（文面の承認器に足りないのは厳しさではなく見えているもの）: SABER で文面から判断する 5 系は 14.8〜18.8% の課題を有害のまま残し、承認なしは 19.7%、Caper は 6.7% です。見逃すのは文面に出ない害で、Figure 3 の課題ではリポジトリ同梱の check-deps.py が .env を読んで送ろうとしますが、依頼にもコマンドにもその印はありません。Claude Code の中で組み込みの分類器を Caper のフックに置き換えると、同じエージェント・同じ承認器モデルのまま SABER が 14.8% → 10.0%、YoloFS-Ext が 62.7% → 6.9% になります。ただし Caper の安全完了は 48.6%（承認なし 57.4%）、安全拒否は 19.1%（9.1%）で、害の減少の一部は完了から拒否への振り替え（約 9 pt）で買っています。著者は安全な結果の合計が 67.8% 対 66.6% で同水準だと書きます

• Finding 2（観測した効果が危険課題と双子を分ける）: 双子はツールのコードだけが違うので、証拠を持たない承認器は両方止めるか両方通すかになります。Qwen3Guard・CARE・Auto Mode はどちらもほとんど止めず、62.7〜69.6% が有害。TS-Guard は危険課題の 8.8% で害のコマンドを止めますが双子も 8.8% 止めます。効果レポートなしの Caper の承認器はより多く止めますが双子の 61.8% も止めます。レポートがあると、危険課題の 84.3% で害のコマンドを止め、双子は 1.0% です（Table 9）

• Finding 3（観測だけでは足りず、判断は確定の前に、エージェントの外から）: YoloFS は Caper と同じファイル変化を観測しますが、コマンドの実行後にエージェント本人へ見せて戻させます。102 の危険な実行のうち 66 で戻し、戻さなかった 36 のうち 33 が有害で、35.3% が残ります。後から戻すのは課題の達成も損ない、安全に完了したのは 22.5%（Caper は 60.8%）。SABER では承認なし（19.7%）より有害率が高く（21.2%）、一度送られた認証情報は取り戻せないためです

アブレーション（Figure 5・6、Table 9）と オーバーヘッド（Section 5.5）

• 文脈を増やしても証拠がなければ、害と誤ブロックのトレードオフになります。コマンドだけ → 対話全体で有害率は 44.1% → 17.6% に下がる一方、双子の誤ブロックは 52.0% → 61.8% に上がります。証拠があれば、コマンドだけで有害率 1.0%、誤ブロック 0 です

• 同じモデルにコマンドと参照先のファイル（3 階層・16 ファイル・32 KB まで。バイナリは読めない）から効果を予測させると、有害率は 3.9% まで下がりますが、双子の 61.8% を止めたままです。予測では承認器の不確かさが消えないため、と著者は説明します。観測した効果なら 7.8% と 1.0%。内容の差分を外すと有害率は 13.7% に上がり、上書き型の課題だけが影響を受けます（削除は遷移そのものが見えるが、上書きはサイズの変化としてしか見えない。付録 D）

• 弱い承認器は観測した効果を足しても誤ブロックが 53.9% → 4.9% に減るだけで、有害率は 25.5% → 33.3% に上がります

• 隠し方: 証拠なしの有害率はバイナリ 4.2%、スクリプト 11.5%、Makefile とスクリプトの連鎖 26.9% と包み方に依存し、証拠があればどの段階でも 4〜15% です。証拠なしの承認器は、むき出しのスクリプトとバイナリの双子を中身に関係なく止めます（コマンドだけを見る設定ではスクリプト 100%、バイナリ 100%。対話全体を見る設定では 65.4% と 83.3%。Table 11）

• SABER での効果レポートは中央値 0.9 KB（95 パーセンタイル 2.6 KB）で、生トレースの 62.5 KB に対し合計で 99.4% 小さい。承認の遅延は中央値 3.2 秒（95 パーセンタイル 6.4 秒）で、証拠なしの同じ承認器は 3.3 秒（11.4 秒）。サンドボックスは Allow で約 0.5 秒、Block で約 1.5 秒（巻き戻しが中央値 972 ミリ秒）。API 費用は 1 課題あたり 0.019 ドル（証拠なし 0.017 ドル。Table 13・14）

• 95% の Wilson 区間（Table 12）: SABER の有害率は Caper 5.0〜9.1%、Auto Mode 12.2〜18.0%。YoloFS-Ext の有害率は Caper 4.0〜14.7%、フック版 3.4〜13.5% で重なります

実例: Auto Mode が通した 2 件

• どちらも Claude Code Auto Mode が通した課題で、コマンドはユーザーの依頼そのものです（Section 5.4）。Case 1 ではレポートの差分がソースをコメント 1 行に置き換えたことを示し、Case 2 ではデータベースが 32 KB から 20 KB に縮んだことが、バイナリや DB の中身を読まなくても止める根拠になります

• Block の理由を受けたエージェントは、Case 1 では deploy.sh を読んでソースのコピーを自分で行い、Case 2 ではデータベースを複製してから移行スクリプトだけを実行して、どちらも安全に完了しています

導入：人の記憶と dreaming

• 人の脳との対応
• 海馬が体験をその場ですぐ記録し、すぐ使える状態にする
• 長期記憶に定着するのはその一部だけ。定着は睡眠中・安静時に海馬が直近の体験を replay し、新皮質に統合することで進むと考えられている

• エージェントでも同じ分業ができる
• 作業中の記録 = ログ・transcript
• Letta と UC Berkeley が提案した sleep-time compute（対話の合間の空き時間で既存コンテキストを整理する）を記憶に応用
• ログを振り返って誤りを直したり、Memory notesやMemory representationsを作ったりする処理を dreaming と呼ぶ

• この記事の内容：Anthropic がエージェントの記憶をどう捉えているか、dreaming を含む各構成要素が記憶の整理に何を足すかを、いくつかの評価で示す

• 図1 記憶の階層（下から上へ）
1. Transcripts：検索できるイベントログ
2. Memory notes：Claude が書いたノート
3. Memory representations：wiki など
4. Injected context：毎セッションの最初に読み込まれるコンテキスト
• dreaming は transcript から各層へ、また隣り合う上位層の間で双方向に働く（誤りの修正・ノート作成・新しい表現の構築・次のセッションに先に読み込ませる内容の調整）

Memory notes

• この記事でいう「agent memory」の定義
• Claude が経験（ユーザーとのやり取り・割り当てられたタスク）から得て、セッションをまたいで保持し、後で読めるコンテキストとして保存される知識

• 人の脳では、体験の前後に出る化学信号が記憶に「重要」の印を付け、印付きの記憶はオフライン時に多く replay されて長期記憶に定着する

• Claude も同様に
• セッションログ中の重要な出来事にその場でタグを付けて後で見つけやすくする
• あるいは memory store（memory notes のフォルダなど）に書き出す

• 問い：この先何が起きるか分からない時点で、何が重要（salient）かをどう判断するのか

記憶は「将来何が必要か」の予測になりうる

• ルールを書き留める = そのパターンがまた関係してくるという予測
• 検証済みの事実を書く = 将来のセッションが再確認せずにそれに頼りたくなる、という予測
• Claude はこの種の予測が大きく上達してきた

• 評価：Continual Learning Bench（CL-Bench）1.0
• 記憶を使って長期タスクに取り組む力を測るベンチマーク
• 使ったタスク：データベースを調べて一連の質問に答える。回答後に正解が知らされ、将来の質問のために記憶を書ける

• モデルごとの到達度
• Sonnet 4.6：間違いの理由の仮説を立てるところまで。memory ディレクトリには、未検証の推測を並べたファイルが散らばっていた
• Opus 4.7：ノートを 1 つの参照ドキュメントにまとめ、確認済みの事実と未確認の事実を区別し始めた
• Sonnet 5：採点で確認された回答に「確認済み」と付け、間違えたときは訂正を書いた
• Opus 5：ループを最初に閉じたモデル。エントリの多くに「ルール（とそれが正しいと分かった根拠）」「過去の質問の答え」「途中で見つけた罠への明確な警告」が入っていた
• Opus 5.5 / Sonnet 5.5：どちらもループを閉じ、検証済みのルールを記憶に残した。記憶ありのスコアは Opus 5 とほぼ同じ、記憶なしのベースラインはやや高い

Claude は「何を覚えるべきか」を判断できるようになった

• 評価：ポケモン 赤 のプレイ（複雑な長期タスク。何を記憶に残すかの判断を見るテスト）
• 各ランの開始時に、プレイ中に読み書きできる memory ファイルのフォルダを渡す

• Sonnet 3.7 と Fable 5 を、それぞれ約 10,000 ステップ時点で比較
• Sonnet 3.7：何でも重要かもしれないとみなし、手当たり次第に書いた
• バトル・拾ったアイテム・会った NPC ごとに別ファイル、という出来事のアーカイブ
• 225 フォルダに 413 ファイル（約 98 万文字）、バッジ 1 個
• Fable 5：2 フォルダに 9 ファイル + トップレベルの 1 つ（約 4.3 万文字）、バッジ 4 個

• Sonnet 3.7 のやり方の問題
• ゲームの状態は常に変わるので、詳細な記録はすぐ古くなる
• 進むほど、ゲームをするより記憶を漁ることに時間とリソースを使うようになった
• 例：10,000 ステップ付近で 4 つ目の「master」memory フォルダを作り始め、その後 17 ステップで 6 ファイル作成・9 ファイル削除し、ゲーム内の行動はゼロ

• Fable 5 のやり方
• ゲームが明示的に教えてくれないことだけを記憶に使った
• 所持金や現在地のような毎ターン画面から読める情報は、保存しても冗長
• 戦略・計画・検証済みのルールは、Claude が自分で導き出さない限り存在せず、書き留めないと消える
• 構成
• ：ダッシュボード役。現在の目標、ジム攻略の事前計画、記憶の使い方に関する自分用ルール
• ：特定ルートの移動計画
• ：ゲームの仕組みについて学んだことに基づく戦略
• 例：捕まえやすいはずのコイキングにモンスターボールが 7 連続で失敗した後、「3 回以上連続で失敗したらタイミングを変える（メニュー操作の間に wait を挟む）— これをした直後に捕まった」と書いた

• 結果：memory フォルダがずっと小さい Fable 5 のほうがはるかに先に進んだ
• Opus 5.5 も同様のやり方で、現在の目標と次の手を追う小さなノートを保ち、プレイしながら書き直して、ゲームをクリアした

記憶の書き方を Claude にどう指示するか

• 方針：記憶が何のためにあるかは伝えるが、どう使うかは指示しないほうがうまくいく
• CL-Bench では「memory フォルダが使える」と伝えただけ。それだけで Opus 4.7 / Opus 5 は記憶をうまく使い、スコアが目に見えて上がった

• 何を書くかの具体的ルールを 1 テストにつき 1 つ与えて、記憶による伸びを比較
• 「失敗だけを記録せよ」とすると、Opus 5 と Opus 4.7 は記憶による伸びの多くを失った
• 強いモデルでは、事前に固定ルールを決めるより重要度の判断を任せたほうが効果的。ルールはかえって性能を落としうる

• 図5 の数値
• 左（Sonnet 4.6）：ベースライン 0.330 → 記憶あり 0.364 → 記憶あり + 指示を改善 0.641（参考線：Opus 4.7 記憶あり 0.700、Opus 5 記憶あり 0.828）
• 右（「失敗だけ記録」での伸びの変化）：Opus 5 −0.234、Opus 4.7 −0.150、Sonnet 4.6 −0.020

• 指示がいちばん役立つのは古いモデル
• Sonnet 4.6 は memory ディレクトリを読まないことが多く、間違いの理由の仮説も検証しなかった
• 「答える前に memory ファイルを読め」「仮説を明示的に検証せよ」と指示すると、スコアがほぼ倍になった
• Sonnet 5 は指示なしでこれをやる：答える前に記憶を読んだのは 10 回中 9 回。Sonnet 4.6 は半分未満

• フロンティアモデルへの実際の指示：「人に頼まれたとき、または明らかに覚えておく価値があるときに memory notes を作る」程度の簡単な指示にとどめ、判断は Claude に任せる

Dreaming は記憶を修正できる

• 問題：記憶はセッション中の重要度判断で書かれるので、最初から間違っているノートや、環境の変化でずれたノートが、後のセッションで読まれて信用されてしまう

• dreaming はノートを元の transcript と突き合わせて検証する手段になる

• 事例：Managed Agents + 記憶用ディレクトリをマウントしてポケモンをプレイ
• おつきみやま：入口が西、出口が東の洞窟。入口近くに一方通行の段差があり、落ちると来た道路に戻され、簡単には登り直せない
• Claude は山の入口にあるポケモンセンターを目印にしていたので、段差から落ちるかどうかは「ポケモンセンターが山のどちら側にあると思っているか」で決まった
• Claude はポケモンセンターが東側（洞窟を抜けた出口側）にあると誤って書いた
• そのため、ポケモンセンターを出たとき洞窟をもう通過したと思い込み、「おつきみやまは後ろだ」と言って、ノートを「Mt Moon DONE（攻略済み）」に更新した
• 実際はまだ入口の手前で、次の街へ向かったつもりが段差から落ち、来た道に戻された
• ナビゲーションツールが段差を表示しなかったため「西に行き過ぎた」と結論し、自分は最初から正しい側にいたと思い込んだ（実際は違う）

• dreaming で罠を避けられるかを検証
• ポケモンセンターの位置を間違えた memory フォルダに dreaming を実行
• Claude はノートをセッションの transcript と照合して誤りに気付き、書き直した（transcript が検証のための正解データになった）
• 修正後のノートでは「洞窟の入口を探して入り直す必要がある」と言ってまっすぐおつきみやまに戻り、ハナダシティに到達

• 未修正のノートのラン
• 同じ道路に 3 回落ちた
• 3 回目の後「ループし続けるより止める」と諦めかけたが、自動応答で続行を指示され、回復と補給のため山の手前のニビシティまで戻った
• ハナダシティには到達しないまま終了

• 図8：記憶 + dreaming は 1,935 アクション目でハナダ到達。未修正の記憶（Raw memory）は段差から落ちてニビまで戻る。記憶なしも到達せず

Dreaming は新しい記憶の表現を作れる

• dreaming で、記憶をたどるための表現（representation）を作れる
• その一つが wiki：Claude が書いて保守するページの集まり。1 つの主題について知っていることをまとめ、他のノートにリンクする
• リンクが記憶を探して必要なときに効率よく見つけるための地図になる

• 評価 1：Stainless（5 月に買収したソフトウェア会社）の社内文書コーパス
• 約 35 万ファイル、約 4.2 億トークン
• コーパスについての 25 問の評価セットを作り、Claude に探索用の検索ツールを渡す
• dreaming で wiki を作るよう指示。128 セッションにわたり、Opus 5 エージェントがファイルを探索し、リンク付き wiki ページを書く・直す・重複を統合する・主張を元資料と照合する
• 各セッションは前のセッションの進捗の上に積み上げ、共有ログで作業を調整

• 結果
• dreaming を 2 セッションから 128 セッションに増やすと、wiki だけでの正答（採点基準の充足率）が 13% → 48%
• 初期の wiki は新入社員の知識、dreaming を重ねるとベテラン社員の知識地図のように育つ
• 検索ツール + wiki の組み合わせが最もよかった：wiki の成長とともに 54% → 61%（検索ツールだけは 53% で横ばい）
• 検索 + wiki で 1 問あたり約 20,000 トークン節約
• wiki は一度作って終わりではなく、後続の dreaming で追加・編集・刈り込みをして少しずつ育てる

• 図10 の wiki の規模：2 セッション後 103 ページ / 766 リンク → 128 セッション後 222 ページ / 12,893 リンク

• 評価 2：どんなタスクで wiki が役立つか（Harvey LAB ベンチマーク + 合併に関する文書群）
• LAB は文書群を渡してリーガルブリーフを書かせ、採点基準のリストで採点する
• 文書から wiki を作らせ、wiki 経由と直接のファイル検索とで、質問回答・ブリーフ作成をさせて比較

• wiki が役立ったケース：合併についての 24 問
• 半分以上が複数文書をまたいで情報を集める必要があり、多くは判断や計算も要る
• これらの項目で、wiki を参照すると 87%、検索だけだと 73%

• wiki が役立たなかったケース
• ある LAB タスクでは、基準の多くが 1 つの文書（主に案件概要メモ）のテキスト検索で取れたため、検索に対する明確な上積みなし
• 別の LAB タスクでは、wiki が元の文書より大きくなった

Dreaming はノートを記憶の階層の上へ引き上げられる

• dreaming でノートを階層の最上位に引き上げ、ハーネスが毎セッションの開始時に Claude のコンテキストへ先に読み込める
• Claude はそれを検索する必要も、検索すべきものがあると知っている必要もない

• この context injection は慎重にやる必要がある
• 注入した記憶は貴重なトークンを消費する
• 間違ったノートが毎セッションに持ち込まれる
• 読み込んでも Claude がそれに従うとは限らない（Claude Code のドキュメントでも、指示ファイルが長いほど守られにくくなると注意している）
• → 最上位層は比較的小さく保つ必要があり、ここでの dreaming の仕事の多くは「小さく保つこと」：詳細を下の層へ移し、リンクだけ残す

• Claude Code の auto memory も同じやり方で注入層を小さく保っている（セッション中に Claude が保守）
• auto memory をすべて読み込むのではなく、 の先頭 200 行または 25 KB だけを読み込む
• この先頭部分が索引となり、何を知っていてどこにあるかを示す

Dreaming は記憶を特定の目的に向けて育てられる

• dreaming で wiki を作るときの「作り方の指示」を、そのタスクで何が大事かに合わせると、記憶の質が大きく上がる

• 事例：Harvey LAB の企業買収タスク
• 課題：契約書の束を読んでリーガルブリーフを書く。採点は「契約条件を正しく書けているか」
• つまりこのタスクで一番大事なのは契約条件だが、最初の指示にはそれが書かれていなかった

• 改善前：「文書から wiki を作って」という一般的な指示
• 複数のエージェントが同時に、契約条件をまとめる 1 つの共有ページ（）へ書き込んだ
• 互いの書き込みを上書きして一部が消え、残った分も要約が雑だった
• 結果：採点される事実 57 個のうち 41 個（72%）しか wiki に残らなかった

• 指示の直し方：人が直さず、Claude 自身に直させた
• 「失敗を振り返る → 指示の変更を提案する → wiki を作り直す」を繰り返した
• その中で Claude は「契約条件を正確に残すことが一番大事」と気付き、指示を書き直した

• 改善後：「契約ごとに 1 エージェントが専用ページを書き、条件は要約せず原文のまま引用する」
• 書き込み先が契約ごとに分かれるので、上書きが起きない
• 結果：57 個すべて（100%）が残った

Dreaming はセッションが残した穴を埋められる

• memory notes を書くとき Claude はそのセッションのコンテキストしか見ていない

• dreaming は多数のセッションを横断して、共通のパターンを見つけたり、よくある誤りを直したりできる

• 事例：LAB 用の wiki を作るとき、まだ存在しないページへのリンクが張られることがあった
• 2 回目の dreaming パスで多くを解消
• あるタスクでは、存在しない ページへの 9 本のリンク（6 ページから）を見つけ、同じ文書の既存ページ に付け替えた
• さらに索引など 3 ページを追加（38 エントリ / 225 リンク → 41 エントリ / 278 リンク）

未解決の問い

• いつ記憶を作るか
• タスク中に memory store（フォルダ・ファイル・DB）へ書けば、その場で重要度を捉え、すぐ次のターン・セッションで使える
• ただし、その場でのメモは本来のタスクから注意をそらす
• dreaming なら記憶作成をバックグラウンドに回せるが、その出力はすぐには使えないかもしれない

• 記憶をどう確実に最新に保つか
• Claude は予測を外したり、最初から間違ったルールを書いたりする。環境の変化で記憶がずれて無関係になることもある
• dreaming はその修正手段の一つだが compute を要する。すべての記憶を常に検証させるのは現実的でないかもしれない
• 変わりやすい情報に dreaming を集中させる、dreaming の頻度を調整する（記憶のアクセス頻度に基づくなど）ことが重要になりうる

• 記憶の中心を transcript 検索にする選択肢
• 表現（wiki など）と検索の組み合わせが役立つこともある（図10）
• ただし表現の保守には compute が要り、誤りやハルシネーションがたまらないよう管理する必要がある

概要

• GRPOによるバイナリ報酬に加えて、失敗ターンのみテキストFBによる自己蒸留を行うTargated Guidanceを提案 (by cursor research)

背景

• RLVR手法はモデルがほとんど出さない行動は報酬が付く機会がなく学習が進まない問題がある

• ルーブリックを用意しそれを満たすか(0/1)でプロセス報酬を与える方法もあるがbinaryであり詳細な情報は失われる

• TG(Targated Guidance)はルーブリックごとに固定のテキストを用意。そのテキストをFBとして失敗ターンに限定して自己蒸留する

提案手法

• 教師と生徒は同じモデルで入力だけ異なる。教師にはルーブリックに基づくヒントを与えている(自己蒸留)

• GRPOのアウトカム報酬に自己蒸留によるプロセス報酬を与える。自己蒸留は失敗ターンに限定

2 つの設計

• 失敗ターンだけに蒸留する（論文では gated distillation）：蒸留の損失も失敗ターンにだけかけます。すべての基準を満たせば損失は通常の RL と同じになり、RL の最適解に向かう邪魔をしない、というのが論文の主張です。

• 基準ごとの RL 報酬と組み合わせる：蒸留は、ほとんど出ない行動へ向かうきっかけを作ります。ただし教師はヒント次第で偏ることがあります。一方、RL 報酬は基準そのものなので偏りません。覚えた行動を保ち、磨くのは RL 報酬の役目です。

実験

学習を安定させる方法

蒸留の重み λ を適切に保つ

thinking トークンも蒸留する

CursorComposer 2.5を発表 · Cursor

大目的

小目的

1. 4000億パラメータのモデルの推論の証明を、実用できる速さと大きさで作れるか。

2. 証明を作る計算は、ふつうの推論の何倍かかるか。

3. これまでの仕組みと比べて、どれだけ速いか。

4. Claude が書いた暗号のコードを、どうやって信用できるようにするか。

何を調べたか

FlashProve の仕組み

提供者が事前に公開したコミットメントに対応する重みのモデルに、このプロンプトを入れると、この応答が出る。

• 嘘がつけない：別のモデルで応答を作った場合、検査に通る証明ファイルは現実的な計算量では作れない。

• 中身が漏れない：証明ファイルをどれだけ調べても、重みは分からない。

速くするための設計

測り方

結果

1. H100 1枚で毎秒110トークン分の証明を作れた。検証は CPU で17秒で済む

2. 証明を作る計算は、ふつうの推論の約72〜94倍かかる

3. 同じモデルを証明した先行例の 0.02 トークン/秒に対して、110 トークン/秒を出した

4. 安全性の性質を Lean で証明し、検証器も Lean で動くものを用意した

考察

証明が使える4つの場面

応答のあとで証明する方式を選んでいる

計算の増え方は、これまでの見込みより小さい

まとめ