9月4日、GoogleエンジニアのJeremy Kunが「Updates on HEIR, the homomorphic encryption compiler project」と題した記事を公開した。Googleが開発する準同型暗号コンパイラ「HEIR」の現状と今後のロードマップについて、実測値を交えながら率直に語った内容だ。
生成AIの普及でサーバーサイド推論が当たり前になった今、「自分のデータをサービス事業者に見せたくない」というユーザーの懸念は根強い。TEE（Trusted Execution Environment）やオンデバイスMLといった既存のアプローチと異なり、HEIRが目指すのは「暗号化したまま推論する」という数学的な保証だ。サーバーは入力・出力・中間値のいずれについても元のデータを一切知ることができない。技術的には夢のような話だが、現実のパフォーマンスはどこまで来ているのか。
HEIRとは何か
HEIR（Homomorphic Encryption Intermediate Representation）は、通常のプログラムを「暗号化されたデータの上で直接動作するプログラム」へと変換するコンパイラだ。基盤となる準同型暗号（Homomorphic Encryption、以下HE）は、暗号文のまま加算・乗算などの演算を行える暗号方式で、復号せずに計算できる点が従来の暗号技術と根本的に異なる。
HEIRはLLVMプロジェクトの多段階中間表現フレームワークMLIRを基盤に構築されており、PyTorchやJAXで学習済みのモデルをHE上で動作するコードへとコンパイルする。開発者のJeremy KunはGoogleのエンジニアでMLIRコミッターでもあり、今回の記事ではGoogle Securityブログと同時に4つのデモを公開した。
実際の性能：クレジットカード不正検知モデルで見る現実
最もシンプルなデモが、クレジットカード不正検知モデルだ。シグモイド活性化関数を持つ3層のフィードフォワードネットワーク（層のサイズは128・64・2）で、Kaggleのデータセットで学習済みのモデルを使う。
実行は1コマンドで完結する：
bazel run -c opt //demos/cc_fraud/lattigo:evaluate_fhe
出力の一部：
Running FHE evaluation (preprocessed)...
Took 2.020821739s
Decrypted logits: [16.464235 -16.781752]
Predicted class: 0
SUCCESS: Predicted class matches expected label!
同じ推論を平文で実行した場合のレイテンシは0.5ミリ秒。HEでは約2秒かかり、約4,000倍の遅延が生じる。これはシングルスレッドCPU・非バッチ実行という条件下での数字だ。
ただし、このデモにはいくつかの注釈がある：
- モデルが小さく、入力データが単一のCKKS（浮動小数点演算に対応したHEスキームの一つ。実数値の計算を近似的に暗号化したまま行えるため、ML推論との相性がよい）暗号文に収まる。要素数が32,000を超えるテンソルでは複数の暗号文が必要になり、オーバーヘッドも増大する
- ブートストラッピングが不要な規模のモデルである。ブートストラッピングとはHEで最も重い処理の一つで、計算の連鎖によって増大するノイズをリセットする操作だ。これが必要になるとレイテンシは跳ね上がる
- ネットワーク遅延やユーザーごとの鍵生成コストは含まれていない
より複雑なモデルでは状況はさらに厳しくなる：
network_anomaly（オートエンコーダのアンサンブル）：推論に30秒criteo（レコメンダーモデル）：推論に5分、メモリ60〜90GiB必要hotword（10層の畳み込みネットワーク）：推論に20分
一方でGPU活用の報告もある。criteoモデルはH100相当のGPU1枚で約500ミリ秒まで短縮できたとのことで、平文の10ミリ秒と比べると50倍の遅延にまで縮まる。FPGAやASICによる高速化も研究されており、さらなる改善が期待されている。
デバッグ・マルチバックエンドなど実用的な機能
HEIRはコンパイル後のプログラムにデバッグコールバックを挿入できる。たとえば：
- レイヤーごとのタイミング計測：
evaluate_fhe_timingを実行すると、最初の線形層が全体の約60%（2秒中1.2秒）を占めることが確認できる - 精度損失の検査：
evaluate_fhe_debugを実行すると、HEによる演算で推論終了時点で約2ビットの精度損失が発生していることがわかる。この損失はコンパイラフラグで調整可能だが、トレードオフの判断にはHEの専門知識が必要だ
バックエンドは複数をサポートしており、Lattigo（Go実装）とOpenFHE（C++実装）を切り替えて比較できる。
モデルをHEIRに取り込む流れ
現時点では、学習済みモデルをHEIRで処理できる形式に変換するプロセスは自動化されていない。主な制約は2つだ：
- モデルをHEIRの中間表現であるMLIR形式に変換する必要がある。PyTorchにはtorch-mlir、JAXにはXLAを介した変換ツールが存在する
- どの入力が秘密か、および各活性化関数への入力の範囲の上界を手動でアノテーションする必要がある
Kunはtorch-mlirのメンテナーと協力し、検証セットを使って範囲推定を自動化する機能の追加に取り組んでいる。ONNXやJAXのサポートについては、現時点では完全には動作しない。
HEが本当に役立つのはどんな場面か
Kunは「HEのキラーアプリは何か？」という問いに率直に向き合っている。学術界では「プライベートLLM推論」と答えるケースが多いが、現状の最先端でも1トークンあたり数秒のレイテンシを要し、クライアントとの往復通信も必要なため、実用にはほど遠い。
Kunが注目するのは「今日のHEで対応できるアプリケーション」だ。その条件として挙げているのが以下の観点だ：
- 「2020年水準のモデル」で事足りるドメイン：畳み込みネットワークがまだ主流な領域は多く、巨大なトランスフォーマーが不要なタスクであれば、HEは現実的な選択肢になる
- 双方にとって機密性が重要なケース：ユーザーのデータだけでなく、サービス側のモデル・ビジネスロジックも保護したい場面（例：独自モデルを外部APIで公開したくない場合）
TEEと比べたHEの強みはまさにここにある。TEEはハードウェアベンダーへの信頼が前提だが、HEは数学的な保証であり、ハードウェアに依存しない。ただし、そのコストは現状では無視できない水準にある。「完璧なプライバシーには相応の代償がある」というのが、Kunが記事全体を通じて伝えているメッセージだ。
コンパイラのインターフェースの現在地
HEIRのインターフェースはclangよりLLVMに近い。heir-optとheir-translateという2つのバイナリが最適化とコード生成を担い、それをBazelルールrules_heirでラップする構造だ。
Pythonフロントエンドとしてheir-pyも存在するが、現時点では機械学習とは無関係で、Pythonバイトコードの限られたサブセットをHEにコンパイルする実験的な段階だ。将来的には、より単純なフラグ体系（-O2相当）を持つclangスタイルの製品に統合することを目指している。
詳細はUpdates on HEIR, the homomorphic encryption compiler projectを参照していただきたい。
