top of page
検索

信頼できるAIのプライバシー問題とは何か：漏えい対策ではなく「後付け不能な監査」で解く

信頼できるAIにおけるプライバシー問題は、「個人情報を隠せるか」ではなく **「扱いを後からごまかせないか」**で決まる。 Differential Privacy（DP）や暗号化は“隠す”に強いが、運用が本当にその通りだったかという **説明責任（accountability）**を自動で固定しない。 だから解くべきは privacy as secrecy ではなく、**privacy as accountability（後付け不能な監査）**である。


ree

1. AIのプライバシー対策とは？個人情報漏えいを防ぐ「監査ログ」と説明責任

1.1 典型的に起きる“プライバシー事故”の分類

  • 直接漏えい（ログ、出力、学習データの露出）

  • 推論的漏えい（個人属性の推定、メンバーシップ推定 [1]）

  • 運用的漏えい（データの持ち回り、権限の拡散、目的外利用）

  • 評価・改善の過程での逸脱（本番データで調整、勝手な再学習）

実際、Shokriらは学習モデルの出力から学習データのメンバーシップを推測できるメンバーシップ攻撃を示しており [1]、Zhuらは共有された勾配情報からプライベートな訓練データを復元できる攻撃を報告している [2]。さらに、GPT-2などの巨大言語モデルに対してクエリを通じて訓練データを抽出する手法も示されている [3]。こうした攻撃研究は「漏えいが現実に起こり得る」ことを示している。

1.2 「信頼できる」の条件を言語化

  • 何を使ったか（入力データの同定）

  • 何をしたか（変換・学習・評価の手順）

  • いつ/どの範囲でやったか（期間・区間・ウィンドウ）

  • 誰でも再現できるか（第三者追試の可能性）

  • 後から変えられないか（運用の後付け不能性）

言い換えれば、どのデータ集合をどんな手順で使い、いつどこで評価したかを記録・証明でき、かつ後から改変できない状態にすることが、信頼性の鍵である [4]。NISTも「訓練データの由来の管理（provenance）が透明性・説明責任に寄与する」と指摘しており [4]、これが担保されて初めてAIシステムは「信頼できる」と言える。

監査で“合格/不合格”を決めるための最小要件（責任固定の定義）

本レポートでは、AIシステムのプライバシーに関する「信頼」を、次の 監査可能な合否条件として定義する。

  1. 入力同定（Input Identification）：参照可能なデータ集合が、IDとハッシュで一意に固定されている。

  2. 手順固定（Procedure Fixation）：分割境界（calibration/test）、閾値ポリシー、評価手順（メトリクス定義）が事前に固定されている。

  3. 追試固定（Replayability）：第三者が、同一入力と同一手順から同一結論を再生成できる（verify 可能）。

  4. 後付け不能（Post-hoc Non-Forgeability）：上記のいずれかを事後に改変した場合、検証で必ず不一致が露呈する（改ざん“困難”ではなく、**改ざん“検出可能”**を保証する）。

この定義は、ガバナンスやチェックリストが「やるべきこと」を列挙するのに対し、実行物としての証拠（evidence）を固定する点が異なる。NIST AI RMFがリスク管理の枠組みを提供している一方で、運用における“実行の証拠”を自動で固定する仕様ではないため、ここをプロトコルとして補う必要がある。


2. 技術と信頼のギャップ：組織が陥るポイント

2.1 多くの組織が詰むポイント（要約）

  • 「プライバシーを守る技術は増えたのに、信頼は増えていない。理由は“守った証拠”が残らないからだ。」

2.2 ここで提示する論点

  • 既存の代表的解（規制対応/DP/FL/TEEなど）は、なぜ“信頼”を完結できないのか

  • 真に信頼を完結するには、何を固定すべきなのか

  • それを最小実装でどう実現するか（証明書監査プロトコル）


3. 問題点：なぜ既存のプライバシー対策は「信頼できるAI」に届かないのか

3.1 規制・ポリシーの限界（守ったことの再現不能）

  • 文書やチェックリストは実運用の挙動を拘束しない。

  • 監査が事後の説明にとどまり、実際の挙動が固定されない。

