Google Private AI Computeのメモリー、クラウドのステートレスなプライバシーモデルに挑む

GoogleはPrivate AI Computeに永続的なサーバー側メモリーを追加し、これまでプライバシー重視のクラウドAIを特徴づけてきたステートレス設計から踏み出した。このシステムは、復号鍵をユーザーが管理するハードウェアに保持したまま、デバイスをまたいでコンテキストを記憶することを目的としている。

これはGoogle Private AI Computeのメモリーにとって重要な変化だ。これまでGoogleとAppleは、「忘れること」を中心的なプライバシー保護策として扱ってきた。各クラウドリクエストは隔離環境に入り、回答を受け取り、永続的な個人コンテキストを残さずに終了していた。

Googleは現在、クラウド環境がリクエストのたびにすべてを忘れてしまうなら、アシスタントは真に継続的な存在にはなれないと主張している。同社が提案する答えは、クラウドに残りつつも、デバイス由来の鍵なしには開けられない暗号化メモリー保管庫だ。

このアーキテクチャは、継続性とデータ最小化の間に直接的な緊張関係を生む。より多くを記憶すればアシスタントはより便利になり得る一方、ステートレスシステムが回避するために設計されてきた永続的な標的も生み出す。

Google、Private AI Computeにメモリーを与える

Googleは、プライベート推論サービスを永続的なパーソナルコンピューティング層へと変えようとしている。

Google DeepMindは2026年9月23日にこのアーキテクチャを公開した。同社の技術アップデートでは、セッションやデバイスをまたいで個人コンテキストを保持するメモリー層が説明されている。

Private AI Computeは当初、負荷の高いAI処理をスマートフォンの外部へ拡張するものだった。ローカルモデルに十分な計算能力がない場合、デバイスは暗号化されたリクエストを保護されたGoogleインフラへ送信できる。

そのクラウド環境は、ハードウェアで隔離されたシステム内でリクエストを処理した。その後、セッションの個人コンテキストを保持せずに結果を返していた。

Googleはこの従来設計をステートレスと呼ぶ。実務的には、このサービスは単発のリクエストには役立っても、その後に同じ体験を安全に継続することはできなかった。

新しいメモリー層はこの制約を変える。推論リクエストが終了した後も、個人コンテキストをユーザーごとのデータベースに残せる。Googleによると、保存された情報は暗号化されたままであり、それを解除するための鍵はユーザーのデバイスに保持される。

認可されたモデルがそのコンテキストを必要とする場合、デバイスは隔離されたクラウド環境との間に認証済みのエンドツーエンド暗号化接続を確立する。そのセキュアエンクレーブは、必要な情報だけを保護されたメモリー内で一時的に復号する。

セキュアエンクレーブは、コードとデータをより広範なサーバー環境から隔離する、ハードウェアで強制された領域である。高い権限を持つインフラソフトウェアであっても、エンクレーブの稼働中メモリーを自由に調べられるべきではない。

リクエストを処理した後、システムは保持されたコンテキストを更新できる。その後、ストレージに戻す前にコンテキストを再び暗号化する。

この構造は、ステートレスモデルでは難しかった体験を支える。スマートフォンで始めた会話を、背景情報を手作業で再構築することなくノートPCで続けられるようになる。

Googleはスマートグラスに関する例も示している。利用者はグラスを通じて手順を確認し、その後、別のデバイスから関連するコンテキストを呼び出せる。

同社は、この発表において幅広い消費者向け提供の時期を明らかにしていない。将来の永続的メモリー体験を可能にする機能として、このアーキテクチャを説明している。

この違いは重要だ。Googleはセキュリティモデルを明らかにしたが、読者が利用できる完全な製品一覧や、保存されたメモリーを確認するための標準的な操作手段はまだ示されていない。

それでも、この発表は戦略的な転換を示す。Googleはもはや、プライベートなクラウド推論と永続的なパーソナライゼーションを別個の課題として扱っていない。

