速報

LIFF SDKのXSSを公表|11月の旧版利用制限前にミニアプリを更新する

CATEGORY

Confidential G4が一般提供へ|AIの機密データを処理中も守る設計

※本ページのリンクにはプロモーションが含まれています。

GPUとCPUを隔離された実行境界に収めアテステーション合格後に鍵を渡す仕組みを表す概念イラスト

目次

Google Cloudは2026年10月21日、NVIDIA RTX PRO 6000 Blackwell Server Edition GPUを備えるG4インスタンスでConfidential Computingを一般提供したと発表しました。対象はCompute Engineの仮想マシンとGKEノードです。AIモデルの重み、利用者のプロンプト、検索で取り出した社内文書、生成結果を、保存中や通信中だけでなく処理中にも保護する選択肢が本番向けに広がりました。

今回の中心は新しい生成AIモデルではなく、AIを動かす実行環境です。通常の暗号化だけでは、推論中にGPUメモリーへ展開されたデータを扱う境界が残ります。Confidential G4はCPU側のAMD SEVとNVIDIAのConfidential Computingを組み合わせ、ハードウェアで隔離された環境を作ります。ただし、機密VMを選べばAIシステム全体が自動的に安全になるわけではありません。IAM、ネットワーク、ログ、入力データ、出力先、鍵管理は別の層として設計が必要です。

本稿はGoogle CloudとNVIDIAの一次資料を2026年10月22日に確認し、一般提供で確定した内容と、本サイトが提案する導入手順を分けて整理します。Googleが示した性能値は提供元の特定条件での測定であり、本サイトによる実測ではありません。

スポンサーリンク

一般提供で何が変わったのか

Google Cloudの発表によると、Confidential G4は36ゾーンで利用でき、標準のオンデマンド、Spot、Flex-start、予約を含む複数の調達方法に対応します。Google Cloudの構成資料では、対象のマシンタイプはg4-standard-48、CPUはAMD EPYC Turin、GPUはNVIDIA RTX PRO 6000です。仮想マシンを作成するときにAMD SEVを指定し、その後にGPUのConfidential Computingモードを有効化します。

既存の通常VMをそのまま機密VMへ変換することはできません。新しいインスタンスを作り、対応OSイメージ、ゾーン、GPUクォータを確認したうえで、データとワークロードを移す必要があります。対応イメージにはContainer-Optimized OS 125系、Ubuntu 22.04・24.04系などが挙げられていますが、実際の採用時は最新のサポート表を再確認します。

Compute EngineだけでなくGKEノードも対象になったため、既存のコンテナ化した推論サービスへ組み込みやすくなりました。一方、マルチノードのクラスターワークロードやHyperdisk Extremeには非対応という制約があります。大規模学習や複数GPUを前提とする構成では、「GPUを使える」だけで要件を満たすと判断せず、トポロジーとプロビジョニング方式を先に照合します。

守れる対象と守れない対象を分ける

Confidential Computingが狙うのは、使用中のデータをホスト管理者、ハイパーバイザー、クラウド基盤から分離することです。メモリー暗号化の鍵はハードウェア側で扱われ、リモートアテステーションにより、期待したCPU・GPU・ファームウェア・ドライバーの状態かを検証できます。ここに保存時の暗号化とTLSを組み合わせることで、保存・転送・処理の三つの状態を連続して守る設計に近づきます。

一方、アプリケーション自身にSQLインジェクションや認可不備があれば、正規の処理として機密データが読み出される可能性があります。プロンプトインジェクションでエージェントが許可済みのツールを誤用する問題も、GPUメモリー暗号化だけでは止まりません。出力を誤ったストレージへ保存する構成や、広すぎるサービスアカウント、過剰なログ記録も別問題です。機密コンピューティングは境界を強くしますが、アプリケーションの権限設計を代替しません。

