Managed Agents Memory Stores

上級

What you'll learn

Memory Store とは何か — そして古いクライアントサイドの memory tool とどう違うか
ストアがセッションサンドボックスの /mnt/memory/ にどうマウントされ、エージェントがそれをどう使うか
人がよくつまずくベータヘッダのルール(agent-memory-2026-07-22 vs managed-agents-2026-04-01)
完全なライフサイクル:作成 → シード → アタッチ → 読み書き → バージョン監査 → リダクト
具体的な制限:セッションあたり8ストア、ストアあたり2,000メモリ、メモリあたり100 kB

Managed Agents で構築したことがあれば、各セッションがデフォルトで新鮮なコンテキストから始まることを知っているでしょう。セッションが終わると、エージェントが学んだものは一緒に消えます。Memory Stores はファーストパーティの解決策です:セッション間で永続する、サーバーサイドでバージョン管理されたテキストドキュメントのコレクションで、エージェントのサンドボックスに、ファイルツールで読み書きできる普通のディレクトリとしてマウントされます。

Memory Stores vs クライアントサイドの memory tool

現在、Claude プラットフォームには 2つの異なる「メモリ」プリミティブ があります。混同しないでください。

	Memory Stores(このページ)	クライアントサイド memory tool(別ページ)
メモリの保管場所	Anthropic ホスト、ワークスペーススコープ	自身のストレージ(Redis、Postgres、ファイル…)
ループを実行するのは誰	Managed Agents	あなた(Messages API + tool ループ)
ベータヘッダ	`agent-memory-2026-07-22`	`context-management-2025-06-27`(memory tool)
エージェントの読み方	`/mnt/memory/` にファイルとしてマウント	ツール呼び出し(`view`、`str_replace`、`create`…)
監査証跡	不変バージョン、redact エンドポイント	自分で構築するもの

同じ アイデア(永続状態);異なる プリミティブ。以下すべては Memory Stores の話です — Managed Agents 専用のサーバーサイドのもの。

メンタルモデル

ストアは小さな Markdown/テキストファイル(メモリ)のフォルダで、ワークスペースにスコープされます。セッションにアタッチすると、サンドボックス内にマウントとして現れ、Claude は標準のエージェントツールセットで読み書きします — ファイルシステムの他の部分に使うのと同じツールです。

2つの重要な系:

各マウントに関する注記(名前、マウントパス、アクセスモード、説明、およびセッションごとの instructions)が自動的にシステムプロンプトに挿入されます。エージェントは伝えなくてもマウントが存在することを知っています。
マウントパスの外(/mnt/memory/ の他の場所)への書き込みは、コンテナローカルのスクラッチに落ち、セッション終了時に失われます。マウントパスへの書き込みだけが永続します。

ベータヘッダのルール(落とし穴)

ここで人は20分を失います。

Watch out

メモリストアのエンドポイントは anthropic-beta: agent-memory-2026-07-22 を使う — それだけ。
セッションエンドポイント(メモリストアをセッションにアタッチすることを含む)は依然として managed-agents-2026-04-01 を使う。
メモリストアリクエストに両方送ると HTTP 400 が返る。コードがベータヘッダを明示的に設定するなら、追加ではなく置換すること。

公式SDKを使えばヘッダは自動的に正しく設定されます。生のHTTPなら、呼び出し部を分けてください:

呼び出し	ヘッダ
`POST /v1/memory_stores`(作成)	`agent-memory-2026-07-22`
`POST /v1/memory_stores/{id}/memories`(メモリの作成/リスト/更新/削除)	`agent-memory-2026-07-22`
`POST /v1/memory_stores/{id}/memory_versions/…/redact`	`agent-memory-2026-07-22`
`POST /v1/sessions` — `resources[]` にストアをアタッチ	`managed-agents-2026-04-01`

ライフサイクル

Guided walkthrough1 of 5

POST /v1/memory_stores で name と description を指定。description はエージェントに渡されるので、ブリーフのように書くこと:「ユーザーごとの好みとプロジェクトコンテキスト」。

