Machine Unlearning：実践的なAIデータ削除ワークフロー

誰かからAIシステム内の自分のデータを削除してほしいと依頼された場合、データベースから1行を削除するだけでは作業は完了しません。Machine unlearningは、特定の学習例に対するモデルの応答を弱めたり方向転換したりできますが、スタックの残りの部分、つまりベクトルインデックス、fine-tuned adapter、キャッシュされたプロンプト、checkpoint、レプリカ、バックアップ、エクスポートを自動的にクリーンアップするわけではありません。NISTはmachine unlearningを、学習済みモデルから特定の学習データ点の影響を選択的に取り除くことと定義しており、効率的な近似手法によってゼロからの完全な再学習を避けられる場合があることも明示しています。これは「システム全体がデータを忘れた」という意味よりも限定的です。NIST

多くのチームにとって、実践的な答えは多層的なものです。まずデータがどこへ流れたかを追跡します。次に再利用を止めます。その後、派生アーティファクトを削除または制限します。それを終えて初めて、モデルの重みを再学習する必要があるか、近似的なunlearningを行うかを判断します。Googleの2023年Machine Unlearning Challengeも、まさにこのモデル中心の枠組みを採用していました。unlearned modelは、forget setなしで再学習したモデルと見分けにくくなる一方、retained setに対する性能は維持すべきだとされています。Google Research

目次

Machine unlearningが実際に意味すること

Machine unlearningはモデルレベルの操作です。選択したデータが学習済みモデルの挙動に与える影響を弱めることを意味します。これはretained setを使った正確な再学習を意味する場合もあれば、完全な再学習コストをかけずに十分近い結果を目指す近似手法を意味する場合もあります。NISTは用語集の項目で両方の考え方を扱っており、GoogleのChallengeページでは、忘却対象の例を除いてゼロから再学習したモデルとの類似性をゴールドスタンダードとして示しています。NIST Google Research

この定義が重要なのは、AIシステムがモデルの重みだけで終わることはほとんどないからです。通常、本番スタックには次のものが含まれます。

これらのレイヤーのうち1つだけを削除しても、別の場所からデータにアクセスできる状態が残る可能性があります。実務上、「このデータをAIから削除する」という作業は、モデル編集の問題になる前に、まずlineageの問題です。

通常の削除フローでは不十分な理由

多くのAI製品は、削除を求められたデータを学習していません。推論時に取得しただけの場合もあります。その場合の作業は、ソースレコード、派生embedding、キャッシュ、アクセス経路を削除することです。モデルの重みは変更されていないため、Machine unlearningは関係ありません。

より難しいケースは、データが重み、adapter、または永続メモリに影響を与えた場合に始まります。その場合は、すべての削除依頼を同じように扱うのではなく、次の4つの状況を分ける必要があります。

この表が示すように、「削除ボタン」という考え方は適切ではありません。正しい考え方は、範囲を定めた削除と証跡の確保です。

実践的な7ステップのワークフロー

1. 依頼の範囲を定め、再利用を凍結する

まず、正確な識別子を確認します。ユーザーID、ファイルハッシュ、文書ID、ベクトルコレクション名、学習バッチID、またはチケット参照番号などです。次に、新たな再利用を止めます。クリーンアップ中に同じデータを再作成する可能性のある取り込み、再学習、エクスポートジョブ、同期を一時停止します。

依頼がプライバシーに関するものであれば、法的な位置付けは限定的に保ちます。GDPR Article 17は、定められた状況における消去の権利を定めていますが、最初にどの技術レイヤーへ対応すべきかまでは示していません。European Data Protection Boardの2024年12月18日付AIモデルに関する意見書も、個人データで学習したモデルを常に匿名とみなせるわけではないとしています。モデルが対象外だと決めつけず、明示的な削除ワークフローを維持してください。EUR-Lex EDPB

2. 何かを削除する前にlineageを追跡する

完全な経路をマッピングします。

3. ソースと派生アーティファクトを削除または制限する

ここで、決定的に削除できるものを消去します。

公開されているAnythingLLM issueでは、あるWeaviateベースの構成において、削除した文書のembeddingが引き続き検索可能だったと報告されています。1件のissueは逸話的な証拠であり、プラットフォーム全体に関する発見ではありません。それでも、すべての削除フローに、文書ID、特徴的なフレーズ、言い換えを対象としたネガティブ検索テストが必要な理由を示しています。

4. モデルの重みが実際に変更されたか判断する

ここが、チームが見落としがちな分岐点です。

Googleの2023年Challengeは、モデル側の目標を定義しています。unlearned modelは、忘却対象の例を除いて再学習したモデルに似ている一方、残りのデータから学習した有用な挙動は維持すべきです。Google Research

5. 重みを変更する前に評価セットを作成する

少なくとも次の3つのスライスが必要です。

*キャプション：削除作業はデータlineageと派生アーティファクトから始まります。モデルのunlearningは、重みが影響を受けたかどうかを確認した後にのみ始まります。*

6. 忘却と保持された有用性を同時にテストする

最近の研究は、トレードオフを明確にしています。

