AIエージェントに1年分のニュースを読ませて4,500件の長期記憶を作って見えた課題
はじめに
LayerX Ai Workforce事業部でApplied R&D をしているtyoyoです。
AI Agentの長期記憶に関して様々な手法が提案されていますが、そのどれもが実際に長期間で運用されたことはほとんどないはずです。なぜなら、それらが台頭したのが最近だからです。
個人的に長期記憶についての肌感覚がなかったので、実験として「1年分のAIニュースの長期記憶」を作ってみることにしました。
最大6並列で約20時間、607回のセッション、4,552個のmemoryファイル ー 動かしてみないと分からない「長期記憶の課題」にぶつかるため、今回はこういった規模でシミュレーションを行いました。
Claude Codeを参考にした簡易的な長期記憶システムの作成
基本的にはClaude CodeのMemoryを参考に、以下のような frontmatter（ファイル先頭のメタデータ記述部分）つきのMarkdownファイルを1つの単位とします。これらが memory/ ディレクトリ以下に大量に配置されるシンプルな構成です。
memoryファイルの具体例
---
date: 2024-08-14
description: "GartnerによるPoC後に見送られる生成AIプロジェクトが30%に達するという2025年末予測、生成AIのROI・短期投資回収困難・データ品質・コスト問題、企業の生成AIPoC失敗率統計を調べている時。"
sources:
- https://atmarkit.itmedia.co.jp/ait/articles/2408/14/news067.html
related:
- 2024-08-07-gartner-ai-investment-business-fit-failure-4-reasons.md
---
# Gartner：生成AIプロジェクトの30%が2025年末までにPoC後に見送りになると予測（2024年8月）
Gartnerは2024年8月、生成AIプロジェクトの30%が2025年末までに概念実証（PoC）後に見送られると予測した。IT Mediaが同日付で報じた。
バイスプレジデントアナリストのリタ・サラム氏は、「生成AIの2023年の過熱ぶりを経て、経営幹部は投資に対するリターンを急いで求めているが、組織は価値を証明し実現することに苦戦している」と述べた。見送りの主な背景として、$500万〜$2000万規模のコスト、短期的なROIが出にくい構造、データ品質の問題が挙げられている。CFOは将来の間接的価値のために投資することに抵抗感を持ちやすいとされ、長期コミットより短期成果を優先する傾向がある。
一方で早期導入企業はビジネス改善を報告しており、Gartnerの2023年9〜11月に822人のビジネスリーダーを対象とした調査では、平均売上高15.8%増加・コスト15.2%削減・生産性22.6%向上という自己報告値が示されている。ただしサラム氏は「ビジネス価値の推定は容易でなく、企業・ユースケース・役割・人材によって大きく異なる」と留保している。
この記憶は、生成AIのPoC後廃棄率・ROI困難・コスト構造に関するGartnerの定量予測として位置づける。楽観的な効果数字と廃棄リスクの両方を持つ点が特徴。
生成AIプロジェクトの投資判断・経営説得・リスク評価の文脈でGartnerの見解を参照したい時に見るとよい。
記憶の追加については、qmem-add というSkillを作り、そこに保存すべきものや保存形式などの指示を記載しました。
記憶呼び出しは、qmem-search というSkillを作り、そこに4つのアクセス手段を提示しました。
- tobi/qmd を用いた検索（BM25（キーワードベースのランキングアルゴリズム）, ベクトル）
- description + ファイル名 の一覧を提示する qmem-ls コマンドによる、SKILL.md風遅延読み込み
- frontmatterのrelated によるグラフ辿り
- grep などを用いたキーワードマッチ
またHook を用いたリマインダーによる自動的な記憶呼び出しも作成しました。各ユーザーからのpromptとツールの呼び出し結果をクエリとし、BM25検索で一定の閾値を超えた場合に <qmem> {filename}: {description} </qmem> のようにAgentに記憶が提示されます。
Dreaming（記憶のライフサイクル管理）としては qmem-maintain Skillを作り、20セッションに1回 Agent自身に記憶の重複削除・古い記憶の更新・related フィールドを用いた記憶の関連付けを行いました。
Agentに1日で1年分のニュースを読ませる
データとしては LayerX AI・LLM Newsletter を60号分（2024年1月-2025年2月まで）使用しました。各Newsletterは平均2万文字、リンクとしては111個と大きなファイルです。Agentは10分割されたNewsletterファイルを読み込み、それぞれのニュースについて記憶を追加するように指示を受けます。
Claude Codeのデフォルト設定を使用し、モデルはSonnet 4.6 (200k) を利用しました。
Dreaming以外は6並列でまわし、およそ20時間程度かかりました。合計で607回のセッションが実行されました。まれにプロセスが固まってしまうため、Claude Codeの /loop を使い実験を監視・再開させていました。またそのClaude Code自体がレートリミットで落ちてしまうことがあったため、codexbar cli を用いてレートリミットがリセットされるタイミングで監視を蘇生させていました。実験はClaude Code Maxプランを用いて行いましたが、API換算だと合計で$407 かかっている計算です。
1年分の記憶をもつAgent
結果として4,552個のmemoryファイルが生成されました。これらの記憶をもつAI Agentに
「RAG の評価設計を相談したい。retriever / reranker / generator のどこから手を付けるべきか?」
と質問をしてみると、
...記憶によると（2024-08-19-aws-ragchecker-claim-level-rag-evaluation-framework.md）、
Amazon/AWS が 2024年8月に公開した RAGChecker は
「Retriever モジュールと Generator モジュールのそれぞれに対して独立した診断メトリクスを持つ」設計で、
個々の claim レベルで評価を行うことで「どのモジュールに問題があるかを切り分けられる」とされています。
8 つの RAG システムを評価した論文で、GitHub（amazon-science/RAGChecker）でオープンソース公開されています。...
のように、過去に読んだ記事をもとにした回答ができています。
Dreamingプロセスの分析
記憶のライフサイクル管理、Dreamingは計18回実行され、450件のファイルを更新・245件のファイルを削除しました。更新では主に記憶同士の関連付け（relatedフィールドの更新）、削除では主に重複した内容の削除（技術ブログとそれを題材にしたSNS投稿など）が行われていました。
またClaude自身が誤ったフォーマットでmemoryファイルを記述してしまい、それをDreamingプロセスで直しているケースも見受けられました。例えばファイル名だけを記述するように指示していたがファイルパスごと記述してしまったり、日付を書くように指定してたものの 2024-08 のように月までしか書いていなかったケースも有りました。これらを防ぐには、長期記憶のシステムにもハーネスのような可能な限りLLMではなくプログラムで守る仕組みが必要です。
個人的に残念だったのは、関連ノードのグラフがほとんど育たなかったことです。全ファイル中 related フィールドをもつのはわずか11.3%で、残りはほぼ孤立していました。もちろん全てのmemoryファイル自体に関連があるわけではありませんが、定性的に確認していても関連しているのにrelated ではないものが見受けられました。relatedを追加するかどうかのpromptは、もっと積極的にrelatedを追加せよ、と書くべきだったかもしれません。
またDreamingのプロセスは「新規追加されたmemoryファイルは全文読み込み、それ以外はfile名とdescriptionのカタログのみ読み込み」を行ってから関連記憶の紐づけを行っていたのですが、4,552ファイルの段階でこのカタログだけで200k contextの228% を占めてしまっていました。DreamingにおいてAgentに自身の記憶を修正させるのは強力ですが、その分扱えるmemoryファイルの数は有限で、「何を忘れるか」の設計も重要そうです。あるいはAgentを使わない埋め込みベースのライフサイクル管理や、階層的なデータ構造なども考えられます。
まとめ
実際に長期記憶の作成をシミュレーションしてみて感じたのは、動かしてみないと見えてこないことがたくさんあるということです。
構想段階では「どのベクトル検索ライブラリを使おうかな」「どんなデータ構造にしようかな」ということを考えていましたが、実際には「何を記憶するか」「いつ繋ぐか」などの細かいプロンプトの影響が大きかったです。またmemoryは容易に膨れ上がるので、「忘れさせる」という戦略をとるか、「スケールするようにする」という戦略の2軸があるように思いました。
この記事で紹介したR&Dチームの詳細はこちらです。