AIエージェントのメモリ：永続的なコンテキストを持つAIエージェントの構築方法

新しい同僚を6か月間、毎朝プリンターまで案内しなければならないとしたら、さすがに心配になるでしょう。これまでの案内をすべて完璧に暗唱できるのに、それでも付き添いが必要だとしたら、記憶力は抜群です…それでも、あなたは毎回席を立つことになります。

現在のAIエージェントのメモリは、この終わりのないプリンター案内のような状態にあります。LettaのCEOであるCharles Packer氏はThe New Stackで、メモリのベンチマークは想起を測定しているため飽和状態にあり、想起はすでに解決済みだと述べています。未解決の課題は、再トレーニングを一切行わずに、保持するコンテキストを通じてエージェントが仕事の腕を上げていくことです。

共同創業者のSarah Wooders氏は、これを仕事を始めたばかりの状態にたとえています。ベンチマークは必要なコンテキストをすべてエージェントに渡したうえで、互いに無関係なタスクを次々とこなさせるもので、人の働き方とはまるで違います。新入社員ならプリンターまでの案内が必要かもしれません。しかし3年も経てば、席を立たずに一行の指示を渡すだけで済むようになってほしいものです。

これこそが目指すべき水準であり、Perplexity Computer向けの自己改善型メモリシステムBrainの狙いでもあります。Brainは過去の作業や修正内容を、進化し続けるナレッジwikiへと整理します。

本記事では、エージェントが何を記憶すべきか、そしてそれがエージェントの仕事の質を高めるかどうかをどう検証するかを解説します。

AIエージェントのメモリとは？

AIエージェントのメモリとは、エージェントが過去のやり取りや作業から保持する情報と、それを更新・活用するための仕組みのことです。永続的なメモリコンテキストがその情報をセッションをまたいで引き継ぐため、会話を閉じても次のタスクをゼロから始める必要はありません。

その名のもとに提供されているものの多くは、ユーザーについて記憶するものです。好み、連絡先、役割、PNGではなくPDFが欲しいという事実などです。これは簡単なほうの半分にすぎません。

Perplexity Computerを支えるメモリシステムであるBrainを構築した際、私たちは作業そのものに焦点を当てました。どのアプローチが成功したのか？どの情報源で20分を無駄にしたのか？エージェントが完了を告げた後に、何を修正しなければならなかったのか？その履歴が、次のタスクのより良い出発点になります。

Brainはこの情報をエージェントのサンドボックス内にファイルとして保存し、次の3つの層に整理しています。

• sessions/には、生のトランスクリプトとその要約が保存されます。
• notes/には、要点を抽出した情報がトピック別に整理されて保存されます。
• knowledge/にはwiki本体が保存されます。人物、プロジェクト、概念に関する、相互にリンクされたMarkdownページです。

ただし、これらが自然に改善されることはありません。夜間には「Dream」と呼ぶバックグラウンドエージェントがその日のセッションを読み込んで要約し、状況が変わった箇所のwikiを修正します。私たちはこうした編集をステージングして確認してからGitでコミットしているため、何かおかしいと感じたときには確認できる差分が残ります。

では、それによってエージェントの仕事ぶりは向上するのでしょうか？30日間のペア評価では、Brainを有効にしたセッションは正確性が9.3ポイント、再現率が8.9ポイント向上し、トークン使用量は約15%減少しました。

拡大

出典：X

エージェント型メモリにはどのような種類があるのか？

大きく分けて2種類あり、その分け方は人間の場合とよく似ています。今まさに頭の中に保持しているものと、来月になってもまだ覚えているものです。

短期記憶

短期記憶は、現在の会話やタスクのコンテキストを保持します。あなたのリクエスト、直近のメッセージ、ツール呼び出しの結果、エージェントが開いたばかりのドキュメントなど、次に何をすべきかを判断するのに十分な情報です。

これはワーキングメモリとも呼ばれます。LLMの場合、コンテキストウィンドウには特定のモデル呼び出しの間に利用できる情報が保持されます。アプリケーションは追加のタスク状態を管理し、各ステップでどの部分を渡すかを決めることもあります。

また、短期だからといって使い捨てとは限りません。フレームワークは会話の状態を保存し、翌日に再開できます。それでもその情報はそのスレッドに属したままです。ただし、別のタスクがその情報を使えるかどうかは、また別の設計上の判断です。

長期記憶

長期記憶は、セッションをまたいで情報を利用できるようにします。CoALAの論文は認知科学から3つのカテゴリーを借用し、経験とノウハウを語るための語彙をエージェントの開発者に提供しました。

