· CTO Marcus テクノロジー  · 9 min read

「データを預けずに安全監視」は成立するか——OpenAIのPrivate Safety Processing

OpenAIは2026年8月19日、フロンティアモデルでのZero Data Retentionの提供と、Private Safety Processingのプレビューを公表しました。複数のやり取りをまたぐ危険を、担当者に内容を見せずに検知する設計です。技術選定の観点で整理します。

OpenAIは2026年8月19日、フロンティアモデルでのZero Data Retentionの提供と、Private Safety Processingのプレビューを公表しました。複数のやり取りをまたぐ危険を、担当者に内容を見せずに検知する設計です。技術選定の観点で整理します。

※ 本記事は2026年8月27日時点の公開情報に基づきます。仕様・提供状況は変化するため、最新情報は各社公式発表等をご参照ください。

OpenAIは2026年8月19日、フロンティアモデルにおけるZero Data Retention(ZDR)の提供と、あわせてPrivate Safety Processingのプレビューを公表しました。ZDRの約束は明快です。「OpenAIは、リクエストの処理後に顧客のプロンプトやモデルの応答を保持しない」。顧客のコンテンツはOpenAIの担当者がレビューできる状態には置かれず、企業顧客のデータは明示的なオプトインがない限りモデルの訓練に使われません(出典: OpenAI 公式)。

技術的な難所——「1回では分からない危険」

なぜ新しい仕組みが要るのか。OpenAIの説明は、エンジニアとして納得のいくものです。「最も深刻なAIの安全上のリスクは、単一のやり取りの中で常に見えるわけではない。有害な意図は、複数のやり取りをまとめて見たときに初めて明らかになることが多い」(出典: 同上)。

具体例として、悪意ある行為者が繰り返し安全機構を試す、複数アカウントで連携する、脅威を通常の調査に見せかける、といったパターンが挙げられています。さらにエージェント的なタスクでは、停止を指示された後も動き続けるといった形で、作業の途中から利用者の意図とずれていく危険もあると指摘されています(出典: 同上)。

従来のZDR対応の安全機構は、やり取りを1件ずつ評価します。1件ずつでは見えない危険をどう捕まえるか——これが技術的な課題でした。

設計の要点——「信号だけを返す」

Private Safety Processingの構造は、権限設計として参考になります。

ZDR構成では、顧客のコンテンツは顧客が管理する基盤に置かれたままです。あわせてOpenAIは、コンテンツをOpenAI側の基盤に顧客が管理する鍵で暗号化して保存する選択肢も「開発中」だとしています。この場合もOpenAIの担当者は鍵の複製を持たないため、内容にアクセスできません。自動化された仕組みが複数のやり取りをまたいでパターンを検知し、リスクが特定された場合、OpenAIが受け取るのは「どの種類の活動が関与しているかを示す、狭く定義された信号」であり、フラグが立った場合でも担当者はコンテンツにアクセスしない、とされています(出典: 同上)。

内容は渡さず、判定結果だけを渡す。 自社でログ基盤やアクセス制御を設計する際にも、そのまま応用できる考え方です。

「安全のためにデータを渡してください」への回答

背景として、OpenAIはこうも述べています。「最近のいくつかのフロンティアモデルの提供では、安全監視のために、機微なコンテンツをAI提供者が保持することを顧客が許可する必要があった。多くの組織にとって、そうした要件はセキュリティ上の義務や、自らが仕える人々への約束と衝突する」(出典: 同上)。

金融・医療・法務のように、顧客データの取り扱いに外部から制約がかかる業界では、この衝突は導入の可否を直接左右します。Private Safety Processingは現在、早期の顧客とともにテスト中で、9月からの提供開始と技術白書の公開が予定されています(出典: 同上)。

中小企業への翻訳——「どこに残るか」を契約前に確認する

高度な仕組みですが、実務で確認すべきことは単純です。

  1. 入力したデータがどこに、どれだけ残るかを確認する。 保持しない/保持する/保持するが暗号化される。この3つは契約条件として明示できるものです。

  2. 訓練利用の可否を明示的に確認する。 既定でオプトアウトなのか、申請が要るのか。無料プランと有料プランで条件が異なることも珍しくありません。

  3. 「安全のため」に何を渡しているかを把握する。 提供者がリスクを検知する仕組みは必要です。問題は、そのために自社の内容そのものを渡しているかどうかです。

この3点を確認できないサービスに、顧客の個人情報や取引条件を入れるべきではありません。逆に、確認さえ済めば、AIの利用範囲は大きく広げられます。

まとめ

  • OpenAIは2026年8月19日、フロンティアモデルでのZero Data Retentionの提供と、Private Safety Processingのプレビューを公表。ZDRではリクエスト処理後にプロンプトと応答を保持しない
  • 背景は「単一のやり取りでは見えない危険」。繰り返しの安全機構の試行、複数アカウントでの連携、停止指示後も動き続けるエージェントなどが例として挙げられている
  • 設計の要点は、顧客の基盤に置くか(あるいは開発中の選択肢として顧客管理の鍵で暗号化したうえで)、自動化された仕組みが横断的にパターンを検知し、OpenAIには狭く定義された信号だけが返る点。担当者はフラグ時もコンテンツにアクセスしない
  • 提供は早期顧客とのテスト段階で、9月からの提供開始と技術白書の公開が予定されている。企業側の実務は「どこに残るか」「訓練に使われるか」「安全のために何を渡すか」の3点確認

AIの利用可否を決めるのは、性能ではなくデータの扱いです。「便利だが情報の行き先が分からない」道具は、業務の中心には置けません。内容を渡さずに安全を担保する設計が標準になれば、これまで導入をためらってきた領域が動きます。技術選定の第一基準は、いまも昔もデータの行き先であると私たちは考えます。

※ 本記事は一般的な情報提供を目的としており、個別の法的・財務的・経営的助言ではありません。具体的な課題については専門家にご相談ください。

この記事のテーマについてご相談されたい方へ

代表 服田伸人が率いるHatta AI Groupでは、中小企業の経営課題に関するご相談を承っています。

お問い合わせはこちら

Related Posts

View All Posts »
Moonshot AI「Kimi K3」2.8兆パラメータ・1Mコンテキスト——技術選定の軸は「重みを自社に置けるか」へ
テクノロジー

Moonshot AI「Kimi K3」2.8兆パラメータ・1Mコンテキスト——技術選定の軸は「重みを自社に置けるか」へ

2026年7月16日、中国Moonshot AIが総パラメータ2.8兆・コンテキスト長1,048,576トークンの旗艦モデル「Kimi K3」を発表しました。重みの公開は7月27日までと予告されています。規模の数字ではなく、重みを自社側に置ける選択肢が技術選定に何をもたらすかを読み解きます。

MicrosoftがCopilotを内製「MAI」モデルへ切り替え開始——LLMは「選ぶ」から「切り替えられる設計」へ
テクノロジー

MicrosoftがCopilotを内製「MAI」モデルへ切り替え開始——LLMは「選ぶ」から「切り替えられる設計」へ

MicrosoftがExcelやOutlookのCopilot機能で、OpenAI・Anthropicのモデルを自社開発「MAI」モデルに置き換え始めたと報じられました。世界最大のAI配布チャネルによる内製切替と、同じ週のFable 5提供再開が示す教訓——LLM選定は一度きりの決定ではなく、切り替えられる設計だという話です。