従来のPrivate AI Computeプラットフォームは、機密性の高いリクエストに従来型のクラウドアクセスパターンを適用することなく、より大きなGeminiワークロードを実行することに重点を置いていた。永続的メモリーは、システムの責任を推論の瞬間を超えて拡張する。

このサービスは今後、送信中、アクティブな処理中、長期保存、後の取得、削除に至るまで、情報を保護しなければならない。段階が増えるたびに、設計上のミスがプライバシーに影響し得る場所も増える。

より広い責任範囲こそが本質だ。Googleは、クラウドAIが、運営者にそのメモリーへの通常のアクセス権を与えずに、時間を通じて個人を記憶できると提案している。

ステートレスなクラウドAIが限界に達した理由

機密クラウドAIを信頼しやすくしたプライバシー機能は、パーソナルアシスタントとしての能力も制限していた。

ステートレス処理は、サーバー上に残る個人情報の量を最小化する。同時に、モデルは過去のやり取りに関する永続的な記録なしで保護された各セッションを開始するため、継続性も制限される。

開発者は、選択した設定を別の場所に保存することでこの問題を回避できる。アシスタントは、ユーザーの希望言語、食事制限、よく行く目的地などを保持するかもしれない。

しかし、孤立した事実の一覧では、進展していく会話を再現できない。未完了の作業、変化する優先順位、異なるデバイスで完了した活動同士の関係を完全に表すこともできない。

その結果、ユーザーは繰り返し同じ選択を迫られる。同じコンテキストを再度説明するか、一般的なクラウドアカウントに保存を許可するか、あるいはパーソナライズの度合いが低いアシスタントを受け入れるかだ。

Google Private AI Computeのメモリーは、この選択をなくすことを意図している。永続的な暗号化ストレージと、情報を読める状態にするために必要な鍵を分離する。

この分離が重要なのは、高度なAIモデルには依然として大規模なサーバーリソースが必要だからだ。スマートフォンやノートPCでも性能の高いローカルモデルを実行できるようになっているが、最先端規模のすべてのタスクを効率的に実行できるわけではない。

クラウドインフラは、より大きなモデル、専用アクセラレーター、より多くの利用可能なメモリーを提供する。一方で、機密情報を別の組織が管理する環境に移すことにもなる。

コンフィデンシャルコンピューティングは、その信頼の隔たりを縮めようとする手法だ。保存中やネットワーク上の移動中だけでなく、データが使用されている最中も保護する。

従来の暗号化は、保存中および転送中のデータを保護する。しかし通常のサーバーでは、モデルが処理する前のどこかでその情報を復号しなければならない。

信頼実行環境、すなわちTEEは、その露出する段階を制限する。承認されたコードは隔離された境界内で可読な情報を処理し、周囲のホストはそれを直接調べられない状態に保たれる。

Google Cloudはコンフィデンシャルコンピューティングを、処理中の機密ワークロードを保護する手段として説明している。用途には、分析、機械学習、保護されたデータセット間のコラボレーションが含まれる。

このアプローチは、すべての信頼上の前提をなくすわけではない。どのコンポーネントを信頼する必要があるかを変え、デバイスが自らのデータを受け取る環境について技術的な証拠を得られるようにする。

永続的メモリーは、こうした保証の重要性を高める。単一の推論リクエストが公開するのは、限られた期間にわたる限定的なコンテキストの断片だ。

永続的なAIメモリーには、会話、好み、文書、位置情報、行動パターンが蓄積され得る。アシスタントにとっての価値は、攻撃者にとっての価値にもなる。

ナレッジワーカーには、その魅力が理解できるだろう。個人アシスタントは、会議、ファイル、意思決定、未完了タスクを時間をまたいで結び付けられるほど有用になる。

同じ原則は、パーソナルナレッジベースにも当てはまる。有用な検索・取得は、永続的なコンテキスト、明確な所有権、無関係な人々によるアクセスを防ぐ制御に依存する。

