数ある記事の中からこの記事を見つけてくださって、ありがとうございます。

「社内データを生成AIに投げていいのか」。この問いに、これまでのエンジニアは規約とネットワーク境界とマスキングで戦ってきました。2026年6〜9月、そこに「そもそも計算中に覗けない状態を作る」という選択肢が実用ラインまで降りてきています。本記事はその入門です。

全体要約

データの暗号化には at rest / in transit という定番がありますが、3つ目の「in use（計算中）」は長らく空白でした。そこを埋めるのが Confidential Computing です。TEEで実行環境をハードウェア隔離し、Remote Attestation で環境を遠隔検証してから鍵を渡す。2026年6月にApple PCCがGoogle Cloudへ拡張され、Confidential AIの入口も広がりました。脅威モデルと実装の現在地、守れるもの／守れないものを整理します。

対象読者とこの記事で分かること

Confidential Computing（以下CC）という言葉は聞いたことがあるが、中身を説明できない方
生成AI／LLMを業務システムに組み込む立場で、データ保護の選択肢を把握しておきたい方
クラウドの信頼境界（trust boundary）をどこに引くべきか考えている方

前提知識は特に要りません。TLSとディスク暗号化の違いが分かれば十分です。

1. 前提整理：暗号化には3つの状態がある

まず土台を揃えます。データ保護は、データが置かれている状態ごとに分けて考えます。

状態	呼称	代表的な技術	普及度
ディスク上に保存されている	at rest（保存時）	ディスク暗号化、KMS連携	当たり前
ネットワークを流れている	in transit（転送時）	TLS / mTLS	当たり前
CPU/GPUが処理している最中	in use（使用中）	← ここが長らく空白	普及の入口

at rest と in transit は、ほぼ解決済みの課題です。KMSで鍵を管理し、TLS 1.3を張っておけば、少なくとも監査で困ることはありません。

問題は3つ目です。

計算中に何が起きているか

暗号化されたデータは、そのままでは計算できません。行列積を取るにも、トークンを生成するにも、いったん平文に戻す必要があります。

つまり、推論中のモデル重みと推論入力は、VRAMやメモリ上に平文で展開されています。

そしてここが本題ですが、クラウドのホスト側にいる特権プロセス — ハイパーバイザー、管理デーモン、権限を持つ管理者 — は、原理的にその領域を読み取れる立場にいます。

TLSも、ディスク暗号化も、ネットワークFWも、この経路は止められません。守っているレイヤーが違うからです。

これまで我々はこのギャップを、契約・SOC2レポート・第三者監査・アクセスログという「組織的・法的な保証」で埋めてきました。しかし、契約書は計算中のメモリ読み取りを技術的に不可能にはしません。実行時点の環境が本当に想定どおりかを検証することもできません。

CCは、この最後の穴を塞ぐためのアプローチです。

CCの発想を一言でいうと、「誰を信頼するか」を決める技術から、「信頼しなければならない相手の数を減らす」技術への転換です。従来は信頼できる相手を選ぶ問題でした。CCはTCB（Trusted Computing Base、信頼しなければならない構成要素の集合）を縮める問題として捉え直します。

2. なぜ in use だけ空白のままだったのか

理由は単純で、難しかったからです。

at rest / in transit は「中身をいじらずに運ぶ／置く」だけなので、暗号化したまま扱えます。一方、計算は中身をいじる行為そのものです。

このため長らく本命視されていたのは準同型暗号(FHE)でした。暗号文のまま演算できる、理論的には理想解です。ただしオーバーヘッドが実用域に入らず、汎用のLLM推論に載せられる段階にはなっていません。

CCが採ったのは別の解き方です。

暗号文のまま計算するのではなく、復号してよい場所をハードウェアで囲い、囲いの外からは誰も覗けなくする。

理論的な美しさを捨てて実用速度を取った、というトレードオフだと理解すると腑に落ちます。代償として「チップベンダーを信頼する」という前提が残ります（後述）。

3. CCを構成する2つの部品

3-1. TEE（Trusted Execution Environment）

ハードウェアによって隔離された安全な実行領域です。主な性質は次の3点です。

メモリ暗号化：TEE内で使うメモリはCPU/GPU内蔵のエンジンで暗号化される。物理的にDIMMを抜かれても、ハイパーバイザーから読まれても平文にならない
完全性保護：メモリの改ざん・リプレイ・リマップを検知する仕組みを持つ実装がある（SEV-SNPの "SNP" は Secure Nested Paging）
特権の排除：ホストOS・ハイパーバイザー・クラウド管理者がTEE内部にアクセスできない

