Private Safety Processingとは？OpenAIのZDR維持型AI安全監視を徹底解説

Private Safety Processing（プライベート・セーフティ・プロセッシング）は、OpenAIが2026年8月19日にプレビュー公開した、ゼロデータ保持（Zero Data Retention・以下ZDR）を維持したままAIの不正利用パターンを検知する安全処理システムです。

Anthropicが6月にCovered Modelsで30日データ保持を必須化した動きに対し、OpenAIは「データを預けなくても自動システムがパターン検知できる」設計を打ち出し、ZDR運用を続けたい企業向けの明確な差別化として位置づけました。

本記事では、仕組み・AnthropicのCovered Models 30日保持との構造的な違い・Apple Private Cloud Computeなど周辺技術との位置関係・早期テスト企業の活用シーン・料金と提供条件・9月ホワイトペーパー待ちで判断すべき論点・エンタープライズがいま取るべき判断までを、2026年8月時点の一次情報で体系的に解説します。

Private Safety Processingとは？OpenAIがZDRを維持したままAI悪用を検知する新しい安全処理

Private Safety Processing（プライベート・セーフティ・プロセッシング）は、エンタープライズAIの現場で長らく両立できなかった「データを預けない」と「不正利用を検知する」を両方成立させるためにOpenAIが2026年8月19日にプレビュー公開した、ZDR（Zero Data Retention・以下ZDR）互換の安全処理システムです。

既存のZDR互換の安全システムは1インタラクション単位で有害性を評価してきましたが、Private Safety Processingは関連する複数インタラクションのパターンまで自動分析の範囲を広げ、OpenAI職員がコンテンツにアクセスすることなく不正利用の兆候を検知する設計になっています。

本サービスが業界で注目された背景には、Anthropicが6月9日にCovered Models（Mythos-class以降の上位モデル）で30日データ保持を必須化した動きがあります。「安全監視のためにはデータを預かる必要がある」というAnthropicの立場に対し、OpenAIは「データを預けなくても複数会話のパターンから検知できる」設計で差別化を打ち出しました。

現時点はプレビュー段階で、9月に本格ロールアウトと技術ホワイトペーパーの公開が予定されています。

---

ZDRと安全監視が両立できなかった構造的な壁

そもそもエンタープライズ向けのAIサービスでは長い間、「顧客データを預からない（ZDR）」と「不正利用を検知する」が構造的に両立しづらい関係にありました。本セクションでは、Private Safety Processingが解こうとしている壁の中身を整理します。

従来ZDRの1インタラクション評価の限界

OpenAIの既存ZDRは、eligible API customer向けに「リクエストの処理が完了した後、プロンプトと応答を保持しない」ことを約束する契約オプションとして提供されてきました。ChatGPT Enterprise・ChatGPT for Healthcare・ChatGPT Edu・API Platformの各サービスで、SOC 2 Type 2 監査・AES-256の保管時暗号化・TLS 1.2+の伝送時暗号化・DPA執行可能を軸に運用されています。

ただしZDRのもとで動く従来型の安全監視は、1つのプロンプトと応答のペアを単位に有害性を分類する設計でした。単発の質問が有害かどうかは判断できても、複数の会話にまたがる悪意（脆弱性リサーチの分散化、セーフガードの繰り返し試行、アカウント間の協調行動）は原理的に検知できないという制約が残っていました。

OpenAIのAleah Houze（Head of Product Policy）は取材でこの限界について、「リスクは、1つのプロンプトと応答のペアを見るだけでなく、複数のインタラクションを時間軸で見たときに初めて浮かび上がる」と説明しています。具体例として、あるユーザーが1つの会話でソフトウェアの弱点を尋ね、別の会話でリモートアクセス手法や、それを検知するセキュリティツールを尋ねるようなケースが挙げられています。

Agenticタスク時代の長時間タスク中のズレ

もう一つの構造的な壁は、Agenticタスク（AIエージェントが長時間・複数ステップの作業を自律実行するタスク）の広がりです。

エージェントが数十〜数百ステップの処理を回すあいだに、途中でユーザーの意図から逸脱したり、停止指示を出したあとも動き続けたりするmisalignmentが起きることがあります。1インタラクション単位の安全評価では、こうしたタスク全体の文脈でしか見えないズレを捉えられません。

OpenAI公式ブログは「AIシステムがより長く、より複雑なタスクを扱うようになるにつれ、この広範な文脈が正当な活動と不正利用を区別するために不可欠になる」と述べており、Agenticタスクへの本格対応がPrivate Safety Processing設計の直接の動機になっていることを明かしています。

監視のためのデータ保持への抵抗

