Googleは同型暗号を用いてプライベートAIを実用化しています

2026年8月15日原文(blog.google)

概要

Googleが新たにHEIRコンパイラをPrivate Computing Toolkitに追加
Homomorphic encryption により暗号化データ上でAI推論が可能
HEIRはオープンソースで非専門家でも利用しやすい設計
多くの研究機関や企業と共同研究・開発を実施
実用的なアプリケーション例も公開

HEIRとHomomorphic Encryptionの革新

HEIR はGoogleが開発した オープンソースコンパイラ
- Homomorphic Encryption Intermediate Representationの略称
- 暗号化データ上で直接AI推論を実現
Homomorphic encryption の特徴
- データを復号せずに計算処理が可能
- サーバーは暗号化されたままのデータを処理し、結果も暗号化されたまま返却
- 利用者のプライバシーやサービスプロバイダーの知的財産を保護
従来の課題
- エンドツーエンド暗号化ではサービス提供者がデータにアクセスできず、機能提供が制限
- ローカル処理では端末性能や知的財産流出リスクが問題
Homomorphic encryptionの進化
- コストが急速に低下
- プライバシーと機能性のトレードオフを再定義

HEIRプロジェクトの特徴とパートナーシップ

HEIR は既存AIモデルを暗号化入力対応へ自動変換
- 暗号化推論導入のハードルを大幅に低減
- 非専門家でもワンクリックで利用可能を目指す
パートナー企業・研究機関との連携
- Belfort, Niobium, Cornami, Optalysysなどハードウェアアクセラレータ企業と協業
- Georgia Tech, Carnegie Mellon, UC Santa Barbara, Illinois Institute of Technology, Purdue, University of Edinburgh, Tsinghua Universityなどと共同研究
- 既に4本の査読論文がHEIR上で発表、今後も増加予定
HEIRは研究プラットフォームとしても活用
- 最適化やベンチマーク、比較研究の基盤を提供

HEIRの実用アプリケーション例

Deep Learning Recommendation Model
- Belfort Labs、LG、New York Universityと共同開発
- プライベートなコンテンツレコメンデーションを実現
クレジットカード不正検出
- Niobium、hardshell.aiと共同で不正検出器をコンパイル
ネットワーク脅威侵入検知
- Niobiumと共同でKitsuneシステムを暗号化トラフィック解析対応に
- パケット内容を開示せず異常検知が可能
Hotword Detector
- Belfort Labsと共同開発
- 音声トリガーAIエージェントが録音内容のプライバシーを保護しつつホットワード認識

今後の展望

ソフトウェア産業全体でのセキュリティ・プライバシー対応強化
Homomorphic encryptionの開発容易化・高速化・普及を推進
さらなる実用例とパートナーシップ拡大を計画

Hackerたちの意見

私の修士論文はこの分野（プライバシー保護型機械学習）についてなんだけど、私の理解ではHEや他の技術は推論タスクに対して非常に高いオーバーヘッド（約10^3）を持っているから、商業的にはあまり実用的じゃないんだよね。

└

まさに私の懸念だし、私が思っていたよりも悪いオーバーヘッドだね。コスト的に見ても、実用的なプライベートコンピューティングはローカルコンピューティングだけだよ。クラウドより高いけど、クラウドでの真のプライベートコンピューティングは確実にもっと高い。

└

1000倍の遅延は悪いけど、完全に致命的ってわけじゃないね。実現可能なファクターってどれくらいだと思う？それに、そこに到達するまでどれくらいかかるかの感覚はある？

└

記事はその点についてあまり詳しく触れてないね。ちょっとAIで調べてみたけど（リンクされたページをサクッとカバーするために）、得られるベストな数字はこのarxivの論文からみたいだね: https://arxiv.org/html/2506.18150v4 そこには「HE-LRMをUCI（健康予測）とCriteo（クリック予測）で評価し、UCIでは24秒、Criteoでは228から489秒の推論遅延を達成した」と書いてある。直接の比較はないみたいだけど、普通の技術では誰も一つのスレッドのCPUに制限する理由がないからだと思う。AIは、通常のセットアップではミリ秒単位の時間が期待されるって言ってた。クリーンな一次情報を見つけられなかったけど、色々クリックしてみた感じでは信憑性はありそうだった。だから、まだ1桁のオーダーで遅い状態、もしかしたら5か6倍遅いかもしれない。つまり、差の対数を取らないと意味のある数字が出ない範囲にいるってこと。パーセントは使ってないよ。（自分で実行するには、HNのリンクからURLを入れて、FHEが遅いことは知られているって言って、ブログ記事にリンクされてるもので具体的な時間が出てるか聞いた。）

└

それがHEIRのような最適化やパラメータ選択の理由だね。10^3から10^6のペナルティを10倍から100倍に絞り込むんだ。

└

それって根本的な限界だと思う？それとも時間と新しいアルゴリズムで改善されるものかな？

└

Googleにとって商業的に実行可能かどうかは、広告の行動をそれに帰属させられるかどうかにかかってる。それから、広告収益を生むかどうかは名目上は重要じゃない、ただその仕組みを回すための二次的な要素がある。Googleでこれをやってるチームは見せかけだけで、実際の製品にはこれが入ることはない。プライバシーを守るMLやフェデレーテッドラーニングを使ってるgboardのような狭い例外はあるけど、これは同じゾーンにはない。正直、Googleがこういうのを発表するのはちょっと恥ずかしいと思ってる。

└

FHEの「128ビットセキュリティレベル」での実際の最新の数字を出すと、普通のデスクトップPCで8つの8ビット符号なし整数をソートするのに、結果が出るまで3秒待つことになる。32個の8ビット符号なし整数をソートしたい？34秒後に結果が出てくるよ。更新: TFHE-rsライブラリを使った原始的な符号なし64ビット整数操作のベンチマークについては[2]も見てね（[1]のソート性能比較での勝者）。等価性は80ms、加算と減算は100ms、除算は8秒、などなど。[1] https://eprint.iacr.org/2026/1495.pdf 「完全同型暗号下の無知ソート：包括的な調査と性能分析」、オマール・アフメド、ロスティン・ショクリ、ネクタリオス・ジョルギオス・ツーツォス、2026年 [2] https://docs.zama.org/tfhe-rs/tfhe-rs/1.0/get-started/benchm...

└

スピードアップの主な道は、NiobiumのようなスタートアップによるカスタムASICにあるみたい。最近のAMDによるTaalasの買収と組み合わせると、これがどうなるか見えてきた気がする。でも、ホットパスのトラフィックは入力データレートに圧倒されるだろうね。ただ、アイデンティティテーブルやキャッシュされたルックアップデータはコアコンポーネントになる必要があると思う。そうすれば、重複チェックをあらゆる方法で避けられるから。

└

私が待ってるのは、バックエンドにFHEを使って完全にプライベートな女性の生理追跡アプリだよ。

これが、デフォルトでパスワードマネージャーにエンドツーエンド暗号化がないGoogleなんだよね。マジで、パスワードマネージャーなのに。

└

ちょっと考えれば、普通のユーザーはそんなの望んでないって気づくよ。

Hacker Newsで議論の続きを見る

ハクソク