第11章: プライバシー保護技術

この章を読む理由

第10章では、DB/APIから取得したデータを source_dataset、reference_version、analysis_run、api_request_log と結び付け、後から取得元・処理条件・更新履歴を説明できるようにしました。第11章では、その同じメタデータを、アクセス権、同意・利用目的、監査ログ、匿名化 / 仮名化の設計へ接続します。

プライバシー保護は、解析が終わった後に暗号や匿名化を追加する作業ではありません。どのデータを、誰が、どの目的で、いつまで、どの粒度で見られるかを、保存時点から記録する設計です。本章の例は研究・教育用途の概念整理であり、実データや医療データを扱う場合は所属機関の規程、倫理審査、法務・専門家レビューに従う必要があります。

なぜ IT 技術者に必要か

ゲノム・医療・研究データを扱う IT 技術者は、解析コードだけでなく、アクセス制御、監査ログ、暗号化、鍵管理、データ共有条件、削除・保持ポリシーを設計する責任を持つ。本章の目的は、患者個人データや非公開医療データを手元に置く前提ではなく、公開・合成・教育用データで安全設計の考え方を確認することである。

学習目標

• 第10章の source_dataset、reference_version / checksum、analysis_run、api_request_log を、権限・同意・監査ログの設計入力として説明できる
• 暗号、差分プライバシー、匿名化 / 仮名化を、対象データと公開範囲に応じて比較できる
• 研究・教育用途の解析と、個人データ・医療データを扱う運用の責任境界を区別できる
• 日本の個人情報保護、研究倫理、NBDCヒトデータベース、次世代医療基盤法を、設計時に確認すべき一次情報として位置づけられる

前提知識

• 第10章の source_dataset、analysis_run、api_request_log、curated data mart、license / terms 確認日の考え方。
• 第12章の研究解析、教育用解析、臨床実装の責任境界。患者・個人の判断に使わない前提。
• 第13章の DMP、FAIR、provenance、data / code availability statement、倫理審査・専門家レビューの位置づけ。
• 日本の個人情報保護、研究倫理指針、NBDCヒトデータベース、次世代医療基盤法は、本文だけで判断せず、実務時点の一次情報と所属機関の規程で確認すること。
• セキュリティ設計として、最小権限、role、access policy、audit log、key management、incident response、data retention / deletion を区別できること。

基本概念

入力データと出力データ

標準的なワークフロー

1. データの種類、利用目的、同意・利用条件、公開可否を分類する。
2. threat model を作り、攻撃者、内部不正、誤共有、再識別、ログ欠落を洗い出す。
3. role-based / attribute-based access control、最小権限、承認フローを設計する。
4. 保存時・転送時の暗号化、鍵管理、secret 管理、バックアップ、削除手順を決める。
5. audit log、access review、exception handling、incident response の記録単位を固定する。
6. データ共有や外部解析では、契約、制度、倫理審査、NBDC 等の利用条件、確認日を記録する。
7. 結果は安全設計の妥当性評価として扱い、個人情報・医療情報の取扱可否を本文だけで判断しない。

実務上の落とし穴

• 公開データと同じ手順で、非公開の患者データや個人ゲノムデータを扱えると誤解する。
• ログを残していても、誰が何を見たか、権限変更がなぜ行われたかを追跡できない。
• 暗号化だけで安全と判断し、鍵管理、アクセスレビュー、復旧手順、削除手順を設計しない。
• 匿名化・仮名化・統計化を混同し、再識別リスクや小集団リスクを評価しない。
• 日本の制度・ガイドラインやデータベース利用条件の確認日を記録しない。

第10章から引き継ぐ監査メタデータ

監査ログには認証トークン、API key、パスワード、個人識別につながるquery文字列をそのまま保存しません。必要な場合は、認証方式やkey ID、マスク済み値、ハッシュ化した照合値、個人識別情報や医療情報を除去したquery摘要だけを残します。

threat model / access control / audit log の最小設計