たとえば、ポリシーやガイドラインは組織に何をすべきか列挙するが、実際の運用フェーズで「何を参照し、何をやったか」をコードレベルで記録するわけではない。つまり、現場で運用が変わっても追跡できず、「本当に守れていたか」を第三者が検証できない仕組みになりやすい。

3.2 Differential Privacy の限界（選定が裁量になりやすい）

  • $\epsilon$（プライバシー損失パラメータ）やノイズ付加などの選定が組織の裁量に依存。

  • 「理論上の保証」と「実際の運用でその保証が成立したか」は別問題。

Differential Privacy（DP）は理論的に強力な保証を持つが、実際の運用で $\epsilon$ の値や敏感度をどう設定したかは組織判断となりがちだ。また、たとえ理論上はプライバシーが保護されても、「本当にそのデータセットに対して正しく実装されていたか」を後から証明するログや証拠が無ければ、結局運用レベルで保証が不明瞭になる。

3.3 Federated Learning / Enclave の限界

  • データを動かさない・中身を見せない構造は実現可能。

  • しかし、本番結果を見て閾値や手順を後付けで変更する動きを構造的に止められない。

分散学習やTEE（Trusted Execution Environment）では確かにデータ輸送や視覚的漏洩は抑えられるが、運用上の評価プロトコル（分割基準や閾値設定など）はシステム外で自由に調整できてしまう。さらに、Zhuらの研究 [2] では、学習参加ノードが共有勾配からプライベートデータを推定できることが示されており、単にデータを秘匿するだけでは漏えいの根本は防げない。

3.4 根因を一言で固定

  • 「漏えいは現象で、根因は“責任の未固定”にある」

以上より、既存技術で捉えている「プライバシー」は漏えいそのものだが、本質的には運用レベルで誰が何をいつどう使ったかを後から証明できないことが根本原因である。従って、対策の焦点は「データを隠す」ことから「運用記録を後付け不能にする」ことにシフトする必要がある。

先行研究マップ：どこまで到達したか／どこが限界か

本節では、プライバシー技術を「漏えい防止（secrecy）」だけでなく、「説明責任（accountability）」まで閉じる観点から整理する。

A. ガバナンス／規制：Trustworthy AI を“枠組み化”した

  • 到達点：NIST AI RMF は組織のリスク管理枠組みを提示し、ISO/IEC 42001等が運用の骨格を整えた。EU AI Actでも記録保持・追跡性が制度的要件になりつつある。

  • 限界：多くは「何をすべきか」の列挙であり、実行物としての“後付け不能な証拠”を自動固定するまでには踏み込まない。

  • GhostDrift/ADIC の突破点：枠組み（What/Why）ではなく実行物（How）を証明書として固定する。data_manifest 等を一体にし、「守った」を“再生成できる事実”へ落とす。

B. 攻撃研究：漏えいが“現実に起こる”ことを固定した

  • 到達点：Membership Inference攻撃 [1]、勾配からの復元攻撃 [2]、LLMからの訓練データ抽出 [3] などが実証された。

  • 限界：攻撃と防御の性能競争に終始し、運用の責任境界を後付け不能に固定するプロトコルを提供しない。事後に閾値調整の有無を追試で決着できない。

  • GhostDrift/ADIC の突破点：参照窓＋評価プロトコルを事前固定し、逸脱を台帳で“検証不一致”として即死させる。

