Confidential Inferenceとは — Claudeの推論を暗号化したまま実行する仕組み

Confidential Inferenceとは何か — 推論中も暗号化を維持する技術

Confidential Inferenceは、Anthropicが研究し、Pattern Labsと共同でレポートを公表した技術です。ユーザーデータを、処理される瞬間を除いて常に暗号化された状態に保ちます。2025年6月18日に公開されたレポートで、その仕組みが説明されました。

狙いは2つあります。1つはモデル重みのセキュリティで、Claudeのような最先端モデルを能力の高い攻撃者から守ります。RANDの「Securing AI Model Weights」報告書が挙げる脅威が念頭にあります。もう1つはユーザーデータのセキュリティで、機密情報が外から読み取れない状態にあることを、暗号技術で証明できるようにします。

Anthropicは毎日、数百万人のユーザーから機密性の高い情報(独自コードから企業の非公開戦略まで)を託されています。「信頼して任せていい」という状態を、運用上の約束ではなく暗号学的な保証にしようとする試みです。Anthropicは公開時のレポートで「まだ研究の初期段階であり、具体的な設計や機能にどうつながるかを予測するのは時期尚早」と述べています。製品化された機能ではありません。

暗号化されたデータはどこで平文に戻るのか

前提は「機密データは処理される瞬間以外は常に暗号化されている」ことです。実現には、確立された機密コンピューティング(confidential computing)の手法を使います。ソフトウェアの安全性を証明する信頼の連鎖を作り、その証明をもとに、暗号鍵を使えるソフトウェアを厳格に絞る仕組みです。

ユーザーデータが平文で扱われる箇所は2つに限られます。

モデルの重み(パラメータ)が平文になるのは推論サーバーだけです。レポートは推論サーバー側に焦点を当てています。

すべてのアクセラレータが機密コンピューティングに完全対応しているわけではありません。そこでAnthropicは、小さく安全な「モデルローダー兼呼び出し役」を土台にした構成を検討しています。ローダーの仕事は2つだけです。暗号化データを受け取って復号しアクセラレータへ送ることと、アクセラレータを呼び出して暗号化した結果を返すことです。復号済みデータに触れられるのはこの「信頼された」ローダーだけで、残りはすべて「信頼されない」側です。

推論サーバーの大部分は信頼されない側で動きます。頻繁に変更されますが、変更がシステム全体の安全性に影響しない設計です。ローダーはハイパーバイザーで隔離された別の仮想マシンで動き、推論サーバーからは「仮想アクセラレータ」に見えます。この仮想アクセラレータは、Anthropicの安全な継続的インテグレーション(CI)サーバーが署名したプログラムしか受け付けません。実行されるコードは、複数のエンジニアのレビューを経ています。

リクエストはどの経路で保護されるのか

レポートの結論部分は、保護対象のデータが辿る流れを4段階で書いています。

手順

ユーザーのリクエストが通る4段階

1. 1

   Anthropicのサーバーに届く前に暗号化される

   リクエストは、Anthropicのサーバーへ届く手前の時点ですでに暗号化されています。

2. 2

   APIサーバーで復号・処理し、再暗号化する

   APIサーバーに届いた時点で復号して処理し、次へ渡す前に再暗号化します。

3. 3

   推論サーバーは暗号化したまま扱う

   推論サーバーはリクエストを暗号化されたまま持ち、信頼されたローダーに送るときにだけ復号します。

4. 4

   応答はローダーを出る前に暗号化される

   完了した応答はローダーを出る前に暗号化され、APIサーバー経由で呼び出し元へ戻ります。

モデルの重みの扱いはもっと単純です。暗号化して保存し、ローダーで復号し、そこから外へは出しません。

暗号化の終端がどこにあるかで、見えるデータが変わる

Pattern Labsとの共同レポートのホワイトペーパーは、リクエストの暗号化に2通りの設計があると整理しています。どちらの設計かで、サービス提供者が入力を読めるかどうかが分かれます。

1つ目は、サービス提供者で暗号化を終端する方式です。クライアントはTLSなどで入力を送り、サービス側が復号してからTEE(信頼された実行環境)へ渡します。この時点でサービス提供者は入力を読めるので、データの機密性を守る設計にはなっていません。

