AIエージェントに1年分のニュースを読ませて4,500件の長期記憶を作って見えた課題
LayerX が AI エージェントに 1 年分のニュースを学習させて 4,500 件の長期記憶を作成した実験により、大規模な長期記憶システム運用における具体的な課題と実装の難しさを明らかにしました。
キーポイント
大規模長期記憶の実証実験
Claude Code のメモリ構造を参考に、最大 6 並列で約 20 時間かけて 1 年分の AI ニュース（4,552 ファイル）を読み込ませる実証を行いました。
長期記憶運用の課題浮き彫り
理論上の手法が実際に長期間・大規模で運用された例は少なく、本実験によって「動かしてみないと分からない」具体的なボトルネックや課題が可視化されました。
簡易的なシステム構成の採用
メタデータ（frontmatter）付きの Markdown ファイルを基本単位とし、memory ディレクトリ下に大量に配置するシンプルなアーキテクチャを採用しました。
Gartner調査による早期導入企業の成果と課題
早期導入企業では売上15.8%増やコスト15.2%削減などの報告がある一方、ビジネス価値の推定は複雑で状況依存であるという留保が示されている。
多様な検索手法と自動維持機能の実装
BM25やベクトル検索に加え、ファイル一覧表示やグラフ辿りによるアクセス手段を設け、定期的な重複削除・更新を行う自動化システムを構築した。
大規模データ処理におけるコストと時間の実態
1年分のニュース（60号分）を処理するために約20時間とAPI換算$407のコストがかかり、レート制限やプロセス固着への対策が必要だった。
Dreamingプロセスの運用課題と改善点
LLMによるフォーマット誤りへの対応にはプログラム層でのバリデーションが必要であり、関連付けプロンプトをより積極化することでグラフの成長を促すべきです。
重要な引用
AI Agent の長期記憶に関して様々な手法が提案されていますが、そのどれもが実際に長期間で運用されたことはほとんどないはずです
動かしてみないと分からない「長期記憶の課題」にぶつかるため、今回はこういった規模でシミュレーションを行いました
「ビジネス価値の推定は容易でなく、企業・ユースケース・役割・人材によって大きく異なる」
「合計で4,552個のmemoryファイルが生成されました」
DreamingにおいてAgentに自身の記憶を修正させるのは強力ですが、その分扱えるmemoryファイルの数は有限で、「何を忘れるか」の設計も重要そうです。
構想段階では「どのベクトル検索ライブラリを使おうかな」「どんなデータ構造にしようかな」ということを考えていましたが、実際には「何を記憶するか」「いつ繋ぐか」などの細かいプロンプトの影響が大きかったです。
影響分析・編集コメントを表示
影響分析
この記事は、AI エージェントの「長期記憶」分野において、単なる概念や小規模実験を超えた大規模実装における現実的な課題を初めて体系的に示した点で重要です。開発者や研究者に対し、長期記憶システムの設計時に考慮すべきパフォーマンスや管理コストなどの具体的な知見を提供し、今後の実用化に向けた道筋を示唆しています。
編集コメント
長期記憶の実装において、理論と実践のギャップを埋めるための貴重な実証データであり、大規模化に伴う課題解決への示唆に富んでいます。
はじめに
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チームの詳細はこちらです。
原文を表示
はじめに
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チームの詳細はこちらです。
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み