C. Differential Privacy（DP）：数学的保証で“影響”を制限した

  • 到達点：DPの基礎と数学的原理が確立し、強い理論保証を与える。

  • 限界（accountability が原理的に閉じない理由）：

    • DPは「出力分布の変化」を数学的に制限する枠組みだが、**その保証が成立していた事実（運用の真偽）**を自動で固定しない。保証は“アルゴリズム”に付くため、正しい実装・隣接関係・会計（privacy accounting）が前提となるが、現実のMLパイプラインでは理論保証と実装の間にギャップが生まれやすい。(petsymposium.org)

    • $\epsilon$（予算）だけでなく、会計・サンプリング・合成が“設定地獄”になり、外部から追試しにくい。DP-SGD 等では会計手法の選択が保証を左右するが、その落とし穴が指摘されることも多い。(arXiv)

    • “ノイズは乱数”なので、手順固定がないと第三者は「同じ保証で同じことをやった」を再生成できない。DPは secrecy を強化するが、accountability を閉じるには **DP設定と実行手順を“証拠として固定”**する層が別途必要になる。(journalprivacyconfidentiality.org)

  • GhostDrift/ADIC の突破点：DP設定（$\epsilon$、感度、ノイズ手順、データ窓、コード環境）を証明書に固定し、同一結論を再生成可能にする上位監査層として機能する。

D. Federated Learning（FL）：データを動かさない学習を普及させた

  • 到達点：FLにおけるプライバシー攻撃・防御の体系化が進んだ。

  • 限界（accountability が原理的に閉じない理由）：

    • FLは参加者の過程が他者から見えないため、データ汚染やモデル汚染（poisoning）が潜みやすく、「データを動かしていない」ことと「参照境界が守られた」ことは同値でない。(arXiv)

    • 評価・閾値・再学習の“後出し”はFLの外側で起きる。FLは通信の枠組みであり、結果を見てから閾値や分割を変える「peek」や「再評価」を構造的に禁止しないため、説明責任が最終段で崩れる。(ACM Digital Library)

    • FL単体では「本当にこの窓のデータだけで、この手順で、この結論に到達したか」という問いを閉じない。評価プロトコルの固定＋台帳による検証不一致（mismatch）検出が必要になる。(ACM Digital Library)

  • GhostDrift/ADIC の突破点：判定に至る評価プロトコル（split/threshold/metric/env）を固定し、出力を証明書化して追試可能にすることで説明責任を完結させる。

E. Confidential Computing / TEE：環境の隔離とアテステーション

  • 到達点：実行環境の機密性・完全性の観点が整理された。

  • 限界（accountability が原理的に閉じない理由）：

    • アテステーションが証明するのは“境界内の測定状態”であり、運用上の“意味”まで束縛しない。一般に「その入力が何であったか」「評価の窓や閾値が事前固定か」までは自動で含まれない。(ACM Digital Library)

    • MLはデータ収集から評価まで長いパイプラインであり、TEEが守るのは多くの場合「ある区間の実行」である。参照したデータファイル群や分割、peekの有無といった説明責任はTEEの外で起きるため、責任固定の主要変数が未拘束になる。(arXiv)

    • “後付け不能”はハードだけでは作れない。TEE内で監査を実行する提案（attestable audits）もあるが、参照窓や評価プロトコルを証明書として外部に提示しない限り、責任固定は完結しない。(arXiv)

  • GhostDrift/ADIC の突破点：アテステーション＋証明書監査で、実行環境だけでなく参照境界・評価手順・出力再生成を同時に固定する。

F. Machine Unlearning：削除要求への対応

  • 到達点：Unlearningの方法・評価の体系化が進んだ。

  • 限界（accountability が原理的に閉じない理由）：

    • **“本当に消えたかを第三者が確定できるか”**が難所である。検証手法が乱立し、同じモデルが成功とも失敗とも判定される基準が並立するため、Unlearning は主張合戦になりやすい。(arXiv)

    • 完全除去は“反事実”に近く、影響の残差をゼロと断言するのが難しい。その「十分」の境界が運用・評価・攻撃モデルに依存し、外部監査で決着しにくい。(サイエンスダイレクト)

    • 版管理（いつ、どのデータIDが、どのモデル版に含まれていたか）が固定されていないと、Unlearning は永遠に“後付け説明”になる。説明責任として閉じるには、データ集合のmanifestと評価境界の固定が先に必要になる。(サイエンスダイレクト)

  • GhostDrift/ADIC の突破点：データ版管理と評価版管理を証明書化し、Unlearningを「この版からこのデータIDが外れた」という追試可能な事実に変える。

