memory storeとは何か
ディレクトリとしてマウントされたテキストドキュメントのコレクション
ドキュメントの定義をそのまま引用すると、「memory storeとは、Claude向けに最適化された、ワークスペーススコープのテキストドキュメントのコレクション」です。
そして、評価に値するその仕組みは以下の通りです。「セッションにストアをアタッチすると、セッションのサンドボックス内にディレクトリとしてマウントされます。エージェントは、ファイルシステムの他の部分で使用するのと同じファイルツールを使って読み書きを行い、各マウントを説明するメモがシステムプロンプトに自動的に追加され、エージェントにどこを参照すべきかを伝えます。」
モデルが新しく学習すべきツールはありません。呼び出すべき検索APIもありません。エージェントはすでにファイルの読み書き方法を知っているため、メモリはすでに操作しているファイルシステムの一部になります。そして、システムプロンプトにポインタが追加されることで、ディレクトリの存在を認識できます。これは、モデルに永続性を提供する方法として、極めて摩擦の少ないアプローチです。
見落とすと静かに動作しなくなるセットアップ要件が1つあります。「これらのインタラクションにはagent toolsetが必要です。エージェント作成時に必ず有効にしてください。」
ドキュメントによると、ストアが保持することを想定している内容は、「ユーザーの好み、プロジェクトの規約、過去の過ち、およびドメインのコンテキスト」です。
不変のバージョンと、実用的な監査トレイル
この設計で特に注目したいのが次の点です。「メモリへのすべての変更は、不変のメモリバージョンを作成し、エージェントが書き込んだすべての内容に対する監査トレイルとポイントインタイムリカバリ（特定時点への復旧）を提供します。」
これが何を解決するかを考えてみてください。自律型エージェントが自身のメモリを管理する場合、誰もが懸念する失敗パターンは、エージェントが誤った情報を書き込み、それを前提として自信満々に処理を進めてしまうことです。不変のバージョニングがあれば、この問題を診断し、元に戻すことができます。いつエントリが変更されたかを確認し、変更前の状態にロールバックできるのです。私たちのシステムを含め、書き込み履歴を第一級のアーティファクトとして扱うメモリシステムはほとんどありません。これは素晴らしい決断であり、最初の誤った書き込みが発生して初めてその重要性に気づくような機能です。
各メモリはパスで指定され、直接編集可能
「ストア内の各メモリはパスによって指定され、APIまたはClaude Consoleを通じて直接読み取りおよび編集ができるため、チューニング、インポート、エクスポートが可能です。」
パス指定が可能であるということは、不透明なバイナリデータ（blob）ではなく、安定したレイアウトとして整理・把握できることを意味します。また、APIやConsoleを介した直接の読み書き・編集ができるため、ストアは外部から見て「書き込み専用」ではありません。初期データを投入（シード）したり、修正したり、内容を取り出したりできます。インポートとエクスポートが明示的に言及されている点は注目に値します。なぜなら、ポータビリティ（移植性）はメモリ機能において真っ先に無視されがちな要素だからです。
description フィールドはインターフェースの一部
ストアの作成には name と description が必要ですが、この説明（description）は単にダッシュボードに表示するためだけのものではありません。「説明はエージェントに渡され、ストアに何が含まれているかを伝えます。」
つまり、説明フィールドはプロンプトの一部として機能します。ドキュメントの例にある「ユーザーごとの好みやプロジェクトのコンテキスト」といった記述は、エージェントにいつそこを参照すべきかを教えます。説明が曖昧だと、どれだけデータが充実していても、エージェントがストアをうまく活用できなくなります。このフィールドは単なるラベルではなく、指示書として扱ってください。
セルフホストされたサンドボックスでは、ライブマウントではなく同期コピー
これを知らないと、丸半日を無駄にすることになる重要な違いがあります。マネージド環境ではストアがマウントされますが、セルフホストされたサンドボックスでは次のようになります。「そのディレクトリはライブマウントではありません。代わりに、SDKの環境ワーカーが、エージェントのツールが実行される前にアタッチされた各ストアをサンドボックスにダウンロードし、そのコピーをストアと同期させます。」
セルフホスト版のドキュメントでは、データフローの観点から同じ境界を次のように説明しています。「エージェントのスキルと、セッションにアタッチされたメモリ・ストアの内容はAnthropicによって保存され、セッションのためにサンドボックスにコピーされます。エージェントがメモリファイルに加えた変更はストアに同期されます。」また、計算がどこで行われるかについての補足として、「ツールの入力と出力は依然としてAnthropicのコントロールプレーン（Claudeが実行される場所）に送られ、モデルが結果を確認して次のアクションを決定できるようにします」とも記載されています。
実用的な解釈：セルフホスト型のインフラでは、エージェントは同期されたローカルコピーに対して作業を行います。これは、自身で制御するサンドボックスにとって適切な設計であり、頭に入れておくべきモデルは「ライブ共有ディレクトリ」ではなく、「ツールの実行前にダウンロードし、書き込み後に同期する」という流れです。
ベータヘッダーで一度はつまずく
設計上の欠陥ではなく、単に紛らわしいエラーを引き起こす細部です。Managed Agentsのリクエストは managed-agents-2026-04-01 ベータヘッダーを使用しますが、「memory storeのエンドポイントは例外で、代わりに agent-memory-2026-07-22 を使用します。」SDKを使用していれば、適切なヘッダーが自動的に設定されます。
手動でヘッダーを設定する場合は、次の明示的な警告に注意してください。「memory storeのリクエストで agent-memory-2026-07-22 と managed-agents-2026-04-01 を組み合わせないでください。両方を送信すると 400 エラーが返されます。」追加するのではなく、置き換えてください。なお、セッションにストアをアタッチするのはセッションエンドポイントであるため、その呼び出しには引き続き managed-agents-2026-04-01 を使用します。
また、同期ジョブを構築する前に読んでおくべきページネーションに関する注意点もあります。2026年7月22日時点で、古いヘッダーは GET /v1/memory_stores/{memory_store_id}/memories において同じリスト動作を採用しており、「ヘッダーなしで行われたリクエストからのページカーソルは、ヘッダーありのリクエストでは無効になるため、最初のページから再開してください」とされています。
memory storeの限界（境界）
ここに書かれていることは批判ではありません。これらは明示されたスコープの決定であり、これらを知ることで、その上に何を構築すべきかを判断できます。
ワークスペーススコープ。 定義にある通り、memory storeはワークスペーススコープのコレクションです。アーキテクチャはこの境界を引き継ぐため、ワークスペースをまたぐ知識の共有には別途計画が必要です。
Claude向けに最適化。 これも定義の通りです。ストアはClaudeが読み取るのに適した形式のテキストドキュメントであり、Anthropicのプラットフォーム上に存在します。Claudeをエージェントのランタイムとして使用している場合にはまさに理想的ですが、別のランタイムが同じストアを読み取ることはできないことを意味します。
設計上、エージェント向け。 ストアはエージェントが使用するためにセッションにマウントされます。チームが日常的に使用するアシスタントやエディタのための、共有ナレッジレイヤーとして位置づけられているわけではありません。
ベータ版。 ヘッダーがそれを示しています。2026年7月22日のページネーションに関する注意書きが示すように、挙動やエンドポイントはまだ変更される可能性があります。
人々がこれで何をするか
意図された通り、エージェントの作業用メモリとして使用する。 Managed Agents上で構築している場合、これは明白かつ正しい選択です。過去の過ちやプロジェクトの規約は、まさにドキュメントに記載されている通りの用途です。
1つのストアを会社のナレッジベースにしようとする。 魅力的ですが、ワークスペーススコープの制限や、Claudeエージェントしかそれを読み取れないという事実に衝突します。お使いのエディタや他のアシスタントはそれを読み取れません。
説明（description）フィールドをスキップする。 手っ取り早いですが、エージェントがそのストアが関連しているかどうかを判断するための手がかり（ポインタ）を失うことになります。
エージェントに自由に書き込ませ、一切確認しない。 不変のバージョニングにより、これは致命的な問題ではなく復旧可能なものになります（これがこの機能のポイントです）。しかし、復旧するためには誰かが問題に気づく必要があります。
ヘッダーを手動で設定し、400 エラーで1時間を無駄にする。 自動的に設定してくれるSDKを使用することで回避可能です。
セルフホストがマネージドと同じように動作すると仮定する。 同期コピーの違いがドキュメントに明記されているのは、まさに同じように動作しないからです。
解決策：プラットフォームのストアに置くべきものと、外部に置くべきものを決める
有益な考え方は、「どちらのメモリシステムが優れているか」ではありません。エージェントの作業用メモリと組織のナレッジは、寿命も性質も異なる別のものであり、分けて管理するのが最善であるということです。
エージェントの作業用メモリはストアに置く。 過去の過ち、エージェントが動作中に適用すべき規約、そのワークスペースにおけるユーザーごとの好みなどです。パスで整理し、適切な説明を書き、書き込みが誤っているように見える場合はバージョン履歴を活用してください。
永続的なナレッジはポータブル（移植可能）に保つ。 決定事項、制約、却下されたアプローチ、ドメイン用語など、ランタイムが変わっても変わらず、特定のエージェントの寿命を超えて存続し、チームの人間やエディタにとっても同様に有用な情報です。これは、単一プラットフォームの単一ワークスペースにスコープを限定すべきではないレイヤーです。
それこそが MemoryLake です。アシスタントやエージェントが MCP や API を介して読み取るメモリレイヤーであり、単一のエージェントランタイムに依存しないナレッジを保持します。セットアップは3つのステップで完了します。
ステップ 1: APIキーの作成
MemoryLake にサインインし、APIキーを作成します。接続するすべてのツールで共通の認証情報として使用できます。
ステップ 2: 最初のメモリをアップロードする
短いエントリで、1つのエントリにつき1つの主張を記述します。エージェントの作業用ストアではなく、ポータブルなレイヤーに置くべきものは以下の通りです。
決定事項と、その背景にある制約。 規約を正しいものにしている論理的根拠であり、エージェントフレームワークが変更されても存続します。
すでに却下されたアプローチ。 再発見するのにコストがかかり、それを学んだ特定のエージェントだけでなく、すべてのエージェントやエンジニアにとって有用な情報です。
ドメイン知識。 業界の用語やルール。ワークスペースやランタイムに依存しません。
これまでに複数回行った修正。 エージェントが間違えたか、人間が間違えたかにかかわらず、エントリの内容は同じです。
ステップ 3: AIとエージェントを接続する
使用しているツールを接続します。MemoryLake は MCP および API 経由でアクセスできるため、Claude Code、Codex、OpenClaw などの MCP ネイティブなエージェントは MCP サーバーを指定して接続し、他のアシスタントは API を介して同じメモリを読み取ります。
3つの率直な制限事項があります。MemoryLakeはAnthropicのmemory storesとは連携しません。 この機能との統合ではなく、memory storeの読み書きはできません。Managed Agents上で構築している場合は、ドキュメントに従ってエージェントの作業用メモリとしてプラットフォームのストアを使用してください。MemoryLakeは、あなたやエージェントが書き込んだ内容のみを保持します。また、コンプライアンスやデータ保持（リテンション）のためのシステムではありません。
実務においてこれが何を変えるか
Managed Agents上のエージェントがコールドスタートしなくなる。 セッションが終了するとその状態も一緒に消えてしまうという、ドキュメントに記載されていた問題に対して、ファーストパーティによる優れた解決策が提供されました。
エージェントによる誤った書き込みが復旧可能になる。 ポイントインタイムリカバリを備えた不変のバージョン管理は、自律型システムにとって重要な安全特性であり、より広く採用されるべき仕組みです。
メモリがファイルシステムの問題になる。 エージェントが通常のファイルツールで読み取るマウントされたディレクトリとしてメモリを公開することで、ツール使用に関する失敗のカテゴリ全体が排除されます。アーキテクチャの観点から、これが今回のリリースで最も興味深いアイデアです。
セルフホスト環境でのデプロイにはメンタルモデルが必要。 「ツールの実行前にダウンロード、書き込み後に同期」であり、ライブマウントではありません。
スコープの決定が明確になる。 ワークスペーススコープやClaude最適化といった明確な境界線があることは、曖昧であるよりも好ましいです。これらを知ることで、他の場所に何を保持すべきかが分かります。その一般的な概要については、what persistent memory means（永続メモリが意味するもの）を参照してください。
agent memory storesのベストプラクティス
エージェント作成時にagent toolsetを有効にする。 エージェントがストアと対話するために必要です。見落としやすく、デバッグ時に混乱を招きます。
エージェントが読むことを前提としてストアの説明（description）を書く（実際に読むため）。 何が含まれており、それがいつ関連するのかを記述します。
パスを意図的に使用する。 メモリはパスで指定されます。初日から安定したレイアウトを設計する価値があります。
SDKにベータヘッダーを設定させる。 手動で設定する必要がある場合は、組み合わせるのではなく置き換えてください。memory storeのリクエストに両方を指定すると 400 が返されます。
APIまたはConsoleを通じて初期データの投入や修正を行う。 インポートやエクスポートを含め、直接の読み取りと編集がサポートされています。ストアは空の状態で始める必要はなく、誤った状態のままにしておく必要もありません。
監視なしで実行した後は、バージョン履歴を確認する。 監査トレイルは活用するために存在します。
ヘッダー変更後はページネーションを再開する。 新しいヘッダーなしで行われたリクエストからのカーソルは、新しいヘッダーありのリクエストでは無効になります。
ランタイムに依存しないナレッジはランタイムの外に置く。 エディタ、アシスタント、そして次のエージェントフレームワークのすべてに共通して当てはまる内容は、それらのいずれにも属さないレイヤーに置くべきです。その背景にある考え方については、MCP and stateless agent memory（MCPとステートレスなエージェントメモリ）を参照してください。
結論
memory storeは非常によく構築されたプリミティブです。エージェントが通常のファイルツールで読み取るディレクトリとしてメモリをマウントすることで、ツール使用に関する多くの複雑さを回避できます。マウントに関するメモをシステムプロンプトに追加するという細かな配慮が実用性を高めており、ポイントインタイムリカバリを備えた不変のバージョン管理は、自律的な書き込みに伴うリスクを監査可能なプロセスへと変える機能です。ClaudeのManaged Agents上で構築している場合は、ぜひこれを活用し、agent toolsetを有効にし、適切な説明を書き、セルフホストされたサンドボックスではライブマウントではなく同期コピーが使用されることを覚えておいてください。
また、その境界も明確に示されています。ワークスペーススコープ、Claude向けに最適化、ベータ版。これらは欠点ではなくスコープであり、他の場所に何を保持すべきかを教えてくれます。エージェントの作業用メモリは、エージェントのプラットフォームに属します。来期にどのランタイムを使用しているかにかかわらず不変である決定事項、制約、却下されたアプローチは、それらのいずれにも縛られないレイヤーに属するべきです。