2つ目はエンドツーエンド暗号化(E2EE)で、入力はTEEの内側でだけ復号されます。実現の仕方も2つ書かれています。クライアントがエンクレーブの証明書類(アテステーション)を検証し、そこに含まれる署名済みの公開鍵で暗号化する方法と、鍵管理システム(KMS)に「証明を提示したエンクレーブだけが復号できる」という方針を設定しておく方法です。

Anthropicの記事は、リクエストが「Anthropicのサーバーに届く前の時点で暗号化されている」と書いています。ただしAPIサーバーでは復号・処理・再暗号化が入ります。この段がホワイトペーパーのE2EE(復号はTEEの内側のみ)の定義にどう当たるかは、記事には書かれていません。この点は、「暗号化している」という説明を読むときの確認点になります。

信頼された環境であることはどう証明されるのか

レポートが定義する「信頼された環境」は3つの特徴を持ちます。ハードウェアで他のワークロードから隔離された暗号化メモリ、無効化されたデバッグ機能、そして正しいコードが動いていることの暗号学的な証明です。

暗号化メモリは、物理的な攻撃や悪意あるハイパーバイザーからの一部の攻撃を防ぎます。ただし、暗号化されたホストメモリをアクセラレータと共有する機能は、まだ十分に確立されていません。この部分は当面、クラウド事業者の物理データセンターとハイパーバイザーのセキュリティに依存するとされています。

デバッグの無効化と正しいコードの証明は、広く採用されている手法で実現できます。信頼できるプラットフォームモジュール(TPM)を信頼の起点にして、ブートの各段階を測定し、最終結果を表すハッシュを報告させます。このハッシュが、ローダーが想定どおり隔離され、署名・レビュー済みのコードを実行し、関連するデバッグ機能を無効にしている証明(アテステーション)になります。

ホワイトペーパーによると、測定値はPCR(Platform Configuration Register)の値として、ハードウェア固有の鍵で署名された証明書類に入ります。鍵サーバーがこの証明を検証し、受信者が安全だと示せたときだけ復号鍵を渡します。

暗号化メモリの限界を踏まえると、この仕組みは暗号学的な保証と運用上の信頼が併存する過渡期の設計です。「信頼できる環境かどうか」の最終判断は鍵サーバーが握ります。他の関係者が信頼されたコードを検証し、独立した鍵サーバーを管理するモデルも検討されています。実現すれば、データごとに強い機密性を保証できる可能性があるとされています。

アクセラレータを信頼の境界に入れる2つの方法

推論にはGPUなどのアクセラレータが欠かせず、CPU側のTEEだけ守っても足りません。ホワイトペーパーは、アクセラレータを境界に含める方法を2つに分けています。

くらべる

アクセラレータの組み込み方

第1の方法

アクセラレータ自身が対応する

アクセラレータが暗号化・隔離・証明の機能を自前で持ちます。暗号化されたパラメータを受け取り、アクセラレータ内の非公開メモリでだけ復号します。出力は外へ出る前に暗号化し、計算中はデバッグと計測の機能を無効にします。例としてNVIDIA H100の機密コンピューティングが挙がっています。

第2の方法

CPUのTEEに接続する

アクセラレータ自体は機密コンピューティングに対応しません。CPU側のTEEに「接続」して、その延長として扱います。ホワイトペーパーは、この方法は完全に密閉されたものではなく、CPUからGPUへのデータ受け渡しが暗号化されないため、一部のサイドチャネル攻撃を受けうると述べています。

第2の方法には、VM全体をTEEとみなす選択肢もあります。アクセラレータは定義上その内側に入りますが、OSや常駐サービスまで攻撃面になる点が弱みです。Anthropicの記事が信頼側を小さなローダーに絞り、推論サーバーの大部分を信頼しない側に置く構成も、攻撃面を小さく保つ点で通じます。

攻撃者に何を握られても守れるか — ホワイトペーパーの脅威モデル

脅威モデルの前提が強いのも、この文書の特徴です。ホワイトペーパーは、攻撃者がTEEの外側をすべて支配していると仮定します。推論システムに関わるマシンや、暗号化された重みを置くストレージバケットまで、攻撃者の手の内に入っている想定です。

さらに各当事者も、お互いを脅威とみなします。モデル提供者、データの持ち主、クラウド事業者が互いを信頼しない前提で、それでも機密を保てるかを問う設計になっています。

文書は、リスクを2種類に分けています。

