タイ PDPA（Personal Data Protection Act B.E. 2562 / 2019）は、個人データの処理者に対して「適切な技術的保護措置」を求めるが、具体的な暗号化方式は指定していない。AES-256 は米国連邦政府・FIPS 197・ISO/IEC 18033-3 で承認された対称暗号であり、実務上の「適切な措置」のベースラインとして広く採用されている。本記事は、タイ現地法人で AI プロダクトを運用する情シス・開発者向けに、PDPA 準拠を目的とした AES-256 の実装パターンを、暗号化対象の選定から鍵管理・監査対応まで一気通貫で整理する。タイの PDPA 対応全体のチェックリスト（同意取得・DPO 設置・越境移転など）は別記事で扱っており、本記事はその技術実装レイヤーに特化する。

タイPDPAでは、データ管理者は個人データの漏えい、アクセス、使用、改ざん、開示を防ぐための適切な技術的・組織的安全管理措置を講じる必要がある。具体的な暗号化アルゴリズムは条文上で指定されていないため、AES-256の採用は実務上の選択肢として位置づけるのが適切である。

PDPA の条文を読むと抽象的な文言が多く、「何を実装すれば合格なのか」が判断しづらい。この節では、PDPA の要件と AES-256 の位置づけ、そして既存の PDPA コンプライアンスチェックリスト記事との役割分担を整理する。

タイ PDPA Section 37(1) は、データ管理者（Data Controller）に対して「個人データの喪失・不正アクセス・使用・改ざん・開示を防ぐため、適切な技術的および組織的な安全対策を講じる」ことを義務づけている。この条文の構造は EU の GDPR Article 32 とほぼ同等で、全面施行以降、タイ PDPC（Personal Data Protection Committee）が発行するガイドラインでも、暗号化・仮名化・アクセス制御が「期待される対策」として列挙されている。

違反時の制裁は、法令上の罰則、行政上の対応、民事上の救済がそれぞれ問題になりうる。具体的な上限額や条文上の区分は、最新の法令本文で確認したうえで整理する必要がある。

AI システムは扱う個人データ量が多く、特にセンシティブ個人データ（健康情報・信条・生体情報など）は Section 26 で厳格な追加保護が求められる。

実務上、「適切な技術的保護措置」が何を指すかは業界標準に依存する。ISO/IEC 27001・ISO/IEC 29100 などの国際標準や、NIST SP 800-53 のコントロールが参照されるのが一般的で、AES-256 はこれらの標準でいずれも推奨アルゴリズムとして位置づけられている。

AES-256 を「適切な措置」として採用する根拠は、複数の公的承認に裏付けられている。AES-256はNISTのFIPS 197で標準化され、NSAのCNSA SuiteでもTop Secretレベルまでの保護に用いられるアルゴリズムとして扱われているため、実務上は採用しやすい。もっとも、PDPA監査での妥当性は、脅威モデル、鍵管理、アクセス制御、監査証跡を含めて総合的に説明する必要がある。AESはNIST FIPS 197で標準化された対称ブロック暗号であり、国際規格でも広く参照されている。規格名を出す場合は、対象の版と正式な位置づけを確認して記載する。

クラウドKMSやTLS 1.3は、現行の標準的な暗号運用を支える仕組みとして有用である。もっとも、TLS 1.3の暗号スイートや各クラウドKMSの既定動作はサービスごとに異なるため、採用時は各ベンダーの最新仕様を確認する必要がある。タイ PDPC から AES-256 固有のガイドラインが発行されているわけではないが、国際標準との整合性があれば、監査で「合理的な判断」として説明しやすい。

逆に、AES 以外の旧式暗号（DES、3DES、RC4）や、自社で独自開発した暗号を採用すると、監査で「適切性」を立証するハードルが一気に上がる。AES-256 を選ぶ最大の実務メリットは、「選定理由を説明する必要が最小限で済む」点にある。

PDPA 対応は技術面と組織面の両輪で進める必要があり、両者を一つの記事に押し込めると密度が下がる。本記事は技術実装レイヤー、特に暗号化と鍵管理に特化する。組織・契約面の論点は別記事で整理するが、通知フローや責任分担は最新のPDPA運用に合わせて都度見直す必要がある。

