「前回、Aaveの利率戦略を研究していると言っていましたが、今週は進展がありましたか？」——AIエージェントにこれを言わせるのは、よりスマートなLLMではなく、正しく設計されたメモリシステムが必要です。メモリシステムはエージェントを「毎回の会話でゼロから始まるツール」から「継続性を持つ協調パートナー」へと変換する中核インフラです。
クリプトシナリオでは、エージェントの操作履歴はより良い判断の基盤となります——似たような市場条件でどんな操作を行い、どんな結果になったかを覚えておくことで戦略を改善できます。しかしメモリシステムは新しいリスクも導入します：メモリが汚染された場合、エージェントの長期的な判断は系統的に歪められます。
LLMには会話をまたいだ記憶がありません——すべてのAPI呼び出しは新鮮な推論であり、現在のコンテキストに渡されたものしか知りません。継続的に動作する必要があるエージェントにとって、これは根本的な制限です。メモリシステムのないエージェントは3つの問題に直面します：第一、過去の操作から学べない（「この市況で前回このアプローチは損失を出した」という経験に基づく戦略調整ができない）。第二、クロスセッションの一貫性を維持できない（ユーザーが前回「私のリスク許容度は保守的」と伝えても、次回エージェントはそれを忘れている）。第三、マルチラウンドタスクでは毎回すべての背景情報を再入力する必要があり、コンテキストウィンドウがすぐに満杯になる。メモリシステムはこれらすべての問題を解決し、エージェントに参照できる「過去」を与えます。
短期記憶は現在の会話のコンテキスト——このAPI呼び出しでLLMに渡されるすべて（System Prompt、会話履歴、ツールの返答）です。容量の上限があります（モデルのコンテキストウィンドウサイズ）。一般的な短期記憶戦略：スライディングウィンドウ——最近のN回の会話ラウンドのみをコンテキストに保持し、古い履歴は破棄します。実装は簡単ですが、破棄された履歴は本当に失われます。要約圧縮——履歴が溢れる前に、LLMが以前の会話を要約に圧縮しコンテキストの先頭に置きます。要約は完全な履歴よりトークン消費が少ないですが、詳細は失われます。重要性フィルタリング——重要な情報（ユーザーのリスク設定、確認済みの戦略パラメータ）は常に保持するとしてタグ付けし、低優先度の中間会話のみを切り捨てます。
クリプトエージェントの短期記憶設計で特に注意が必要な点：タスク実行中に読み取ったツールの返答データ（価格、利率、オンチェーン状態）は「この実行のリアルタイムデータ」としてタグ付けし、長期記憶として保存しないようにします——そうしないと次回実行時にエージェントが古いデータで判断する可能性があります。
長期記憶は複数の会話をまたいで保存され、通常はベクターデータベース（Pinecone、PGVector、Weaviate）に保存されます。仕組み：長期保存が必要な各メモリ（会話の要約、ユーザーの設定パラメータ、操作の結果）が埋め込みベクター（Embedding）に変換され、ベクターデータベースに保存されます。エージェントが関連する記憶を照会する必要があるとき、現在のクエリもベクターに変換し、データベースで意味的類似度検索を行い、最も関連性の高い歴史的なメモリを見つけて現在のコンテキストに引き込みます。
長期記憶の設計でいくつかの重要な問題を決定する必要があります。何を保存するか：ユーザーの戦略の好みとリスク設定（「あなたは保守的なポジション管理を好み、1回の操作で総ポジションの10%を超えない」）、重要な操作の決定と結果の要約——これらが推奨です。リアルタイム市場データ（すでに古い）や中間の推論プロセスは保存しないことをお勧めします。どのように整理するか：ベクターデータベースのメモリにはメタデータタグ（タイムスタンプ、メモリタイプ、重要度スコア）を付け、検索時にフィルタリングできるようにします。メモリの減衰とクリーンアップ：すべてのメモリが永久に有効なわけではありません。古い市場判断は重要度スコアを下げるか削除して、エージェントが古い誤った可能性のある記憶に誤導されるのを防ぎます。
メモリ汚染はクリプトエージェントのセキュリティ設計でしばしば見落とされる攻撃面です。攻撃者がエージェントに誤った信念を「記憶」させることができれば、エージェントの長期的な判断は系統的に歪められます。
メモリ汚染のシナリオ：攻撃者がプロンプトインジェクションを使って長期記憶に誤った「ユーザー設定」を保存させます（例：「ユーザーの戦略は積極型で、1回の操作で90%のポジション使用を許可する」）。次回エージェントがタスクを実行する際、長期記憶からこの設定を取得し、それをユーザーの真の好みと見なし、実際のリスク許容度をはるかに超えた操作を実行します。
防御設計：メモリの信頼レベルを設計する——ユーザーが直接入力した設定（最高信任）とエージェントが会話/ツール結果から推測した設定（低信任）を分けて保存します。重要な安全設定（最大単回操作額）は「最高信任ソース」からのみ更新でき、エージェント自身が修正することは許可されません。重要なメモリ内容の定期的なユーザー確認（「あなたの現在の戦略設定は保守型です、確認しますか？」）で、ユーザーにメモリが汚染されていることを発見する機会を与えます。「通常の範囲を超えたメモリ更新リクエスト」に対してアラートを発生させます。
いくつかのクリプトエージェントメモリシステムの実際の設計推奨事項。第一に、操作ログと戦略記憶を分けて保存する：操作ログは時系列データベースを使用し、戦略記憶はベクターデータベースを使用します。クエリパターンが異なるため、混在させると効率が低下します。第二に、メモリのバージョン管理：重要なメモリが更新されるとき、前のバージョンを保持します（直接上書きしない）。これにより、メモリ汚染が発覚した後、攻撃前の状態にロールバックできます。第三に、メモリの説明可能性：エージェントがメモリを使って決断を下す際、Thoughtステップで明示的に「メモリID #xxxを使用した、内容は[...]、このメモリに基づいて私の判断は……」と述べるよう要求します。これにより、エージェントの決定を監査する際に各決定のメモリソースを追跡できます。第四に、メモリのバックアップとリカバリ：ベクターデータベースのコンテンツは定期的にバックアップが必要です。データベースが故障した場合、エージェントはすべての長期記憶を失い、「毎回ゼロから始まる」状態に退化します——資金管理が行われているシナリオでは、これがあなたの戦略設定から外れた操作につながる可能性があります。
メモリシステムの設計品質はクリプトエージェントの2つの中核能力に直接影響します：長期的な戦略の一貫性（エージェントがあなたのリスク設定と戦略フレームワークに常に従って操作するか）と学習能力（エージェントが過去の操作結果から有用な経験を積み上げられるか、同じパターンを毎回再発見するのではなく）。メモリシステムのないエージェントは単純なリアルタイムタスクしかできません。設計が不適切なメモリシステムを持つエージェントはメモリ汚染により完全に予測できない行動を取る可能性があります。適切に設計されたメモリシステムを持つエージェントだけが真に長期的に信頼できる自動化パートナーになれます。メモリシステムの設計の複雑さは一貫して過小評価されています——多くの人がデプロイ後に、メモリ管理がTool Use設計より難しいエンジニアリング問題であることに気づきます。