「処理が終われば消える」を前提にAIへ渡した情報が、次の会話でも使われる。その変更は、暗号化を強くするだけでは扱えません。

Googleは2026年9月23日、Private AI Computeにサーバー側の永続メモリを加える設計を発表しました。処理後に文脈を消していた仕組みを、端末をまたいで文脈を保持できるようにする構想です。公式発表

ここで設計者が分けるべきなのは、内容を読める相手と、内容を残す期間です。暗号化は前者を制御します。後者には、保存・再利用・削除の仕様が要ります。

AI生成の概念イラスト。封筒を、保存しながら内容を守る記憶に見立てています。実際のシステム構成図ではありません。

2026年9月25日時点の設計発表を扱います。今回の発表だけを根拠に、一般ユーザーが利用できる機能や、その削除・復旧仕様まで確定したとは扱いません。

保存先を暗号化するだけでは、計算中を守れない

暗号化されたファイルを普通のサーバーアプリが読み、復号して処理する。これだけなら、保存中は保護できても、処理中の内容をその実行環境から隠せるとは限りません。

保護する場面は三つあります。ディスクに置かれたデータ、通信中のデータ、そして計算に使っているデータです。Confidential Computingは、ハードウェアによる隔離実行環境で、最後の「使用中」を保護する考え方です。Google Cloudの技術解説

今回のGoogleの説明では、記憶を利用者ごとに暗号化して保存し、鍵は個人の端末が保持します。端末から認証された暗号化経路でクラウドの隔離領域につなぎ、そこで一時的に復号して処理し、更新した文脈を再び暗号化します。公式発表の処理フロー

つまり、クラウドのどこにも平文が現れない方式ではありません。見るべき境界は、復号した内容に触れられる実行環境をどこまで限定するかです。

たとえば自分たちで同種の仕組みを設計するなら、暗号化DBの採用だけでレビューを終えず、復号後の文字列がログや例外通知へ流れる経路も調べる必要があります。保存先が安全でも、処理の途中で別の場所にコピーすれば、そのコピーには別の保護が必要だからです。これは一般的な設計上の確認点であり、Googleでその漏えいが起きたという話ではありません。

「メモリをオフ」に三つの意味を持たせない

ここからは、発表を踏まえた筆者の設計上の整理です。

仮に、出張を手伝うAIが「来月は大阪へ行く」という予定を保存するとします。旅行が終わり、利用者がメモリをオフにした。この操作の結果が次のどれなのかで、システムの挙動は変わります。

操作の意味	新しい記憶を書き込む	既存の記憶を次の応答に使う	既存の記憶を保存する
新規保存だけ停止	しない	使い得る	続ける
利用を停止	しない	使わない	続ける
削除を要求	しない	使わない	削除処理の対象になる

これはGoogle製品の仕様表ではなく、操作の意味を分けるための例です。

一行目なら、オフにした後も古い予定が提案に混ざり得ます。二行目なら、再びオンにしたときに記憶を復活させる設計もできます。三行目なら、削除が完了するまでの状態と、完了後に戻せるかどうかを決めなければなりません。

どの方式にも用途はあります。ただし、UIで同じ「オフ」とだけ表示すると、利用者は結果を判断できません。

仕様書には「無効化する」ではなく、「新規書き込みを止める」「読み出しを止める」「保存済みデータを削除する」と書く。まず、それだけでレビュー対象が具体的になります。

鍵を持ち続けるなら、暗号文は再び記憶に戻る

暗号化された記憶が残り、有効な鍵を使えるなら、内容は再び読み出せます。これは暗号化の失敗ではありません。再利用するために保存したのだから、必要な性質です。

では、忘れさせるにはどうするか。

一般的な方法の一つが、暗号学的消去です。NISTは、暗号化データの機密性を保護する鍵を消去し、元のデータの復元を実行困難にする手法として定義しています。単に暗号化した状態で置いておくこととは違います。NISTの用語定義

この違いから、設計レビューでは具体的な問いが生まれます。鍵のコピーが別の端末や復旧経路に残るなら、どこまで消すのか。記憶一件だけを削除したいとき、その鍵をほかの記憶と共有していたらどうするのか。元の会話から作った要約も、同じ削除対象に含めるのか。

暗号学的消去を採用すれば自動的に解決する、という話でもありません。消したい情報の範囲と、消せる鍵の範囲が合っているかを確かめる必要があります。

今回確認した発表本文だけでは、Googleの個別メモリ削除や端末紛失時の復旧動作までは判断できません。ここを推測で埋めて、製品の保証にしてはいけません。

次のレビューでは「削除後に戻らないか」を試す

自分たちのAIメモリを検証するなら、架空の予定を一件登録し、別のテスト端末でも参照できる状態を作ります。そのうえで削除を要求し、削除完了後の再ログイン、端末切り替え、復旧フローを通した後にも参照できないかを確かめる。これは提案する確認手順であり、今回Googleのサービスで実施した試験ではありません。

ただし、AIがその予定を答えなかっただけでは、削除の証明にはなりません。保存状態、読み出し結果、派生した要約やバックアップの扱いを、システム側の記録と仕様でも確認する必要があります。

便利に覚えてくれるAIほど、読み出せる条件と、忘れる条件の両方が製品仕様になります。

次に「データは暗号化しています」と説明されたら、その後に一つ聞いてみてください。

「削除した記憶は、どの経路からも再利用されなくなるのですか？」

参考資料

Google DeepMind — Advancing Private AI Compute with secure, server-side memory（2026年9月23日）
https://deepmind.google/blog/advancing-private-ai-compute-with-secure-server-side-memory/

Google Cloud — Confidential Computing overview（使用中のデータ保護の基礎説明）
https://docs.cloud.google.com/confidential-computing/docs/confidential-computing-overview

NIST CSRC — CE / cryptographic erase（SP 800-88r2に基づく用語定義。新発表ではなく、消去の概念を確認する資料）
https://csrc.nist.gov/glossary/term/ce