G. 文書化（Model Cards / Datasheets）：透明性の文化

  • 到達点：透明性を高める記述枠組みが提示された。

  • 限界：文書は「後から書ける」。説明は増えても、実行の後付け不能性は増えない。

  • GhostDrift/ADIC の突破点：文書ではなく 実行証拠（ledger） にする。「このデータID集合からこの結論が再生成できる」を固定する。

先行研究の“原理的限界”まとめ：なぜ責任固定が別レイヤーとして必要か

DP/TEE/FL/Unlearning はそれぞれ secrecy・integrity・分散学習・削除要求に対して強いが、共通して (i) 参照窓の同定、(ii) 評価窓・閾値・手順の事前固定、(iii) 第三者が再生成して一致/不一致で裁ける形（replayability） を、単独では完結しない。 この“未拘束な変数”（データ集合・境界・手順・環境）が残る限り、「守った」は後付け説明になり、信頼（accountability）が閉じない。 したがって必要なのは、既存技術を置き換えることではなく、それらを上位から束ねて 責任境界を後付け不能に固定する監査プロトコル（certificate + ledger + verify） である。(ACM Digital Library)

補足：後付け不能な監査は“既に実績のある設計パターン”である

「後付け不能（tamper-evident / append-only）な監査」は、AI以前からセキュリティ領域で実績がある。代表例が Certificate Transparency（CT） で、TLS 証明書を追記のみの公開ログに載せることで、誰でも監査できる形にする。 また、ソフトウェア供給網では in-toto や Sigstore、SLSA 等が「何が・誰によって行われたか」を暗号学的証跡（provenance/attestation）として残す枠組みを提供しており、GhostDrift/ADIC はこの設計パターンを AI運用に移植し、「守った」を追試可能な事実として固定する。


4. 解決の骨格：privacy as accountability（後付け不能な監査）

flowchart LR
A[Privacy as Secrecy\n(隠す/漏らさない)] -->|DP/暗号/TEE/FL| B[Leakage Reduced\n(漏えい確率↓)]
A2[Privacy as Accountability\n(後付け不能/追試可能)] --> C[Certificate + Ledger]
C --> D[Third-party Verify\n(第三者追試)]
D --> E{Mismatch?}
E -->|Yes| F[REJECT\n(逸脱・後付けが露呈)]
E -->|No| G[ACCEPT\n(責任が確定)]

GhostDrift数理研究所では、後から言い逃れできない証明可能なプロトコルとしてプライバシーを捉える枠組みを提案する。具体的には以下の3点を柱とする：

4.1 解決原理（3点セット）

  • 入力同定：使用したデータ集合をハッシュ等で固定し明示。

  • 手順固定：モデルの分割境界や閾値ポリシー・評価手順を事前に固定。

  • 追試固定：第三者が同一手順で結論を再生成できる形式で「証明書」を発行。

上記により、データ・手順・結果のすべてが一貫してログ化・証明される。これで初めて、「どのデータを使った」という事実や「手順通りに評価した」という事実が再生成可能な形で残る。

4.2 何が「後付け不能」になるか

  • 「そのデータは使っていない」「別目的で使っていない」といった言い逃れができなくなる。

  • 「結果を見てから評価手順を調整した」という操作を、構造的に実行不可能にする。

例えば、運用記録により許可されていないデータ参照や突発的な閾値変更は自動的に検知・拒否される形になる。これにより、データ利用および評価結果に対する説明責任（accountability）が制度的に担保される。


5. 具体解：証明書＋Ledger で“非参照”と“逸脱”を扱う

GhostDrift数理研究所では、実装レベルで監査可能性を確保するために、証明書（certificate）と台帳（ledger）の二段構成を用いる。

5.1 証明書に入れる最小要素（v1.0）

  • data_manifest：参照可能なデータファイルの同定、期間、欠損処理、特徴量定義など。

  • split_spec：キャリブレーション期／テスト期のデータ境界。

  • threshold_policy：閾値設定・固定ルール・例外条件の定義。

  • run_environment：実行コード、依存パッケージ、乱数シードなど。

  • outputs：判定結果、必要なメトリクス、再現手順。