本記事はそこで扱わなかった技術実装レイヤー、特に暗号化と鍵管理に特化する。両記事は併用を想定しており、先にチェックリスト側で組織体制を整え、その中で「技術的保護措置」の実装が宿題として残った開発チーム向けに本記事を位置づけている。

読み進め方の推奨フローは次のとおり。PDPA 対応プロジェクトを立ち上げた初期フェーズでチェックリスト記事を参照し、DPO や契約雛形を整える。その後、開発チームが具体的な暗号化実装に入るタイミングで本記事に戻ってくる。技術面の実装が一段落したら、再度チェックリスト側で組織運用の継続性を点検する、という往復が実務的だ。

AIシステムでは、プロンプト、応答、ログ、埋め込みベクトル、学習データに個人データが含まれうるため、層ごとに保存・アクセス・保持期間を分けて設計する必要がある。暗号化の要否も、検索性や監査要件とのバランスを踏まえて判断する。

「API 経由で外部 LLM に送るだけだから自社 DB では暗号化不要」という誤認は典型的な PDPA 違反パターンになる。以下では AI 固有の 4 層を、データの特性別に 2 つの H3 に分けて整理する。

AI システムのプロンプトには、ユーザーが意識せずに個人データを書き込むことが多い。「私の名前は〇〇で、先月健康診断で△△と言われた。このデータをどう解釈すべきか」といった入力は、AI 利用シーンでは日常的に発生する。プロンプトが平文で DB に保存されていれば、そのデータベースが丸ごと PDPA の管理対象になる。

応答側も同様に個人データを再生する可能性がある。RAG（Retrieval-Augmented Generation）を使う場合、社内のドキュメント（人事評価・顧客リスト・医療記録など）を検索結果として返すため、応答テキスト自体に個人データが含まれる。応答を会話履歴として保管する場合、その保管先も暗号化対象になる。

見落としやすいのがログファイルだ。デバッグ目的でプロンプトと応答を平文ログに出力し、数ヶ月〜数年にわたって保管するケースは多い。ログは「気づいたら肥大化し、削除ポリシーも曖昧」になりやすく、PDPA 違反時の典型的な漏洩経路になる。ログは機微性に応じて暗号化し、保管期間ポリシーを定めたうえで不要になったものは適切に削除するのが望ましい。保存期間は業務要件や法定保存義務と整合させて決める必要がある。

ベクトルデータベース（Pinecone、Supabase pgvector、Chroma など）に保存される埋め込みベクトルには元テキストの一部を推定されるリスクがあるため、機微情報を含む場合は保存方法を慎重に設計する必要がある。検索要件との兼ね合いを踏まえ、暗号化、アクセス制御、保存期間の管理を組み合わせるのが望ましい。

会話履歴（チャット履歴）は、プロダクトによって保管期間が数時間から数年までまちまちだが、PDPA の保管期間制限（目的達成後は削除）を満たすためにも、暗号化と削除ポリシーを両立する設計が必要になる。Postgres であれば pgcrypto 拡張、MySQL であれば InnoDB TDE、NoSQL であれば KMS 連携オプションを使うのが標準パターンである。

学習データ（ファインチューニング用コーパス、RAG 用ドキュメント）は、業務データが大量に含まれることが多い最もリスクの高い対象だ。学習データは「実行時にしか復号しない」設計にし、平時は暗号化状態で保管する。クラウド上の学習ジョブで復号する場合、一時領域（/tmp）への書き込みが残留していないか、ジョブ終了後のクリーンアップも監査対象に含める。

AES-256 は「アルゴリズム名を選ぶ」だけでは安全にならない。モード・初期化ベクトル（IV）・認証タグの 3 要素を正しく組み合わせて初めて、機密性と完全性が担保される。実装時の選定ミスは、AES-256 を使っていながら実質的に平文と変わらない結果を招く。

実務では GCM と CBC の選び分け、そして転送時と保存時の整合が最も頻繁に問われる。以下の 2 つの H3 でそれぞれを整理する。

AES には複数のブロック暗号モードが定義されているが、新規実装では、原則としてGCMのようなAEADモードを採用するのがよい。環境によっては他のAEAD方式がより適切な場合もあるため、性能要件や既存資産との互換性を踏まえて選定する。GCM は AEAD（Authenticated Encryption with Associated Data）方式であり、暗号化と同時に認証タグを生成する。これにより、暗号文が改ざんされた場合に復号段階で検出できる。