暗号、差分プライバシー、匿名化 / 仮名化を選ぶ前に、何から守るのかを短い threat model / 脅威モデルとして書き出します。攻撃者を過度に抽象化すると対策を選べないため、少なくとも内部利用者、外部API、公開レポート、再解析時の運用者を分けて考えます。

この表は、実データ向けの法務判断やセキュリティ設計を代替しません。本文の例では、研究・教育用途の小さな確認表として、次の節で扱う暗号学的手法、差分プライバシー、匿名化 / 仮名化を選ぶ前の前提をそろえるために使います。

日本の制度・ガイドラインを読むときの責任境界

日本の制度や研究データ共有ルールは、用語が似ていても適用範囲と義務が異なります。本書は法令解釈を代替しません。ここでは、研究・教育用途の設計表に「どの一次情報を確認したか」を残すための整理に限定します。実データや医療データを扱う場合は、その時点で有効な法令・指針、所属機関の倫理審査、法務・情報セキュリティ担当者の判断に従います。

この表は「このデータは使ってよい」と判断するためのものではなく、判断に必要な情報の抜けを見つけるためのものです。公開データや合成データだけを使う教育例でも、実データに見える列名、患者数、希少variant / 変異、施設名、取得日を含める場合は、再識別リスクと利用条件を確認します。

controlled-access データと外部 LLM / SaaS の境界

NBDCヒトデータベースの controlled-access / 制限公開データは、利用目的、利用者、所属、承認期間、セキュリティレベル、データ保管場所を分けて審査・記録する前提のデータです。NBDCガイドラインは、すべての LLM / SaaS 名を列挙しているわけではありませんが、利用者限定、目的外利用禁止、再配布禁止、セキュリティガイドライン遵守、機関外サーバ利用条件を求めています。したがって本書の教育・研究運用では、承認申請・契約・所属機関のセキュリティ審査で明示的に許可されていない限り、controlled-access のヒトデータや派生して個人識別性が残るデータを、公開 LLM、外部 SaaS、未承認クラウド、個人端末へ投入しません。⁵⁶⁸

データ発見・変異表現・臨床報告の標準はアクセス許可そのものではないため、第12章: 臨床応用・医療システム連携 の GA4GH VRS、Beacon、HL7 FHIR Genomics の整理とあわせて確認します。

この節は、公開情報から標準や手順を学ぶための安全側の運用原則です。実データで外部サービスを使う必要がある場合は、データ提供元の利用条件、倫理審査、所属機関の情報セキュリティ審査、契約、監査ログ要件を先に確認します。

secure enclave / federated analysis / encryption の位置づけ

保護技術は単独で選ぶのではなく、データを移動するか、計算をどこで行うか、鍵やログを誰が管理するかで組み合わせます。ここでは製品名やクラウド固有機能ではなく、設計時に確認すべき責任境界として整理します。

研究・教育用途の小さな例では、暗号化やfederated analysisを実装したことにせず、どの方式を候補にし、どの前提が未確認かを明記します。実データで採用する場合は、鍵管理、権限分離、監査ログ、障害時対応、専門家レビューを同じ設計書で扱います。

11.1 暗号学的手法

準同型暗号:

• 暗号化状態のまま、特定の演算を行うための暗号技術
• 加法準同型や乗法準同型など、扱える演算は方式・パラメータ・実装に依存する
• 応用候補: 集計、照合、限定された統計量の計算。ただし、通常の解析コードをそのまま暗号化状態で実行できるわけではない

秘密分散:

• データや鍵を複数の断片に分割し、単一の保管先だけでは復元できないようにする
• 閾値秘密分散では、必要数以上の断片を集めた場合だけ復元できる
• 応用候補: 鍵管理、複数機関での共同保管、限定された共同計算。ただし、運用手順と監査が弱いと安全性は担保できない

