データを暗号化したままAIの推論を動かすという発想は、これまで研究テーマとして語られることが多いものでした。しかしGoogleは2026年8月14日付の公式ブログで、完全準同型暗号（FHE）を使って暗号化されたままAI推論を実行する取り組みを紹介し、その中核を担うオープンソースのコンパイラ・ツールチェーンとして「HEIR」を打ち出しています。本記事では、サーバーサイドやAI開発をリードする立場の読者に向けて、HEIRが何を解決するのか、どのスキームがどんな用途に向くのか、そして導入を検討するときに何を見るべきかを、セキュリティと実務の両面から整理します。

なぜいま暗号化したまま動かすAIが注目されるのか

FHEは、データを暗号化したまま加算や乗算を任意の回数だけ実行でき、最後に復号すると平文のまま計算した結果と一致するという性質を持つ暗号方式です。サーバ側はデータを一度も復号することなく処理を進められるため、機微なデータを秘匿したまま推論や分析を回せます。この性質が、医療や金融のように扱う情報の機密性が高く、それでいて高度な分析を求められる領域と強く結びついてきました。

準同型暗号にはいくつかの段階があります。加算か乗算の片方だけを扱える部分準同型（PHE）、限られた回数の演算だけが可能なsomewhat（SHE）、そしてブートストラップと呼ばれる仕組みでノイズを回復させて任意回数の演算を可能にするFHEです。FHEが「完全」と呼ばれるのは、この任意回数という自由度を確保しているためです。

一方で、AIに応用するうえでの課題も明確です。第一に計算オーバーヘッドが重く、平文での計算に比べて処理コストが大きく膨らみます。第二に実装難度が高く、暗号パラメータの選択やノイズ管理といった専門知識が求められます。第三に対応できる演算に制約があり、比較や分岐、非線形関数といったAIで多用する処理は、近似や工夫を重ねないと素直には表現できません。こうした壁を開発者から見えにくくすることが、ツールチェーンに期待される役割になります。

言い換えると、FHEそのものは理論として成立していても、モデルをそのまま暗号化領域に載せられるわけではありません。どの層を暗号化データ上で計算し、どの演算を近似に置き換えるか、パラメータをどう積み上げるかといった判断が積み重なり、専門チームでなければ扱いにくいものになりがちでした。だからこそ、これらの判断をコンパイラ側に寄せられるかどうかが、実務での普及を左右する分岐点になります。

HEIRがAIモデルのコンパイル時に解決すること

HEIRはHomomorphic Encryption Intermediate Representationの略で、LLVM由来のMLIRを基盤としたFHE向けのコンパイラ兼ツールチェーンです。GitHub上でも自らを準同型暗号コンパイラのためのMLIRベースのツールチェーンと説明しており、ライセンスはApache-2.0で公開されています。狙いは、高レベルなPythonやTorchで書かれたプログラムを、暗号化データ上で動く等価な実装へとコンパイル変換することにあります。

実務的に大きいのは、開発者の書き方です。開発者はPythonコードのなかで、どのデータをシークレット（暗号化したまま処理する対象）にするかをアノテートで指定します。あとはHEIRがコンパイル時に、その指定を踏まえてFHE対応の実装へ自動的に変換します。暗号方式の詳細を手作業で組み込む代わりに、秘匿したい箇所を宣言するという発想へ寄せられている点が特徴です。

内部では、MLIRのdialectという仕組みが効いています。BGVやCKKS、CGGI、LWEといった各FHEスキームや低レベル表現をdialectとして段階的に表し、抽象代数演算の最適化や段階的なコード生成（lowering）を進めます。さらに複数のスキーム、複数のバックエンドライブラリ、そしてGPUやTPU、FPGA、ASICといったハードウェア向けのコード生成までを抽象化の対象に据える設計思想を掲げています。ハードウェア対応は現時点で目標として位置づけられている点は押さえておくとよいでしょう。

対応スキームとバックエンドから読み解く適用範囲

どのスキームを選ぶかは、扱いたいデータ種別と演算から逆算するのが実務的です。BGVとBFVは整数（有限体上）のベクトル演算に向いたスキームで、SIMD的なバッチ処理と相性がよい構造を持ちます。CKKSは実数や複素数の近似演算に向き、機械学習の浮動小数点的な計算に適していますが、結果はあくまで近似値になる点を前提に据える必要があります。CGGIは一般にTFHEとして知られ、ビット単位の処理と高速なブートストラップにより、比較や分岐といった非線形演算に強みを発揮します。