Anthropicが6月9日にCovered Modelsで30日保持を必須化した動きは、まさに「安全監視のためにデータを預かる」方向の判断でした。しかしThe Register報道によれば、この方針は金融・医療・法務など機密データを大量に扱うエンタープライズから強い反発を招きました。

規制業種で運用されるサービスは、DPA（Data Processing Addendum）や顧客との契約で「モデル学習に使わない」だけでなく「そもそもプロバイダー側に保持されない」ことを求められることが多く、30日保持の義務化は既存契約と衝突する構造になっていたためです。

OpenAIはこの反発を背景として、「ZDRを諦めずに安全監視も強化できる」設計としてPrivate Safety Processingを打ち出しました。産業構造の観点では、両社の判断の分岐点はほぼ同時期（Anthropic 6月9日、OpenAI 8月19日）に固まっており、フロンティアモデルの「安全性と機密性の両立」がベンダー選定の第一級の論点になったタイミングと重なります。

---

Private Safety Processingの仕組み

ここからは、Private Safety Processingが技術的にどう動くのかを、OpenAI公式の説明を軸に整理します。「関連する複数会話をどうつなげて分析するか」「シグナルとして何が返るか」「データはどこに保管されるか」の3点が中核です。

データ保管の2つの選択肢

OpenAI公式ブログによれば、Private Safety Processingは以下の2種類のデータ保管形態で動作します。

保管形態	保管場所	暗号化キーの持ち主	想定顧客
ZDRデプロイ	顧客が管理するインフラ	顧客	既存ZDR eligible API customer
OpenAI管理サーバー（開発中）	OpenAIインフラ	顧客が管理	ZDR未契約でも保管を委ねたい企業

いずれの形態でも、OpenAI職員は暗号化キーのコピーを保持しないと明言されており、原理的にコンテンツを復号できない設計です。自動システムのみがコンテンツにアクセスし、パターン分析を実行します。

The Registerの技術解説によれば、この構造は「顧客管理鍵で暗号化されたOpenAIサーバーで動くローカル分析」と説明されており、暗号化の実装詳細（AES-256-GCMなど具体的なアルゴリズム）は9月公開予定のホワイトペーパーで明らかにされる見込みです。

複数インタラクションをまたぐパターン検知

Private Safety Processingの中核機能は、「関連する複数のインタラクション」を1つの分析対象として結び付けることです。

OpenAI公式は「既存のZDR互換安全システムは各インタラクションを個別に評価する。Private Safety Processingはそれらの保護を関連インタラクション全体に拡張する」と説明しています。関連性の判定基準（同一ユーザー・同一アカウント・同一プロジェクト・同一トピックなど、どの軸でつなげるか）の技術的な詳細は現時点で非公表です。

Aleah Houze氏が示した具体例は分かりやすい説明になっています。ある人物が1つの会話で「ある会社のソフトウェアの弱点」を尋ね、別の会話で「リモートアクセスの手法」を尋ね、さらに別の会話で「セキュリティツールが何を検知できるか」を尋ねる——このように単発では正当なリサーチに見える質問が、時間軸で並べて初めて悪意を持った探索として浮かび上がるケースを検知できると想定されています。

シグナル発報時の運用

パターン検知でリスクが特定された場合、OpenAI公式は「活動タイプを示す、狭く定義されたシグナル（narrowly defined signal）」を受け取る、と説明しています。

このシグナルの粒度が具体的にどこまで細かいか（ラベル+重大度の2軸のみか、活動カテゴリの列挙まで含むか）は現時点で公開情報が限定的です。explainx.aiは「煙感知器のように『既知の悪パターンに一致した』と報告するだけで、部屋の中身は伝えない」と、監視カメラではなく煙感知器のメタファーで整理しています。

シグナル発報後の運用フローは以下のとおりです。

• OpenAI側の判断
  シグナルを受けたOpenAIが、必要ならエンフォースメント（強制措置）を判断する。フラグ立てされた場合でも、コンテンツ本体へのアクセスは付与されない。
  
  

• 顧客側の調査
  顧客は自社システムに残っている情報（自社のアクセスログ・利用履歴）を使って警告内容とエンフォースメント判断を独自に調査できる。
  
  

• 異議申し立てや共同調査
  顧客が「正当な活動である」と主張したい、あるいは検証された悪用の調査でOpenAIと共同したい場合、必要に応じて追加情報を自発的にOpenAIに共有できる。

この設計は「デフォルトはOpenAIから見えない、必要ならデータの一部を顧客判断で共有する」という顧客主導の統制が徹底されている点で、Anthropic Covered Modelsの「デフォルトで保持し必要ならレビュー」型と発想が真逆になっています。

---

AnthropicのCovered Models 30日保持との構造的な違い

