データ分類：コンプライアンス要件がパイプライン設計を逆向きに拘束する

プライバシーコンピューティングのエンジニアリングで最も踏み外しやすいのは、本番展開前のスキャン工程として扱ってしまうことです。業務がまずデータを集め、モデルを学習し終えてからコンプライアンスチームが検査に来て、非適合が見つかったら回头してマスキングを足す。この順序ではエンジニアリング上ほぼ確実に失敗します。学習セットがディスクへ書き込まれ、勾配が蓄積し、ベクトルがインデックスに書き込まれた時点で、ロールバックのコストは週単位、甚至月単位になるからです。実際に機能するのは分類を前倒しにすることです。コンプライアンス上の結論がデータパイプラインの形そのものを決めるようにします。

まず分類が何を解決すべきなのかを整理します。データ分類とは、各テーブルに「秘匿/機密」というラベルを貼れば終わり、というものではありません。実行可能な三組の判断を出力するものです。このデータ集合を現在の信頼境界から出してもよいのか。出してよいなら、どの 형태로出なければならないのか（平文、仮名化、集約、あるいは統計量のみ）。そしてシステム内部で、どのロールが元の形を読めて、どのロールは減格された形しか読めないのか。三つ目の判断が実際にパイプラインとランタイムによって強制されるとき、前の二つに初めて意味が生まれます。

実践上、分級の軸は単一の曖昧なレベルではなく、三つの直交した軸に分けます。

軸答えるべき問い典型的な判定根拠エンジニアリング成果物
感度漏洩した場合、人や財産へ直接損害が生じるか直接識別子や準識別子の組み合わせ、健康・金融属性が含まれるかフィールド単位の機密ラベルと継承ルール
用途制約このデータ集合は具体的にどの目的へ使用が許可されているか告知・同意のテキスト、契約条項、データ処理協定用途ラベルとパイプラインのゲート
移転等級どのドメイン・どの法域へ流してよいかローカライズ要件、越境メカニズム、業界規制の運用保存場所のポリシーと移転の承認

この三つの軸は分けてラベル付けしなければなりません。あるフィールドが「高感度だが国内限定かつリスク管理用途のみ」であり、別のフィールドが「低感度だがあらゆる分析に使える」場合もあります。レベルを一本の列にまとめると、エンジニアリング上は二つの方向に破綻します。低い感度のデータを高い感度として扱い、コストが受け止められなくなるか。あるいは高い感度のデータを低い感度として通し、その用途制限を誰も確認しないまま流してしまうか。

コンプライアンス要件によるパイプライン設計への逆向きの拘束は、典型的には収集段階に現れます。目的限定の原則は「この目的のために収集したデータを都合よく他へ転用してはならない」という要求であり、エンジニアリングへ落とすと、収集側は書き込みの時点で用途ラベルを必ず付与し、いったん書き込まれた用途ラベルは下流が恣意的に書き換えられないようにしなければなりません。これをコードレビューで担保すると、半年もせず何らかの暫定スクリプトがそれを迂回します。推奨するのは用途ラベルをデータ契約の一部にすることです。スキーマの段階で NULL 不可かつ制約つきのフィールドを持たせ、すべての書き込み経路を同じ検証へ通します。スキーマを迂回してファイルへ直接書き込む行為は、デプロイ段階で権限ビットと監査アラートによって塞ぎます。

二つ目の逆向きの拘束は収集時の最小化です。最小必要の原則（data minimization）は多くのチームで「フィールドを少し減らす」と誤解されていますが、実際に制約しているのは「宣言した単一の目的のために、いまどの要素が必要か」ということです。エンジニアリングで実行しやすい判断は要素ごとの必要性論証です。そのフィールドを削除しても、宣言した目的はまだ達成できますか。できるなら、そのフィールドは収集すべきではありません。この論証は収集前に終わらせる必要があり、収集してから削除するのでは不十分です。収集済みのデータは、削除したかどうかに関わらずすでにコンプライアンス上の露出を生じさせているからです。

三つ目の逆向きの拘束は、ログとデバッグ面に出ます。多くのチームがデータパイプラインに完全な生のリクエストボディを障害調査のために残しています。このデータはすべての主要経路のマスキングロジックを迂回しているにもかかわらず、最も審査が薄い場所に最も価値の高い生の内容が置かれている。エンジニアリング上、観測面には単独でレベルを付ける必要があります。ログ内容は構造的に切り詰め、排障に必要なメタデータと要約だけを残してください。パッケージ全体を転送するのではなく。

分類的結論がパイプラインのゲートになるには

分類そのものが安全を生むのではなく、強制されることで初めて安全を生みます。私がこれまで見てきたインシデントのほとんどで、根本原因は「分類をしていない」ことではありません。「分類的結論が、機械判定可能なチェックの何ひとつに変換されていない」ことです。翻訳が目指すのは、違反する書き込みが技術的に不可能になることです。フロー上「許可されない」状態を保つことではありません。

実装可能な方法は三種類あり、強制の強さは増加します。一つ目は入口ゲートウェイでのラベルベースのポリシー検査で、リクエストが携带する用途ラベルが対象ストレージドメインの許可集合に合わなければ拒否します。二つ目はストレージ層での強制で、機密フィールドには専用の暗号化鍵とアクセス資格情報を使い、アプリケーション側は復号能力を得られず、管理された減格ビューしか呼べません。三つ目は出口統制で、信頼ドメインを離れるすべてのバルク出力がポリシーエンジンを通り、行き先の法域・用途・フィールドの組み合わせごとに一項目ずつ判定され、その判定結果が監査ログへ記録されます。

三つの仕組みに共通するのは、判断材料がパイプライン内部にあるという点であり、呼び出し側の自制心にあるわけではないという点です。どれを選ぶかはデプロイ形態で決まります。セルフ構築のクラスタなら二番目が最も手間が少なく、マネージドサービスなら一種類目と三種類目の組み合わせしかできません。

マスキングの技術ルート：静的と動的の分担

静的マスキング（static masking）とは、データが下流システムに入る前の段階で元の値をマスキング後の形へ置き換え、下流にはマスキング結果しか見せない手法です。利点は徹底しており、元のデータが後続のフローに参加しないため漏洩面が自然に狭まり、監査でも「下流は一度も元の値を見ていない」と根拠を添えて説明できます。代償は、マスキング結果と元の値との間に追跡可能な関連性が失われることで、業務が関連分析を必要とするなら、残った安定した識別子に頼るしかありません。

動的マスキング（dynamic masking）とは、データをそのまま保存し、読み出しのときに閲覧者の身元・用途・時間枠に応じて原文を返すか、マスキングした値を返すか、空を返すかを決める手法です。関連分析の能力を保て、同じストレージを異なるロールに提供できます。たとえばコールセンターのオペレーターにはマスキングされた電話番号が、信用リスク審査者には承認後に完全な番号が見える、といった使い方ができます。代償は元の値が常にストレージ内に存在することです。ストレージ層のアクセス制御、鍵管理、監査粒度が十分強くなければ、動的マスキングはフロントエンドにフィルターをもう一枚貼っただけになります。

どちらを選ぶかの判断基準は、マスキング後の形でクロースソースの関連分析が必要かどうかです。リスク管理、不正検知、グラフ系のシナリオでは動的マスキングがほぼ必須です。これらのシナリオの価値は恰恰、各システムに分散した識別子を突き合わせること自体にあるからです。一方、外部提供用のデータセット、学習用の汎用コーパス、レポート出力は静的マスキングにすべきです。これらのシナリオで原文に戻す必要はないため、原文を残しておくのは純粋なリスクを増やしているだけです。

仮名化と匿名化の法的境界

これはマスキング体系のなかで、法律上の概念まで厳密に区別しなければならない唯一の部分です。エンジニアリングのチームがここで取り返しのつかない誤った判断を下すからです。「マスキングしたものが匿名に見える」と「すでに匿名である」を同一視してしまうようなことです。

仮名化（pseudonymization）とは、置換・ハッシュ・写像などの手段で直接識別子を別の値へ入れ替えることを指し、追加の情報を保持していなければ特定の主体を識別できないものの、関連性は残る状態を指します。多くの法域の規制運用は、これを匿名化ではなく一つの安全措置として扱います。写像表や鍵を保持していればデータはいまだ個人情報であり、個人情報保護のすべての義務が適用されます。エンジニアリング上の含意は非常に明確です。仮名化されたデータは個人情報として管理し、そのアクセス制御レベルを元のデータより低くしてはなりません。

匿名化（anonymization）とは、あり得る限りの合理的な手段をすべて考慮したあとでも、データ主体が識別できず、他の情報を用いて復元することもできない状態を指します。この基準は結果志向で絶対的なものであり、立証責任は通常、処理者側にあります。エンジニアリング上の含意はこうです。匿名と宣言した以上、可逆的な写像を持つと主張してはいけません。システム内に本人へ戻せる表や鍵が残っているなら、それは匿名化ではなく、高度な仮名化に不正な営業文句を添えたものにすぎません。

この区別の実務的な影響は責任の境界にあります。仮名化データが漏洩すれば個人情報のセキュリティ事象となり、通知、通報、影響評価といった義務のフローを踏む必要があります。匿名化を宣言したデータが漏洩した場合、通常は同じ経路では扱われませんが、規制当局は匿名化の有効性を問う権利を持ちます。つまり「匿名」というラベルには代償のある判断が伴います。自由に貼り付けられる営業語ではありません。

よく見落とされている点がもう一つあります。仮名化の安定性です。携帯電話番号をハッシュして得られる仮名は、技術的には不可逆です（鍵付き構成を使った場合）。しかしデータセット全体で一貫しているため、他の情報を何点も保持する攻撃者は準識別子の組み合わせを使い、仮名と個人を再び結び付けられる可能性があります。これは次のセクションで扱う形式的な保証が解決する問題です。

