【2026年版】機密データをクラウドAIに渡す「推論時の丸見え（data-in-use）」対策ガイド——Confidential Computing／TEE・秘匿推論で、プロンプト・社内データ・モデルを”使用中”もハードウェアで暗号化する｜NVIDIA H100/H200 CC・Intel TDX・AWS Nitro Enclaves・リモート認証（Attestation）による多層防御

  1. はじめに——守る対象が「保存中・通信中」から「使用中（data-in-use）」へ
  2. 前提——データの「3つの状態」と、これまで抜けていた1つ
  3. なぜ2026年か——主要TEEが出そろい、GPU秘匿推論がGAになった
    1. 1. CPU／GPUのTEEが出そろってGA化した
    2. 2. 性能ペナルティが実用域まで下がった
    3. 3. 「使用中データ」が規制・監査の論点になった
  4. 主要TEEの整理——CPU側・GPU側・クラウド固有
  5. この記事が既存記事と別軸である理由——「検知」ではなく「基盤」で守る
  6. Attestation（リモート認証）——「本当にTEEの中で動いているか」を暗号的に証明する
    1. Attestationが証明すること
    2. 実装上の勘所
  7. 実装アーキテクチャ——機密データをクラウドAIに渡す3パターン
    1. パターンA：自社ホスティングLLM＋GPU CC（最も強い）
    2. パターンB：Nitro Enclavesで機密処理だけ隔離
    3. パターンC：Confidential Computing対応のマネージド推論を利用
  8. Confidential Computingが守らないもの——過信への注意
  9. 多層防御チェックリスト
  10. よくある質問（Q&A）
    1. Q1. ディスク暗号化とTLSをやっていれば、機密データをクラウドAIに渡しても大丈夫では？
    2. Q2. TEEを使うと推論はどれくらい遅くなりますか？
    3. Q3. クラウド事業者が「機密（Confidential）」と言っていれば信頼していいですか？
    4. Q4. Confidential Computingを入れれば、プロンプトインジェクションやモデル窃取も防げますか？
    5. Q5. CPUのTEEだけ、GPUのCCだけでは不十分ですか？
  11. まとめ——「使用中も暗号化」を前提に、クラウドAIの信頼境界を引き直す
  12. 参考リンク

はじめに——守る対象が「保存中・通信中」から「使用中（data-in-use）」へ

これまでのAIセキュリティ記事では、ベクトルDBに保存された埋め込みの漏洩、公開した推論エンドポイントの窃取、通信経路の暗号化（TLS）といった「保存されているデータ（data-at-rest）」と「通信中のデータ（data-in-transit）」をどう守るかを中心に扱ってきました。しかし2026年、これらを固めても残る「第三の状態」が正面から問われるようになりました。それが使用中のデータ（data-in-use）——CPU／GPUが実際に計算している瞬間に、メモリ上に平文で存在するプロンプト・社内データ・モデルの重みです。

ディスクは暗号化し、通信はTLSで守っても、推論の瞬間だけはホスト側のメモリに平文が載ります。つまりクラウド事業者の特権プロセス、侵害されたハイパーバイザー、悪意ある内部者、同居する別テナントから見れば、「使用中の一瞬」はサーバー側から丸見えになり得ます。機密データをクラウドAIに渡すとき、多くの企業が見落としているのはこの盲点です。

筆者はネットワークのTAC（テクニカルアシスタンスセンター）とアドバンスドサービスで、長年インフラの信頼境界（トラストバウンダリー）の設計に携わってきました。本記事の核心は、「そもそも平文をホスト側に晒さない」というハードウェア基盤側の防御——Confidential Computing／TEE（Trusted Execution Environment）と秘匿推論です。攻撃を「検知して止める」ロジックの話ではなく、物理・ハードウェア層に信頼の起点（Root of Trust）を置き、使用中も暗号化したまま計算するという、これまでのソフトウェア防御とは別軸の一手を、実装の視点で整理します。

想定読者は、医療・金融・法務などの機密データをクラウドAI（API・SaaS・自社ホスティングLLM）に渡さざるを得ない事業者、EU AI法・GDPRのコンプライアンス対応を迫られる情シス・CISO、そして「使用中データ」の保証を顧客・監査から求められている方々です。