CBC（Cipher Block Chaining）モードは歴史的に広く使われてきたが、認証機能を持たないため、別途 HMAC を付与しない限り改ざんを検出できない。CBC + HMAC の組み合わせを自前実装するより、GCM を使うほうが実装ミスが入り込む余地が少ない。既存レガシーシステムとの互換性が必要な場合を除いて、CBC を新規採用する理由は乏しい。

GCM を使う上での最大の落とし穴は IV（初期化ベクトル、nonce）の再利用だ。同じ鍵と同じ IV で 2 つの平文を暗号化すると、XOR 関係から平文を復元できる致命的な脆弱性が生じる。実装では必ず暗号学的に安全な乱数で IV を生成し、同じ鍵での再利用を避けるカウンター管理や、専用ライブラリ（例: Node.js crypto.createCipheriv、Python cryptography.hazmat）の推奨パターンに従う。

データのライフサイクル全体で暗号化を担保するには、転送時と保存時の両方を押さえる必要がある。片方だけの実装は、必ずどこかで平文が露出する穴を作る。

転送時はTLS 1.3を基本とし、利用する暗号スイートは環境とベンダーの設定方針に応じて選定する。AES-256-GCMは有力な選択肢の一つだが、TLS 1.3全体の既定値として扱うべきではない。CDN やリバースプロキシの設定を TLS 1.3 + AES-256-GCM のみ許可する構成にし、TLS 1.2 以下や RC4・3DES などの旧式暗号は無効化する。

保存時は、データベースのカラム暗号化（Postgres pgcrypto、MySQL InnoDB TDE、SQL Server Always Encrypted）、ファイルストレージの暗号化（AWS S3 SSE-KMS、Google Cloud Storage CMEK、Azure Storage CMK）、そしてバックアップの暗号化（KMS 連携のスナップショット）の 3 レイヤーすべてに AES-256 を適用する。

見落としやすいのがログ・一時ファイル・開発環境のダンプだ。本番 DB を開発環境にコピーする際、暗号化が外れた状態で保管されていないか、定期的にレビューする。PDPA の監査で問われるのは「設計上の暗号化」ではなく「実際の運用で暗号化が維持されているか」である。

AES-256 の実効的な安全性は、アルゴリズムではなく鍵管理でほぼ決まる。鍵をコードリポジトリや設定ファイルに平文で置いた時点で、どれだけ強い暗号も無意味になる。KMS・HSM・テナント分離を組み合わせるのが、現代の実務におけるベースラインだ。

鍵管理の設計では 3 つの判断軸が重要になる。どのサービス（KMS / HSM）を使うか、どうローテーションするか、マルチテナントでどう分離するか、である。

クラウド環境では、AWS KMS・Google Cloud KMS・Azure Key Vault といった鍵管理サービス（KMS）を第一選択とするのが標準だ。KMS は鍵の生成・保管・利用を API で制御し、アプリケーションコードから平文鍵を一切扱わずに暗号化・復号を実行できる。いわゆる「エンベロープ暗号化」（KEK で DEK を暗号化する 2 段階構造）を KMS が内部で実装しているため、パフォーマンスとセキュリティを両立しやすい。

HSMは、鍵を専用ハードウェア境界内で保護する仕組みである。採用時は、FIPS 140-2またはFIPS 140-3のどちらに準拠しているかを製品ごとに確認する必要がある。金融機関・医療機関・政府案件では HSM が規制要件になるケースがあるが、タイ PDPA 単独では HSM の利用は必須要件ではない。

実務判断としては、一般的な AI プロダクトは KMS で十分、センシティブ個人データ（健康・信条・生体など）を扱う業務や、金融・医療など業界規制が重なる場合は HSM を検討する、という切り分けになる。HSM は AWS CloudHSM や Azure Dedicated HSM で調達でき、運用コストは KMS より 1 桁〜2 桁高いため、ビジネス要件と照らして判断する。

