AI活用の検討会が、担当者の「そのデータは外に出せないので」という一言で終わる。そして次の議題に移り、その後は誰も蒸し返しません。 半年後に同じ検討が最初から始まります。
この止まり方が厄介なのは、誰も間違っていないことです。出せないという判断は多くの場合正しく、代案を出す責任も特定の誰かにはない。結論が出ないまま、検討そのものが消えます。
「出せない」は3種類ある
まず分けておくと、その後の打ち手が変わります。
1つ目は契約や法令で縛られているものです。取引先との秘密保持契約で第三者提供が禁じられている、あるいは業法上の制約がある。これは技術で回避する対象ではなく、条件を満たすかどうかの判断になります。
2つ目は社内規程で決めているものです。「機密区分Aは社外のサービスに投入しない」といった自社ルール。これは自社で決めた以上、条件次第で見直せます。
3つ目はなんとなく怖いから出さないものです。規程にも契約にも書かれていないが、前例がないので止めておく。実務では、この3つ目が最も多い。そして3つ目は、技術の話をしても解けません。
止まっている案件がどれなのかを先に確かめてください。3つ目に技術的な解を持ち込んでも、判断者は動きません。
これまでの選択肢は2つだった
契約や規程が理由で、しかし業務上の必要はある。この場合に取れる道は、これまで実質2つでした。
ひとつは、条件を満たす形でクラウドに出すこと。データの取り扱い範囲を契約で縛り、学習に使われない設定を確認したうえで送る。もうひとつは、手元やオンプレミスで動かすことです。データを外に出さない代わりに、計算資源を自前で用意します。
後者は近年かなり現実的になりましたが、設備と運用が要る点は変わりません。 端末側で動かす場合の実際の要求水準についてはオンデバイスAIの現実で整理したとおり、「動く」と「業務で使える」の間には距離があります。
3つ目の道筋としてのHEIR
2026年8月、GoogleはHEIRをオープンソースとして公開しました。学習済みAIモデルのPythonコードをコンパイルし、暗号化されたデータを復号せずにそのまま推論へ入力できる形に変換するコンパイラとツールチェーンです。
支えているのは完全準同型暗号（FHE）です。暗号化したままの状態で計算を行い、結果も暗号化されたまま返す。受け取った側は、処理しているデータの中身を最後まで見られません。
| 方式 | データの置き場所 | 処理側が中身を見られるか |
|---|---|---|
| クラウドに送る | 外部サービス | 見られる（契約で制限） |
| 手元・オンプレで動かす | 自社内 | 自社のみ |
| 暗号化したまま計算 | 外部でもよい | 見られない |
3行目が成立すると、「外に出せない」の前提そのものが変わります。出しているのは暗号文であって、平文ではないからです。
今日の案件には、まだ使えない
期待値を先に置いておきます。これは今期の提案書に載せる技術ではありません。
完全準同型暗号は、暗号化したまま計算する代償として、平文で同じ処理をする場合に比べて計算量が大きく増えることが知られています。GPUによる高速化の研究が進み、実用に近づいているという段階であって、汎用の生成AIをこの方式で回すのが当たり前になったわけではありません。
HEIRが埋めようとしているのは、その手前にある障壁です。従来この分野は暗号の専門知識がないと手が出せませんでしたが、学習済みモデルのコードをコンパイルするという入り口にしたことで、扱える人の範囲が広がります。 オープンソースである点も含め、これは「使えるようになった」ではなく「試せる人が増えた」という変化です。
したがって現時点での位置づけは、選択肢そのものというより、数年後の選択肢を織り込んだうえで今の投資判断をするための材料です。オンプレミス環境に大きく投資する直前であれば、この方向の進み方を一度確認しておく価値はあります。
鍵を誰が持つかで、話が変わる
技術の成熟とは別に、この方式には最初に決めておくべき論点があります。暗号を解く鍵を誰が保持するのかです。
暗号化したまま計算できるという性質が意味を持つのは、計算する側が鍵を持たない場合だけです。処理を委託した相手が鍵も預かっているなら、いつでも復号できる状態なので、平文を渡しているのと変わりません。「暗号化して送っています」という説明だけでは、実質的な保護になっているかどうかは判断できません。
裏を返せば、鍵は自社で持ち続ける必要があります。すると鍵の保管、バックアップ、担当者の交代時の引き継ぎといった管理が発生します。鍵を失えば、暗号化したデータは自社でも読めなくなる。これは可用性の問題として、情報漏洩とは別に評価すべきリスクです。
将来この方式を検討する場合、技術的な可否より先に、この鍵の管理を自社で背負えるかどうかが判断材料になります。 現時点で答えを出す必要はありませんが、論点として認識しておくと、ベンダーの提案を評価するときの軸になります。
それでも今できることがある
将来どの方式を選ぶにせよ、共通して必要になる作業がひとつあります。自社のデータのうち、どれが本当に出せないのかを区分することです。
冒頭の3分類でいえば、1つ目と2つ目に該当するデータだけが、技術的な工夫を要する対象です。多くの現場では、この線引きがされないまま「うちのデータは全部機密」として扱われ、結果としてすべての検討が止まります。分類の実務的な進め方はドライブのAI分類とラベルで扱った仕組みが出発点になります。
この区分は、暗号方式が実用化されたときにそのまま使えます。逆に区分がないと、どんな技術が来ても「出せない」で止まり続けます。 待っている間にやれる仕事は、ここにあります。
次にやること
まず、直近で止まったAI活用の検討を1件思い出し、その「出せない理由」がどの分類だったかを確かめてください。 3つ目（前例がないから）だった場合、必要なのは暗号技術ではなく、小さく試して前例を作る段取りです。
そのうえで、出せないデータの区分に着手してください。 全社を一度にやる必要はなく、止まった検討で使いたかったデータだけで構いません。1件分の線引きができれば、次の検討はその続きから始められます。
機密データを扱う前提でのAI活用の設計、データ区分の整理、オンプレミスとクラウドの構成比較については、グリームハブの開発・AI・自動化のご相談で承っています。データの性質と制約によって取れる構成が変わるため、個別にご相談ください。お問い合わせからどうぞ。
