# Differential Privacyで評価テレメトリを保護する CURRENT_STATUS: CURRENT OBSERVATION: SPEC_ONLY FRESHNESS: CURRENT PAGE_TYPE: reference CANONICAL_URL: /tools/ea-737-differential-privacy CLAIM_IDS: none EVIDENCE_IDS: EA-737-CURRENT-APPROVAL, EA-737-CURRENT-BODY-READBACK UNKNOWN_IDS: EA-737-UNKNOWN-01 OPS_IDS: none ## Summary AIシステムの評価telemetryには、失敗率、拒否率、品質指標、ツール実行結果、エラー分類、利用パターンなど、運用改善に必要な情報が含まれます。一方、評価対象が実ユーザーの入力や希少な失敗事例に由来する場合、識別子を削除するだけでは個人・組織・機密事象の推定可能性を十分に抑えられないことがあります。Differential Privacy（DP）は、個々のレコードや寄与の有無によって公開統計がどの程度変わり得るかを数学的に制約し、集約評価telemetryの公開・共有境界を設計する手段です。 ## Current judgment AIシステムの評価telemetryには、失敗率、拒否率、品質指標、ツール実行結果、エラー分類、利用パターンなど、運用改善に必要な情報が含まれます。一方、評価対象が実ユーザーの入力や希少な失敗事例に由来する場合、識別子を削除するだけでは個人・組織・機密事象の推定可能性を十分に抑えられないことがあります。Differential Privacy（DP）は、個々のレコードや寄与の有無によって公開統計がどの程度変わり得るかを数学的に制約し、集約評価telemetryの公開・共有境界を設計する手段です。 ## Scope Differential Privacyで評価テレメトリを保護する ## Confirmed ## UNKNOWN - EA-737-UNKNOWN-01: - Enterprise AI評価telemetryにおける妥当なε・δの業界横断的な標準値は確認できません。 - event-level、conversation-level、user-level、organization-levelのどれを標準保護単位とすべきかは、製品・契約・データ生成形態に依存します。 - rare failure検知に必要なutilityを維持しながら十分なprivacy guaranteeを与える最適mechanismは、母集団・query・頻度ごとの実測が必要です。 - consumer telemetryでのLDP運用実績のparameterをEnterprise AI評価へ直接適用できるとは確認できません。 ## Evidence - EA-737-CURRENT-APPROVAL (RESEARCH): 現行本文の監査・revision対応 - EA-737-CURRENT-BODY-READBACK (IMPL): 現行本文の収録照合 ## Failure / limits DP導入後も、次の場合は期待した保護または運用品質を得られません。 ## Failure / limits 隣接関係・保護単位が実際のprivacy objectiveと不一致。 ## Failure / limits 寄与制限がなく、少数主体が大量のeventを生成する。 ## Failure / limits releaseを繰り返すのにcompositionをaccountingしない。 ## Failure / limits ε・δやmechanismを記録せず、「DP採用」のラベルだけで安全性を主張する。 ## Failure / limits small cohort / rare failureの統計にnoiseが支配的となり、品質異常を見逃す。 ## Failure / limits DP済み集計を理由にraw traceの収集・保持・権限制御を緩める。 ## Failure / limits benchmarkや研究上のDP設定を、異なるデータ分布・組織・製品へ無検証で外挿する。 ## Failure / limits telemetryから派生した複数dashboard・API・定期reportを別々に扱い、全体privacy budgetを追跡しない。 ## Failure / limits DPは「個人情報を含むtelemetryを何でも安全に共有できる」技術ではありません。noiseはutilityを損ない、特に小集団・希少事象の分析では損失が大きくなります。また、DPの数学的保証は設定した隣接関係、mechanism、accounting、実装が正しい範囲に限られます。機密情報の不適切な収集、アクセス権限の過剰付与、ログ保管期間、内部者リスク、モデル出力自体の機密漏えいなど、別種のcontrolを不要にはしません。 ## PUBLIC_CLAIM AIシステムの評価telemetryには、失敗率、拒否率、品質指標、ツール実行結果、エラー分類、利用パターンなど、運用改善に必要な情報が含まれます。一方、評価対象が実ユーザーの入力や希少な失敗事例に由来する場合、識別子を削除するだけでは個人・組織・機密事象の推定可能性を十分に抑えられないことがあります。Differential Privacy（DP）は、個々のレコードや寄与の有無によって公開統計がどの程度変わり得るかを数学的に制約し、集約評価telemetryの公開・共有境界を設計する手段です。 ## 運用上の意味 DPを評価telemetryへ適用する主目的は「raw traceを安全にする」ことではなく、raw traceから生成する集約出力の情報漏えいを定量的に制約することです。NIST SP 800-226は、DPをデータ中の個人の有無に伴うprivacy lossを定量化する枠組みとして扱い、実装評価では数式上のεだけでなく、データ収集、隣接関係、寄与制限、privacy accounting、実装・セキュリティなどを含めて保証を評価する必要があると整理しています。 AI評価基盤でDPを導入する場合も、単に「ノイズを加える」だけでは不十分です。少なくとも、保護単位（1イベント、1会話、1ユーザー、1組織など）、1単位が集計へ与えられる最大寄与、公開するquery群、ε・δ、再公開を含む累積privacy budget、raw dataの保持とアクセス制御を一体で定義します。 ## 主要control ### 保護単位と隣接関係を先に固定する 「1 telemetry eventを除いても結果がほぼ変わらない」というevent-level DPと、「1ユーザーの全イベントを除いても結果がほぼ変わらない」というuser-level DPは同じ保証ではありません。長時間のagent実行や反復評価では、一人・一組織が多数のイベントを生成し得るため、event-levelの保証をuser-levelの保証として説明しません。評価データの生成単位と実際に守りたい主体を一致させます。 ### 寄与制限を設ける 同一主体が無制限にtelemetryへ寄与できる設計では、感度が増え、必要なnoiseも増えます。集計前に、主体あたりのイベント数、カウント、値の範囲などをclipping/boundingします。これはutility確保だけでなく、想定したDP保証を成立させる前提です。 ### privacy budgetを累積で管理する NIST SP 800-226は、同じデータに対する複数のDP releaseがcompositionによってprivacy lossを累積させることを示しています。同じ評価telemetryから日次・週次・モデル別・顧客別に多数の統計を出す場合、それぞれを独立した「εの小さい公開」として扱いません。query/releaseの台帳、privacy accountant、上限到達時の停止または再設計を運用controlとして持ちます。 ### ε・δを単一の標準値で決めない NISTは適切なprivacy-loss parameterについて単一の推奨値を示しておらず、データ感度、利用目的、文脈、utilityとのtrade-offを考慮した判断を求めています。また、大きなεは特にoutlierのprivacy leakageを残し得ます。ε・δは監査可能な設定値として記録し、選定根拠、想定攻撃者、utility検証、変更履歴を残します。 ### rare failure分析を別扱いにする AI運用では、重大incident、希少なjailbreak、特殊な顧客環境など「少数例ほど重要」なtelemetryがあります。しかしDPでは小集団の統計ほどnoiseの相対影響が大きくなり、utilityとprivacyの両立が難しくなります。DP集約値だけでrare failureの根本原因分析を代替せず、希少事例は厳格なアクセス制御下のraw/limited-access分析と、外部・横断共有用のDP集約telemetryを分離します。 ### raw trace収集リスクはDPで消えない DPは最終releaseのprivacy guaranteeを強化できますが、中央でraw traceを収集する方式では、収集・保存・処理中のデータ侵害リスクが残ります。raw traceには最小収集、短期保持、暗号化、アクセス制御、監査ログ、purpose limitationを別途適用し、DP済み出力をraw data保護の代替理由にしません。 ## 実装上の選択肢 中央集約型DPでは、信頼された境界内でraw telemetryを集約し、公開前にDP mechanismを適用します。高いutilityを得やすい一方、中央のraw data境界が高価値な攻撃対象になります。 Local Differential Privacy（LDP）では、端末・クライアント側でrandomizationしてから収集します。Appleは実運用telemetryの一部でLDPを用い、featureごとのprivacy budgetと寄与回数を制限してきました。これはtelemetryへDPを適用できる実例ですが、その具体的εや寄与頻度をEnterprise AI評価へそのまま移植できる根拠にはなりません。保護対象、母集団、query、脅威モデルが異なるためです。 ## FAILURE_ENVELOPE DP導入後も、次の場合は期待した保護または運用品質を得られません。 - 隣接関係・保護単位が実際のprivacy objectiveと不一致。 - 寄与制限がなく、少数主体が大量のeventを生成する。 - releaseを繰り返すのにcompositionをaccountingしない。 - ε・δやmechanismを記録せず、「DP採用」のラベルだけで安全性を主張する。 - small cohort / rare failureの統計にnoiseが支配的となり、品質異常を見逃す。 - DP済み集計を理由にraw traceの収集・保持・権限制御を緩める。 - benchmarkや研究上のDP設定を、異なるデータ分布・組織・製品へ無検証で外挿する。 - telemetryから派生した複数dashboard・API・定期reportを別々に扱い、全体privacy budgetを追跡しない。 ## COUNTEREVIDENCE_AND_LIMITATIONS DPは「個人情報を含むtelemetryを何でも安全に共有できる」技術ではありません。noiseはutilityを損ない、特に小集団・希少事象の分析では損失が大きくなります。また、DPの数学的保証は設定した隣接関係、mechanism、accounting、実装が正しい範囲に限られます。機密情報の不適切な収集、アクセス権限の過剰付与、ログ保管期間、内部者リスク、モデル出力自体の機密漏えいなど、別種のcontrolを不要にはしません。 ## SAFE_WORDING Differential Privacyは、定義した保護単位・寄与制限・privacy parameters・accountingの下で、集約telemetryのreleaseが個々の主体について追加的に漏らす情報を制約するための手段です。保証はraw trace自体の安全性や完全な匿名性を意味せず、データ収集・セキュリティ・アクセス制御・utility評価と併せて設計・監査する必要があります。 ## OPEN_UNKNOWN - Enterprise AI評価telemetryにおける妥当なε・δの業界横断的な標準値は確認できません。 - event-level、conversation-level、user-level、organization-levelのどれを標準保護単位とすべきかは、製品・契約・データ生成形態に依存します。 - rare failure検知に必要なutilityを維持しながら十分なprivacy guaranteeを与える最適mechanismは、母集団・query・頻度ごとの実測が必要です。 - consumer telemetryでのLDP運用実績のparameterをEnterprise AI評価へ直接適用できるとは確認できません。 NEXT: /agent/start.json STOP: This is a knowledge projection, not an execution order.