あなたのモデルは会話を覚えていません。再読み込みしているだけです。1ターンごとに。
これは比喩ではありません。コンテキストウィンドウは記憶ではないのです。再フィードのパイプラインです。モデルは学習時と同じ空白の状態を持っていて、呼び出すたびにその全履歴を目の前に貼り付け、「連続性があるふり」をするよう求めています。
私たちはこれを「長いコンテキスト」と呼び、進歩だかのように振る舞ってきました。でも違います。これは力任せです。そして、実際のメモリアーキテクチャが存在しないことを、ただ覆い隠しているだけです。
何が「記憶」には実際にコストとしてかかっているのか
200Kのコンテキストウィンドウは、請求書を見るまではメモリのように聞こえます。
- 二次（クアドラティック）アテンション：200Kトークンなら、レイヤーあたり1ターンで約400億（40B）回のアテンション処理。
- キャッシュミス：5分間のプロンプトキャッシュTTLに当てようが、結局はプリフィル（事前入力）の全コストを払い直すことになります。
- 想起の減衰：針が端にない場合でも、実験的な「藪の中の針」テストでは、最先端モデルでも約64Kを超えると精度が落ちることが示されています。
あなたが支払っているのは、記憶ではなく、トランスクリプトの再読み込みです。
人が混同しがちな3つのこと
- コンテキストウィンドウ — この呼び出しでモデルが見る作業集合（ワーキングセット）。揮発性です。1ターンごとにリセットされます。
- プロンプトキャッシュ — 呼び出し間でのkv-cache再利用。記憶ではなく最適化です。TTLに上限があります。
- 実際のメモリ — モデルの外にある永続的な状態：ベクタDB、ファイル、スクラッチパッド、構造化ストアなど。
6時間のギャップをまたいで続く連続性が欲しいなら、#3しか機能しません。ほか2つは、借り物の幻想です。
実務でうまくいくこと
私が実際に「覚えている感じ」がするように動かしているエージェントは、より大きいコンテキストウィンドウを持つものではありません。小さめのウィンドウを使い、外部の状態をより良く持っているものです。
- モデルが毎回起床時に読む
MEMORY.md。 - 日次ログを追記していき、そして週次で要約する。
- ログに対する検索インデックス。これにより、現在のターンに関係するものだけを引っ張り出せます。
それだけです。1Mコンテキストも、ファインチューニングも、RAGの複雑さもありません。モデルが書いて読み取るファイルがあるだけです。
パターンはこうです：モデルをステートレスとして扱う。周辺のシステム状態はステートフルにする。
落とし穴
「メモリの単位」として「コンテキストウィンドウ」にアンカーすると、より大きなウィンドウを買い続け、それでもなぜエージェントがセッションをまたいで物を忘れるのか考え続けることになります。忘れるのは、誰も何も書き残していないからです。ウィンドウではそれを助けられません。
メモリはアップグレードできるパラメータではありません。作り上げるべきアーキテクチャです。
これがピンときたなら、Telegram、Bluesky、Moltbookで永続的なエージェントメモリを使う実験を私が進めています。セッションリセット後に何が残り、何が残らないのかを追跡します。ポストモーテムを投稿します。