Private Safety Processingを理解する上で、AnthropicのCovered Models 30日保持ポリシーとの比較は避けて通れません。両社が同じ課題（フロンティアモデルの安全監視）に対して、まったく異なる設計思想で応じている点が本セクションの主題です。

AnthropicのCovered Models 30日保持ポリシー

Anthropicは2026年6月9日、Mythos-class以降の「Covered Models」を対象に、プロンプトと出力を30日間保持することを全プラットフォームで必須化しました。

以下の表で、Covered Modelsポリシーの適用範囲を整理します。

項目	内容
対象モデル	Claude Mythos（Mythos-class）以降の同等能力モデル
適用範囲	Claude Console workspaces / Claude Code with Enterprise ZDR / AWS Bedrock ZDR / Google Cloud Agent Platform ZDR / Microsoft Azure Foundry ZDR
コンシューマープラン	Claude Free・Pro・Maxは対象外（既存ポリシー継続）
保持期間	30日、その後自動削除（法的要請時を除く）
追加オプション	顧客管理暗号化キー・監査ログ設定可能

Anthropicが必須化に踏み切った理由は、best-of-N jailbreakingや国家支援型の高度な悪用パターンは個別リクエスト分析では検知不可能で、時限的なデータ集約が必要という技術判断です。しかし既存ZDR契約を結んでいた金融・医療の顧客からは強い反発が出ました。

両社の設計思想の分岐点

The Registerは両社のアプローチを「Anthropicはretain-then-review（保持してからレビュー）モデル、OpenAIはzero-retention-plus-signal（保持せずシグナルを飛ばす）モデル」と整理しています。

以下の比較表で、両社の主要な違いをまとめました。

項目	OpenAI Private Safety Processing	Anthropic Covered Models
データ保持	ZDR維持（保存しない or 顧客管理キー暗号化）	30日間保持を必須化
悪用検知の対象	関連する複数インタラクションのパターン	個別コンテンツ＋パターン集約分析
人間レビュー	児童性的搾取コンテンツ検知時のみ（顧客が自発的に共有した場合を除く）	フラグ立て時に承認済みレビュアーがコントロールされた経路で閲覧
コンテンツへのOpenAI/Anthropic職員アクセス	なし（暗号化キーは顧客が管理）	あり（30日間の保持期間内、承認レビュアー）
対象プラン	eligible API customer（Enterprise契約）	上位Mythos-classモデル全プラットフォーム

両社の違いは技術的な差というより、「安全性を担保するために顧客データにどこまで踏み込むか」という設計思想の分岐です。Anthropicは「best-of-N jailbreakingは実データを見ないと分からない」と判断してデータ保持に踏み込み、OpenAIは「シグナル抽出の自動化で十分に検知できる」と判断してZDRを維持しました。

選定への影響——契約見直しが発生する条件

両社のポリシー差は、実務のベンダー選定に直接影響します。特に以下の条件に該当する組織は、既存契約の見直しが必要になります。

• Anthropic ZDRを結んでいた金融・医療組織
  Covered Modelsを使う場合、DPA・顧客との契約で「プロバイダー側で保持しない」を約束していた条件と衝突する可能性がある。契約書レベルで再点検が必須。
  
  

• OpenAI eligible API customerでMythos-classモデル相当を求めていた組織
  これまでAnthropic Covered Modelsを想定していた高度なタスクを、Private Safety Processing対応のOpenAIモデルに寄せる選択肢が生まれる。ただし9月のホワイトペーパーで挙動を確認してから判断する。
  
  

• 両社を並行運用している組織
  「用途によって使い分ける」戦略が現実的になる。監査・ガバナンス要件を満たさないケースをどちらに寄せるかを、ケース別に整理する必要が出てくる。

両社の設計差は今後、規制対応・監査対応・データレジデンシー要件との組み合わせで、実務判断の分水嶺になっていく見込みです。

---

Apple PCC・Confidential Computingとの位置関係

Private Safety Processingを業界横断で見ると、Apple Private Cloud Compute（PCC）、Google Private AI Compute、NVIDIA H100/H200のConfidential Computingなど、「クラウドAIでもプライバシーを技術的に担保する」路線が2026年の共通潮流になっていることが分かります。本セクションでは、PSPが業界のどこに位置するかを整理します。

Apple PCCの第三者インフラ拡張

Appleは2026年6月、Private Cloud Computeを自社データセンター以外にも拡張し、GoogleおよびNVIDIAとの協業を通じてGoogle Cloud上のNVIDIA GPUでもApple Intelligenceワークロードを実行できるようにする発表を行いました。

Apple PCCは「使用データは要求を満たすためだけに使い、決して保存せず、Appleを含む誰にもアクセスできない」設計を維持したまま、第三者インフラへ拡張しています。ただし、サードパーティ開発者向けのアクセスは「severely limited」で、Apple自身のApple Intelligence機能とApp Store Small Business Programに限定されている状態です。