スキームは単独では動かず、バックエンドライブラリとの組み合わせで実現します。GitHubの互換性マトリクスという事実に沿うと、OpenFHEとLattigoはBGV・BFV・CKKSに対応し、tfhe-rsとJaxiteはCGGIに対応するという住み分けになっています。つまりCGGIを使いたい場合はtfhe-rsまたはJaxiteが選択肢となり、逆にOpenFHEやLattigoではCGGIを扱えません。この制約は選定の初期段階で効いてきます。

注意したいのは、公式が掲げる「すべての現代的なスキームに対応する」という表現が目標だという点です。現状の実装はバックエンド依存で未対応の組み合わせが残っており、目標像と実装状況を混同すると設計を誤ります。扱う演算とデータ種別を先に決め、それに合うスキームとバックエンドを選ぶという順序が安全です。

実運用で効いてくる活用シーンと導入検討の論点

Googleは公式ブログで、HEIRを使った4つのユースケースを示しています。ディープラーニングによるレコメンデーションモデル、クレジットカードの詐欺検出、Kitsuneと呼ばれるシステムをコンパイルしたネットワーク侵入・脅威検知、そして音声トリガー型AIエージェント向けのホットワード検出です。いずれもBelfort LabsやNiobium、hardshell.ai、LG、ニューヨーク大学といった企業や研究機関との協業として紹介されています。想定される応用領域としては、医療や金融のように機微なデータを扱うプライバシー保護推論が挙げられています。

実際に導入を検討する際は、いくつかの論点を並行して見る必要があります。まず性能コストです。FHEは計算オーバーヘッドが大きいため、この重さが導入可否を大きく左右します。次にレイテンシで、リアルタイム性が求められる用途ほど慎重な見極めが要ります。さらに扱いたい演算やデータ種別に合ったスキームが選べるか、対応するハードウェアで加速できるかも判断材料になります。

性能に関する数値の扱いには注意が必要です。Googleは公式ブログでレイテンシに関する値を示していますが、それはシングルスレッドCPUで測定した前提付きの値として提示されています。自社の要件に引き当てて数値を引用するなら、Googleがどのような前提で公表したのかを帰属表現とともに明記し、単独の数字が独り歩きしないようにすることが望ましいです。並列化やハードウェアアクセラレータの活用によって実効的な処理時間は変わり得るため、単一の測定条件をそのまま自社環境の見積もりに転用しない姿勢が大切です。

もう一つ実務で押さえたいのは、暗号化の対象範囲をどう設計するかです。すべてを暗号化領域で処理するのか、機微な特徴量だけを秘匿するのかによって、コストもレイテンシも大きく変わります。ユースケースが求めるプライバシー水準と、許容できる応答時間のバランスを先に定義しておくと、スキームやバックエンドの選定がぶれにくくなります。

現時点の制約とこれからの展望

期待の一方で、HEIRの立ち位置は冷静に捉えるべきです。GitHubのリポジトリには、これは公式にサポートされるGoogle製品ではないという趣旨の免責が明記されており、正式なサポート製品というより研究・開発段階の性格が強いことがうかがえます。本番採用を急ぐより、まずは検証環境で自社ユースケースとの相性を測る使い方が現実的でしょう。

それでもプロジェクトの方向性は明確です。HEIRは業界標準のFHEコンパイラになることを目指すと自称しており、2023年ごろから進められてきた取り組みの成熟と成果を今回まとめて紹介した位置づけと読み取れます。複数の査読付き研究がHEIRを基盤にしているとも伝えられていますが、こうした点は公表情報の範囲で捉え、内部ロードマップの推測には踏み込まないのが賢明です。

コスト面についても、Googleは公式ブログのなかでFHEのコストは急速に低下しており、医療や金融などでの実用が現実的になりつつあると述べています。これはGoogleの主張として受け止めるべき見解ですが、暗号化したまま動かすAIという選択肢が、研究の外側で検討に値する段階へ近づいていることを示す動きだと言えます。自社の機微データ活用を見据えるなら、いまのうちに仕組みと制約を理解しておく価値は十分にあります。