AIがあなたを覚えるときその記憶は誰が読めるのか

AIに「前に相談した件の続き」と頼むには、会話が終わった後も情報を残しておく必要がある。その記憶に仕事の事情や家族の情報が含まれていたら、AIを動かす会社はどこまで読めるのだろう。

Google DeepMindは2026年9月23日、Private AI Computeに安全なサーバー側の長期記憶を加える設計を発表した。目指すのは、記憶をクラウドに置きながら、Googleの運用担当者からも中身を守ることだ。この設計で記憶を守るのは、暗号化した保管場所、利用者の端末を起点にする鍵、処理中のデータを守る隔離実行環境の三つである。発表文

ただし、処理に使う鍵は端末の外へ渡る。公開監査では、端末から鍵を受け取った隔離領域で記憶を復号して使う仕組みが説明されている。また、「他人に読ませないこと」と「削除した記憶が戻らないこと」は別の保証だ。第三者監査でも、削除した記憶が戻り得る問題は未解決とされている。

この記事の要点

• 9月23日に発表されたのは、長期記憶を保護する設計だ。一般利用者向けの提供開始日や、対応する全製品の一覧は示されていない。
• 保存中は暗号化し、必要なときだけ検証された隔離領域で復号する設計。AIが暗号文のまま内容を理解する仕組みではない。
• Trail of Bitsの公開監査では10件中8件が解決済み。削除後の記憶の復活と、回答由来のハッシュ値の外部送信に関する2件は、報告書時点で未解決とされる。

資料確認日：2026年9月30日。Googleの設計説明、監査会社の確認結果、LATENTによる資料の読み解きを区別する。本番システムを独自に侵入試験した記事ではない。

目次

1. 新たに加わるのは会話をまたぐ記憶の保管場所
2. 鍵は端末から検証済みの隔離領域へ渡される
3. 記憶の内容を守れても利用者との紐付けは残る
4. 第三者監査では削除と外部送信に課題が残った
5. 公開台帳と端末による独立検証は同じではない
6. 利用前に確かめたいのは対象機能と記憶の消し方

新たに加わるのは会話をまたぐ記憶の保管場所

Private AI Computeは、個人のデータを保護した領域でクラウドのAIに処理させる基盤だ。Googleは2025年11月の基盤発表で、PixelのMagic Cueによる提案やRecorderの文字起こし要約を利用例として挙げていた。今回の長期記憶は、その基盤に持続的な保存層を足す更新であり、基盤の初登場ではない。2025年の公式発表

一回の依頼を処理して作業用データを消す仕組みと、次の依頼のために情報を残す仕組みでは、守るべきものが変わる。たとえば出張の相談で毎回好みを伝え直す手間は減るが、残した好みや予定は、後日も保護し続けなければならない。

ここでいう「記憶」は、AIモデルの重みそのものを書き換えることではない。今回の技術資料では、利用者ごとの情報をデータベースに保存する仕組みを説明している。必要な記録を取り出し、次の依頼と一緒にモデルへ渡して回答に使う。技術資料10〜12ページ

設計が発表されたからといって、「Geminiの過去の会話や保存済み情報がすべて新方式になった」とは判断できない。9月23日の発表と今回確認した技術資料からは、一般向けの開始時期、対象アプリ、地域、端末条件までは確定できなかった。

鍵は端末から検証済みの隔離領域へ渡される

クラウドに暗号化して保存する場合は、復号する鍵を誰が使えるかも確かめたい。保存を担う会社が自由に復号できるなら、その会社から記憶の内容を守ることはできない。

今回の構造には二種類の鍵がある。監査報告書によると、端末は利用者の秘密情報から、別の鍵を保護するための鍵を作る。この鍵をKEK（鍵を暗号化する鍵）と呼ぶ。記憶の内容を直接暗号化するのは、利用者ごとのDEK（データを暗号化する鍵）だ。サーバーの通常の保存領域には、暗号化した記憶と、KEKで暗号化したDEKを置く。監査報告書のPDF 13〜17ページ

要素	役割	防ぎたいこと
保存先	暗号化した記憶とDEKを保持	保存データを盗むだけで中身を読まれる
鍵	端末側のKEKでDEKを開く	保存サービスだけの判断で復号される
隔離領域	鍵と記憶を一時的に使う	通常の管理機能から処理中の内容を読まれる