粒度は実装により異なり、プロセス単位のエンクレーブ型（Intel SGX系）と、VM単位の Confidential VM 型（AMD SEV-SNP / Intel TDX）に大別されます。アプリ改修なしで既存ワークロードを載せられるという点で、近年の主流はVM単位のほうです。

3-2. Remote Attestation（遠隔検証）

TEEだけでは「本当にTEEの中で動いているのか」を利用者が確認できません。そこで必要なのがアテステーションです。

TEE上で想定どおりのコード・設定が実行されていることを、ハードウェアの署名を根拠に遠隔から検証する仕組みです。典型的な流れは次のようになります。

[1] クライアント → ワークロード : nonce 付きで attestation を要求
[2] TEE (CPU/GPU)               : 起動時に測定した値（measurement）を
                                  ハードウェア鍵で署名 → Evidence 生成
[3] ワークロード → クライアント : Evidence を返却
[4] クライアント / Verifier     : ベンダーの証明書チェーンで署名を検証
                                  measurement が期待値と一致するか照合
[5] 検証 OK の場合にのみ         : KMS が復号鍵 / データを解放

ポイントは [5] です。「検証が通ったときにだけ鍵を渡す」という運用にできるため、改ざんされた環境には、そもそも平文データが渡りません。信頼が宣言ではなく制御フローになります。

Verifier を誰が担うかは設計判断で、自前で持つ、クラウドの提供する検証サービスを使う、中立の第三者を挟む、といった選択肢があります。この「誰が検証するか」が後述するApple PCCの設計で効いてきます。

4. 実装の現在地（2026年9月時点）

レイヤー	代表的な実装
CPU（VM単位）	AMD SEV-SNP、Intel TDX
CPU（プロセス単位）	Intel SGX 系エンクレーブ
CPU（AWS独自）	AWS Nitro Enclaves
GPU	NVIDIA Hopper / Blackwell / Vera Rubin がGPUベースのTEEに対応

クラウド別の対応状況は次のとおりです。

プラットフォーム	CPU側のTEE	GPU / 特記事項
AWS	Nitro Enclaves、AMD SEV-SNP	Nitro System の設計を軸に展開
Azure	Confidential VMs（AMD SEV-SNP・Intel TDX 両対応）、Confidential Containers	Build 2026 で Intel TDX 向け Confidential Live Migration をプライベートプレビュー発表
Google Cloud	Confidential VM（AMD SEV / Intel TDX）、Confidential Space	Confidential G4（Blackwell）、Confidential GKE、H100対応

GPU側がTEEに対応したことが、AI文脈でのCC普及のトリガーになっています。CPUだけ守っても、推論の本体がVRAM上で丸見えなら意味がないためです。

5. 2026年6〜9月に何が起きたか

CCの概念自体は新しくありません。変わったのは、この夏に一般ユーザーの手元まで降りてきたことです。

5-1. Apple が Private Cloud Compute を自社DCの外へ拡張（6月8日）

Appleは2026年6月8日、Private Cloud Compute（PCC）をApple自身のデータセンターの外へ拡張すると発表しました。GoogleおよびNVIDIAと協業し、新しいApple Intelligenceのワークロードを Google Cloud 上で動かすもので、PCCのプライバシー要件をサードパーティのデータセンターへ広げるのは初めてです。

設計上の要点を挙げます。

中核要件は据え置き：ステートレス計算、強制力のある保証、特権的なランタイムアクセスの排除、非標的性、検証可能な透明性
実装は、NVIDIA GPUによるConfidential Computing、Intel TDX搭載CPU、GoogleのTitanチップの組み合わせ
ユーザーデータを持ち出しうるコンポーネントのソフトウェア検証は、独立したベンダー由来の2つ以上の信頼の起点（root of trust）に紐づけられており、Intel・NVIDIA・Googleのいずれか1社が侵害されただけでは検証の連鎖が破れない
Googleの自社検証とは別に、中立的な信頼の起点として DigiCert が第三者アテステーションを提供

「単一ベンダーを信頼しない」という発想が実装に落ちている点が、アーキテクチャとして参考になります。なおこの展開はプレビュー段階で、AppleとGoogleが2026年1月に締結した複数年契約が背景にあります。

5-2. Google Cloud が Confidential AI を一般向けへ（6月24日）

Google Cloudは、NVIDIA RTX PRO 6000 Blackwell Server Edition GPU を搭載した G4マシンシリーズで Confidential VMs と Confidential GKE ノードのプレビュー提供を開始しました。Confidential G4 は標準のG4が使える全リージョンで提供され、オンデマンド・予約・DWS Flex Start・Spot など複数の利用モデルに対応します。

それまで高価なH100系インスタンスに限られていた Confidential AI の入口が、価格帯・調達形態の両面で広がった格好です。