PSPと比べると、Apple PCCは「そもそもAppleがユーザーコンテンツを見ない」ことに強い焦点があり、悪用検知よりも「デフォルトでプライバシー」を優先する設計です。エンタープライズ向け機能というより、Apple製品エコシステム内のiOS・macOSユーザー保護が中心です。

NVIDIA H100/H200のConfidential Computing

ハードウェアレイヤーでは、NVIDIA H100/H200 GPUのConfidential Computing機能が2026年に本格的な実運用フェーズに入りました。

Intel TDX / AMD SEV-SNP / AWS Nitro EnclavesなどのCPU側TEEと組み合わせた「複合アテステーション」でAI推論を保護し、推論スループットのオーバーヘッドは1〜7%の範囲にまで抑えられています。

H200は192GB HBM3eメモリを持ち、CC modeが有効な場合、GPUセキュリティプロセッサ内で生成された鍵によりHBM書き込みがAES-256-GCMで暗号化される仕組みです。SOC 2 Type I認証・HIPAA準拠のエンタープライズ展開も可能な段階に到達しています。

PSPと比べると、Confidential Computingは「モデル推論そのものが技術的に保護された環境で動く」というハードウェアレイヤーの解決策で、レイヤーがまったく異なります。両者は補完的な関係で、規制業種の企業ではPSPとConfidential Computingを組み合わせる構成が今後の主流になり得ます。

業界潮流の中でのPSPの立ち位置

以下の表で、主要4アプローチを整理します。

ソリューション	レイヤー	プライバシー担保の方法	エンタープライズ向け成熟度
OpenAI Private Safety Processing	アプリ層（安全監視）	顧客管理キー暗号化＋自動シグナル	プレビュー（9月ロールアウト予定）
Anthropic Covered Models 30日保持	アプリ層（安全監視）	30日保持＋承認レビュアー	既に運用中（6月9日発効）
Apple Private Cloud Compute	クラウド推論層	「Appleも見られない」設計＋独立監査	Apple製品エコシステム限定
NVIDIA H100/H200 Confidential Computing	ハードウェア層	TEE＋HBM暗号化＋アテステーション	実運用フェーズ（1-7%オーバーヘッド）

この比較から見えるのは、PSPは「アプリ層で安全監視をZDR互換に再設計する」立ち位置で、Confidential Computingの補完として動く関係にあるという点です。エンタープライズ側では「アプリ層＝PSP／Anthropic」「クラウド推論層＝Apple PCC」「ハードウェア層＝Confidential Computing」の各レイヤーをどう組み合わせるかが、2026年後半の設計論点になっていきます。

---

早期テスト企業から見える想定ユースケース

Private Safety Processingは現時点で少数の早期テスト企業と共に検証が進んでいます。本セクションでは、公開されている早期テスターの構成と、公式コメントから読み取れる想定ユースケースを整理します。

早期テスト企業の構成

OpenAI公式ブログとメディア報道によれば、Private Safety Processingの開発フィードバックを提供した企業として以下4社が明示されています。

• Glean
  エンタープライズ検索・アシスタント基盤を提供。CISOのSunil Agrawal氏がPSPに関して公式コメントを寄せている唯一の企業。
  
  

• Databricks
  データ・AI基盤の主要ベンダー。The RegisterはMicrosoftと並ぶ早期テスターとして紹介している。
  
  

• Abridge
  医療AI（臨床会話のAI要約）を提供。医療業界の機密データ扱いが厳しい領域でのPSP評価を担当。
  
  

• Microsoft
  OpenAIの主要出資者・パートナー。早期テスターとしてMicrosoft自身のエンタープライズ展開への影響を検証。

4社の顔ぶれは「エンタープライズ検索・データ基盤・医療AI・クラウド基盤」と機密性の高いドメインが並んでおり、OpenAIがPSPを「機密データを大量に扱う企業」に照準を合わせて設計していることが読み取れます。

Glean CISO Sunil Agrawal氏の公式コメント

早期テスターの中でPSPに関して唯一公式コメントを出しているのがGleanのCISO、Sunil Agrawal氏です。OpenAI公式ブログには以下のコメントが掲載されています。

Enterprise AI adoption depends solely on customer control of data, with no direct or derivative use beyond the chosen service. OpenAI's no-training commitment and ZDR give Glean confidence to build with OpenAI. As models become more capable, OpenAI shows safety can advance without compromising the privacy and control that sustain enterprise trust.
（エンタープライズAIの採用は、選択したサービス以外で直接的にも派生的にも使われないという顧客のデータ統制に完全に依存します。OpenAIのno-training commitmentとZDRは、GleanがOpenAIとともに構築するための信頼の基盤です。モデルの能力が高くなっても、OpenAIはエンタープライズの信頼を支えるプライバシーと統制を損なわずに安全性を進化させられることを示しています。）
出典: OpenAI