Googleはこれらの原則をクラウド規模で適用しようとしている。継続性を保ちつつ、プロバイダーを可読な個人履歴の管理者にしないことが求められる。

この圧力はGoogleに限らない。継続性はタスク完了率を高め、繰り返しのプロンプトを減らすため、主要なアシスタントベンダーはどこもより長期的なコンテキストを求めている。

難しい問いは、アシスタントが記憶すべきかどうかではもはやない。従来型のサーバー側での可視性を受け入れずに、ユーザーが有用なメモリーを得られるかどうかだ。

Google Private AI Computeのメモリーの仕組み

この設計は、暗号化されたメモリーをGoogleのインフラに置きながら、実質的な解除権限を個人のデバイスに結び付ける。

Googleはメモリーストアを安全なデジタル保管庫として説明している。各ユーザーには、そのユーザーのデバイスに関連付けられた暗号化で保護される、隔離されたストレージが割り当てられる。

このアーキテクチャでは、一般にDEKと呼ばれるデータ暗号化鍵を用いて、保存されるメモリーを暗号化する。さらに第2の鍵がそのDEKを保護するため、データベースには直接利用可能な解除用シークレットが保持されない。

Googleの図は、この第2層を鍵暗号化鍵の仕組みとして示している。デバイスは、保存データを解除するために必要な鍵素材の導出または保護に関与する。

この設計は、暗号化されたデータベースを盗んだだけでは、その内容を明らかにできないことを意味する。攻撃者にはさらに、認可済みの鍵経路と承認された処理環境へのアクセスが必要になる。

アシスタントがコンテキストを必要とする際、クライアントはまずリモート環境を検証する。このプロセスはリモートアテステーションと呼ばれる。

リモートアテステーションにより、デバイスは機密情報を送る前に、サーバーのハードウェアと実行中のソフトウェアに関する主張を確認できる。有効なレポートは、承認済みのコードが想定されたエンクレーブ内で動作していることを示す必要がある。

次にデバイスは、その環境への暗号化チャネルを作成する。システムが必要な検証を通過した後に限り、メモリーは隔離されたメモリー内で復号される。

モデルは、そのコンテキストを利用してリクエストに回答できる。また、メモリーサービスが後のやり取りのために保存する新たな情報を生成することもできる。

Googleによると、管理者も通常のクラウドサービスもこの情報を調べることはできない。さらに同社は、このアーキテクチャによりデータはGoogle自身にとってもアクセス不能になると主張している。

この主張は暗号化だけに依存するものではない。デバイスはサーバーを正しく検証する必要があり、エンクレーブは隔離を強制し、ソフトウェアは出力を通じたデータ漏えいを防がなければならない。

鍵管理も中心的な課題になる。アカウント復旧、デバイス交換、同期、失効の過程で、別のアクセス経路が気付かれないまま導入されれば、プライベートなシステムでも失敗し得る。

Googleは、こうしたユーザーライフサイクルのシナリオを公開発表で完全には詳述していない。これらは、実際に導入されるシステムがそのアーキテクチャ上の約束にどこまで近づくかに影響する。

たとえば、信頼できるデバイスをすべて失った場合、難しい選択が生じる。強力なデバイス専用鍵は、メモリーを永久に復元不能にする可能性がある。

プロバイダーが管理する便利な復旧機構は、そのリスクを下げるだろう。一方で、ユーザー以外の誰かがアクセスを得る別の経路を作る可能性もある。

新しいスマートフォンの追加も関連する問題をもたらす。システムは、鍵を仲介者に明かしたり、認可されていない登録を受け入れたりすることなく、そのデバイスに権限を移さなければならない。

削除は、目に見えるメモリー項目を取り除くだけでは不十分だ。ユーザーは、廃止された鍵、レプリカ、バックアップ、キャッシュ、派生コンテキストによって、削除されたはずの情報が後から復元されないという確信を必要とする。