同時に、Prompt Encryption SDK がオープンソース公開されています。問題意識はこうです。

モデルの実行環境を守るだけでは不十分。プロンプトやレスポンス自体に機密情報が含まれうる。

このSDKでは、クライアントから送られた瞬間からTEEで処理されるまで、そしてレスポンスがクライアントへ戻るまでを暗号で保護します。守る範囲を「箱の中」から「エンドツーエンド」に伸ばした、という位置づけです。

基盤側の整備も同時に進みました。Confidential Space向けの独立した検証サービスとして Intel Trust Authority が一般提供開始、Confidential Space での NVIDIA Hopper GPU サポートが一般提供、C4マシンシリーズのIntel TDX搭載Confidential VMがプレビュー間近、C3DベースのConfidential VMのライブマイグレーションが一般提供、といった具合です。

5-3. 国内：Acompany が Confidential AI を体系化（9月1日）

名古屋のスタートアップ株式会社Acompanyが、ホワイトペーパー「Confidential AI：Confidential Computingで実現する『秘密を守れるAI』」（全16ページ、2026年9月1日発行）を無料公開しました。

背景の整理が、そのまま日本企業の要件定義になっています。

利用企業は、診療情報や設計図といった機密データを組織外に出したくない
一方でモデル提供者も、莫大な投資の結晶である知的財産を外部にさらしたくない
この対称的な緊張関係がビジネスの障壁になってきた

そのうえで、契約・内部統制・第三者監査といった組織的・法的な保証では、計算中のデータへのアクセスを技術的に制限することも、実行時点の環境を検証することもできないと指摘し、Confidential AIの要件を「データの保護」「モデルの保護」「主権への寄与」「実行環境の検証」の4点に整理しています。

同社 Chief Scientist の髙橋翼氏は、Confidential AI は特定の製品や単一技術を指す言葉ではなく、利用者のデータと提供者のモデル双方の秘密を守りながらAIを運用するための設計の考え方である、という趣旨を述べています。

5-4. 業界の温度感

Gartnerは「2026年の戦略的テクノロジートレンド」にConfidential Computingを選出。TEE内にワークロードを隔離することで、インフラ所有者やクラウドプロバイダーからも機密性を保つ技術と位置づけ、規制産業や地政学的リスクに直面するグローバル業務で特に価値があるとしています
Confidential Computing Summit 2026 は6月23〜24日にサンフランシスコで開催され、チケットは完売、当日登録も受け付けない状態でした。基調講演にはGoogleのNelly Porter氏、MicrosoftのMark Russinovich氏（Azure CTO）らが登壇し、「エージェント経済のための信頼レイヤー」がテーマの一つに掲げられています
同サミットでは、前述のAcompanyが「ソブリンAIのためのConfidential Computing：日本における新たな機会」「日本の大規模データクリーンルーム事例」の2セッションで登壇しています。複数事業者のデータを、互いに生データを見せずに突き合わせるデータクリーンルームは、CCの代表的なユースケースの一つです

6. 脅威モデルの整理：何が守れて、何が守れないか

ここを曖昧にすると「CCを入れたので安全です」という危険な説明が生まれます。切り分けます。

脅威	CCで守れるか	補足
ホストOS・ハイパーバイザーからのメモリ読み取り	○	主目的
クラウド管理者・特権プロセスによる覗き見	○	TCBから外れる
物理アクセス（コールドブート等）	○（概ね）	メモリ暗号化により緩和
実行環境の改ざん	○	Attestation + 鍵解放制御で検知・遮断
モデル重みの窃取（提供者側の保護）	○	管理外環境への配備でも直接アクセスを制限
プロンプトインジェクション	×	別途ガードレールが必要
ハルシネーション・不適切な出力	×	評価・後段フィルタの領域
アプリ自体の脆弱性（SQLi、認可バグ等）	×	TEEの中で普通に起きる
過大な権限を渡したエージェントの暴走	×	権限設計の問題
サイドチャネル攻撃	△	実装・世代依存。研究は継続中
チップベンダー自体の侵害・バックドア	△	信頼の起点を複数化して緩和（Apple PCCの例）

CCは「使用中のデータ」を守る技術であって、AIの振る舞いのリスクとは守備範囲が異なります。Acompanyの整理でも、ガードレールやハーネスと組み合わせる枠組みとして位置づけられています。

7. 現場で先に効くのは、実はもっと手前の話

CC対応基盤の導入は、多くの組織にとってすぐの話ではありません。一方で、同じ問題領域のインシデントは既に起きています。

2026年9月3日、RIZAPが従業員による情報漏えいを公表しました。

