DatabricksでAgent Memoryを導入：過去の作業を再利用可能に
Databricksはベータ版としてエージェントメモリを導入し、企業向けエージェントが過去の会話で学んだことを毎回あらためて発見し直す慣行に一石を投じた。10月20日の発表「Introducing Agent Memory on Databricks」では、同社のエージェント開発プラットフォームであるAgent Bricksに永続的なコンテキストを組み込んでいる。実務上の問いは、経験を保持することが、変化するビジネスタスク全体で信頼できる改善を生むかどうかだ。
主な比較対象は、マネージドメモリと、繰り返される再発見およびカスタムメモリ基盤である。企業の開発者は、自前のシステムを維持することが今なおエンジニアリングコストに見合うのかを判断しなければならない。AmazonのAgentCoreはすでにマネージドメモリを提供しており、Databricksは、エージェントが蓄積した知識をどこに置くべきかを巡る既存の競争に参入する。
購入者にとって、この発表が提起するのは、アシスタントが好みの応答形式を覚えているかどうかよりも具体的な問いだ。プラットフォームは有用な修正を保持し、適切に適用し、記憶された情報が回答に影響したタイミングを説明できるのか。この組み合わせによって、メモリが運用上の優位性になるのか、それとも新たなエラー源になるのかが決まる。
DatabricksでAgent Memoryを導入し、コンテキストを永続化する
Databricksはセッションをまたぐメモリを運用サービスとして提供し、実装負担の一部をアプリケーションチームから移している。
同社のエージェントメモリに関する発表では、管理された会話履歴、永続メモリ、そしてエージェントが保持すべき内容を統合するバックグラウンドプロセスが説明されている。このサービスは、DatabricksのマネージドPostgresデータベースであるLakebase上で稼働する。Databricksによれば、開発者は記憶されたエントリを確認、エクスポート、削除できる。
これは企業アプリケーションの出発点を変える。以前は、永続性を自ら構築するチームが、ストレージと、有用な情報を選択・検索するためのルールを接続する必要があった。マネージドの選択肢があれば、そのチームは自前の実装に取り組む前に、既存の実装を評価できる。
この違いは重要だ。会話記録を保持しても、自動的に有用なメモリが生まれるわけではない。記録には、誤り、放棄されたアプローチ、一時的な前提を含め、起きたことが残る。有用なメモリには、どの部分が将来の作業に影響を与えるに値するかという判断が求められる。
たとえば、収益の定義に関する修正を受け取る分析アシスタントを想定してみよう。その修正は、ある部門、報告期間、または特定のダッシュボードにのみ当てはまるかもしれない。適用範囲を伴わずに文だけを記憶すると、昨日の回答を別の質問に当てはめる危険がある。
この点で、発表はパーソナライゼーションを超えて意味を持つ。口調に関する好みは表現に影響する。記憶されたビジネス定義は、回答の内容、さらにはその後に取られる行動に影響する。
したがって、エンジニアリング上の判断はストレージと同じくらい責任に関わる。開発者がマネージドメモリを採用する場合でも、保持した情報のうち何をアプリケーションに含めるべきかを決める必要がある。また、権威的に見えても、もはや適用できないエントリに異議を唱える手段も必要だ。
DatabricksでAgent Memoryを導入することで、そうしたチームには基盤の選択肢が与えられる。しかし、すべての会話が永続的な知識を生むべきだとは示していない。特にユーザーが持続的な好みと一時的な依頼を混在させる場合、選択的な保持は依然としてプロダクト上の判断である。
アプリケーションが、ユーザーの好むレポート形式を記憶しつつ、暫定的な予測は保持しないという判断は合理的かもしれない。どちらの発言も会話を通じて届くが、そこに伴う期待は異なる。同一に扱えば、永続化は実装しやすくなる一方で、信頼しにくくなる。
したがって、目先の変化は具体的だが限定的である。Databricksは今、会話をまたいで経験を保存するためのマネージドな場所を開発者に提供している。その経験が再利用に値するかどうかは、アプリケーションのルールと各メモリを裏付ける根拠に依存する。
この境界が商業上の利害を形づくる。チームは基盤作業をプラットフォームに移せるが、何が有効なビジネス知識に当たるかという理解まで移管することはできない。
企業チームは異なる内製か購入かの判断に直面する
圧力を受けるのは、依存するエージェントと並行してメモリ基盤を維持しているチームだ。
社内プラットフォームグループにとって、カスタムメモリは継続的な責務を生む。欠落したエントリ、不適切な検索、矛盾する修正、失敗した更新を誰かが調査しなければならない。こうした責務は、最初のデモが機能した後も残り続ける。
マネージドサービスは、比較の軸を機能の有無から運用価値へと変える。問われるのは、カスタム実装が、その維持を正当化できるほどの制御や専門性を提供するかどうかだ。これは、エージェントが情報を保存できることを示すだけよりも厳しい基準である。
カスタムアプローチを維持すべき正当な理由もある。組織には、専門的な保持ルール、特殊なデプロイ境界、既存システム間で共有されるメモリ形式が必要な場合がある。マネージド基盤が常に優位だと決めつけるのではなく、こうした要件を評価する必要がある。
反対に、一般的な要件しかないチームが、すでにアプリケーションを所有しているという理由だけで、よくある基盤部分を再構築して得られるものは少ない。限られたエンジニアリングの注意力は、より良い評価や、より明確なユーザーコントロールに向けた方が大きな価値を生むかもしれない。
Databricksの参入は、企業の購入者に別の比較基準も与える。AmazonのAgentCore memory typesドキュメントでは、生のインタラクションストレージと、バックグラウンド処理によって抽出される長期記録が説明されている。また、後続セッションをまたぐ統合と検索についても記載されている。
この重なりは競争上の基準線を示す。永続メモリはすでに、別の大手プロバイダーが提供するプラットフォーム機能である。Databricksは、実装品質、運用上の適合性、顧客が実際に実行しているワークロードとの統合で競争しなければならない。
利用可能なドキュメントからは、これらのサービス間で性能上の勝者を確定することはできない。アーキテクチャの説明は意図された動作を示すが、同等のテストの代わりにはならない。公正な比較では、タスク、モデル、履歴、採点ルールを一定に保つ必要がある。
購入者にとっては、ベンダー選定をアプリケーションの失敗パターンに従わせるべきだという意味になる。好みを忘れるサポートアシスタントと、誤った情報源を繰り返し選ぶ分析エージェントでは、求められるものが異なる。メモリの品質は、外部に委ねようとしている特定の問題に照らして測定しなければならない。
調達の議論では、利便性と依存関係も区別する必要がある。基盤を統合すれば、組織が運用するシステム数を減らせる。一方で、蓄積されたコンテキストがアプリケーションの挙動の一部になると、移行の影響はより大きくなる。
エントリをエクスポートできることは有用だが、エクスポートだけで別の環境でも同等の挙動が保証されるわけではない。別のシステムが異なるメモリを選ぶ可能性も、同じ保持済みテキストを異なる形で解釈する可能性もある。ポータビリティは、データ転送テストだけでなく、挙動のテストも必要とする。
したがって、マネージドメモリを購入する最も強い根拠は実務的なものだ。サービスは、アプリケーションに必要な制御を保ちながら、保守を減らすべきである。購入者は、基盤の統合を改善と見なす前に、両方の結果を示す根拠を求めるべきだ。
圧力はカスタム実装とマネージドベンダーの双方にかかる。いずれも、単にエージェントが保持できる情報量を増やすのではなく、自らのアプローチが完了した作業をどう改善するのかを説明しなければならない。
仕組みは再利用に値するものの選定に依存する
中核となる設計上の課題は、どの経験が次のタスクに影響すべきかを決めることだ。
Databricksのメモリパイプラインのドキュメントでは、永続的な情報を抽出し、重複するエントリを統合し、保存済みメモリを再編成するバックグラウンド処理が説明されている。開発者は何を保持するかについて指示を与えられる。文書化された設計は、ライブソースから取得すべき変動値よりも、再利用可能な事実や手順を重視している。
この違いは企業分析に直接的な影響を与える。指標の計算方法を記憶すれば、エージェントが有効なワークフローを繰り返す助けになる。指標の過去の値を記憶すると、基盤となる事業が変化した際に古い回答を生む可能性がある。
例として、営業アシスタントを考えると違いが明確になる。特定のレポートでは、チームがキャンセル済み契約を除外するというルールを保持できる。しかし次のレポートを作成する際には、現在の契約データを取得すべきである。
保持されたルールは、新たな根拠を置き換えることなく再発見を減らす。ただし、組織がそのルールを変更した場合、メモリには適切な修正が必要になる。再利用の成功は、保存と改訂の両方に依存する。
バックグラウンド処理は別の判断境界も生む。パイプラインのドキュメントでは、手動実行または約24時間ごとのスケジュール実行が可能とされている。したがって、スケジュールされた統合は、すべての新しい修正が直ちに将来のすべてのインタラクションを再構成する保証ではなく、遅延処理として理解すべきだ。
アプリケーション設計者にとって、その示唆は明快である。ユーザーの次の依頼に必要な修正は、後の統合まで待てる知識とは異なる扱いを受けるべきだ。修正が反映されたかを知るために、ユーザーが処理スケジュールを理解する必要があってはならない。
ドキュメントによれば、メンテナンスによって、エージェントが直接保存したエントリが変更される場合もある。つまり保存されたメモリは、会話についての進化する解釈の一部である。元の発言の恒久的なコピーとは限らない。
これはプロダクトチームに説明責任の問いを生む。記憶された指示が統合中に変化するなら、アプリケーションは、その結果としての挙動を説明できるだけの根拠を持つべきだ。そうでなければ、ユーザーには理解可能な理由なしに解釈を変えるアシスタントが見えることになる。
有用な類推として、作業メモを維持するアナリストを考えられる。メモが役立つのは、関連する条件を保持し、検証済みのソース資料と区別できる場合だけだ。エージェントの保持済み要約にも同様の精査が必要である。
同じ区別はパーソナルナレッジマネジメントにも見られる。情報を集めることと、それを有用にすることは関連しているが別のタスクだ。企業向けエージェントでは、保持された情報が現在の依頼に適切であり続けるかどうかにも有用性は依存する。
この仕組みにより、メモリはアプリケーションの挙動の能動的な一部となる。次のタスクが始まる前に、経験を選別し、圧縮し、更新する。サービスを評価するチームは、保存の成功を終着点と見なすのではなく、こうした変換を評価すべきだ。
ベンチマークは限定的な性能上の主張を裏付ける
Databricksは自社の企業向けベンチマークで改善を報告しているが、その結果は普遍的な向上を示すものではない。
同社のMemCurrent研究では、このリリースを支えるアーキテクチャが説明されている。Databricksは社内ベンチマークにおいて、MemCurrent使用時の合格率が68.4%で、メモリなしの場合の22.3%と比べて高かったと報告している。また、トークン数は31%減少し、実行速度は26%向上したとしている。
この社内ベンチマークには、29人のユーザーと2,233件の過去セッションに関わる114件のケースが含まれている。Databricksによれば、この評価はエンタープライズのデータ対話から構築され、ケースのレビューも実施された。これらは同社が報告した結果であり、すべての導入事例を独立して検証したものではない。
この調査では、ワークフロー改善の例も報告されている。先行タスクでは11回のツール呼び出しと約6分を要したのに対し、関連する後続の問い合わせでは2回のツール呼び出しと41秒で済んだという。この例は、探索の繰り返しを回避するという提案された仕組みを裏付ける。ただし、顧客が期待できる平均的な改善幅を示すものではない。
例示と期待される成果の区別は重要である。再利用可能なコンテキストを伴う繰り返しタスクは、メモリ活用に有利な機会となる。一方、無関係な要件を持つ新規タスクでは、過去の情報から得られる利点は小さい可能性がある。
同様に、トークン数の削減は特定のリソースを測る指標であり、運用負荷全体を示すものではない。チームは、メモリの作成、保守、検査、評価に必要な作業も考慮する必要がある。導入判断では、アプリケーション全体を検討すべきである。
この知見は、特定の仮説を検証する理由として最も有用だ。エージェントが安定した業務知識を繰り返し再発見しているなら、保持された経験によってその反復は減るはずである。過去の会話に関連情報がほとんど含まれない場合、この仮説は弱くなる。
評価には、メモリが使われないはずのタスクも含めるべきである。そうでなければ、あらゆる回答に履歴コンテキストを挿入することで、システムが成功しているように見えてしまう。無関係な想起はそれ自体が注意をそらすため、選択性が重要である。
独立研究は、より広範な評価フレームワークを示している。ICLR 2025で発表されたLongMemEvalベンチマークは、抽出、セッション横断の推論、時間的推論、知識更新、棄権を検証する。棄権とは、利用可能な証拠が回答を支持しない場合に答えを控えることを意味する。
これらの分類は、単純な想起が不完全な尺度である理由を明らかにする。アシスタントは古い発言を正確に取得しても、誤ったタイミングで適用する可能性がある。また、メモリに関連する証拠がないにもかかわらず、自信を持って回答するという失敗も起こり得る。
したがってエンタープライズの購入担当者にとって有用な問いは、メモリがベンチマークスコアを改善するかどうかよりも狭い。定義変更や相反する指示を含むケースも含め、従業員が実際に行うタスクを改善するのか、という点である。
DatabricksでAgent Memoryを導入することで、マネージドインフラストラクチャ上でその比較を実行する機会が生まれる。公開された結果は注目に値する一方、報告された仕組みが移転可能かどうかは、アプリケーション自身の評価によって判断しなければならない。
これは証拠に対する妥当な解釈である。同社は、評価方法を示した測定可能な主張を提示している。顧客には依然として、自社の履歴、権限、業務上の意思決定を反映した結果が必要だ。
メモリの所有権にはユーザー識別子以上のものが求められる
記憶された情報は、それを生んだ会話より長く残り得るため、永続的なコンテキストには明示的なセキュリティルールと削除ルールが必要である。
Databricksのメモリおよびセッションに関するドキュメントでは、セッションを削除してもメモリは削除されないと説明されている。また、ユーザーのパーティショニングとアクセス制御は区別されている。アクター識別子は、操作で使用するエントリの所有者を選択するが、ストアへのアクセス権を持つプリンシパルは他のアクターに属するエントリも読み取れる。
ドキュメントでは、その識別子を信頼できるアプリケーションコード内で検証済みのIDから導出することを推奨している。厳格なテナント分離には、別々のストアを推奨している。また、ベータ版のインターフェースと動作は変更される可能性があるとも警告している。
これらは、リリースを評価する購入者にとって重要な実装上の詳細である。情報をユーザー別にラベル付けするフィールドがあっても、自動的にセキュリティ境界が強制されるわけではない。アプリケーションは、ID、権限、ストレージ構造を正しく結び付けなければならない。
顧客サポートへの導入例は、この懸念を示している。記憶された設定は、顧客自身のアカウント内では無害でも、別の顧客との会話では不適切になり得る。正しい取得には、モデルがメモリを要求する前に、アプリケーションが正しいIDを確立することが必要である。
削除は別の問題をもたらす。ユーザーは会話を削除すれば、アシスタントがそこから学習した内容も削除されると合理的に考えるかもしれない。派生情報が残るなら、製品はその違いを明確に説明する必要がある。
これは、特定の導入で削除処理が不適切であるという証拠ではなく、アプリケーション設計上の含意である。文書化された分離によって、これはチームが答えるべき問いとなる。完全な削除ポリシーは、元の対話と、そこから保持された情報の両方を扱うべきである。
訂正にも同様の注意が必要である。誤ったメモリを置き換えれば将来の挙動に影響するはずだが、チームは訂正が残りの履歴とどのように相互作用するかも理解する必要がある。そうでなければ、同じ基礎的な証拠が再び誤った解釈を支える可能性がある。
メモリは、永続的な権威を持つべきでなかった指示も保存し得る。たとえば、誤解を招く運用上の指示を含む文書を考えてみよう。エージェントがその指示を受け入れられた慣行として要約すると、その誤りは元の文書レビューを超えて後続タスクに影響する可能性がある。
このシナリオでは、情報源の権威性と保持挙動の評価が求められる。Databricksで発見された脆弱性として提示すべきではない。重要な問いは、アプリケーションがユーザーに承認された設定と、作業中に遭遇した信頼できないコンテンツを区別できるかどうかである。
ここでは、バックエンドと同じくらい製品体験が重要である。ユーザーには、重要なメモリを検査し、訂正し、削除を要求するための分かりやすい手段が必要だ。その制御が影響を受ける人々にとって利用しにくいままであれば、技術的能力の実用的な価値は限られる。
開発者にとって、運用上の教訓は具体的だ。メモリは、情報が回答へ到達する新たな経路を導入する。したがってデバッグでは、エージェントが何を記憶したか、なぜその情報を取得したのか、そしてアプリケーションがその使用を許可したかを考慮する必要がある。
こうした責任は、マネージドストレージによって消えるわけではない。それらは、マネージドサービスがアプリケーションの信頼境界に適合するかを判断する一部となる。
ベータ版発表後に注目すべき点
次に必要な証拠は、マネージドメモリを再現可能な顧客成果およびより明確な運用上の制約と結び付けるものである。
最初のシグナルは、反復的なエンタープライズタスクに関する独立評価または顧客公開の評価である。有用な結果は、訂正、変化する事実、無関係なリクエストを含めながら、同じアプリケーションをメモリあり・なしで比較するものとなる。この証拠は、保持されたコンテキストが同社の選定ケースを超えて業務を改善するかどうかを検証する。
説得力のある評価は、成功とともに失敗も説明する。パフォーマンスが密接に繰り返される質問でのみ改善するなら、その利点は持続的な業務理解よりも狭いままである。関連しているが異なるタスクでも効果が持続するなら、再利用可能な経験の根拠はより強くなる。
2つ目のシグナルは、運用上の制約とユーザー制御をめぐる製品開発である。購入者は、スケジューリング、規模、分離、検査、削除の挙動に関する文書化された変更を注視すべきだ。これらの詳細は、大規模な補助インフラストラクチャを構築せずに、どのアプリケーションがこのサービスに依存できるかを決定する。
こうした制御の進展は、構築か購入かという議論を強める。通常のメモリ挙動を管理するためにチームが依然として広範な独自の仕組みを必要とするなら、運用上の優位性は説得力を失う。重要な尺度は、サービスが実際にどれほどの責任を取り除くかである。
3つ目のシグナルは、競合他社が自社のメモリに関する主張をどのように検証しやすくするかである。Amazonには既存の提供製品があり、このカテゴリーにはすでに代替手段が存在する。より明確な比較評価は、顧客が挙動の違いと用語の違いを区別する助けとなる。
競合の反応だけでは、Databricksの優位性は証明されない。それは、マネージドメモリがプラットフォーム選定の新たな次元になったことを示す。アプリケーションがサービス間で有用な挙動を維持できるという証拠は、購入者が期待できるポータビリティの程度も明らかにする。
購入対象は継続的なシステムであるため、これらのシグナルは一体として捉えるべきである。制御のないパフォーマンスは、困難な運用上の問いを生む。有用なタスク改善のない制御は、価値が不確かな別の機能を購入者に維持させるだけである。
ナレッジワーカーにとって、その成果は日常的な利用で明確に見えるべきだ。アシスタントは、状況の変化に対応し続けながら、繰り返しの訂正を必要としなくなるべきである。古くなった前提をより一貫して記憶するだけでは、本質を見失う。
開発者にとって、この発表は焦点の定まった実験を生み出す。識別可能なメモリ関連の失敗を持つ反復ワークフローを選び、一貫した条件下で成果を比較する。ライブの証拠を記憶されたガイダンスから分離し、過去の情報が回答に含まれるべきではないケースも検証する。
DatabricksでAgent Memoryを導入することで、エンタープライズチームは既存のアプローチに対して評価できる具体的なサービスを得る。まず、エージェントが繰り返し誤る、または不必要に反復する作業から始める。どの訂正を永続化すべきか、どの事実を現在の情報源に結び付けたままにすべきかを特定する。そのうえで、古い前提を持ち越すことなく、保持されたコンテキストが後続の意思決定を改善するかを検証する。誰がメモリを検査でき、誰が変更でき、アプリケーション全体で削除が何を意味するかを問う。公開されたベンチマークは、自社のタスクで検証する価値のある仮説として扱うべきである。導入を拡大する前に、チームはエージェントが正しい教訓を記憶し、その教訓が適用されなくなったときに使用をやめることを示せるだろうか。