前提——データの「3つの状態」と、これまで抜けていた1つ

データ保護は、データが取り得る3つの状態それぞれに対策が必要です。ところが従来のセキュリティは、そのうち2つしかカバーしていませんでした。

データの状態典型的な守り方これまでの充足度
保存中（at-rest）ディスク暗号化、KMS、DB暗号化広く実装済み
通信中（in-transit）TLS／mTLS、VPN広く実装済み
使用中（in-use）Confidential Computing／TEE・秘匿推論抜けていた／2026年に実装可能に

「使用中」だけが長らく無防備だった理由は単純で、CPUは計算のために一度データを復号する必要があったからです。暗号化したままでは足し算も掛け算もできない——この物理的制約が、data-in-use保護を「理論はあっても実用にならない」領域に留めてきました。

この壁を崩したのが、CPU／GPUにハードウェアで隔離された実行環境（TEE）を作り込み、「メモリを暗号化したまま、その中でだけ復号して計算する」というアプローチです。TEEの内側は、たとえOS・ハイパーバイザー・クラウド管理者であっても覗けません。信頼の起点をソフトウェアではなくCPU／GPUのハードウェアそのものに置くのが、Confidential Computingの発想です。

なぜ2026年か——主要TEEが出そろい、GPU秘匿推論がGAになった

data-in-use保護が「今」の論点になったのには、明確な理由が2つあります。

1. CPU／GPUのTEEが出そろってGA化した

2026年時点で、主要な信頼実行環境が実運用（GA）で使える状態に揃いました。CPU側ではIntel TDX（Trust Domain Extensions）とAMD SEV-SNP、クラウド固有ではAWS Nitro Enclaves。そして最大の変化がGPU側で、NVIDIA H100／H200のConfidential Computingにより、LLM推論のようなGPUワークロードを暗号化されたまま実行できるようになりました。従来はCPUのTEEしかなく「AI推論の主役であるGPUが守れない」というギャップがありましたが、これが埋まったのが2026年です。

2. 性能ペナルティが実用域まで下がった

かつてのTEEは「安全だが遅すぎて使えない」が定説でした。しかしH100／H200世代では、GPUダイ上に専用のConfidential Compute Engine（CCE）が統合され、HBMへの書き込みをAES-256-GCMでハードウェア暗号化します。ベンチマークでは、大きなバッチ・長い系列ほどオーバーヘッドは小さくなり、LLM推論の実務域ではおおむね1〜7%程度（NVIDIA公式は大規模行列演算で3%未満）に収まります。オーバーヘッドの主因は計算そのものではなくCPU↔GPU間のデータ転送であり、大規模推論ほど相対的に無視できる水準になります。「安全のために性能を大きく諦める」時代は終わりつつあります。

3. 「使用中データ」が規制・監査の論点になった

EU AI法やGDPRは、機密データの処理に対して「適切な技術的・組織的措置」を求めます。2026年に入り、「保存中・通信中は暗号化しているが、使用中は？」という問いが、監査・顧客デューデリジェンス・データ処理契約（DPA）の場で具体的に問われ始めました。Confidential Computingは、この「使用中も守っている」ことをリモート認証（Attestation）で暗号的に証明できる点で、コンプライアンス上の武器になります。

主要TEEの整理——CPU側・GPU側・クラウド固有

「TEE」と一口に言っても、隔離の単位（プロセス／VM）や信頼の起点（チップメーカー／クラウド）が異なります。選定の出発点として、まずここを分けて理解します。

技術提供元隔離の単位信頼の起点（Root of Trust）主な用途
Intel TDXIntelVM単位（Trust Domain）Intelの鍵＋SGXベースのQuoting Enclave汎用CVM、CPU推論
AMD SEV-SNPAMDVM単位（VMごとに固有鍵）AMDの鍵＋専用セキュアプロセッサ汎用CVM、CPU推論
AWS Nitro EnclavesAWSEC2内の隔離エンクレーブAWS独自の署名基盤（Nitro）鍵処理・機密データ隔離
NVIDIA H100/H200 CCNVIDIAGPU＋暗号化VRAMGPUオンダイのCCE＋デバイス証明書LLM／GPU推論