これらは通常の運用要件であり、Googleの設計に欠陥がある証拠ではない。プライベートAIメモリーが、単にデータベースをエンクレーブの背後に置く以上のものを必要とする理由を示している。

推論経路そのものには複数のコンポーネントが含まれる。先行する独立評価では、暗号化されたクライアント接続、フロントエンドサービス、オーケストレーションシステム、AI安全モジュール、強化されたTPUインフラが説明されていた。

これらのコンポーネントは相互に認証し、アテステーションを用いて承認済みの通信経路を確立する。追加される各サービスは、想定されたプライバシー境界内にとどまらなければならない。

Googleは、サーバーソフトウェアに関する改ざん耐性のある記録も公開する計画だ。クライアントは個人データを送信する前に、サーバーがアテステーションで提示したソフトウェア測定値を公開記録と照合できる。

この仕組みは、クラウドにおける微妙なリスクに対処する。プロバイダーがレビュー用に安全なコードを公開しながら、本番環境では異なるソフトウェアを稼働させる可能性があるためだ。

追記専用の透明性記録は、検出されない置き換えをより困難にする。研究者は記載されたビルドを調査でき、デバイスは承認済みの測定値と一致しない環境を拒否する。

この仕組みは、承認されたすべてのビルドに脆弱性がないことを証明するものではない。デバイスが信頼を許可されたソフトウェアが、実際に調査対象となったソフトウェアに対応していることの証拠を提供する。

この区別は重要だ。透明性は精査を可能にするが、精査には依然としてアクセス可能な成果物、有能な研究者、そして時間が必要となる。

プライバシーの約束には依然としてハードウェア上の境界がある

Googleはクラウド管理者の権限を縮小できるが、Googleが設計したハードウェアとソフトウェアへの依存をすべて取り除くことはできない。

Googleは2025年春から、NCC GroupにPrivate AI Computeの選定部分の評価を委託した。10人のコンサルタントが、アーキテクチャおよびコンポーネントのレビューに計100人日を費やしたと報じられている。

独立レビューでは、Oak Session暗号ライブラリ、リモートアテステーション、IP匿名化リレー、透明性ログ、選定されたサーバーコードを検証した。この作業は、監査を受けていない製品上の主張よりも具体的な根拠を提供する。

ただし、その対象範囲は重要だ。選定コンポーネントのレビューは、将来のすべてのメモリー機能、クライアント実装、ハードウェア改訂、運用手順を認証するものではない。

この評価は、根本的な制約も示している。実用的なAI推論は現在、何らかの物理的な計算システム内部で可読状態となるデータを扱っている。

そのため、暗号化された情報は計算中に保護されたプロセッサ内で平文となる。ハードウェアと承認済みコードは、要求された処理を実行しなければならないため、それにアクセスできる。

NCCの報告書は、ハードウェア設計者が理論上はチップに情報流出経路を作り出せる能力を保持していると指摘する。Private AI Computeは最終的に、Googleの強化されたTPUプラットフォームが説明どおりに動作することに依存している。

この制約は、コンフィデンシャルコンピューティング全般に当てはまる。エンクレーブはハイパーバイザー、管理者、侵害されたホストソフトウェアへの露出を減らすが、物理的な計算を信頼不要にするわけではない。

サイドチャネル攻撃も別の懸念を生む。こうした攻撃は、タイミング、メモリーアクセス、リソース競合、消費電力などの観測可能な振る舞いから、保護された情報を推測する。

コンフィデンシャルプラットフォームは継続的に緩和策を追加しているが、新たなハードウェア脆弱性によって従来のセキュリティ前提が変わる可能性がある。したがって、システムのプライバシーに関する説明も脅威環境の変化に応じて進化しなければならない。

エンクレーブ内のソフトウェアも誤りを犯し得る。基盤となるストレージが暗号学的に保護されていても、モデルや支援サービスが出力を通じて機微な詳細を露出させる可能性がある。

