WEB担当者のためのタイのPDPA（個人情報保護法）対応ガイド

PDPAとは？

PDPA（Personal Data Protection Act）は、タイで制定された個人データ保護法です。2019年に公布され、2022年から全面的に施行されました。企業や組織が個人データをどのように取得し、利用し、保管し、第三者に提供するのか、その扱いを透明かつ適正に管理することを目的としています。いわば、個人のプライバシーを守るために企業に説明責任を求める法律です。

この法律の設計には、EUのGDPR（General Data Protection Regulation：一般データ保護規則）が強く影響しています。PDPAはGDPRを参考に作られており、考え方や仕組みも非常に似ています。たとえば「本人の明確な同意を前提とすること」「データ主体の権利（開示・訂正・削除請求など）を保障すること」「国外にデータを移転する場合の安全性を確保すること」などの点は共通しています。違いがあるとすれば、GDPRが欧州全域で適用される包括的制度であるのに対し、PDPAはタイ国内の実務環境や法体系に合わせて柔軟に運用されている点です。

また、PDPAはタイ国内の企業だけでなく、タイ居住者の個人データを扱う海外企業にも適用されます。たとえば、日本企業がタイの顧客や応募者からWEBフォームを通じて個人情報を受け取る場合も対象に含まれる可能性があります。つまり「タイ国内に拠点があるかどうか」ではなく、「タイの個人データを扱っているかどうか」が判断の基準となるのです。

日本の個人情報保護法と比べると、PDPAはより「明示的な同意」を重視しています。日本では利用目的を公表していれば黙示的な同意で処理できるケースが多いのに対し、PDPAでは処理の法的根拠として同意を含む複数の選択肢が定められています。状況に応じて契約、法的義務、正当な利益等を適切に選びます。センシティブ情報は原則として明示的同意が必要です。

こうした点から、PDPAは単なる国内法ではなく、GDPRと同様に「グローバル基準での個人データ保護」を志向する法律だといえます。国や規模を問わず、企業がどのように個人情報を扱うかが信頼を決める時代になったということです。

特にWEBサイトは、顧客や応募者など外部から個人データを受け取る最前線です。問い合わせフォーム、Cookieによる行動データの収集、アクセス解析など、日常的な運用の中にPDPAが関係するポイントが数多くあります。だからこそWEB担当者にとっても、この法律の趣旨を正しく理解し、現場でのデータの扱い方を見直すことが、企業全体の信頼を支える第一歩となるのです。

WEBサイトでPDPAが関係する主な場面

PDPAは企業のあらゆるデータの取り扱いに関わりますが、WEBサイトはその中でも特にリスクと影響の大きい領域です。企業の顧客や応募者など、外部の個人と最初に接点を持つのがWEBサイトであるためです。

「自社では特に個人情報を扱っていない」と思っていても、サイトの仕組みの中で自然と個人データが集まっているケースは少なくありません。ここでは、WEBサイト運用の中でPDPAが関係する代表的な場面を整理します。

1. 問い合わせフォーム・資料請求フォーム

最も典型的なのが、問い合わせフォームや資料請求フォームです。
氏名、メールアドレス、電話番号といった情報はもちろん、メッセージ欄の自由記入部分にも個人を特定できる情報が含まれる可能性があります。こうしたデータを取得する際は、「なぜこの情報を収集するのか」「どのように利用するのか」を明示し、ユーザーの同意を得ることが必要です。また、フォーム送信時にはSSL通信による暗号化だけでなく、データの保存先や削除ルールも含めて管理体制を整えることが求められます。

2. 採用エントリーフォーム

採用ページは、氏名や連絡先だけでなく、職務経歴書や顔写真、資格情報などセンシティブな個人データを扱うため、より厳格な対応が必要です。PDPAではこのような「特別カテゴリーの個人データ」を扱う場合、明示的で書面または電子的に確認できる同意が必要とされています。採用フォームにおいては、応募者が同意内容を確認し、チェックを入れて送信する設計を行うことが望ましいでしょう。

3. Cookie・アクセス解析・広告タグ

