2026.08.24 セキュリティ

Google HEIRとは？暗号文のままAIモデルを動かすコンパイラの仕組みと採用判断

顧客のデータを外へ出さずにAIで判定したい、という相談は増えています。従来はデータを預ける相手を信頼するか、そもそも預けないかの二択でした。暗号文のまま計算する準同型暗号はその二択を崩す技術ですが、暗号の回路を自力で組む必要があり、実装できるチームは限られていた。Googleが2026年8月に打ち出したHEIRは、そこへコンパイラを挟む道具です。本記事では、HEIRが何を引き受けて何を利用者へ残すのか、最小構成でどう動かすのか、公表されている性能をどう読むのか、そして今の段階で試す価値がある業務はどこかを実装者の手順として並べていきます。

まとめ｜HEIRの検討で先に押さえる三つの前提

結論から書きます。HEIRは暗号方式そのものではなく、学習済みのモデルを暗号文の上で動く形へ書き換えるコンパイラです。方式の選択や値の詰め方といった暗号側の設計判断を道具の側が引き受けるため、暗号の専門家を抱えていない開発チームでも入口には立てる。

二つ目は、公表されている性能の土台が単一スレッドのCPUだという点です。専用半導体との組み合わせで分からミリ秒へという見立ては示されていますが、その実証は近日という段階にとどまります。手元の業務要件へ当てはめるなら、まず自分の環境で測った数字を持ってください。

三つ目は、対象を選べば今日から試せる一方、対話型の生成AIをそのまま暗号化する構想には現時点で届かないことです。入力が小さく、推論の回数が限られ、出力が数値や分類に収まる処理から当たるのが現実的だと考えています。暗号方式そのものの成り立ちは準同型暗号とは？その定義、歴史、そして基本的な概念で扱っているので、方式側の前提はそちらを土台にしてください。

Google HEIRとは何か｜暗号文のまま推論するためのコンパイラ

HEIRはHomomorphic Encryption Intermediate Representationの略で、完全準同型暗号を対象にしたコンパイラツールチェーンです。土台にはLLVM系の中間表現基盤であるMLIRを使っており、複数の抽象度を段階的に下げていく構成を取ります。

2026年8月の発表で変わった点｜研究者向け基盤から実装の導線へ

Googleがこのプロジェクトの開始を表明したのは2023年8月で、当初の位置づけは暗号研究の共通基盤でした。各所の研究者が個別に書いていたコンパイラの土台を一本化し、比較や再実装の手間を減らす狙いです。実際に複数の大学が参加し、論文の実装を移植する場として使われてきました。

2026年8月14日の発表で前に出たのは、平文を前提に学習させたモデルを暗号化された入力で動く形へ変換できるという点です。書き手が暗号の回路を組む作業を、道具の側が引き受ける方向へ寄せた形になります。

提示された用途は四つで、推薦モデルによる配信、クレジットカードの不正検知、ネットワークの脅威検知、そして音声の起動語検出でした。いずれも入力が個人に紐づく一方、モデル提供側が中身を見る必要のない処理という共通点があります。

準同型暗号との関係｜方式そのものではなく方式を使うための道具

混同を避けたいのはここです。準同型暗号は暗号文のまま加算や乗算を実行できる方式の総称で、HEIRはその方式を呼び出すコードを生成する側にあたります。方式の実装そのものは外部のライブラリが担う。

したがって、HEIRを入れれば暗号が強くなるという理解は当たりません。強度を決めるのは選ばれた方式とパラメータであり、道具の役目はその選択を機械的に決めて回路へ落とすところにあります。鍵の配送や移行計画といった運用側の話はハイブリッド暗号方式とは？仕組みとPython実装・PQC移行で整理しました。

対応するスキームとバックエンド｜四つのライブラリへ書き出す構成

2026年8月時点の対応表では、OpenFHEとLattigoがBGV・BFV・CKKSの三方式を受け、tfhe-rsとJaxiteがCGGIを受けます。整数演算を束ねて処理したいならBGVやBFV、実数の近似演算を回したいならCKKS、任意の関数を表引きで扱いたいならCGGIという住み分けです。

公式サイトの記載では、方言と呼ばれる中間表現の層は30を超えます。出力先としてGPU・TPU・FPGA・ASICが挙げられており、ソフトウェアのライブラリだけを相手にした構成ではありません。

ひとつ注意しておきたいのは、リポジトリの説明文に公式サポート対象の製品ではないと明記されている点です。試作や検証には足りますが、事業の継続性を前提にした調達物として扱うなら、その但し書きを社内へ先に共有しておいてください。

