共有する前に：AIのプライバシーに必要なのは約束だけではない

はじめに：その会話は、あなたの人生そのものになりつつある

難しい返信を書くために、AIアシスタントを開く。メッセージを貼り付け、相手との関係を説明し、ほかではまだ共有していない細かな事情も添える。別の日には、契約書をアップロードしたり、まだ形になっていないアイデアについて相談したり、受信トレイを接続して、何に注意を向けるべきかをアシスタントに理解させたりする。

こうした行為のどれも、何かを公表している感覚にはなりません。あなたは助けを求めているだけです。

それでも、その情報は会話ウィンドウからはほとんど見えないまま、インフラ、保存システム、レビュー工程、法的義務の中を通過していく可能性があります。アシスタントは、データの扱いがその期待に見合うようになるずっと前から、個人的な存在に感じられてしまうのです。

私の立場はシンプルです。AIのプライバシーは、企業が情報を受け取った後に何をすると約束するかだけに依存すべきではありません。そもそもそのシステムが、どの情報をモデルに届かせないようにしているかにも依存すべきです。ポリシーは重要です。しかし、その裏付けとなる技術的保護が必要です。

この記事は、Dvinaチームの協力を得て作成しました。ChatGPT、Claude、Cursor、Perplexity、Manus、MetaのMuse、そしてDvinaにおける、記録された事例と現在の運用を検証しています。目的は、AIが私たちの生活により深く関わるようになる中で、なぜプライバシーがエンジニアリング上の中心的な優先事項にならなければならないのか、そしてDvinaがその責任にどう向き合っているのかを説明することです。

事例が教えてくれること

懸念は仮説上のものではありません。ただし、証拠の種類が違えば、示している問題も違います。確認済みのデータ露出、認められた人によるレビュー、研究不正利用に関する申し立ては、同じ出来事であるかのように扱うべきではありません。

ChatGPTの2023年の露出：システムそのものの障害。

2023年3月20日、ソフトウェアのバグにより、一部のChatGPTユーザーが、別のアクティブユーザーの会話履歴にあるタイトルを閲覧できる状態になりました。OpenAIによれば、特定の状況では、新しく作成された会話の最初のメッセージも表示されていた可能性があります。同社の調査では、特定の9時間の間にアクティブだったPlus加入者の1.2%について、支払い関連情報が露出した可能性が確認されました。カード番号の全桁は露出していません。OpenAIはバグを修正し、影響を受けたユーザーに通知しました。1

ここから得られる教訓は、同じ脆弱性が今も放置されているということではありません。重要なのは、プライバシーに関する約束だけでは、システムが誤った相手に情報を返してしまうことを防げないという点です。分離、アクセスチェック、そして露出しうる識別可能情報の量、そのすべてが重要です。

The New York Timesの訴訟：削除は法的義務に直面した。

2025年、OpenAIは、本来であれば削除されていたはずのデータを保存するよう命じる裁判所命令に直面した。10月の更新では、新規データを無期限に保存するという広範な義務は2025年9月26日に終了し、一方で限定的な過去データの集合については引き続き法的保全の対象にあるとされた。当初の保存要件は、特定の製品およびゼロデータ保持の取り決めを除外していた。2

その後の展開は、別個に読む必要がある。2025年12月、Reutersは、著作権訴訟において裁判官がOpenAIに対し、2,000万件の匿名化されたチャットログの提出を命じ、OpenAIの異議を退けたうえで、再識別防止措置と保護的な安全策を根拠にしたと報じた。これは証拠開示命令であり、すべての人の私的なチャットがインターネット上で公開されるという話ではない。3

これらの出来事をあわせて見ると、削除設定だけでは保持された情報をめぐるあらゆる問題が片づかない理由がわかる。ひとたびコピーが存在すれば、ユーザーの管理外にある義務が、その後の扱いに影響しうる。不要な保持を減らすことは、紛争が始まる前の段階でその露出を変える。

人によるレビュー：侵害がなくてもアクセスは許可されうる。