多くの企業サイトで導入されているアクセス解析や広告計測タグもPDPAの対象になり得ます。
CookieやトラッキングIDには個人を直接特定できない情報も含まれますが、行動履歴やデバイス情報と組み合わせることで「個人を識別し得る情報」と見なされるため、Cookie等で個人データを処理する場合、同意等の法的根拠と同意の記録・変更手段が必要です。実務では同意管理バナーを用いた運用が一般的です。
「すべて許可」「拒否」「詳細設定」といった選択肢をユーザーに提供し、同意を得た後にのみGoogle Analyticsや広告タグが発火するよう設定することが求められます。
さらに、Googleが推進する「Consent Mode v2」への対応も今後の実務では避けて通れないポイントです。Consent Mode v2はGoogleタグの同意連動を支援する技術です。取得した同意に沿ったタグ制御や推計精度の確保に実務上有用です。

4. 会員登録・ログイン機能、ECサイトでの購入情報

ログイン機能や会員登録を設けているサイト、またはECサイトなどでは、個人データの蓄積・更新・削除のプロセスが日常的に発生します。これらのデータには購入履歴や配送先住所、決済情報などが含まれるため、アクセス権限の管理やデータ保管期間の明確化が不可欠です。
また、外部システム（決済代行やCRMなど）と連携している場合は、データがどこで処理・保存されるかを明示し、委託先との契約内容（Data Processing Agreement：DPA）を確認しておくことも重要です。

5. ニュースレター・メール配信登録

メール配信登録フォームやキャンペーン応募フォームなども、個人データを収集する仕組みのひとつです。
登録時に収集する情報（氏名、メールアドレス、興味関心カテゴリなど）については、目的外利用を行わないこと、および配信停止の手段を明示することが必要です。
特にCRMやMAツールと連携している場合は、同意の取得からデータの利用まで一貫した管理体制を構築しておく必要があります。

このように、WEBサイト上にはPDPAが関係する場面が数多く存在します。
つまり、WEB担当者が行う日常的な作業—フォームの設置、アクセス解析の設定、広告タグの管理、メール配信の運用—のすべてが、データ保護の観点から再点検の対象になるということです。

次章では、これらの場面ごとに求められる「具体的な対応と実装のポイント」を見ていきます。

フォーム編：明示的な同意取得と文面整備

WEBサイトで個人データを最も直接的に扱うのが、問い合わせや応募などの各種フォームです。

氏名やメールアドレスといった連絡先だけでなく、自由記入欄に含まれる情報、添付ファイル、アクセスログなども個人データと見なされる可能性があります。そのため、フォーム運用では「どのような情報を・何のために集めているのか」を明確に示し、ユーザーが納得の上で送信できる仕組みを整えることがPDPA対応の基本になります。

同意取得の設計 ― 「チェックをつけて送信」が重要な理由

PDPAでは、個人データを取得・利用する前に本人の明示的な同意（explicit consent）を得ることが原則とされています。
そのため、フォーム送信前に「プライバシーポリシーを読み、同意します」といった文言を表示し、チェックボックスを設けるのが基本的な設計です。
チェックボックスは初期状態でオンにせず、ユーザー自身が意識的にチェックを入れる動作が必要です。
また、送信ボタンの近くに同意文を配置することで、同意が送信行為と明確に紐づくようにします。

このように「目的の明示」と「任意のチェック操作」をセットにすることが、法的にもユーザー体験的にも望ましい設計です。

採用フォームなど、センシティブ情報を扱う場合

職務経歴書や顔写真、健康情報など、個人の属性を示す情報は「特別カテゴリーの個人データ」としてより厳格に扱う必要があります。
PDPAではこのような情報を処理する際、通常よりも強い明示的同意（文書または電子的記録で確認可能な形）が求められます。
さらに、採用管理システムなど外部サービスを利用している場合は、委託先との間でData Processing Agreement（データ処理契約）を締結し、情報の保管・削除責任を明確にすることも大切です。

利用目的と範囲の明確化

PDPAでは、「同意の有効性」はその説明内容に依存します。
つまり、利用目的をあいまいに書いていたり、実際の運用と異なる目的でデータを使ってしまうと、たとえ同意を得ていても違反になる可能性があります。
目的はできるだけ具体的に記載し、不要な情報はそもそも取得しない設計が理想です。

たとえば、問い合わせ対応のみが目的であれば「当社サービスに関するお問い合わせへの対応のため」と明記し、営業活動や第三者提供など他の目的がある場合は、それぞれを個別に説明します。