実務では、CPU側TEE（TDX／SEV-SNP）とGPU側CC（H100/H200）を組み合わせるのが典型です。CPUのVMをTDXで隔離し、そのVMから暗号化リンクでH100のCCへデータを渡す——CPUからGPUまで一貫して平文をホストに晒さない「エンドツーエンドの機密経路」を作ります。AWS Nitro Enclavesは、鍵の取り扱いなど「特に機密性の高い一部処理」を主VMから切り離す用途に向きます。

この記事が既存記事と別軸である理由——「検知」ではなく「基盤」で守る

当サイトのこれまでのAIセキュリティ記事——モデル抽出・蒸留窃取、埋め込み反転、メモリ汚染、目標ハイジャックなど——は、いずれも「攻撃を検知し、防御するロジック」の話でした。異常なクエリを見分け、汚染された入力を弾き、逸脱した振る舞いを止める。これらはソフトウェア層・アプリケーション層の防御です。

本稿はそのどれとも軸が異なります。扱うのは「そもそも平文をホスト側に晒さない」ハードウェア基盤側の防御です。整理すると、AIセキュリティの防御は少なくとも3つの独立した軸に分かれます。

防御の軸問い代表的な対策層
権限（オーバーシェアリング）誰がそのデータに触れてよいかアクセス制御、最小権限、RAG権限設計アプリ／認可
分離（マルチテナント）テナント間で論理的に混ざらないかテナント分離、名前空間、論理境界アプリ／論理
基盤（data-in-use）ホスト自身から物理的に隠せているかConfidential Computing／TEE・Attestation物理／ハードウェア

権限も論理分離も「ソフトウェアが正しく動くこと」を前提にした防御です。しかしハイパーバイザーやOS自体が侵害されたら、その前提は崩れます。Confidential Computingは「ホスト側のソフトウェア全体を信頼しない」ことを出発点に、ハードウェアに信頼の起点を移す——だからこそ、権限とも論理分離とも別の、独立した最終防衛線になります。本稿は、この物理・ハードウェア層に踏み込む回です。

Attestation（リモート認証）——「本当にTEEの中で動いているか」を暗号的に証明する

Confidential Computingの本質は暗号化そのものではなく、Attestation（リモート認証）にあります。「暗号化しています」という主張を、相手が暗号的に検証できる証拠に変えるのがAttestationです。これが無ければ、TEEは「信じてください」という自己申告に過ぎません。

Attestationが証明すること

Attestationのフローは、おおむね次の3ステップです。

  • 計測（Measurement）： 起動したTEEが、自分自身の初期状態（ロードされたコード・設定のハッシュ）を計測する。
  • 署名（Signing）： ハードウェア（CPU／GPU）が、その計測値をプラットフォーム固有の鍵で署名する。この鍵はチップに焼き込まれ、取り出せない。
  • 検証（Verification）： データを渡す側（あるいは監査側）が、署名された計測値を受け取り、「期待どおりの環境か」「本物のハードウェアか」を検証してから初めて鍵・データを渡す。

これにより、「正しいコードが、本物のTEEの中で、改ざんされていない状態で動いている」ことを確認してからでないと機密データが復号されないという設計が可能になります。TDXはSGXベースのQuoting Enclaveで、SEV-SNPは専用セキュアプロセッサで、NVIDIA CCはデバイス証明書とオンダイのRoot of Trustで、それぞれこの署名を発行します。

実装上の勘所

  • 鍵解放をAttestationにゲートする： KMSやシークレット管理を「Attestation検証成功」を条件に鍵を解放する構成にする。環境が期待と違えば鍵が出ないため、平文が復号されない。
  • Composite Attestation（複合認証）： CPU側TEEとGPU側CCの両方の証明を突き合わせる。CPUだけ、GPUだけの証明では経路の一部しか保証できない。
  • 検証ロジックの独立配置： Attestationの検証を、守りたいワークロードと同じ信頼境界に置かない。第三者・独立サービスで検証させることで、証明の自作自演を防ぐ。

