【geek-terminalニュース】10Mトークン時代のエージェント記憶設計、全部突っ込む派を卒業せよ

【事象の全貌と背景】
以前お伝えしたRAG、State in Payload、エージェント経年劣化の続報です。今回の焦点は、AIエージェントの長文記憶をどう設計するか。編集部的に一番おいしいポイントは、10Mトークン級の巨大コンテキストが見えてきても、現場の勝負は全部突っ込めるかではなく、何を短期状態に置き、何を検索対象にし、何を要約し、何を永続記憶として更新するかに移っていることです。

公式に確認できる範囲では、Databricksはエージェント記憶を、以前の会話や過去の会話から得た情報を保持し、後続の応答や行動で利用できる仕組みとして説明しています。さらに、ユーザーの嗜好、過去の決定、セッションをまたいだ文脈、複数エージェントやプロジェクト間で共有される知識を扱うものだと整理しています。つまり記憶とは、チャット履歴の倉庫ではなく、次の行動を変える状態管理レイヤーです。

一方で、検索結果1で紹介されているPokee-Isaac 28BやTencentDB Agent Memory v2.0の具体的な主張は、公式裏取りではなく報道ベースとして扱う必要があります。Pokee AIのPokee-Isaac 28Bは、10Mトークンのコンテキスト、28B規模、顧客境界内、VPC、オンプレミス、デバイス上での運用可能性を掲げるモデルとして紹介されています。Tencent Cloudについても、TencentDB Agent Memory v2.0をAIコーディングエージェント向けのチームレベル記憶ハブとしてオープンソース化したと報じられています。ただし、ここで断定すべき核心は個別製品の優劣ではありません。巨大文脈と永続記憶基盤が同時に話題化し、エージェント記憶がモデル性能ではなくデータ設計の問題として前面に出てきた、という構図です。

【技術的ディープダイブ】
公式・学術系の整理では、記憶は大きくエピソード記憶と意味記憶に分かれます。Databricksは、エピソード記憶を会話ログやユーザーフィードバックのような生の相互作用、意味記憶をそこから蒸留された再利用可能な事実やルールとして説明しています。これは実装者にとってかなり重要です。会話ログは、何が言われたかの証跡です。しかしエージェントが再開時に本当に欲しいのは、何を決めたか、何が終わったか、どの制約が有効か、次に何をすべきかです。

Microsoft Foundry Agent Serviceの公式ブログも、長期記憶ストアをセッション、デバイス、ワークフローをまたいでチャット要約、ユーザー嗜好、重要文脈を保存、検索、管理するものとして説明しています。想起時にはハイブリッド検索で関連記憶を取り出す設計だとされ、これは長文を常に全量投入する方式ではなく、必要な記憶を検索してコンテキストに戻す方式です。Semantic KernelのAgent Memoryは実験的機能として警告付きで扱われており、この領域がまだ固定仕様ではなく、評価とフィードバックで変化していることも見逃せません。

ここで10Mトークン文脈の意味を冷静に見る必要があります。報道ベースではPokee-Isaac 28Bが10Mトークン文脈を掲げ、単一GPUやRTX 4090相当からの運用可能性も紹介されています。もし長文を保持できるならRAGはいらないのでは、という雑な発想が出てきますが、実務では逆です。巨大コンテキストは入力上限の痛みを減らしますが、古い決定と新しい決定の衝突、情報の鮮度、削除権、チーム共有、証拠への戻り道、監査可能性までは自動で解きません。

だから記憶設計はDB設計に近づきます。短期記憶は現在の作業に必要な状態をコンテキストへ載せるキャッシュ。長期記憶は過去セッションから抽出した嗜好、決定、事実、手順を保存する永続ストア。ベクトル検索は意味的に近い記憶を探す索引。知識グラフは出来事や人物や決定同士の関係を表す構造。要約は圧縮ですが、証拠リンクなしの要約は劣化した伝言ゲームになります。学術ソースでも、エージェント記憶は単一推論ステップを超えて累積状態を維持する永続的なデータ管理オブジェクトと定義され、未構造の観測から構造化された記憶単位へ変換するライフサイクルが論じられています。

【コミュニティの生々しい熱量と議論】
Reddit側の温度感は、派手な10M文脈礼賛よりもかなり実務寄りです。r/AI_Agentsでは、長期コンテキストを必要とするエージェントで記憶をどう扱うかという相談が出ており、単なるチャット履歴保存では足りないという問題意識と整合しています。別のReddit投稿ではTencentDB Agent Memoryについて、単純に埋め込みを保存して後で検索する層というより、構造化されたローカル記憶システムに見える、という反応が出ています。

特に面白いのは、階層化への反応です。コミュニティコメントでは、下層に生の会話や詳細があり、その上にatoms、scenes、persona風の要約が載り、元証拠へ戻るパスがある点が注目されています。これは単純なベクトルストア記憶より、なぜエージェントがそれを覚えていたのかをデバッグしやすい、という評価につながっています。一方で、トレードオフとしてエコシステムと複雑性が増すとも見られています。

この反応はかなり現場っぽいです。軽いユーザー嗜好やシンプルなチャット履歴だけなら、ローカルのSQLite、Redis、ベクトルDB、あるいは単純なJSONでも足ります。しかし、長く走るコーディングエージェント、チームで共有されるプロジェクト文脈、複数セッションをまたいだ意思決定、監査ログまで必要になると、記憶は急にプロダクトの中核DBになります。Redditのコメントにも、ローカルで長時間走るエージェントワークフローには向くかもしれないが、軽量な好み保存には過剰かもしれない、という冷めた評価が混じっています。この冷静さが重要です。

【今後の展望とエコシステムへの影響】
この流れでオワコン化しそうなのは、チャット履歴を丸ごと保存して記憶と呼ぶだけの実装です。次に厳しくなるのは、ベクトルDBに全部投げて類似検索すれば長期記憶になる、という雑なRAG万能論です。これから強いエージェント基盤は、記憶の型、スコープ、鮮度、証拠、更新ルール、削除ルール、アクセス権を持つはずです。

逆に伸びるのは、記憶をデータプロダクトとして扱うスタックです。ユーザー単位の記憶、プロジェクト単位の記憶、チーム共有の組織知識、セッション内の短期状態を分け、必要なものだけをハイブリッド検索で呼び戻す。さらに、要約された意味記憶から元のエピソード記憶へ戻れるようにする。これはデバッグ、監査、セキュリティ、コンプライアンスにも効きます。

10Mトークン文脈モデルの登場が本当に重要なのは、RAGや記憶DBを不要にするからではありません。むしろ、巨大文脈、検索、要約、永続記憶をどう組み合わせるかという設計空間を広げるからです。長文を読めるモデルは強力な実行エンジンになります。しかし、何を覚え、何を忘れ、何を証拠付きで再利用するかを決めるのは、モデルではなくアーキテクチャです。エージェントの記憶は、もはや便利機能ではなく、AIアプリのデータベース設計そのものになりつつあります。