NVIDIA Confidential Computing、ベアメタルを拡張し、AI開発者が信頼すべき相手を変える
NVIDIA Confidential Computingは専用のサードパーティーサーバーへと対象を拡大し、モデル開発者により大きな制御権を与える一方で、信頼できるソフトウェアに対する責任をなくすものではない。2026年10月21日に発表されたConfidential Bare Metalは、機密モデルやデータの管理を維持しながら外部のコンピューティング能力を利用したい組織を対象とする。中心にある緊張関係は所有権だ。ハードウェアを借りることが、その運用者にそこで稼働するすべてへのアクセスを認めることを意味してはならない。
これはAI開発者にとってのインフラ議論を変える。モデル開発者は、システムが誰のアクセスを制限するのか、誰のソフトウェアを信頼するのか、そして保護された情報をいつ利用可能にするかを誰が決めるのかを評価する必要がある。Microsoft Azureはすでに、ハードウェアに裏付けられた保護機能を備える、ソフトウェア定義のコンピューターである機密GPU仮想マシンを提供している。NVIDIAの発表は、機密AIを新たに発明するのではなく、別の導入選択肢を加えるものだ。
この違いはインフラチームにとどまらず重要である。企業顧客は、社内文書、独自コード、業務記録をAIサービスに委ねる。これらの素材をホスティングプロバイダーから保護することは、一つの露出リスクに対処するものだ。それらをAIサービス自体から保護するには、別個の境界、明示的なポリシー、そしてそのポリシーが維持されていることを示す証拠が必要となる。
NVIDIA Confidential Computing、ベアメタルという選択肢を追加
この発表は、モデル開発者がソフトウェアの制御を維持したまま、保護されたインフラを借りる方法を拡張する。
NVIDIAはConfidential Bare Metalの発表で、専用のサードパーティーハードウェア向け導入オプションを説明している。ベアメタルとは、顧客がプロバイダー管理の仮想マシン内だけで運用するのではなく、物理サーバーを直接利用することを意味する。
同社は現在、Confidential Bare Metal、Confidential Containers、Confidential Virtual Machinesという3つの導入オプションを提示している。コンテナはアプリケーションと依存関係をまとめ、Kubernetesはそのデプロイを調整する。これらの選択肢により、組織はワークロードの周囲にセキュリティ境界を設ける異なる方法を選べる。
NVIDIAはまた、Grace BlackwellおよびRubinシステム全体でのサポートに加え、インフラソフトウェア基盤であるNVIDIA DSX OSとの統合計画も発表した。これにより、この発表は個別のサーバー構成の範囲を超える。ただし、プラットフォームのサポートを、すべてのプロバイダーや地域での普遍的なサービス提供可能性と解釈すべきではない。
CohereはConfidential Bare MetalをModel Vaultに統合する計画だ。NVIDIAはこれを、ハードウェアに裏付けられた保護をGPU実行へ拡張するものと位置付ける。GPUは、モデルのトレーニングや提供を含む並列計算に使われるプロセッサーである。この発表は、独立して検証された導入結果ではなく、統合の意図を説明している。
有用な変化は運用モデルにある。開発者は、自社の知的財産を扱う環境への責任を維持しながら、別の場所でインフラを求められる。実行中の情報にハードウェアに裏付けられた保護を用いる機密コンピューティングは、そのキャパシティ判断の一部となる。
発表を評価する読者にとって、制御には正確な定義が必要だ。アプリケーションソフトウェアに対する制御は、ハードウェア保守に対する制御とは異なる。暗号鍵に対する制御は、スケジューリングに対する制御とは異なる。専用サーバーは一部の関係を単純化できるが、他の関係は契約や実装に依存したままとなる。
だからこそ、導入カテゴリーよりも実際の境界の方が重要だ。同様のセキュリティラベルを掲げる2つのサービスでも、顧客に課す責任は大きく異なり得る。両者を選ぶ組織には、各コンポーネントを誰が運用するのかについて明確な説明が必要になる。
したがって、この発表は技術的な選択肢と並んで調達上の問いも提示する。組織は、受け入れられないと考える管理アクセスを認めずに、必要なハードウェアを調達できるのか。この問いに答えるには、プロバイダーが機密コンピューティングを宣伝しているかどうかを確認するだけでは不十分だ。
モデル開発者は、自由と利便性も区別すべきである。望むソフトウェアスタックを運用できれば、プロバイダー管理の構成への依存を減らせる。一方で、開発者自身のリリースプロセス、セキュリティレビュー、インシデント対応の重要性は増す。
そのため、価値提案は具体的だ。このアプローチは、付随する作業を引き受けるほどソフトウェアの所有権を重視する組織に適している。すべてのエンタープライズAIワークロードがベアメタルへ移行すべきだと示すものではない。
クラウドプロバイダーは、より厳格なキャパシティ販売に直面する
プロバイダーは、顧客が借りられるハードウェアだけでなく、顧客がインフラ保護をどのように検証できるかも説明しなければならない。
Google Cloudは、ベアメタルAIインフラの発表を通じ、この拡張を独自に裏付けている。同社は、NVIDIA GB300 NVL72システムを搭載するA4X Maxインスタンスを、Confidential Bare Metalの導入先として挙げている。
Googleは、ハードウェアに根ざしたセキュアブートとアテステーションについて説明している。これは、プラットフォームの識別情報と承認済み状態を評価するために用いる暗号学的証拠を意味する。また、暗号化メモリーと、GPU間を接続するNVIDIAのリンクであるNVLinkも挙げている。これらは引き続き、提供アーキテクチャに関するプロバイダー側の主張である。
Googleの発表は、A4インスタンスにおける既存の機密コンピューティング提供と、ベアメタルオプションの導入を区別している。この違いは、準備状況を評価する際に重要だ。名前の挙がる統合は一般的なパートナーシップ声明より強い証拠となるが、読者には依然として製品固有の提供可能性に関する詳細が必要である。
プロバイダーへの圧力は、顧客の交渉上の立場から生じる。モデル自体が価値ある知的財産であるなら、アクセス条件はインフラ購入の一部になる。キャパシティだけでは、そのキャパシティが受け入れられるかどうかは決まらない。
調達チームにとって、これは異なる比較プロセスを示唆する。プロバイダーが示す証拠、承認判断に関する顧客の権限、不適切な構成を拒否する手順を評価すべきだ。マーケティング文言は、こうした回答の代わりにはならない。
別の市場へサービスを拡大する仮想的なモデル開発者を考えてみよう。エンジニアは適切なコンピューティングクラスターを見つけるが、セキュリティチームはホストの管理アクセスに異議を唱える。その場合、購買判断は、そのサービスが両チームの要件を満たせるかに左右される。
機密インフラは、この対立を解消する可能性のある経路を生む。しかし、購入者には依然として合意済みの責任分担が必要だ。変更を誰が承認するのか。障害を誰が調査するのか。誰がサービスを停止でき、復旧中に保護された情報はどうなるのか。
これらの問いは、地理的拡大の実務的な意味に影響する。ある場所が適切なハードウェアを提供しても、組織の運用要件を満たさない場合がある。逆に、技術的に受け入れ可能な保護モデルでも、追加の契約レビューが必要になり得る。
したがって、所在地と機密性は別個の評価基準であり続けるべきだ。前者は処理がどこで行われるかに関するものだ。後者は、システムの前提の下でどの当事者が情報へアクセスできるかに関するものだ。購入者は、どちらかを代替物として扱うのではなく、両方を記録することで利益を得る。
同様の区別は、プロバイダーの多様性にも当てはまる。ホスティングの選択肢が増えれば開発者の選択肢も広がるが、切り替えには、受け入れ先の環境が自社のポリシーを満たす証拠が必要となる。移植可能なアプリケーションが、自動的に移植可能なセキュリティ判断を意味するわけではない。
最も強力なプロバイダーの対応は、こうした判断を評価しやすくするものだろう。明確な構成ドキュメント、明示的なアクセス境界、現実的なサービスコミットメントは、顧客による提供内容の比較を助ける。それらがなければ、供給者リストが拡大しても、購入者の作業の多くは未解決のままだ。
専用ハードウェアと仮想マシンは異なる約束をする
有用な比較は、どの導入ラベルがより強く聞こえるかではなく、責任と保護境界に関するものだ。
Microsoftの既存の機密GPUオプションは、AMD EPYCプロセッサーとNVIDIA H100 GPUを組み合わせている。Microsoftは、機密仮想マシンと接続されたGPUにまたがる、ハードウェアで保護された実行境界である信頼された実行環境を説明している。
このドキュメントには運用上の制約も記載されている。機密GPU仮想マシンは専用ハードウェアを使用し、文書化された提供内容ではリサイズはサポートされていない。顧客は高可用性と災害復旧に引き続き責任を負う。こうした詳細は、アーキテクチャ比較に運用上の証拠が必要な理由を示している。
この基準と比べると、ベアメタルの拡張は制御の配分を変える。専用インフラを選ぶ開発者は、望むソフトウェアと管理モデルが追加の責任を正当化するかを問うべきだ。仮想マシンを選ぶチームは、対応するサービス上の制約を評価すべきである。
どちらの答えも、技術の名称から自動的に導かれるものではない。文書化された境界が要件に合う組織には、管理環境が適している場合がある。より大きなソフトウェアの自由は、それを維持する人員とプロセスを持つ別の組織に適している場合がある。
AWSは、分離コンピューティングエンクレーブを通じて別の比較対象を提供する。Nitro Enclavesは、親インスタンスから分離された制約付き環境を作成する。AWSは、エンクレーブ内に永続ストレージ、対話型アクセス、外部ネットワーク接続がないことを文書化している。
AWSは暗号学的アテステーションと、自社の鍵管理サービスとの統合もサポートしている。このサービスは暗号鍵を管理し、アテステーション証拠を評価できる。Nitro Enclavesは、焦点を絞った分離アプローチを示すものであり、同等のGPUキャパシティの証拠でも、発表されたベアメタル構成の代替でもない。
これらの例は、単純なベンダー順位付けよりも有用な競争上の枠組みを示す。購入者が比較しているのは、異なる保護単位と異なる運用形態だ。制約付きエンクレーブ、機密仮想マシン、専用ホストは、それぞれ異なる導入上の問いに答える。
どの違いが重要かは、組織のワークロードによって決まるべきだ。範囲を限定した機密操作には、モデル提供環境全体とは異なるニーズがある。厳格なカスタマイズ要件を持つサービスには、サポート対象の管理構成を中心に設計されたサービスとは異なるニーズがある。
これが、パフォーマンスに関する主張にも慎重さが必要な理由である。仮想化レイヤーがないことだけでは、ワークロード固有の結果は得られない。購入者は、想定する構成に対する測定値を求め、許容可能な動作が何かを説明すべきだ。
意味のある評価には、組織の実際のアプリケーション動作とサービス要件を含める必要がある。目的は、保護された導入が必要なサービスを提供できるかを確立することだ。好意的なアーキテクチャ図だけでは、その運用上の問いに答えられない。
同じ論理は、エンジニアリング上の労力にも当てはまります。あるデプロイメントがセキュリティ要件を満たしていても、チームが継続的に負担できる以上の作業を要する場合があります。それはアーキテクチャの有効性を否定するものではなく、その組織に適したアーキテクチャかどうかを左右するものです。
競争上の帰結として、選択肢の幅が広がる一方で、より正確な比較が求められます。制約事項を明確に文書化するプロバイダーは、購入者に具体的な評価材料を提供します。包括的な機密保持の約束に頼るプロバイダーでは、最も重要な違いが不明確なまま残ります。
モデル所有者も依然として信頼境界の内側にいる
インフラストラクチャプロバイダーからモデルを保護しても、モデル所有者から顧客情報が自動的に保護されるわけではありません。
NVIDIAの開発版ベアメタル脅威モデルは、この区別を明確に示しています。脅威モデルとは、セキュリティ設計の基礎となる敵対者、前提条件、限界を定義するものです。
ドキュメントによれば、Confidential Bare Metalはモデル所有者の特権ソフトウェアと管理者を信頼します。エンドユーザー情報を、その所有者またはその承認済みソフトウェアから隔離するものではありません。インフラストラクチャ所有者は、引き渡しと検証の後、ランタイム境界の外側に位置します。
この文書はまた、保護が実際のプラットフォームと設定に依存することも示しています。Grace Blackwellのベースラインでは、CPUとGPU間のチップ間リンクの暗号化や、ハードウェアによるPCIe暗号化は提供されません。PCIeはシステムコンポーネントを接続します。NVLinkの暗号化も、他のすべての通信経路に対する保護を確立するものではありません。
これらは文書化された制約であり、侵害されたデプロイメントの証拠ではありません。同時に、機密情報を運ぶすべての経路が同一の保護を受ける、という包括的な推論も妨げます。重要なのは、完全なデプロイメントが組織固有のリスク要因に対応しているかどうかです。
エンタープライズ顧客にとって、この信頼上の区別はベンダーのプライバシー主張の解釈を変えます。「当社のホスティングプロバイダーはこのワークロードにアクセスできない」という説明は、「当社のサービスはお客様の情報にアクセスできない」よりも狭い問いに答えるものです。
これらの記述は、セキュリティレビューでは分けて提示されるべきです。サービスはインフラストラクチャからのアクセスに対して意味のある保護を提供しながら、自身のソフトウェアを通じたアクセスを維持できます。購入者は、自分たちがどの命題を受け入れるのかを把握する必要があります。
社内の技術文書を検索するエンタープライズアシスタントを例に考えてみましょう。その顧客は、機密資料を不必要な第三者に公開することなく、有用な回答を求めています。インフラストラクチャ保護はその目的の一部に対応します。一方で、サービス自体のアクセスルールも同等に重要です。
そのため顧客は、誰が文書を取得できるのか、リクエストを確認できるのか、生成された回答をレビューできるのか、それらを処理するソフトウェアを変更できるのかを尋ねるべきです。これらはアプリケーションおよび運用ポリシーに関する問いです。ハードウェアの機密性に関する主張が、暗黙のうちにそれらを解決するわけではありません。
こうしたレビューを行うチームにとって、検索可能なナレッジベースは、アーキテクチャ上の意思決定やベンダーの証拠にアクセスしやすい状態を保つのに役立ちます。その文書化はレビューを支援しますが、評価対象となる保護そのものを提供するものではありません。
この区別は、公開メッセージにおいても重要です。モデル開発者は、自社アーキテクチャによって排除される特定の当事者を説明する必要があります。完全なプライバシーに関する広範な主張は、システムが依然として信頼している主体に対しても保護されると顧客に想定させかねません。
慎重な購入者は、その限定的な主張が自らのニーズに合致するなら受け入れることができます。問題は、購入者とプロバイダーが同じ言葉に異なる意味を与えるときに生じます。明示的な境界は、その不一致をデプロイ前に可視化します。
これが、NVIDIA Confidential Computingのベアメタル拡張における主なトレードオフです。開発者はインフラストラクチャからの独立性へ向かう道を得る一方、ソフトウェアの信頼に関する意思決定は引き続き自らが担います。このアーキテクチャは責任の所在を変えますが、顧客はなお、その結果として生じる構成を理解する必要があります。
起動時の検証成功はランタイムセキュリティを確定しない
ワークロードが承認済みの状態で起動したという証拠は、その後に何が起こるかという別の問いを残します。
MITREは、このより広範な問題を継続的リモートアテステーションのフレームワークで扱っています。2026年7月16日に公開されたこのフレームワークは、クラウドおよびAIワークロードでは起動時の検証だけでは不十分だと論じています。
MITREは、ワークロードが信頼された状態で開始した場合でも、ランタイム侵害を懸念事項として挙げています。同組織が提案するアーキテクチャは、検証をランタイムの完全性、振る舞いの保証、トランスポートのバインディング、AIワークロードのチェックへと拡張します。これは実装に依存しないフレームワークであり、NVIDIAの発表に対する評価判断ではありません。
この独立した視点は、デプロイメントの説明に有益な問いを投げかけます。購入者は、実行前に収集される証拠と、運用中に適用される制御の両方を理解する必要があります。これらを別々のレビュー項目として扱うことで、欠落した前提を明らかにしやすくなります。
たとえば、企業が特定のソフトウェアリリースを承認した後、更新を許可する場合があります。重要なのは、その変更がどのように承認プロセスへ入るかです。組織には、誰がそれを承認できるのか、どの証拠をレビューするのかを記述したポリシーが必要です。
関連する問いは例外対応に関するものです。本番運用チームは、想定されたコンポーネントが利用できない場合にサービスを復旧する必要が生じることがあります。購入者は、通常運用がすべての復旧経路をカバーすると想定するのではなく、緊急時の手順が約束された保護とどう関わるのかを確認すべきです。
これらは評価のための問いであり、導入済みシステムに対する非難ではありません。その目的は、アーキテクチャ上の約束を運用上のコミットメントへと転換することです。プロバイダーの回答は、顧客がレビューできる観測可能な挙動を説明すべきです。
回答の質は、誰が受け入れを管理するかにも左右されます。顧客がその証拠が自らのポリシーを満たすか判断できない場合、証拠の実用的価値は限定的です。検証と承認には明示的な関係が必要です。
この関係は、責任が複数の組織にまたがる場合に特に重要になります。モデル開発者、インフラストラクチャ運営者、エンタープライズ顧客、検証サービスは、それぞれ異なる優先順位を持つ可能性があります。レビューでは、意見の相違をどの当事者が解決するのか、また結果として生じるサービスリスクをどの当事者が負うのかを特定すべきです。
AIエージェントでは、機密性と権限も別々に議論すべきです。エージェントは、モデルを用いて行動を選択し、ツールとやり取りするソフトウェアです。その実行環境を保護しても、特定の行動が適切かどうかは決まりません。
したがって、エージェントをレビューする企業は、情報アクセスと併せて許可される行動について尋ねるべきです。どのシステムを変更できるのか。どのリクエストに人間のレビューが必要なのか。後の調査を支える記録はどれか。これらはアプリケーションの振る舞いと権限に関する問いです。
同じ分離は、ナレッジワーカーがセキュリティ上の主張を解釈する際にも役立ちます。サービスはホスティング側のアクセスに対する保護を改善できる一方で、保持、共有、自動化された行動に関するすべての懸念に答えるわけではありません。境界を理解することで、その改善の価値をより正確に評価しやすくなります。
実務上の含意は、階層化された購買判断です。インフラストラクチャに関する証拠は、判断材料の一部を支えます。ソフトウェアガバナンス、アクセスポリシー、運用手順は、別の部分を支えます。購入者は、完全なサービスを自らの要件に照らして評価すべきです。
可用性、本番環境の証拠、プロバイダー間の検証を注視する
次のシグナルは、発表されたアーキテクチャが、顧客が評価・運用できるサービスへと変わるかどうかを示すはずです。
最初のシグナルは、製品固有の可用性です。今後数か月にわたり、プロバイダーが対応ロケーション、構成、アクセス条件、サービス上のコミットメントを公開するかを注視してください。そうした情報は、この拡張が実用的なインフラストラクチャの選択肢を生み出すという見方を強めるでしょう。
名称のあるプラットフォームが、すべてのデプロイメント上の疑問に答えるわけではありません。購入者は、必要な構成が自身のワークロード向けに利用可能か、その運用条件が適合するかを知る必要があります。明確な文書化があれば、議論は発表文言の域を超えることができます。
これに対応する警告サインは、継続する曖昧さです。見込み顧客が対象となるサービスを特定できない、またはその構成要件を取得できない場合、実務的な拡張を評価することは依然として困難です。その場合、短期的なデプロイメントの柔軟性に関する結論は弱まります。
2つ目のシグナルは、モデル開発者とエンタープライズ顧客による本番環境の証拠です。有用な証拠は、導入済みの構成、意図された保護境界、それを運用するために必要な作業を説明するものです。これらの詳細を欠くマーケティング上の推薦は、購入者の問いへの回答としては限定的です。
性能報告では、顧客が実際に運用する保護されたデプロイメントを用いるべきです。購入者は、保守、ソフトウェア変更、復旧に関する説明も確認すべきです。こうした詳細は、アーキテクチャが日常的なサービス提供に適しているかを判断する助けになります。
有用であるために、証拠が機密性の高い内部設計を開示する必要はありません。責任、サポートされる挙動、観測された制約を明確に説明すれば、評価を支援できます。正直な制約は、普遍的な適合性を裏付けなく主張するよりも、信頼を強めるでしょう。
3つ目のシグナルは、プロバイダー間での検証です。ホスティング環境間でワークロードを移動する際、開発者が理解可能な承認ポリシーを適用できるかを注視してください。それは、機密性が別の孤立したデプロイメント構成を生むのではなく、インフラストラクチャの選択を支えるという議論を強化するでしょう。
プロバイダー間の検証は、すべてのプラットフォームが同一であると装うことを必要としません。組織が許容可能かどうかを判断できる程度まで、違いを可視化することが必要です。その判断を支える文書化は、有意義な進展となります。
より弱い結果では、各移行が不透明な証拠と説明されない例外に依存したままになります。開発者は追加のサプライヤーを得るかもしれませんが、自らのポリシーが移行先でも適用されるかについて、大きな不確実性に直面し続けます。それは、拡張されたデプロイメント選択肢の運用上の価値を制限するでしょう。
これらのシグナルを合わせることで、分析は発表の実際の約束に焦点を保ちます。NVIDIA Confidential Computingは、コンピューティング能力へのアクセスとモデルへのアクセスを分離する別の方法を開発者に提供します。重要な証拠は、プロバイダーが実際にその区別をどれほど明確に維持するかを示すでしょう。
この拡張を評価する企業は、具体的なワークロードと、排除する必要がある当事者の明示的なリストから始めてください。各保護の主張をその要件に対応付けるよう、プロバイダーに求めましょう。モデル所有者のアクセスと、インフラストラクチャ運営者のアクセスは分けて扱ってください。最新の構成文書、可用性の条件、ソフトウェア承認および復旧手順の説明を求めます。それらの回答を、アプリケーション、インフラストラクチャ、顧客データを担当する人々とともにレビューしてください。次に、同じ要件に基づいて提案サービスを既存のデプロイメントと比較します。Confidential Bare Metalによって、組織はどの信頼に関する判断を変更でき、どの責任を引き続き担う必要があるのでしょうか。
