はじめに
AIアシスタントが便利になるほど、「私のことをどこまで覚えているのか」「その記憶は誰が読めるのか」が気になります。2026年9月23日、Googleは、クラウド上でAIの長期的な記憶を持たせながら、その内容をGoogle自身にも読めない形で保つという設計を発表しました。「Private AI Compute」に、サーバー側の永続メモリを加えるものです。
ただし、この発表は**「今後提供する仕組み」**の説明です。本記事では、公式ブログと技術ブリーフ(白書)をもとに、仕組みと、現時点で分かっていること・まだ分かっていないことを整理します。
Private AI Compute とは
Googleは2025年11月11日に、Private AI Computeを発表しました。Geminiのクラウド上の高性能モデルの力を使いながら、端末内で処理するのと同じレベルのセキュリティとプライバシーを保つ、というAI処理基盤です。Googleが独自に開発するTPU上で動き、Titanium Intelligence Enclaves(TIE)で保護されます。個人のデータは、ユーザー本人だけがアクセスでき、Googleを含む他の誰にもアクセスできない、と説明されています(Private AI Compute: our next step in building private and helpful AI | Google)。
発表時の利用例は、Pixel 10のMagic Cue(タイミングの良い提案)と、PixelのRecorderアプリで、より多くの言語で文字起こしを要約する機能でした。
なぜ「記憶」が課題だったのか
Google DeepMindの公式ブログによると、Private AI Computeはこれまで、処理が終わった時点でコンテキストをすべて消す「ステートレス」な仕組みでした。業界の同種の技術も同じだったとされています。AIが個人の事実や好みのリストを保存する回避策では、個人向けAIに期待される豊かで継続的な体験を支えるには足りない、という説明です(Advancing Private AI Compute with secure, server-side memory | Google DeepMind)。
技術ブリーフでは、端末側に記憶を置く方法の限界として、次の3点が挙げられています(Google Private AI Compute: Enabled with Secure Server-Side Memory(技術ブリーフ)| Google)。
| 端末に保存する場合の制約 | 内容 |
|---|---|
| 容量 | 端末の物理的な保存容量に限りがある |
| 同期 | 複数の端末をまたいで同期する手間がかかる |
| 通信 | 膨大な履歴を、クラウド上の最先端モデルへ毎回送ると、帯域と遅延の負担が大きい |
ブログは、たとえば、スマートグラスで以前見た組み立て手順をノートパソコンで開く、モバイルとWebの間で複雑な会話を再開する、といった場面を例に挙げています。
新しい仕組み: サーバー側メモリ
ブログによると、新しい永続メモリ層は、クラウド上の「安全なデジタル金庫」のように機能します。アシスタントが必要とする情報は、専用の暗号化ストレージに封じられます。それを開けるための暗号鍵は、ユーザーの個人の端末だけが保持し、Googleを含む他の誰も情報にアクセスできない、と説明されています。
AIモデルが情報を必要とするときは、端末と、クラウド上の保護された隔離環境(セキュアエンクレーブ)が、認証済みのエンドツーエンド暗号化チャネルで接続されます。エンクレーブは、隔離されたメモリ内で一時的にデータを復号して要求を処理し、新しいコンテキストがあれば保存して、すぐに再び暗号化します。
技術ブリーフでは、この仕組みを構成する要素が、次のように説明されています。
| 構成要素 | 内容 |
|---|---|
| ユーザーごとのハードウェア隔離データベース | 中核は「memory Oak Server」。ハードウェアのTEE(信頼実行環境)の中で動く、ユーザーごとのデータベース。記録はユーザーごとの鍵で暗号化され、鍵は信頼された計算基盤の外側やGoogleのインフラからは見えない。暗号化されたデータベースの保存・複製・バックアップは可能だが、平文にはアクセスできない |
| オーケストレーター | AIモデルとmemory Oak Serverの間を仲介し、データの経路制御、モデル呼び出し、ストレージ操作が、保護された境界の内側に収まるようにする。ユーザーデータは平文ではエンクレーブの外に出ない |
| 証明付きの暗号化チャネル | オーケストレーター、メモリサーバー、推論パイプラインは、互いに双方向の証明(アテステーション)で認証し合う。有効な証明を出せない構成要素は、データの経路に加われない |
| メモリ安全な言語 | メモリ用のTEEアプリケーションはRustで書かれ、Oak Containersランタイム(こちらもRust製)上で動く。メモリ安全性の脆弱性のリスクを大きく減らす狙い |
| オープンソース | memory Oak ServerとOak Containersランタイムはオープンソースで公開され、第三者が実装を確認できる |
なお、CPU側の処理はAMDのハードウェアTEE、TPU側の処理は、TPUのハードウェアを使って「一般的なTEEに匹敵する」性質を持たせた強化済みTPUプラットフォーム(Titanium Intelligence Enclave)で保護されます。
リクエストの流れ
技術ブリーフには、過去の記憶を必要とするエージェント的な問い合わせが、どう処理されるかが4段階で説明されています。
| 段階 | 内容 |
|---|---|
| 1. 証明付きの受け付け | クライアントがNoiseプロトコルで暗号化セッションを確立。要求は、AMD SEV-SNPの機密VM内にあるオーケストレーション用エンクレーブに届く |
| 2. 証明付きの文脈取得 | オーケストレーターが、memory Oak Serverとの間で相互に証明されたALTSチャネルを確立。エンクレーブの計測値をハードウェアで検証したうえで、ユーザーの復号鍵がデータベースエンジンに渡される。関連する記録は、エンクレーブの揮発性メモリの中だけで復号される |
| 3. 記憶を加えた推論 | 取得した記憶と、現在のプロンプトを統合し、証明済みの内部チャネルで強化済みTPUプラットフォームへ送る。モデルは、TPUの境界の内側だけでプロンプトを評価し、平文のプロンプトや中間状態は、その境界を越えない |
| 4. 状態の確定と揮発領域の消去 | セッションで新しい記憶、事実、更新された好みが生まれたら、memory Oak Serverに書き戻し、ユーザーの鍵で再暗号化して永続ストレージに保存。応答の返却後すぐに、プロンプトのコンテキスト、トークン、中間状態を消去し、平文が残らないようにする |
鍵の管理
メモリの記録は、Googleのインフラではなく、ユーザーに紐づく鍵で暗号化されます。ブログは「鍵は個人の端末だけが保持する」と表現していますが、技術ブリーフでは、端末に由来する鍵で守られたユーザーごとのデータベースとして説明されており、鍵の実体は、証明済みのTEEの中でだけ平文で存在するとされています。また、鍵をメモリサーバーに渡すかどうかは、証明が条件です。承認されたメモリ用バイナリに一致する証明を示せないエンクレーブは、鍵を得られず、メモリを読めません。改変された、あるいは許可されていないビルドの場合も同様です。
脅威モデル: 何を守り、何を主張していないか
技術ブリーフは、永続データのセキュリティ目標を、次のように整理しています。
| 目標 | 内容 |
|---|---|
| 一時的ではなく、隔離による保護 | メモリ機能を使う場合、データは定義上「保持」される。保護は、ハードウェアによる隔離とユーザーごとの暗号化によって成り立ち、証明済みのエンクレーブの外側にいる誰も、内容を解釈できない形で存在する |
| 特権アクセスの排除 | 緊急時を含め、平文のユーザーデータへの管理者向けの経路はない |
| 侵害の封じ込め | メモリサーバーは機密VM内で動くため、1つのインスタンスの侵害が、他のユーザーの状態には及ばない |
| 外部への流出の制御 | 既定で外部への送出を禁止し、監視、ログ、コアダンプ経由でメモリの内容が出ないようにする。ユーザーが明示した意図がある場合を除く |
| 標的にされにくさ | ステートフルな仕組みでは、ネットワークレベルでの「標的にされにくさ」は主張していない(下記) |
最後の項目は、重要な違いです。ステートレスな推論では、IPアドレスを隠す中継(第三者が運用)や匿名トークンで、問い合わせとユーザーを結びつけられないようにしていました。一方、永続メモリでは、要求は必ずユーザーのストアに届く必要があり、ユーザーごとの安定した識別子を解決せざるを得ません。そのため、ステートフルな仕組みは、ネットワークレベルの標的にされにくさを主張しません。代わりに、特定のユーザーのメモリを狙っても、得られるのは意味を持たない暗号文だけで、平文にはユーザーの鍵が必要になり、その鍵は証明済みのエンクレーブの中にしか存在しない、という設計です。
検証可能性: 「信じて」ではなく「確かめられる」ために
ブログは、信頼はまず透明性から始まるとして、次の取り組みを挙げています。
- 更新した技術ホワイトペーパーの公開
- サーバーソフトウェアの、改ざん防止のある公開記録の公開
- Private AI Computeを実行する端末が、個人データを送る前に、ソフトウェアが本物で改変されていないことを検証できるようにすること
- 大手のサイバーセキュリティ企業による、独立した監査の結果の共有
技術ブリーフによると、初回のリリースと、サーバー側メモリの更新の両方について、外部の監査人が、システム設計が厳格なプライバシー・セキュリティ基準を満たすことを確認しており、その要約が公開されています。
一方、技術ブリーフの「What's next」では、検証の証拠を利用者側へさらに移していく方向性が示されています。現状と今後を整理すると、次のとおりです。
| 現在 | 今後の方向性 | |
|---|---|---|
| 監査 | 第三者による監査(2025年、2026年の要約を公開) | 定期的な第三者監査、再現可能なビルドの対象拡大、セキュリティ研究者との継続的な対話 |
| ソフトウェアの証明 | システム全体の証明(Titanセキュリティチップからのハードウェア証明とTEE)。本番のバイナリのダイジェストを公開台帳に公開 | 台帳を、独立した第三者が観測・共同署名する、追記専用の透明性ログへ発展させる |
| 端末側の検証 | 端末は、データを送る前にサーバーの鍵を検証し、本物で改変されていないサービスかを確認する。ただし、準拠しているという根拠自体は、Googleが示す形。Pixelと対応するAndroid端末では、Private AI Computeへの通信を、ネットワークログで確認できる | Googleが示す形から、サーバーの証明の証拠と、承認されたバイナリの識別を、端末が独立して暗号的に検証できる形へ移行する |
つまり、サーバーの証明の証拠を、端末が独立して暗号的に検証する仕組みは、現時点では今後の課題として位置づけられています。ブログでも、端末が検証できるようになる、という将来形で書かれています。
現時点で分かっていないこと
- 提供時期と対象サービス: ブログと技術ブリーフには、どのサービスで、いつからサーバー側メモリが使えるのかは書かれていません。ブログは一貫して、これから提供する、という書き方です
- 記憶の中身の管理: 技術ブリーフには、ユーザーが記憶の内容を確認・削除するための機能の詳細は書かれていません。「保持される」ことが前提の仕組みである点は、押さえておく必要があります
まとめ
- Private AI Computeは、2025年11月に発表された、Geminiのクラウド上のモデルを、端末内処理と同水準のプライバシーで使うための基盤。これまでは処理後にコンテキストを消す「ステートレス」だった
- 2026年9月23日の発表は、これに、永続的でクロスデバイスな「サーバー側メモリ」を加える設計。暗号化されたストレージに記憶を封じ、鍵は個人の端末側にあるとブログは説明しており、Googleにも読めない設計とされている
- 中核は、ハードウェアTEE内で動くユーザーごとのデータベース(memory Oak Server)で、Rust製、オープンソース。オーケストレーターと推論パイプラインは、互いに証明し合うチャネルでつながる
- 鍵は、証明を通過したエンクレーブにだけ渡され、改変されたビルドは鍵を得られない
- ステートフルな仕組みは、ネットワークレベルの「標的にされにくさ」は主張せず、標的にされても得られるのは暗号文だけ、という設計
- 独立した監査の要約は公開済み。端末がサーバーを自分で検証する仕組みなどは、今後の課題
- 提供時期や対象サービスは、公式には示されていない
AIの記憶とプライバシーをどう両立させようとしているのかを知りたい方の参考になれば幸いです。
参考リンク
- Private AI Compute: our next step in building private and helpful AI | Google
- Advancing Private AI Compute with secure, server-side memory | Google DeepMind
- Google Private AI Compute: Enabled with Secure Server-Side Memory(技術ブリーフ)| Google
本記事は2026年9月時点の公式情報をもとにまとめています。サーバー側メモリは今後提供される予定の技術で、仕様や提供条件は変更される可能性があります。