そのため導入理由は「AIだから使う」ではなく、扱う資産と脅威モデルから決めます。顧客の非公開文書をRAGで検索する、社内コードを独自モデルへ渡す、複数組織が共同で機密データを分析する、モデル重み自体を保護したい、といった用途では評価価値があります。公開情報の要約だけを行う処理なら、費用と運用負担に見合うかを別に判断できます。

スポンサーリンク

アテステーションは確認画面ではなく鍵の条件にする

アテステーションは、実行環境が期待した状態であるという証拠を取得し、検証者がポリシーと照合する仕組みです。Google Cloudの資料では、CPU側のアテステーションレポートに起動処理、ハードウェア、ファームウェアなどの測定値が含まれます。GPU側ではドライバーとGPUデバイスを検証でき、NVIDIA GPUデバイスの検証ではVBIOSやソフトウェアの版を確認できます。

重要なのは、結果を担当者が一度見るだけで終わらせないことです。本サイトでは、モデル重みや復号鍵、機密データへの短期アクセス権を渡す前に、外部の検証サービスがアテステーションを判定する構成を提案します。合格時だけ鍵管理サービスやデータ配布サービスが短時間の資格情報を発行し、失敗・期限切れ・未知の測定値では処理を開始しません。

Google Cloudのドキュメントには、GPUアテステーションで測定レコードの不一致が起きる既知の問題も記載されています。回避には機密VMの完全停止と再起動が必要で、ゲストOSからの再起動では解消しないとされています。アテステーションを必須条件にするなら、失敗時に無条件で迂回するのではなく、ジョブを止めて証拠を保存し、再作成や完全停止を行う手順まで決めます。

Secure Bootとドライバーを運用対象にする

Google Cloudは堅牢なGPUドライバー検証のためSecure Bootを有効にするよう案内しています。Secure Bootにより署名されたドライバーだけを読み込み、NVIDIA GPUとのSPDMセッションとデバイスアテステーションの信頼の起点を作ります。NVIDIAの互換性資料では、RTX PRO 6000 Blackwell向けに互換性のあるドライバーと検証ツールの版を使う必要があります。

ここでの注意点は、更新を止めれば測定値が安定するわけではないことです。ファームウェアやドライバーの脆弱性修正は必要であり、更新後はアテステーションの許可ポリシーも見直します。新しい正規版をまだ許可していないと、健全なノードが機密データを受け取れなくなります。逆に、旧版を永続的に許可すると、修正後も弱い構成へ鍵を渡し続けます。

本番では、開発・ステージングで新しいイメージとドライバーを検証し、期待する測定値を承認し、少数ノードへ展開してから全体へ広げます。ロールバック先もアテステーションポリシーに登録し、有効期限を付けます。GPUファームウェアを独自にフラッシュすると不安定化やクラッシュの可能性があるため、Google Cloudの注意事項に従って管理された更新経路を使います。

スポンサーリンク

性能値は自社の一件完了時間で測る

Google Cloudはg4-standard-48でLlama 3、Llama 3.3、ResNet-50、SDXLを使った測定を行い、標準G4と比べたスループット低下が3.5%未満だったと報告しています。ただし、同社も構成やワークロードで結果が変わると注記しています。トークン生成速度だけをそのまま自社の遅延や費用へ当てはめるべきではありません。

検証では、モデル読み込み、RAG検索、入力整形、推論、後処理、保存までを含む一件の完了時間を測ります。コールドスタート、イメージ取得、ノード置換、アテステーション失敗時の再試行も分けて記録します。GPU処理がほぼ同じでも、起動や復旧の時間がサービス目標へ影響する可能性があります。

費用にはGPU料金だけでなく、NVIDIA Confidential Computingのライセンス料、対応リージョンへのデータ転送、予備容量、検証サービス、ログ、鍵管理、待機ノードを含めます。Google CloudのドキュメントはRTX PRO 6000を使うConfidential G4でライセンス料が自動的に発生すると説明しています。価格表と見積もりを確認し、通常G4との差額ではなく業務一件あたりで比較します。