ストアと最初のメモリを作成

ストアの name と description はエージェントが見るもの — フォルダのREADMEのように書いてください。

ストア作成(curl、生HTTP)

curl -s https://api.anthropic.com/v1/memory_stores \
-H "x-api-key: $ANTHROPIC_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "anthropic-beta: agent-memory-2026-07-22" \
-H "content-type: application/json" \
-d '{"name": "User Preferences", "description": "Per-user preferences and project context."}'
# -> {"id": "memstore_01Hx...", ...}

メモリをシード

curl -s "https://api.anthropic.com/v1/memory_stores/$store_id/memories" \
-H "x-api-key: $ANTHROPIC_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "anthropic-beta: agent-memory-2026-07-22" \
-H "content-type: application/json" \
-d '{"path": "/formatting_standards.md", "content": "All reports use GAAP formatting. Dates are ISO-8601."}'

ストアをセッションにアタッチ

ヘッダが managed-agents-2026-04-01 に戻ることに注意 — セッションエンドポイント(アタッチを含む)は Managed Agents ヘッダを使います。

セッション作成時にアタッチ(read_write)

curl -s https://api.anthropic.com/v1/sessions \
-H "x-api-key: $ANTHROPIC_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "anthropic-beta: managed-agents-2026-04-01" \
-H "content-type: application/json" \
-d '{
  "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."
  }]
}'

instructions フィールドは 4,096 文字が上限で、ストアの name と description と一緒にエージェントに表示されます。

アクセスモードとインジェクションリスク

access はデフォルトで read_write。エージェントがセッションから学ぶべきときはこれが正しい選択です。誰も(何も)変更してほしくないストアには 間違った 選択です。

Watch out

read_write ストアは、セッションのプロンプトインジェクションリスクの下流にある。エージェントが信頼できない入力(ユーザープロンプト、フェッチしたページ、サードパーティのツール出力)を処理する場合、成功したインジェクションはストアに悪意あるコンテンツを書き込める。後のセッションはそれを信頼できるメモリとして読む。
経験則:共有参照資料(標準、用語集、ドメインドキュメント)は read_only でアタッチ。増える必要のあるユーザーごとまたはセッションごとの状態だけ read_write でアタッチ。
必要なら両方アタッチ:1つの read_only 参照ストア + 1つの read_write スクラッチストア。セッションあたり最大8。

具体的な制限

すべて公式ドキュメントから、すべて覚える価値あり:

制限	値
セッションあたりメモリストア	8
ストアあたりメモリ	2,000
メモリあたりバイト	100 kB(約25kトークン)
`instructions` 長(アタッチごと)	4,096 文字
バージョン保持	30日(最近のバージョンは常に保持)

ストアが2,000メモリに達すると、以降の書き込み — 直接API呼び出しとエージェント自身のファイル書き込み — が失敗し始めます。ドキュメント推奨の解決策は「1つの巨大ストア」ではなく、多くの小さくフォーカスされたストア(ユーザーごとに1つ、共有参照に1つ、プロジェクトごとに1つ)を使い、memories.delete で古いエントリを剪定するか、dreaming セッションを実行して統合することです。

監査証跡、バージョン、ロールバック

メモリへの書き込みごとに不変な メモリバージョン(memver_...)が作成されます。バージョンはメモリではなくストアに属するので、メモリ自体が削除された後も残ります — 監査証跡は完全なまま。

便利なパターン:

時点検査: GET /v1/memory_stores/{id}/memory_versions?memory_id=… で誰が何を変えたかを新しい順に確認。
ロールバック: 専用の restore エンドポイントはない。欲しいバージョンを取得し、その content を memories.update で書き戻す(親メモリが消えていれば memories.create)。
安全な並行編集: memories.update に content_sha256 プレコンディションを渡す。head ハッシュがもう一致しなければ更新は拒否され、再読して再試行 — 古典的な楽観的並行性。

コンプライアンス:バージョンをリダクト