k-匿名性、l-多様性、t-近接性：形式的な保証それぞれの代償

直接識別子のマスキングは「このレコードが誰か」という問題しか解きません。「このグループのレコードから個人を逆算できるか」には答えません。準識別子（quasi-identifier）とは、年齢、性別、郵便番号、受診科目といったフィールドを指し、その危険性は組み合わせると特定の一人を固定するのに十分な情報量になる点にあります。単独で見ればどれほど普通でも、組み合わせれば一人へ絞り込めるからです。形式的な保証は、まさにこの「組み合わせによる開示」のために設計されています。

k-匿名性（k-anonymity）が要求するのは次のことです。データセット内の任意のレコードについて、少なくとも k-1 件の他のレコードが存在し、それらのレコードが準識別子集合上の値が当該レコードと完全に一致すること。直感的には、どの単独レコードも最低でも k 人の群れの中に隠れるということで、攻撃者が属性の組を見ても一人まで絞り込めません。エンジニアリング上の代償はグループの爆発です。準識別子が多く基数が高いほど、k を維持するには大幅な一般化（たとえば「1987年3月」を「1985〜1989年」へ一般化する）か、大規模の抑制（一部のフィールドとレコードを直接削除する）が必要になり、これはデータの効用を直撃で破壊します。経験則として、実業務データで高基数な準識別子を三つ以上同時に k-匿名性の制約へ取り入れると、情報量のほぼすべてを失うのがほぼ確実です。

保証防御する攻撃形式的条件主な代償
k-匿名性準識別子の組み合わせによる個体の逆算各同値クラスの大きさが k 以上一般化による効用損失、同質性攻撃に脆弱
l-多様性同質性攻撃、背景知識からの推測各同値クラス内で機密属性が少なくとも l 種の値を持つk-匿名性と衝突した場合は追加調整が必要で、精度損失はさらに大きい
t-近接性全体の分布からの推測各同値クラスと全体の機密属性分布の距離が閾値内パラメータ選定が難しく、実用的なツールチェーンが少ない

k-匿名性の弱いところは同質性（homogeneity）にあります。ある同値クラスにたまたま同じ機密値だけが入っている場合（たとえば全員が特定の病気と診断されている場合）、攻撃者は個性が誰であるかを知らなくても、その集団の健康状態を推測できます。これが l-多様性（l-diversity）が埋める穴です。各同値クラス内部の機密属性の値が多様性を有することを要求し、実装としては再帰的多様性やエントロピー多様性といった具体的な尺度が使われます。

l-多様性はもう一つ尻尾を残します。分布レベルの保護です。「同質性の推測」は防げますが、「同値クラス全体の分布が全体から偏离する」という構造的漏洩までは防げません。攻撃者は個別が見えなくても、ある集団全体が全体より偏高か偏低かを判断できます。t-近接性（t-closeness）は分布距離についての要件であり、各同値クラスの機密属性分布を全体の分布に近づけます。

この三つは重ねて選べるパッケージではなく、仮定を段階的に締めていくものだと考えるのが自然です。エンジニアリング上、多くの企業は本当に t-近接性の実装に手を入れていません。別の道を選んでいます。差分プライバシー（differential privacy, DP）でノイズを加えた集計統計を公開するか、評価を経たモデルのみを公開するかで、個体データが受統環境から出ない仕組みにすることです。この二つは、コンプライアンスの論証という面では、通常、形式的な匿名化よりもしっかりした立場に立てるものです。

四つのプライバシーコンピューティング技術の能力境界

次の四つの技術はよく一緒に説明されますが、信頼前提はまったく異なります。信頼前提をはっきりさせることは、利点を並べるよりずっと有効です。方案を誤ったときのコストは性能の低下ではないのです。データが誤った前提のもとで処理されてしまうのです。

信頼実行環境（TEE）

信頼実行環境（Trusted Execution Environment, TEE）とは、ハードウェア層で提供される隔離された実行ドメインを指し、代表的な実装は CPU 上のエンクレーブ（enclave）や GPU の機密計算機能です。その信頼前提は、ハードウェアベンダーのチップ実装と attestation（証明）メカニズムが信頼できるというものです。ホスト OS は信頼できないが、エンクレーブのメモリやレジスタを読み取ることはできない、という前提です。代表的な流れはリモートアテステーション＋リモートコールです。呼び出し側がまずエンクレーブのメトリクス（metrics）を検証し、自分が期待したコードが動いていることを確認してから、機密データを送り込んで計算させます。

TEE が守れるのは次のことです。使用中の平文データがホスト側から観測されない。ディスクに落ちなければ静的データの漏洩を誘発しない。マルチテナントが同一物理マシンを共有していても互いに見えない。信頼ドメイン内で復号と計算を完了できる。鍵をドメイン内で使うだけなら、外へ取り出す必要がない。

TEE が守れないのは何か。ここは設計文書に必ず書き込むべき部分です。エンクレーブへ入れる前に発生する収集・転送段階の漏洩を防ぎません。アプリケーションロジック自身がドメイン内で、保護されていないインターフェースへデータを書き戻すことも止めません。サイドチャネルや Iago 型の攻撃が利用するのは、共有メモリ、マイクロアーキテクチャの状態、観測可能な時間だからです。安全性は具体的なチップモデルとファームウェアバージョンに結び付いています。ファームウェアの脆弱性や、証明メカニズムが回避された実績も珍しくありません。独立したエンクレーブサポートのないアクセラレータでは、多くの実装がソフトウェア暗号化へ退行し、それはもう TEE の安全性論証ではありません。さらに TEE 自身は「計算結果が正しい」証明を提供しませんし、アクセスログを自動記録することもありません。

エンジニアリング上の代償は、主に起動レイテンシとメモリの予約、ドライバとイメージの検証プロセス、そしてコンテナやオーケストレーションシステムでセキュリティ領域を正しく注記する設定の複雑さです。性能面上では、暗号化メモリとページ分離による追加オーバーヘッドは大規模モデルの推論では無視できません。具体的な幅度は実装とワークロードによって変わるので、汎用的な数字を一つ示すべきではありません。重要な点がここです。TEE の安全性を主張するどのアーキテクチャも「鍵はどうやって入ってくるのか」に答えられなければなりません。鍵が必ずホスト OS を通らなければならないなら、その鍵はすでに信頼できない側に現れていることになり、TEE の価値は大幅に減殺されます。

同型暗号化（HE）

同型暗号化（homomorphic encryption, HE）は、暗号文上で算術演算や多項式演算を直接行い、結果も暗号文となり、鍵を保持する側しか復号できません。四つの技術のなかで数学的前提が最も硬いものです。安全性は格子上の困難問題に基づいており、ハードウェアを信頼する必要も、実行主体を信頼する必要もありません。

HE が守れるのは次のことです。データが保存、転送、計算のすべてで暗号文のまま。計算側（多くの場合はクラウドや第三者）が見るのは中間平文がゼロ。暗号文上での統計、検索スコア計算、簡単な機械学習の推論が可能。TEE と異なり、信頼モデルに「部分的に信頼できるハードウェア」が存在しない。

HE が守れないのは次のことです。平文の入力段階は守れません。データがクライアント側で復号されてアップロードされる那一刻は丸見えなので、端末側の暗号化と鍵管理は依然として独立したエンジニアリング上の負担です。アクセスパターンを隠しません（メタデータについては後述）。計算側にサービス拒否や誤った結果を返すことを止めません。可検証計算を別途実装しない限りです。大規模モデルの推論については、モデル構造を深く改修しない限り意味のある保護経路をほとんど提供しませんが、それはもう常规的なエンジニアリングではありません。

代償は三桁以上の性能とサイズの膨張です。暗号文の膨張倍率、乗算深度の制限、非対称方式の単発演算コストが主要なボトルネックです。実用的なルートは二系統あります。ひとつは対称型同型暗号で小規模な機密計算を処理する経路です。たとえば数十次元のベクトル上で暗号文のままスコアリングする方法です。もうひとつは暗号学的系変換（transpilation）で、線形層の重みを事前暗号化して暗号文形式にしておけば、推論時は暗号文上での行列乗算だけを行い、明文暗号混在と組み合わせます。どちらのルートも実装の难度は高く、エンジニアリング負荷の主因は演算子の実装とメモリ管理にあります。

強調すべきメタデータの問題があります。HE は平文の内容を保護しますが、暗号文そのものの長さ、アクセス時刻、繰り返し回数は情報を漏洩します。同一のユーザーが同一の場所から同じ暗号文を繰り返し送信すると、暗号文の等値性そのものが識別子になります。したがってエンジニアリングでは通常、固定長までのパディングとランダム性（blinding / re-randomization）の導入を組み合わせ、暗号文のサイズとアクセスパターンも漏洩面の分析に含めます。「HE を使えば絶対に安全だ」という主張は、レビューで差し戻されるべきです。

フェデレーテッド学習

フェデレーテッド学習（federated learning, FL）の考え方は、データを各参加者のローカル側に置いたまま、モデルの更新だけを交換するというものです。守るのはデータ所有権と物理的隔離であり、計算過程の機密性ではありません。

FL が守れるのは次のことです。生のデータがローカルの境界を出ない。これは現実的な価値として最大のものです。参加者同士が互いのストレージシステムを信頼する必要がない。多者が共同でモデル化するシーンでは、各参加者がデータを一つの主体へ集約する必要がなく、コンプライアンス交渉のコストが大幅に下がります。

FL が守れないのは次のことです。勾配とパラメータ更新は情報を漏洩します。これは十分に認識されている種類の問題であり、大量の更新からの反転、訓練サンプルからの抽出、特定の設定下での部分的な生データの復元などが、実際に研究されている攻撃面です。単一の悪意ある参加者が更新を構造化したり毒入れしたりしてグローバルモデルを操作できる一方、中心集約自体には検出手段がありません。FL は「ローカルデータが安全である」という前提を仮定します。ある参加者のローカル環境が侵害されれば、FL は追加の保護を一切提供しません。最も重要なのは、FL は推論段階の漏洩を解決しないという点です。集約されたモデルが外部にサービスを提供するときも、訓練データと推測される内容を出力する可能性があります。