導入前に実環境で確認する九項目

  1. 対象データとモデル重みのどれを守るのかを分類し、通常G4で許容できない脅威を文章にする
  2. 利用リージョンとゾーン、g4-standard-48の容量、GPUクォータ、調達方式を確認する
  3. 対応OSイメージ、NVIDIAドライバー、CUDAライブラリー、コンテナの互換性を固定した検証環境で確かめる
  4. Secure Bootを有効にし、CPU・GPU・ドライバーのアテステーション証拠を取得する
  5. 検証結果が合格した場合だけモデル鍵や短期資格情報を発行する仕組みを試す
  6. IAM、VPC、外部通信、保存先、監査ログを機密VMとは独立して最小化する
  7. 通常G4と同じ入力で品質、スループット、末尾遅延、起動時間、一件完了費用を比較する
  8. アテステーション不一致、ノード置換、Spot停止、ゾーン在庫不足を再現し、安全に停止・再開できるか確認する
  9. ドライバーやOS更新後の測定値承認、段階展開、ロールバック、旧版の失効を手順化する

Web開発チームが採用を判断する基準

Confidential G4は、個人情報や非公開文書をAI推論へ渡しつつ、クラウド運営層からの分離と検証可能性が契約・規制・顧客要件になる組織に向きます。特に、自社管理のモデルをGPUで動かす構成や、アテステーション結果を鍵解放へ結び付けたい場合は、一般提供になったことが評価開始の具体的な契機になります。

反対に、外部AI APIだけを呼ぶWebアプリでは、自社がConfidential G4を立てても提供先の処理境界までは変えられません。利用中のAPIに同等の保護があるか、保存期間、学習利用、地域、監査、削除条件を別途確認します。また、通常のCompute Engineへ置くだけの小規模処理では、移行と検証の負担が利益を上回る可能性があります。

社内文書を使うRAGでは、文書を安全なGPUへ渡すだけでなく、検索時のアクセス権と回答品質も必要です。検索品質の検証は「RAGの回答がずれるのはなぜ?文書分割と検索品質から改善する」で整理しています。Google Cloud経由のモデル採用条件と契約面は「Google CloudでOpenAIモデルを使う前に確認したい評価と契約」も参考になります。

結論として、今回の一般提供は「暗号化GPUへ移せば完了」という発表ではありません。実行環境を暗号学的に確かめ、その結果をデータや鍵を渡す条件として運用できることが本質です。小さな推論サービスで通常G4と並行評価し、アテステーション失敗時に安全に止まるところまで確認してから、機密性の高い用途へ段階的に広げるのが現実的です。

関連記事

スポンサーリンク

参考資料

この記事を書いた人

Ryohei

Webエンジニア / アプリ開発者 / 技術ブログ運営者

福岡のWeb制作会社に勤務するWebエンジニアです。10年以上にわたりWeb制作・開発に携わり、これまでに100以上のWordPressサイトの構築・保守を担当してきました。Webサイト制作に加え、アプリ開発やAIを活用した開発にも取り組み、近年はWebセキュリティにも注力しています。

2015年から技術メディア「Into the Program」を運営し、実務や開発で得た知識をもとに、プログラミングの実装方法やWebサイトの運用・セキュリティ情報を発信しています。

主な分野
WordPress / PHP / JavaScript / アプリ開発 / Webサイトの運用・セキュリティ対策
資格・試験合格
情報セキュリティマネジメント試験
基本情報技術者試験
AWS認定ソリューションアーキテクト アソシエイト
PHP8技術者認定ウィザード
メディア運営
2015年〜

記事の作成・更新について

セキュリティ記事は、ベンダーの公式アドバイザリやCVE・JVNなどの一次情報を参照し、出典と情報確認日を記載します。実環境での検証を行った場合は、その環境と確認範囲を明示します。重要な追加情報や誤りを把握した場合は、内容を確認して追記・訂正します。

スポンサーリンク

関連する記事

おすすめの書籍

キーワードから探す