PII、秘密、またはユーザー削除リクエストのためにコンテンツを 履歴から消す 必要があるとき、redact を使ってください。コンテンツをスクラブしつつ監査証跡(いつ誰が何をしたか)を保持します。

Pro tip

ライブメモリの現在の head はリダクトできない。まず新しいバージョンを書く(またはメモリを削除する)、次に古いバージョンをリダクト。
バージョンは親メモリより長生きなので、メモリ削除は自動的に履歴を消さない — 依然としてバージョンごとにリダクトする。
バージョン保持は最低30日。コンプライアンスのためにより長い保持が必要なら、期限切れになる前にAPI経由でバージョンをエクスポート。

よくある間違い

Pro tip

メモリストア呼び出しに両方のベータヘッダを送る — HTTP 400 が返る。追加ではなく置換。
実行中セッションにストアを追加または削除しようとする — サポートされていない。アタッチはセッション作成時のみ、以上。
共有参照ストアを read_write でアタッチ — 1回のインジェクションで、あなたの標準が将来のすべてのセッションで破損する。
多くのフォーカスされたストアではなく1つの巨大ストア — 2,000上限に達し、以降の書き込みがロックアウトされる。
永続を期待して /mnt/memory/scratch/ に書き込む — マウントパス外はすべてコンテナローカルで、セッション終了時に蒸発する。

自分でチェック

0/5

anthropic-beta: agent-memory-2026-07-22 と anthropic-beta: managed-agents-2026-04-01 の両方でメモリストア作成リクエストを送りました。何が起きますか?
セッションサンドボックス内でメモリストアはどこに現れますか?
エージェントが外部ユーザーからのメールを処理します。共有の「標準と用語集」ストアに最も安全なアクセスモードは?
漏洩した秘密を履歴から削除する必要があります。どの順序が機能しますか?
メモリあたりのサイズ上限とストアあたりのメモリ数は?

Key takeaways

Memory Stores は Managed Agents 用のサーバーサイド永続メモリプリミティブ — クライアントサイドの memory tool とは異なる。
ヘッダのルール:メモリストアエンドポイントには agent-memory-2026-07-22、セッションエンドポイントには managed-agents-2026-04-01。決して両方ではない。
ストアはセッション作成時にアタッチし、/mnt/memory/[store-slug]/ にマウントされる;セッション途中の追加/削除はサポートされない。
共有参照にはデフォルトで read_only;ユーザーごとまたはセッションごとの成長だけ read_write にする。
書き込みごとに不変バージョンが作成される;ロールバックは「取得 + 書き戻し」;redact はコンプライアンスのために履歴をスクラブする。

Managed Agents — 親コンセプト:エージェント、セッション、環境、vault、デプロイメント
APIでエージェントを構築する — 自分でループを回すなら
Memory Tool と Context Editing(クライアントサイド) — もう一つ のメモリプリミティブ
プロンプトインジェクション — 共有ストアで read_only が重要な理由
エージェントメモリアーキテクチャ — 永続メモリシステムの背後にある設計パターン

Memory Stores vs クライアントサイドの memory tool​

メンタルモデル​

ベータヘッダのルール(落とし穴)​

ライフサイクル​

ストアと最初のメモリを作成​

ストア作成(curl、生HTTP)

メモリをシード

ストアをセッションにアタッチ​

セッション作成時にアタッチ(read_write)

アクセスモードとインジェクションリスク​

具体的な制限​

監査証跡、バージョン、ロールバック​

コンプライアンス:バージョンをリダクト​

よくある間違い​

自分でチェック​

自分でチェック

次へ​

Memory Stores vs クライアントサイドの memory tool

メンタルモデル

ベータヘッダのルール(落とし穴)

ライフサイクル

ストアと最初のメモリを作成

ストアをセッションにアタッチ

アクセスモードとインジェクションリスク

具体的な制限

監査証跡、バージョン、ロールバック

コンプライアンス:バージョンをリダクト

よくある間違い

自分でチェック

次へ