[翻訳] エージェントメモリソリューションとしての OpenSearch: 永続メモリを使用したコンテキスト認識エージェントの構築
効果的な AI エージェントを構築するには、強力な言語モデルだけでなく、過去のインタラクションを記憶し学習する能力が必要です。OpenSearch 3.3 では、AI エージェントが OpenSearch の実績ある検索およびストレージインフラストラクチャを使用して、会話全体でコンテキストを維持し、知識を抽出し、理解を構築できる包括的な永続メモリシステムである「エージェントメモリ (agentic memory)」を導入しました。
本記事では、AI エージェントが直面するメモリの課題を探り、エージェントメモリのコアコンセプトを紹介し、エージェントフレームワークとの統合方法を説明します。
AI エージェント開発におけるメモリの課題
効果的な AI エージェントには、言語理解だけでなく、時間の経過とともにコンテキストを維持しインタラクションから学習する能力が必要です。現在の AI システムは各会話を独立して処理しており、ユーザーとの意味のある進化する関係を可能にする永続メモリが欠けています。
AI エージェントを構築する開発者は、メモリ機能を実装する際にいくつかの技術的課題に直面します。
トークン制限の管理: 大規模言語モデル (LLM) には有限のコンテキストウィンドウがあり、開発者は処理制限内で会話履歴を管理する戦略を実装する必要があります。
カスタムインフラストラクチャのオーバーヘッド: 専用のメモリソリューションがない場合、チームは会話データ、ユーザー設定、エージェント状態を保存するための独自システムを構築することが多く、プロジェクト間で作業が重複します。
インテリジェントな検索の複雑さ: 生の会話ストレージだけでは不十分です。開発者は、意味のある洞察を抽出し、関連情報をコンテキストに応じて表示する洗練されたシステムが必要です。
理解を伴わないストレージ: 従来のアプローチはインテリジェントなメモリ形成ではなくデータの永続化に焦点を当てており、インタラクションから価値あるパターンを識別・抽出する組み込み機能が欠けています。
これらの技術的制限はユーザーエクスペリエンスの問題を引き起こします。
- ファイナンシャルアドバイザーが以前のセッションで議論したクライアントの投資目標を見失う
- コーディングアシスタントが確立された開発設定やプロジェクトコンテキストを忘れる
- カスタマーサービスエージェントがユーザーに以前のインタラクションで共有した情報を繰り返し求める
効果的なメモリシステムがなければ、AI の会話は意味のある継続的な関係を構築するのではなく、断片化したままになります。
OpenSearch エージェントメモリの紹介
OpenSearch エージェントメモリは、OpenSearch の実績ある検索およびストレージインフラストラクチャ上に構築された包括的なメモリ管理システムを提供することで、これらの課題に対処します。このソリューションにより、AI エージェントは即時の会話コンテキストとインタラクション全体にわたる永続的な知識の両方を維持でき、よりインテリジェントでパーソナライズされたユーザーエクスペリエンスを実現します。
このシステムはいくつかのコア原則に基づいて設計されています。
統合プラットフォームアプローチ: 検索ワークロードとエージェントメモリの両方に既存の OpenSearch インフラストラクチャを使用し、運用の複雑さとインフラストラクチャコストを削減します。
インテリジェントな処理機能: 設定可能な戦略により、統合された LLM 処理を使用して生の会話から洞察、設定、要約を自動的に抽出します。
フレームワークの柔軟性: REST API 設計により、ベンダー依存なしに任意のエージェントフレームワークやカスタム実装との統合が可能です。
階層的な組織化: 名前空間ベースのメモリ組織により、マルチユーザー、マルチエージェント環境での構造化されたアクセス制御と効率的な検索を提供します。
本番環境でのスケーラビリティ: OpenSearch の分散アーキテクチャ上に構築されており、一貫したパフォーマンスでエンタープライズ規模のメモリワークロードを処理します。
エージェントメモリのコアコンポーネント
OpenSearch エージェントメモリは、エージェントに短期コンテキストと長期インテリジェンスの両方を提供するために連携するいくつかの主要コンポーネントで構成されています。
メモリコンテナ
メモリコンテナは、チャットボット、リサーチアシスタント、カスタマーサービスエージェントなど、特定のユースケースのすべてのメモリタイプを保持する論理コンテナです。各コンテナは以下で設定できます。
- テキスト埋め込みモデル: 保存されたメモリ全体でのセマンティック検索機能用
- LLM: 長期メモリでのインテリジェントな知識抽出と処理用
- メモリ処理戦略: 長期メモリの処理と整理方法を定義
- 名前空間: コンテキスト、ユーザー、エージェント、またはセッションごとにメモリを分割
以下の例は、これらの設定でメモリコンテナを作成する方法を示しています。
POST /_plugins/_ml/memory_containers/_create
{
"name": "customer-service-agent",
"description": "Memory container for customer service interactions",
"configuration": {
"embedding_model_type": "TEXT_EMBEDDING",
"embedding_model_id": "your-embedding-model-id",
"llm_id": "your-llm-model-id",
"strategies": [
{
"type": "USER_PREFERENCE",
"namespace": ["user_id"]
},
{
"type": "SUMMARY",
"namespace": ["user_id", "session_id"]
}
]
}
}
メモリタイプ
各メモリコンテナは 4 つの異なるタイプのメモリを保存します。
セッション: 会話セッションとそのメタデータを管理します。各セッションは、開始時間、参加者、セッション状態などのセッション固有の情報を含む、ユーザーとエージェント間の個別のインタラクションコンテキストを表します。
以下の例はセッションの作成方法を示しています。
POST /_plugins/_ml/memory_containers/<memory_container_id>/memories/sessions
{
"session_id": "user123_session_456",
"summary": "Customer support conversation",
"metadata": {
"user_id": "user123",
"channel": "web_chat"
},
"namespace": {
"user_id": "user123"
}
}
ワーキングメモリ: エージェントが進行中のインタラクション中に使用するアクティブな会話データと構造化情報を保存します。これには、最近のメッセージ、現在のコンテキスト、エージェント状態、実行トレース、即時処理に必要な一時データが含まれます。
長期メモリ: 時間の経過とともにワーキングメモリから抽出された処理済みの知識と事実を含みます。推論が有効な場合、LLM はワーキングメモリの内容を分析して重要な洞察、ユーザー設定、重要な情報を抽出し、セッションを超えて存続する永続的な知識として保存します。
履歴: メモリコンテナ全体のすべてのメモリ操作 (追加、更新、削除) の監査証跡を維持し、メモリがどのように進化したかの包括的なログを提供します。
メモリ処理戦略
メモリ処理戦略は、生の会話を意味のある長期メモリに変換するインテリジェンスレイヤーを定義します。どの情報を抽出すべきか、どのように処理すべきか、結果のメモリをどこに保存すべきかを決定します。各戦略は、抽出されたメモリが統合される特定の名前空間で設定されます。
OpenSearch エージェントメモリは 3 つの組み込み戦略を提供します。
SEMANTIC: 将来の参照のために会話で言及された事実と知識を保存します。例: 「顧客はサーバーレス処理に AWS Lambda を使用し、開発には Node.js を好むと述べました。」
USER_PREFERENCE: ユーザーの設定、選択、コミュニケーションスタイルを保存します。例: 「ユーザーは高レベルの要約よりも詳細な技術的説明を好みます」または「ユーザーは SMS アラートよりもメール通知を好みます。」
SUMMARY: 会話の要約を作成し、セッションにスコープされた主要なポイントと決定を記録します。例: 「ユーザーは OpenSearch の価格について問い合わせ、クラスターサイジング要件について議論し、実装タイムラインを要求しました。」
メモリコンテナを作成する際にメモリ戦略を設定するには、以下の設定を使用します。
POST /_plugins/_ml/memory_containers/_create
{
"name": "customer-service-agent",
"description": "Memory container for customer service interactions",
"configuration": {
"embedding_model_type": "TEXT_EMBEDDING",
"embedding_model_id": "your-embedding-model-id",
"llm_id": "your-llm-model-id",
"strategies": [
{
"type": "SEMANTIC",
"namespace": ["user_id"]
},
{
"type": "USER_PREFERENCE",
"namespace": ["user_id"]
},
{
"type": "SUMMARY",
"namespace": ["user_id", "session_id"]
}
]
}
}
デフォルトでは、すべての戦略は長期メモリレコードから個人識別情報 (PII) を除外します。
名前空間
名前空間は、メモリコンテナ内で組織構造を提供する柔軟な JSON キーバリューペアです。ユースケースに合った任意のキーを定義できます。事前定義されたスキーマはありません。これらのユーザー定義のアプリケーション固有のキーにより、メモリデータの整理方法を完全に制御でき、マルチエージェント、マルチユーザー、またはその両方のマルチテナントシステムに名前空間を強力にします。
名前空間はいくつかの重要な目的を果たします。
- 組織構造: 異なるタイプのメモリ (設定、要約、エンティティ) を個別の論理コンテナに分離
- アクセス制御: 異なるエージェントや異なるコンテキストでアクセス可能なメモリを制御
- マルチテナント分離: 異なるユーザーや組織のメモリを分離
- フォーカスされた検索: 無関係な情報を検索せずに特定のタイプのメモリをクエリ
例えば、ユーザーとセッションの追跡のために名前空間を以下のように構造化できます。
{
"user_id": "user123",
"session_id": "session-456"
}
または、ドメインに合わせたカスタムキーを使用できます。
{
"department": "sales",
"region": "us-west",
"customer_tier": "enterprise"
}
以下の例は、メモリを保存する際に名前空間を使用する方法を示しています。
POST /_plugins/_ml/memory_containers/<memory_container_id>/memories
{
"messages": [
{
"role": "user",
"content": [
{
"text": "I prefer email notifications over SMS",
"type": "text"
}
]
}
],
"namespace": {
"user_id": "user123",
"session_id": "session-789",
"org_id": "ecommerce-bot"
},
"payload_type": "conversational",
"infer": true
}
エージェントフレームワークとの統合
OpenSearch エージェントメモリはフレームワーク非依存のソリューションとして構築されており、標準の REST API インターフェースを通じて任意のエージェントフレームワークで動作します。LangChain、LangGraph、Amazon Bedrock Agents を使用している場合でも、カスタム実装を構築している場合でも、フレームワーク固有の依存関係やベンダーロックインなしに、標準の HTTP リクエストを通じて永続メモリ機能を統合できます。
高度な機能
コアメモリ管理機能に加えて、OpenSearch エージェントメモリは、メモリの処理、検索、保存方法をより柔軟に制御できるいくつかの高度な機能を提供します。
推論モード
OpenSearch エージェントメモリは、infer パラメータ (デフォルトは false) で制御される 2 つの推論モードをサポートしています。
生のストレージ (infer: false): LLM 処理なしでメッセージとデータをワーキングメモリに直接保存します。これはデフォルトモードで、単純な会話履歴や、アプリケーションで処理を行いたい場合に便利です。
インテリジェント抽出 (infer: true): 設定された LLM を使用して会話から重要な情報、事実、洞察を抽出し、設定された戦略を使用して自動的に長期メモリに処理します。
セマンティック検索機能
OpenSearch の強力な検索エンジン上に構築されたエージェントメモリは、洗練された検索機能を提供します。エージェントメモリは完全な OpenSearch クエリ DSL をサポートしており、term クエリ、range フィルター、セマンティック検索、集計、または OpenSearch の強力なクエリ機能の任意の組み合わせを使用してメモリを検索・取得する完全な柔軟性を提供します。
以下の例は、ユーザー設定の検索クエリを示しています。
GET /_plugins/_ml/memory_containers/<memory_container_id>/memories/long-term/_search
{
"query": {
"bool": {
"must": [
{"term": {"namespace.user_id": "user123"}},
{"match": {"strategy_type": "USER_PREFERENCE"}}
]
}
},
"sort": [
{"created_time": {"order": "desc"}}
]
}
構造化データストレージ
会話以外にも、エージェントメモリはさまざまなデータニーズに対応する複数のペイロードタイプをサポートしています。
会話ペイロード: ユーザーとアシスタント間の会話メッセージを保存するため。
データペイロード: エージェント状態、チェックポイント、参照情報などの構造化された非会話データ用。
以下の例は構造化データの保存を示しています。
POST /_plugins/_ml/memory_containers/<memory_container_id>/memories
{
"structured_data": {
"agent_state": "researching",
"current_task": "analyze customer feedback",
"progress": 0.75,
"tool_invocations": [
{
"tool_name": "ListIndexTool",
"tool_input": {"filter": "*,-.plugins*"},
"tool_output": "green open security-auditlog-2025.09.17..."
}
]
},
"namespace": {
"agent_id": "research-agent-1",
"session_id": "session456"
},
"metadata": {
"status": "checkpoint",
"branch": {
"branch_name": "main",
"root_event_id": "evt-12345"
}
},
"tags": {
"data_type": "trace",
"priority": "high"
},
"payload_type": "data",
"infer": false
}
特殊なユースケースでは、binary_data フィールドを使用して Base64 エンコーディングでバイナリデータを保存することもできます。
ベストプラクティス
以下の推奨事項は、メモリシステム設計、戦略の最適化、運用効率、フレームワーク統合をカバーし、本番環境でエージェントメモリを効果的に実装するのに役立ちます。
効果的なメモリシステムの設計
エージェントの特定のユースケースとユーザーニーズに基づいてメモリ実装を構造化します。
- 即時の会話コンテキストと一時的なエージェント状態にはワーキングメモリを使用
- 永続的な知識とユーザー設定には推論を有効にした長期メモリを使用
- アプリケーションのユーザーおよびセッション管理に合わせた名前空間パターンを実装
メモリ戦略の最適化
最も価値のある洞察を抽出するようにメモリ処理を設定します。
- 知識の蓄積と事実抽出には
SEMANTIC戦略を使用 - ユーザーの選択と設定を学習・記憶するには
USER_PREFERENCE戦略を適用 - 会話コンテキストの圧縮には
SUMMARY戦略を実装 - 特定のドメインに最適な戦略の組み合わせをテスト
効率的なメモリ操作
メモリ操作でパフォーマンスとコンテキストの豊富さのバランスを取ります。
- コンテキスト確立のために会話開始時に関連メモリを取得
- ターゲットを絞ったクエリを使用: 即時コンテキストには最近のワーキングメモリ、履歴的な洞察には長期メモリ
- 正確な会話履歴を維持するためにインタラクションを迅速に保存
- 長期メモリ抽出は非同期であることを忘れずに、結果整合性を考慮して設計
統合アプローチ
エージェントフレームワークと接続する際:
- フレームワークインターフェースを OpenSearch API にマッピングする抽象化レイヤーを構築
- 本番使用のための適切なエラー処理と接続管理を実装
- アプリケーションのマルチテナンシーニーズをサポートする名前空間戦略を設計
- 頻繁にアクセスされるメモリデータのキャッシュパターンを検討
はじめに
エージェントにエージェントメモリを実装するには、以下の手順を使用します。
- 適切な埋め込みモデルと LLM モデルでメモリコンテナを作成:
curl -X POST "localhost:9200/_plugins/_ml/memory_containers/_create" \
-H "Content-Type: application/json" \
-d '{
"name": "my-agent-memory",
"description": "Memory for my AI agent",
"configuration": {
"embedding_model_type": "TEXT_EMBEDDING",
"embedding_model_id": "your-embedding-model-id",
"llm_id": "your-llm-model-id",
"strategies": [
{
"type": "USER_PREFERENCE",
"namespace": ["user_id"]
}
]
}
}'
- エージェントインタラクション中にメモリを追加:
curl -X POST "localhost:9200/_plugins/_ml/memory_containers/<memory_container_id>/memories" \
-H "Content-Type: application/json" \
-d '{
"messages": [
{"role": "user", "content": [{"text": "I prefer concise responses", "type": "text"}]},
{"role": "assistant", "content": [{"text": "I will keep my responses brief and to the point", "type": "text"}]}
],
"namespace": {"user_id": "user123"},
"payload_type": "conversational",
"infer": true
}'
- 関連メモリを検索・取得:
curl -X GET "localhost:9200/_plugins/_ml/memory_containers/<memory_container_id>/memories/long-term/_search" \
-H "Content-Type: application/json" \
-d '{
"query": {
"bool": {
"must": [
{"term": {"namespace.user_id": "user123"}},
{"match": {"strategy_type": "USER_PREFERENCE"}}
]
}
}
}'
- LangChain、LangGraph、またはカスタム実装について上記で示したパターンを使用してエージェントフレームワークと統合。
ユースケース例
以下の例は、OpenSearch エージェントメモリをさまざまな業界やワークフローに適用して、よりインテリジェントでコンテキスト認識型の AI エージェントを作成する方法を示しています。
永続コンテキストを持つカスタマーサービス
顧客関係履歴を維持するエージェントを構築:
- 推論を有効にして顧客インタラクションを保存し、設定と過去の問題を記録
-
USER_PREFERENCE戦略を使用してコミュニケーションスタイルとサービス設定を学習 - データ分離と効率的なアクセスのために名前空間を使用して顧客 ID で整理
- 構造化データストレージを通じて既存のサポートシステムと接続
知識構築型リサーチアシスタント
時間の経過とともに専門知識を蓄積するエージェントを作成:
- 即時コンテキストのためにワーキングメモリにリサーチクエリと発見を保存
-
SEMANTIC戦略を使用してリサーチトピック全体で相互接続された知識ベースを構築 - 方法論の進化と意思決定の根拠を追跡するためにリサーチ履歴を維持
- 複雑で長期的なリサーチプロジェクトのためにクロスセッション知識構築を有効化
チームベースの AI コラボレーション
コラボレーティブワークフローをサポートするエージェントを展開:
- チーム、プロジェクト、個人のメモリ分離のための名前空間階層を実装
- プロセスの透明性と改善のためにエージェントの意思決定トレースを保存
- 適切なアクセス境界を維持しながら制御された知識共有を有効化
- 構造化された会話要約を通じてコラボレーティブプロセスを追跡
まとめ
OpenSearch エージェントメモリは、AI エージェント開発における最も重要な課題の 1 つである、時間の経過とともに記憶し、学習し、コンテキストを構築するシステムの作成に対処します。OpenSearch の堅牢な検索機能とインテリジェントなメモリ処理を組み合わせることで、開発者は複雑なメモリインフラストラクチャを管理することなく、より効果的な AI エージェントを構築できます。
柔軟なメモリタイプ、設定可能な処理戦略、階層的な組織化の組み合わせにより、OpenSearch エージェントメモリは、ユーザー設定を記憶するカスタマーサービスボットからセッション全体で知識を蓄積するリサーチアシスタントまで、幅広いアプリケーションに適しています。REST API 設計により、既存のエージェントフレームワークとの互換性を確保しながら、本番デプロイメントに必要なスケーラビリティを提供します。
AI エージェントがビジネスアプリケーションでより普及するにつれて、永続的でインテリジェントなメモリを維持する能力が、真に有用なエージェントと単純な質問応答システムを区別するようになります。OpenSearch エージェントメモリは、これらの次世代 AI エクスペリエンスを構築するための基盤を提供します。
始める準備はできましたか?完全なエージェントメモリドキュメントを参照して、今日からよりスマートなエージェントの構築を始めましょう。
OpenSearch Project(OSS) の Publicationです。 OpenSearch Tokyo User Group : meetup.com/opensearch-project-tokyo/
Discussion