Agrawal氏のコメントは、単に技術評価というより「顧客データの統制を維持したまま安全性が進化する」という設計思想への評価に重点があります。エンタープライズAI採用の意思決定者が最も重視する「no direct or derivative use（直接利用も派生利用もない）」というフレーズがそのまま登場している点は、PSPが顧客契約の実務要件を意識して設計されていることを示唆しています。

想定ユースケースの推測

現時点でPSPの具体的な導入事例（数値・削減効果・期間など）は公開されていません。プレビュー段階かつ9月ロールアウト予定という状況を踏まえると、当面は以下のような領域で活用が広がると見られます。

• エンタープライズ検索・社内ナレッジ（Gleanが該当）
  社内文書・機密プロジェクト情報を扱う検索アシスタント。ZDRは必須要件、複数会話をまたぐ機密漏洩リスクの検知が必要。
  
  

• 医療AI（臨床会話・診療サマリー）（Abridgeが該当）
  患者データを扱うAI。HIPAA準拠のためデータ保持は原則不可、複数患者にまたがるパターン悪用（不適切な情報引き出しなど）の検知が求められる。
  
  

• データ基盤上のAIエージェント（Databricksが該当）
  BigQueryやDelta Lakeなどのデータ基盤上で動くAI。データレジデンシー・監査要件が厳しく、ZDR維持は必須。
  
  

• クラウド基盤の統合サービス（Microsoftが該当）
  Azure Foundryなど各種SaaSとの統合。ガバナンス・監査ログ統制の一元化を狙う。

これらは推測ですが、早期テスターの業界構成から、PSPが**「機密性が最優先だが安全監視も必要」という規制業種の中核企業**を明確に対象としていることは読み取れます。

---

料金・提供条件・利用開始のステップ

Private Safety Processingの提供条件・利用可否は、2026年8月時点で公開情報が限定的です。本セクションでは、現時点で確認できる情報のみを整理し、9月ロールアウトで確定する見込みの項目を明示します。

提供対象——eligible API customer限定

OpenAI公式ブログは、Private Safety Processingを「eligible API customer using Zero Data Retention」向けに提供すると明記しています。具体的には以下の条件を満たす企業向けです。

• 既存のZDR契約を結んでいるeligible API customer
  通常のpay-as-you-goのAPIプランでは利用不可、negotiated enterprise agreementが必要。
  
  

• ChatGPT Enterprise / ChatGPT Business / ChatGPT for Healthcare / ChatGPT Edu
  これらの上位契約プランでは、既にワークスペース管理者がデータ保持期間をコントロールできる仕組みが提供されている（Private Safety Processing自体はプレビュー段階）。
  
  

• API Platform
  Enterprise agreement締結企業のうち、Private Safety Processingのプレビューに招待された企業のみ利用可能。

コンシューマー向けのChatGPT（Free/Plus/Pro）は現時点で対象外です。あくまでエンタープライズAI採用の文脈での機能提供にとどまります。

料金体系の現状——未公表

現時点で、Private Safety Processing自体の料金は公表されていません。The Registerや複数の技術メディアが「価格・レイテンシは未発表」と報じています。

OpenAI公式ブログには料金に関する言及がなく、9月ロールアウト時のホワイトペーパーで明らかにされる可能性が高い状況です。既存のZDR契約とセットで提供されるのか、追加オプションとして課金されるのか、シグナル発報のスループット制限があるのかも現時点では不明です。

ロールアウトのタイムライン

OpenAI公式ブログは、以下のタイムラインを提示しています。

時期	内容
2026年8月19日	プレビュー開始（Glean・Databricks・Abridge・Microsoft等の早期テスターに提供）
2026年9月（予定）	本格ロールアウト開始、技術ホワイトペーパーの公開
2026年9月以降	対象顧客の拡大（詳細な対象条件はホワイトペーパーで明示予定）

企業側が確定情報に基づいた導入判断を行えるのは、実質的に9月のホワイトペーパー公開後になります。

利用開始のステップ

現時点でPrivate Safety Processingを検討する企業が取り得るステップは以下のとおりです。

• STEP 1：現在のOpenAI契約がZDR対応のeligible API customerに該当するかを確認する
• STEP 2：OpenAIのアカウントチーム／営業窓口にPrivate Safety Processingの早期アクセス希望を伝える
• STEP 3：9月のホワイトペーパー公開まで詳細仕様・料金・SLA情報を待つ
• STEP 4：既存のZDR契約書・DPA・社内AIガイドラインを、Private Safety Processing追加を想定してレビュー準備しておく

