AIが「忘れる」のは設計上そうなっているから

Claudeに限らず、AIエージェントはセッションが終わると、そのセッション中に得た知識をすべて失います。「先週この判断基準を教えたのに」「前回このやり方はダメだと言ったのに」という体験の正体はこれです。会話履歴は残っていても、別の新しいセッションを始めれば白紙からのスタートになります。

この記事で扱うMemory Storesは、Anthropicの Managed Agents（インフラを持たずにAIエージェントを本番運用する仕組み）に用意された、この問題への公式な回答です。エージェントに「書き込める永続ディレクトリ」を渡し、次のセッションでも同じディレクトリをマウントすることで、記憶を引き継がせます。

まず判断：CLAUDE.md・スキル・Memory Storesの使い分け

「AIに何かを覚えさせたい」ときの選択肢は3つあります。ここを間違えると、動くけれど運用が破綻します。

決め手は「AIに書き込ませたいかどうか」です。CLAUDE.mdとスキルは人間が管理するファイルで、AIは読むだけです。Memory StoresはAIが自分で書き込める点が決定的に違います。

逆に言うと、「絶対に守らせたいルール」をMemory Storesに入れるのは向いていません。読むかどうかはAIの判断に委ねられるためです。そういうものはCLAUDE.mdやシステムプロンプトに置いてください。スキルとサブエージェントの使い分けについては別記事で判断基準を整理しています。

実際の使い分け例

• CLAUDE.md：「このリポジトリはGoで書く」「テストは必ずtable-driven形式で」
• スキル：「請求書の作成依頼が来たら、この6ステップで処理する」
• Memory Stores：「A社の担当者は数値の根拠を必ず求めるので、集計元を併記する」「前回このAPIでタイムアウトしたので、リトライ間隔を長めに取る」

Memory Storesの構造：3階層を押さえる

実装に入る前に、データ構造を理解しておくと以降が読みやすくなります。

重要な制限が2つあります。1ストアあたり最大2,000メモリ、1メモリあたり最大100KBです。公式も「少数の巨大ファイルではなく、多数の小さなファイルに分けて構成すること」を推奨しています。この上限に達すると新規書き込みが失敗するため、設計段階で意識しておく必要があります（対処は後述）。

実装：ストアを作ってセッションに接続する

ステップ1：ストアを作る

description はエージェントに渡されます。人間向けの説明ではなく、AIが「このフォルダには何が入っているか」を判断するための文章として書いてください。

from anthropic import Anthropic

client = Anthropic()   # ANTHROPIC_API_KEY を環境変数から読む

store = client.beta.memory_stores.create(
    name="Client Context",
    description="顧客ごとの前提・好み・過去のやり取りで判明した注意点。作業開始前に確認すること。",
)
print(store.id)   # memstore_01Hx...

ステップ2：初期データを流し込む（任意）

エージェントを一度も動かす前に、参考資料を入れておけます。memories.create はパス指定で作成し、既存のパスがあると409エラーになります（上書きはしません）。更新は memories.update を使います。

client.beta.memory_stores.memories.create(
    store.id,
    path="/standards/report_format.md",
    content="レポートは結論を先頭に置く。数値には必ず集計元と期間を併記する。",
)

ステップ3：セッションに接続する

ここが最重要ポイントです。メモリストアはセッション作成時にしか接続できません。実行中のセッションに後から追加・削除することはできない仕様です。ファイルやGitHubリポジトリのリソースとは扱いが異なります。

session = client.beta.sessions.create(
    agent=agent.id,
    environment_id=environment.id,
    resources=[
        {
            "type": "memory_store",
            "memory_store_id": store.id,
            "access": "read_write",          # または "read_only"
            "instructions": "顧客の前提情報。作業を始める前に必ず確認すること。",
        }
    ],
)

instructions はこのセッション限定の使い方指示です（最大4,096文字）。ストアの name / description と一緒にエージェントへ提示されます。1セッションあたり最大8ストアまで接続できます。

ステップ4：エージェントから見るとどうなるか

接続されたストアは、サンドボックス内の /mnt/memory/ 配下にディレクトリとしてマウントされます。エージェントは専用ツールではなく、いつものファイル操作ツール（read・write・edit・glob・grep・bash）でそのまま読み書きします。

ディレクトリ名はストアの表示名をファイル名として安全な形に変換したものです（小文字化し、英数字以外の連続をハイフン1つに置換）。たとえば「Demo Memory」というストアは /mnt/memory/demo-memory/ になります。

なお、エージェントがマウントを読み書きする動作は、イベントストリーム上では通常の agent.tool_use / agent.tool_result イベントとして流れてきます。特別なイベント型はありません。

また、Memory Storesを使うにはエージェント作成時にエージェントツールセット（agent_toolset_20260401）を有効化しておく必要があります。ファイル操作ツールがないと、マウントされていても読み書きできません。

セキュリティ：read_writeで接続してよいか毎回考える

ここは軽視されがちですが、Anthropic自身が公式ドキュメントで警告している項目です。

対策はシンプルで、書き込む必要がないストアは read_only で接続することです。具体的には次のような使い分けになります。

複数ストアを接続できる仕様は、まさにこの分離のためにあります。「共有の参照資料は read_only、自分の作業メモだけ read_write」という2ストア構成が、実用上の基本形です。

access はファイルシステムレベルで強制されます。read_only のマウントへの書き込みは、AIが試みてもOSレベルで拒否されます。プロンプトでのお願いではありません。

監査とロールバック：AIが何を覚えたかを追う