• エピソード記憶は、何が起きたかの記憶です：過去のセッション、エージェントが実行した手順、得られた結果などが含まれます。Brainでは、sessions/が生のトランスクリプトとその要約によってこの履歴を提供します。
• 意味記憶は、エージェントが真実とみなすものです：会話から抽出された、ユーザーやそのプロジェクト、その人を取り巻く世界に関する事実などがこれにあたります。Brainのknowledge/のwikiは、この種の情報を根拠へのリンクとともに保持します。
• 手続き記憶は、物事のやり方です：プロンプト、再利用可能なワークフロー、そして仕事に必要な指示とツールをエージェントに与えるためにPerplexityが構築するスキルなどです。メモリと呼んでいないだけで、すでにこうしたものをお持ちかもしれません。

興味深いのは、層と層のあいだで起きることです。セッションには、あなたがPNGを却下したことが記録されます。PDFを使うようにというあなたの指示は、エージェントが今後も引き継げる好みになります。エクスポート手順への修正は、次回から従える手順になります。

「これが起きた」から「これは真実だ」、そして「これがやり方だ」への変換こそが、冒頭で取り上げた学習の課題の一部であり、Brainが夜間に実行するDreamエージェントが力を注いでいる部分です。

共用キッチンで誰かが魚を電子レンジで温めたとしましょう。苦情が出て、窓が開けられます。やがて「魚禁止」の貼り紙が現れます。

6か月後、当の本人はすでに退去していますが、貼り紙は残っています。これが永続性です。メモリの種類は、何が残るかという観点から説明できます。

• ワーキングメモリは、昼食を作りながら把握していること、たとえば「スープをかき混ぜなければ」といったことです。
• エピソード記憶は、魚の一件そのものです。廊下まで皆についてきた、あのにおいです。
• 意味記憶は、そこから得た知識です。共用キッチンで魚を温め直すと、においがいつまでも残ることがある、ということです。
• 手続き記憶は、次に何が起こるかを左右する指示です。ここで魚を電子レンジで温めないこと。貼り紙があれば、一件をまったく知らない人でもルールに従えます。

もう1つ区別があります。私たちが構築するものに関わるからです。2025年12月に初めて公開されたサーベイ論文『Memory in the Age of AI Agents』は、短期か長期かだけでは不十分だとして、メモリを形態によっても分類しています。

• トークンレベル：エージェントが読み取る明示的なコンテンツです。ファイル、保存されたレコード、取得されたチャンクなどがこれにあたります。
• パラメトリック：学習済みの重みにエンコードされた情報です。更新するにはトレーニングやモデル編集の手法が必要です。
• 潜在：読み取り可能なテキストとして書き出されることなく、内部表現に保持される情報です。

ここではトークンレベルのメモリ、つまりモデルの外部に保存され、必要に応じてコンテキストに読み込まれる情報に焦点を当てます。BrainのMarkdown wikiはその一例です。

拡大

ページを更新すると、エージェントが次のタスクで読める内容は変わりますが、基盤となる重みは変わりません。これが冒頭で紹介したPacker氏の指摘です。つまり、再トレーニングなしに、エージェントが保持するコンテキストを通じて向上していくということです。

エージェントの各種メモリはどのように連携するのか？

エージェントは以前の試行を振り返り、どこで失敗したかを確認し、その後にあなたが与えた指示を読み込むことができます。1つのタスクには複数の種類のメモリが関わっていますが、それぞれが順番を待つ必要も、個別のデータベースを持つ必要もありません。

ここでは、会話の終了後に何が利用可能なまま残るかを永続性が決め、エージェントがそれを再び目にするかどうかを取得が決めます。

Brainでは、教訓から根拠へとさかのぼる経路を保持しています。たとえば、先週のプロジェクトの続きをComputerに頼んだとしましょう。

• Brainのインデックスによって、どのメモリページが存在し、どこにあるかがわかります。
• Brainはプロジェクトページを開き、保存された決定事項や指示を読み取ります。
• あなたがあるアプローチを却下したとメモに書かれていれば、エージェントはその引用をたどって会話にさかのぼり、理由を確認できます。

関連ページへのリンクを使って、関係する人物や他のプロジェクトを調べることもできます。エージェントはこれを、ファイルの読み取りと検索によって行います。たとえばgrepを使えば、プロジェクト名でその言及箇所を見つけられます。

また、ファイルを探索できることでエージェントが何を得られるのかも検証しました。150件の金融文書に関する質問を用いた社内ベンチマークでは、標準的なファイルツールを使う探索エージェントの回答スコアが0.627だったのに対し、同じコーパスに対するセマンティック検索では約0.37でした。

拡大