隔離実行環境はTEEとも呼ばれ、ハードウェアの仕組みを使って、処理中のデータを周囲のソフトウェアから隔てる。普通のアプリでアクセス権を設定するだけよりも、信頼する範囲を狭める狙いがある。Private AI Computeは複数の保護された計算領域を使い、その間も相手を認証して暗号化通信を行う。技術資料4〜5ページ

監査対象のメモリ処理を、細かな中継機構を省いて並べると次のようになる。

1. 端末が接続先の証明を確認し、隔離領域との暗号化された通信路を作る。
2. 端末がその通信路の中でKEKを渡す。隔離領域はKEKでDEKを開き、記憶を作業用メモリに復号する。
3. AIが必要な記憶を依頼の文脈として使う。更新する記憶は再び暗号化して保存する。
4. セッションの終了時には、一時的な検索用データなどを破棄する。

「鍵は端末側にある」といっても、鍵が絶対に端末から出ないという意味ではない。Googleの一般向け発表だけでは見落としやすいが、監査資料は検証済みセッション内へのKEK送信を明記している。記憶を守るには、鍵の渡し先と、そこで実行できる処理を制限する必要がある。監査報告書のPDF 14〜17ページ

記憶の内容を守れても利用者との紐付けは残る

長期記憶には、従来の一回限りの処理と異なる条件もある。正しい記憶を呼び出すには、その依頼を「同じ利用者の保存場所」へ結び付けなければならない。

Googleの技術資料は、このため持続的な記憶を使うシステムでは、ネットワーク上で特定利用者を狙えないという保証を主張しないと明記している。Trail of Bitsの監査にも、処理中の利用者の識別情報は隔離領域外のシステムに分かるという説明がある。技術資料12ページ・監査報告書のPDF 6ページ

利用者を識別できても、記憶の中身まで読めるという意味ではない。しかし、記憶の内容が秘密であることと、誰の保存場所が使われたかまで隠れることは別だ。利用者が「プライベートな記憶」にどこまでを期待するかで、確認すべき項目が変わる。

第三者監査では削除と外部送信に課題が残った

設計図だけでなく、実装に対する外部の評価も公開されている。Googleの依頼を受けたTrail of Bitsは、2026年6〜7月に主に長期記憶の設計とコードを調べ、8月5〜7日に修正を確認した。9月21日付の最終報告書では、10件の指摘のうち8件が解決済みとされる。監査報告書のPDF 4〜8ページと49〜51ページ

監査会社は、調査したコードにGoogle従業員が利用者データを閲覧する仕組みを見つけなかったと報告している。一方で、全システムやTPU基盤のコードを今回すべて精査したわけではなく、非公開の重要なコードも残る。この監査結果が示すのは、調査した範囲と時点での評価だ。

残った二つの指摘は、一般利用者にとっても意味がある。

指摘	評価	利用者への影響
記憶の復活	低	強い内部権限で古い状態を戻すと、後の利用時に削除済み情報が再び使われ得る
ハッシュ値の送信	高	回答の断片から作る値が保護領域外へ渡り、強い内部権限を持つ攻撃者の推測材料になり得る

記憶の復活に関する指摘番号はTOB-PAICSM-1。内部ストレージへの継続的な特権アクセスがあると、暗号を破らなくても「いつの記憶を読み込ませるか」を変えられるという問題だ。復号した作業用メモリを消すことと、古い暗号化データが将来も復活しないことは同じではない。Googleは残る巻き戻しのリスクを受容し、端末を使った状態確認を検討していると報告書に記載されている。

ハッシュ値の送信に関するTOB-PAICSM-9は、著作物の長い再現を防ぐ照合処理に関わる。Googleは、平文の回答そのものは外へ送らず、悪用には強い権限が必要だと説明する。隔離領域内で先に候補を絞るBloom filterを導入する方針も示したが、公開報告書では未解決のままだ。監査側も、指摘が外部の第三者による侵害を可能にするものとは述べていない。一般公開の漏えいや実被害が起きたとの報告ではない。監査報告書のPDF 7〜9ページと49〜51ページ

この監査結果だけでは、9月30日現在の本番環境の状態までは分からない。LATENTは、その後の対策の導入完了や実際の稼働状態を独自確認していない。

公開台帳と端末による独立検証は同じではない

