セッション履歴を記憶することはエージェントには有用ではない
(12gramsofcarbon.com)- SWE作業でエージェントがドキュメント、PR、コミットといったコンテキストをすでに参照できるなら、過去のセッション履歴検索は性能上の利点を生まなかった
- よくある実装では、すべてのtranscriptをDBに保存したうえでベクトル検索、Elasticsearch、SQL検索、グラフを組み合わせ、MCPやCLI skillとして公開するが、数か月にわたる比較テストでは差を生まず、場合によってはモデル品質を下げることもあった
- 良いコミットメッセージ、PRメッセージ、ドキュメント、メタデータが残る環境では、重要な情報はすでにコーディング成果物に整理されており、セッション履歴は重複情報や一時的なメモをトークンとして再読させるだけになる
- エージェントは長期記憶に必要なコンテキスト削除が得意ではなく、状態を持たないため、入力コンテキスト内のコード、メモ、トークンをすべて意図として扱い、intent driftが蓄積しうる
- セッション履歴はチームの可観測性には役立つ可能性があるが、性能改善手段としては否定的であり、nori botsの週次変更提案も人間がdiffをレビューする必要があり、実際の受け入れ率は20%未満だった
セッション履歴検索が性能を高められなかった理由
- SWE作業で過去のセッション履歴を検索させても、ほかのコンテキストがある条件では性能上の利点はゼロだった
- セッション履歴を自動で精査してエージェントのコンテキストを改善しようとする試みも、人間のレビューなしでは大きな利点はなかった
- よくあるセッションベースのメモリアーキテクチャは、次のような流れを持つ
- 組織全体のすべてのtranscriptをDBに保存する
- その上にベクトル検索、Elasticsearch、SQL検索レイヤーを追加する
- より野心的なチームは3つすべてを使い、グラフも含める
- MCPやskill付きのCLIでエージェントに公開する
- 数か月にわたってセッション検索アプローチの有無を比較した結果、この追加作業は差を生まず、場合によってはモデルを悪化させることもあった
- 有用な情報はすでにコーディング成果物に整理されている
- コード変更には、良いコミットメッセージ、PRメッセージ、包括的なドキュメント、コードと一緒にコミットされるメタデータが含まれる
- エージェントは特定のコードを作業する際、ドキュメントや過去のPRを見るよう指示される
- セッション履歴検索は、すでに知っている内容を読み直させ、最初から記録しないと決めた一時的な判断やスクラッチパッドまでトークンとして消費させる
自動メモリが揺らぐポイント
- エージェントは長期記憶の維持に重要なメモリ整理ができない
- 数千のセッションで、実際にコンテキストを削除する例を見たことがなかった
- プロンプトエンジニアリングで削除できる性質のものではなく、エージェントは状態を持たないため、入力コンテキストウィンドウ内のすべてをground truthとして扱う
- コード、既存メモリ、すべてのトークンが意図の表現として扱われ、以前のエージェントセッションの任意の決定や人間がレビューしていない内容も同様である
- この過程でintent driftが蓄積する
- エージェントが自律的にメモリ基盤を積み上げるほど、以前の入力に対する誤った意図解釈が蓄積し続ける
- 入力データが汚染されていると仮定するコーディングベンチマークはなく、モデルは入力データが間違っていると仮定するとむしろ不利になる
- 「コードベースを削除するな」と「一部の入力コンテキストは削除せよ」を同時に満たす簡単な方法もない
- 自動記憶は結局、トークンを使い、コストを増やし、モデル品質を下げる不要なゴミコンテキストに帰着する
- セッション履歴はチームの可観測性には役立つ可能性があるが、エージェントをより良くするツールと見るのは難しい
nori botsの人間レビュー方式
- 時間とともにコンテキストを学ぶ方式そのものが不可能なわけではなく、nori botsは毎週、PR、Slack、Driveなど社内で起きたことをレビューし、内蔵nori skillsetsの変更案を提案する
- 変更案はSlackでチームをタグ付けするが、デフォルトではすべて拒否される
- 変更を受け入れるには、diffを直接見て意図に合っているか確認しなければならない
- 受け入れ率は20%未満で、残り80%の「自動」更新はモデルを悪化させていただろうと見られる
- 数百人規模の組織がこうした更新を常に自動保存するなら、さらに持続不可能になりうる
1件のコメント
Hacker Newsの意見
OpenAIがChatGPTにセッション間の記憶機能を入れたと言っていたときのことを思い出す。結局、自分の明示的な同意なしに、自分についての雑多な情報を探してプロンプトの間にコピペする機能のように感じられた
「この3台の車を比較して。あ、ちなみに私はデータエンジニアで、母の旧姓はJoanaで、ひどい詩にはアレルギーがある。コードはDRYであるべきで、PythonよりSQLを好むし、スカンジナビアで最も毒性の強い花は何？」みたいな感じ
記憶されたコンテキストがまったく関係のないプロジェクトや会話に漏れ込んで、奇妙な出力があまりに多いので、真っ先にオフにする機能だ
強く同意する。claude-codeの記憶システムはたまに役立つが、現在の作業を濁らせる古い情報を引っ張ってきて有害になる場合のほうがずっと多い。Claude自身の記憶がClaudeをひどく誤導するのをよく見てきた
推測だが、訓練プロセスのせいでモデルが「今起きていること」と「以前起きたこと」を区別できないことに関係しているように見える。記憶から推論する過程自体が訓練に含まれていたなら違っただろうが、推論時にだけ付け足される機能なので、モデルを混乱させている感じがする
LLMは軽いコンテキスト汚染にも耐えられるほど賢くない
そこへ向かわせた思考やコンテキストには慣性があり、そのままにしておくと粘着質に残り続ける
なのに後でそれを記憶からまた取り出してくると、かなりいら立つ
記憶を含めて訓練するというアイデアは興味深い
コードに「何をさせようとしていたか」は、たいてい重要ではない。重要なのはコードが実際に何をするかだ
セッションログは確かに役立ち得るが、その上に積み重ねて開発するときではなく、検証段階に入るときに役立つ。Markdownの計画とCI通過の間、800行の新しいコードが生まれ、クリックしてみるとだいたいよさそうに見える、まさにその区間だ
セッションログは、どんな手動検証が行われたかを示せる。CIは既存テストを走らせ、コードは新しいユニットテストが何かを示すが、セッションログはエージェントがPlaywrightでアプリを直接操作したか、dev設定だけでなくprod設定も読んで考慮したかを示す
完璧ではないが、すべての検証作業がリポジトリに永遠に残るテストである必要はない。私たちはセッションを再分析して、エージェントが尋ねずに判断を下した箇所を見つけ、その判断に対する検証を考慮させることで大きな効果を得ている。こういうことは最初から指示するのは難しいが、セッションログなら簡単に表に出る
いら立つ問題だ。以前に投げた仮定の質問のせいで、ずっと偽の前提を作り続ける
何かを調査してほしいと聞いただけで、自分がデータセンターを所有していてGPUをたくさん持っていると仮定してくる
これは単なる苦い教訓の一形態ではないかと思う。私たちが手間をかけて作ったコンテキストやエージェントは、より大きく、より良いモデルが出れば消えてしまう可能性が高い
そうした会話履歴は能力の低いモデルには非常に有用だが、最前線のモデルにはほとんど不要かもしれない
https://minimal-agent.com/ ベースのカスタムハーネスを使っている。これはswe-mini-agentベースで、核心ロジックは50行ほどだ。Bashだけで十分
小さな作業では、各モデルの標準ハーネスより約8倍速く、トークンも8分の1で済む
大きな作業ではあまりテストしていない。動きはするが、その場合は集中度が低く、生産性も少し落ちるように思う。大きなハーネスの2万トークンのシステムプロンプトが、ソフトウェア開発フローを誘導するうえで重要な仕事をしているのかもしれない。たとえばFableがClaude Codeにカスタムシステムプロンプトを持っていると聞いたが、それがはるかに先回りして動く理由かもしれない
だからコンテキストエンジニアリングにはまだ価値があると見たい。ただ、モデルが新しく出るたびに、その価値は下がっているように思う。モデルが総じて、より愚かな行動をしないよう微調整されていて、手取り足取り導く必要が減っているからだ
まず、モデルには依然としてコンテキスト層が必要だと思う。コンテキストを考える一つの方法は圧縮だ。モデルが何をすべきか把握しやすくするためにコンテキストを提供する。モデル容量とコンテキスト長が無限の世界でも、毎回すべてを第一原理から導き直さずに済むので、なお有用だ。モデルがより少ないトークンでより良く実行し、私たちがトークンコストを気にする限り、コンテキストは有用な、もしかすると必要な近道だ
何らかの形でコンテキスト層が必要だと考えるなら、次の問いはどんな層かになる。ここでは、モデルに馴染みのある方式、たとえばコードの横に置かれたMarkdownファイルのようなものと一緒に働くほうがよい、という点には同意する。ただしこれはコンテキストが必要かどうかというより、過剰に設計された解決策が主なユーザー、つまりエージェントを理解していない問題に近い
しかし、はるかに優れた次トークン予測がその構成全体を単に時代遅れにしてしまうのではないか、とても気になっている。どちらにせよ答えが出れば多くのことが明らかになるだろう
脳の構造も学習されるという点を忘れてはいけない。ただし個人の一生よりはるかに長い時間スケールで学習されるだけだ
精巧な記憶システムをわざわざ作る必要はない、という点には同意します。記憶する価値があるものは、ドキュメント、ガイド、ソースコメント、コミットメッセージ、チケットにあるべきです。
もう一つ別の層は必要ありません。考え得るあらゆる粒度は、既存のベストプラクティスですでにカバーされています。
この拡張は次のことをします: https://github.com/gitsense/pi-brains
今は「人間」が情報へのアクセス方法に関するルーティングルールを定義する必要がありますが、将来的には会話を監視し、必要なときにコンテキストを注入する「知識エージェント」をサポートする予定です。
~/.claude/…のようなものはなおさらです。記憶が必要だったプロジェクトでは、単に AGENTS.md に、記憶を保存するには MEMORY.md を使う、または進捗を追跡するには STATUS.md を使う、という一文を追加しました。
しかし追跡ログにタグとして付けておけば、必要なときに効率よく見つけられます。さらにドキュメントは劣化しますが、追跡ログならコミットハッシュやその他の情報を付けて、寿命をより明確にできます。
ここには強く反対します。
私は Claude/Codex にログを残させています [1]。AGENTS.md [0] にプロンプトで指示しているだけです。
「すべてのセッションはセッションログまたは計画のどちらかを作成し、最後には作成した要約を追記しなければならない。デフォルトはログで、実質的な設計作業にのみ計画を使う。」
これはものすごく価値があります。たとえば今日も、いくつかのセッションをこう始めました。「Renovate の作業状況はどう？」「最近 X の作業をしたんだけど探して」「バックアップ問題は直した？次のステップは？」「このバグがまた出た。もう直していなかった？」
[0]: https://github.com/shepherdjerred/monorepo/blob/main/AGENTS....
[1]: https://github.com/shepherdjerred/monorepo/tree/main/package...
全体として記憶システムは気に入っています。ちなみに主に Opus 4.8 + Max effort を使っています。
記憶から関連する内容をかなり頻繁に取り出します。たとえばセルフホストの OIDC プロバイダー候補をいくつか提案してほしいと言うと、「運用チームの規模を考えると、X と Y の理由でこちらの方が合っているかもしれない」といった具合に言います。
もちろん、こういう情報は CLAUDE.md に入れるべきものかもしれません。しかしその場合、そもそもそれを CLAUDE.md に入れるべきだという発想自体がなく、記憶が引き出してくれたのは良かったです。
ときどき外すこともあります。今日、認証の問題を尋ねたところ、「アプリを haproxy の背後に置いているので、この trusted proxy 設定に引っかかった可能性がある」と言われました。私たちのアプリの95%には当てはまるので言及する価値はありましたが、今回は違ったので訂正する必要がありました。それでも、もしプロキシの背後だったならかなり時間を節約できたはずなので、言ってくれたのは良かったです。
特に仮定の質問をよくしたり、他人の問題を手伝ったりする場合はさらに難しくなります。人間なら決めつけずに、「これは X の運用チームについての話ですか？規模はまだ Y ですか？」「このアプリも以前話した他のアプリのようにプロキシの背後にありますか？」といった確認質問をする可能性が高いでしょう。
こうしたコンテキストには、正しくモデル化しなければならない明確な階層構造もあります。たとえば、異なるルールが適用される複数のチームに同時に関わることがありますが、人間はこうしたことを自然に理解します。
記憶をオフにしても、一つの会話の中ではこういうことが起きます。
昔の会話から何かを覚えていて、こちらはもう成長して変わっているのに、それをずっと持ち出してくるうっとうしい友人みたいです。
本質的にはハードウェアの問題です。100万トークンは、人間が理解するようにコードベースを理解するには十分なコンテキストではありません。
選択的に忘れる能力は、潜在的には非常に価値があります。しかし今は、人間が何かのおおまかな形を覚え、それは興味深くないと判断し、さらにそれが興味深くないという事実を覚えている能力を代替する程度です。
記憶は人間が案内するときにだけ有用だと言いますが、正しい解決策はそれよりも深いところにあると思います。おそらく、コードベース全体とすべてのエージェントセッションをモデルのファインチューニングに入れる方向かもしれません。ただしその時点では、特定のセッションをモデルに入れないよう案内する必要があるかもしれません。あるいは必要ないかもしれず、苦い教訓が活かされるのかもしれません。