出典：X

AIエージェントのメモリを改善するには？

OrogatとMansourによる2026年5月の論文は、エージェントのメモリで繰り返し起こる4つの失敗を挙げています。ストアが肥大化し続けること、古くなった認識が修正されないこと、容量が尽きると情報が忘れられること、そして取得が読み取るだけで、そのアクセスから何も学ばないことです。

彼らが提案する解決策は、エージェント型メモリをストレージとして扱うのをやめ、取り込み、修正、忘却、取得という4つの操作を通じて進化する「状態」として扱うことです。これが本セクションのチェックリストになります。

何を記憶するかを厳選する

いったん「悪い」記憶が入り込むと、以降のすべてのステップがそれを引き継ぎます。

Workday AI Researchは、LoCoMoベンチマークから得た約1,500件の候補メモリを対象に選択的なアプローチを検証し、保持する前にそれぞれについて次の5つの問いを投げかけました。

• 有用か？今後また関係してくる可能性があるか？
• 信頼できるか？会話の中で実際にそう言われたのか、それともモデルが補ったのか？
• 新しい情報か、それともすでに保存されているか？
• 鮮度は十分か？
• 永続的な事実か、それとも一時的な状態か？

モデルの呼び出しが必要だったのは最初の問いだけでした。残りの4つはルールとして実行され、合計65ミリ秒未満で完了しました。この手法は、保持か破棄かの判断で適合率が12%向上し、関連するメモリの97%を保持しました。

最も大きく寄与したのは最後の問いでした。永続的な情報と一時的な情報の区別を取り除くと、判断の質は約18%低下しました。

履歴を失わずに答えを修正する

ある事実がいつ有効になったのか、どの情報源がそれを裏付けているのか、何を置き換えたのかを記録しましょう。情報源同士の内容が食い違う場合は、解決できるだけの根拠が揃うまで、その食い違いを見える状態にしておきます。最新のドキュメントが間違っていることもあるからです。

Brainは、ソースドキュメント、コネクタの結果、ユーザーによる修正を使ってwikiを更新します。各メモリエントリは、その出典にリンクしています。エージェントには現在の答えを見つけてもらうと同時に、その答えが疑わしく思えたときに確認できる場所も必要です。

意図的に忘れる

この論文では、ある失敗パターンを「容量起因の忘却」と呼んでいます。有用でなくなったからではなく、ストレージの上限を満たすために情報が削除されてしまうことです。

共用キッチンの話に戻りましょう。6か月も経てば、誰が魚を温めたのか、窓がどれくらい開いていたのかを気にする人はいません。それでも、貼り紙にはまだ役目があります。

次の人が昼食を作るときにも、ルールはそこにあります。苦情はアーカイブしてしまえばよいのです。

Workdayの鮮度チェックと情報タイプのチェックは保存の前に行われ、メモリとして残すに値するものを選別します。Brainではさらに、ソースドキュメントの変更やユーザーによる修正に合わせて、既存のナレッジを見直します。どちらの場合も、介入が必要になるきっかけはコンテンツです。

取得を次の更新に活かす

エージェントは事実を取得して使い、ストアを見つけたときのままの状態で残します。そうなると、その後に何が起きたかをシステムが記録しない限り、その事実が役に立ったのか、それともエージェントをまた別の行き止まりに導いたのかは、どこにも記録されません。

結果、情報源、そして修正があればそれも記録しましょう。Brainを構築した際、私たちはこうした作業履歴を記憶の対象に含めました。どのアプローチが成功したか、どの情報源が行き止まりだったか、エージェントが完了を告げた後にユーザーが何を修正したか、といったことです。Brainはこうした経験を定期的なwiki更新に取り込むため、後のタスクで活用できます。

しかし、こうしたことは想起のベンチマークには一切表れません。このループが機能しているかを知るには、メモリがなければ完了できないタスクをエージェントに与え、コストとレイテンシーも併せて、どれくらいの頻度で完了できるかを数えることです。それを行うのがDolphinBenchであり、だからこそトップスコアはいまだに70台にとどまっているのです。

Perplexityで永続的なメモリを持つエージェントを構築する方法

PerplexityのAgent APIには、Brainのような自己管理型のメモリシステムは搭載されていません。この点は最初にお伝えしておきます。ただし、必要なメモリの構成要素は提供しています。手順を保持する場所、ターン間でコンテキストを引き継ぐ方法、そして自分で管理するストアへの読み書きを行うツールです。

手続き記憶から始める