準同型暗号の概念例（SEAL系ライブラリを想定）: 以下は暗号ライブラリ利用時の責任境界を示す Python 断片です。SEAL系ライブラリの導入、鍵管理、性能測定、運用検証を省略しているため、そのままでは実行できません。 🧪 概念例（実行不可: 暗号ライブラリ導入・鍵管理・運用検証を省略した Python 断片）

# 注：実運用には Microsoft SEAL 本体のビルド、または TenSEAL 等のPythonラッパー（wrapper）が必要です。
# 代表例:
# - Microsoft SEAL: C++実装（公式）
# - TenSEAL: PythonからCKKS等を利用（OS/コンパイラ要件あり）
# - PySEAL: 参考実装
# 本書のコードはAPI設計を説明する概念例であり、実行検証済み実装ではありません。

class HomomorphicWeightedSumBoundaryExample:
    """準同型暗号を使う場合の責任境界を示す概念例"""
    
    def __init__(self):
        """SEALコンテキストの初期化"""
        # 仮想的な実装（実際にはSEALライブラリを使用）
        self.context = self._setup_seal_context()
        
    def _setup_seal_context(self):
        """暗号パラメータの設定"""
        # 実際のSEAL実装の例
        """
        import seal
        
        parms = seal.EncryptionParameters(seal.scheme_type.ckks)
        poly_modulus_degree = 8192
        parms.set_poly_modulus_degree(poly_modulus_degree)
        parms.set_coeff_modulus(seal.CoeffModulus.Create(
            poly_modulus_degree, [60, 40, 40, 60]))
        
        scale = 2.0**40
        
        context = seal.SEALContext(parms)
        return context
        """
        return None  # デモ用
    
    def encrypt_genotype(self, genotype_vector):
        """
        ジェノタイプデータの暗号化
        
        Args:
            genotype_vector: SNPデータ（0,1,2の配列）
        
        Returns:
            暗号化されたデータ
        """
        # 実際の暗号化処理
        # encrypted = []
        # for value in genotype_vector:
        #     ciphertext = self.encryptor.encrypt(self.encoder.encode(value))
        #     encrypted.append(ciphertext)
        
        # デモ用の仮想実装: 後続の zip(encrypted_genotype, weights) と
        # 形をそろえるため、暗号文プレースホルダーの配列として返す。
        return [
            {'encrypted': True, 'index': index, 'ciphertext_placeholder': '<ciphertext>'}
            for index, _ in enumerate(genotype_vector)
        ]
    
    def compute_weighted_sum_encrypted(self, encrypted_genotype, weights):
        """
        暗号化状態での教育用の重み付き集計
        
        Args:
            encrypted_genotype: 暗号化されたジェノタイプ
            weights: 各SNPに対応する重み（平文）
        
        Returns:
            暗号化された集計値
        """
        # 準同型演算の例
        # encrypted_sum = sum(encrypted_g * w for encrypted_g, w in zip(encrypted_genotype, weights))
        
        return {'encrypted_sum': True, 'computation': 'homomorphic'}

データ活用とプライバシーの両立: ゲノムデータは本人だけでなく血縁者や集団に関する情報も含み得るため、単に暗号化するだけでは十分ではありません。準同型暗号や秘密分散は、同意、利用目的、アクセス制御、監査ログ、匿名化 / 仮名化と組み合わせる選択肢です。採用前には、対象演算、性能、鍵管理、復元権限、障害時対応、専門家レビューの要否を明確にし、概念検証と本番運用を分けて評価します。

11.2 差分プライバシー

定義: ε-差分プライバシーは、1個のレコードの有無によって、公開される集計結果の分布が大きく変わりすぎないように制御する枠組みです。保証の対象は「定義したクエリ、機構、privacy budget、前処理・後処理の範囲」に限られ、元データの安全管理、同意、アクセス制御、監査ログを置き換えるものではありません。

実装手法:

• ラプラス機構: 数値クエリにノイズ付加
• 指数機構: 非数値クエリの確率的選択
• 応用候補: 十分な集団サイズがある統計量の公開、頻度表、集計レポート