バックエンド	対応方式	向く処理
OpenFHE	BGV・BFV・CKKS	整数と実数の演算
Lattigo	BGV・BFV・CKKS	Goで組む推論経路
tfhe-rs	CGGI	表引きと分岐処理
Jaxite	CGGI	並列演算機での実行

HEIRのコンパイル経路｜Pythonの注釈から暗号回路までの流れ

実装者にとっての要点は、どこまでを人が書き、どこからを道具が決めるのかという線引きです。三つの層に分けて見ていきます。

フロントエンド｜秘密のまま扱う引数を型の注釈で指定する書き方

入口は通常のPythonコードです。書き手がやることは、関数の引数のうち暗号文のまま扱うものへ型注釈を付けることに尽きます。

from heir import compile
from heir.mlir import I64, Secret

@compile()
def dot(x: Secret[I64], y: Secret[I64]):
    return x * y

デコレータの既定はBGV方式とOpenFHEバックエンドで、指定を足せば方式や出力先を切り替えられます。公式サイトはフロントエンドとしてTorchも挙げているため、学習済みモデルを取り込む経路も用意されている形です。

中間表現と変換パスの役割｜方式選択と値の詰め方を機械が決める

注釈の付いたコードは、秘密の値を扱う抽象度の高い表現へ一度落とされます。そこから方式ごとの表現へ段階的に変換され、最終的に暗号ライブラリの呼び出し列になる。

この途中で道具が決めているのは、方式の選択、演算を暗号文の算術へ組み替える処理、一つの暗号文へ複数の値を詰める配置、そして安全性と誤差の両立を満たすパラメータの決定です。手作業でやると暗号の知識が要る部分で、そこを引き受ける点が売りになっています。

値の詰め方は性能に直結します。暗号文一つが数千の枠を持つため、演算対象を枠へどう並べるかで必要な演算回数が変わる。ここを機械が決めることの意味は、書き手が暗号の内部構造を知らなくても現実的な速度に届き得る、という一点にあります。

バックエンド生成｜暗号ライブラリ向けのコードとして書き出す処理

最後の段階で、選ばれたライブラリ向けのソースコードが出力されます。OpenFHE向けならC++のヘッダと実装、CGGI系ならRustやJAXの経路という具合です。

出てくるのは呼び出し列なので、既存のアプリケーションへ組み込む作業は通常のライブラリ利用と大きくは変わりません。鍵の生成と保管、暗号文の受け渡し、復号する場所の設計は自前で決める領域として残ります。

HEIRを最小構成で動かす手順｜導入から鍵生成と復号までの一往復

読むより一度通したほうが早い種類の道具です。最小の経路を示します。

導入方法の選び分け｜pipとBazelと事前ビルド版の使いどころ

導入は四系統あります。手早く試すならPythonパッケージ、既存のビルド体系へ組み込むならBazelとrules_heir、コマンド行の道具だけ欲しいなら夜間ビルドの配布物、内部を改造するならソースからのビルドです。

pip install "heir_py[python,openfhe]"

暗号ライブラリ側の導入が別途要る点には注意してください。OpenFHEを使う構成では、そのビルド環境を先に整えておく必要があります。

Python版で一往復する｜鍵生成から復号までの呼び出しの順序

コンパイル済みの関数には、鍵の準備と暗号化と復号の入口が生えます。順序はいつも同じです。

dot.setup()
a = dot.encrypt_x(7)
b = dot.encrypt_y(8)
print(dot.decrypt_result(dot.eval(a, b)))

鍵の生成は初回だけ走らせ、生成物を保管して使い回します。ここで体感してほしいのは、演算の実行そのものより鍵の生成と暗号文の大きさのほうが効いてくるという感覚です。平文なら一瞬の掛け算に、桁違いの時間と容量がかかる。

コマンド行から扱う場合｜heir-optとheir-translateの分担

中間表現を直接触る場合は、道具が二本に分かれます。変換パスを適用するのがheir-opt、バックエンドのコードを書き出すのがheir-translateです。

heir-opt --mlir-to-bgv='min-slot-count=8' input.mlir
heir-translate --emit-openfhe-pke output.mlir

パイプライン指定にはCGGIへ落とす経路やループを展開する処理、並列演算向けに並べ替える処理などが並びます。どの段階でどんな表現になっているかを見られるので、速度が出ない原因を追うときはこちらの経路が要る。

実用コストをどう見るか｜評価が割れている論点を三つに切り分ける

この技術の評価は、期待と懐疑の幅が大きい領域です。数字の読み方を三つに分けます。