これらを証明書にまとめて署名・公開することで、使用したデータ集合や評価プロセスが一元的に固定される。特に訓練データの出所（provenance）や評価プロセスが明示化されるため、NISTが指摘する訓練データ由来の管理による説明責任 [4] が実現される。

5.2 “見ていない”を扱う：非参照の形

  • 「何を参照してよいか」を事前に決め、それ以外への参照を監査で排除。

  • プライバシーを「秘密」ではなく「参照境界の遵守」として定義。

つまり、あらかじめ許可したデータ集合に限定して分析を行い、証明書に示された範囲外のデータ参照をすべて記録・拒否する。これにより、データの非参照性が技術的に保証され、単にデータを隠すのではなく、「ここまでのデータならアクセスした」という境界自体を固定する。

5.3 “気づいたら逸脱”を扱う：プライバシードリフトという発想

  • 評価ドリフト：評価手順や閾値設定の変化を“検出対象”と捉える。

  • 訓練データだけでなく、評価手順・閾値のバージョン管理も追跡。

プライバシー事故は必ずしもデータそのものの変化ではなく、運用中に評価基準や閾値が勝手にズレることでも起きる。GhostDriftの考え方では、データのドリフトと同様に評価手順のドリフトも監視対象とし、逸脱検知を行う。

5.4 GhostDrift/ADIC：責任固定監査プロトコル v1.0

GhostDrift数理研究所が提案するのは、「後から言い逃れできない」ことを検証可能性として定義した監査プロトコルである。合否は、次の単純な規則で決まる：

  1. 証明書が固定した 参照窓（data_manifest） から外れた参照があれば REJECT。

  2. 証明書が固定した 評価手順（split/threshold/metric） と異なる実行があれば REJECT。

  3. 証明書が固定した 環境（code/deps/seed） と異なる実行で結果が一致しないなら REJECT。

  4. 逆に、第三者が verify を実行して一致するなら、その運用は 説明責任として確定（ACCEPT）。

このとき重要なのは、「守ったはず」を証明するのではなく、破ったら必ず不一致が出るように設計する点である（改ざん困難ではなく改ざん検出可能）。


6. 実装導線：短い手順で監査を固定する

6.1 最小導入ステップ

  • 既存モデルはそのままに、周辺に監査ラッパーを追加する。

  • キャリブレーション期のみ推論を許可し、テスト期には評価だけを行う。

  • 実行時に証明書と台帳を自動生成し、最後に第三者が検証できる状態にする。

6.2 成果物の形（出力イメージ）

  • certificate.json：data_manifest, split_spec等を含む証明書ファイル。

  • ledger.csv：各工程（データ入力・中間出力・閾値判定）を記録した台帳。

  • verify.log：第三者検証（replay）の成否レポート。

出力例（ミニ実物）

certificate.json（抜粋）

{
  "schema_version": "GD-ADIC-AUDIT-1.0",
  "data_manifest": {
    "dataset_id": "tokyo_demand_weather_v1",
    "allowed_files": [
      {"path":"demand_2024-01.csv","sha256":"..."},
      {"path":"demand_2024-02.csv","sha256":"..."},
      {"path":"weather_tokyo_2024-01.csv","sha256":"..."}
    ],
    "time_window": {"start":"2024-01-01","end":"2024-04-30"},
    "feature_spec": ["temp_prev_hour","sunshine_prev_hour","rel_humidity","demand_mw"],
    "missing_policy": "drop_rows_with_any_nan"
  },
  "split_spec": {
    "calibration": {"start":"2024-01-01","end":"2024-03-31"},
    "test": {"start":"2024-04-01","end":"2024-04-30"}
  },
  "threshold_policy": {
    "metric": "audit_score",
    "rule": "reject_if_score_exceeds",
    "threshold": 0.80,
    "no_peeking": true
  },
  "run_environment": {
    "repo_commit": "git:abcd1234",
    "python": "3.11.x",
    "deps_lock_sha256": "...",
    "random_seed": 123456
  },
  "outputs": {
    "decision": "ACCEPT",
    "score": 0.42
  }
}

