Claudeのメモリ漏洩「Memory Heist」製品導入前に確認すべきこと

Claudeのメモリから氏名や勤務先が抜き取られた「Memory Heist」が2026年7月に話題になりました。

読んですぐ気になるのは「これって自社プロダクトにも関係あるのか？」ですよね。

先に結論を言うと、悪用されたのはclaude.aiコンシューマー版の自動メモリで、プロダクトに組み込むManaged Agentsのメモリとは仕組みが違います。

ただ、それで「関係ない」と読み流すのはもったいなくて、背景にある構造的なリスクは共通します。

Memory Heist事件を入口に、自社プロダクトへMemory機能を組み込む前の判断材料を整理しておきます。

何が起きたか？ Claudeのメモリ漏洩「Memory Heist」の仕組み

Ayush Paulさんというセキュリティ研究者が2026-07-09に「The Memory Heist」というPoCを公開しました。

悪用されたのは、claude.aiのチャットに搭載されている3つの機能の組み合わせです。

• 日次のメモリ要約（会話を自動要約し、以降の全会話に注入する）
• conversation_search（過去の会話を横断検索する）
• web_fetch（外部URLを取得する）

攻撃の流れが巧妙で、攻撃者が用意したサイトに「Cloudflare認証を装った偽の文字選択UI」を置いておく。

Claudeがそのサイトをweb_fetchで開くと、UIに従って「文字を1つ選ぶ」動きを取り、選ぶたびに攻撃者のアクセスログに1文字ずつ記録される。

これを積み重ねて、氏名・勤務先・出身地まで外部に流出したという内容です。

注目されたのは、ユーザーが会話で触れた「Queen City Hacks」というハッカソン名から、Claudeが独自に出身地（Charlotte, NC）を"推論"して送信していた点でした。

保存された事実だけでなく、推論から復元された情報まで流出したところが、メモリの本当の怖さです。

Anthropicは既に対応済みで、web_fetchが外部ページ内リンクを辿る機能を無効化し、ユーザー指定URLとweb検索結果のみアクセス可能に制限しています。

The Memory Heist

How I tricked Claude into leaking your deepest, darkest secrets

www.ayush.digital

Claudeのメモリから氏名や勤務先を盗み出す攻撃手法が発見される、ウェブ閲覧機能を悪用して外部サイトへ送信

AIアシスタント「Claude」のウェブ閲覧機能を悪用し、メモリに保存された氏名や勤務先などの個人情報を、ユーザーに気付かれないまま外部サイトへ送信させる攻撃手法をセキュリティ研究者のAyush Paul氏が報告しました。Paul氏によると、問題はAnthropicに報告され、記事作成時点で外部ページ内のリンクをClaudeがたどれないようにする対策がすでに施されています。

gigazine.net

セキュリティ研究者のSimon Willisonさんが提唱している「lethal trifecta」——(1)私的データへのアクセス、(2)信頼できないコンテンツの処理、(3)外部通信手段の3条件が揃うと構造的に脆弱、というフレームワーク——の教科書的な事例として引かれています。

これは自社プロダクトの話なのか——claude.aiとManaged Agentsメモリの違い

自分がこの事件を読んで真っ先に確認したのが、「自社が使うAPI／Managed Agentsにも同じ問題があるのか」でした。

結論から言うと、Memory Heistが突いたのはclaude.aiコンシューマー版の自動メモリで、プロダクトに組み込むManaged Agentsのメモリとは別のアーキテクチャです。

Managed Agentsのメモリはこう設計されています。

• メモリストアは自動生成されない。開発者が明示的に作成し、セッションのresources[]にアタッチしない限り使われない
• アタッチ時にaccessをread_write（デフォルト）またはread_onlyで選べる
• 全メモリ変更は不変の「メモリバージョン」として記録され、監査証跡・特定時点への復元・redact（コンプライアンス目的での履歴消去）に対応

claude.aiのように「会話が勝手に要約されて次のセッションに注入される」自動蓄積は起きません。

