AIネイティブ時代のプライバシーインフラ：MetaがLLMでデータを分類する7ステップパターン

はじめに：なぜ今、データ分類が問題なのか

AIサービスが普及するにつれ、私たちが扱うデータはもはや整然としたテーブルやカラムだけではありません。ログキー、イベントパラメータ、埋め込みベクトル、ML特徴量、パイプランの中間生成物...データの形態は多様化し、その意味はコンテキストによってまったく異なります。

例えば、単に age という名前のフィールドがあるとします。あるシステムではユーザーの年齢を保存する機密情報かもしれませんが、別のインフラパイプラインではキャッシュTTL（Time-To-Live）の単なる数値かもしれません。前者であればGDPRやCCPAなどの厳格な保護ポリシーが適用されるべきですが、後者であればそのまま素通りしてよい運用データです。

このような微妙な違いをシステムが正確に理解し分類することが、プライバシー対応インフラ（Privacy-Aware Infrastructure, PAI） の出発点です。Metaのエンジニアリングブログで公開されたこの事例研究は、この課題をLLMと決定論的ルールのハイブリッドパターンでどのように解決したかを詳細に示しています。

本記事では、原文のエッセンスを実務者の視点で再構成しました。単なる翻訳ではなく、日本の開発環境で適用可能なインサイトと注意点を合わせてお伝えします。

中核パターン：7ステップで解きほぐすハイブリッド分類システム

Metaチームが提示したアプローチは、大きく7つのステップで構成されます。各ステップは、「LLMですべてを解決しようとせず、LLMは曖昧な部分を処理し、安定化したパターンは決定論的ルールに蒸留(distill)する」という原則に基づいています。

ステップ1：契約(Contract)をまず明確にせよ

分類器はプラットフォームサービスのように振る舞うべきです。つまり、入力と出力の契約が小さく、明確で、安定している必要があります。Metaチームは、各分類器が1つの狭い質問（例：「このアセットはユーザーデータか？」）だけを担当するように設計しました。出力は常に以下を含みます：

• 分類カテゴリ
• 信頼度スコア（モデル自己評価）
• 決定根拠（Decision Trace）
• マッチしたルール（決定論的ロジック使用時）
• コンテキスト、ルール、プロンプトのバージョン情報

ステップ2：プロンプトよりコンテキストを先に構築せよ

Metaチームが最も強調する部分です。分類失敗の大部分はプロンプトが弱いからではなく、証拠（コンテキスト）が不足しているために発生しました。

単にフィールド名だけを見てモデルに推測させる代わりに、以下のような「証拠ブリーフ（Evidence Brief）」を構成します：

• ソースコード解決情報（フィールドが定義/使用された場所）
• 所有権および組織メタデータ
• 意味論的アノテーション（データ型、出典）
• 系列（Lineage）情報（データの流れ）
• MLヒューリスティック出力（スキャナー、埋め込みベース分類器）
• コード検索結果（参照、ロギング宣言、呼び出し箇所）

ここで重要なのは、循環参照（Circular Reasoning）を防止するために、すでに正解を暗示するフィールドはモデルに提供せずマスキングする点です。このマスキングは単なるプロンプト衛生ではなく、システム不変ルール（System Invariant） として扱われます。

ステップ3：決定ファネル（Decision Funnel）を使用

コンテキストが準備できたら、分類器は2つの経路に分岐します：

1. 決定論的経路（Deterministic Path）： バージョン管理されたルールがマッチすれば、ミリ秒単位で高速に決定。全トラフィックの約85%を処理。
2. LLMベース経路： 新規または曖昧なアセットはLLMが証拠ブリーフを分析。約15%を処理し、数秒かかり、コストは約400倍。

両方の経路とも同じ結果スキーマ（カテゴリ、信頼度、根拠、バージョン）を出力するため、ダウンストリームシステムは決定がどこから来たかを知る必要がありません。

ステップ4：コールドスタートを意図的に解決せよ

初期段階ではラベルがほとんどない状態から始めます。ランダムサンプリングではなく、ポリシーに基づいた例をシーディング（seeding）します：

• レアな機密カテゴリ
• 境界ケース（ポリシー解釈が難しい場合）
• 機密に見えるが実際はそうでないネガティブ例
• コンテキストシグナルが衝突するアセット

ステップ5：学習ループを安全に保て

最も重要な設計原則の1つは、モデルが自分の宿題を自分で採点できないようにすることです。Metaチームは2つのループを分離しました：

• 参照ループ（Reference Loop）： 人間がレビューしたラベルを追加専用、バージョン管理。このラベルが評価の基準となります。
• 最適化ループ（Optimization Loop）： プロンプト、ルーティング、コンテキスト使用を改善しますが、常に参照ループのラベルで評価されます。

また、3人の独立した「ジャッジ（Judge）」LLMを使用して多数決で最終ラベルを決定し、Cohen's Kappaでジャッジ間の信頼性を測定します。この指標に基づき、システムは自ら「停止すべき時」を認識します。

ステップ6：安定した振る舞いをルールに蒸留せよ

LLMが発見した安定したパターンは、段階的に決定論的ルールに変換されます：

• ステージ1： 単一フィールドベースルール（完全一致、キーワード、数値範囲など）
• ステージ2： 複合ルール（例：「on-callにXを含む AND semantic typeがACCOUNT_ID」）
• ステージ3（オプション）： LLMがルール生成を支援しますが、すべての候補は厳格な検証ゲート（ホールドアウト検証、シャドウモード、人間レビュー）を通過しなければプロダクションにデプロイされません。

この蒸留プロセスにより、LLMのプロダクションでの役割は徐々に減少し、最終的にはLLMがまったく不要な決定論的エンジンのみで日常的な分類が行われるようになります。