ledger.csv（抜粋）

step,artifact,sha256,value,notes
load,weather_tokyo_2024-01.csv,...,,allowed_by_manifest
split,calibration_end,,2024-03-31,fixed_by_split_spec
metric,audit_score,,0.42,computed_in_test_window_only
decision,final,,ACCEPT,threshold=0.80

7. どこに刺さるか（用途の例）

  • 医療・金融・行政：既に監査・説明責任が前提で規制されており、プライバシー管理の厳密さが価値になる分野。

  • B2Bモデル提供：顧客は内部手順を信用しない前提でサービスを受けるため、証明可能な説明責任が重要。

  • 社内MLOps：担当者交代や外部委託、多部署開発で「言った言わない」のトラブルが増える領域。


8. 先回りFAQ（反論への回答）

  • 「暗号やDPと競合するのか？」 → 競合しない。むしろ上位層の監査プロトコルとして併存可能。必要に応じてDPやTEEを組み合わせ、最後に「守れた証拠」を残す形で説明責任を担保する。

  • 「重くならないか？」 → 学習アルゴリズム自体は変更せず、評価・記録・追試の周辺処理として追加するだけ。オーバーヘッドは追加記録・検証コストに限定される。

  • 「何が新しいのか？」 → 従来は「隠す/守る」技術の拡充が中心だったが、本提案は運用ログそのものを後から動かせない責任境界として固定する点で革新的である。


9. まとめ

信頼できるAIにおけるプライバシー問題は、単なる漏えい対策だけで解決するわけではない。本稿で述べたように、根本的には責任の未固定が問題であり、これを解決するには後付け不能な監査プロトコルが必要となる。GhostDrift数理研究所のアプローチでは、証明書とLedgerによって参照データの範囲や評価手順・追試可能性を固定化することで、プライバシー保護が「守る」から「説明できる信頼」へと完結する。これにより、AIシステムの透明性・説明責任が技術的に担保され、最終的にプライバシーが信頼として完結する [4]。

信頼できるAIを実現するには、技術的なプライバシー保護に加え、運用の追試可能性・監査可能性を同時に保証する仕組みが不可欠である。なお、NIST AI Risk Management Framework でも訓練データのプロビナンス維持が説明責任に寄与するとしており [4]、本提案はその指摘を実装レベルで具現化するものである。

参考文献

  • NIST. Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100-1, 2023.

  • ISO/IEC. ISO/IEC 42001:2023 Artificial intelligence — Management system.

  • ISO/IEC. ISO/IEC 23894:2023 Artificial intelligence — Guidance on risk management.

  • European Union. AI Act (Official Journal version, 13 June 2024) / logging & record-keeping.

  • Dwork, C., Roth, A. The Algorithmic Foundations of Differential Privacy. FnT TCS, 2014.

  • Shokri, R., et al. Membership Inference Attacks Against Machine Learning Models. IEEE S&P 2017. [1]

  • Zhu, L., Liu, Z., Han, S. Deep Leakage from Gradients. NeurIPS 2019. [2]

  • Carlini, N., et al. Extracting Training Data from Large Language Models. USENIX Security 2021. [3]

  • Zhao, J. et al. A Survey of Federated Learning Privacy Attacks, Defenses, Applications, and Policy Landscape. ACM Computing Surveys, 2025.

  • Mo, F. et al. Machine Learning with Confidential Computing: A Systematization of Knowledge. ACM Computing Surveys, 2024.

  • A Survey of Machine Unlearning. ACM Computing Surveys, 2025.

  • Mitchell, M. et al. Model Cards for Model Reporting. (FAccT/FAT*), 2019.

  • Certificate Transparency (RFC 6962).

  • Sigstore. Software Signing for Everybody. ACM, 2022.

  • in-toto. in-toto: securing software supply chains.

  • SLSA. Supply-chain Levels for Software Artifacts.

 
 
 

コメント

bottom of page