代償の面は、通信ラウンド数が多いこと、参加者の計算機がヘテロジェネアスで同期効率が悪いこと、切断時の処理が複雑なこと、実験から本番へのチューニングコストが高いことです。エンジニアリングではさらに、データ分布の偏りによる収束問題、そして中央に平文ログを持たない状態で「訓練は確かに認可されたデータだけを使った」と証明する方法をどうするかという課題も出てきます。

フェデレーテッド学習が最も誤用されやすいのは、単一組織内部の分散学習です。それは実質的にデータ並列であり、プライバシーとは無関係です。それでいて、資料の中ではフェデレーテッドという名前で登場します。判断基準は単純です。参加者同士が互いに信頼していないか、法律上データ所有権が分離されているか。このどちらでもなければ、フェデレーテッドは不要です。

秘密共有

秘密共有（secret sharing）は、一つの値を複数のシェアに分割して別の参加者へ配布し、閾値を下回るシェアだけでは復元できず、閾値に達すれば共同で復元できるようにする手法です。最も単純で、説明しやすく、ハードウェアにもっとも依存しない方式です。

秘密共有が守れるのは次のことです。単一の参加者または単一のシェアが漏洩しても秘密は露出しない。実装が単純で、暗号学的仮定のリスクがない。多者共同の承認、鍵の分散保管、機関をまたぐゲーティングの入力に向いている。

秘密共有が守れないのは次のことです。共有されたデータそのものは隠しません。復元した時点ですべての平文になります。参加者は演算のために互いに通信して協業する必要があり、多者調整のコストが高い。シェア保持者の数は固定なので、スケールアウトと権限変更が難しい。「計算の途中でデータが見られない」という要望に対しては、分割と復元の二つの境界でのみ有効で、中間の演算を共同で行う必要があれば、通常は MPC プロトコルと組み合わせるしかない。

これに隣接するのが安全多方計算（secure multiparty computation, MPC）です。秘密共有に同型の攪乱レイヤーを加えて共同計算を実現し、多者が入力を露出せずに関数の結果を計算できます。実際の制約は通信ラウンド数と演算種類にあります。乗算ゲートは対話を要し、深層ネットワークのフォワードパスには大量の非線形活性化が含まれるため、どちらで扱うかは、高価な三者間乗算を導入するか多項近似へ落とすかで、精度と性能の両方に代償が付きます。従って MPC は暗号学的には強い一方、深層学習パイプラインへの実装は限定的で、現時点で成熟しているのは統計クエリ、比較、ソート、そして暗号学的プロトコルで実装した識別子の照合です。

四つの技術の対照：信頼前提と現実の代償

上に挙げた四つを一つの表に並べて比較すると、選定の論理がかなり見えやすくなります。重要なのは機能の一覧ではなく、「あなたは誰から守ろうとしているのか」という点です。好奇心旺盛なクラウド運用者を相手にするなら TEE で十分です。利益を動機とする第三者に対して正しい計算を期待するなら HE か MPC が必要です。データ保持者本人からの漏洩を防がなければ、はじめて FL のようなデータを集約しないアーキテクチャが必要になります。

方式中核となる信頼前提守れる工程主な失效モード典型的な性能代償
TEEハードウェアと証明メカニズムが信頼でき、ホストは信頼できない使用中の平文とメモリファームウェア欠陥、サイドチャネル、ホスト側の入力漏洩起動とメモリのオーバーヘッド、暗号化メモリによる帯域低下
HE格子上の困難問題保存、転送、計算の全工程平文の入力段階、メタデータとアクセスパターン桁違いの膨張、乗算深度による制限
FL各参加者のローカル環境が信頼できる生データがドメイン外に出ない更新からの反転、毒入れ、中心側の悪意通信ラウンドが多い、ヘテロジェネアスと偏りが収束に影響
秘密共有/MPC暗号学プロトコルの正しさ、通信チャネルの信頼性入力を露出させない共同計算復元後の平文、参加者の共謀または共謀の閾値対話ラウンドが多い、非線形と高精度は制限される

強調しておきたいのは、この四つは排他ではなく、組み合わせで使うのが常态だということです。実際、企業が採る解法は、たとえば次のようになります。TEE で推論と特徴計算を担い性能を得て、FL でマルチセンターのデータがドメイン外に出ないようにし、HE を極小規模の機関間照合に使い、秘密共有を鍵と承認のゲーティングに使います。これらを同じアーキテクチャに置き置くときに見るのは、信頼前提が互いに打ち消しあっていないかです。たとえば TEE サポートのないアクセラレータで機密計算を主張したり、参加者のローカルストレージに置いた暗号化鍵を同じ中心主体へ一元管理させたりするのは、組み合わせた解法を最も弱い一環へ戻してしまいます。

RAG シーンの特殊性：漏洩面は思ったより三層多い

検索拡張生成（RAG）は「データコンプライアンス」の問題を学習段階から実行時へ移しました。そして実行時の問題はより難しいです。呼び出しのたびに新しいデータの痕跡が生まれるからです。従来のデータエンジニアリングにおけるコンプライアンスレビューには固定のチェックリストがありますが、RAG にはありません。RAG は、それまで存在しなかった一類の資産、ベクトルインデックスを持ち込みました。

ベクトルストアそれ自体が、未分類の新しいデータ資産である

多くのチームは設計段階でベクトルストアをキャッシュ扱いし、その結果、元のデータの分類とアクセス制御をすべて素通りします。実際の帰結はこうです。ベクトルストア内のすべてのベクトルは、いずれかの管理された文書から来ています。それなのにベクトルストアには通常、文書レベルのアクセス制御がありません。たった一つのテナントがテナントをまたぐベクトルを検索できてしまえば、漏洩するのは特定の利用者のデータではなく、知識ベース全体です。従来データベースで一行が漏洩した場合の影響は限定的ですが、ベクトルインデックスの漏洩が重いのは、それが本質的にコーパス全体の意味を集約しており、しかも検索インターフェースが呼び出し資格情報を 가진すべての主体に開かれているからです。

もっと厄介なのは削除です。ベクトルストアの物理ストレージはシャードファイルとインデックス構造からなります。元の文書を削除しても、該当するベクトルは残っているのでしょうか。定期的な再構築を行っているなら、旧いベクトルは再構築が完了するまで検索され続けてしまいます。行っていないなら、それらは永遠に残ります。この問題の本質は関係データベースのハード削除と同じですが、ベクトルの場面ではより見落とされやすい。運用担当者がインデックスの中にデータがあるとは考えないからです。

検索ログとキャッシュは隠れた漏洩面である

検索ログにはクエリテキスト、ヒットした文書 ID、類似度スコア、ユーザー識別子、タイムスタンプが記録されます。このデータの情報密度は一般的なアプリログを遥かに超えています。連続するクエリ列から、ユーザーが今何を調べているかを復元できるからです。医療や法務の相談場面では、甚至病情まで推測できてしまいます。また、ヒットした文書の集合は「誰がどの内容に関心があるか」というプロフィールに等しいものです。多くのチームがアプリログに保持期限を設けマスキングを行っているのに、検索ログを同じ方針に含めていないのです。

キャッシュの問題はもっと微妙です。セマンティックキャッシュ、検索結果キャッシュ、生成結果キャッシュという三種類があり、いずれも鍵にクエリテキスト自体を含み、値には原文を含む生成結果が入る可能性があります。キャッシュのライフサイクルは通常、データ保持方針の管理下にありません。分散キャッシュノードはアベイラビリティゾーンをまたいで配置されるうえ、データ主体が削除を要求したあともヒットし続けることがあります。エンジニアリング上、キャッシュの鍵と値をともに分類対象に含め、キャッシュの失効トリガーを明確にしなければなりません。削除要求、権限変更、用途変更はいずれも強制的な失効イベントであるべきです。

見落としやすい点がもう一つあります。リランキング（rerank）段階と引用の復元です。引用の復元は原文の断片を最終回答に貼り込みます。ベクトルストア側で権限フィルタリングをしていても、引用解決の段階で ID 直取りのバイパスがあれば、ユーザーが閲覧権を持たない原文を引き出せます。这类のバイパスはたいてい「パフォーマンス最適化」の名目で持ち込まれ、気づかないうちに制御されていない読み取り経路へ育ってしまいます。

権限フィルタリングは検索層で完了させる必要がある

本文でいちばん強く主張したいエンジニアリング上の結論がここにあります。権限フィルタリングは検索層で発生すべきであり、アプリケーション層で発生させてはなりません。

アプリケーション層でフィルタリングする作りはこうです。検索時には権限を区別せずに top-k を取得し、コードの中でユーザーの権限に応じて閲覧権のない文書を結果から落とします。この作りには互いに独立した四つの障害経路があり、いずれも本番環境で実際に起こります。

一つ目が切り詰めです。取得した k は固定ですが、フィルタリングがその一部を消費します。さらに隠れた本命は、いくつかの実装が「必ず結果を返す」ことを保証するために、フィルタ後に件数が足りない場合に再検索の範囲を広げるようにしている点です。すると権限のない文書は、逆に検索された回数が多いほど結果に入りやすくなります。二つ目が類似度の漏えいです。文書自体が破棄されても、そのスコア、時刻、順序、存在するかどうかといったシグナルは推測に利用され得ます。「これらの文書がストアには存在する」「この人物のクエリが医療系コンテンツに当たった」ということ自体が情報だからです。三つ目がキャッシュ汚染です。フィルタを通していない結果が一度キャッシュへ入れば、後続のリクエストが読むのは権限外のコンテンツになり、キャッシュ自体には権限コンテキストを持ちません。四つ目が実装ドリフトです。アプリケーション層のフィルタリングロジックは複数のクエリ入口に散らばっており、必ずどれか一つの入口だけフィルタの追加を忘れます。