OpenAIの一般消費者向け文書では、セキュリティ調査、サポート、法的事項、対象となるモデル改善など、特定の目的のために、認可された担当者およびサービスプロバイダーによる限定的なアクセスが明示的に認められている。Anthropicの一般消費者向けガイダンスでも、利用ポリシーの執行のために指定されたスタッフが会話を確認することが認められており、同意に基づくフィードバックに関連した別個のアクセスもある。4, 8

これらは文書化されたアクセス経路であり、噂ではない。だからといって、従業員がすべての会話を読んでいることを示すものではない。しかし、プライベートに見えるチャットインターフェースが、必ずしもプロバイダーによるアクセスに対する技術的な障壁ではないことは示している。

Anthropicの現行文書は、ビジネス側の重要な例も加えている。同社の指定Covered Modelsでは、以前はゼロデータ保持を用いていた一部の導入環境において、管理された人によるレビューと例外を伴う30日間の保持が求められる。このルールにはモデル、プラットフォーム、適格性の境界があり、Claudeのすべての製品に対する一律の変更ではない。一般消費者向けプランについては、これらの画面ではすでに入力と出力が保持されているため、影響を受けないと説明されている。9

安全性モニタリングには正当な目的がある。工学上の課題は、その目的を満たしつつ、モニタリングシステムやレビュアーが利用できる機微情報を最小限に抑えることにある。安全性を理由にしても、プライバシーの問題が消えるわけではない。

数学をめぐる論争：未解決の疑惑、現実の信頼問題

2026年9月に起きたOpenAIのNavier–Stokes発表をめぐる論争は、別の懸念を浮かび上がらせた。私的な研究を手伝うアシスタントが、自らも研究を行う企業に属している場合、何が起きるのかという問題である。

争点となったのは、未公表の数学的研究と功績の帰属だった。報道では、数学者のTristan BuckmasterとLevent Alpögeが自身の研究でAIツールを使っていたこと、そしてBuckmasterが、彼らの私的な資料がOpenAIの成果に寄与したのではないかと疑問を呈していたことが伝えられた。10

OpenAIはその説明に異議を唱えている。同社の公表した回答によれば、同社の研究者もその代理人も、公開前にその2人の研究を見ていない。さらに、9月10日付の更新では、調査により、直前の2か月間におけるBuckmasterのCodexプロンプトからの影響は、学習経由を含めて一切なかったことが確認されたと述べている。この期間を区切った説明は、一部報道における先行する説明よりも具体的である。11

公の説明はなお対立したままである。ここで検討した情報源だけでは、OpenAIがそれらの私的な会話を用いて自社の成果を生み出したことは独立には立証されない。

それでもこの争いは、明確に答える価値のある問いを露わにしている。人々が未完成の仕事をAIに持ち込むとき、その仕事の情報としての価値は何によって守られるのか。 証明から著者名を取り除いても、証明そのものは消えない。商業戦略を匿名化しても、その戦略が公有財産になるわけではない。

だからこそ、強いプライバシーには、本人識別情報と内容の両方を守る保護が必要になる。ユーザーは、自分の資料が学習、研究、評価、レビューのワークフローに入る可能性があるのか、そしてその境界をどのような技術的統制が担保しているのかを理解できるべきだ。

決して一つにまとめてはならない4つの問い

混乱の多くは、「プライベート」を単一の性質として扱うことから生じている。実際には、会話がどう扱われるかを決めるのは、別々の4つの問いである。

学習: その内容はモデルの開発や改善に役立てられるのか。オプトアウトは、情報の許容された利用方法を変える。それは必ずしも、その情報が送信されたか、保存されたかを変えるものではない。

アクセス: どのシステムとどの人がそれを閲覧できるのか。送信中および保存中の暗号化は重要だが、それによって認可されたサービスが処理やレビューのために内容を復号できなくなるとは限らない。

保持: 何が、どこに、どれくらいの期間残るのか。インターフェースからチャットを削除すること、本番記録を削除すること、バックアップを期限切れにすること、将来の学習からデータを除外することは、それぞれ別の操作である。