プロンプトインジェクションも関連する課題をもたらす。悪意あるコンテンツは、ユーザーがその文脈で共有する意図のなかった情報を、アシスタントに取得または開示させるよう操作できる。

エンクレーブは、ある要求がユーザーの真の意図を表すかどうかを自動的に判断できない。開発者が実装したポリシーの下で、承認済みソフトウェアを実行する。

永続的なコンテキストは、侵害された1回のやり取りの際に利用可能な情報が増える可能性があるため、リスクを高める。アクセス制御では、各機能が取得できるメモリーを制限しなければならない。

システムには、メタデータからの推論を防ぐ対策も必要だ。ストレージ容量、アクセス頻度、デバイスのタイミング、ネットワークパターンは、メモリーの正確な内容を露出させずに情報を明らかにし得る。

Googleの従来アーキテクチャには、ユーザーIDとリクエストを分離するよう設計されたIP匿名化リレーが含まれている。永続システムでも、メモリーの読み取りと更新にわたって同様の保護を維持しなければならない。

研究者は、コンフィデンシャルAIに向けたよりオープンなアプローチを提案している。2026年のOpenPCC論文は、GoogleとAppleによる初期システムが独自インフラに大きく依存していると論じている。

同論文の著者は、市販の信頼実行環境を用いたオープンソースのプロトタイプを構築した。その批判は、Googleにとって重要な検証上の問いを浮き彫りにしている。

外部の研究者には、意味のあるプライバシー上の主張を検証するために、十分なコード、測定値、ツールが必要だ。公開ログだけでは完全な再現性は得られない。

Googleは、更新したアーキテクチャの詳細、セキュリティ証明、検証プロトコル、監査結果を公開するとしている。この開示の深さによって、研究者がメモリー層をどこまで独立して評価できるかが決まる。

したがってユーザーは、「Googleでさえアクセスできない」という表現を、階層的な制御で支えられたセキュリティ目標として解釈すべきだ。Googleをまったく信頼する必要がないという主張ではない。

このアーキテクチャは、個人的なコンテキストを閲覧できる人やシステムの数を減らす。また、不正アクセスを技術的に困難にし、検出しやすくする。

これは、主にポリシーと管理アクセス制御によって保護される一般的なクラウドデータベースより強い基準だ。それでも、すべての情報をネットワークから切り離されたハードウェアに保持することと同等ではない。

Appleのステートレスモデルが現在の主要な対照軸となる

Googleは、私的な永続性がユーザーの実効的なプライバシー境界を弱めずに、厳格な忘却を上回れると賭けている。

AppleのPrivate Cloud Computeは最も明確な比較対象となる。AppleはPCCを、ステートレス処理、限定的な管理アクセス、標的化不可能性、検証可能なソフトウェア透明性を中心に構築した。

同社のセキュリティアーキテクチャでは、リクエスト完了後にユーザーデータが残らないようにすべきだとしている。ノードのデータボリューム用暗号鍵は再起動時に変更され、保持されない。

AppleはPCCノードから対話型デバッグツールと汎用ログ機能も取り除いている。その公開モデルでは、ユーザーデータを保持できないことを強制可能な特性として扱う。

Private AI Computeの開始時、Googleもこのステートレスの哲学の多くを共有していた。永続的なサーバー側メモリーは今や、両アプローチの明確な分岐を生み出している。

Appleのモデルは、長期にわたるクラウド状態を最小化する。Googleの新しい設計は、個人向けAIにとってデバイス間の継続性が不可欠だとみなし、耐久性のある暗号化状態を受け入れる。

どちらの立場も、すべての問題を解決するわけではない。ステートレス処理は長期的な蓄積から保護する一方で、アシスタントが自然に作業を再開する能力を制限する。

永続的な暗号化メモリーは、より豊かなパーソナライゼーションを支える。その代わり、作成、取得、変更、転送、保持、削除を含む、より大きなライフサイクルが生じる。

比較は単なるGoogle対Appleではない。これは、プライベートクラウドAIが何を保証すべきかについての二つの定義を表している。