鍵ローテーションは、万が一の鍵漏洩時の被害を限定するために不可欠な運用だ。AWS KMSやGoogle Cloud KMSには鍵ローテーション機能があり、運用設計に応じて有効化できる。ローテーション周期はサービスや鍵種別で異なるため、利用するクラウドの最新仕様に従って設定する。漏洩が疑われる事象が発生した場合は、手動で即時ローテーションする手順も準備しておく。

鍵の分離は、用途別・環境別に別の鍵を使う設計原則だ。たとえば「DB カラム暗号化用鍵」「ログ暗号化用鍵」「API トークン暗号化用鍵」を別々に発行し、本番・ステージング・開発環境でも別の鍵を使う。こうすることで、1 つの鍵が漏洩しても影響範囲が限定される。

もう一つの実務上の工夫が鍵の階層化だ。マスターキー（KEK）を KMS 内に保管し、データ暗号化鍵（DEK）をアプリケーションが一時的に取得して使う。KMS の Encrypt/Decrypt API で KEK を介して DEK を扱う構造にすれば、DEK がメモリ上に長時間残らず、万一のコアダンプやメモリダンプでも漏洩しにくい。

マルチテナント SaaS で PDPA 対応を真剣に設計する場合、テナント単位で独立した鍵を持たせる「テナント別鍵管理」が強く推奨される。「一つの鍵が漏れたら全テナントが露出する」最悪シナリオを避けられる。

AWS KMSでは、テナントごとに個別のカスタマーマネージドキーを使う設計が有力である。コストと運用負荷を踏まえ、単一鍵、環境別鍵、テナント別鍵のどれを採るかを決めるべきである。

各テナントの DB 行は、そのテナントの CMK でエンベロープ暗号化された DEK で暗号化される。テナント A のデータを復号しようとするコードが、誤ってテナント B のデータにアクセスしても、正しい CMK を呼び出せないため復号できない仕組みになる。

PostgreSQLベースのマルチテナント基盤では、RLSと暗号化を組み合わせる設計は有力である。Supabaseを使う場合は、現行の権限モデルと暗号化オプションを確認したうえで設計する必要がある。実装コストは通常の RLS だけの場合より増えるが、PDPA の「技術的保護措置の適切性」を説明する上で強力な根拠になる。

AES-256 を導入したプロジェクトで PDPA 監査時に指摘される失敗は、アルゴリズム選定よりも「運用の穴」に集中する。特に平文バックアップ・サードパーティ SaaS 経由の流出・監査ログの不備が 3 大パターンだ。

これらは技術選定段階では見えにくく、運用開始後に気づくことが多い。以下の 2 つの H3 で、よくある失敗と監査対応の論点をまとめる。

本番 DB を AES-256 で暗号化していても、バックアップ経路が平文のままというケースは驚くほど多い。pg_dump で吐き出した SQL ファイル、週次でローカルに保管する CSV エクスポート、QA 検証用に開発環境にコピーしたスナップショット — こうした「派生データ」が暗号化されていなければ、本番の暗号化は意味を半分失う。KMS 連携のスナップショット機能を使い、ダンプファイルも必ず AES-256 で暗号化する。

サードパーティ SaaS 経由の漏洩も典型的な盲点だ。エラー監視（Sentry）、APM（Datadog、New Relic）、プロダクト分析（Mixpanel、Amplitude）などに、プロンプトや応答が平文で流れているケースが多い。これらのサービスは自社で暗号化しているが、「誰が鍵を握っているか」が重要になる。SSE（サーバーサイド暗号化）だけでなく、CSE（クライアントサイド暗号化）を検討し、PII はアプリケーション側でマスキング・ハッシュ化してから送信するパターンが安全だ。

「外部 SaaS に送る前に PII を除去する」処理を共通ライブラリとして実装し、全てのテレメトリ送信でそれを経由させる仕組みを作ると、開発者が意識しなくても漏洩を防げる。

PDPA 監査で問われるのは「今暗号化されているか」だけではなく、「継続的に暗号化運用が維持されているか」である。そのための土台が監査ログと定期レビューだ。

KMS の使用ログは AWS CloudTrail や Google Cloud Audit Logs に記録される。鍵の使用頻度、異常な時間帯のアクセス、通常と異なる IAM ロールからの呼び出しなどをアラート化しておく。AI プロダクトでは、開発チームが一時的に「KMS 経由ではなく環境変数で鍵を渡した」といったアンチパターンを踏みやすく、ログからその痕跡を定期的にレビューすると未然に防ぎやすい。

