2026年6月、米マイクロソフトが満を持してプレビュー公開したWindows 11の「Recall（リコール）」機能。数秒ごとに画面をキャプチャし、AI（ローカルNPU）を用いて過去のあらゆる操作を検索可能にするというこの機能は、発表直後から世界中のセキュリティコミュニティを巻き込む大炎上へと発展した。当初、オプトアウト（デフォルト有効）で提供される予定だったこの機能は、世論の反発を受けてセットアップ時のオプトイン必須化、Windows Hello認証の強制、そしてキャプチャデータの暗号化強化という防衛策を余儀なくされ、最終的にプレビュー提供自体が延期される事態となった。ゲームやインフラ、セキュリティの変遷を30年見守ってきた一人のエンジニアとして言わせてもらえば、これは単なる「配慮不足」のレベルではない。現代のOSベンダーが陥った「常時監視」という傲慢な思想が生んだ、必然の迷走である。
Windows 11 Recall機能がもたらすプライバシーの崩壊――セキュリティ後退の現実とユーザーの激怒
画面キャプチャをSQLiteで平文保存していたなんて信じられない。完全にトロイの木馬をOSに内蔵するようなものだ！
Hello認証を必須にして暗号化するなら利便性は勝るかもしれないが、そもそもMicrosoftを100%信用できるかが問題だ。
Recallは、PCの画面上でユーザーが見たすべての内容（テキスト、画像、アプリ操作など）を数秒おきに自動でスナップショットとして記録し、それをローカルAIモデルで処理して「あの時見ていたウェブサイト」や「数時間前にチャットした内容」を自然言語で検索できるようにする機能だ。マイクロソフトは「すべてのデータはデバイス上で処理され、クラウドには送信されない」と安全性を強調していた。
しかし、初期のプレビュー版を解析したセキュリティ研究者たちによって、キャプチャされたテキストデータがユーザーのローカルフォルダ内（`AppData`配下）のSQLiteデータベースファイルに、**暗号化すらされずに平文（プレーンテキスト）のまま保存されている**ことが暴露された。これは、万が一PCがマルウェアに感染した場合、あるいは他人が数分間PCに物理アクセスしただけで、過去のログインパスワード、クレジットカード情報、プライベートなメールなど、すべての個人情報が一瞬で盗み出されることを意味する。コミュニティが激怒し、スパイウェアと変わらないと糾弾したのは当然の帰結だった。
ここが面白い：技術的背景とオールドエンジニアの回顧劇
技術的に見れば、Recallのセキュリティ構造の最大の欠陥は「特権昇格なしでのデータアクセス権限」の設計の甘さにあった。初期バージョンでは、スナップショットから光学文字認識（OCR）によって抽出されたテキストが保存されているSQLiteデータベースファイルに対し、現在のログインユーザー権限を持つプロセスであれば、管理者権限（Admin）を要求されることなくアクセス可能だった。つまり、Webブラウザの脆弱性を突いて実行された悪意あるJavaScriptや、ユーザー権限で動作する一般的なソフトが、コマンドライン一つでデータベースを丸ごとコピーできてしまう状態だったのである。マイクロソフトはこの欠陥に対し、Windows Helloの生体認証をデータベースの解読キー（暗号化鍵）に紐付け、アクティブなユーザーセッション中のみデータをメモリ上で解読する仕様へと変更を余儀なくされた。
ここで、オヤジの昔話をさせてもらいたい。今から20年以上前、2000年代初頭のWindows XP時代、私たちは「Blaster（ブラスター）」や「Sasser（サッサー）」といったワーム（自己増殖型マルウェア）の猛威に直面していた。当時のWindowsはネットワークセキュリティの概念が極めて脆弱で、インターネットにPCを直接接続しただけで、TCP 135番ポートなどを経由して外部から勝手にコマンド実行され、画面に「システムは60秒後にシャットダウンされます」というダイアログが表示されて強制終了するパニックが世界中で発生していた。深夜のサーバルームで、冷や汗を流しながらファイアウォールの設定を確認し、ルーターのACL（アクセス制御リスト）をアセンブラのような泥臭さで書き換えていたあの胃の痛い日々が昨日のことのように思い出される。また、当時は「Back Orifice」や「SubSeven」といった遠隔操作ツール（トロイの木馬）が流行しており、攻撃者にデスクトップのキャプチャ画像をリアルタイムで覗き見られることの精神的恐怖を、当時のエンジニアは身を以て知っていたのだ。Recallという機能は、あの頃私たちが必死で駆逐してきた「デスクトップキャプチャ型スパイウェア」の機能を、OSの公式標準機能として自ら埋め込むような暴挙に他ならない。
もう一つ、ハードウェアリソースの観点からも技術的パラドックスが存在する。VRAMが1MBや2MBしかなく、CPUが数百MHzだった時代、画面全体のビットマップ（フレームバッファ）をキャプチャして保存・転送することは、システム全体のメモリ帯域幅を飽和させ、PCを確実にフリーズさせる超重量級の負荷処理だった。しかし現代では、毎秒数ギガバイトの帯域を持つ超高速なメインメモリと、専用のNPU（ニューラルプロセッシングユニット）を積んだハードウェアが平然とそれをやってのける。ハードウェアの進化が、「本来やってはならないはずの常時監視と画面収集」を可能にしてしまったのだ。しかし、いくらNPUが効率的に動作しようとも、数秒ごとのキャプチャ処理はストレージ（SSD）の書き込み寿命（TBW）を摩耗させ、微小ながら常にCPU/GPUのリソースを消費し続けるボトルネックであることに変わりはない。
ハンズオン：Windows Recallの技術的検証と無効化設定
ここで、現場のエンジニアや管理者向けに、Recallの技術的特性を確認するためのハンズオン実例を提示する。
1. 当初問題となった「SQLiteデータベース」からの情報抽出（概念検証）
初期プレビュー版において、RecallのOCRテキストデータが保存されていたデータベース（`UkLog.db`）から、ログインパスワードや機密情報を含みそうなレコードをSQLで直接抽出するクエリの例だ。管理権限なしでこれが実行可能だったことの異常さが理解できるだろう。
-- Recallのデータベースからパスワードやクレジットカードと思われるテキストを抽出するクエリ
SELECT
datetime(CaptureTime / 10000000 - 11644473600, 'unixepoch', 'localtime') AS LocalTime,
ApplicationName,
WindowTitle,
OcrText
FROM CapturedData
WHERE OcrText LIKE '%password%'
OR OcrText LIKE '%credit%'
OR OcrText LIKE '%API_KEY%'
ORDER BY CaptureTime DESC;
2. PowerShellを用いたシステム全体でのRecall（AI分析）強制無効化
企業のシステム管理者や、個人環境でRecall機能をレジストリ層から確実に無効化するためのPowerShellコマンドである。グループポリシー（GPO）で「WindowsAIデータ分析の無効化」を設定する処理と同等のレジストリ操作を行う。
# 1. WindowsAIデータ分析用のレジストリキーが存在しない場合は作成
$RegistryPath = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsAI"
if (!(Test-Path $RegistryPath)) {
New-Item -Path $RegistryPath -Force | Out-Null
}
# 2. DisableAIDataAnalysis (AIデータ分析の無効化) を「1」(無効) に設定
Set-ItemProperty -Path $RegistryPath -Name "DisableAIDataAnalysis" -Value 1 -Type DWord
# 3. 反映確認
$CurrentValue = Get-ItemProperty -Path $RegistryPath -Name "DisableAIDataAnalysis" -ErrorAction SilentlyContinue
if ($CurrentValue.DisableAIDataAnalysis -eq 1) {
Write-Host "[SUCCESS] Windows Recall (AI Data Analysis) has been forcefully disabled." -ForegroundColor Green
} else {
Write-Warning "[ERROR] Failed to disable Windows Recall."
}
この話題をどう見るか？：現実的な視点と利用価値
日本の一般的なユーザーやオフィス環境において、このRecall機能をどう評価すべきか。マイクロソフトは「仕事の生産性が劇的に向上する」と謳うが、現実のビジネス現場への導入を考えると、そのリスクは利便性を遥かに凌駕する。例えば、多くの日本企業では、個人情報保護法や社内コンプライアンスの観点から、業務PCの画面に顧客の個人情報、暗号キー、あるいは他社との守秘義務（NDA）に関わる未公開情報を表示させながら作業を行っている。Recallがこれらの機密画面をすべて自動でスナップショットとして保存し続ける以上、そのPCは「歩く情報漏洩の爆弾」と化す。インサイダー取引の嫌疑をかけられかねない証券取引データや、医療従事者のカルテ画面がローカルとはいえ自動保存されることを許容できるセキュリティ責任者は、日本の組織にはまず存在しないだろう。
また、日本特有の住宅・オフィス事情（特にディスプレイの覗き見や物理的近さ）を考慮すると、セキュリティの穴はシステム的なものだけに留まらない。離席時に画面ロックをかけ忘れた僅か数分間に、他人がRecallを使って過去の行動履歴を全てスライドショーで遡るという「物理的なソーシャルエンジニアリング」に対する脆弱性は極めて深刻だ。マイクロソフトが慌てて「離席時にはHello認証を再度要求する」などの仕様に変更したのは、この「物理アクセス時のリスク」を無視できないと悟ったからに他ならない。
さらに、実用面での価値を冷徹に批評すれば、Recallが提供する「曖昧な過去の検索」という体験は、多くのPCワーカーにとって「あれば便利かもしれないが、必須ではない」というレベルのものだ。まともなエンジニアであれば、重要な情報はGitのコミットログ、ドキュメント管理ツール（NotionやWiki）、あるいはブラウザのブックマークで管理している。自分の曖昧な記憶とスローなAI検索に頼らなければ過去の作業に辿り着けないような散らかったワークフロー自体が、プロフェッショナルとしては二流の証だろう。Recallをオプトインしてまで得られる時間短縮効果は、セキュリティ上の巨大なバックドアを開くリスクと釣り合っていないのである。
導入・試す前の実用メモ
- 確認点：ハードウェア（Copilot+ PC）の物理要件
Recallを利用するには、最低40 TOPS以上の処理能力を持つNPUを搭載したプロセッサ（Snapdragon X Elite/Plusや、Intel Core Ultra 200Vシリーズなど）を搭載した「Copilot+ PC」仕様の最新ハードウェアが必要となる。古いPCに無理やりRecallのバイナリを移植して動かすハックも存在するが、NPUの恩恵を受けられないためCPU負荷が激増し、実用には程遠いことを理解しておくべきだ。 - 落とし穴：暗号化を過信した「マルチユーザー環境」での共有
Windows Hello認証によってデータが暗号化されるようになったとはいえ、同一のWindowsログインアカウントを家族や同僚と共有して使用している場合、この暗号化の境界線は意味をなさない。アカウントにログインしている状態であれば、誰でも他のユーザーの過去の行動履歴（検索ワードやメール閲覧履歴）にアクセスできてしまう。共有PCでのRecallの有効化は絶対避けるべき落とし穴だ。 - 選択のヒント：今すぐ機能を完全に封印すべき人
金融関連の業務、ソースコードの記述（特に外部サービスへのアクセスキーやAPIキーをコード内に直接入力してデバッグする場面がある開発者）、医療データのハンドリングなどを行うプロフェッショナルは、Recallの機能がプレビューとして再提供されたとしても、初期セットアップで「オプトアウト」し、さらに前述のPowerShellなどでポリシーレベルから完全にこの機能を無効化しておくべきである。
総括：現場のエンジニアとしての導入意思決定
一人のソフトウェアエンジニアとして、またセキュリティに関わってきた現場の人間としての決定を示す。このWindows 11 Recall機能について、利用可能な状態になった際にオンにすべきか。私の答えは、**「絶対的なオプトアウト（強制無効化）」**である。技術的にどれほどHello認証で暗号化を施そうとも、OSが数秒おきに画面の魚拓を取り続けるという「仕組み自体」が構造的なリスクだからだ。
マイクロソフトがこの機能をデフォルト有効のまま出荷しようとした姿勢には、顧客のプライバシーに対する致命的な鈍感さと、自社のAIエコシステム普及に対する焦りが透けて見える。プレビュー延期という判断を下したことで一応のブレーキはかかったが、一度失われた信頼を回復するのは容易ではない。セキュリティは常に「性悪説」で設計されるべきであり、「ローカルにあるから安全」「マイクロソフトが保証するから安全」という他力本願な信頼は、牙を剥くハッカーたちの前では無力である。
道具を選ぶとき、私たちは「その道具がもたらす便益」と「背負うことになるリスク」の天秤を常に水平に保たなければならない。Recallは、わずかな検索の利便性のために、自分のPCの中に「完璧に整理されたプライバシー情報への裏口」を自ら掘る行為に他ならない。仕事が終わった夜、市川市の自宅近くで愛犬を連れて散歩しながら、かつてBlasterワームと格闘して徹夜した日々を思い返し、私たちは利便性の甘い罠に対し、常により懐疑的で、泥臭い自己防衛を続けなければならないのだと、改めて自戒している。
広告・アフィリエイトリンクを含みます。商品選定は記事内容との関連性を優先しています。
関連アイテム