一方の定義では、プライベートな計算はタスクごとに忘却すべきだとする。もう一方では、記憶してよいが、ユーザーのデバイスが承認する鍵とソフトウェアを通じてのみ行うべきだとする。

Appleはまた、高負荷なワークロード向けにPCCをGoogle Cloudインフラへ拡張している。Appleデバイスが信頼するのは、引き続きAppleが暗号学的に承認したソフトウェアのみだとしている。

この提携は、ハードウェアの所有とプライバシー制御が常に同じ組織に属するとは限らないことを示す。ソフトウェアアテステーションにより、一社が別の会社のインフラ上で要件を強制できる。

それでもAppleは、PCCをステートレスであると説明し続けている。したがってGoogleの永続層は、Appleが中核的な保護策として提示する特性を超えるものだ。

この違いは製品の挙動を通じて具体化する。ステートレスなアシスタントは、クラウドに入るたびにデバイスまたは別のユーザー管理ストアからコンテキストを取得する必要がある。

Googleのアプローチでは、保護されたクラウド環境がデバイスの承認後、過去のコンテキストを直接取得できる。これにより、レイテンシー、繰り返しの転送、製品間の断絶が減る可能性がある。

一方で、Googleのメモリー形式とデバイス登録システムへの依存を強める可能性もある。ユーザーは、内部アシスタント向けに最適化された履歴を調査または移行することが難しいと感じるかもしれない。

発表ではポータビリティには触れられていない。標準的なエクスポート形式、保持のデフォルト設定、互換性のあるメモリーサービスを別の場所で運用する能力についても同様だ。

これらの問題は、プライバシーと同じくらい競争に影響する。有用なメモリーは、時間とともに価値を高めるパーソナライズされた資産となる。

その資産が一つのアシスタントに結び付いたままであれば、サービスを切り替えることは蓄積したコンテキストの喪失、または移行時の露出を意味する。暗号化だけではロックインを防げない。

Googleは、明確な閲覧、エクスポート、修正、削除の管理機能をユーザーに提供することで、自らの立場を強化できる。また、人々がデバイスやアカウントを変更した際にメモリーがどのように移動するかを文書化することもできる。

一方のAppleには、自社のステートレス設計が同等の継続性を提供できることを示す圧力がかかる。暗号化されたデバイスストレージへの依存を強め、各リクエストに必要な最小限のコンテキストのみを同期する可能性がある。

他のアシスタントベンダーも同じ選択に直面している。メモリーを従来型のアカウントデータベースに保持する、コンフィデンシャルインフラを採用する、あるいは長期的なコンテキストをユーザー管理デバイスに残すという選択肢がある。

Googleの設計は、高度に個人的なアシスタントにとって通常のサーバー側ストレージが以前より擁護しにくいものに見えるようにする。より強力な制御が存在する以上、プライバシーを重視するユーザーは、競合他社がなぜそれを利用しないのかを問える。

ユーザーと研究者が次に注視すべきこと

このアーキテクチャが信頼を得るのは、図解だけではなく、実装された制御と外部からの精査を通じてだ。

最初の兆候は製品展開だ。Googleは、どのGemini体験が永続的なPrivate AI Computeメモリーを使用し、どの体験が他のストレージシステムを継続使用するのかを明示する必要がある。

リクエストが保護された環境に入る時点で、ユーザーに分かる表示があるべきだ。Googleはすでに、対応するPixelデバイスでPrivate AI Computeのネットワーク情報を提供している。

永続メモリーにも同様に明確な管理機能が必要だ。ユーザーは、何が保持されたのか、なぜ取得されたのか、どのデバイスが操作を承認したのかを確認できるべきである。

そのインターフェースは、Google AIメモリーのプライバシーがセキュリティ論文の外でも理解可能かどうかを示す。隠されたメモリーや過度に広範なメモリーは、このアーキテクチャの実用的な価値を損なうだろう。