データ管理・削除ルールを明示する

フォームで収集したデータは、保管期間や削除ルールを明確に定めておくことが望まれます。
たとえば、「取得から○か月後に自動削除」「採用活動終了後に全データを破棄」といった方針をポリシーや内部ルールで定め、ユーザーに開示できる状態にしておきます。
データの保存先（CMS、サーバー、CRMなど）が複数に分かれている場合は、担当者レベルで削除責任を明確にしておくことも重要です。

フォーム設計におけるPDPA対応は、単なる法的義務にとどまりません。
「どんな情報を、何のために預かるのか」を明確に伝えることは、ユーザーの安心感を生み、企業の信頼にもつながります。
同意取得の仕組みを整えることは、結果的に問い合わせや応募の品質向上にも寄与する実務的な投資といえるでしょう。

Cookie／アクセス解析編：同意バナーとタグ管理

Cookieそのものは識別子（ID）にすぎませんが、アクセス履歴やデバイス情報と組み合わさることで「特定の個人の行動履歴」として識別可能になる場合があります。
PDPAではこのような情報も「個人データ」とみなされる可能性があるため、ユーザーの許可なく追跡・分析を行うことは原則として認められません。
そのため、Cookieやタグを利用する際には、ユーザーが選択できる同意の仕組みを提供することが必要です。

Cookieバナー導入の基本設計

PDPAでは、Cookieなどを通じて個人データを収集する場合、その利用目的や範囲をユーザーに通知し、必要に応じて同意を得ることが求められます。この「通知・同意取得」の方法として、Cookieバナーを用いるのが最も一般的な対応手段とされています。
アクセス解析や広告タグを通じて個人データを収集しているサイトでは、PDPAの趣旨に照らしてバナーや同意管理の仕組みを導入することが実質的に推奨される対応です。

最低限、以下の要素を備えるのが望ましい構成です。

・明示的な選択肢：「すべて許可」「拒否」「詳細設定（カテゴリ別許可）」
・目的別の説明：解析、広告、機能改善など、それぞれの目的を簡潔に記載
・同意の変更機能：一度選択した後も、再設定・撤回できる仕組みを用意
・Cookieポリシーへのリンク：詳細な情報を別ページで提示

「ただバナーを出す」だけではなく、ユーザーが自ら判断できる状態をつくることが、PDPAの趣旨に沿った設計です。

タグ管理とConsent Modeの考え方

Google Analyticsや広告タグを利用している場合は、Google Tag Manager（GTM）などを使ってタグの発火条件を「同意取得後」に限定する設定が求められます。
たとえば、Cookieバナーで「解析を許可」したユーザーだけにGA4タグを発火させる、といった制御です。

また、Googleが提供する「Consent Mode v2」は、ユーザーの同意ステータスに応じてデータの送信挙動を自動的に切り替える仕組みです。PDPA対応と同時に、このConsent Modeを導入しておくことで、広告・分析データの正確性と法令順守の両立が可能になります。

同意の記録とログ管理

同意取得を行うだけでなく、「いつ・どの条件で・どの選択がなされたか」という証跡を残すことも重要です。
これは後から監査や問い合わせがあった場合に、企業が適切に対応していたことを証明するための根拠になります。
Cookie管理ツールによっては同意履歴を自動的に記録・更新できる機能もあるため、仕組みとして組み込むのが効率的です。

外部サービスとの連携に注意

チャットボット、ヒートマップ、SNSプラグインなど、外部ツールを導入している場合も注意が必要です。
これらが第三者にデータを送信している場合、PDPA上は「第三者提供」に該当する可能性があります。
導入前に、提供先のデータ保護体制や契約条件（データ処理契約：DPA）を確認しておくと安全です。

法令遵守はUXにもつながる

Cookieバナーは「邪魔なもの」と捉えられがちですが、正しく設計すればむしろ“安心して利用できるサイト”という印象を高めるUIになります。
透明性を確保しつつ、分かりやすい文言と操作感で構成することで、ユーザーの信頼を得ることができます。
法対応を単なる義務ではなく、ブランド体験の一部として考える視点が、これからのWEB運用には欠かせません。

プライバシーポリシー編：Web公開文書の更新