差分プライバシーの概念例: 以下は差分プライバシーの集計公開で検討する処理境界を示す Python 断片です。入力データ、privacy budget 設計、公開抑制条件、乱数管理を省略しているため、そのままでは検証済みの公開処理として利用できません。 🧪 概念例（実行不可: 入力データ・privacy budget 設計・公開判定を省略した Python 断片）

import numpy as np

class DifferentialPrivacyAlleleFrequencyExample:
    """差分プライバシーで公開する集計値の責任境界を示す概念例"""
    
    def __init__(self, epsilon=1.0):
        """
        Args:
            epsilon: プライバシーパラメータ（小さいほど強い保護）
        """
        self.epsilon = epsilon
        
    def laplace_mechanism(self, true_value, sensitivity):
        """
        ラプラス機構によるノイズ付加
        
        Args:
            true_value: 真の値
            sensitivity: 感度（1レコード変更の最大影響）
        
        Returns:
            ノイズ付加された値
        """
        scale = sensitivity / self.epsilon
        noise = np.random.laplace(0, scale)
        return true_value + noise
    
    def private_allele_frequency(self, genotypes):
        """
        アレル頻度にノイズを加える概念例
        
        Args:
            genotypes: ジェノタイプデータ（0,1,2）
        
        Returns:
            ノイズ付加と後処理を行ったアレル頻度
        """
        # アレル数のカウント
        allele_count = np.sum(genotypes)
        total_alleles = len(genotypes) * 2
        
        # 感度：1人の変更で最大2アレル変化
        sensitivity = 2.0 / total_alleles
        
        # 真の頻度
        true_frequency = allele_count / total_alleles
        
        # ノイズ付加
        private_frequency = self.laplace_mechanism(true_frequency, sensitivity)
        
        # [0,1]の範囲にクリップ
        return np.clip(private_frequency, 0, 1)

科学的厳密性の確保: 差分プライバシーは、定義した集計公開に対して数学的に扱える保護水準を与える一方、値の有用性、説明可能性、反復公開時のbudget管理に制約があります。「理論的に安全」と断定するのではなく、どのクエリに、どの epsilon を、何回まで使い、どの結果を公開しないかを事前に決めます。研究・教育用途でも、希少variant / 変異や小集団の集計では、公開抑制、丸め、専門家レビューを組み合わせて判断します。

11.3 匿名化技術

匿名化 / 仮名化は、データを公開できる状態へ自動的に変える魔法ではありません。氏名やIDを削除しても、年齢、性別、地域、疾患、希少variant / 変異、受診時期などを組み合わせると再識別リスクが残ります。第10章の source_dataset と curated data mart の列設計に戻り、どの列を削除、一般化、丸め、集計、抑制するかを明示します。

k-匿名性:

• 同一の準識別子を持つレコードをk個以上確保
• 限界: 同質性攻撃、背景知識攻撃、希少な組み合わせへの弱さ

l-多様性:

• 各等価クラス内でセンシティブ属性をl種類以上確保
• 限界: 属性分布が偏っている場合や、値の近さに意味がある場合は十分でない

t-近似性:

• 等価クラス内外でのセンシティブ属性分布の差を一定範囲に抑える考え方
• 限界: 分布差の定義、しきい値、データ有用性の低下を事前に検討する必要がある

実用的データ活用の基盤: 匿名化 / 仮名化の判断は、解析目的、公開範囲、攻撃者が持ち得る背景知識、データの希少性、再利用条件によって変わります。本書の例では、研究・教育用途の確認表として、対象列、変換ルール、残る再識別リスク、公開しない項目、専門家レビューが必要な条件を残します。実データや医療データを扱う場合は、所属機関の規程、倫理審査、法務・セキュリティ担当者のレビューに従います。

小さな実例

以下は、実データや患者データを使わない架空の確認表です。法務助言、臨床判断、施設規程の代替ではなく、実務で専門家レビューに渡す前に「何を確認すべきか」を漏らさないための概念例です。

