← 記事一覧

NVIDIA がフロンティアモデルを制限した後、ZDR は何を証明するのか

Fable の30日間保持と OpenAI・Anthropic の約束から考える、企業が確認すべきデータ管理の境界

企業は、外部モデルにコードを読ませることには同意しても、ベンダーがそのコードを一か月保存することには同意しないかもしれない。この二つの判断は矛盾しない。作業のために一時的にデータを処理させる場合と、別の会社に長期間の保存、関連付け、取り出しを認める場合では、引き受けるリスクが違うからだ。

2026 年 9 月、NVIDIA がフロンティアモデルの利用を制限しているという報道が、この違いを浮き彫りにした。報道から、同社が Anthropic と OpenAI のモデルを全面的に使わなくなったとは言えない。そこで問われているのは、どのモデルが最も優秀かという話よりも具体的なことだ。安全監視にもデータが必要なとき、そのデータを残すかどうかを誰が決めるのか。

この記事の目次

報道、発表、因果関係を分ける

9 月 14 日、ロイターは The Information の報道を伝えた。NVIDIA は Anthropic のモデルを機密性の低い作業に限定し、Palantir は撤回できないゼロデータ保持の取り決めを求め、Booz Allen は独自のサイバーセキュリティ業務での利用を制限しているという。報道は Anthropic と OpenAI のデータの扱いに対する企業の懸念を取り上げているが、NVIDIA が両社のモデルを全面禁止したという正式な通知は示していない。各社も取材に対して直ちには回答していなかった。ロイターの報道

これとは別に、公に確認できる事実がある。NVIDIA と Palantir は 9 月 10 日、サプライチェーンの意思決定を支援する協業を発表した。NVIDIA 自身の業務から導入を始め、Nemotron を使い、独自データの管理権を重視するという内容だ。共同発表

この二つを合わせて考えることはできる。しかし、「Claude の保持方針が原因で NVIDIA は Nemotron に切り替えた」という、確認されていない因果関係で結んではいけない。自社モデルの導入では、業務への適合、費用、データ管理、製品戦略を同時に考慮している可能性がある。導入の発表は、報道から想像できる動機をすべて裏付けるものではない。

NVIDIA が以前から外部モデルを拒んできたわけでもない。同社は 4 月、GPT-5.5 を利用する Codex の社内導入を紹介し、すでに一万人を超える社員が使っていると説明した。承認済みのクラウド仮想マシン、社員ごとの専用環境、本番システムへの読み取り専用権限を用い、ZDR 方針を適用する構成だ。これは同社自身の説明であり、独立した監査結果ではない。それでも、問題が外部モデルを使うかどうかだけではなく、どの経路でどのデータに触れさせるかにあることは分かる。NVIDIA の導入説明

30 日間の保持が調達判断を変える理由

6 月 9 日、Anthropic は Fable 5 と Mythos 5 を発表した。同時に、このクラスのモデルでは複数のやり取りにまたがる複雑な悪用を検出するため、商用利用の通信内容を 30 日間保持する必要があると説明した。用途は安全上の防御であり、新しい Claude モデルの学習ではないと強調している。モデル発表と保持方針

ベンダーから見れば、一度のリクエストだけでは、複数のリクエストを組み合わせた攻撃を見抜けないことがある。顧客から見れば、内容全体が残ることで、その先一か月にわたり新たな保存先、アクセス手続き、インシデントにさらされる箇所が生まれる。双方とも安全を求めていても、そのために必要な条件は異なり得る。

これは「学習には使わない」という約束が覆されたということではない。その約束だけでは、もともとすべての問いに答えられなかったということだ。データがモデルの重みを変えなくても、ログ、悪用調査、障害診断、その他のサービスの状態として残る可能性はある。機密の設計、未公表の財務情報、サプライチェーン情報のリスクは、学習データに入るかどうかだけでは判断できない。

9 月 1 日、Anthropic は Enterprise Frontier Safeguards を発表した。安全監視のシグナルを顧客管理のクラウドストレージに保存し、鍵、権限、監査を顧客が管理する案で、同年秋の後半から段階的に提供する計画だった。それまでの間、条件を満たす顧客には一時的な ZDR の取り決めを提供するとした。仕組みの発表、顧客の利用資格の確定、個別システムへの導入完了は、それぞれ別の状態だ。9 月中旬の時点で、全顧客がすでに得た保証として扱うことはできない。EFS の発表

ZDR は四つの約束の総称ではない

ゼロデータ保持は、まず適用範囲のあるサービス上の取り決めだ。どの組織、どのエンドポイント、どの内容を対象に、いつまで保存するのか。「ベンダーがデータに一切触れない」とまとめてしまうと、かえって確認できなくなる。

約束 実際に答えている問い 別途確認すること
学習に使わない 入出力をモデルの改善に使うか 安全監視ログ、障害記録、人による調査の有無
ゼロデータ保持 合意した内容を永続的に保存するか 対象モデル、エンドポイント、データの種類、例外
人によるアクセスの制限 元の内容を誰が閲覧できるか 自動処理、承認による例外、アクセス記録
顧客がストレージを管理 保存先、鍵、権限を誰が管理するか 実行時の処理、再委託先、顧客自身の設定リスク

OpenAI のデータ管理文書は、学習目的の利用、悪用監視ログ、アプリケーションの状態を明確に分けている。API のデータを標準では学習に使わないことは、すべての機能が状態を持たないことを意味しない。ZDR を申請する場合も、対象となるエンドポイントの確認が必要だ。ファイル、会話、ベクトルストアなどに、通常のリクエストの設定だけで同じ保証が自動適用されるわけではない。OpenAI のデータ管理文書