特定保健指導のデータを集計する作業中、担当者が個人で利用していた外部の生成AIサービスに対象データをそのままアップロード
含まれていたのは氏名・生年月日・性別・保険証記号番号に加え、高血圧症や糖尿病といった疾患情報、一部には住所・電話番号
対象は健康保険組合の加入者210名分
発覚は監視システムの検知ではなく、担当者本人の自己申告
運営事業者への確認により、AIの学習には利用されていないことは確認済み

いわゆるシャドーAIです。注目すべきは検知経路で、DLPでも監査ログでもなく自己申告でした。

そして重要な点として、この事案はCCが解こうとしている問題そのものです。「学習に使われるか」だけがリスクではなく、「そもそも誰が見られる状態にあるか」が問われています。

明日から着手できる項目

CC以前に、次の順で効きます。

許可する生成AIサービスの明示。ホワイトリストがないと、人は自分で探します
入力ルールの粒度を上げる。「機密情報は入力しない」では運用できません。固有名詞は置換、実数値は概数化、といったレベルまで落とす
技術的制御の追加。未許可サービスへのアクセス制限、送信前の自動マスキング、プロキシでの検知
エージェントの権限最小化。読ませる範囲と実行させる操作を分け、不可逆操作は当面自動化対象から外す

「使うな」と禁止するだけでは、便利さに負けて個人利用に流れます。会社として安全に使える経路を用意するほうが、結果的に防御になります。RIZAPの事案が示したのはそこです。

調達・設計時のチェックリスト

CC対応基盤を検討する段階なら、最低限これを聞きます。

Attestation の Evidence を利用者側が検証できるか（ベンダーの「検証済みです」という宣言で終わっていないか）
measurement の期待値はどう管理・更新されるか。モデル更新時の運用は
鍵解放は検証結果に技術的に紐づいているか、運用手順で紐づけているだけか
信頼の起点が単一ベンダーに集中していないか
ログ・監査要件をTEE内で満たせるか（覗けないことと、監査できないことは両立しやすい）

8. 留保事項（誇張しないために）

記事や社内資料に数字を書く前に、以下は押さえておいてください。

性能オーバーヘッド：ベンダー資料ではGPUベースのAIワークロードで5〜15%程度とされますが、これはベンダー発の数値でワークロード依存です。未確認扱いが妥当で、自分のワークロードでの実測が必要です
市場規模予測：2025年242.4億ドル→2026年427.4億ドル、CAGR 34.70%（Fortune Business Insights）といった数字がありますが、調査会社ごとに幅が大きい領域です
「2029年までに信頼されていないインフラ上での業務の75%以上が秘密計算で保護される」というGartner予測は二次引用で、原典を確認できていません
サイドチャネル耐性は実装・世代に依存します。「TEEに入れたから安全」ではなく、脅威モデルごとの評価が必要です

まとめ

3行に畳みます。

データ保護には at rest / in transit / in use の3状態があり、最後の in use が長らく空白だった。TEEによるハードウェア隔離 + Remote Attestation による遠隔検証がその解で、検証が通ったときにだけ鍵を渡す制御に落とせる
2026年6〜9月に、Apple PCCの他社DC拡張、Google CloudのConfidential G4／Confidential GKE、Prompt Encryption SDK、国内での体系化が揃い、「研究の話」から「調達の選択肢」に変わった
ただし守備範囲は限定的。プロンプトインジェクション、ハルシネーション、アプリ脆弱性、エージェントの権限過多はCCでは1ミリも守れない。そして多くの組織にとって先に効くのは、許可ツールの明示と入力ルールの具体化

信頼を「人の誠実さの問題」から「検証可能な制御の問題」に置き換える。CCの価値は、突き詰めるとそこに尽きると思います。

参考にした主な情報源

Apple Security Research「Expanding Private Cloud Compute」（2026年6月8日）
Google Cloud 公式ブログ「検証可能なプライベート AI」（2026年6月24日／日本語版7月1日）
NVIDIA 公式（Confidential Computing 関連、2026年6月）
株式会社Acompany ホワイトペーパー「Confidential AI」およびプレスリリース（2026年9月1〜2日）
Linux Foundation / Confidential Computing Consortium（Confidential Computing Summit 2026）
Gartner「2026年の戦略的テクノロジートレンド」
各種報道（RIZAP情報漏えい公表、2026年9月3日）

最後までお読みいただき、ありがとうございました。

CCは名前の物々しさに比べて、考え方自体は素直な技術だと思います。「TCBを縮める」という一点さえ掴めば、各社の実装差分も読み解きやすくなるはずです。

この記事が参考になりましたら、LGTMとストックをいただけると励みになります。誤りやご指摘、実際に動かしてみた知見などがあれば、ぜひコメントで教えてください。最新のAI・セキュリティ関連の記事も継続して投稿していきますので、よろしければフォローもお願いします。