論文*Behavioral Audit of Machine Unlearning Has a Privacy Cost*は、凸モデルの場合、ブラックボックスの挙動監査では、不十分なunlearningを検出しながら、正直だが好奇心の強い監査者にretained setのメンバーシップ情報を漏らさないことを同時に実現できないと論じています。著者らは、この緊張関係が非凸設定でも続くことを示す実証的な証拠も提示しています。つまり、1つのきれいな監査スコアは、安全な忘却を普遍的に証明するものではありません。arXiv

Google Researchの2026年6月10日の監査フレームワークは、別の方向からこの問題に取り組んでいます。Regularized f-Divergence Kernel Testsを提案し、監査の感度を高め、サンプルサイズ全体でfalse positiveをより安定して制御することを目指しています。これは統計的検定であり、完全な削除の証明ではありません。Google Research

PrivUnは、直接検索、in-context recovery、fine-tuningによる復元という3つの復元レベルを分けています。モデルへのアクセス方法に合った段階を使ってください。元のプロンプトに対する拒否は最初のチェックを通過しても、より強い復元経路では対象が露出する可能性があります。

7. 古いアーティファクトを廃止し、証跡を保持する

モデル側の作業後、古いレプリカ、checkpoint、adapter、キャッシュを削除または隔離します。そのうえで、次の証拠パッケージを保持します。

この証拠があることで、削除ワークフローはサポート、セキュリティ、法務、エンジニアリングの全員が検証できるものになります。

最新のunlearning研究が実際に裏付けていること

ここで役立つ最近の3本の論文は、それぞれ異なる主張を裏付けています。

挙動監査にはコストがある

2026年6月の挙動監査に関する論文は、過大な主張に対する最も強い警告です。その中心的な結果は「unlearningは不可能」というものではありません。より限定的で有用な結果は、不正な所有者と正直だが好奇心の強い監査者のもとでは、挙動監査がプライバシーと監査のトレードオフを生み得るということです。コンプライアンスの説明がブラックボックスの探索だけに依存している場合、忘却を検証しようとする過程で保持データに関する情報を漏らす可能性があります。arXiv

対象を絞った編集は、選択されたベンチマークで機能する可能性がある

*ZeroUnlearn*は、より楽観的な結果です。Machine unlearningをモデル編集の問題として捉え直し、Llama-3.2、Llama-3.1、Qwen-3で強いベンチマーク結果を報告しています。また、closed-formのfew-shot updateにより、MCFとZsREでSVDステップを0.3秒未満に抑え、end-to-end編集は10サンプル時の約0.04時間から、1000サンプル時には3.35〜3.82時間へ増加し、総メモリは約14.9〜17.4 GBだったとしています。これらの数値は、近似的なunlearningがテストするには自動的に高コストすぎるわけではないことを示すため重要です。arXiv

しかし、見出しよりも制約の方が重要です。この論文は、MCF、ZsRE、MQUAKEの適応版single-hopなど、選択されたオープンモデルとベンチマークデータセットを評価しています。また、一般的な能力を損なわないよう、対象を絞ったlayer選択も行っています。これは、ベンチマーク規模での有望な事実削除の証拠ではありますが、本番システムが機密情報のすべてのコピーを完全に消去した証明ではありません。arXiv

マルチモーダルシステムでは継続的な削除が依然として弱い

*ICU-Bench*は、厳しい反証となる結果です。このベンチマークには、医療報告書と労働契約書から作成したプライバシーに関わる1,000件のプロフィール、9,500枚の画像、16,000組の質問回答、100件の連続forgetタスクが含まれています。結論は単純です。現在のマルチモーダルunlearning手法は、継続的な設定に苦戦しており、忘却品質、保持された有用性、長いシーケンスでの安定性を同時に維持できていません。製品が時間の経過とともに繰り返し削除依頼を受けるなら、きれいな自動化を約束する前に読むべき論文です。arXiv

これらの論文を総合すると、実践的には次のように整理できます。

ユーザーとステークホルダーに約束すべきこと

約束は少なく。検証は多く。

適切な表現は次のようなものです。

不適切な表現は次のようなものです。

短いルールが必要なら、これを使ってください。Machine unlearningは、より広範なAIデータ削除ワークフローの中の1つのレイヤーです。

FAQ

ベクトルデータベースの行を削除すれば、LLMは忘れますか？

いいえ。検索経路がデータを再導入するのを止められるため、RAGシステムでは最初に行うべき適切な修正であることが多いです。しかし、同じコンテンツがfine-tuning、継続学習、または永続的なモデルメモリに使われていた場合、ベクトル行だけを削除しても重みは変わりません。

Machine unlearningによって、すべてのモデルコピーから自分のデータが消えたことを証明できますか？

それだけではできません。最近の監査研究は、ブラックボックス監査には限界があることを示しています。また、本番システムには、監査対象のモデル表面の外側にキャッシュ、adapter、checkpoint、レプリカ、バックアップが存在することがよくあります。必要なのはモデルレベルのスコアだけではなく、システムレベルの証拠です。arXiv Google Research

主張の確認

出典