アクション: 接続されたアシスタントは、何を読み取り、変更し、送信できるのか。アカウントを通じて動作できるようになると、プライバシーは権限設定と送信データに対する制御にも左右されます。

有用なプライバシー比較では、こうした問いを分けて考えます。有料サブスクリプション、学習のオン・オフ切り替え、あるいはプライベートタスクのラベルだけでは、この4つすべてに答えることはできません。

サービスの比較

以下の表は、別の適用範囲が明記されていない限り、個人利用に焦点を当てています。これはレビュー対象のドキュメントを要約したものであり、独立したセキュリティ監査の結果ではありません。

Service	Training position	The separate boundary to understand
ChatGPT	個人のコンテンツは改善のために利用される場合があります。コントロールにより、新しい会話と Codex タスクは除外されます。Temporary Chat は除外されます。4, 5	認可されたアクセスと保持は、別の論点として残ります。Codex には、これとは別にフル環境向けの学習設定もあります。
Claude	コンシューマー向けモデルの改善はユーザーの選択に依存します。フィードバックと安全性関連の利用には別のルールがあります。Incognito は一般的な改善の対象外です。6	レビューと保持の例外は引き続き適用されます。特定の商用 Covered Models には追加の保持要件があります。7–9
Cursor	Privacy Mode は、明記された例外を条件として、顧客データを Cursor の学習対象から除外し、プロバイダー側の非保持の取り決めを説明しています。12	リクエストは引き続き Cursor のバックエンドを通過します。不正利用調査、キャッシュ、モデル固有の通知が重要です。
Perplexity	コンシューマー向け AI 学習用の収集は、Pro と Max を含め、デフォルトで有効です。ユーザーは将来分についてオプトアウトできます。13	オプトアウトしても、サービス運用や法令遵守のための処理は止まりません。Enterprise の条件は異なります。
Manus	Team のドキュメントには学習のオプトアウトが記載されていますが、このレビューでは個人プランにおける決定的な学習ルールを確認できませんでした。15	個別タスクがデフォルトで非公開であることは共有の可視性を示すものであり、プロバイダーによる利用を全面的に制限することを意味するわけではありません。14
Meta’s Muse	ローンチ時のドキュメントでは、サニタイズされたインタラクションデータをデフォルトで学習に使い、オプトアウト可能と説明されています。16	学習前のサニタイズは、推論前のマスキングと同じではありません。ローンチ時点のオペレーター制限は、計画中の Confidential VM とは異なります。
Dvina	会話、ファイル、プロンプト、ワークスペースデータは AI モデルの学習には使用されません。17, 18	自動マスキングは、より前段の境界に対応します。検出された個人識別子は、モデル処理の前に置き換えられます。

以下では、こうした区別が日常的な利用の中でどこで重要になるのかを説明します。

ChatGPT と Claude: どの操作をするかで適用ルールが変わる。

OpenAI では、通常のチャット履歴を削除しなくても、ユーザーは学習を無効にできます。Temporary Chat は会話の扱いをさらに変えますが、そのドキュメントでは依然として不正利用レビューが認められており、30日間の削除期間も説明されています。Codex のユーザーは、アカウント全体のコンテンツ設定と、それとは別のフル環境設定も区別すべきです。4, 5

Claude では、特にフィードバックに注意が必要です。Anthropic によれば、サムズアップ、サムズダウン、またはバグ報告には、関連する会話を最長5年間保存し、モデル学習を含む目的に利用することが含まれる場合があります。一般的なモデル改善を有効にすると、対象となる匿名化済みの素材が学習パイプライン内に最長5年間残ることも認められます。これらは通常のチャット削除と同じルールではありません。6, 7

そのため、1つの製品の中で、本人が別々の判断だと気づかないまま、複数のプライバシー上の意思決定をしていることがあります。製品設計では、こうした違いを利用時点で明確に示すべきです。

Cursor と Perplexity: 製品ラベルは処理上の境界ではない。