検索層でのフィルタリングの正しい形はこうです。権限条件を検索から切り離せない構成要素として扱い、候補生成の段階で既に効かせることです。典型的なやり方は、権限述語とベクトル検索を加重融合するか、まず権限で事前フィルタをかけてから、そのサブセットの中でベクトル検索することです（ベクトルインデックスが条件付きスキャンに対応しているかどうかで制約されます）。あるいは権限ドメインごとに独立したインデックスパーティションを保ち、クエリのときに該当パーティションへルーティングする方法もあります。三つの手法の分かれ目は、事前フィルタの実装の難度がベクトルストアのメタデータフィルタリング能力と選択性見積もりに依存し、パーティション分離の実装コストが権限次元の組み合わせ数に比例して増える、という点です。

検索層のフィルタリングが本当に機能しているかを判断するには、コードを読むのではなく、テストに任せなければなりません。テスト群を必ず用意してください。同じクエリを異なるユーザーロールで実行し、返される文書の ID 集合とスコアの分布が想定範囲に収まることを表明するテストです。それに加えてキャッシュに対する権限外テスト、つまり高権限アカウントで生成されたキャッシュを低権限アカウントが同じクエリで参照し、ヒットしないことを表明するテストも必要です。

検索層の権限フィルタリングの実装スケルトン

以下のコードは検索層フィルタリングの三つの重要点を示しています。権限述語とベクトル検索を同じ場所で組み立てること、スコアと文書 ID を一緒に返して表明できるようにすること、そしてパーティションルーティングを隔離のフォールバックとして用意することです。本番用コードではありません。重点は構造にあります。

class Retriever:
    def search(self, query, principal, top_k=8):
        # 第一步:由权限服务给出主体可见的文档域,不接受调用方传入
        scope = self.acl.resolve_scope(principal)
        if scope.is_empty():
            return []

        # 第二步:分区隔离作为兜底,避免误配置时的跨域检索
        partitions = [p for p in self.index.partitions() if p in scope.partitions]

        candidates = []
        for part in partitions:
            # 第三步:元数据过滤条件必须与向量检索在同一次调用中生效,
            # 不允许先无过滤检索再在应用层丢弃结果
            hits = part.knn(
                vector=self.encoder.encode(query),
                top_k=top_k * self.acl.oversample_factor(principal),
                where=scope.metadata_predicate(part),
            )
            candidates.extend(hits)

        # 第四步:即使过滤发生在候选集上,也保留显式校验作为纵深防御
        candidates = [h for h in candidates if self.acl.can_read(principal, h.doc_id)]

        candidates.sort(key=lambda h: (-h.score, h.doc_id))
        return [Hit(doc_id=h.doc_id, chunk_id=h.chunk_id, score=h.score,
                    text=self.render(h, principal)) for h in candidates[:top_k]]

このスケルトンのなかには三つの点を個別に説明する価値があります。第一に、scope は権限サービスが生成するため、呼び出し側から指定できません。この一点が「クライアントがフィルタ条件を渡せる」というよくある脆弱性を塞ぎます。呼び出し側が where 条件を渡せてしまうと、空の条件を渡せてしまうからです。第二に、パーティション分離はパフォーマンスの最適化ではなくセキュリティ境界です。メタデータフィルタがインデックス実装の制約で事後フィルタへ退行しても、パーティションルーティングは権限外の文書が候補集合に一度も入らないように保証します。第三に、多層防御としての明示的な検証を冗長なコードとして削除してはいけません。インデックス実装が変更されたとき、あるいは ACL サービスが異常をきたしたときに効く防御だからです。

データライフサイクル：五つの段階におけるコントロールポイント

コンプライアンス上の義務は一度きりのものではありません。データが収集されてから廃棄されるまでのすべての段階にまたがっています。コントロールポイントをライフサイクル順に並べるのは、技術順に並べるよりも監査しやすく、欠落を見つけやすいからです。

収集

収集段階の中核となる義務は適法性と最小必要性です。エンジニアリング上のコントロールポイントとしては、収集側で用途ラベルを強制的に付与すること、明確な同意と告知の記録をどこに残すかを定めること、そして任意フィールドに対して本物のデフォルト無効機能を提供することが含まれます。よくある欠陥は、同意を全選択式の一次性承認として実装し、その後にするすべての用途をその承認の下に置してしまうことです。これは規制の説明としては成立しにくいのです。技術的により堅牢なのは、用途ごとにグループ化した独立した同意状態を用意し、用途が変わったときに再確認を求めることです。そのためにはバックエンドが用途を書き込み条件として扱わなければならず、フロントエンドでの一度のクリックでは足りないのです。

収集側の、もう一つのコントロールポイントは、忘れられる機能の前倒しです。データ主体が同意を撤回しても、ある記録の派生コピー（特徴量、ベクトル、キャッシュ）を特定できないなら、撤回は単なる UI 操作に終わります。したがって収集時点で安定した来歴識別子（provenance ID）を書き込んでおき、派生チェーンを通じてそのまま伝播させなければなりません。これは後述のすべての削除操作の基礎になります。

ストレージ

ストレージ段階のコントロールポイントは、アクセス制御と暗号化に集中します。エンジニアリングで落实すべきなのは、at rest 暗号化と鍵管理の分離（鍵システム自体を独立して認可する）、オブジェクト単位の認可（テーブル単位にとどめないこと）、そしてすべてのアクセス経路に痕跡を残すことです。ベクトルストア、特徴量ストア、メッセージキュー、バックアップはいずれもストレージ段階の一部です。彼らのアクセス制御の粒度はメインストアより粗くなることが多く、個別に評価する必要があります。バックアップとスナップショットの保持期間がメインストアよりかなり長くなることが多く、これはコンプライアンスの説明でよく見つかる穴です。

派生データの分類も省略できません。特徴量、ベクトル、キャッシュ値はすべて元のデータから派生したものであり、その感度は通常、由来元より高くはありません。エンジニアリングではメタデータの中で由来元のラベルを継承させ、派生時に「ラベルは締める方向のみ許され、緩めることはできない」という規則を埋め込めば、下流がコードで機密ラベルを消してしまうことを防げます。

利用

利用段階の中核となる義務は、目的限定と最小化アクセスです。コントロールポイントとしては次が含まれます。学習タスクの入力データセットには用途ラベルがあり、認可範囲と一致していること。クエリ側のオブジェクト単位の権限検証。人によるアクセスの承認と理由の記録。およびプロンプトと検索結果の取り扱いルールです。プロンプトそれ自体が個人情報を構成しうるからです。ユーザーが個人情報を入力欄に貼り付けたとき、その内容がログやトレーシングシステムへ入ってしまいます。

開発・デバッグ環境は利用段階の重灾区です。エンジニアが問題を再現するために本番データをローカルの Notebook へ書き出し、効果を切り分けるために完全なプロンプトとコンテキストを画面に出力し、分析のために全量レコードを単一ノードへ引き寄せます。これらの経路はすべての主要経路のコントロールを迂回しています。独立したデータアクセス承認フローと、管理されたデバッグ環境（マスキング後のデータなら利用可能、あるいは管理されたサンドボックス内でアクセスする）によって収口させなければなりません。

共有

共有段階のコントロールポイントは、越境と外部提供の判定です。エンジニアリングで行うべきことは次の通りです。転送前のマスキングまたは形式的な保証。行き先の法域と受領側の資格の記録。データ処理協定のフィールド単位の痕跡。そして共有清単の継続的な保守です。共有清単は一度きりのものではありません。受領側が処理方法を変更するかもしれませんし、新たな再処理者を導入するかもしれませんし、データを新しいシステムへ送るかもしれません。これらはすべて清単の更新を誘発するはずで、清単の変更が再評価をトリガーするかどうかについては、明確なルールが必要です。

廃棄

廃棄段階は最も形式化しやすい段階です。証明書には「期限到来時に削除」と書いてありますが、実際に三回検証したところ、バックアップにはまだ残り、オブジェクトストレージの旧バージョンにはまだ残り、分析基盤のデータレイクのコピーにもまだ残っていました。廃棄の正しいエンジニアリング上の定義はこうです。その主体のデータの完全なコピー一覧を列挙し、派生された形も含めてすべてを網羅したうえで、削除結果を一つずつ検証し、監査可能な証拠を残すことです。コピー一覧の正確さが廃棄作業の核心的な難所であり、通常は来歴識別子とアセットレジストリの共同保守が必要になります。

ベクトルストアとキャッシュの中で削除権が本当に削除できることの難しさ

忘れられる権利（right to erasure）は関係データベースには比較的明確な実装経路がありますが、AI システムにはありません。これは AI データが多重の派生形態を持つことに由来します。

难点の第一は、派生関係が明示されていないことです。ベクトルストアの一つのベクトルは文書の一つのチャンクに対応し、チャンクは文書に対応し、文書は一組の元の記録に対応します。この連鎖を書き込み時に記録していなければ、後から逆方向に辿ることはできません。エンジニアリング上の必要条件は、チャンクとベクトルの双方が原文までの経路識別子（文書 ID、記録 ID の集合、位置オフセット）を持つべきであり、テキストだけを保存するのではないことです。

难点の第二はインデックスの物理構造です。ベクトルを削除した後も、インデックスの内部構造がその寄与の情報を保持している可能性があります。より現実的に言えば、いくつかの実装では「削除」は印を付けるだけで、物理的なデータはマージや再構築の時に初めて取り除かれます。これ会带来二つの帰結があります。ひとつは削除の完了時点が確定しないこと（次の compaction を待つ必要があります）。もうひとつは、削除の期間中にその文書がまだ検索される可能性があることです。コンプライアンス上は明確な最長完了時点の約束が必要であり、システムレベルで「削除待ち」のデータが検索結果として返されないように阻止しなければなりません。

