AIのベンチマークは、問題が学習側へ漏れた瞬間に「未知の能力」を測れなくなる。
しかし問題を隠すためにモデル重みを評価者へ渡せば、今度はモデル提供者の知的財産が漏れる。
2026年8月27日に公開された二重盲検評価は、この対立を契約ではなくGPU enclaveとリモートアテステーションで解こうとした。

この記事では、通常のAPI評価、第三者の隔離評価、二重盲検評価をアーキテクチャとして比較する。重要なのは新しいスコアではない。誰が平文を見られるか、誰の何を信頼するかを、評価パイプラインの設計で変えた点である。

この実証はモデルの優劣を示すランキングではない。公開された技術報告には評価スコアが掲載されておらず、検証対象は機密性を保ったまま評価を完走できるかというシステム設計である。

何が「二重盲検」なのか

従来の非公開ベンチマークには、二者間の根本的な緊張がある。

評価者は、問題や採点方法をモデル提供者に見せたくない
モデル提供者は、重みや推論コードを評価者に渡したくない
それでも両者は、正しいモデルと正しい問題で評価した証拠を必要とする

APIにゼロログ設定や契約を加える方法は、運用上は有用だ。ただしモデル提供者の基盤には平文プロンプトが到達するため、将来の事前学習や事後学習へ偶発的に混入しないことを技術だけでは証明できない。一方、評価者の環境へ重みをコピーすれば問題の秘密は守れるが、閉じた最先端モデルでは受け入れにくい。

今回のDouble-Blind Evaluation（DBE）は、モデルと問題を一時的なTrusted Execution Environment（TEE）へ別々に投入する。評価者は重みを見ず、モデル提供者は問題を見ず、外へ返す情報を集約指標に制限する。

3つの評価アーキテクチャを比べる

方式	実行場所	問題を見得る主体	重みを見得る主体	主な信頼の根	汚染耐性	運用負荷
通常のAPI評価	モデル提供者の基盤	モデル提供者	モデル提供者	契約、アクセス制御、ゼロログ	中	低
第三者の隔離評価	評価機関の閉域環境	評価機関	評価機関へ提出する場合は評価機関	中立機関、手続き、物理・論理分離	高	中〜高
二重盲検評価	アテステーション済みTEE	許可されたTEE内だけ	許可されたTEE内だけ	CPU/GPUのRoot of Trust、測定値、検証ポリシー	高	高

比較対象として、NISTは2026年7月24日にAITEのロードマップを公開し、同年8月に評価期間を開始した。AITEは非公開データを隔離テストベッドへ置き、共通データ・共通指標・共通採点でモデルを比較する。初期タスクは量子科学、ゲノミクス、公共安全のVLM画像分析3分野である。

NIST方式の強みは、中立な第三者がデータと採点を統制する点にある。DBEの差分はさらに狭く、第三者を含む参加組織の誰にも相手の秘密を渡さずに計算することを目標にする。つまり「隔離された場所を信頼する」設計から、「その場所で動くハードウェアとソフトウェアの測定値を双方が検証する」設計へ進んでいる。

実証に使われたスタック

技術報告の実証は、Google DeepMind、OpenMined、MLCommons、AVERI、Singapore AISIの共同作業である。中心となる構成は次の通りだ。

層	実証で使われたもの	役割
ホスト	GCP A3 Confidential VM、Intel TDX	ホストRAMをハードウェア暗号化
GPU	NVIDIA H100 80GB Confidential GPU	モデル重みを置くHBM3を保護
実行基盤	Google Cloud Confidential Space	一時的で隔離された実行環境を提供
協調・承認	OpenMined PySyft 0.10.x	二者の資産投入、コード確認、実行承認を仲介
モデル	Gemini 2.5 Flash Lite	JAX C++ Model ServerをUnix Domain Socketで提供
評価データ	MLCommons AILuminate AIRR 1.4のreserve setなど	過去にモデル処理されていない非公開プロンプト

報告書の構成図では、ホストRAMにAES-256、H100のVRAMにAES-XTS-256、CPUとGPU間に暗号化PCIe DMAを置く。公開APIを呼ぶのではなく、暗号化されたmTLS経路から重みと評価データをそれぞれenclaveへ流し込む。

AILuminateの問題は、CBRNE、サイバー攻撃、ヘイトスピーチ、自傷、暴力犯罪の誘発などを対象とした。プロンプトと出力の暗号化・復号、出力評価はAVERIが担当した。Singapore AISIの実証では、シンガポールの文脈における有害コンテンツ誘発用の非公開プロンプトセットも使われた。

信頼を作る7ステップ

DBEは、メモリ暗号化を有効にするだけでは成立しない。技術報告が示す処理は、次の流れに整理できる。

モデル所有者が重みと推論コードを、評価者が問題と評価コードを準備する
片方がGPU enclaveを起動する。起動者の特権は停止できることに限られる
双方がPySyftクライアントからアテステーション証明を取得する
必要なら偽のモデルや問題を使ったmock interfaceで接続部分を実装する
双方が暗号化経路でコードと秘密資産をenclaveへ送る
双方が、見える部分のコードと制限された非公開部分を確認して承認する
両者の承認が揃った時だけ計算し、許可された集約結果だけを返して環境を破棄する