PDPA対応において、プライバシーポリシー（Privacy Policy）は企業が「どのように個人データを扱っているか」を示す最も重要な公開文書です。フォームやCookieなどで同意を取得したとしても、その内容を裏づける明確な方針がWEB上に示されていなければ、法的にもユーザーの信頼の面でも不十分です。
まずは現状のポリシーを確認し、PDPAの要件に沿ってアップデートすることが必要

PDPA対応で求められる記載項目

プライバシーポリシーには、少なくとも次の内容を含めることが望まれます。
これらはPDPA第23条（データ主体への通知義務）に基づき、ユーザーが自身の情報がどのように扱われているかを理解できるように記載する必要があります。

管理者情報
会社名、所在地、代表者、個人データ保護責任者（DPO）の連絡先など。

収集するデータの種類
氏名、メールアドレス、Cookie情報、アクセスログなど、どのような個人データを取得しているか。

収集・利用の目的
問い合わせ対応、サービス提供、採用選考、マーケティング分析など。

第三者提供・委託の有無
外部ベンダーやクラウドサービスへのデータ提供がある場合、その範囲と目的。

データの保管期間と削除方針
どのくらいの期間保管し、いつ・どのように削除または匿名化するのか。

個人の権利と請求手続き
開示・訂正・削除・処理停止などの請求が可能であること、およびその方法。

国外移転の有無
タイ国外にデータを送信する場合、その安全措置と法的根拠。

問い合わせ窓口
個人データに関する質問・苦情の受付先を明記。

これらを「網羅的に」「分かりやすく」記載することがPDPAの基本要件です。

日本のテンプレートをそのまま使わない

多くの日系企業サイトでは、日本の個人情報保護法に基づくテンプレートをそのまま流用しているケースがあります。
しかし、日本法では「利用目的の公表」で足りる場合がある一方、PDPAでは**収集時に本人へ明示すべき通知事項（第23条）**が細かく定められています。
たとえば、収集目的や保管期間、第三者提供の有無、問い合わせ窓口などを明確に記載する必要があります。
また、データ国外移転の扱いや、DPO（データ保護責任者）の連絡先の開示といったPDPA特有の要件も存在します（DPOの情報開示は任命が義務付けられる事業者に限られます）。
そのため、日本語版をベースにしつつも、PDPAの要件に沿って項目を再整理し、タイの実務に合わせた構成へアップデートすることが求められます。

開場所とリンクの設置

プライバシーポリシーは、ユーザーがいつでも確認できる場所に設置する必要があります。
一般的には、フッターに常時リンクを設けるのが標準です。
さらに、フォーム送信画面やCookieバナーからも同一ポリシーへリンクし、「いつでも確認できる状態」を維持します。
このように、ポリシーは“公開するだけの文書”ではなく、WEB全体の設計と連動して機能させることが重要です。

定期的な見直しと改訂履歴の明示

PDPAの運用ガイドラインは今も更新が続いており、ツールや解析手法の変化にも対応する必要があります。
新しいサービスや計測ツールを導入した際には、収集データや目的が変わる可能性があるため、ポリシーの改訂を忘れずに行いましょう。
また、更新日を明記し、改訂履歴を簡単に確認できるようにしておくと、透明性を示すうえでも有効です。

「開示」ではなく「信頼の設計」へ

プライバシーポリシーは、単に法的リスクを回避するための書面ではありません。
企業がどのように個人データと向き合っているかを示す「信頼の設計図」です。
法的要件を満たすことはもちろん、わかりやすい言葉と誠実な姿勢で伝えることで、ユーザーから「安心して利用できるサイト」という印象を得ることができます。
PDPA対応をきっかけに、情報開示を「企業姿勢を表すコミュニケーション」として再構築することが、今後のWEB運用では欠かせない視点です。

よくある誤解と落とし穴

PDPA対応を進めるうえで、法令の解釈や実務への反映をめぐって誤解されやすいポイントがいくつかあります。
ここでは特に日系企業のWebサイト運用で見落とされがちな注意点を整理します。

誤解①：「SSL化されていれば十分」

フォーム送信をHTTPS（SSL通信）にしているから安全、という考え方は部分的にしか正しくありません。
SSL化は通信経路の暗号化を行う技術的な保護にすぎず、PDPAが求めているのは「データの取得・利用・保管・削除までを含めた一連の管理プロセスの適正化」です。
つまり、フォームの同意文や保存期間、データ削除手順といった運用面のルール整備を行わない限り、法的には不十分です。