実装アーキテクチャ——機密データをクラウドAIに渡す3パターン

「使用中も暗号化」を実際にどう組むか。機密度と運用負荷に応じて、代表的な3パターンを整理します。

パターンA：自社ホスティングLLM＋GPU CC（最も強い）

自社が管理するクラウドVM（TDX／SEV-SNP）上に、H100/H200のCCを使ってLLMをホスティングします。プロンプトも社内データもモデルの重みも、CPU↔GPUの経路全体でホストに平文を晒しません。機密度が最も高い医療・金融データを、汎用クラウドのインフラ上でも扱える構成です。運用負荷は高いものの、data-in-use保護としては最も強力です。

パターンB：Nitro Enclavesで機密処理だけ隔離

アプリ全体ではなく、機密データの復号・鍵処理・前処理といった一部だけをAWS Nitro Enclavesの中に隔離し、外側の主アプリからは平文が見えないようにします。既存のAWS構成に段階的に組み込みやすく、「全部をTEE化するのは重いが、最も機密な一点だけは物理的に隔離したい」ケースに向きます。

パターンC：Confidential Computing対応のマネージド推論を利用

自前でTEEを組まず、Confidential Computing対応を明示するマネージド推論サービス／Confidential VMを利用します。この場合、「使用中も守っている」ことをサービス側のAttestationで検証できるかが選定の肝です。マーケティング上「機密」を謳うだけでなく、検証可能なAttestation証拠を出せるかを必ず確認します（出せないなら、それは自己申告に過ぎません）。

パターン機密度運用負荷向くケース
A：自社ホスティング＋GPU CC最高高医療・金融など最機密、モデルも守りたい
B：Nitro Enclavesで一部隔離高中既存AWS構成に段階導入、鍵・機密処理の隔離
C：CC対応マネージド利用中〜高低自前運用は避けたい、Attestation検証が前提

Confidential Computingが守らないもの——過信への注意

TEEは強力ですが、万能ではありません。「TEEを入れたから安全」という過信は、かえって危険です。守備範囲を正確に理解しておきます。

  • アプリケーションの脆弱性は守らない： TEEの中で動くコード自体にバグ・プロンプトインジェクション・権限設計の穴があれば、TEEはそれを防ぎません。data-in-use保護は「ホストからの覗き見」を防ぐもので、アプリ層の防御（前述の権限・分離・検知）を置き換えません。
  • 出力からの漏洩は守らない： 推論結果そのものにPIIやシステムプロンプトが載って外に出れば、TEEの外側で漏れます。出力フィルタは別途必要です。
  • サイドチャネルは完全には防げない： 消費電力・タイミング・キャッシュ挙動などのサイドチャネル攻撃は、TEEでも研究上の懸念が残ります。最機密用途では脅威モデルに含めて評価します。
  • Attestationを検証しなければ意味がない： TEEを使っていても、鍵解放をAttestationにゲートしていなければ、「暗号化しているつもり」で平文を渡してしまう構成になり得ます。

つまりConfidential Computingは、権限・分離・検知といったソフトウェア防御に「積み重ねる」最終防衛線であって、それらの代替ではありません。多層防御の一層として位置づけるのが正しい理解です。

多層防御チェックリスト

層対策主に守る対象
基盤（CPU）Intel TDX／AMD SEV-SNPでVMを隔離使用中のプロンプト・社内データ
基盤（GPU）NVIDIA H100/H200 CC＋暗号化VRAM使用中のモデル重み・推論データ
基盤（隔離）AWS Nitro Enclavesで機密処理を分離鍵・復号・前処理
証明Attestationで環境を検証してから鍵解放「本当にTEE内か」の保証
証明Composite Attestation（CPU＋GPU）経路全体の一貫した保証
アプリ権限設計・テナント分離・出力フィルタ（別軸）認可・論理分離・出力漏洩
運用Attestation失敗時のフェイルクローズ・監査ログ誤設定・改ざんの検知と立証

よくある質問（Q&A）