プレビュー段階の招待は限定的ですが、9月ロールアウト以降は対象が広がる見込みなので、eligible API customerに該当する組織は早期のアカウントチーム連絡が現実的です。

---

検証待ちの論点と批判の中身

Private Safety Processingは注目される新機能ですが、プレビュー段階ゆえに検証待ちの論点も少なくありません。本セクションでは、公開情報から把握できる批判・懸念点と、9月ホワイトペーパー待ちの論点を整理します。

Matthew Green氏の批判

暗号理論の専門家として著名なJohns Hopkins大学のMatthew Green氏は、The Registerの取材で「Private inferenceは十分にプライベートではない」と指摘しています。

批判のポイントは、AIエージェントが機密データにアクセスしながら動くケースでは、Private inferenceだけでは技術的保護が不十分という点です。暗号化された状態で推論しても、シグナルとして返される情報（活動タイプの分類）から元のコンテンツの性質が推測されるサイドチャネル攻撃の余地は残ります。

この批判は、PSPが「顧客コンテンツはOpenAI側から見えない」と主張していても、シグナル粒度によっては実質的にコンテンツの一部が漏れる可能性を指摘しています。9月のホワイトペーパーで、シグナル定義の具体（活動タイプの列挙・重大度の粒度・アグリゲーションの単位）が公開された後、暗号研究コミュニティによる検証が本格化する見込みです。

シグナル粒度による内容推定リスク

日本語の技術メディアtech-noisy.comも、Private Safety Processingへの3つの留保として「シグナル粒度が細かすぎると実質的に内容推定可能」という懸念を挙げています。

具体的には、シグナルが「セキュリティ・生物化学・違法薬物・児童搾取」のような大分類だけであれば内容推定リスクは低いですが、「特定のセキュリティ脆弱性の種類」「特定の化学物質」まで細かい分類になると、シグナル自体から元のプロンプトの内容が推測できてしまいます。

OpenAI公式は「narrowly defined signal」と表現しているものの、具体的な定義は9月ホワイトペーパー待ちです。規制業種の企業が本番投入を判断する際は、シグナル定義のレベルを技術審査してからの意思決定が現実的です。

価格・レイテンシ未発表

Private Safety Processingの検証待ちで、実務判断に直結する項目が価格とレイテンシです。

• 価格
  複数メディアが「価格・レイテンシは未発表」と報じている。既存ZDRとバンドルなのか、追加課金なのか、シグナル発報のスループットにコスト連動があるのかも不明。
  
  

• レイテンシ
  複数会話をまたぐパターン分析を自動システムで走らせるため、応答速度への影響が読めない。Agenticタスクのリアルタイム性が求められるユースケースでの実用性は9月ホワイトペーパーの数値を待つ必要がある。
  
  

• スループット制限
  シグナル発報の頻度・分析対象の会話数・時間軸の遡り範囲に制限があるかどうかは現時点で不明。

これらは全て9月ホワイトペーパーで明らかにされる見込みです。それまでは既存の運用を大きく変える判断は控え、既存契約の見直し準備に留めるのが現実的です。

規制業種で評価保留が推奨される理由

tech-noisy.comは「規制業種での活用は年度末展開まで評価保留を推奨」と結論付けています。理由は以下の3点に集約されます。

• 技術仕様の詳細が公開情報として存在しない
  9月ホワイトペーパーが出るまで、シグナル定義・暗号化アルゴリズム・アテステーション手法などの技術審査ができない。金融・医療の監査対応で「技術仕様書」を要求される場面で提示物がない状態。
  
  

• サイドチャネル攻撃への耐性が未検証
  暗号研究コミュニティによる第三者評価が9月以降になる見込み。それまでは「攻撃耐性は不明」として扱うのが安全側の判断。
  
  

• 既存DPA・監査条項との整合が不透明
  既存の顧客契約に含まれる「モデル学習・派生利用の禁止」条項が、Private Safety Processingでのパターン分析にどう適用されるか、法務レビューが必要。

逆に言えば、9月のホワイトペーパー公開・技術審査・法務レビューが済んだ後は、既存ZDR契約者にとって強い追加価値になる可能性が高い機能です。判断のタイミングを「今」ではなく「9月〜年末」に置くのが実務的なアプローチになります。

---

エンタープライズが今取るべき判断（ケース別ガイド）

Private Safety Processingの登場は、エンタープライズがAIベンダー選定・データ扱い設計・監査ガバナンスをどう組み立てるかに直接影響します。本セクションでは、AI総合研究所の支援現場で見えているパターンも踏まえ、ケース別の判断軸を整理します。

直接使えない企業がいますぐやること

