0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

AIエージェントにおけるMemory設計

0
Posted at
Page 1 of 14

はじめに

これまでの記事で、Harness、Loop Engineering、Evaluation、Context Engineering、Tool Engineeringと、AIエージェントを支える要素を一つずつ見てきました。

今回はMemory、つまりAIエージェントが情報をどう保持し、どう活用するかについて掘り下げます。前々回のContext Engineeringと近い領域ですが、Memoryは「情報をどう蓄積し、どこから引き出すか」という、もう少し長いスパンでの設計に関わる話です。


1. Memoryとは何か

AIエージェントにおけるMemoryとは、過去の情報を保持し、必要なときに取り出せるようにする仕組みのことです。

一回きりの対話であれば、Memoryはそれほど重要ではありません。しかし、複数のステップにまたがるタスクや、日をまたいで続くプロジェクト、繰り返し利用されるエージェントでは、過去に何が起きたのかを覚えていることが、判断の質を大きく左右します。

同じ質問を何度もされる、同じ間違いを繰り返す、以前決めたルールを忘れる。こうした問題の多くは、Memoryの設計が不十分であることが原因になっていることが多いです。


2. 「全部覚えさせればいい」わけではない

Memoryと聞くと、できるだけたくさんの情報を保存しておいたほうが安全、と考えたくなります。しかし実際には、それほど単純な話ではありません。

保存する情報が増えすぎると、後から必要な情報を探すコストが上がります。また、古くなった情報や、すでに状況が変わってしまった情報がそのまま残っていると、AIが誤った前提で判断してしまうこともあります。

重要なのは、何を保存するか、いつ保存するか、いつ取り出すか、いつ忘れるか、という4つの問いに、ある程度明確な方針を持っておくことです。


3. Memoryの階層

Memoryは一枚岩ではなく、いくつかの階層に分けて考えると整理しやすくなります。

短期コンテキストは、今まさに進行中のタスクに関する情報です。直近のやり取りや、今の作業状態が含まれます。

セッション履歴は、一つの対話やタスクの中での経緯です。何を試して、何がうまくいかなかったか、といった情報が該当します。

長期メモリは、セッションをまたいで保持しておきたい情報です。ユーザーの好みや、繰り返し発生するルールなどが含まれます。

プロジェクト知識は、特定のプロジェクトに固有の、比較的安定した情報です。仕様や設計方針、過去の意思決定などがここに含まれます。

このように階層を分けておくと、どの情報をどのタイミングで参照すべきかが整理しやすくなり、Context Engineeringとの連携もスムーズになります。


4. 何を保存すべきか

すべての出来事を記録する必要はありません。保存する価値がある情報には、いくつかの傾向があります。

繰り返し参照されそうな情報は、保存しておく価値が高いです。一度しか使わない一時的な情報を無理に残す必要はありません。

失敗や意思決定の経緯も、保存しておく価値があります。同じ失敗を繰り返さないためには、何がうまくいかなかったのかという記録が役立ちます。

逆に、機密性の高い情報や、すぐに古くなる情報は、保存する範囲や期間を慎重に決める必要があります。


5. いつ保存し、いつ取り出すか

保存のタイミングも重要な設計ポイントです。

すべてのやり取りをその都度保存するのではなく、意味のある区切り、例えばタスクが完了したタイミングや、重要な意思決定がなされたタイミングで保存する、という考え方があります。逐一保存してしまうと、後から重要な情報を見つけ出すのが難しくなります。

取り出すタイミングについても同様です。常にすべてのMemoryを参照するのではなく、今のタスクに関連しそうな部分だけを検索して取り出す、というRetrievalの発想がここでも使われます。


6. いつ忘れるか

意外と見落とされがちなのが、忘れることの設計です。

情報が古くなった場合、状況が変わった場合、あるいは単に参照される頻度が下がった場合、その情報を積極的に整理していく仕組みがないと、Memoryはどんどん肥大化していきます。

すべてを永久に保存するのではなく、一定期間参照されなかった情報を要約して圧縮する、重要度の低い情報を削除する、といった仕組みを組み込んでおくと、Memoryが健全な状態を保ちやすくなります。


7. MemoryとContextの関係

以前の記事でも触れましたが、MemoryとContextは近い概念でありながら、役割が異なります。

Memoryは、情報を保存し引き出す仕組み全体を指します。Contextは、その中から実際にAIへ渡される、今この瞬間の判断材料を指します。

Memoryにどれだけ豊富な情報が蓄積されていても、それを適切なタイミングでContextとして渡せなければ、AIはその情報を活用できません。逆に、Memoryの設計が雑だと、そもそも良質な情報が蓄積されず、Contextとして渡す材料自体が不足してしまいます。この2つは切り離さず、セットで設計する必要があります。


8. 個人の好みとプロジェクトの知識を分ける

実際にMemoryを設計するとき、性質の異なる情報を混ぜてしまうと、扱いにくくなることがあります。

例えば、ユーザー個人の好みや傾向に関する情報と、プロジェクト固有の仕様やルールに関する情報は、別々のカテゴリとして管理したほうが見通しがよくなります。前者はユーザーが変わっても、後者はプロジェクトが同じ限り引き継がれるべき情報だからです。

このように情報の性質ごとにカテゴリを分けておくと、必要なときに必要な種類の情報だけを取り出しやすくなります。


9. Memoryが機能しないとどうなるか

Memory設計が不十分な場合、いくつかの分かりやすい症状が現れます。

同じ質問を繰り返しても、AIが以前答えた内容を踏まえずに一から考え直してしまう。以前指摘したミスを、また同じように繰り返してしまう。プロジェクト固有のルールを、都度説明し直さなければならない。

こうした症状が出ているとき、多くの場合は、Memoryそのものが存在しないか、あるいは存在していても適切なタイミングで参照されていない、という状態になっています。


10. まとめ

Memoryは、AIエージェントが過去の経験を今の判断に活かすための仕組みです。短期コンテキスト、セッション履歴、長期メモリ、プロジェクト知識という階層で情報を整理し、何を保存し、いつ取り出し、いつ忘れるかを設計しておくことで、AIエージェントは一回きりの対話では得られない一貫性を持てるようになります。

MemoryはContextと切り離せない関係にあり、両方を意識してはじめて、AIが本当に過去の情報を活用できるようになります。地道な設計の積み重ねですが、AIエージェントを「毎回ゼロから考える存在」から「経験を積み重ねる存在」に変える、重要な部分だと感じています。

次回は、AIエージェントが何をしたのかを追跡する、Observability設計について掘り下げていきます。


関連記事

  • AIエージェントで本当に重要なのはLLMではない?Harness EngineeringとLoop Engineeringから考える次世代AI開発(全体像)
  • Harness Engineeringとは何か?AIエージェントの性能を決める「実行環境」の設計
  • Loop Engineeringとは何か?AIエージェントを「失敗から改善するシステム」に変える方法
  • AIエージェントの評価(Evaluation)設計入門
  • Context Engineeringとは何か?AIエージェントに「何を見せるか」を設計する
  • AIエージェントのTool Engineering入門
  • AIエージェントのObservability設計(次回予定)

Tags

AI AIエージェント Memory LLM AgenticAI

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?