ハードウェアで隔離された環境内でAIワークロードを実行し、運用者がその中身を検査できないようにする機密コンピューティング企業のOPAQUEが、AIモデル開発者向けの新しいオープン標準を公開しました。この標準を使えば、モデル開発者は自社サーバーを離れた後、自社のモデルの重み(weights)がいつ、どこで復号されるかを自ら制御できるようになります。「Weight Custody Manifest」と呼ばれるこの標準は、開発者プレビュー版の仕様書、Python SDK、そして91件のテストケースを網羅する公開テストスイートとして提供されています。

今回の発表は、ある特有の板挟み状況を解消するものです。企業は自社データを使ってオープンモデルをファインチューニングする一方、AI研究機関は、ますます価値の高くなるフロンティアモデルを、自国の法的管轄内に留めるソブリンクラウドを含め、自らが管理するインフラ上での実行を求める顧客に引き渡すよう求められています。しかし、いったんモデルの重みが開発元のデータセンターを離れてしまえば、契約上の取り決めを技術的に強制する手段は開発元にはありませんでした。
WCMは、受け入れ側のインフラが、開発元が承認した条件に合致していることを暗号学的に証明するまで、モデルの重みを暗号化したまま保持します。さらに、その条件が後に変化した場合には、アクセス権を取り消すことも可能です。
「現在の機密AIは顧客をモデルから守るものです。しかしWCMはモデルを顧客から守ります」と、OPAQUEのチーフ・プラットフォーム・オフィサーであるイムラン・シディーク(Imran Siddique)氏は述べています。「モデル開発者には、自社の知的財産が合意済みの条件を満たす環境でのみ復号されるという証明が必要です。WCMは、どちらか一方に信頼を強いるのではなく、すべての当事者に検証可能な証明を提供します」
検証の仕組み
保護されたワークロードは、鍵ブローカーに対して使い切り型のチャレンジを要求します。CPU、そして必要な場合にはGPUのアテステーションが、そのチャレンジ、実行中ワークロードの計測値、そして転送鍵を、特定の起動インスタンスに結び付けます。ブローカーは、証明書チェーン、署名、失効状態、鮮度を確認したうえで、アテステーション済みのワークロードに対して復号鍵を封印します。条件が一致しなければ、鍵は発行されません。
OPAQUEによると、同社はこの検証プロセスをNVIDIA H100上、さらにAzureおよびGoogle Cloudでホストされた別個のAMD・Intelの機密コンピューティングサーバー上で実行し、SDKの独立した2つのビルドが5,948個のファイルにわたって同一の出力を生成したとしています。
このデモが証明していないこと
実際にこの標準を試してみると、OPAQUEが自社ハードウェアで実行した結果とは異なる体験になります。公開されているクイックスタートでは、ブローカーとワークロードのロジックが、合成された証拠データとプレースホルダーの鍵を用いて、単一の通常のPythonプロセス内で実行されるだけです。適合性テストスイートを実行すると91件のチェックすべてに合格します(第1レベル32件、第2レベル37件、第3レベル12件、第4レベル10件)。しかしこれらはすべて、リファレンスプロトコルのロジックを合成された証明書ルートに対して検証するものであり、GPUの暗号学的検証は完全にスキップされています。テストの合格は、記述されたとおりにコードのロジックが機能することを確認しているにすぎません。ハードウェア自体の検証には、開発元が実際に展開を予定するマシン上での別のテストが必要です。
ここには一つ明確な限界があります。正当な署名があるからといって、それが認可された鍵なのか、あるいは攻撃者がすでにハードウェアから抜き出した鍵なのかを区別することはできません。機密コンピューティング用チップに対する物理的攻撃は現実に存在し、文献にも記録されています。OPAQUEはこの問題を解決済みだと主張するのではなく、そうした研究成果を指し示すにとどめています。
翻訳元: https://www.helpnetsecurity.com/2026/09/10/weight-custody-manifest-open-standard/