なぜAIグラスはクラウドへ逃げざるを得ないのか
AIグラスはフォームファクタとして非常に優秀です。視界を遮らず、常に身体に装着され、ユーザーの視覚と聴覚をそのまま共有できます。問題は演算能力です。通話の発信やメッセージ返信程度ならオンデバイスで十分ですが、リアルタイム翻訳や会話要約、数日前のコンテキストを引き継ぐパーソナライズ応答は、グラスのツルの内部に収まるモデルサイズでは到底実現できません。
しかも計算資源だけが問題ではありません。真に有用なアシスタントになるには、状態(state)を保持し、数日〜数週間にわたる文脈を繋ぎ、バックグラウンドで能動的に処理を進める必要があります。これは結局クラウドで動かすしかない、ということを意味します。
ここで根本的なジレンマが生じます。
「あなたを深く理解する超パーソナライズAIを、プライバシーを守りながらどう作るのか?」
従来のクラウドアーキテクチャは、この問いに答えるようには設計されていません。データは保存時(at rest)と転送時(in transit)には暗号化されますが、演算時(in use) にはメモリ上で復号された状態で存在する必要があります。その瞬間、ハイパーバイザ、ホストOS、インフラ運用者はデータを閲覧できます。
本記事は、MetaがAIグラス向けに設計した Private Processing — コンフィデンシャルコンピューティングの上に構築された基盤 — をエンジニアリング視点で整理したものです。根拠資料はMetaエンジニアリングブログで確認できます。

核心概念3点セット:Confidential Computing、TEE、Private Processing
用語が頻出するので、まず整理します。
1. Confidential Computing(パラダイム)
データには元来3つの状態があります。
| 状態 | 説明 | 従来の保護方式 |
|---|---|---|
| At rest | ディスクに保存 | ディスク暗号化 |
| In transit | ネットワーク転送中 | TLS |
| In use | メモリ上で演算中 | なし ← ここが穴 |
コンフィデンシャルコンピューティングは、この第3の状態を塞ぐ業界全体の動きです。
2. TEE(Trusted Execution Environment、ハードウェアプリミティブ)
TEEはCPU/GPUに内蔵されたハードウェア機能です。プロセッサが特殊なVM(これを CVM、Confidential VMと呼びます)のメモリを、チップ内の専用セキュリティハードウェアが保持する鍵で暗号化します。その鍵はホストOS、ハイパーバイザ、さらにはサーバ管理者にも一切渡りません。
CCC(Confidential Computing Consortium)が定義するTEEの3大保証:
- Data Confidentiality — CVM外部からメモリ内容を読めない
- Data Integrity — CVM外部からデータを追加・削除・改変できない
- Code Integrity — ロード済みコードは誰も変更できない
3. Private Processing(Metaの実装)
TEE上に構築されたMetaの基盤で、ハードウェアが提供する機密性+アテステーションに、以下を追加します。
- Non-targetability — 特定ユーザーのセッションだけを狙って攻撃できないようにする
- Encrypted Storage — 保存データもユーザー提供鍵でのみアクセス可能
クライアントがサーバを検証する流れ(Remote Attestation)
ここが本当の核心です。クライアントはサーバを信頼せず、検証します。
1. クライアント → サーバ: リモートアテステーション要求
2. サーバTEE → クライアント: チップ内部鍵で署名されたattestation reportを返却
(CVMがロードしたソフトウェアイメージのmeasurementを含む)
3. クライアント検証:
a. 署名がチップベンダーのroot keyまでチェーンするか?
b. measurementがappend-only透明性台帳に公開された値と一致するか?
4. どちらかが失敗 → 接続拒否、データ送信なし(fail-closed)
つまり「我々を信頼してください」ではなく「このバイナリが正しいか自分で確認してください」という構造です。