ほとんどの企業はプレビュー段階のPrivate Safety Processingに直接アクセスできませんが、ベンダー選定と社内ガイドライン整備の準備は前倒しできます。以下の表で、業態別の優先度高アクションをまとめました。

対象企業	いますぐやること	Private Safety Processing正式提供後の判断基準
金融機関（メガバンク・地銀・証券）	既存OpenAI/Anthropic契約のDPA・データ保持条項を再点検、Anthropic Covered Models 30日保持の適用可否をチェック	9月ホワイトペーパー公開後にPSPの技術審査を実施、Confidential Computingとの併用可否を評価
医療機関・医療AIベンダー	HIPAA・個人情報保護法の観点で「AIプロバイダー側の保持」が許容されるか法務確認、Anthropic Covered Modelsを避けるガイドラインを整備	Abridge等の医療AI導入事例を参照、AI総研の医療AI支援で使えるユースケースを整理
大手Enterprise SaaS開発企業	Glean相当の「エンタープライズ検索」機能を持つ場合、CISOが顧客への説明責任を負えるベンダー選定に切替を検討	Gleanの公式コメントを参考に、自社顧客契約との整合性を再点検
大企業のIT部門（DX推進）	社内AIガイドライン（ChatGPT Enterprise/Copilot/Claude for Enterprise使い分けルール）に「ZDR運用の統一方針」を追加	9月以降にPSP対応モデルを社内標準AIに組み込むかを判断
スタートアップ・中小企業	現行のOpenAI API/ChatGPT Business契約で満たすべき最低ラインを整理、Enterprise agreement締結の可否を検討	PSPは基本的にEnterprise向けなので、当面は既存ZDR代替（Azure OpenAI Service経由のDPA運用など）で対応

以下、各ケースの背景を深掘りします。

金融機関の場合——両社ポリシーの分岐が直接効く

金融機関では、既存のDPA・顧客契約で「AIプロバイダー側でデータを保持しない」を約束しているケースが多く、Anthropic Covered Modelsの30日保持は既存契約と衝突する可能性があります。

具体的な優先アクションは以下の3点です。

• 既存契約の再点検
  OpenAI・Anthropicとの契約書・DPAを法務が再レビュー。特に「モデル学習に使わない」だけでなく「保持しない」条項の有無と、Covered Models適用時の扱いを確認する。
  
  

• Claude Mythos級モデルの利用可否評価
  高度な脆弱性発見・複雑タスクの自動化にMythos級モデルが必要な場合、Covered Modelsの30日保持は避けられない。PSPが正式提供された後、OpenAI側の同等能力モデルへの切替を評価する。
  
  

• Confidential Computingとの併用検討
  Azure Foundry上でNVIDIA H100/H200のConfidential Computing機能とPSPを組み合わせる構成が、ハードウェア＋ソフトウェア両レイヤーで保護を担保する現実的な選択肢になり得る。

医療機関・医療AIベンダーの場合

医療分野では、HIPAA準拠・個人情報保護法の観点で「AIプロバイダー側でのデータ保持」がそもそも許容されないケースがあります。

Abridgeが早期テスターに含まれていることは、医療業界向けにPSPが明確に照準を合わせている証拠です。以下のアクションが有効になります。

• HIPAA準拠のZDR運用の維持を優先
  ChatGPT for Healthcareの既存ZDR運用を維持しつつ、PSPが正式提供された後の「安全監視のZDR互換強化」として組み込むロードマップを検討。
  
  

• AnthropicのCovered Modelsを避けるガイドライン整備
  臨床データを扱う用途では、Anthropic Covered Models（30日保持）ではなくAnthropicの通常モデルまたはOpenAI側のPSP対応モデルを標準にするガイドラインを整備。
  
  

• 医療特化Agentへの応用検討
  Abridge型の臨床会話AI要約Agentを社内で構築する場合、PSPは「複数患者に跨るパターン悪用の検知」に有効な可能性がある。

大企業のIT部門の場合——ガイドラインの統一が優先

大企業のIT部門・DX推進部門では、社内でOpenAI・Anthropic・Google Gemini・Microsoft 365 Copilotなど複数のAIサービスが並行運用されているケースが多く、各サービスのデータ扱いポリシーが揃わない問題が既に起きています。

導入判断で詰まりやすい論点は次の3点に集約されます。

• 部門ごとに違うAIサービスが選ばれていて、データ扱いポリシーが統一されていない
• ZDR運用が必須の業務データと、ZDR不要な一般業務データの分類基準が曖昧
• 監査対応で「どのAIサービスで何を照会したか」の統合ログが取れていない

これらは技術論というより運用ガバナンスの話で、Private Safety Processingを社内標準AIに組み込むタイミングでガイドラインを再整備するのが現実的です。実務では、既存のClaude for EnterpriseやAzure OpenAI Service経由のOpenAI利用と、9月ロールアウト後のPSP対応OpenAIモデルをどう組み合わせるかが焦点になります。