难点の第三はキャッシュです。キャッシュの鍵はクエリテキストで、値は生成結果か検索断片です。データ主体が特定の文書の削除を要求しても、キャッシュにはその文書の断片を含む生成結果が残っている可能性があり、クエリテキストからは逆引きできません。したがって「コンテンツからキャッシュへの対応付け」を構築するか、あるいはデータ主体ごとにパーティションを分けたキャッシュ名前空間を使う必要があります。そうすれば削除時に名前空間単位で直接失効させられます。どちらの方式もカバーしていない場所については、キャッシュに短い保持期間を設定してフォールバックとし、その間の残留リスクが明示的に記録されることを受け入れる必要があります。

难点の第四は再生成です。削除したあとに「同じ内容を生成するな」と求められますが、これは純粋な統計学的意味では保証できません。モデルの重みには依然として関連情報が含まれているからです。コンプライアンスの上では通常、二種類の主張を区別します。データ削除（ストレージ層の削除）とモデル遗忘（出力層で再現しないこと）です。前者はエンジニアリングで実現でき検証もできますが、後者は具体的な手段（影響関数による方向付き忘却、機械学習の unlearning 手法など）を必要とし、効果は限定的です。ドキュメントではこの二つを必ず分けて書き、「すでに削除した」という表現で「モデルが関連する内容を再び語らない」ことを示唆してはいけません。

差分プライバシー：測定可能な保証を提供する唯一の技術群

これまで触れてきた技術のどれも「某一側が能動的に漏洩しないと信頼する」という前提の上に立っています。差分プライバシー（differential privacy, DP）はそうではありません。その保証は出力分布に関する数学的性質であり、実行側の善意に依存しません。だからコンプライアンスの論証の中で特殊な地位を持ちます。「漏洩リスクが元のデータ量やクエリ回数に比例して増えない」と直接述べられる数少ない技術だからです。

中核となる定義が注目するのは、隣接するデータセットの出力分布が区別できないという点です。記録を一本だけ変更した（あるいはある人物が集合に含まれるかどうかだけを変更した）とき、クエリ結果の分布の差が計算可能なある界の中に収まっていなければなりません。この界の逆数がプライバシー予算（epsilon）です。予算が消費される仕組みが鍵です。クエリのたびに予算が使われ、連続したクエリは保証を単調に弱めます。したがって予算管理は選択肢ではなく、必ず実装しなければならないエンジニアリング上のオブジェクトです。

AI システムにおいて DP の主な置き場所は三つあり、そのエンジニアリング上の難度は大きく異なります。

統計公開が最も成熟した置き場所です。指標クエリにノイズを加え、外部に集計した数値を公開します。利用回数カウント、差分プライバシーデータキューブ、データ指向のクエリ監査システムはこの類です。エンジニアリング上の負担は主に予算台帳とクエリ審査にあります。

モデル学習が二つ目の置き場所です。勾配のクリッピングにノイズを加える手法と、記録ごとのサンプリング確率を使う手法があり、このセットは高額な per-sample 勾配計算を置き換えるために使われます。代償は効用の損失です。プライバシー予算はサンプリング率、クリッピング閾値、総学習ステップ数に直接関係し、この三者が最終的な保証の強さを一緒に決めるため、ハイパーパラメータのチューニングは予算制約の中で行わなければなりません。これは通常の「まず学習して後から調整」という流れとは衝突し、実際の推進の中で最も難しい部分です。全部をファインチューンする、層の一部だけをファインチューンする、軽量アダプタだけ学習する、のいずれを選ぶかで予算と効用の関係はまったく違い、実装にも依存するので、プロジェクト内で実測して決める必要があります。

推論サービス上の DP は三つ目の置き場所であり、しかも最も誤解されやすいものです。出力側に摂動を加えることと、学習で DP を使うことは別のことです。前者は単一の出力から特定記録を反転しにくくするだけで、モデル全体が学習データを漏洩しないことを保証できません。後者にこそ学習データレベルの保証があります。エンジニアリングドキュメントではこの二つを分けて書く必要があります。そうしないと「すでに推論側でノイズを入れたから学習データは安全だ」という、成立しない結論が生まれます。

DP における最大のエンジニアリング上の負担は予算台帳です。次の問いに答えられなければなりません。現在の予算消費はいくらか。誰が消費したのか。どのクエリが消費したのか。残りは何に使えますか。この台帳がなければ、DP は監査できない技術的な宣言に終わります。

プロンプトとログの中の個人情報

RAG とエージェントシステムは、これまで存在しなかった漏洩面を導入しました。ユーザーの入力そのものです。システムはユーザーが任意のコンテンツを貼り付けられるようにしなければならず、そこには身元情報、健康状態の詳細、財務の明細が含まれます。つまり個人情報が入力経路に沿ってプロンプト、トレーシングシステム、ログ、評価データセット、デバッグ用のコンテキストスナップショットの中へ入り込みます。

コントロールポイントは四層あります。第一層は入口側の検出と通知です。明らかに身元証明書番号、銀行口座番号、携帯電話番号、メールアドレスに対してパターン識別を行い、送信前に警告を出すか自動的にマスクします。この層は省略できません。ただしその限界をはっきりさせる必要があります。パターン識別は自由記述の中に含まれる個人情報の召回率に限りがあります。その価値は高確信度の明示的な識別子を遮断することにあるのであって、自由記述の問題を解決することではありません。

第二層は永続化側の方針です。入力内容はデフォルトで長期保存へ入れず、トレーシングとログには必要なメタデータとマスキング済みの要約だけを残します。障害対応のために完全な入力の保存が必要なときは、管理された経路を通さなければなりません（独立した暗号化ストレージ、短期保持、アクセス承認）。この層の「初期値」の判断が中核です。保存しないが初期値である方が、保存するが初期値であるより安全ですが、障害対応の利便性を犠牲にします。したがってアーキテクチャ上で管理された一時ストレージを用意する方が、完全に禁止するより実用的です。

第三層は出力側の検出です。モデルが生成した内容に入力内の個人情報をエコーバックしている場合、あるいは検索断片にユーザーが閲覧権のない原文をエコーバックしている場合は、検出して遮断しなければなりません。検出には生成テキストへのパターン識別と、引用元の権限検証の両方が含まれます。

第四層は評価とテストデータセットのガバナンスです。評価セットは大量の実際のユーザー入力を集めていることが多く、見落とされやすい資産のコピーになっています。主データと同等の分類とアクセス制御が必要です。人手によるアノテーションとモデルのレビュー過程もこれらの内容に触れます。したがってレビュー環境自体も管理下になければなりません。

エージェント（agent）システムはこの四層の困難さをすべて引き上げます。ツール呼び出しの引数と戻り値が新しいデータフローだからです。ツール呼び出しの引数には検索結果から抽出された識別子が含まれる可能性があります。ツールの戻り値にはユーザーがアクセス権のない完全な記録が含まれる可能性があります。したがってツール層の入出力は用途とロールで分類し、エージェントのコンテキスト組み立て部でもこれらのラベルを維持しなければなりません。そうしないとエージェントがコンテキストを整理するときに、異なる権限レベルのデータが黙って混ざってしまいます。

アセット台帳と削除実行の実装

以下のコードは削除要求の実行スケルトンを示しています。来歴識別子からすべての派生コピーを列挙し、アセット種別ごとに対応する削除アダプターへルーティングし、各工程の結果を監査可能な実行記録へ書き込む構造です。強調されているのは「削除のロジック」ではなく「証拠の連鎖」であるという点です。

class ErasureExecutor:
    def run(self, subject_id, request_id):
        # 来源标识是全链路透传的,这里只依赖它做反向定位
        derived = self.provenance.all_derived(subject_id)

        plan = []
        for asset in derived:
            for kind in asset.forms():
                if kind in self.adapters:
                    plan.append((asset, kind, self.adapters[kind]))

        results = []
        for asset, kind, adapter in plan:
            try:
                detail = adapter.erase(subject_id, asset)
                results.append(Outcome(asset=asset, kind=kind, status="ok", detail=detail))
            except NotImplemented as err:
                # 未实现的形态必须显式暴露,不能静默跳过
                results.append(Outcome(asset=asset, kind=kind, status="unsupported",
                                       detail=str(err)))
            except Exception as err:
                results.append(Outcome(asset=asset, kind=kind, status="failed",
                                       detail=str(err)))

        # 未完成删除的资产不允许停留在 pending 状态,要么重试要么上报人工
        self.retry_or_escalate([r for r in results if r.status != "ok"])

        # 审计记录写入只追加日志,并带上请求标识与执行时间
        self.audit.append(AuditRecord(request_id=request_id,
                                      subject_id=subject_id,
                                      results=results,
                                      completed_at=now()))
        return results

    def verify(self, subject_id):
        # 验证不是"删除成功"的同义词:需要重新枚举,确认没有残留
        remaining = [a for a in self.provenance.all_derived(subject_id) if a.live()]
        return remaining

二つの設計を強調しておきたいです。第一に、派生列挙の完全性が削除の信頼性を決めます。来歴識別子がある経路で失われると、その種類の派生アセットは黙って削除をすり抜けるため、adapter は「来歴識別子に依存している」と宣言できなければなりません。経路の欠落は unsupported として露出させ、黙って飛ばしてはいけません。第二に、verify と run を分離することです。削除は冪等な操作であり、検証は再列挙です。検証を通過して初めて、外部に対して完了を宣言できます。エンジニアリングでこの二つを一つの関数にまとめてしまうのは、削除ワークフローにおける最も一般的な設計ミスです。

越境転送と監査：コンプライアンス文書とコントロール項目の対応