単一スレッドのCPUという前提｜性能比較の土台を先にそろえる

発表資料に並ぶレイテンシは、単一スレッドのCPUを土台にした値だと明記されています。並列化や専用機材を前提にした数字ではありません。

この前提を落として読むと判断を誤ります。逆に言えば、素のCPU一本でこの水準という読み方をすれば、改善の余地がどこにあるかは見通しやすい。自社で測るときも、まず一本のスレッドで一件あたり何秒かかるかを取ってから並列化を考えるのが順序として堅い。

専用ハードウェアへの期待値｜分からミリ秒への短縮という見立ての読み方

Googleは暗号処理向け半導体を手がける4社との提携を挙げ、コンパイラがそれらを直接の出力先にできると説明しています。処理時間が分単位からミリ秒級へ下がるという表現もそこで出てきます。

ただし同じ発表の中で、その改善効果の実証は近日という書き方になっている。つまり2026年8月時点では、見立てとして提示された段階です。調達計画へ織り込むなら、実証結果が出るまでは括弧付きで扱ってください。

加えて、専用半導体は入手性と価格が読みにくい。自社のクラウド環境で使える形になるまでの時間差も、計画では見ておく必要があります。

精度と回路の制約｜非線形の処理をどう近似するかという別の課題

三つ目は速度とは別筋の制約です。暗号文の上で素直に回せるのは加算と乗算で、活性化関数のような非線形の処理はそのままでは扱えません。

方式によって対処が分かれます。実数の近似演算を扱う方式なら多項式で近似する、表引きを扱える方式なら値の対応表を引く、といった具合です。前者は近似の誤差が推論結果に乗り、後者は一回の処理が重くなる。

結果として、平文で動いていたモデルをそのまま持ち込めるとは限りません。精度がどこまで落ちるかを検証の最初に測る計画を組んでおくと、後戻りが減ります。

論点	公表されている前提	検証で測るもの
速度	単一スレッドCPU	一件あたりの秒数
専用機材	効果は実証待ち	入手性と単価
精度	非線形は近似が要る	平文との差分
容量	暗号文は平文より大	通信量と保管量

他のプライバシー保護手段との使い分け｜TEEや証明技術との境界

暗号文のまま計算するという発想は選択肢の一つで、目的が近い手段は他にもあります。守備範囲を並べて見ます。

TEEとの違い｜ハードウェアの製造元を信頼するかどうかで分かれる

実行環境を隔離する仕組みは、処理の瞬間だけ平文へ戻します。速度の面では圧倒的に有利で、既存のモデルをほぼそのまま持ち込める点も強い。

代わりに、半導体の製造元と実装を信頼する前提が入ります。準同型暗号はその前提を置かずに済む代わりに、速度と実装の手間を払う構図です。仕組みの中身はTEE（Trusted Execution Environment）とは？仕組みとREEとの違いで解説しているので、比較する際はそちらと突き合わせてください。

ゼロ知識証明や差分プライバシーとの違い｜守備範囲を分けて見る

証明技術が扱うのは、計算結果が正しいことを中身を明かさずに示す場面です。計算そのものを隠す準同型暗号とは目的が違います。両方を組み合わせる研究もありますが、まずはゼロ知識証明（ZKP）とは何か？基本概念とメリットで守備範囲を確認しておくと選択を誤りません。

統計的に個人を特定させない手法は、出力側にノイズを混ぜる考え方です。入力を隠す発想とは別の層にあたるため、併用する余地があります。なお学習データそのものを汚す攻撃は、暗号では防げない領域として残る。この面はデータポイズニングとは｜学習データ汚染の攻撃手口と防御策で扱っています。

契約と匿名加工で足りる場面｜暗号技術を持ち出さない判断の線引き

正直なところ、多くの案件は暗号を持ち出さずに解けます。委託契約で取り扱いを縛る、識別子を落として渡す、事業者側の保護機能を使うといった手当てで足りる場面が大半です。

事業者が提供する保護の枠組みも整ってきました。生成AI側の扱いについてはOpenAI Privacy Filterの基本仕様とリリース背景のような機能が出ており、まずそちらで要件を満たせないかを確認するのが順序です。

暗号文のまま計算する構成が要るのは、データを預ける相手そのものを信頼できない場合に絞られます。ここを取り違えると、費用と工数だけが増える。

HEIRを採用してよい条件と見送る場面｜検証プロジェクトの組み方

ここは言い切ります。今のHEIRは全社的な導入対象ではなく、条件を絞った検証の道具として置くのが妥当です。