• システム由来のリスク: ハイパーバイザーの欠陥、アクセラレータのファームウェアやドライバーの欠陥、ベンダー側のサプライチェーン攻撃、暗号方式そのものの破綻
• 導入に伴うリスク: 認証せずにエンクレーブを起動する、デバッグモードで動かす、通信を傍受される、鍵管理の方針を甘く設定する

導入に伴うリスクのうち、鍵管理の例が具体的です。クラウド標準のKMSに重みの復号鍵を置くと、管理者アカウントが乗っ取られた場合、攻撃者がポリシーを書き換えて自分に復号権限を与えられます。KMSの置き場所を決める時点で、誰を信頼するかの選択が済んでいるわけです。

退役させたエンクレーブも危険の元です。セキュリティ上の欠陥が見つかって廃止したエンクレーブのKMS権限を外し忘れると、攻撃者がその脆弱なエンクレーブを持ち込んで復号に使う「BYOVE(Bring Your Own Vulnerable Enclave)」攻撃が成立しうる、と書かれています。

ローダーのコードを誰が作り、誰が検証するのか

ローダーのコード自体が漏えい経路にならないかも、重要な論点です。ホワイトペーパーは、信頼の根拠を3層に分けて扱っています。

まずソースコードの監査です。モデル提供者とクラウド事業者の共同所有(shared-source)なら、双方がコードを監査できます。オープンソースにすれば、データの持ち主も監査に加われます。

次にバイナリが、監査したソースと一致する保証です。ビルド環境が侵害されると、監査済みのソースと違うコードが混ざります。当事者のどれか1者がビルドを握るだけでも、他の当事者は不正な機能が足されていないと言い切れません。対策として挙がっているのは3つです。

• 完全に再現可能なビルド: 1者が作ったバイナリを、他の当事者が自前のビルドで照合する
• バイナリ解析: 再現可能なビルドがない場合、BinDiffなどの解析ツールでソースと突き合わせる
• 事前に保証済みの第三者製バイナリを使う

最後にイメージの中身です。ベースイメージやライブラリなどの第三者コンポーネントは、侵害される入口になります。空のベースイメージ(DockerのFROM scratch)から始め、依存関係を最小に絞ることが勧められています。

今後の拡張として何が検討されているか

レポートは「Future directions」で、モデルが高性能になるほど、信頼されたローダー層に追加の安全対策が必要になる可能性に触れています。具体例は2つです。平文のモデル重みを保持するサーバーに対する通信帯域の追加制限(egress bandwidth limitations)と、安全性を判定するクラシファイアの署名がなければ推論を実行できない仕組みです。

「こうした機能が検討に値するかの議論を喚起したい」という位置づけで、確定した実装計画ではありません。

2つの案は役割が違います。帯域制限は、重みが盗まれる際に外へ持ち出せる量を絞ります。クラシファイアの署名は、推論そのものを実行する条件に安全性の判定を組み込みます。暗号化と検証が「誰が読めるか」を決める技術だとすれば、この拡張案は「読める立場の側ができること」を絞る方向です。

企業のデータガバナンス担当者は何を見ておくべきか

Confidential Inferenceが研究段階でも、Anthropicがモデル重みとユーザーデータの両方を暗号化保護の対象にしていることは、Claudeの導入を判断する材料になります。ただし、この記事で扱った内容は、すべてAnthropicが「目指す設計」の説明です。契約や設定で今日使える保護策とは分けて評価します。

関連する今日の機能に、Claude API advisorツールの結果暗号化があります。こちらは個別機能の仕様で、Confidential Inferenceのようなインフラ全体の設計とは別物です。機密情報をClaudeへ入力する場面の現行の扱いは、機密情報を入力する際の安全性で整理しています。

Anthropicはレポートの末尾で、ハードウェア設計者にも機密コンピューティング機能をチップへ組み込むよう呼びかけています。アクセラレータ自体にハードウェアの信頼の起点があれば、この種のシステムの信頼境界を大きく縮められるという理由です。裏返せば、現状はハードウェア側の対応が発展途上ということです。

まとめ

Confidential Inferenceが保証を約束するのは、設計どおりにローダーが動く場合に限られます。そのため、証明の仕組み・鍵の置き場所・ビルドの検証まで含めて初めて意味を持つ技術です。導入判断の材料にするときは、研究の方向性と、契約書やDPAに書かれた現行の保護策を別々に評価します。