スタートアップ・中小企業の場合——既存ZDR代替で対応

Enterprise agreement締結が難しい規模の企業では、Private Safety Processingは直接の対象外になります。ただし、代替手段としてAzure OpenAI Service経由のDPA運用や、GPT-OSSなどのオープンモデルの自社ホスティングでZDR相当を実現する選択肢は残ります。

AI総合研究所の支援現場でも、Enterprise契約が困難な中小規模の顧客には「Azure OpenAI Serviceでリージョン統制＋DPA運用」を推奨するケースが増えています。PSPが正式提供された後も、しばらくはEnterprise契約組織が優先対象になる見込みなので、当面は既存の運用を維持し、9月以降の対象拡大アナウンスを待つのが現実的です。

---

ZDR運用を業務Agentプロセスと一体化するなら

Private Safety Processingの登場で、エンタープライズAIの安全監視とZDR運用の設計が変わりつつあります。ただし多くの企業は、PSPが正式提供される9月を待つよりも先に、現行のOpenAI・Anthropic・Microsoftモデルを業務プロセスに組み込み、ZDR運用・監査ログ・モデル切替を統合管理する基盤を整える段階にあります。モデル選定単独では動かず、業務Agent実行層・データ扱いポリシー・監査ログを統合する管理層が並行して必要です。

このレイヤーを担うのが、自社Azureテナント内で動くエンタープライズAIエージェント基盤です。AI総合研究所のAI Agent Hubは、Teamsから呼び出せる業務特化Agent群を1つのダッシュボードで統合管理し、PSPやCovered Modelsの世代交代を吸収しながら業務プロセスに載せる運用基盤として機能します。

• ZDR運用を統一した業務Agentプロセス
  OpenAI・Anthropic・Microsoftの各モデルをバックエンドに据えたAgent群を、統一されたZDR運用ポリシーの下で実行。ベンダー間のポリシー差を吸収し、業務側は「同じ運用ルールで動く」状態を維持できます。
  
  

• モデル世代交代を吸収する管理層
  PSP正式提供・Anthropic Covered Models新世代・GPT新モデルなど短サイクルの世代交代を業務Agent側で吸収。特定モデルのポリシー変更で業務が止まるリスクを回避できます。
  
  

• Agent単位でセキュリティ統制を1画面統制
  機密データ・業務コードを扱うAgentごとにアクセス範囲を設計。誰がどのAgentで何を照会したかを不変ログで残し、監査対応をそのまま提出できる形で保管します。
  
  

• データは100%自社Azureテナント内に保持
  業務データ・機密情報はAIの学習対象から完全除外。Azure Managed Applicationsとして自社テナント内で動作が完了する設計です。

AI総合研究所の専任チームが、フロンティアモデル選定から業務Agent基盤の統合設計まで一貫して支援します。AI Agent Hubのサービスページで、ZDR運用×業務Agent実装例をご確認ください。

---

まとめ

本記事では、Private Safety Processingについて、仕組み・AnthropicのCovered Models 30日保持との違い・Apple PCCなど周辺技術との位置関係・早期テスト企業のユースケース・料金や提供条件・検証待ちの論点・エンタープライズが今取るべき判断までを、2026年8月時点の最新情報で解説しました。

2026年時点で押さえておくべきポイントは次の3つです。

• Private Safety Processingは2026年8月19日プレビュー公開のZDR維持型AI悪用検知システム。関連する複数インタラクションのパターンを自動分析し、OpenAI職員はコンテンツにアクセスせず「狭く定義されたシグナル」のみを受け取る設計
• Anthropicが6月にCovered Modelsで30日保持を必須化したのに対し、OpenAIはZDR維持で対抗。両社は「保持してレビュー」と「保持せずシグナル」で設計思想が明確に分岐し、既存ZDR契約者は9月ホワイトペーパー公開後の再点検が必要
• 料金・レイテンシ・シグナル定義の詳細は未公表、Matthew Green氏の暗号研究者からの批判もあり、規制業種は9月ホワイトペーパー公開まで評価保留が現実的
  
  

企業のCISO・AIガバナンス担当者にとってPrivate Safety Processingは、「9月に自社が使えるかどうか」よりも「フロンティアモデルのZDR運用とAnthropic Covered Models型の保持型運用が明確に分岐した2026年後半に、自社のAIベンダー選定・データ扱いポリシー・監査ガバナンスをどう再設計するか」という問いを突きつける動きです。まずは既存のOpenAI・Anthropic契約のDPA条項を再点検し、9月ロールアウト後の技術審査で判断できる準備を整えるところから着手するのが、最も実用的な第一歩になります。