個人情報保護法の基本とデータ基盤への影響

2022年に全面施行された改正個人情報保護法は、データ基盤の設計に直接影響します。主要な変更点は「仮名加工情報」の新設、漏洩発生時の報告義務、外国への個人情報移転ルールの厳格化です。データエンジニアにとって特に重要なのは、DWHに格納されるデータが「個人情報」に該当するかどうかの判断と、それに応じた加工・アクセス制御の実装です。

個人情報保護法が定める「個人情報」は、生存する個人に関する情報で、氏名・住所・メールアドレス・IPアドレス・Cookie ID等の識別情報を含みます。データ基盤の文脈では、これらの情報を含むカラムを特定し、目的外利用・不正アクセス・漏洩を防ぐ設計が必要です。法律の遵守だけでなく、顧客からの信頼維持という観点でも、適切な個人情報管理は現代のデータ基盤の必須要件となっています。

匿名加工情報と仮名加工情報の違い

比較軸匿名加工情報仮名加工情報
定義特定個人を識別できず、かつ復元不可能な情報他情報と照合すれば特定個人を識別できる情報
復元可能性完全に不可能他情報との照合で可能
個人情報への該当非該当該当(個人情報の一種)
第三者への提供可能(一部手続きあり)原則不可(本人同意等が必要)
利用目的の制限制限なし内部分析・業務改善に限定
主な用途外部提供・公開データ・研究機関との連携DWH内の分析・機械学習・内部レポート
規制の強さ加工基準が厳格比較的実装しやすい

実務上、データ基盤の内部分析では仮名加工情報として取り扱うケースが多くなります。完全な匿名加工は「他の情報と組み合わせても再識別できない」という厳格な基準を満たす必要があり、実装コストが高い反面、外部提供・販売・研究機関への提供が可能になります。

データ基盤での実装パターン

データフロー別の加工ポイント

ソースDB(個人情報を含む生データ)
    │
    ▼ ETL/EL フェーズ(個人情報加工の実施ポイント)
    │  ┌── ハッシュ化: 顧客ID、メール等の識別子
    │  ├── マスキング: 氏名・住所・電話番号
    │  ├── 丸め処理: 誕生日→年齢層、住所→都道府県
    │  └── 削除: 分析不要な個人識別情報
    │
    ▼
クラウドDWH(仮名加工済みデータ)
    │
    ├── 内部分析層: 仮名加工情報のまま利用可
    ├── レポート層: 集計値のみ(→ 実質匿名)
    └── 外部提供: 統計情報・集計値のみ(→ 匿名加工情報)

ハッシュ化・マスキングSQL実装例(BigQuery)

-- 仮名加工: 個人識別子のハッシュ化とマスキング
SELECT
    TO_HEX(SHA256(CONCAT(customer_id, 'company_salt_2024'))) AS pseudo_id,
    CONCAT(LEFT(name, 1), REPEAT('*', GREATEST(LENGTH(name)-1, 0))) AS masked_name,
    REGEXP_EXTRACT(email, r'@(.+)')               AS email_domain_only,
    CONCAT(LEFT(postal_code, 3), '****')          AS masked_postal,
    FLOOR(age / 10) * 10                          AS age_group,
    purchase_category
FROM raw.customers
WHERE is_deleted = FALSE;

このクエリのポイントは3つです。第1にSHA256+ソルト(企業固有の秘密文字列)でIDをハッシュ化し、元の顧客IDを復元不可能にします。第2に氏名は頭文字のみ保持してマスキング。第3に年齢を10歳単位に丸めて個人特定を困難にします。この加工済みデータをdbtのstagingモデルとして定義し、以降の全ての変換はこの加工済みデータを基にすることが基本方針です。

同意管理とデータライフサイクル

改正個人情報保護法では、利用目的の明示と同意管理が強化されています。データ基盤の設計では以下の3点を考慮します。