Cursor の Privacy Mode は、学習とプロバイダー保持に対して意味のある制限を提供します。ただし、エディタがローカル専用になるわけではありません。Cursor は、ユーザー提供の API キーを使う場合でも、リクエストは引き続きそのバックエンドを経由すると述べています。ドキュメントでは、一時的な暗号化ファイルキャッシュや、不正利用調査または指定モデルに関連する例外についても説明されています。12

Perplexity は別の違いを示しています。Free、Pro、Max の各アカウントはコンシューマー向け学習コントロールの対象であり、収集はデフォルトで有効です。公開されているオプトアウトは、その後に収集されるデータに適用されるものであり、以前の学習データをさかのぼって削除するものではありません。個人向けサブスクリプションを購入しても、それが Enterprise アカウントになるわけではありません。13

どちらの場合も、重要なのは選択したモードやアカウントによって何が変わるのかであって、製品名から受ける印象ではありません。

Manus と Muse: 非公開ワークスペースにも明示的な境界が必要。

Manus は、共有されない限り個別タスクは非公開だとしています。また Team のドキュメントでは、オーナーがチームのセッション内容にアクセスできることも説明されています。これらは有用な可視性ルールですが、個人向けの学習ポリシーを確立するものではありません。このレビューでは Manus の完全なプライバシーページを取得できなかったため、この点は別プランの内容で補うのではなく、未確認のままとなっています。14, 15

Muse のローンチ時ドキュメントは、運用上の制限と技術的な防止の違いを非常に明確に示しています。Meta によれば、ローンチ時点の Secure VM はポリシーによってスタッフのアクセスを制限しますが、サービスの運用、サポート、または保護に必要な場合のアクセスまでは防ぎません。オペレーターのアクセスを暗号学的に防ぐことを意図した Confidential VM は、今後提供予定であり、限定的なテスト中だと説明されていました。計画中の保護を、すでに誰でも利用できるものとして数えるべきではありません。16

Muse はまた、実際のコネクタ認証情報をメインのエージェントから切り離し、アクション承認を別個の権限管理の下に置いています。これは重要な原則を示しています。便利かもしれないという理由だけで、エージェントに秘密情報や権限を与えるべきではありません。16

保護を露出前の段階へ移す

学習からの除外は、データの利用方法を規定します。マスキングは、処理に利用可能なデータそのものを変えます。保持の制限は、残るコピーを減らします。権限制御は、エージェントにできることを制限します。これらの保護は相互補完的であり、それぞれがどの段階で機能するかが重要です。

例として、特定のメールアドレスにいるクライアントへフォローアップを書く、という依頼を考えてみてください。モデルに必要なのは、目的、トーン、関連する約束事項かもしれません。ですが、メッセージを下書きするために、そのクライアントの本名や実際の住所まで必要とは限りません。推論の前に、検出されたそうした識別子をプレースホルダーに置き換えれば、タスクの有用な構造を保ったまま、モデルが受け取る情報を減らせます。

これは、元のテキストをそのまま送っておき、あとで何らかの用途に使う前に識別子を削除すると約束するのとは別の話です。

同じ原則は、個人識別子にとどまりません。機密研究には研究内容そのものに対する管理が必要ですし、連携アカウントには必要最小限に絞った権限が必要で、保存される記録には明確な保存期間と強制可能なアクセス制限が必要です。本人情報のマスキングはその設計の一要素であって、発明や文書の中身を保護する代替にはなりません。

業界全体でも関連する取り組みがあります。OpenAIは2026年4月にローカルで実行可能なPrivacy Filterを公開し、MetaのMuse documentationでは技術的分離と、開発中のより強力な confidential-computing 設計が説明されています。こうした取り組みは、プライバシーをシステムに組み込むべきだという主張を後押しします。ただし、ツールの公開やロードマップがあること自体は、すべての一般消費者向け会話がすでに対応する保護を受けている証拠にはなりません。16, 19

基準にすべきなのは、その人が今日使っている製品の中で実際に受けられる保護です。