年次で実施すべきレビュー項目としては、暗号化対象データの棚卸し、鍵ローテーション履歴、バックアップ経路の暗号化状態、サードパーティ SaaS の暗号化ポリシー更新、PDPC からのガイドライン更新への追随の 5 点を最低ラインに設定する。また、PDPA のデータ主体権利（開示請求・削除請求）に対応した際の操作ログも、暗号化対象と同じレベルで保管する。監査は「証跡があれば乗り切れる」ケースが大半で、証跡そのものが PDPA 準拠の可視化になる。

AES-256 と PDPA 実装に関して開発現場で頻出する質問を整理する。いずれも「知らないと手戻りが大きい」論点だ。

Q1: AES-256 を導入すれば PDPA の技術的保護措置は完全に満たせるか？ 完全ではない。AES-256 はあくまで暗号化のベースラインであり、アクセス制御（RBAC・IAM）、監査ログ、データ分類、削除ポリシー、従業員教育といった他の層との組み合わせで初めて「適切な措置」になる。PDPA は暗号化だけを要求しているわけではなく、データ保護の仕組み全体を包括的に問うている。

Q2: AES-128 では PDPA 要件に不足するか？ AES-128 も FIPS 197 承認アルゴリズムで、多くの規制で受容されている。AES-256 との差は「将来の暗号解析耐性」の観点で AES-256 が優位だが、PDPA 対応の現時点ではどちらでも「適切な措置」と判断される可能性が高い。既存システムで AES-128 を使っており、リプレースコストが高い場合は継続利用も合理的だ。新規実装では AES-256 を選ぶのが無難である。

Q3: 既存 DB で TDE（透過的データ暗号化）が有効なら追加実装は不要か？ TDE は「ディスク窃取時の保護」には有効だが、SQL アクセス権を持つユーザーに対しては透過的に復号されるため、内部不正や SQL インジェクション経由の漏洩は防げない。センシティブカラムには TDE に加えてカラム単位の暗号化（pgcrypto、アプリ層暗号化）を重ねるのが、PDPA 監査で説明しやすい実装だ。

Q4: 量子耐性暗号は今すぐ意識すべきか？ 量子コンピュータによる AES-256 の実用的な攻撃はまだ成立していない。NIST は量子耐性暗号の標準（ML-KEM、ML-DSA）を発表したが、これは主に公開鍵暗号（RSA、ECDH）の置き換えが焦点で、対称暗号の AES は鍵長を 256 ビットに保つことで当面は安全とされている。長期保管データ（10 年以上）を扱う場合のみ、将来的な再暗号化計画を視野に入れる。

タイ PDPA の「適切な技術的保護措置」を満たすための核として、AES-256 は実務上最も説明しやすい選択肢だ。ただし「AES-256 を使っている」ことだけで監査を乗り切れるわけではない。暗号化対象の設計（プロンプト・応答・ベクトル・学習データの 4 層）、モード選定（GCM を第一選択）、鍵管理（KMS・テナント分離・ローテーション）、バックアップと SaaS 経由の漏洩対策、監査ログと継続レビュー — これらを一体で設計して初めて、PDPA 準拠の技術基盤になる。

本記事は技術実装レイヤーに特化したが、PDPA 対応は組織面との両輪で進める必要がある。同意取得・DPO 設置・越境移転契約・データ主体からの要求対応といった組織・契約面については、当社の「タイの PDPA 対応と AI 活用を両立させるコンプライアンスチェックリスト」で整理している。また AI システム全体のガバナンス設計は「AI ガバナンスとは？EU AI Act 対応から社内ルール整備まで実務ガイド」で、セキュリティリスク全般は「AI サイバーセキュリティの最新動向」で扱っているため、あわせて参照してほしい。

次のアクションは、自社 AI プロダクトで扱うデータを 4 層（プロンプト・応答・ベクトル・学習データ）で棚卸しし、各層の現在の暗号化状態をマッピングすることだ。ギャップが可視化されれば、実装の優先順位は自然と決まる。