もう一つの論点は、「説明されたソフトウェアが本当に動いているか」だ。監査したプログラムが安全でも、接続先が別のプログラムにすり替わっていたら、その監査を根拠にはできない。

Googleは、実行されるソフトウェアを識別する値を公開台帳へ記録し、接続時の証明と結び付ける仕組みを説明している。台帳を調べ、記録に含まれることを暗号学的に確認する検証手順書も公開されている。長期記憶の実装はProject Oak内で公開されており、ソースも調べられる。

ただし、台帳に記録があることは、それだけで実装に欠陥がない証明にはならない。公開ソースと本番で動くプログラムが一致するか、改変の有無を誰が確かめるかまで追って、初めて検証の範囲が分かる。

Googleの技術資料は、現行のシステムによる証明・公開台帳の説明とは別に、利用者の端末による独立した検証の拡充、第三者が継続的に監視し共同署名する透明性ログ、再現可能なビルドの対象拡大を将来の計画に置いている。監査対象には端末側の証明検証コードも含まれるが、それを一般利用者向けの検証経路がすべて提供済みという意味には取れない。技術資料13〜14ページ

LATENTが今回確認したのは、これらの資料と公開コードの所在、監査の対象・修正状況である。台帳の署名検証、ソースからの再ビルド、本番の実行プログラムとの照合は実施していない。

利用前に確かめたいのは対象機能と記憶の消し方

この発表を評価するには、暗号化した保存先、鍵を渡す条件、復号する場所、削除後の扱いをそれぞれ確かめたい。「Googleを信じるか」という問いだけでは、個々の保護の仕組みまでは判断できない。

実際の製品で長期記憶を使い始めるなら、まずその機能が今回の保護対象なのかを確認したい。そのうえで、保存された記憶を見返せるか、記憶を止めたり削除したりできるかを確かめる。端末を失ったときや買い替えたときに、鍵と記憶をどう引き継ぐかも確認したい。今回の発表と技術資料だけでは、こうした利用者向けの操作や復旧手順は確定できない。

また、記憶を秘密に保管できても、その内容が正しいとは限らない。AIが勘違いした好みや古い予定を安全に保存し続ける可能性もある。閲覧する権限を守る技術と、記憶を確かめて訂正できる製品の仕組みは、合わせて評価する必要がある。

今回の発表では、端末を起点にした鍵管理や公開実装、外部監査を通じて、AIの長期記憶を評価する材料が増えた。個人の情報を長く覚えるAIを選ぶときは、誰が記憶を読めるのか、消した記憶は戻らないのか、利用者自身がどこまで確かめられるのかを合わせて見ておきたい。

出典と確認範囲

一次資料は2026年9月30日に確認した。以下の監査PDFのページ番号は、表紙を1ページ目とするPDF上の順番。報告書内の印刷ページ番号とはずれる箇所がある。

1. Google DeepMindによる2026年9月23日の発表 — 発表日、設計の狙い、公式構成図。
2. Google Private AI Compute Technical Brief 2026年9月版 — 10〜12ページに長期記憶と鍵・識別情報、13〜14ページに現行の検証手段と将来計画。Google自身による設計説明。
3. Trail of Bitsによる2026年9月21日付の監査報告書 — Googleが依頼した独立監査。5〜9ページに総括とGoogleの見解、12ページに調査の限界、13〜17ページに鍵とデータの流れ、49〜51ページに修正確認の結果。
4. NCC Groupによる2025年の監査概要 — 既存基盤に対する先行調査。2026年の長期記憶に対する監査とは対象が異なる。
5. Project Oakの長期記憶ソース — 公開実装の所在を確認。LATENTによる網羅的なコード監査・ビルド検証は未実施。
6. 公開台帳の検証手順書 — 台帳の記録と証明の確認方法を照合。コマンドを用いた検証は未実施。
7. Googleによる2025年11月11日の基盤発表 — 既存の利用例と今回の更新を区別するために参照。

未確認の事項： 長期記憶の一般提供日と対象製品・地域・端末、利用者向けの保存・削除・鍵復旧の仕様、監査後の未解決事項への対策完了、すべての利用者の端末から本番環境まで通した独立検証。記事中の「設計」「Googleの説明」「報告書時点」という限定は、これらを提供済み・実証済みと混同しないために付している。