ここで核になるのがリモートアテステーションである。起動時にfirmware、guest kernel、init、container runtime、application imageまでをハッシュ化し、ハードウェアのRoot of Trustにつながる鍵で署名する。参加者はデータを送る前に、署名、期待する測定値、使い回しを防ぐnonceの鮮度をそれぞれ検証する。

概念的には、次の条件を満たした場合だけ秘密を解放する。

release(secret) iff
  verify_vendor_signature(quote)
  and quote.nonce == challenge
  and quote.measurements == approved_tcb
  and both_parties_approved(code_policy)

IETFのRATS Architecture（RFC 9334）の用語では、enclaveがEvidenceを作るAttester、測定値とポリシーを照合する側がVerifier、その結果を基に秘密を渡すか判断する参加者がRelying Partyに相当する。暗号化は「中身を読ませない」ため、アテステーションは「期待した中身が動いていると確かめる」ためにある。片方だけではDBEにならない。

非公開コードをどう審査するのか

難しいのは、モデル重みだけでなく推論コードや評価コード自体にも秘密が含まれる場合だ。コードを完全公開できなければ、悪意ある非公開部分が問題や重みをネットワークへ送信するかもしれない。

提案はStructured Transparencyという考え方を使う。秘密部分の実装そのものは伏せても、そこから呼べる操作を、ネットワーク送信を行わないPyTorchやJAXなどの許可済みメソッドへ制限する。技術報告では、この制約付きredactionをsyft-restrictが検査し、PySyftがコード提出と双方承認を扱う。

これは秘密計算の魔法ではない。検証可能な公開部分、呼び出し可能な操作のallowlist、外向き通信を閉じた実行環境、出力ポリシーを組み合わせ、秘密部分が情報を持ち出せる経路を小さくする設計である。

正直な限界

1. Googleを信頼境界から完全には外せていない

技術報告は、Confidential Space guest OSの個々のbuildが秘密の署名鍵を入力に使うため、第三者がbit-identicalに再現できないと明記する。さらにアテステーション報告の署名・検証にGoogleのサービスを使う。Googleがモデル所有者でもある今回の構成では、検証経路にもGoogleへの信頼が残る。

2. すべての非公開コードをallowlist化できていない

Gemini 2.5 Flash Liteを公開ライブラリの層だけで動かすのは、この実証では工数が大きすぎた。独自メソッドの実装が残り、すべてのコードを閲覧またはallowlist検査できたわけではない。AVERIは説明を受けたうえで構成を受け入れている。

3. TEEは信頼を消さず、移動させる

参加組織間の信頼は減るが、CPU/GPUメーカーの鍵管理、firmware、クラウド実装、TCBの脆弱性は信頼対象として残る。サイドチャネルや供給網侵害まで自動的に解決するものでもない。

4. 実証の規模と性能データは限定的

公開された構成は単一のH100 80GBとGemini 2.5 Flash Liteが中心で、評価スコアや、この実証固有の詳細な遅延・コスト測定は示されていない。報告書は既存研究を根拠にenclaveの計算オーバーヘッドを5%未満と述べるが、今回のワークロードで独立に測った値として読むべきではない。複数ノードのH100/B200 confidential clusterは今後の課題である。

5. ボトルネックは人間の手続きに移る

報告書が最大の障害として挙げるのは計算負荷ではなく、法的合意、コードレビュー、組織間調整である。測定値や依存関係ハッシュを人が理解し続ける運用はスケールしにくい。

実務への含意

モデル選定のために公開ベンチマークを眺めるだけなら、DBEは過剰設計だ。しかし、次の条件が重なる評価では現実的な選択肢になる。

問題を公開すると学習汚染や攻略を招く
モデル重みを規制・契約・知財上の理由で移送できない
医療、サイバー、行政のように評価データ自体が機密である
第三者評価の独立性を、契約だけでなく技術証拠でも示したい

導入判断では、ベンチマークの問題数より先にデータフロー図を描くべきだ。「入力、重み、中間状態、個別出力、集約指標を誰が見られるか」を列にし、各境界に暗号化、アテステーション、allowlist、出力制限、破棄証跡を割り当てる。これにより、ゼロログAPIで十分なのか、中立機関の隔離環境が必要なのか、DBEまで必要なのかを説明できる。

DBEの価値は、ベンチマークを絶対に正しくすることではない。問題品質、採点妥当性、母集団代表性は別に検証が必要だ。それでも「モデル提供者が問題を見たかもしれない」「評価者が重みを得たかもしれない」という二つの疑念を、監査可能なシステム要件へ変換した点は大きい。評価の信頼性をスコアの小数点ではなく、信頼境界から設計するための一歩である。

参考リンク

Piloting the world's first double-blind AI evaluations

Double Blind Evals: Resolving the Dual Confidentiality Dilemma in AI Safety Auditing

NIST AI Technology Evaluation (AITE)

NIST AI Technology Evaluation Overview & Road Map Version 1.0

PySyft

Remote ATtestation procedureS (RATS) Architecture RFC 9334

Hopper Single GPU Attestation Example