じゃあ関係ないのかというと、そうでもなくて、背景の構造的リスクは共通します。

lethal trifectaに戻ると、Managed Agentsで組み立てるセッションも「私的データにアクセスし、Webやメールなど外部の信頼できないコンテンツを処理し、外部通信できる」構成になった瞬間、Memory Heistと同じ穴が開く可能性が出てきます。

しかも、Anthropicの公式ドキュメントには既にこの警告が明記されていました。

エージェントメモリの使用

メモリストアを使用して、セッションをまたいで保持される永続的なメモリをエージェントに付与します。

platform.claude.com

原文を引用します。

メモリストアはデフォルトでread_writeアクセスでアタッチされます。エージェントが信頼できない入力（ユーザー提供のプロンプト、取得したWebコンテンツ、サードパーティのツール出力など）を処理する場合、プロンプトインジェクションが成功すると、悪意のあるコンテンツがストアに書き込まれる可能性があります。その後のセッションは、そのコンテンツを信頼されたメモリとして読み取ります。参照資料、共有ルックアップ、およびエージェントが変更する必要のないストアにはread_onlyを使用してください

事件の前から、公式が正面から警告している事象という位置づけです。

Memory機能を組み込む前に確認すべき3つの論点

まず1つ目、そのセッションが「信頼できない外部コンテンツ」を扱うかどうかです。

lethal trifectaの1辺で、Webページの取得、外部からのメール本文、SlackやTeamsに投稿されるユーザー入力、第三者ツールの出力——このどれかが混ざるセッションは、プロンプトインジェクションの経路になり得ます。

該当するかどうかを機能ごとに一次で洗い出す。

該当しないセッションはリスクの大半が消えるので、対策の優先度も自然に下げられます。

次に2つ目、書き込み権限は本当に必要か——read_onlyという選択肢です。

Managed Agentsのメモリストアはデフォルトがread_writeで、意識しないとread_onlyには切り替わりません。

公式ドキュメントの警告文もここに集中しています。

「エージェントが変更する必要のないストア」——参照資料、社内FAQ、製品ドキュメント、共有マスタ——はread_onlyで運用する。

設計時点で切り分けておくだけで、プロンプトインジェクションで悪意のあるメモリを書き込まれるリスクの大半を消せます。

最後に3つ目、メモリの変更履歴を後から追跡できる状態になっているか。

Managed Agentsはmemory_versionで自動的に不変の変更履歴を残します。

コンプライアンス側から「エージェントが何を覚えていたか、いつ書き換わったか、消したという証拠は残せるか」を問われたとき、この履歴とredact機能で応じられるかを設計時に確認しておく。

事件後にログを整備し始めると、遡及的に「不正な書き込みがあったかどうか」を追えないという事態になります。

3つ並べて気付くのは、Memory機能そのものの是非を議論しているのではなく、「Memory機能を安全に使い倒すための設計チェック」の話だ、ということです。

外すべき機能ではなく、設計軸を持って組み込む機能、という位置づけで扱う方が実務的にワークします。

今日のミーティングに持ち込めるMemory機能チェックリスト

チームで一度棚卸しするなら、3つの項目に絞れます。

• Memory機能を持つセッションが扱うコンテンツの信頼度を洗い出したか
• read_writeとread_onlyの使い分けを設計時点で決めているか
• メモリの変更監査と削除の手段を持っているか

Memory Heistの怖さは事件そのものより「気付かないうちに構造的なリスクを抱え込んでいる」ことにあります。

claude.aiコンシューマー版とManaged Agentsは仕組みが違いますが、lethal trifectaの構造は共通する——だから「自社は関係ない」で読み流さずに、上の3項目を一度チームで棚卸ししておくのが、この事件から持ち帰るいちばん実務的な収穫だと思います。

Memory機能はこれから確実に「プロダクトに載せて当然」の層になっていきます。

事件を入口に、設計軸を先に立てておく。

そこまでやっておくと、次にどんな類の事件が起きても、慌てて後追いで対策する側から一歩抜けられます。