利用目的別のデータ分離: 「サービス提供のために収集した個人情報」と「マーケティング分析のために同意を得た個人情報」は利用目的が異なります。DWHのテーブル設計段階で用途別のアクセス制御を設計します。

保持期間の自動管理: BigQueryのTable Expiration・PartitionのTTL(Time To Live)設定、Snowflakeのデータ保持ポリシーを使い、保持期間を超えたデータの自動削除を設定します。「削除忘れ」によるリスクを設計で排除することが重要です。

削除要請対応(忘れられる権利): 個人から削除要請が来た際、ソースDB・DWH・バックアップ・キャッシュすべてのデータを追跡して削除するには、データリネージ(A-10)の活用が必要です。個人IDをキーにリネージを遡り、影響範囲を特定して一貫して削除するパイプラインを事前に設計します。

実装時の注意点チェックリスト

チェック項目担当具体的な対応
個人情報カラムの洗い出し・タグ付けデータエンジニア/DPOデータカタログ(DataHub等)でPIIタグを付与
仮名加工処理の実装データエンジニアdbt stagingモデルでハッシュ化・マスキングを実装
カラムレベルのアクセス制御クラウドエンジニアBigQuery Column Security・Snowflake Masking Policies
データ保持期間の設定DPO/エンジニアBigQuery TTL、Snowflakeのデータ保持ポリシーで自動削除
削除要請対応手順の整備DPO/エンジニアデータリネージで所在追跡→削除パイプライン整備
監査ログの有効化クラウドエンジニアBigQuery Audit Logs・Snowflake Access History
外国へのデータ移転の確認法務/DPO外国のDWHへの移転に必要な手続きを確認・実施

ツールとサービスの選択肢

個人情報保護対応を支援するツールカテゴリと代表製品を紹介します。

  • データマスキング・仮名加工: dbt(stagingモデルでSQLベース実装)、Tonic.ai(テスト環境用データマスキング)、IRI FieldShield
  • 同意管理プラットフォーム(CMP): OneTrust、TrustArc、Cookiebot。同意状況をデータ基盤と連携させ、同意取り消し時にデータ利用を自動停止する仕組みを構築します。
  • PIIタグ管理・データカタログ: DataHub・OpenMetadataでPII(個人識別情報)タグを管理し、個人情報を含むテーブル・カラムを一元把握します。
  • アクセス制御: BigQuery Column-level Securityによる列単位の暗号化・アクセス制御、Snowflakeのrow access policiesによる行レベルのアクセス制御が主要な実装手段です。

まとめ

個人情報保護法への対応は、データ基盤設計の最初から組み込むべき要件です。後付けでの対応は工数が大きくリスクが高くなります。

  • 仮名加工情報と匿名加工情報を使い分け、用途に応じた加工レベルを選択する
  • 個人情報のハッシュ化・マスキングはdbt stagingモデルで一元実装する
  • 削除要請対応のためにデータリネージとデータカタログを整備する
  • 保持期間・アクセス制御・監査ログを設計段階から組み込む

よくある質問(FAQ)

Q. 匿名加工情報と仮名加工情報の違いは?

A. 匿名加工は復元不可能な加工で第三者提供が可能、仮名加工は他の情報と照合すれば復元可能で内部分析のみ利用可能です。DWH内の分析用途なら仮名加工情報として扱い、外部提供が必要な場合は匿名加工情報の基準を満たす処理が必要です。

Q. DWHに個人情報を格納してよいですか?

A. 利用目的の範囲内であれば可能ですが、アクセス制御・暗号化・監査ログの実装が必須です。分析用途では仮名加工してから格納するのがリスク軽減の観点で安全です。特にマネージドクラウドDWHでは個人情報の取り扱い規約をベンダーと確認する必要があります。

Q. データ削除要請への対応はどう設計しますか?

A. データリネージで個人データの所在を追跡し、ソースからマートまで一貫して削除/匿名化するパイプラインの事前設計が必要です。「削除リクエストテーブル」を設け、パイプラインの実行時に自動的に該当レコードをマスキング・削除する仕組みが実践的です。