Dvina: プライバシーを通常のやり取りの一部にする

Dvinaのアプローチは、このより早い段階での保護をアシスタント体験に持ち込みます。公開されている設計によれば、人が入力したりコンテンツをアップロードしたりする際に、機微な個人情報をローカルで検出し、検出された個人データを暗号化し、モデル処理の前にプレースホルダーへ置き換えます。モデルは、元の検出済み識別子ではなく、それらのプレースホルダーを使って処理を行います。17, 18

この違いは実務上大きいものです。ユーザーは、名前や連絡先の詳細を手作業で削除するために、すべての作業をいちいち中断する必要があるべきではありませんし、モデルがそれらを受け取った後に何が起きるかという約束だけに頼るべきでもありません。保護は、やり取りそのものに伴うべきです。

Dvinaはまた、ユーザーの会話、ファイル、プロンプト、ワークスペースデータをモデル学習から除外しています。この組み合わせが重要です。学習しないという約束は再利用を制限し、一方で前処理による保護は、そもそもモデルにさらされる個人情報を減らします。17, 18

そのアプローチを支える層はほかにもあります。Dvinaは、暗号化された会話保存、保存されたメッセージとユーザー本人情報の分離、そしてGDPR水準の保護を備えたEUホストのデータについて説明しています。これらはそれぞれ、処理プロセスの異なる部分に対応するものであり、単一の学習設定にすべての負担を背負わせるものではありません。17, 18

技術的な違いは明確です。検出された個人識別子はモデル入力の段階で置き換えられ、その一方で周囲のタスク文脈は処理可能なまま保たれます。プライバシーは、ユーザーが忘れず管理しなければならない単なる設定ではなく、データフローの一部になります。

私にとって、これこそがAIのより有用な方向性です。人々が仕事に意味のある文脈を持ち込めるようにしつつ、そのタスクに必要な範囲を超えて本人情報を開示しないようシステムを設計することです。

結論: プライバシーが、人々がAIをどこまで生活に受け入れるかを左右する

AIアシスタントは、私たちの状況をより深く理解するほど有用になります。だからこそ、その理解の背後にある情報を守る責任が生まれます。より広いアクセスを人々に求めながら、提示するのが設定ページをもう1枚増やすことだけでは、十分な答えにはなりません。

証拠が示しているのは、いくつかの異なるリスクです。ソフトウェアはアカウントをまたいでデータを露出させる可能性があります。保存された会話は法的要求の対象になりえます。セキュリティ侵害がなくても、正規のレビューが存在しうります。さらに、非公開研究をめぐる争いは、その主張が独立に立証されていない場合であっても、信頼を損なう可能性があります。

こうしたリスクに必要なのは、言い回しを改善することではなく、エンジニアリング上の取り組みです。機微データの検出、前処理による保護、本人情報の分離、限定的な保存、そして強制可能な権限管理は、AIの基盤的な安全機能として継続的な注意を払うべきです。アシスタントの有用性とユーザー保護は、同時に前進しなければなりません。

Dvinaでは、モデル処理前の保護を製品基盤の一部にすることで、その転換を先導する一助となっています。 目指しているのは、より強い主張によってさらなる信頼を求めることではありません。約束だけに委ねなければならない信頼の量そのものを減らすことです。

人々は、助けを求め、アイデアを育て、前に進むために必要な文脈を共有する際に、あらゆる会話をプライバシーを差し出す可能性のある行為として扱わずに済むべきです。その確信を築くことは、AIにとって今後の最も重要な課題の一つです。

出典と対象範囲

出典の確認日は2026年9月22日です。この記事は、提供元の文書と帰属付き報道に基づいており、独立したセキュリティ監査ではありません。比較の主な対象範囲は個人向けプランです。商用、API、およびモデル固有の例外は別途明記しています。数学セクションでは、報告された懸念とOpenAIの更新後の回答を区別しており、いずれも独立した調査結果として提示していません。Manusの個人向けプランにおける学習ルールは、完全なプライバシーポリシーを取得できなかったため、未確認のままです。