越境転送は現在の規制問合せの高頻度領域であり、同時に「文書はきれいに書かれているのに、技術的には何もかもない」という領域でもあります。中核的な問題は、メカニズムが存在するかどうかではなく、問われたときにそのメカニズムが検証可能な証拠を出せるかどうかです。

越境と判定される三つの典型情形

一つ目はデータが国外に保管されている場合で、国外リージョンのデータベース、オブジェクトストレージ、ベクトルストア、ログサービスの利用を含みます。二つ目はデータは国内に保管されていても国外の主体がリモートアクセスできる場合で、国外運用チームの管理者アカウント、国外 SaaS のコントロールプレーン、国外の実体の技術サポート経路を含みます。三つ目は処理そのものが国外で行われる場合、つまりデータが出国した後に国外で計算と推論が行われることで、国外のモデルサービスを呼び出すことも含みます。エンジニアリングでは一つずつ必ず照合しなければなりません。特に二つ目と三つ目は、実際のアーキテクチャでは極めて忘れられがちです。国内のクラスタにデプロイされ、国外のチームが運用するベクトルストアなら、二つの場合に同時に該当します。

該当する各ケースについて、コンプライアンス文書には依存している転送メカニズムと、それに対応する技術的なコントロールを明記しなければなりません。メカニズム自体ではなく、「メカニズムが約束している技術的条件が、本当にシステムの中で成立しているか」を問うものです。たとえば標準契約条項で合意したアクセス制御、暗号化、ログ保持、監査権は、技術側にそれぞれ対応する実装と検証の証拠が必要です。

改ざん不能な監査ログの設計要点

監査ログの価値は、証拠として使えるかどうかで完全に決まります。技術的に「改ざん不能」は通常相対的なものですが、かなり強いものにできます。コツは、いかなる単一コンポーネント（管理者を含めて）が履歴を書き換える能力を持たせないことにあります。

いくつかの典型的な加固手段があります。ログをリアルタイムで本番クラスタの権限ドメインと完全に隔離されたストレージへ外部送信し、本番側には追記書き込みの権限だけを与える。ログの各エントリへハッシュチェーンを張り、各エントリが直前のハッシュを含むようにし、それにより挿入と削除がいずれも検出可能になる。チェーンの先頭を定期的に独立したシステムへアンカーする。すなわちオブジェクトストレージの保持ポリシーロック（WORM）や独立した監査アカウントであり、攻撃者がチェーン全体を巻き戻すことを防ぐ。ログ内容自体も機密怎么处理し、監査ログが新たな漏洩面になることを避ける。すなわちユーザー識別子を平文で記録するのではなくハッシュを取る。関連性は保ったままリスクを減らせます。

見落としやすい攻撃点がもう一つあります。ログレベルの可変性です。アプリケーションが自由に監査ログを停止できたり、出力を一時ファイルへリダイレクトできたりすると、ログの完全性はアプリケーション開発者の自制心に依存してしまいます。エンジニアリングとしては、監査出力を停止できない下層インターフェース（たとえばランタイムによる強制注入）を通し、ログ量の異常な減少、タイムスタンプの欠落、シーケンスの不連続についてはアラートを出すべきです。

文書条項から技術コントロール項目への対応表

コンプライアンス文書の中の約束を一つずつ技術コントロールへマッピングすること、それが監査を実行可能にする前提です。次の表は典型的な対応関係を示していますが、具体的なリストは所在する法域や業界の運用に合わせて調整する必要があります。

文書条項技術コントロール項目検証方法よくある欠落
データの最小化収集収集側の用途ラベル、フィールド必要性レビュー記録スキーマ制約テスト、レビュー記録の抜き取り検査既存の蓄積フィールドを遡って消去していない
処理の目的限定パイプラインゲートの検証、学習タスクの用途一致違反書き込みを構築して拒否するテスト暫定スクリプトとバイパス書き込み
アクセス制御と最小権限オブジェクト単位の認可、鍵の分離、定期的なレビュー権限マトリクスの監査、鍵アクセスログベクトルストアと特徴量ストアの粒度过粗
転送と保存の暗号化at rest 暗号化、転送時の暗号化、鍵のローテーション設定スキャン、鍵バージョン記録バックアップとスナップショットが未対応
削除と保持期間来歴識別子の伝播、削除の実行と検証削除演習、残留列挙レポートキャッシュと派生アセットが未対象
監査の追跡可能性追記式ログ、ハッシュチェーン、外部アンカーチェーン完全性の検証、アンカー記録ログがアプリケーションから停止できる
越境転送の統制越境清単、メカニズムに対応する技術的条件アーキテクチャ巡検、アカウントとアクセス経路の点検国外の運用アカウントとコントロールプレーン
モデルと出力の安全性出力フィルタ、個人情報のエコーバック検出レッドチームテストセット、定期的な回帰プロンプトログの中の個人情報

この表で最も価値が高い使い方は、書き写すことではなく、逆向きに使うことです。一項目ずつ「私たちはこの項目を持っていますか」と問う。そして各項目について、実装済み、部分実装、未実装のいずれかを付け、部分実装には残りの欠落と計画を明記する。この正直な差分リストそのものが優れたコンプライアンス資料になります。すべてにチェックを入れる表よりも信頼できます。審査する側は、チェックの入った表は包装されたものと既定で想定するからです。

鍵管理と資格情報の境界

これまで挙げた多くのコントロールは、最終的には鍵に依存しています。at rest 暗号化はデータ鍵に依存し、TEE の場面では鍵の注入に依存し、詳細な認可は資格情報の分離に依存します。鍵の体系の問題はデータセキュリティの問題という形で爆発するので、独立したデータ域として管理しなければなりません。

基礎となる要求は三つあります。第一に、データ鍵と暗号化されたデータは分けて保管しなければなりません。暗号化鍵を保管するシステム（鍵管理サービス、ハードウェアセキュリティモジュール）の権限ドメインは、データストレージから分離されていなければなりません。そうでなければデータストレージの資格情報を手に入れた時点で復号能力が手に入ります。第二に、鍵のローテーションは実行可能かつサービスを中断させないものでなければなりません。ローテーション後に古いデータを再暗号化する必要があるかは、明示的な判断を要する問題です。多くのシステムが過去データの遡及読み出しのために古い鍵を長期保持することを許していますが、それ自体も評価すべきリスクであり、期限戦略を持たなければなりません。第三に、鍵へのアクセスは痕跡を残さなければならず、この痕跡自体がデータアクセスログと関連していなければなりません。そうでなければ「誰がいつどのデータを復号したか」に答えられません。

多者の場面では、鍵の共有とカストディも考慮する必要があります。機関をまたぐ共同計算では通常、鍵の共同管理と「誰が復号能力を持つか」の明確な取り決めが伴います。この取り決めが欠けていると、プロトコル設計上の約束は具体的な鍵配布のフローまで落とし込まれません。これが、多者協力プロジェクトで最も多い落とし穴です。

多者協業におけるデータ契約と責任分界

二つ以上の主体に関わる AI データ協力では、技術とは別に、前もって取り決めておかなければならないことがあります。そうしないとプロジェクトは実行時に責任不明のまま停滞します。各社がどの粒度のデータにアクセスできるか、モデルの帰属と認可範囲はどうか、出力結果を片方が独占して使えるか、そして、いずれかの参加者が離脱したときのデータとモデルの処分はどうするか。

エンジニアリングで最も見落とされやすいのは離脱条項です。A 社が離脱した時点でも、A 社は自分が付与したデータを削除する権利を持つのでしょうか。そのデータはすでにモデルの重みとベクトルインデックスへ組み込まれており、削除の実現可能性は元の段階よりはるかに低いのです。したがって契約の中で次を取り決めておくべきです。参加前に、モデル内でのデータの不可撤销性を明確にすること。離脱時の処理方法（現行モデルの使用を停止する、その社のデータを含まないバージョンで再学習する、強制削除はしないが利用を制限する）。そして貢献者がモデルの挙動を継続的に検証する権利を持つかどうか。

この部分を契約に書いておくことは、あとから議論するよりずっと安く、そして技術方式の選択に直接影響します。契約が「いずれかの参加者が離脱したら再学習しなければならない」と定めているなら、学習経路には「参加別にデータセットを分割し、再学習に対応する」機能を残しておく必要があります。これをアーキテクチャの初期段階で用意しなければ、後の改修コストが非常に高くなります。

検証：コンプライアンスエンジニアリングには独自のテスト体系が必要である

データコントロールはアーキテクチャの進化に伴って劣化します。これは偶然ではなく必然です。したがってすべてのコントロールに対して対応する自動検証が必要であり、継続的インテグレーションに組み込まなければなりません。そうしないとコンプライアンスの状態は、二、三回のリファクタリングのあとでゼロに戻ってしまいます。

推奨する検証の階層は四種類です。ユニットと統合層の検証です。違反した書き込み（用途が一致しないデータセット、権限外のクエリ、削除権限のない削除要求）を構築し、パイプラインが拒否することを表明します。この種のテストはコストが低く、CI に入れられ、コントロールポイントが配線されたままかどうかをカバーします。周期的なアーキテクチャ巡検です。実際のデータ流とアクセス経路をスキャンし、アカウントのリスト、コントロールプレーンの設定、アベイラビリティゾーンや法域をまたぐアクセス経路を含めて、設計文書との差分を出力します。この種の検査は「誰も書いていないバックドア」を発見するので、定期的に回す必要があります。削除演習です。テスト用の主体で実際の削除要求を定期的に発火させ、列挙、削除、検証のフローを一通り通した結果として、残留レポートを成果物として出します。レッドチームテストです。出力漏洩、プロンプトインジェクション、テナントをまたぐ検索に対して対抗的なテストを行います。この種のテストは網羅できませんが、構造的な問題は発見できます。

この四種類のテストの結果をコンプライアンスの証拠として保存することは、声明書を保存するよりずっと有効です。規制の問合せは通常「どうやって知ったのか」を問うものです。テスト報告ならこの問いに直接答えられます。

