各Managed Agentsセッションは、デフォルトでは新しいコンテキストで開始されます。セッションが終了すると、エージェントが構築した状態はすべて失われます。メモリストアを使用すると、エージェントはユーザーの好み、プロジェクトの規約、過去の間違い、ドメインコンテキストなどの情報をセッションをまたいで引き継ぐことができます。
メモリストアは、Claude向けに最適化された、ワークスペーススコープのテキストドキュメントのコレクションです。ストアをセッションにアタッチすると、セッションのサンドボックス内にディレクトリとしてマウントされます。エージェントは、ファイルシステムの他の部分に使用するのと同じファイルツールでそれを読み書きし、各マウントを説明するメモがシステムプロンプトに自動的に追加され、エージェントにどこを見ればよいかを伝えます。これらのやり取りにはエージェントツールセットが必要です。エージェント作成時に必ず有効にしてください。
ストア内の各メモリはパスでアドレス指定され、APIまたはConsoleを通じて直接読み取りおよび編集できるため、チューニング、インポート、エクスポートが可能です。
メモリへのすべての変更は、不変のメモリバージョンを作成し、エージェントが書き込むすべてのものに対して監査証跡と特定時点への復旧を提供します。
ストアにnameとdescriptionを指定します。descriptionはエージェントに渡され、ストアに何が含まれているかを伝えます。
store_id=$(ant beta:memory-stores create \
--name "User Preferences" \
--description "Per-user preferences and project context." \
--transform id --raw-output)メモリストアのid(memstore_...)は、ストアをセッションにアタッチする際に渡すものです。
エージェントが実行される前に、参照資料をストアに事前ロードします。
ant beta:memory-stores:memories create \
--memory-store-id "$store_id" \
--path "/formatting_standards.md" \
--content "All reports use GAAP formatting. Dates are ISO-8601..." \
> /dev/nullメモリストアは、セッション作成時にセッションのresources[]配列でアタッチされます。ファイルやリポジトリのリソースとは異なり、メモリストアはセッション作成時にのみアタッチできます。実行中のセッションへの追加や削除はサポートされていません。
オプションでinstructionsを含めて、エージェントがこのストアをどのように使用すべきかについてセッション固有のガイダンスを提供できます。これはストアのnameとdescriptionとともにエージェントに表示され、4,096文字に制限されています。
accessも設定できます。デフォルトはread_write(以下の例で明示的に示されています)ですが、read_onlyもサポートされています。
ant beta:sessions create <<YAML
agent: $agent_id
environment_id: $environment_id
resources:
- type: memory_store
memory_store_id: $store_id
access: read_write
instructions: User preferences and project context. Check before starting any task.
YAMLセッションごとに最大8個のメモリストアがサポートされています。メモリの異なる部分に異なる所有者やアクセスルールがある場合は、複数のストアをアタッチしてください。一般的な理由は次のとおりです。
アタッチされた各ストアは、セッションのサンドボックス内の/mnt/memory/配下のディレクトリとしてマウントされます。ディレクトリ名は、ストアの表示名をファイルシステムセーフなスラッグにサニタイズしたものです(小文字化され、英数字以外の連続は単一のハイフンになります)。そのため、「Demo Memory」という名前のストアは/mnt/memory/demo-memory/にマウントされます。正確なパスは、セッションのメモリストアリソースのmount_pathフィールドで返されます。自分で構築するのではなく、そこから読み取ってください。エージェントは標準のエージェントツールセットでストアを読み書きします。マウントパス配下への書き込みはストアに永続化され、それを共有するセッション間で同期が保たれます。/mnt/memory/配下の他のパスへの書き込みは、コンテナローカルのスクラッチに置かれ、セッションが終了すると失われます。各マウントの簡単な説明(表示名、マウントパス、アクセスモード、ストアのdescription、およびinstructions)がシステムプロンプトに自動的に追加されます。
accessはファイルシステムレベルで強制されます。read_onlyマウントは書き込みを拒否し、read_writeマウントへの書き込みは、セッションに帰属するメモリバージョンを生成します。
エージェントの読み取りと書き込みは、マウントに触れたツールの通常のagent.tool_useおよびagent.tool_resultイベントとしてイベントストリームに表示されます。
メモリストアはAPIを通じて直接管理できます。レビューワークフローの構築、不正なメモリの修正、またはセッション実行前のストアのシードに使用してください。
ストア内のメモリを一覧表示します。結果は、サーバーが定義した安定した順序で返されます。
path_prefixは、リストを1つのディレクトリにスコープします。/で終わる必要があり、パスセグメント全体に一致するため、path_prefix=/notes/は/notes/todo.mdを返しますが、/notes-archive/todo.mdは返しません。depthは、path_prefixの下でリストがどれだけ深くなるかを制御します。省略する(または0を渡す)とサブツリー全体を一覧表示し、1を渡すと直接の子のみを一覧表示します。その他の値は400エラーを返します。ant beta:memory-stores:memories list \
--memory-store-id "$store_id" \
--path-prefix "/"完全なパラメータとレスポンススキーマについては、メモリの一覧表示リファレンスを参照してください。
個々のメモリを取得すると、完全なコンテンツが返されます。
ant beta:memory-stores:memories retrieve \
--memory-store-id "$store_id" \
--memory-id "$mem_id"完全なパラメータとレスポンススキーマについては、メモリの取得リファレンスを参照してください。
memories.createは、指定されたpathにメモリを作成します。createは上書きしません。既存のメモリを変更するには、memories.updateを使用してください。
mem=$(ant beta:memory-stores:memories create \
--memory-store-id "$store_id" \
--path "/preferences/formatting.md" \
--content "Always use tabs, not spaces." \
--format json)
mem_id=$(jq -r '.id' <<< "$mem")
mem_sha=$(jq -r '.content_sha256' <<< "$mem")完全なパラメータとレスポンススキーマについては、メモリの作成リファレンスを参照してください。
memories.updateは、IDで既存のメモリを変更します。content、path(名前の変更)、またはその両方を変更できます。この例では、メモリをアーカイブパスに名前変更します。
ant beta:memory-stores:memories update \
--memory-store-id "$store_id" \
--memory-id "$mem_id" \
--path "/archive/2026_q1_formatting.md" \
> /dev/null完全なパラメータとレスポンススキーマについては、メモリの更新リファレンスを参照してください。
同時書き込みを上書きしてしまうのを避けるには、content_sha256の事前条件を渡します。更新は、保存されているコンテンツハッシュが読み取ったものとまだ一致する場合にのみ適用されます。不一致の場合は、メモリを再読み取りし、最新の状態に対して再試行してください。
ant beta:memory-stores:memories update \
--memory-store-id "$store_id" \
--memory-id "$mem_id" \
--content "CORRECTED: Always use 2-space indentation." \
--precondition "{type: content_sha256, content_sha256: $mem_sha}" \
> /dev/nullant beta:memory-stores:memories delete \
--memory-store-id "$store_id" \
--memory-id "$mem_id" \
> /dev/null完全なパラメータとレスポンススキーマについては、メモリの削除リファレンスを参照してください。
メモリへのすべての変更は、不変のメモリバージョン(memver_...)を作成します。バージョンエンドポイントを使用して、誰がいつ何を変更したかを監査し、以前のスナップショットを検査または復元し、redactで履歴から機密コンテンツを削除します。
バージョンは(個々のメモリではなく)ストアに属し、メモリ自体が削除された後も存続するため、監査証跡は完全なまま保たれます。バージョンは30日間保持されます。ただし、最近のバージョンは経過時間に関係なく常に保持されるため、変更頻度の低いメモリは30日を超えて履歴を保持する場合があります。ライブのmemories.retrieve呼び出しは常に最新バージョンを返します。バージョンエンドポイントは保持されている履歴を提供します。
専用の復元エンドポイントはありません。ロールバックするには、目的のバージョンを取得し、そのcontentをmemories.update(または親メモリが削除されている場合はmemories.create。バージョンは親よりも長く存続するため)で書き戻します。
過去のメモリバージョンは30日後に削除される場合があります。メモリ履歴をより長く保持するには、APIを通じてバージョンをエクスポートしてください。
ストアのバージョン履歴を新しい順に一覧表示します。この例では、単一のメモリの履歴にフィルタリングしています。
versions=$(ant beta:memory-stores:memory-versions list \
--memory-store-id "$store_id" \
--memory-id "$mem_id" \
--format json)
# `list --format json` はアイテムごとに1つのJSONオブジェクトを出力します。
jq -r '"\(.id): \(.operation)"' <<< "$versions"
version_id=$(jq -rs '.[1].id' <<< "$versions")完全なパラメータとレスポンススキーマについては、メモリバージョンの一覧表示リファレンスを参照してください。
個々のバージョンを取得すると、リストレスポンスと同じフィールドに加えて、完全なcontent本文が返されます。
ant beta:memory-stores:memory-versions retrieve \
--memory-store-id "$store_id" \
--memory-version-id "$version_id"完全なパラメータとレスポンススキーマについては、メモリバージョンの取得リファレンスを参照してください。
redactは、監査証跡(誰がいつ何をしたか)を保持しながら、過去のバージョンからコンテンツを削除します。漏洩したシークレットやPIIの削除、ユーザーの削除リクエストなどのコンプライアンスワークフローに使用してください。
ライブメモリの現在のヘッドであるバージョンはredactできません。まず新しいバージョンを書き込む(またはメモリを削除する)してから、古いバージョンをredactしてください。
ant beta:memory-stores:memory-versions redact \
--memory-store-id "$store_id" \
--memory-version-id "$version_id"完全なパラメータとレスポンススキーマについては、メモリバージョンのredactリファレンスを参照してください。
createに加えて、メモリストアはretrieve、update、list、archive、deleteをサポートしています。
ワークスペース内のストアを一覧表示します。アーカイブされたストアはデフォルトで除外されます。含めるにはinclude_archived: trueを渡してください。
ant beta:memory-stores list --include-archived完全なパラメータとレスポンススキーマについては、メモリストアの一覧表示リファレンスを参照してください。
アーカイブすると、ストアは読み取り専用になり、新しいセッションにアタッチできなくなります。アーカイブは一方向であり、アーカイブ解除はありません。
ant beta:memory-stores archive --memory-store-id "$store_id"完全なパラメータとレスポンススキーマについては、メモリストアのアーカイブリファレンスを参照してください。
ストアをそのすべてのメモリとバージョンとともに完全に削除するには、memory_stores.deleteを使用してください。
ストアが2,000メモリの制限に達すると、新しいメモリへの書き込みは失敗します。直接のmemories.create呼び出しと、マップされていないパスへのエージェントのファイル書き込みの両方が対象です。既存のメモリは引き続き読み取りおよび編集可能です。以下のプラクティスは、制限を十分に下回る状態を維持し、制限に達した場合に適切に回復するのに役立ちます。
焦点を絞ったストアを使用する。 1つの大きな汎用ストアではなく、目的別に構築された小さなストアを使用してください。ユーザーごとに1つ、共有ドメイン知識用に1つ、プロジェクト固有のコンテキスト用に1つなどです。各ストアには独自の2,000メモリの制限があるため、ストアのスコープを絞ることで、いずれか1つが満杯になる可能性が低くなります。
ストアが満杯になる前に凝縮または削除する。 memories.deleteで古いまたは冗長なメモリを削除してください。また、ドリーミングセッションを実行することもできます。これは、元のストアを変更するのではなく、断片化されたコンテンツを別の新しい出力ストアに統合します。セッションをその出力ストアに切り替えてから、元のストアをアーカイブまたは削除してください。
必要に応じて新しいストアをアタッチする。 ストアが有用なスコープを超えて成長した場合は、新しいコンテンツ用に新しいストアをアタッチし、元のストアをread_onlyアクセスでアタッチしてください。エージェントは両方から読み取ることができますが、書き込みは新しいストアにのみ行います。
適切な場合は書き込みアクセスを制限する。 共有参照資料を読み取るだけのセッションにはread_writeは必要ありません。書き込みアクセスを実際に新しいメモリを追加するセッションに限定することで、成長の原因を追跡しやすくなります。
Was this page helpful?