AIエージェントに1年分のニュースを読ませて4,500件の長期記憶を作って見えた課題

• URL: https://tech.layerx.co.jp/entry/ai-agent-long-term-memory-simulation
• 日付: 2026-06-03
• Tier: Tier 3
• 要旨: LayerX AI Workforce 事業部が、Claude Code の Memory 機構を参考に構築した長期記憶システムで 1 年分の AI ニュース（60 号分）を処理し、4,552 件の記憶ファイルを生成。実スケールで動かして初めて見えた課題（コンテキスト枯渇・グラフ未成長・フォーマット崩れ）を詳細にレポート。

詳細

• 実験規模: 最大 6 並列・約 20 時間・607 セッション・4,552 メモリファイル生成
• コスト: Claude Code Max プラン、API 換算で約 $407
• モデル: Claude Sonnet 4.6（200k コンテキスト）
• システム構成（Claude Code Memory を参考）:
  • frontmatter 付き Markdown ファイル 1 つが 1 記憶単位
  • qmem-add Skill: 記憶の追加
  • qmem-search Skill: BM25＋ベクトル検索、ファイル名/description カタログ (qmem-ls)、グラフ辿り、grep
  • Hook によるリマインダー: ユーザー prompt と tool 結果をクエリに BM25 検索し、閾値超えで <qmem> 注入
  • Dreaming (qmem-maintain) Skill: 20 セッションに 1 回、重複削除・古い記憶更新・related 更新
• Dreaming 結果: 18 回実行、450 件更新・245 件削除（主に重複削除）
• 発見された課題:
  1. コンテキスト枯渇: 4,552 ファイルのカタログだけで 200k コンテキストの 228% を占有。Dreaming 自体がスケールしない
  2. グラフ未成長: related フィールドを持つファイルがわずか 11.3%。関連があるのに紐づいていないケースを多数確認。プロンプトの積極性不足
  3. フォーマット崩れ: ファイル名のみ指定するところにパスを記述、日付を月までしか書かない等。Dreaming が修正するが、LLM 依存ではなくハーネス側でバリデーションが必要
• 教訓: 記憶設計よりプロンプトの細部（いつ繋ぐか・何を記憶するか）の影響が大きい。「忘れさせる戦略」vs「スケールさせる戦略」の 2 軸で設計を決める必要がある