この違いはエージェントで特に重要になる。一度の呼び出しでは内容を残さなくても、エージェントが使うファイル保管先、会話履歴、ツールのログ、第三者の検索サービスには情報が残るかもしれない。モデルの入口だけを審査しても、作業全体はカバーできない。

これまでは何を根拠に「残していない」と確認してきたか

正常に返された回答を見ても、サーバーが別にログを保存したかどうかは分からない。通信のキャプチャで送信内容は確認できても、ベンダー内部で行われたことをすべて把握できるわけではない。そのため、信頼できる ZDR は、数字のゼロを表示する画面ではなく、互いに対応する複数の証拠に支えられてきた。

まず契約で、保持期間、許される用途、再委託先、例外、変更通知、監査権など、範囲と責任を定める。アカウント設定は、その約束を組織、プロジェクト、モデル、API に適用する。構成資料はデータが通るシステムを説明し、運用記録はアクセス、削除、例外処理が合意どおりだったかを示す。独立監査は、特定の期間と統制について保証を与える。

確認する層 入手すべき資料 その資料で分かる範囲
義務 DPA、ZDR 契約、例外と変更の条項 責任を問う根拠であり、すべての呼び出しが適合した証明ではない
設定 組織の承認、エンドポイントの適格性、バージョン、保持設定 その設定に対応する経路だけをカバーする
データの流れ ログの場所、アクセス制御、キャッシュ、削除の仕組み モデル外の状態や後続サービスも説明する必要がある
運用 アクセス・削除記録、例外処理、監査報告 監査には対象範囲と期間があり、永久の保証ではない

SOC 2 の報告や ISO 認証だけで、この確認を省くこともできない。必要なのは、購入するサービスと関連する統制が報告の対象に含まれるかを見ることだ。ベンダーのサイトに認証のマークがあると確認するだけでは足りない。契約上の約束と実装の間に隙間があるとき、見落とされやすいのはエラーログ、キャッシュ、中間サービスである。

モデルの更新によって問題が再び生じることもある。以前承認したモデルには不要だった保持が、新しいモデルでは安全審査のために必要になるかもしれない。自動的に切り替われば、顧客は新たな判断をしていないのに、元の境界を越えてしまう。撤回できない約束が交渉の焦点になるのは、顧客が今日の設定だけでなく、ルールが変わったときに拒否する権利も求めているからだ。

厳格なモードの価値は、条件を満たさなければ止まること

ゼロ保持は「なるべくログを少なくする」という意向だけでは実装できない。条件を満たさない場合の動作を明確にする必要がある。モデルや機能が制約に適合しなければ呼び出しを拒否するのか、それとも黙って標準の保持方式へ切り替えるのか。

AWS Bedrock のデータ保持文書は、参考になる実装例を示している。厳格な非保持モードは、データ保存を必要とするモデルをブロックできる。一方、リクエストに store=false を指定するだけでは、プラットフォームの保持方針の代わりにはならない。対応するモードの詳細は更新されるが、制約を満たさなければ呼び出しを続けないという設計原則は明確だ。Bedrock の保持文書

企業はこの原則をもとに、自社の利用条件を設計できる。すべてのベンダーが永久に同じルールを使うことを期待する必要はない。公開資料は一般向けサービスへ、制限対象のデータは承認された経路だけへ送る。ファイルとツールは個別に審査し、モデルのバージョンが変われば再確認する。大切なのは、その一覧が調達資料の付属文書にとどまらず、実際のリクエストを制御することだ。

自社モデルなら組織をまたぐデータの経路を短くできるが、リスクが自動的になくなるわけではない。鍵、パッチ、権限、バックアップ、セキュリティ対応の責任は企業に戻ってくる。誰も保守しない自社運用サービスは、成熟したベンダーの管理されたサービスより脆弱な場合もある。

企業が具体的に答えられるべき問い

単に「ZDR に対応していますか」と尋ねるよりも、ベンダーと社内プラットフォームの担当者に、次の点を一緒に説明してもらう方がよい。

  • 今回の呼び出しは、どの組織、リージョン、モデルのバージョン、エンドポイント、中間サービスを通るか。
  • 入力、出力、メタデータ、ファイル、キャッシュ、ツールのログは、それぞれどこに、どれだけの期間保存されるか。
  • どの自動システムと担当者がアクセスでき、誰が例外を承認し、どのような証拠を残すか。
  • モデル更新や安全方針の変更時に誰が顧客へ通知し、顧客は引き続き保持を拒否できるか。
  • 条件を満たさなくなったとき、システムは拒否するのか、通知するのか、別のモードへ切り替えるのか。

この一連の証拠でも、「世界のどこにも一度も複製が存在しなかった」という絶対的な証明は得られない。それでも、曖昧な約束を、確認でき、拒否でき、責任を問える取り決めに変えることはできる。

フロンティアモデルは、この対立を大きくした。安全システムはより長く利用状況を見たい一方、企業は元のデータを早く消したい。調達判断で重要なのは、モデルの賢さだけではない。両方の要求を同時に満たせないとき、企業が自ら承認した境界を守り続けられるかどうかだ。

参考資料

写作附记

元のプロンプト

$blog-writer 出来事の経緯を詳細に整理する。消息称英伟达内部では Anthropic と OpenAI のフロンティアモデルの使用を制限し、機密データについては自社製 AI を使用するようにしているとのことだが、かつては各社はどのように ZDR を証明していたのか。

この3か月の記事を書き直してください。AI が書いた記事でなければ、書き直す必要はありません。

目次

コメント

この位置までスクロールするとコメントを読み込みます。