コンフィデンシャルコンピューティングとは｜TEE・MPCとの違いと導入条件

コンフィデンシャルコンピューティングは、ハードウェアに基づく、構成証明された信頼できる実行環境（TEE）で処理を行い、使用中のデータを保護する技術です。保存・通信の暗号化と組み合わせ、どの主体から、どの処理とデータを守るかを明確にして導入します。

本記事では、2026年10月時点で確認した公式資料をもとに、TEEと暗号技術の違い、保護の境界、構成証明、クラウドでの選定と検証、AIへの適用と運用の確認点を整理します。

TEEで使用中のデータを保護する仕組みと、MPC・FHEとの違い

データは、保管されているとき、ネットワークを移動するとき、計算に使われるときで、確認すべき保護範囲が変わります。ディスク暗号化や通信の暗号化を導入した事実だけでは、処理中に誰がデータを読めるかまで説明できません。反対に、TEEを使っていても、そこへ入れる前のファイルや、外へ返した結果、バックアップ等が自動的に保護されるわけではありません。各経路と担当をつなげて考えます。

Microsoftの概要は、コンフィデンシャルコンピューティングを、ハードウェアに基づく構成証明済みのTEEで使用中のデータを保護するものと説明しています。保存・通信の暗号化と併用し、適切に有効化・構成するという条件も確認する必要があります。製品名に「Confidential」があることだけで、対象システム全体の設定が済んだとは判断しません。出典：Azure Confidential Computingの概要。

TEEによる保護は、計算中もデータを一度も復号しない、という意味ではありません。MicrosoftのTEEの説明では、承認されたコードが内部のデータを操作し、内部では平文で処理することを示しています。保護された実行環境の外からのアクセスと、その中で実行を認めるコードによるアクセスを分けて考える点が重要です。出典：TEEの公式説明。

状態・方式	整理する問い
保存・通信の保護	どこに保管・送信し、誰が鍵と接続先を管理するか
TEE	どの実行環境へ処理を隔離し、その環境とコードを何で確認するか
MPC・FHE等	どの計算を、どの暗号方式と参加者・鍵の条件で実現するか

「秘密計算」という言葉だけで、これらを同じ仕組みとして扱わないことも大切です。NISTは、MPCを複数の参加者の私的な入力に対する共同計算、FHEを暗号化したデータ上で計算し、後で復号して結果を得る技術として説明しています。TEEによる隔離とは保護の仕方や前提が異なります。出典：NISTのPrivacy-Enhancing Cryptographyの技術解説。

選定では、企業が一社か複数かという区切りだけで決めず、誰を信頼するか、入力と結果のどこを共有するか、必要な処理を実行できるかを比べます。暗号方式やTEEの採用だけをもって、計算結果から分かる情報や、データを利用する権限まで解決したとは考えません。処理の目的と、共有してよい成果物を先に決めることが出発点です。

保護の境界と構成証明を、データを渡す条件へつなげる

導入前には、守りたいデータと処理、アクセスを制限したい主体を整理します。クラウド側の運用者、ホストの管理者、ゲストOSの管理者、アプリケーションの利用者では、権限と位置付けが異なります。「管理者からも守れる」という表現を、すべての管理権限やアプリケーションの操作へ広げないことが大切です。どの部分を保護の内側と外側に置くかを、対象の方式と構成に即して確認します。

このときの判断材料が、TCB（Trusted Computing Base：信頼する基盤）です。Microsoftの説明では、安全性を支えるハードウェア・ファームウェア・ソフトウェアが含まれ、方式によって範囲が変わります。VM全体をTEE内へ置く場合はゲストOSも内側となり、アプリケーションの特定の処理を保護する方式とは境界が異なります。出典：AzureのTCBの説明。信頼が不要になるのではなく、信頼する対象と更新の責任を具体化します。

構成証明（アテステーション）は、実行環境の証拠を確認し、利用を認める条件につなげる仕組みです。AWS Nitro Enclavesの説明では、署名付きの測定値を外部サービスのポリシーと照合し、要求された操作を許すか判断します。構成証明の文書を受け取ることと、その内容を期待する条件で検証し、鍵等の利用可否へ結び付けることは分けて設計します。出典：AWSのCryptographic attestationの説明。

実装では、どのコード・環境を許可するか、変更を誰が承認するか、検証に失敗した場合に何を止めるかを決めます。古い版をどこまで認めるか、更新時に確認する項目、判定結果の保存先も整理します。構成証明が成功した事実を、アプリケーションに不具合がないことや、出力してよい情報の保証へ読み替えません。許可するコードの内容と、そのコードを実行する環境の確認を組み合わせます。

データの流れには、入力を受ける窓口、前処理、一時保存、TEE内での計算、結果の返却、ログと削除まで含めます。途中で保護の外へ出るデータや、別サービスへ送信する情報があれば、その理由と条件を記録します。鍵の管理、利用者の認証、権限、ログの閲覧と保管も担当を置きます。TEEの内側だけを評価して、外側の入力・出力や管理画面を点検対象から落とさない進め方を提案します。

そのうえで、確認できた範囲、未確認の経路、対象外の処理を明示します。未確認を安全と扱わず、追加の確認が必要か、対象を狭めるかを判断します。利用するサービスの説明は技術の仕組みを理解する資料として参照し、海外の提供例や保護機能の説明を、日本の法令・契約上の要件を一律に満たす根拠にはしません。

