Windows Recall をめぐるセキュリティ議論が再び熱を帯びている。セキュリティ研究者 xaitax が「認証後の復号データが保護されていないプロセスに渡る」と主張したのに対し、Microsoft は「文書化済みの意図した設計通りだ」と反論し、調査を「脆弱性なし」として終了した。両者は同じ挙動を見ながら、まったく異なる結論に達している。
何が問題になっているのか
Windows Recall は Copilot+ PC 限定の機能で、画面のスナップショットを定期的に保存し、後から自然言語で検索・参照できるようにするものだ。セキュリティ設計の柱は3つ——オプトイン（初期状態は無効）、ローカル保存（Microsoft への送信なし）、Windows Hello 認証（TPM と VBS（仮想化ベースのセキュリティ）によるデータ暗号化）。
研究者 xaitax が問題にしたのは、この3つの柱の「その先」で起きることだ。
VBSエンクレーブとレンダリング層のはざまで何が起きるか
Recall のデータは VBS エンクレーブ内で暗号化・保護されている。この部分は文字通り鉄壁だ。しかし認証が完了した後、復号されたスクリーンショットや OCR テキスト、メタデータは「タイムライン表示」のための UI プロセス（AIXHost.exe）に渡される。xaitax の主張は、この AIXHost.exe が Protected Process Light（PPL）を持っていないため、同一ユーザーとして実行されるコードからのプロセスインジェクションに対して無防備だ、というものだ。
研究者はこう表現している——「VBSエンクレーブは鉄壁。問題は暗号でも認証でも PPL でもない。復号済みのコンテンツを保護されていないプロセスに渡して表示させていることだ。金庫の扉はチタン製。でも隣の壁は石膏ボード」と。
Microsoft の反論は「認証後にアクセスできる設計は文書化されており、その挙動は意図通りだ」というもの。つまり論点は「バグか仕様か」ではなく、「その仕様設計が十分に安全か」にある。
アーキテクチャの本質的なトレードオフ
Microsoft が 2024 年に公開した設計説明によれば、スナップショット操作と復号は「信頼されたエンクレーブサービス」が担い、「信頼されていない Recall UI」にはユーザーが要求したデータのみが認証後に渡される、とされている。つまり Microsoft 自身が UI を「信頼されていない（untrusted）」と位置づけた設計だ。
これは実用的な UI 体験を提供するための合理的なトレードオフと見ることもできる。しかし「信頼されていないプロセスに復号済みデータを渡すことがどこまで許容されるか」という問いへの答えは、組織のリスク許容度によって大きく変わる。
日本のIT現場への影響
現時点で Recall を積極展開している日本企業は少数派だが、Copilot+ PC の普及とともに今後は検討対象として浮上してくる。IT 管理者として押さえておきたいポイントは3点だ。
- 現時点では Recall をオプトインしないのが最もシンプルな判断。機能を有効化しなければ攻撃対象にならない
- グループポリシーおよび Intune による Recall 無効化が可能。「禁止」より「情報システム部門が承認したユースケース以外では無効」という管理ポリシーが現実的
- 「認証が通れば安全」は出発点に過ぎない。ゼロトラストの観点では認証後の動作も脅威モデルに含めて設計する必要がある
筆者の見解
Microsoft が「意図した設計通り」と主張するのは、技術的には間違っていないかもしれない。しかし「仕様であるか否か」と「その仕様が十分に安全か」は、まったく別の問いだ。xaitax の指摘の核心は「設計の選択への異議」であり、それは今後も続く正当な議論だと思う。
VBS エンクレーブの強固さはよくわかる。暗号と認証の部分は本当によくできている。だからこそ「その後の UI 層まで一貫して保護する」設計まで踏み込んでほしかった、という気持ちがある。技術力があるからこそ、もう一歩先を期待してしまう。
Recall の構想自体は面白い。過去の作業コンテキストを自然言語で呼び戻せる体験は、実際に使えれば確かに便利なはずだ。セキュリティ設計がより堅牢になり、プライバシーへの懸念が払拭された時には、胸を張って推奨できる機能になってほしい。今回の議論がその完成度を高める契機になることを期待している。
出典: この記事は Microsoft Says Windows Recall Behavior Matches Intended Design の内容をもとに、筆者の見解を加えて独自に執筆したものです。