カスタムスキルは、指示、手順、補助ファイルをバージョン番号付きでパッケージ化します。プラットフォームチームは、デプロイチェック、ロールバック基準、レポート形式を一度書くだけで、複数のアプリケーションから同じスキルを参照させることができます。手順が変わったら、チームは新しいバージョンをアップロードします。

拡大

出典：X

プロファイルは、さらに一段上の仕組みです。プロファイルは、エージェントのモデル、指示、ツール、スキル、コネクタ、実行設定を、バージョン管理された1つのIDにまとめて保存します。

9月にはこの両方を追加しました。あわせてマネージドコネクタも追加したため、プロジェクト管理者は承認済みのGitHubやSlackの接続を一度設定するだけで、アプリケーションごとに認証情報を保存しなくても、その接続を参照させることができます。アクセス権が変わったときは、管理者が1か所で接続を更新します。

なぜこれが記憶と言えるのでしょうか。もう一度、電子レンジで魚を温めたあのキッチンの話に戻りましょう。次に来た人は、苦情の場面に居合わせていなくても「NO FISH」に従うことができます。

スキルは、エージェントに対して同じ役割を果たします。しかも、電子レンジの扉には書ききれない手順、例外、チェックまで盛り込めます。スキルは文書化され、バージョン管理され、次に同じタスクが発生したときにも利用できます。

当社では、Dreamによるメモリ更新のガイドにもスキルを使っています。ただし、スキル自体が自ら学習することはありません。指示が変わるのは、人または自動化されたプロセスによって新しいバージョンがアップロードされたときです。

あるサービスでロールバックチェックが失敗し続けていることにエージェントが気づき、自ら調整するようにしたいなら、それは先ほど説明した「セッションからWikiへ」のループの役割です。

何が起きたかを保持し、何を変えるべきかを導き出し、その修正を次回利用できるようにする必要があります。そのためには、次の2つの要素が必要です。

ターン間でワーキングメモリを引き継ぐ

エージェントがデプロイチェックを実行します。あなたは「それはなぜ失敗したの？」と尋ねます。妥当なフォローアップの質問ですが、それが成り立つのは、エージェントが「それ」が何を指しているかをまだ把握できている場合に限られます。

当社のAgent APIは、会話のコンテキストを引き継ぐ2つの方法をサポートしています：

• 会話を自分でリプレイする：以前のメッセージを次のリクエストのinput配列に含めます。送信前に、何を残し、要約し、秘匿化し、削除するかを自分で決められます。
• 完了したレスポンスから続ける：そのIDを保存し、次のメッセージとともにprevious_response_idとして渡します。会話の状態は当社がサーバー側で保持するため、アプリケーションが以前のターンを再送する必要はありません。チェーン内の最新のレスポンスから続けることができます。

リプレイではエージェントに見せる内容を制御でき、IDによる継続では会話を組み立て直す手間を省けます。どちらの場合も、次のレスポンスに必要な新しい指示、ツール、モデル設定は改めて指定してください。

エピソード記憶と意味記憶のストアは自前で用意する

ここは、Agent APIがあなたに委ねている部分です。

1つの方法は関数呼び出しです。あなたがツールを定義し、エージェントが呼び出しをリクエストし、アプリケーションがそれを実行して結果を返します。メモリについては、エージェントが行動する前に読み取り操作を、行動した後に書き込み操作を行うのがシンプルな出発点です。

エージェントが取得した事実だけを記録しても、それが役に立ったかどうかはわかりません。結果、情報源、ユーザーが修正した内容を記録すれば、エピソード記憶のレイヤーの基礎ができます。

当社のMCPサポートを使えば、もう1つの方法もあります。互換性のあるリモートMCPサーバーが必要な操作を公開していれば、各操作をカスタム関数としてラップしなくても、エージェントはそれらを呼び出せます。

当社のコネクタを使えば、エージェントは記憶の裏付けとなるエビデンスにアクセスできます。GitHub、Slack、Google Drive、Datadog、Linear、Notionはマネージドカタログに含まれており、社内システム向けにカスタムコネクタを追加することもできます。

最後に、履歴をいつ見直し、現在の記録をいつ改訂するかを決めます。

新しいセッションで何が引き継がれるかをテストする

では、会話を終了しましょう。古いメッセージをリプレイしたりprevious_response_idを渡したりせずに新しいリクエストを開始しますが、エージェントには同じメモリストアへのアクセス権を与えます。修正内容を改めて伝えずに、関連する作業を依頼してみてください。

エージェントに改めて伝える必要があるなら、まだ完成とは言えません。

デプロイエージェントについては、引き継がれるべき内容を中心にいくつかテストを作成します：