学習側：プライバシーデータの記憶と反転

私有データでファインチューンをすると、モデルが一部の訓練サンプルを覚えるということがあります。これはエンジニアリング上、検証すべきリスクではなく既定の事実として扱わなければなりません。直接的帰結はこうです。ファインチューン後のモデルそのものがデータ保護の対象に含まれ、そのアセットの等級は学習に用いた機微データより低くてはならないということです。

記憶の現れ方

観察されうる現象にはいくつかの種類があります。ひとつは逐語記憶です。モデルは、まれなサンプルや書式の特殊なサンプルを丸ごと再現できます。とくに列が短く、複数回現れる、特定の位置に出現するサンプルに 그렇っています。ひとつはパターン記憶です。モデルは珍しい組み合わせでは、一般化された妥当な値ではなく、訓練分布の中の一つの具体的な値を生成しがちです。たとえばある特定の罕见な病名や、ある特定の住所テンプレートを出力しがちです。ひとつはメンバーシップ推論です。モデルがあるサンプルへの信頼度と、ほかの類似サンプルへの信頼度を比較することで、そのサンプルが訓練に参加したかどうかを判定できます。

これらの現象の強さは、データの規模とモデルの規模の比率、訓練の反復回数、データの重複の程度、学習率とオプティマイザの選択など、複数の要素に依存します。エンジニアリングで「学習率を小さくすれば記憶の問題は解決する」と考えることはできません。これらの要素の働き方と大きさは具体的な設定に依存するからです。確実な方法は、「モデルが機微なサンプルを再現するかどうか」を回帰テストの一項目として計測することです。一度きりの設計仮定として扱ってはいけません。

できること、できないこと

できて、かつ有効な手段がいくつかあります。第一にデータ側での抑制です。高リスクのサンプル（識別容易性の高い個人データ、珍しいパターン）を除外または置換し、モデルがその内容を学べないようにします。これは最も直接的な方法で、代償は訓練データの品質低下と「どのサンプルが高リスクか」を判断するコストです。第二に学習目標での抑制です。損失関数に記憶に対するペナル項を加える、あるいは差分プライバシー付き確率的勾配降下法（DP-SGD）のような手法を使い、制御可能なプライバシー予算と引き換えに、より弱い記憶を得ます。このルートには明確な理論的保証がありますが、代償は効用の損失であり、予算の設定は実装と場面に依存するため、実測して決める必要があります。

できないことをはっきり言っておく必要があります。モデルが訓練データ内の機微な内容を出力しないことを保証することはできません。モデル内部に何某かの情報が含まれないことを証明することもできません。学習側の手法だけで再生成のリスクを除去することもできません。差分プライバシーの手法が提供するのは、量化しうる、特定の攻撃モデル（出力漏洩）に対する保証です。メンバーシップ推論以外の推論攻撃はカバーしませんし、モデルの重みファイルそのもののアクセス制御ニーズも消し去りません。重みファイルが漏洩すれば、機微な訓練データを含むモデルは漏洩事象を構成します。

したがって学習側の実際のコンプライアンス姿勢は組み合わせです。データ抑制で機微な入力を減らし、プライバシー予算の方法が記憶の強さを制限し、出力側の遮断で暴露を防ぎ、重みファイルのアクセス制御と暗号化が最後の環を守ります。どれか一つだけでは足りません。そしてこの四層で最も見落とされやすいのは重みファイルです。実験プラットフォームにアップロードされたり、オブジェクトストレージに保管されたり、チーム間でリンクで受け渡されたりして、すべてのデータ方針を完全に迂回していることが多いからです。

2026 年の進展：法規制の進化と技術の実装状況

このセクションではすでにコンセンサスの得られたトレンドとメカニズムだけを記述し、個別の出来事の時間線については断定しません。各地の立法の進捗は大きな差があるため、間違いやすいのはまさに細部だからです。

法規制側：三つの方向

第一に、AI 专项立法が施行段階に入りました。複数の法域で専用の AI 立法または行政の規制枠組みが完成し、それらの共通点はコンプライアンス上の義務を、事後のデータ保護からモデルとシステムのレベルへ拡張していることです。透明性義務、リスク段階分け、高リスク用途への追加要求、そして開発者と提供者の責任の配分です。エンジニアリングチームへの直接的な影響は、これまでなら「データ処理が適法か」を証明すればよかったのに、現在はさらに「システムリスクが評価され、緩和措置が取られたか」を証明しなければならないことです。これは技術文書が学習方法、データ出典、既知の限界、評価の結論を網羅する必要があることを意味します。

第二に、自動化された意思決定の透明性と異議申立ての仕組みが普遍的な要求になっています。システムは特定の判断の主な影響要因を説明でき、影響を受ける者に人手による再審査の経路を提供しなければなりません。エンジニアリングに落とすと、意思決定の根拠連鎖を保持することが必要です。入力特徴量、モデルのバージョン、ルールまたはモデルの出力、そして人手による介入の記録です。これは MLOps の実験追跡の基盤と大量に重なるので、別の仕組みを新たに作るより、同じ記録構造を使い回すほうが楽です。

第三に、越境転送のメカニズムが絞り込まれ、詳しくなっています。判断の根拠が「データが出境するかどうか」から「処理過程が国外で起きているか」および「国外の主体がアクセスできるか」へ拡張されたためです。これにより、国外のモデルサービス、国外の SaaS コントロールプレーン、国外の運用チャネルを使うことがいずれもメカニズムの要件を誘発しうります。同時に、規制当局は「データローカライズ要件と国外の AI サービス利用の組み合わせによる衝突」を気にし始めています。これは現実の中に一つの技術的な制約を生み出します。ある場面では、国内にデプロイされたモデルの能力を使う必要があり、国外のインターフェースを直接呼び出すことはできない、ということです。

技術側：ハードウェアとソリューションの成熟度

機密計算のハードウェアはもう概念検証の段階ではありません。主要なクラウド事業者はいずれも証明机制のあるインスタンスを提供しています。CPU 側のエンクレーブと一部のアクセラレータ側の機密インスタンスは、本番環境で実際にデプロイされています。成熟している部分には次のようなものがあります。証明プロセスとリモートコールには安定した実装があります。コンテナオーケストレーションとの統合は公式または主要なソリューションでサポートされています。鍵注入のパスは比較的標準化されています。依然として難しい部分には次のようなものがあります。GPU 学習シナリオでのサポートは限定的です。サイドチャネル防御の強度をアプリ側から検証することが困難です。ファームウェアと証明ポリシーのアップグレード管理には専任者が必要です。言い換えれば、TEE は推論や特徴処理のような「単発の計算で入力が機微」という場面ではかなり実用的になっていますが、「アクセラレータを長時間占有して学習する」という場面では依然として制約があります。

フェデレーテッド学習のエンジニアリング上の成熟度は明確に上がりました。焦点は主に、機関をまたぐ共同モデリングとコンプライアンス評価のツールチェーンに置かれています。フェデレーテッド学習は単一組織内の分散学習においては依然としてデータ並列の変種にすぎず、プライバシー論証は不要です。その真の価値は多者が互いに信頼しない境界にあり、実装もそこに置かれています。

同型暗号の進展は、暗号学的系変換と小型の暗号文モデルという二つの実用ルートに集中しています。これにより、暗号文ドメインのなかで線形推論を実行することが実行可能なエンジニアリングになりました。深いネットワークと非線形活性化は依然として主な障害で、大規模データセットでの汎用機械学習はほとんど不可能なままです。秘密共有と安全多方計算は暗号学プロトコルライブラリの層では成熟度が高いものの、機械学習パイプラインへの統合は統計系の計算が中心です。

企業が実際に採用した部分

実装の状況を見ると、広く採用されているのは「投資が制御可能で、明瞭な義務に直接対応する」部分です。データ分類と用途ラベルの体系、アクセス制御のオブジェクト単位の細分化、ログの集中と外部送信、暗号化の鍵との分離、そして越境清単とアーキテクチャ巡検です。これらはモデルを変更する必要がなく、パフォーマンスの損失もほとんどなくて、大部分のコンプライアンスの問診に直接カバーできます。

部分的に採用されているのは、TEE を推論と特徴計算の高機敏な経路に使う活用で、主に明確なコンプライアンス上の圧力があり、かつ十分なパフォーマンス余裕のある場面に集中しています。RAG の検索層の権限フィルタリングは、権限体系そのものがすでに成熟している組織で早く導入されます。学習側の出力遮断は、通常は全体のコンテンツセキュリティ体系の一部として一緒に構築されます。

まだ少ないのは、大規模の形式的な匿名化の実装です（より、集約や差分プライバシーの統計量に頼る場面が多くあります）。学習側の差分プライバシー予算の手法は、効用の効くファインチューン場面では進展が遅く、そして HE を通常の推論経路へ導入することもまだまれです。この部分のほぼすべてが、多くの組織でまだ評価と試みの段階にとどまっています。

この分布自体に情報があります。企業は、理論的にはより強力であっても中核の経路を変更する必要がある技術ではなく、摩擦の小さいコントロール項目を優先して採用しています。したがってコンプライアンスエンジニアリングの現実的な推進経路は、まず基礎的なコントロールを最大化し、次に高リスクの経路をより強力な技術へ一つずつ移行することです。最初から全面的なプライバシーコンピューティングの改造から始めることではありません。

実装への道筋：コントロールポイントをアーキテクチャ制約に書き込む

これまで各節で挙げたコントロールポイントが文書の中にしか存在しなければ、さまざまな形で失効します。実際に効く実装方法は、それらをアーキテクチャ決定記録の中で回避できない制約へ変え、違反があればデプロイパイプラインが直接失敗するようにすることです。