二つ目の兆候は独立検証だ。研究者には、新しいメモリーコンポーネントに関する利用可能なソフトウェア記録、検査ツール、アテステーションの証拠、文書が必要となる。

Googleの透明性ログは、永続的なコンテキストを取得または更新できるすべてのセキュリティ上重要なサービスを対象にするべきだ。部分的な対象範囲では、重要なコードが公開精査の外に残る可能性がある。

将来の評価では、従来のステートレスインフラだけでなく、実際に展開されたメモリー経路を検証すべきだ。鍵の取り扱い、デバイス登録、削除、復旧、悪意ある入力への耐性を調べる必要がある。

公開された脆弱性研究は、公開文書の数より重要になる。信頼できる発見、修正、開示のタイムラインは、プラットフォームが圧力下でどのように振る舞うかを示す。

三つ目の兆候は競合各社の対応だ。Appleによるステートレス処理へのコミットメントは、Googleの設計を判断するための明確な代替案として機能している。

Googleが重大なプライバシー上の失敗なく有用なデバイス間の継続性を実現すれば、厳格なステートレス性は不必要に制約的に見え始めるかもしれない。競合各社には保護された永続性を追加する圧力がかかるだろう。

復旧、削除、検証のいずれかで不透明さが明らかになれば、Appleの「忘れることを優先する」アーキテクチャへの支持が強まるだろう。同じ結果は、メモリーをローカルに保持するアシスタントにも有利に働く。

企業の購入担当者は、Googleがこのシステムを組織データ向けにどう適応させるかも注視すべきだ。個人用デバイスの鍵は、従業員の離職、法的な保存義務、共有ワークスペースにそのまま対応できるものではない。

企業では、管理者が記録を復旧したり、アクセス権を削除したりする必要がある場合がある。こうした要件は、プロバイダーでさえ保存済みコンテキストを復号できないという約束と衝突する可能性がある。

開発者は、将来的なアクセスモデルを精査すべきだ。プライベートなメモリー層には、無関係な目的のために作成されたコンテキストを、あるアプリケーションが取得できないよう、限定的な権限が必要となる。

すべてのGoogle AI機能が自動的にこれらの保護を受けると、ユーザーは考えるべきではない。Private AI Computeは特定のアーキテクチャであり、すべてのクラウド処理に適用される包括的な呼称ではない。

製品ドキュメントには、システムがいつ有効になるのか、利用できない場合に何が起きるのかを明記する必要がある。リクエストがより保護の弱いサービスへ密かに移行するなら、フォールバック動作がプライバシーを損なう可能性がある。

Google Private AI Computeのメモリーは、プライベートなクラウドアシスタントが抱える現実的な弱点に対応する。ステートレスなシステムは、忘却によってユーザーを保護する一方で、デバイスをまたぐ継続的な作業の支援には苦労する。

Googleの代替案は、技術的には野心的であり、概念的には分かりやすい。コンテキストをリモートに保存し、鍵はユーザーが保持し、検証済みソフトウェア内でのみ復号するというものだ。

本当の難しさは、その設計が図面を離れた後に始まる。アカウント復旧、デバイス移行、アクセス境界、透明性、削除、ソフトウェアの欠陥が、実際のプライバシー水準を左右する。

ユーザーにとって、当面取るべき行動は簡単だ。今後のGeminiメモリー機能がPrivate AI Computeを明示しているか、保持されるコンテキストを表示するか、直接的な削除コントロールを提供するかを確認するとよい。

研究者にとって、試験はより厳格だ。独立した専門家は、本番環境のソフトウェアを検証し、信頼の連鎖を再現し、攻撃者より先に重大な弱点を見つけられるのか。

Googleは、クラウドアシスタントがメモリーとプライバシーの間で、もはや選択を迫られなくなる可能性を提案した。今後のリリースでは、安全なサーバー側メモリーがこの約束を長期にわたって守れるかどうかが示されなければならない。