「プロンプトエンジニアリング」「コンテキストエンジニアリング」に続く第3の波「メモリエンジニアリング」とは？
メモリエンジニアリングの話に入る前に、小川氏は2つの前提を示した。
前提の1つ目は「LLMは関数のようなもの。記憶する機構を実装しなければ何も覚えない」。LLMにトークンを入力すると、トークンが出力される。ここで過去の入力を反映した内容が出力されるのは、都度プロンプトを付加しながら“覚えているように”振る舞わせているだけで、実際にはLLMが自然と継続的に学習しているわけではない。新規セッションのたびに一度すべてリセットされる。コンテキストウィンドウは「一時的な作業メモリ」なのだ。
前提の2つ目は「LLMのコンテキストウィンドウは指数関数的に拡大している」。約1年前までは数千から数万トークンが限界だったが、現在では10万から100万トークンまで保持できるようになっており、LLMの“短期記憶”は飛躍的に拡張された。
しかし、その一方で、「『単にコンテキストを増やすだけでは性能は向上しない』と、広く知られている」と小川氏は指摘する。多くのコンテキストを記憶させると、性能が低下することは複数の論文で明らかになっている。その理由は、次の4つだ。
1つ目に「Context Poisoning（文脈の汚染）」がある。これは、会話履歴の中の古いコンテキストが残り続け、ノイズを含んだツール結果が混在してしまう事象だ。結果として、長い履歴の一部が誤解釈される。
2つ目に「Context Distraction（文脈の注意散漫）」だ。関係ないログが多数混ざることで、必要な情報が埋もれて見つからず、推論の優先度判断が曖昧になる。
3つ目に「Context Confusion（文脈の混乱）」。過去の回答と現在の回答が食い違い、反対の指示が混ざる。あるいは似た文章が複数あり、照合が乱れることがある。
そして、最後に「Context Clash（文脈の衝突）」を挙げた。異なるツールの結果が食い違うことで、会話の前後で条件が変化。RAGと履歴が矛盾してしまう。
その解決策を探るために、ここで改めてAIエージェント開発の主流にこれまでどのような開発手法があったのか、振り返ってみよう。
まずは、プロンプトエンジニアリングが話題になった。Chain-of-ThoughtやFew-shot Learningなどを用いて、一問一答の精度向上を目指す、“何を聞くか”を設計するアプローチだ。
次に波が来たのは、コンテキストエンジニアリングだ。RAGやFunction Callingによって、「今この瞬間」の情報最適化を図る、“何を渡すか”を設計するものである。
そして現在、一部の界隈でじわじわと注目され始めているのがメモリエンジニアリングだ。メモリの中で“何を覚え、何を忘れ、何を思い出すのか”を設計する、蓄積・忘却・想起の最適化のアプローチだ。
では、なぜ今、メモリエンジニアリングが注目され始めているのか。その理由を次に詳しく見ていく。