AIに書き込ませる以上、「何をいつ書いたか」を追えないと運用に乗りません。メモリバージョンがその役割を果たします。

変更履歴を見る

メモリへの変更（作成・更新・削除）ごとに memver_... が1つ作られます。operation フィールドで created / modified / deleted が区別できます。

versions = client.beta.memory_stores.memory_versions.list(
    store.id,
    memory_id=mem.id,
)
for v in versions:
    print(f"{v.id}: {v.operation}")

各バージョンには created_by という実行主体の情報が付きます。セッションが書いたのか（session_actor）、APIから人間・スクリプトが書いたのか（api_actor）が区別できます。「AIが勝手に変な内容を覚えた」を検証するときの入り口はここです。

ロールバックのやり方

専用のリストアAPIはありません。手順は「戻したいバージョンを取得して、その content を書き戻す」です。

version = client.beta.memory_stores.memory_versions.retrieve(
    version_id, memory_store_id=store.id
)

client.beta.memory_stores.memories.update(
    mem.id,
    memory_store_id=store.id,
    content=version.content,      # 過去の内容を書き戻す
)

バージョンはメモリ本体より長生きします。メモリを削除したあとも履歴は残るため、削除済みメモリの復元は memories.update ではなく memories.create で行います。

同時書き込みの衝突を防ぐ

人間の修正とエージェントの書き込みがぶつかると、片方が消えます。precondition を渡すと、読んだ時点から内容が変わっていた場合に更新を弾けます。

client.beta.memory_stores.memories.update(
    memory_id=mem.id,
    memory_store_id=store.id,
    content="修正: インデントは半角スペース2つ。",
    precondition={
        "type": "content_sha256",
        "content_sha256": mem.content_sha256,   # 読んだときのハッシュ
    },
)

ハッシュが一致しなければ409エラーになるので、再取得してやり直します。人間が管理画面から編集するツールを作る場合は、これを入れておかないと事故ります。

機密情報が書き込まれてしまったとき

APIキーや個人情報がメモリに書き込まれた場合、redact で履歴から内容だけを消し、監査証跡（誰がいつ操作したか）は残すことができます。

client.beta.memory_stores.memory_versions.redact(
    version_id, memory_store_id=store.id
)

注意点として、現在の最新版（live memoryのhead）は直接redactできません。先に新しいバージョンを書き込むかメモリを削除して、それから古いバージョンをredactします。

運用：2,000件の上限にどう備えるか

ストアが2,000メモリに達すると、新規メモリの書き込みがすべて失敗します。API経由の memories.create も、エージェントによるファイル書き込みもです。既存メモリの読み書きは続けられますが、成長は止まります。

公式が挙げている対処は4つです。

1. ストアを目的別に分ける。1つの汎用ストアに全部入れず、「ユーザーごと」「共有ドメイン知識」「プロジェクト固有」で分割します。上限はストアごとなので、分けるだけで余裕が生まれます
2. 埋まる前に整理する。古い・重複したメモリを memories.delete で削除します
3. 新しいストアに切り替える。既存ストアが役目を終えたら、新規ストアを read_write、旧ストアを read_only で両方接続します。読むのは両方、書くのは新しい方だけ、という構成です
4. 書き込み権限を絞る。参照するだけのセッションに read_write を与えないことで、どこから増えているかを追いやすくなります

設計時点で「1ユーザー1ストア」「1プロジェクト1ストア」のようにスコープを切っておくのが、いちばん素直な予防策です。

Vertex AI・Bedrock経由のClaudeでは使えない

「うちはGoogle CloudのVertex AI（Agent Platform）でClaudeを使っている」「AWSのBedrock経由で契約している」というケースは多いはずです。結論から書くと、Managed Agentsはこれらのプラットフォームでは利用できません。Anthropicの公式ドキュメントに、サポート対象外として明記されています。

なぜ使えないのか

Managed Agentsが「モデルを呼び出すAPI」ではなく、エージェントの実行ループとサンドボックス環境そのものをAnthropicがホストするサービスだからです。Vertex AIやBedrockが提供しているのは推論（Messages API）であって、Anthropic側のコンテナやスケジューラではありません。

同じ理由で、これらのプラットフォームではFiles API・コード実行・Agent Skills・MCPコネクタ・Message Batchesなども対象外です。Vertex AI・Amazon Bedrock・Microsoft Foundryそれぞれの公式ドキュメントに、いずれも「サポートされない機能」の一覧としてClaude Managed Agentsが挙げられています。

Vertex AI・Bedrockのままで近いことを実現するには

記憶の永続化に限れば、memoryツール（memory_20250818）が代替になります。こちらはVertex AI・Amazon Bedrock・Microsoft Foundryのいずれでも利用可能です。

ただし性質はかなり違います。memoryツールはクライアント実装型で、Claudeは「このファイルを読んで」「ここに書いて」というツール呼び出しを返すだけです。実際の保存先（ファイルシステム、データベース、S3など）は自分で実装します。

要するに「Anthropicに預けるか、自分で作って自社環境に置くか」の違いです。記憶データを自社の管理下に置きたい要件があるなら、むしろmemoryツールのほうが適している場面もあります。実装の手間と引き換えに、保存先とアクセス制御を完全に自分で握れます。

よくある質問

まとめ

今日やれる最初の一歩は、「いま毎回説明し直していることを3つ書き出す」ことです。そのうち「人間が決めた不変のルール」はCLAUDE.mdへ、「AIが作業しながら気づくこと」はMemory Storesへ振り分けてください。この仕分けができていれば、実装自体は数十行で済みます。