投入対効果の順に並べると、推奨する推進順序はこうです。まずデータ分類と用途ラベルを作り、収集側で強制的に書き込ませます。次にオブジェクト単位のアクセス制御を補完し、重点はベクトルストア、特徴量ストア、ログシステムという三か所です。次に監査ログを追記式の外部送信へ変更し、ハッシュチェーンを張ります。続いてすべての派生アセットに来歴識別子を付与し、削除フローで列挙と検証ができるようにします。最後が高機敏な経路に対する TEE や、より厳格な技術手段の導入です。

この順序の背後にある判断はこうです。最初の四項のコストは主にプロセスとメタデータ管理にあり、モデル性能には影響しませんが、あらゆるコンプライアンスの問診の着地点のほとんどをカバーします。後の項目はパフォーマンス予算とアーキテクチャ改造を必要とするので、基礎的なコントロールが信頼できるようになったあとにやるべきです。そうでなければ、信頼できない土台の上にパフォーマンスのコストを積み上げるだけになります。

よくある誤った做法

最後に、エンジニアリングの実践の中で繰り返し現れ、后果も明確な誤りを数種類まとめて、自己点検リストとします。

ベクトルストアをキャッシュ扱いすることです。理由には、検索パイプラインが自動的に生成し、構造化された業務フィールドを含まず、アクセスは通常統一ゲートウェイ経由だという点があります。この認識は、ベクトルストアにオブジェクト単位の権限がなく、分類もなく、削除フローもない、という状態をそのまま招きます。RAG システムにおける最大の単一の漏洩面です。

仮名化を匿名化と呼ぶことです。この誤りは文書や宣伝資料に非常に高い頻度で現れ、代償は責任の境界が誤って主張されることです。漏洩が起きたとき、本来なら個人情報の事象フローを踏むべき事例が遅延して対応される可能性があり、規制当局の追及を受けたときも「私たちは安全措置を実施しただけだ」という位置へ退避できません。

アプリケーション層で権限フィルタリングをすることです。理由は通常「より柔軟で、デバッグが方便」というものです。代償は四種類の障害経路が長期潜伏することであり、キャッシュは一度の権限外行為を複数回へ拡大します。

ログを設定で停止できるようにすることです。理由は、障害対応のためにログレベルを自由に制御したい、というものです。代償は監査の完全性が開発者の自制心に依存することになり、これはまさにコンプライアンスの問診が最も直接的に検査する部分です。

データローカライズを出境しないと同一視することです。国外の運用アカウント、国外のコントロールプレーン、そして国外のモデルサービスの呼び出しというこれらのアクセス経路を落としているのです。この種の欠落は通常、対象を絞ったアーキテクチャ巡検を実施したときに初めて発見されます。

一度のデモで回帰検証を代用することです。どのデータコントロールにも対応する自動テストか定期的な巡検が必要です。とくに権限フィルタリング、削除の実行、そして越境アクセス経路、この三項はアーキテクチャの進化に伴って劣化します。

おわりに

AI データコンプライアンスのエンジニアリング上の難点は、技術が足りないことにはなく、技術とパイプライン設計の間に強制的な接続が欠いていることにあります。マスキング、プライバシーコンピューティング、権限フィルタリング、削除実行という手段はどれも存在しますが、それらが効くかどうかは、コンプライアンス文書の約束リストに書かれたかどうかではなく、アーキテクチャ制約とデプロイ時の検証に書かれたかどうかで決まります。

経験のあるエンジニアリングチームにとって、最も効果的な進め方は常に同じです。まずコントロールポイントを具体的なパイプライン上の位置とアセット種別に対応づける、次に各コントロールポイントがなお成立しているかを自動化された方法で検証する。前者が設計の正しさを決め、後者が設計の長期的な有効性を決めます。前者のみで後者のないコンプライアンス体系は、通常、最初のアーキテクチャのリファクタリングのあとに失効してしまいます。

ベクトルインデックスの削除と再構築：ある具体的なエンジニアリング問題

前にベクトルストア削除の物理構造の問題に触れましたが、ここではより具体的な処理の骨格を示します。強調されるのは「削除の過程において削除待ちの内容を返すことを許さない」という不変条件、そして検証と再構築の関係です。

class ErasurableVectorIndex:
    def mark_for_erasure(self, subject_id, chunk_ids):
        # 第一步:写入墓碑标记,而不是直接物理删除
        # 墓碑在查询路径上立即生效,保证待删内容不再被返回
        for cid in chunk_ids:
            self.tombstone.add(cid)
        self.registry.bind(subject_id, chunk_ids)

    def search(self, query, principal, top_k=8):
        # 第二步:候选生成阶段排除墓碑,而不是取回后再丢弃
        hits = self.index.knn(self.encoder.encode(query), top_k=top_k,
                              where=self.acl.predicate(principal) & self.tombstone.not_deleted())
        return hits

    def compact(self):
        # 第三步:物理回收发生在合并阶段,合并前墓碑内容仍在磁盘上,
        # 因此必须有墓碑年龄上界以及到期强删的兜底路径
        stale = [t for t in self.tombstone.all() if t.age() > self.max_tombstone_age]
        for t in stale:
            self.force_purge(t.chunk_id)
        self.index.compact()

    def verify_absent(self, chunk_id):
        # 验证分两步:查不到,且物理扫描也确认不存在
        if self.index.lookup(chunk_id) is not None:
            return False
        return not self.raw_scan.contains(chunk_id)

三点に注意する必要があります。第一に、墓碑（tombstone）は「論理的な削除」であり、その役割は物理回収のタイミングを要求時刻からマージ時刻まで後ろへ押しやることです。代償はその間もデータがディスク上に残るため、墓碑の寿命の上限と期限到来時の強制削除経路が必ず必要です。さもないと、一つの要求が一度の全量再構築を引き起こしえます。第二に、フィルタ条件はベクトル検索と同じ呼び出しの中で有効でなければなりません。これは前に述べた検索層のフィルタリングと同じ原則です。第三に、検証はインデックスだけを見てはいけません。インデックスのヒット漏れは、削除済みマークが立っているだけで、まだ実際には除去されていない可能性 있기 때문입니다。監査可能な結論を出すには、物理スキャンを組み合わせなければなりません。

保持期間、コスト、コンプライアンスの結合

保持方針はコンプライアンス文書の中では通常一行の文字ですが、エンジニアリングの中では互いに衝突する一群の制約になります。バックアップの保持期間は災害復旧の要件によって決まります（たいていかなり長くなります）。ログの保持期間はデバッグのニーズによって決まり、評価データの保持期間はモデルの改善のニーズによって決まります。そしてこれらのいずれも、個人のデータの法定期限より長くなっている可能性があります。

この問題への対処法は三つあります。第一は階層型の保持です。メインストアは法定期限に従って削除し、バックアップは短い周期でロールオーバーさせ、削除できない部分は暗号隔離とアクセス権限の制限を行い、同時に評価資料の中でそれを明確に説明することです。第二は、削除できない部分を個人のデータの範囲から除外することです。たとえば集約統計やマスキング済みの分布特徴だけを残し、バックアップの中に対象個人へ関連付けられる内容が含まれないようにします。第三は、長いバックアップ保持期間を受け入れることです。その上でリスク評価の中で、そこに含まれる個人のデータの比率と保護措置を論証します。多くの法域でこれは認められています。論証が十分で、対応する暗号化とアクセス制御があることが前提ですが。

どれを選ぶ場合でも、重要なのは保持期間をコンフィグレーション項目として集中管理することです。各サービスのパラメータに散らすことではないのです。エンジニアリングでより安定した方法は、アセットレジストリの中で各アセットの保持期限と期限到来時の処理動作を記載し、そこから巡検タスクが実際の状態と登録値の一致を確認するというものです。一致していない場所こそが、そのシステムの中で最もデータの期限超過が起きやすいポイントです。

内部脅威と権限運用

これまで述べてきたすべての技術的施策が向き合うのは外部の攻撃者です。しかし漏洩事象のかなりの部分は内部に由来します。権限設定の誤り、権限外のクエリ、デバッグ時のデータエクスポート、そして退職後に速やかに回収されなかった資格情報です。これらはプライバシーコンピューティングが解決できる範囲の問題ではありませんが、エンジニアリングには非常に具体的で効果的なコントロールがいくつかあります。

短期資格情報で長期資格情報を置き換えることが、効果の最も高い施策です。すべてのサービス間呼び出しで短期発行されたトークンを使い、そのトークンに呼び出し元の身元と対象リソースを結び付ける。そうすれば資格情報の漏洩窓は「永続」から「分単位」になり、取消しも即座に行えます。データベース側の強制方針も同様に有効です。アプリケーションに全テーブル権限を持つアカウントの使用を禁止し、ビュー単位またはストアドプロシージャ単位でのアクセスを要求する。これにより権限の境界がアプリケーションのコードではなくデータベース内部に置かれます。

運用アクセスの承認と記録も範囲に含めるべきです。高権限のデータベース操作は承認ワークフローを通し、特権セッションの記録、または完全な文単位のログを保持し、そしてデータエクスポート系の操作には独立した承認を設定します。これらは組織のプロセスに属しますが、エンジニアリングとしてできるのは承認結果を技術的な資格情報にすることです。人がまず申請することを覚えておくのではなく、有効な承認識別子を持っている者だけがエクスポートを実行できるようにする。

権限のレビューは常態化させ、しかも内容を持たせる必要があります。「四半期ごとに権限をレビューする」というだけでは、形式的な手続きに終わります。そうするくらいなら、レビューを具体的な問いへ落とすべきです。過去の一期間に機微なアセットへアクセスしたものの、そのロールがその権限を必要としないアカウントはどれか。過去のプロジェクトから引き継がれた権限はどれか。サービスアカウントの所有者がもう該当チームにいないものはどれか。こうしたレビューは、既存の正しい状態を再確認するのではなく、本当の欠落を発見できます。