ステップ7：正しいものを自動化せよ

自動化の境界を明確に設定します。コンテキスト収集、証拠ブリーフ生成、候補分類、評価実行、障害分析、候補ルール提案は自動化します。しかし、ポリシー解釈、参照ラベルのレビュー、高リスクの不一致、保護レベルを変更しうるルールの承認は、必ず人間の判断を経るように設計しました。

以上の7ステップパターンは、以下のコードスニペットで概念的に要約できます：

# 概念例：決定ファネル（Decision Funnel）

def classify_asset(asset_id, context_bundle):
    # 1. 証拠ブリーフ生成（コンテキストから重要シグナルを抽出）
    evidence_brief = build_evidence_brief(asset_id, context_bundle)
    
    # 2. まず決定論的ルールを試行
    matched_rule = find_matching_rule(evidence_brief)
    if matched_rule:
        return deterministic_decision(matched_rule, evidence_brief)
    
    # 3. LLMフォールバック（曖昧な場合）
    llm_result = llm_classify(evidence_brief)
    
    # 4. 信頼度が低い、またはジャッジ不一致の場合は人間レビューへルーティング
    if llm_result.confidence < AUTO_ACCEPT_THRESHOLD:
        route_to_human_review(asset_id, evidence_brief, llm_result)
    
    return llm_result

日本の開発環境における適用コンテキスト

Metaのこのパターンは大規模なビッグテックの事例ですが、日本の環境でも十分に適用可能な原則を含んでいます。

1. レガシーシステム / 金融機関: 日本のSI案件や金融機関のシステムには、多数のテーブルとカラムが存在しますが、データの意味（個人情報かどうか）がドキュメント化されていないケースが多く見られます。このパターンを応用すれば、初期はLLMで迅速に分類を試み、安定したパターンが発見されればSQLベースの決定論的ルールに移行できます。例えば、カラム名に「氏名」「生年月日」「電話番号」などのキーワードが含まれていれば自動的に機密情報と分類するルールを先に設定し、残りの曖昧なケースだけをLLMに渡す方法です。

2. スタートアップの迅速なプロダクト開発: スタートアップはデータガバナンスに投資する余裕が限られています。しかし、このパターンは「完全な分類」よりも「継続的な改善」を目標としています。初期はシンプルなキーワードベースのルールだけから始め、サービスが成長するにつれてLLMベースの分類を導入し、さらに安定したパターンをルール化するという段階的な高度化が可能です。

3. 注意点:

• コスト： LLM推論コストは決定論的ルールの約400倍にもなる可能性があります。日本の環境ではトークンコストが特に重要になるため、LLMの使用量を継続的にモニタリングし、ルールカバレッジを拡大することがコスト最適化の鍵です。
• 日本語データ： 日本語は膠着語の特性上、形態素解析が重要です。単純なキーワードマッチだけでは「氏名」「お名前」「ネーム」などの多様な表現を捉えきれません。初期ルール設計時には、正規表現とともに日本語形態素解析器を活用したパターンを検討すべきです。
• 規制対応： 個人情報保護法など日本の規制は、データ分類により厳格な基準を求める可能性があります。「自動分類」の結果を完全に信頼するのではなく、一定割合のサンプルを常に人間がレビューする「監査ループ」をシステムに組み込むことが望ましいでしょう。

結論：プライバシーインフラは「税金」ではなく「より良いアーキテクチャ」の原動力

Metaのこの事例が与える最大の教訓は、プライバシーインフラの構築が単なるコンプライアンスコストではなく、システムアーキテクチャをより明確にし、豊かなコンテキストを備え、安全に進化させる原動力になり得るという点です。

中核原則を改めて整理します：

1. コンテキストがプロンプトより重要である。 モデルにより良い質問を考える前に、より良い証拠を提供せよ。
2. 決定論は再現可能性を意味する。 LLMが同じ答えを出すことではなく、同じ入力とバージョンで同じ決定を再現できること。
3. 精度だけで判断するな。 不均衡データセットではマシュー相関係数、macro F1、クラス別再現率など複数の指標を併用せよ。
4. LLMの推薦と真実（参照ラベル）は分離せよ。 モデルに自分の採点をさせてはならない。
5. カバレッジは正確性と等しくない。 自動化率が上がっても品質が維持されているか常に確認せよ。
6. 蒸留（Distillation）がプロダクションモデルである。 LLMは発見と推論に使い、安定したパターンは決定論的ルールに変換せよ。
7. 自己規制は運用ではなくアーキテクチャの問題である。 システムが自ら停止する方法を知っていなければならない。

次のステップとしての学習方向

• 実践： ご自身のプロジェクトで最も分類が曖昧なデータフィールドを3つ選び、手動で「証拠ブリーフ」を作成してみてください。どのようなコンテキストが決定に役立つかを考えるだけでも、大きなインサイトが得られます。
• ツール探求： オープンソースのデータ分類ツール（例：Apache Atlas、DataHub）とLLMを組み合わせたPoCを実施してみましょう。
• 発展学習： Metaのこのパターンは「エージェントの可観測性（Agent Observability）」など他の領域にも拡張可能とされています。LLMエージェントの行動を監査するアーキテクチャにも同じ原則が適用できるでしょう。

出典： 本記事はMetaエンジニアリングブログの「Privacy-aware infrastructure in the AI-native era: An asset classification case study」を基に作成しました。

合わせて読みたい記事

• NVIDIA IGX Thor、産業用エッジAIのゲームチェンジャー登場
• NVIDIA DLSS 4.5公開：超解像度強化と動的マルチフレーム生成