試す価値がある条件｜モデルが小さく推論の頻度が低い業務から選ぶ

条件は三つあります。一つ目、入力の次元とモデルの規模が小さく、推論の出力が数値や分類に収まること。二つ目、応答が数秒から数分待てる業務であること。三つ目、データを預ける相手を信頼できない事情が実在することです。

不正検知の判定や、閾値を跨いだかどうかだけを返す処理は当てはまりやすい。逆に、平文前提の推論APIをそのまま置き換える構想には向きません。通常の推論基盤の構成はモデルサービングとは？推論APIの構成とKServe・Triton・BentoMLの選定基準で扱っているので、比較の基準線はそちらで押さえてください。

見送るべき場面｜対話型の生成AIをそのまま暗号化する構想は避ける

大規模言語モデルの推論を暗号文のまま回す構想は、2026年8月時点では見送りが妥当だと考えています。演算量と暗号文の容量が桁で足りず、対話の応答時間に収まる見込みが立たない。

画像や動画をそのまま扱う処理も同様です。この領域で今できるのは、扱う値を絞った小さな判定処理を切り出し、そこだけ暗号文のまま回す設計に寄せることでしょう。

もう一つ避けたいのが、実証実験の成果物をそのまま本番へ載せる進め方です。公式サポート対象の製品ではないと明記されている以上、運用の継続性は自社で担保する前提になります。

外部の手を借りる境界｜検証の設計と評価をどこから委託するのか

自社で進めやすいのは、対象業務の切り出しと平文側の基準値の測定までです。ここは業務理解が要る反面、技術的な難所ではありません。

判断が割れるのは、方式とパラメータの選び方、近似による精度低下をどこまで許すか、そして測った数字を採用可否へどう翻訳するかという部分です。暗号側の設計とモデル側の評価をまたぐため、経験の差が出ます。検証の設計から数字の評価までを外へ出すなら生成AI開発・AI受託開発のような形で、対象業務と判定基準を先に決めて依頼するのが早い。

逆に、対象業務が定まらないうちに技術検証だけを頼むと、動いたという結果しか残りません。測る対象を自社で決めてから渡すのが無駄がない。

よくある質問

HEIRを使えば暗号の知識がなくてもAIを暗号化できますか？

入口の敷居は確かに下がります。方式の選択やパラメータの決定、暗号文への値の詰め方を道具の側が引き受けるため、暗号の内部構造を知らなくてもコンパイルは通せる。ただし鍵をどこで生成しどこへ保管するか、復号する場所をどう設計するかは利用者側の判断として残ります。精度がどこまで落ちるかの評価も自社の仕事です。専門家が不要になるのではなく、専門家が要る範囲が狭まったと捉えるのが実態に近いところでしょう。

HEIRは無料で商用利用できますか？

オープンソースとして公開されているため、コード自体は入手して試せます。ただしリポジトリの説明文には公式サポート対象の製品ではないと明記されており、不具合対応や後方互換の保証を前提にした調達物とは性格が違う。商用の系へ載せるなら、版を固定して自社でビルド環境を保持し、更新の追随を誰が担うかを決めておいてください。ライセンス条件は導入前にリポジトリ側の記載を確認するのが確実です。

準同型暗号は実用の速度に届いているのですか？

処理の種類によります。小さな判定処理なら現行のCPUでも現実的な範囲に収まる一方、大規模なモデルの推論は依然として桁が足りません。Googleは専用半導体との組み合わせで分単位からミリ秒級へ下がるという見立てを示していますが、その実証は近日という段階です。公表値の土台が単一スレッドのCPUである点も含め、自社の要件で測り直してから判断してください。

HEIRとTEEはどちらを選ぶべきですか？

信頼の置き場所で決まります。半導体の製造元と実装を信頼できるなら、実行環境の隔離のほうが速度も移植性も有利です。その前提を置けない場合、あるいは規制や契約で預け先を信頼しない構成が求められる場合に、暗号文のまま計算する構成が候補に入る。両者は排他ではなく、機微な一部の処理だけを暗号側へ寄せる併用も設計として成立します。

どの方式を選べばよいか分からない場合はどうしますか？

まず既定のまま動かして、精度と時間を測るのが早い。Pythonフロントエンドの既定はBGV方式とOpenFHEバックエンドで、整数演算が中心の処理ならこのままで見通しが立ちます。実数の演算が多いならCKKS、条件分岐や表引きが多いならCGGIへ切り替えて比較する。方式ごとに得手不得手がはっきり分かれるため、机上で決めるより二つ三つ試して数字を並べるほうが結論は早く出ます。