AIグラス向けPrivate Processing:5つのエンジニアリング要件
リアルタイム文字起こし、コンテキスト検索、長期リコールといった重いワークロードを安全にオフロードするには、次の5つが必要です。
- Hardware Isolation — 転送・演算・保存のすべての状態で、ホストOS・ハイパーバイザ・Metaがデータを暗号学的に読めない
- Fail-Closed Guarantees — 保証を破ろうとする試みはシステムを閉じさせるか、公開的に発見可能にする
- Public Verifiability — 本番のすべてのCVMイメージはappend-only公開台帳に登録
- Non-Targetability — 特定個人のセッションを狙う攻撃が、システム全体を侵害しない限り不可能
- Encrypted Storage — 保存データはユーザー提供鍵でのみアクセス
セッション確立フロー(4段階)
[1] Decoupling Identity (Non-targetable Routing)
- 匿名クレデンシャル(blind-signed token)をランダムスケジュールで取得
- 認証サービスがリクエストをアカウントに紐付けられない
- サードパーティOHTTPリレー(Fastly/Cloudflare)経由 → TEEノード選択
[2] Remote Attestation (Verification)
- RA-TLSセッション開始、サーバTEEのハードウェア署名証明書を要求
- バイナリハッシュを公開透明性台帳と照合
- 失敗時はハンドシェイク終了
[3] Processing (Execution)
- TLSで暗号化blobを送信、インフラはルーティングのみで読めない
- TEE内部でモデル実行、Metaもアクセス不可
- TEE間通信も同一のRA-TLSプロトコルで相互証明
[4] Stateful Memory (Encrypted Storage)
- 永続メモリが必要な場合、ユーザー鍵で暗号化してTEE外部へ出力
- 取得時はデバイスが鍵を提供 → TEE内部で復号・処理
なぜ「デバイスで暗号化 → クラウドDB保存」ではダメなのか
一見妥当に見えるこのアプローチは、2つの理由で破綻します。
- アクセスパターンが行動を漏洩する — 内容が暗号化されていても、外部DBはいつ読み書きするか、どのくらい頻繁にクエリするか、どのレコードが同時にアクセスされるかを観測できます。このメタデータだけで日常ルーティンが地図のように描かれます。暗号化はペイロードは守れても、実行パターンは隠せません。
- リモート暗号化クエリはスケールしない — セマンティックベクトル検索やマルチセッションjoinを行うには、巨大なciphertextをネットワーク越しにTEEへ引き込み、復号する必要があります。コンテキストが増えるほどレイテンシが爆発します。
そこでMetaは ストレージエンジン自体をTEE内部に 配置しました。信頼境界を拡張し、データを機密的に保存し、クエリエンジンがTEE境界内で直接動作します。読み取りが外部ネットワークを跨がないため高速です。
デバッグ・イン・ザ・ダーク:運用可観測性
ここで興味深い問題が生じます。運用者を暗号学的に排除したシステムを、どう高可用性で維持するのか?
TEE内部では標準的な診断がすべて無力です。
- 実行中のTEEにデバッガをアタッチできない
- クラッシュ時のメモリスタックダンプ、モデル入出力ログが取れない
- 障害を引き起こしたペイロードを覗けない
そのため可観測性はすべて out-of-band で設計する必要があります。CPU使用率、メモリ割当、ネットワークレイテンシ、集約されたハードウェア障害率といった 集約シグナル(aggregate signal) のみに依存してサービスヘルスを維持します。ユーザーデータ1バイトも露出せずに。
検証可能な透明性(Verifiable Transparency)
「我々は安全です」は何の意味もありません。そこで2つの仕組みを置きます。
- Binary Transparency via Public Ledgers — 本番のすべてのCVMイメージをappend-only公開台帳に登録。異なるバイナリを配備しようとすれば、クライアントと外部モニタが不一致を発見できます。これはtamper-evidence(改ざん証拠)を作るものであり、tamper-proofではありません。
- Third Party Validation — NCC Groupのような独立セキュリティ企業と研究者に、アーキテクチャ、アテステーションロジック、分離モデルの境界を監査してもらいます。さらにAIグラス向けPrivate Processingを Bug Bountyの対象範囲に明示的に含め、外部研究者にCVMバイナリとドキュメントを提供します。
この技術の限界と注意点
- TEEは万能ではない — サイドチャネル攻撃(Spectre系、キャッシュタイミング)は依然として研究テーマです。ハードウェアベンダーのマイクロコードパッチに依存する部分が大きいです。
- 公開台帳はtamper-evidenceでありtamper-proofではない — 改ざんを「検知」するだけで「遮断」はしません。検知後の対応ロジックが別途必要です。
- パフォーマンスオーバーヘッド — CVM内部演算、メモリ暗号化、リモートアテステーションハンドシェイクは無料ではありません。レイテンシ敏感な機能はプロファイリング必須です。
- 運用複雑度 — デバッガをアタッチできないシステムの運用とは、可観測性パイプラインをゼロから再設計することを意味します。
次のステップ学習方向
- CCC(Confidential Computing Consortium) のホワイトペーパーとthreat model文書を読む
- Intel TDX / AMD SEV-SNP / NVIDIA H100 Confidential Computing のスペック比較
- RA-TLS プロトコルとOHTTPリレー構造の実習
- 実際に CVM上に簡単なワークロード を載せてアテステーションフローを観察
- エージェント時代の inter-CVM通信 設計パターンの学習(これが次の難題です)

まとめ:「信頼して」から「検証せよ」へ
AIグラス向けPrivate Processingの本質は、華やかなモデルではなく 信頼境界の再設計 です。
- データを保存・転送・演算 のすべての状態で保護
- クライアントがハードウェアアテステーションでサーバを 直接検証
- 特定ユーザーだけを狙う攻撃を構造的に遮断(non-targetability)
- ストレージまでTEE内部に引き込み、アクセスパターン漏洩を防止
- 運用者を暗号学的に排除しつつ、集約シグナルで可用性を維持
今後AIはますます stateful、multimodal、agentic になっていきます。エージェントが機微な状態を保持し、複数セッションにわたって行動するには、分離とデータ来歴の証明、CVM間通信が必須です。今のこの基盤が、その未来の土台となります。
機能は拡大し続けても、セキュリティとプライバシーの境界はそのまま維持される — これがこのアーキテクチャが投げかける本当のメッセージです。