Q1. ディスク暗号化とTLSをやっていれば、機密データをクラウドAIに渡しても大丈夫では？

それらは「保存中」と「通信中」を守りますが、「使用中（推論の瞬間）」は守りません。推論時、データはメモリ上に平文で載り、クラウド事業者の特権プロセスや侵害されたハイパーバイザーからは覗き得ます。この盲点を埋めるのがConfidential Computing／TEEです。

Q2. TEEを使うと推論はどれくらい遅くなりますか？

H100/H200世代では、LLM推論の実務域でおおむね1〜7%程度に収まり、NVIDIA公式は大規模行列演算で3%未満としています。オーバーヘッドの主因はCPU↔GPU間のデータ転送で、バッチが大きく系列が長いほど相対的に小さくなる——大規模推論ほど有利です。「安全のために性能を大きく諦める」時代は終わりつつあります。

Q3. クラウド事業者が「機密（Confidential）」と言っていれば信頼していいですか？

いいえ。重要なのは謳い文句ではなく、検証可能なAttestation証拠を出せるかです。「暗号化しています」という主張を、あなた側が暗号的に検証できて初めて意味を持ちます。Attestationを出せないサービスは、実質的に自己申告と変わりません。

Q4. Confidential Computingを入れれば、プロンプトインジェクションやモデル窃取も防げますか？

防げません。TEEは「ホストからの覗き見（data-in-use漏洩）」を防ぐ基盤層の対策で、アプリ層の攻撃（インジェクション、権限の穴、出力からの漏洩、大量クエリによるモデル抽出）は別軸の防御が必要です。Confidential Computingは既存のソフトウェア防御に積み重ねる最終防衛線であり、代替ではありません。

Q5. CPUのTEEだけ、GPUのCCだけでは不十分ですか？

用途によります。CPU推論だけならCPU側TEEで足りますが、LLMのようにGPUで推論する場合は、CPUのVMからGPUへ渡す経路も守る必要があります。CPU側TEEとGPU側CCを組み合わせ、両方のAttestationを突き合わせる「Composite Attestation」で、経路全体を一貫して保証するのが最機密用途の基本形です。

まとめ——「使用中も暗号化」を前提に、クラウドAIの信頼境界を引き直す

AIセキュリティの議論は、長らく「入力をどう守るか」「保存データをどう守るか」に集中してきました。しかし機密データをクラウドAIに渡す以上、推論の瞬間にメモリ上へ載る平文（data-in-use）という盲点は避けて通れません。要点は3つです。

1. 守る状態は3つある。 保存中・通信中は広く守られてきましたが、使用中だけが長く無防備でした。2026年、主要TEEのGA化とGPU秘匿推論の実用化で、ここをハードウェアで守れるようになりました。

2. 別軸の最終防衛線として積み重ねる。 Confidential Computingは、権限（オーバーシェアリング）とも論理分離（マルチテナント）とも別の、物理・ハードウェア層の防御です。ソフトウェア防御を置き換えず、その上に重ねる最終防衛線です。

3. 本質はAttestation。 「暗号化しています」を「暗号的に検証できます」に変えるAttestationこそが核心です。鍵解放をAttestationにゲートし、CPUとGPUの複合認証で経路全体を保証して初めて、data-in-use保護は「主張」から「証明」になります。

クラウドAIを使わない選択肢が現実的でない以上、「使用中の一瞬もホストに晒さない」を前提に、CPU・GPU・証明・運用の各層で信頼境界を引き直す——これが、機密データを安心してクラウドAIに渡すための基本姿勢です。

参考リンク

免責事項： 本記事は2026年8月時点の公開情報および各社の公式ドキュメントに基づく一般的な情報提供であり、特定の製品・構成における安全性を保証するものではありません。また、法的助言ではありません。実際の実装は自社環境・脅威モデル・関連法令（EU AI法・GDPR等）に照らして検討し、必要に応じてセキュリティ専門家や弁護士にご相談ください。性能数値は測定条件・モデル・バッチサイズにより変動します。技術仕様・GA状況・ガイドラインは更新されるため、最新情報は各公式ソースでご確認ください。

コメント

タイトルとURLをコピーしました