クラウドの提供範囲を比較し、実際の処理でPoCを設計する

クラウドを選ぶ際は、VM全体、アプリケーションの一部、コンテナー等のどこを保護するかから比較します。サービス名を横に並べるだけでは、必要な改修、使える機器、入出力の制約はそろいません。CPU・GPU、利用地域、OSやランタイム、必要な機能、一般提供かプレビューかを、採用する具体的な構成の現行資料で確認します。古い概要ページに残る提供状況を、そのまま現在の仕様としないことも必要です。

例えばAzureの資料には、既存ワークロードをVM単位で扱う方式と、アプリケーションを開発して隔離領域を使う方式があります。両者で、保護の境界と変更する作業が異なります。どちらが常に簡単、または常に安全と順位付けせず、必要な処理と運用に合うかを確かめます。既存のプログラムを起動できても、周辺の接続、鍵管理、構成証明と更新の条件は別途確認します。

AWS Nitro Enclavesは、EC2の親インスタンスから分離した実行環境です。公式説明では、永続ストレージ、外部ネットワーク、SSH等の対話アクセスを持たず、親との接続を使うとされています。通常のVMと同じ接続や保管を前提にせず、データの受け渡しと処理結果の返し方を設計します。親インスタンスを停止・終了するとエンクレーブも終了する条件も、再開方法と合わせて確認します。出典：AWS Nitro Enclavesの概要・制約。

Google Cloudも、Confidential VM、Confidential Space、Google Cloud Attestation等を案内しています。必要な製品と構成証明、データ共有の仕組みを分けて確認し、概要の製品一覧だけで自社の必要機能がすべて利用できると判断しません。出典：Google Cloud Confidential Computingの概要。

PoCでは、処理の正しさと保護の確認項目を用意します。代表的な入力とデータ量、同時実行、応答時間や処理量、メモリ、起動・復旧、外部との通信、確認作業を測ります。通常構成と比較する場合は、資源と処理条件をそろえ、そろわない点を記録します。性能の低下率を共通の5〜15％等と置かず、実測値と未測定の条件を分けます。計画の作り方はPoCの評価基準と本番移行の判断も参照できます。

費用には、計算資源、保管や通信、鍵・構成証明に関わるサービス、開発・検証・運用の作業を含めて見積もります。機能自体の追加料金がない場合でも、周辺を含む総費用がゼロになるとは限りません。固定の導入月数から広げるより、受入条件と未解決事項を確認して次の段階を決めます。費用と便益の期間・範囲をそろえる際は、費用対効果とROIの評価方法を参照できます。

AIの入出力と運用まで含めて、保護を継続できる状態にする

AIへ適用する場合は、学習、追加学習、推論のどの処理を対象にするかを決めます。Microsoftの機密AIの資料は、学習データやモデル、推論の要求・応答を保護する構成などを説明しています。ただし、概要に記載されたシナリオと、採用する機器・サービスで実現できる範囲は分けて確認します。特定のGPUやプレビューの記載を、すべての環境で使える機能として扱いません。出典：Azureの機密AIの説明。

例えば推論では、プロンプトを受け取る窓口、参照データの取得、前処理、モデルの実行、回答の返却と保存を追います。モデルを動かす箇所が保護されていても、手前のログや外部ツールへ入力が残る構成なら、そちらの取り扱いも確認します。GPUや別のノードを使う場合は、その間の転送と処理がどこまで対象となるかを明らかにします。「AIをTEE内で実行する」という一文で、全経路の確認を済ませないことが大切です。

また、利用者に返す回答や集計結果から、提供してよい範囲を超える情報が伝わらないかも評価します。利用者ごとの権限、参照先、回答の確認、必要な場合の人の承認は、実行環境の保護と別の設計事項です。データを使う目的と利用条件、モデルや入力の変更による影響も整理します。組織全体の管理とつなげる場合は、AIセキュリティの脅威・対策・ガバナンスも参照できます。

本番移行では、担当者、確認・承認の権限、運用時間と連絡先を決めます。更新後のコードや環境で構成証明が通るか、許可していない版を拒めるか、失敗時にデータや鍵を渡さず停止できるかなど、合意した条件を検証します。障害時の再実行と二重処理、復旧後のデータ整合、切り戻しも業務に応じて確認します。保護を保ったまま復旧できるかを、通常の処理の成功とは別の受入条件にします。

運用中は、依存部品やファームウェア、鍵、ポリシー等の変更が保護と証明へ及ぼす影響を確認します。変更した対象、承認者、検証結果、残る課題を記録し、見直す条件を決めます。データの保管・削除、問い合わせへの対応、担当交代時の引き継ぎも含め、特定の担当者の理解だけに依存しない仕組みにします。導入した時点で完了とせず、変更後も前提を追える状態を目指します。

業務とデータの要件を整理し、既存システムとの連携、検証から実装・運用へつなぐ工程が課題なら、renueのFDEによる要件整理・設計・実装・運用支援へ相談できます。利用する環境、API・権限、データ形式とセキュリティ条件を確認して支援範囲を決めます。TEEの採用そのものを目的にせず、守る処理と必要な成果、実装・運用の制約を具体化するところから進めます。