誤解②：「Google Analyticsは匿名だから問題ない」

Google Analyticsや広告タグが収集するデータは、個人名などを直接扱わないため安全と思われがちです。
しかし、IPアドレスやブラウザ識別子、行動履歴といった情報は、他データと組み合わせることで個人を特定し得る情報とみなされます。
PDPAの下ではこれらも「個人データ」に該当する可能性があり、同意なしに収集・送信することはリスクがあります。
したがって、Cookie同意バナーとタグ制御の実装（Consent Mode対応など）が推奨されます。

誤解③：「日本で個人情報保護法に対応しているから問題ない」

日本の個人情報保護法とPDPAは考え方が似ていますが、運用基準や適用範囲には違いがあります。
特に、PDPAは明示的な同意を原則とする点、域外適用がある点など、より厳格です。
「日本で使っているフォームやポリシーをそのまま流用する」だけでは対応不足になりやすく、タイの法基準に合わせ設計を見直す必要があります。

誤解④：「社内利用だけだから対象外」

「社内の従業員データだからPDPAの対象ではない」という誤解も多く見られます。
PDPAでは、企業が従業員や関係者などの個人情報を扱う場合も原則として対象に含まれます。
たとえば、採用応募フォームで収集した履歴書データを社内で共有・保管する場合も、取得時の同意や保管期間の設定が求められます。
社外か社内かではなく、“個人データを扱うかどうか”が判断基準です。

誤解⑤：「海外のサーバーに置いているから関係ない」

データの保存先がタイ国外であっても、対象となるユーザーがタイ居住者であればPDPAの適用を受けます。
これを「域外適用（extraterritoriality）」と呼び、GDPRと同様の考え方です。
そのため、サーバーやクラウドの所在地ではなく、誰のデータを扱っているかで判断する必要があります。

誤解⑥：「Cookieバナーを設置すれば自動的に対応完了」

Cookieバナーを設置するだけではPDPA対応とは言えません。
ユーザーが「許可」「拒否」「設定変更」を選べる設計であること、同意後にのみタグが作動すること、さらに同意履歴を管理・証跡として保存することが求められます。
単に表示しているだけでは「同意の自由意思」が確認できず、形式的な対応に留まってしまう点に注意が必要です。

誤解⑦：「同意を取れば何をしてもよい」

同意があれば万能、というのも誤りです。
PDPAでは「収集目的の範囲内でのみデータを利用できる」ことが前提であり、同意を得た後でも別目的で利用する場合は再同意が必要です。
また、データ主体（本人）には削除請求・訂正請求の権利があるため、同意の履歴管理と再同意のプロセス設計が欠かせません。

PDPA対応は、法律知識よりも「自社のサイトや業務の中で何をしているか」を正しく理解することが出発点です。
フォーム・Cookie・データ管理・ポリシーを一貫した設計として見直し、“運用で守る”体制をつくることが、最も現実的で確実な対策といえます。

まとめ

PDPAは、単なる法的義務ではなく「企業が個人のデータとどう向き合うか」を問う法律です。
その考え方の根底にあるのは、ユーザー一人ひとりが自分の情報をコントロールできる社会を実現するという理念です。
そしてWEBサイトは、その理念を最も具体的に体現できる場所でもあります。

問い合わせフォームでの明確な同意取得、Cookieバナーによる選択の尊重、わかりやすいプライバシーポリシーの提示。
こうした小さな実務対応の積み重ねが、ユーザーから「この企業は信頼できる」と感じてもらうための基盤になります。
PDPA対応を「信頼を築く設計」として捉えることが、これからのWEB運用の新しいスタンダードといえます。

まずは、自社サイトを点検し、

・どんなデータを取得しているのか
・どんな同意を得ているのか
・その情報をどう保管・削除しているのか

を一つずつ可視化することから始めてみてはいかがでしょうか。

法令対応の先にあるのは、「安心して利用されるサイト」「信頼される企業」という成果です。
PDPAはそのゴールへの出発点であり、WEB担当者が企業の信頼価値を高めるための大切なチャンスでもあります。