Managed Agents にセッション横断の永続メモリ機能「Memory Stores」を追加
Managed Agents のスキルドキュメントに Memory Stores(パブリックベータ)の解説ページが新設され、エージェントがセッションをまたいで知識を保持できる仕組みが整備された。既存の resources[] 機構に統合されるため、ファイルやリポジトリとほぼ同じインターフェースで扱える。
背景
Managed Agents のセッションはデフォルトでエフェメラルであり、セッションが終了するとエージェントが得た情報はすべて消失する。この制約を解消するために Memory Stores が導入された。Memory Stores はワークスペーススコープの小さなテキストドキュメントのコレクションで、セッションをまたいで情報を保持できる。
新しいドキュメント shared/managed-agents-memory.md(197行追加)がその中心となる解説ページであり、オブジェクトモデル・セッションへのアタッチ方法・FUSE マウントのエージェントインターフェース・ホスト側の CRUD・バージョン管理と Redact までを体系的に説明している。あわせて SKILL.md、managed-agents-api-reference.md、managed-agents-core.md、managed-agents-environments.md、managed-agents-overview.md の5ファイルに相互参照が追加され、ドキュメント全体の整合性が保たれた。
技術的な変更
Memory Stores は3層のオブジェクトモデルで構成される。各オブジェクトのIDプレフィックスで層が識別できる設計になっている。
| オブジェクト | ID プレフィックス | スコープ | 備考 |
|---|---|---|---|
| Memory Store | memstore_... |
ワークスペース |
resources[] でセッションにアタッチ |
| Memory | mem_... |
ストア | パスで管理されるテキストファイル(≤ 100KB) |
| Memory Version | memver_... |
メモリ | ミューテーションごとに生成される不変スナップショット |
ストアの作成と初期コンテンツのシードは以下のように行う。description はエージェントのシステムプロンプトに渡されるため、モデルが理解しやすい文章で記述することが推奨されている。
store = client.beta.memory_stores.create(
name="User Preferences",
description="Per-user preferences and project context.",
)
client.beta.memory_stores.memories.create(
store.id,
path="/formatting_standards.md",
content="All reports use GAAP formatting. Dates are ISO-8601...",
)
セッションへのアタッチは resources[] に type: "memory_store" エントリを追加するだけで、既存の file や github_repository と並べて指定できる。ただし セッション作成時にのみ指定可能であり、sessions.resources.add() では後から追加できない。また1セッションあたりの上限は 8ストアである。
session = client.beta.sessions.create(
agent="agent_abc123",
environment_id="env_xyz",
resources=[
{"type": "memory_store", "memory_store_id": store.id},
],
)
アタッチされたストアはコンテナ内で /mnt/memory/<store>/ にFUSEマウントされ、エージェントは通常のファイルツールでシームレスに読み書きできる。ホスト側からメモリを操作する場合、path を指定した memories.create で新規作成し、既存ファイルの更新は memory_id を使った memories.update で行う。content_sha256 プリコンディション(楽観的排他制御)もサポートされており、競合を検知できる。
API リファレンス(managed-agents-api-reference.md)には Memory Stores・Memories・Memory Versions の3セクションが追加された。削除・アーカイブの可否は既存リソースと異なる点があるため注意が必要だ。
-
Memory Stores:
deleteとarchiveの両方あり -
Memories:
deleteのみ(archiveなし) -
Memory Versions:
deleteもarchiveもなく、redactのみ
この非対称な操作セットは、バージョン履歴の不変性を保ちながら機密コンテンツを消去できるよう設計されている。
SDKのベータ名前空間にも memory_stores が追加され、client.beta.{agents,environments,sessions,vaults,memory_stores}.* の全呼び出しで managed-agents-2026-04-01 ベータヘッダーが自動付与される。SKILL.md、managed-agents-overview.md、managed-agents-api-reference.md の3箇所でこの記述が更新されており、ドキュメントの一貫性が保たれている。
設計判断
Memory Stores は既存の resources[] 配列に統合する設計が採用されており、file や github_repository と同じ仕組みでセッションに結びつけられる。エージェントから見たインターフェースもFUSEマウントによる通常ファイルアクセスであるため、Memory Stores 専用のツール呼び出しは不要だ。
一方で、file や github_repository と異なりセッション作成後の追加が不可という制約を設けている。これはアーキテクチャ図(managed-agents-core.md)の「attached at startup」という表現にも反映されており、マウント処理がセッション起動シーケンスに組み込まれていることを示している。
バージョン管理の設計も注目に値する。メモリへのあらゆるミューテーションが不変スナップショット(memver_...)として記録されるため、監査証跡とポイントインタイムのロールバック・Redactが可能になっている。Memory Versions は delete も archive も持たず redact のみという非対称な操作セットは、履歴の完全性を保ちながら機密データを消去するというトレードオフの結果だ。
まとめ
Memory Stores は resources[] という既存の統合ポイントを拡張することで、エージェントのアーキテクチャを大きく変えることなくセッション横断の永続化を実現している。FUSE マウントによるファイルシステム抽象化・memver_ による不変バージョン履歴・redact による機密消去の組み合わせは、エージェントの永続メモリに求められる操作性・監査性・安全性のバランスを設計レベルで示している。