実務的には、これは「データを一切残さない」仕組みというより、顧客管理型のデータ保持に近い提案です。
Anthropicは、限定的なデータ保持とレビューを安全対策の一部と位置付けています。同社が懸念するのは、巧妙な悪用が単独の一往復だけでは判別できないケースです。攻撃が複数回のやり取りを通じて段階的に進む場合、時間を追って確認できる記録があれば、パターンの発見や事後調査に役立つとしています。
一方、この判断には明確なトレードオフがあります。プロンプトと出力を保持すれば、不審な活動を再構成しやすくなる反面、機密情報、規制対象データ、法的な秘匿特権に関わる情報を扱う企業には、追加のデータガバナンス義務が生じます。Anthropic自身のリスク報告書も、ゼロ保持に慣れた顧客から反発を受け、事業上のリスクになり得ると認めたうえで、高度な攻撃の検知には必要だと説明しています。
つまり、このポリシーは「保持しても問題がない」という主張ではありません。企業は、調査に使える証拠の履歴を得る価値と、その元データを保存することに伴うリスクを比較する必要があります。
プロバイダー側でログを保管することは、規制の厳しい組織にとって受け入れにくい場合があります。企業は、データの保管地域、社内のアクセス制御、守秘義務、インシデント対応、法的な証拠開示、そして機密性の高いプロンプトを外部環境に置くことによる影響を検討しなければなりません。
顧客が管理するクラウドへの保存を認めれば、通常のプロバイダー保管よりも、データの管理主体に関する懸念へ直接対応できます。企業は、自社の認証・認可、地域別のクラウド構成、暗号鍵の管理、監視、保存期間に関するルールを適用できる可能性があります。ただし、実際の保護水準は最終的な実装と契約条件に左右されます。
OpenAIのPrivate Safety Processingは、ゼロデータ保持を維持しながら、関連する複数のやり取りにまたがる安全上のパターンを検知することを目指しています。OpenAIによると、システムは元のプロンプトや応答を同社の担当者に見せることなく、範囲を限定した安全シグナルを送信できます。ZDR環境では、顧客データは顧客が管理するインフラに残り、OpenAIのインフラに暗号化して保存し、顧客管理の鍵を使う方式も開発中です。
両社の構成の違いは、次のように整理できます。
これは単なる契約条項の違いではありません。時間をかけて進行する悪用をどう検知するかについて、異なるアーキテクチャを採用しているということです。Anthropicは再確認できる履歴を重視し、OpenAIはプライバシー保護型の計算とデータ管理の最小化を重視しています。
ただし、OpenAIの提案はまだプレビュー段階です。検知の範囲や有効性、誤検知・見逃しの特性、技術的な保護策、インシデント発生時のエスカレーション手順については、文書化、テスト、独立した検証を経るまで、確立した保証とみなすべきではありません。
選択は、プロバイダーが「ゼロ保持」とうたっているかどうかだけで決めるべきではありません。自社の脅威モデルとコンプライアンス要件に照らして、少なくとも次の点を確認する必要があります。
Anthropicの顧客管理型の選択肢は、再構成可能な監査履歴を重視し、自社環境で30日間の保存を管理できる組織に適する可能性があります。一方、OpenAIの方式は、生のコンテンツ保持やプロバイダーによるアクセスを受け入れられない組織にとって魅力的です。ただし、最も機密性の高い業務で利用する前に、技術資料と検証結果を求めるべきです。
現在の争点は、単純な「プライバシー対安全性」ではありません。安全監視の証拠をどこに置くのか、誰が管理できるのか、そしてコンプライアンスやインシデント対応の負担をどちらが負うのかという問題です。
Anthropicは、高性能モデルによる巧妙で複数段階の悪用を見つけるには、保持された履歴が必要だと考えています。OpenAIは、プライバシー保護型の処理によって、生の顧客コンテンツを保管しなくても同等の監視が可能だと主張しています。両方の主張は、システムが文書化され、広く導入され、独立評価を受けるまでは確定的な結論として扱うべきではありません。
企業にとって、モデルの性能は購入判断の一部にすぎません。データの管理主体、監査可能性、削除、アクセス権限、そしてプロバイダーが安全設計をどこまで説明できるかが、同じくらい重要な判断材料になります。