この例で重要なのは、暗号・差分プライバシー・匿名化のどれかを選ぶことではなく、利用目的、データ区分、権限、ログ、公開範囲、残るリスクを同じ表で説明できるようにすることです。

結果の読み方

監査ログやアクセス制御の結果は、単に「エラーがない」ことではなく、目的外アクセス、権限過多、例外承認、鍵操作、データ持ち出し、削除漏れを説明できるかで読む。差分プライバシーや匿名化の指標も、リスクをゼロにする保証ではなく、仮定と用途の範囲内での安全性の説明である。

限界と注意点

本章は研究・教育用データを前提に安全設計を学ぶ章であり、実際の患者個人データ、非公開医療データ、個人ゲノムデータを扱う承認を与えるものではない。実運用では、所属機関の規程、契約、倫理審査、法務・情報セキュリティ部門、データ提供元の条件に従う必要がある。

Source notes / 次の一歩

• 2026年版出典監査メモ: 日本の個人情報・研究倫理（個人情報保護法、研究倫理指針、NBDCヒトデータベース、次世代医療基盤法の確認日）
• 第10章: データベース技術（source_dataset、analysis_run、api_request_log と来歴管理）
• 第12章: 臨床応用・医療システム連携（臨床判断・研究解析・教育用途の責任境界）
• 第13章: 研究方法論・統計・再現性（研究計画、DMP、FAIR、provenance）

2026年時点の更新メモ

• 個人情報保護法、研究倫理指針、NBDCヒトデータベース、次世代医療基盤法などは、対象データ、利用目的、第三者提供、匿名加工・仮名加工、認定事業者、外部 LLM / SaaS 利用可否の条件を分けて確認する。
• secure enclave、federated analysis、差分プライバシー、暗号化は有用な選択肢だが、同意、アクセス制御、監査ログ、契約、倫理審査を置き換えない。
• 更新根拠は 2026年版出典監査メモの日本の個人情報・研究倫理項目と clinical interoperability / data standards 項目へ集約する（確認日: 2026-06-05 JST）。

最小入出力（期待成果物/期待ログ）

• 入力: 扱うデータの範囲（合成データ推奨）、source_dataset、reference_version / checksum、analysis_run、api_request_log、想定する攻撃モデル、利用目的、公開範囲、権限ロール
• 出力（期待成果物）: 制度・ガイドライン確認表、保護手法の選定（暗号/差分プライバシー/匿名化）、主要パラメータ（例: ε, k）、匿名化 / 仮名化対象列、access policy、リスク評価メモ
• 期待ログ（例）: パラメータ・前提、DP機構・privacy budget・実装version、検証用seed（本番ノイズを再生成できないもの）、承認ID、実行者、実行日時、入力snapshot、reference_version / checksum、検証日時、出力先、アクセス判定結果が記録される。本番で公開したDP集計のノイズ生成seedは、公開値から真値を推定できないよう監査ログへ残さない。概念例のみの場合は「実装なし」を明記する。

演習

1. source_dataset、reference_version / checksum、analysis_run、api_request_log を入力に、研究・教育用途の解析で必要な権限ロール、承認ID、保持期間、監査ログ項目を設計せよ。
2. 実データを扱わない教育例であっても、個人情報保護、研究倫理、NBDC、次世代医療基盤法のどれを「対象外」「要確認」「適用可能性あり」とするかを確認表にまとめよ。
3. 暗号、差分プライバシー、匿名化 / 仮名化のいずれかを選び、選定理由、主要パラメータ、残るリスク、専門家レビューが必要な条件を整理せよ。

具体課題例

• TCGA-LUAD の研究用データマートを例に、解析者、管理者、監査担当者が見られる列と操作を分ける。
• api_request_log に残る endpoint / query / HTTP status を、公開レポートに出してよい項目と内部監査だけに残す項目へ分類する。
• 匿名化 / 仮名化対象列、access policy、承認ID、実行ログ、出力先、削除・保持期間を1枚の確認表にまとめる。