各Managed Agentsセッションは、デフォルトでは新しいコンテキストから開始されます。セッションが終了すると、エージェントが構築した状態はすべて失われます。メモリストアを使用すると、エージェントはユーザーの好み、プロジェクトの規約、過去のミス、ドメインのコンテキストといった情報をセッションをまたいで引き継ぐことができます。
memory store(メモリストア)は、Claude向けに最適化された、ワークスペーススコープのテキストドキュメントのコレクションです。ストアをセッションにアタッチすると、セッションのサンドボックス内にディレクトリとしてマウントされます。エージェントは、ファイルシステムの他の部分に使用するのと同じファイルツールでこれを読み書きします。また、各マウントを説明するメモが自動的にシステムプロンプトに追加され、エージェントにどこを参照すべきかを伝えます。これらの操作にはエージェントツールセットが必要です。エージェント作成時に必ず有効にしてください。
ストア内の各memory(メモリ)はパスでアドレス指定され、APIまたはClaude Consoleを通じて直接読み取りや編集ができるため、チューニング、インポート、エクスポートが可能です。
メモリへのすべての変更は不変のmemory version(メモリバージョン)を作成し、エージェントが書き込むすべての内容について監査証跡とポイントインタイムリカバリを提供します。
ストアに 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?