• 修正が保持される：影響を受けるサービスについて、検証済みのロールバックコマンドを取得して使用する。
• 修正が適用範囲内にとどまる：他のサービスの手順には手を加えない。
• 新しい情報が古いガイダンスを置き換える：コマンドが再び変更されたときは、現在のバージョンを使用し、その変更を情報源までたどることができる。

当社の回帰テストのクックブックでは、エージェントの出力と取得したエビデンスを保存し、期待される動作と照合し、指示やモデルを変更した後の実行結果を比較する方法を紹介しています。

メモリあり・なしで実行結果を比較する間は、モデル、プロファイル、スキルのバージョンを固定しておきます。各比較はストアの既知のスナップショットから開始してください。そうしないと、あるテストが次のテストの答えをエージェントに教えてしまう可能性があります。

何かが失敗したら、そのケースを保存します。次の変更は、そのケースに合格しなければならないようにします。

あるいは、構築は省略：ComputerのBrain

部品ではなく完成したループが欲しいなら、それがComputerです。その基盤ではBrainが動作しており、4つの情報源から学習します：あなたのセッション、接続されたツール、作成したファイルやアーティファクト、そしてあなたによる修正です。Brainはバックグラウンドで更新を行い、今も有効な情報を強化し、変化した情報を修正し、古くなった情報にマークを付けます。

そのループを自分で構築する必要はありません。あなたはただ作業をするだけです。

メモリは、あなたが共有した好みや詳細を保持します。Brainは、プロジェクト、人、意思決定、未完了の作業を、その裏付けとなるエビデンスと結び付けます。

Brainが学習した内容はメモリビューで確認でき、各エントリーを情報源までたどったり、編集・削除したりできます。Brainはあなた自身のアクティビティを使用し、シークレットセッションは対象外で、専用のオン／オフ設定があります。

拡大

たとえばRhoでは、請求書関連プロジェクトの意思決定がSlack、Notion、Jira、Figma、Google Docsに散在していました。チームはComputerを設定し、夜間に変更内容を確認して不整合にフラグを立て、Slackに朝のダイジェストを投稿するようにしました。

同社のソフトウェアエンジニアであるOktawian Jurkiewicz氏は、Computerがプロジェクトのメモリも構築していることに気づきました。「私たちが定義したわけではありません」と彼は言います。「各ソースからどのデータポイントを保存すべきかを、Computerが自ら判断したのです」

チームは毎週の会議時間を2.5時間から15分に短縮したと報告しており、12週間のプロジェクト全体で120時間の作業時間を削減できたと見積もっています。

この120時間は、コネクタ、夜間の実行、Slackダイジェストを含むワークフロー全体による成果です。削減できた時間のうち、メモリだけによるものはどれくらいでしょうか？　それはまだ定量化できていません。

ただし、アドバイスできるのは、独自に構築する場合は先ほどのテストに立ち返ることです。メモリレイヤーをオンにした場合とオフにした場合で同等のタスクを実行し、完了率、コスト、時間（結果の修正に誰かが費やす時間を含む）を比較してください。

AIエージェントのメモリに関するよくある質問

AIエージェントはメモリを持つことができますか？

はい。AIエージェントは、保存された会話、事実、好み、再利用可能な手順を通じて、セッションをまたいで情報を保持できます。システムは、関連する場面でその情報を取得し、状況が変わったときに更新する必要があります。

たとえばPerplexity ComputerのBrainは、セッション、接続されたツール、ファイル、ユーザーによる修正から作業コンテキストを構築します。

AIエージェントはどれくらいのRAMを使用しますか？

一律の要件はありません。エージェントがPerplexity Agent APIを通じてホスト型モデルを呼び出す場合、そのモデルを自分のRAMに読み込む必要はありません。ただし、アプリケーションやローカルツールには引き続きメモリが必要です。

ローカルでモデルを実行する場合は事情が異なります。パラメータあたり4ビットの場合、80億パラメータは約4 GBの生の重みデータになります。量子化のオーバーヘッド、コンテキスト処理、モデルを実行するソフトウェアを含めると、実際に必要なメモリはそれより多くなります。

AIエージェントに最適なメモリとは？

最適な構成は、エージェントが何を引き継ぐ必要があるかによって異なります。会話の状態はフォローアップの質問を支え、エピソード記録は起きたことを保存し、意味記憶は現在の知識を保持し、手続き記憶は再利用可能な指示を提供します。

継続的な作業の多くは、これらを組み合わせることでメリットが得られます。当社ではBrainに、相互にリンクされ、情報源に裏付けられたWikiを使用しています。独自に構築する場合は、その構成によってエージェントがタスクを完了し、修正を適用し、古くなったガイダンスを廃止できるようになるかをテストしてください。