IAB Transparency & Consent Framework（TCF）とは？
TCF は、主に欧州のデジタル広告エコシステムで用いられています。TCF は、標準化されたポリシー、技術仕様、同意シグナル、ベンダー情報、API を提供し、参加する組織が個人データの取り扱いやデバイス上の保存・アクセスに関するユーザーの選択を伝えられるようにします。
現行のフレームワークは TCF v2.3 です。2025 年に導入され、特定のベンダーがユーザーに開示されたかどうかについての曖昧さを解消するため、Disclosed Vendors セグメントを TC String の必須の一部としました。TCF v2.3 への移行期限は 2026 年 2 月 28 日でした。
IAB TCF とは何を意味しますか？
IAB TCF は、IAB Europe Transparency & Consent Framework の略称です。
TCF は、次のような関係者を含むデジタル広告エコシステムに、共通のフレームワークを提供します。
- パブリッシャー
- メディア企業
- 広告主
- 広告代理店
- 同意管理プラットフォーム
- アドテクのベンダー
- デマンドサイドプラットフォーム（DSP）
- サプライサイドプラットフォーム（SSP）
- アドサーバー
- 効果測定の提供事業者
- その他のテクノロジーパートナー
一般的な広告エコシステムには、多数のベンダーが関与し得ます。TCF は、それらのベンダー、ベンダーが宣言した処理目的、適用される適法な根拠、ユーザーの選択に関する情報を伝えるための標準化された方法を提供します。
IAB Europe は TCF を、パブリッシャーとテクノロジーパートナーが連携しつつ、ユーザーに標準化されたプライバシー選択の体験を提供できるようにすることを意図した、業界横断の任意参加の標準であると説明しています。
IAB TCF は法律ですか？
いいえ。
IAB Transparency & Consent Framework は業界のフレームワークであり、法令ではありません。
TCF は、次のものに取って代わるものではありません。
- GDPR
- ePrivacy 指令
- UK GDPR
- 各国のプライバシー法
- 規制当局のガイダンス
- 裁判所の判断
- その他の適用されるデータ保護上の要件
IAB Europe の現行ポリシーは、TCF への参加が、適用される法律を遵守する各参加者の責任に取って代わるものではないことを明確に述べています。
したがって、TCF に対応した CMP を利用しても、ウェブサイトが自動的に GDPR に適合するわけではありません。
TCF はむしろ、一定のプライバシーおよび広告のワークフローを支える、標準化された仕組みを提供するものです。
IAB TCF の目的は何ですか？
TCF の主な目的は、デジタル広告のサプライチェーンの中でプライバシー上の選択に関する共通言語を作ることです。
数十社もの広告・効果測定のベンダーと取引しているパブリッシャーを考えてみてください。
標準化されたフレームワークがなければ、そのパブリッシャーは、ベンダーごとに異なる技術的な仕組みを用いてプライバシー上の選択を伝えなければならないかもしれません。
TCF は、このやり取りの重要な部分を標準化します。
簡略化したワークフローは次のとおりです。
- ユーザー
- CMP
- TCF のシグナル
- 広告ベンダー
- 取り扱い
これにより、参加する組織は次のことを把握しやすくなります。
- どのベンダーが関与しているか
- ベンダーがどのような目的を宣言しているか
- フレームワークの中でどの適法な根拠が用いられているか
- ユーザーがどのような選択を行ったか
- どのベンダーが開示されたか
- どのパブリッシャー制限が適用されるか
- ユーザーのプライバシーの状態をどのように伝えるべきか
TCF v2.3 とは何ですか？
TCF v2.3 は、IAB Europe Transparency & Consent Framework の現行バージョンです。
IAB Europe は 2025 年に TCF v2.3 を公開しました。その主要な変更点は、Disclosed Vendors セクションを TC String の必須の一部としたことです。
この変更は、とりわけ Special Purposes に関する正当な利益にもとづく取り扱いの場面において、特定のベンダーが実際にユーザーへ開示されたかどうかについての曖昧さを解消するために導入されました。
移行期間は 2026 年 2 月 28 日に終了しました。つまり現行の TCF 実装は、古い v2.2 の実装に依拠するのではなく、v2.3 に対応すべきです。
TCF のバージョン履歴
主要な TCF のバージョンは次のとおりです。
- TCF v1.12018
- TCF v2.02019
- TCF v2.12020
- TCF v2.22023
- TCF v2.32025
現在の用語集の内容や実装のガイダンスでは、TCF v2.3 を参照すべきです。
TCF v2.3 では何が変わりましたか？
v2.3 で最も重要な変更は、Disclosed Vendors セグメントが必須になったことです。
このセグメントは、あるベンダーが CMP のインターフェースを通じてユーザーに開示されたかどうかを伝えます。
技術的な構造には次のものが含まれます。
- Core セグメント
- Disclosed Vendors セグメント
- 任意の Publisher TC セグメント
IAB Tech Lab は、Disclosed Vendors セグメントが、ベンダーがユーザーに開示されたかどうかを示すバイナリのシグナルを提供するものであると説明しています。
これは、ベンダーが一定の取り扱い活動について正当な利益に依拠しており、自社の関与についてユーザーが適切に知らされていたかどうかを把握する必要がある場合に、とりわけ重要です。
これが重要な理由
ベンダーの開示は、重要な透明性の要件です。
ベンダーが、自社が実際にユーザーへ提示されたかどうかを推測しなければならない状況は望ましくありません。
TCF v2.3 は、その曖昧さを減らすための標準化されたシグナルを提供します。
TC String とは何ですか？
Transparency and Consent String（一般に TC String と呼ばれます）とは、TCF のエコシステムにおける関連情報とユーザーの選択を機械可読な形で表現したものです。
TC String は、次の事項に関する情報を伝えることができます。
- ユーザーの同意
- ユーザーの異議
- ベンダー
- 目的
- 適法な根拠
- パブリッシャー制限
- 開示されたベンダー
- フレームワークのメタデータ
TC String により、参加するベンダーは、CMP を通じて確立されたプライバシーの状態に関する標準化された情報を受け取ることができます。
したがって TC String は、TCF の技術的な構成要素の中でも最も重要なものの一つです。
TC String は同意と同じものですか？
いいえ。
TC String は、プライバシーに関する情報と選択を技術的に表現したものです。
それ自体が、有効な同意に代わる法的なものではありません。
同意が法的に有効かどうかは、次のような要素によって決まります。
- どのような情報が提供されたか
- その選択が自由になされたものか
- 目的が十分に特定されていたか
- 必要な場合に、ユーザーが能動的に同意を示したか
- 撤回が可能かどうか
- 適用される法的要件が満たされているか
- 実際の取り扱いが、開示された取り扱いと一致しているか
TCF は技術的な標準化を提供するものであり、それ自体が取り扱いの適法な根拠を作り出すものではありません。
Disclosed Vendors セグメントとは何ですか？
Disclosed Vendors セグメントは、TCF v2.3 における重要な追加要素です。
このセグメントは、該当する CMP のインターフェースを通じてベンダーがユーザーに開示されたかどうかを伝えます。
その目的は、ベンダーが自社が実際にユーザーへ提示されたかどうかを判断する必要がある場面で、曖昧さを取り除くことにあります。
これは、一定の正当な利益にもとづく場面でデータを取り扱うベンダーにとって、とりわけ重要です。
TCF v2.3 は、TC String に Disclosed Vendors セグメントを含めることを求めています。
Global Vendor List（GVL）とは何ですか？
Global Vendor List（GVL）とは、TCF のエコシステムに参加しているベンダーの標準化された一覧です。
GVL は、CMP その他の参加者が、参加ベンダーとその宣言された活動を把握するために用いる情報を提供します。
ベンダー情報には次のものが含まれ得ます。
- ベンダー ID
- ベンダー名
- 宣言された目的
- 特別な目的
- 機能
- 特別な機能
- 適法な根拠
- データのカテゴリー
- その他のフレームワーク上の情報
GVL が重要なのは、TC String と CMP のインターフェースが標準化されたベンダー情報を必要とするためです。
IAB Europe の現行の TCF 関連リソースは、引き続き GVL をフレームワークの中核的な構成要素として挙げています。
GVL により、CMP その他の参加者は、参加ベンダーに関する標準化された情報にもとづいて作業できます。
GVL は、次のことを支えます。
- ベンダーの識別
- 目的の宣言
- 特別な目的の宣言
- 機能に関する情報
- 適法な根拠に関する情報
- ベンダーの開示
GVL は、TCF の標準化されたベンダー間のやり取りを可能にする中核的なリソースの一つです。
TCF CMP とは何ですか？
TCF CMP とは、IAB Europe の TCF エコシステムに参加している同意管理プラットフォームのことです。
TCF CMP は、次のことに必要なユーザー向けおよび技術的な基盤を提供できます。
- プライバシーに関する情報を提示すること。
- 該当するベンダーと目的を開示すること。
- ユーザーの選択を取得すること。
- TC String を生成すること。
- 参加ベンダーがそのシグナルを利用できるようにすること。
- 該当する CMP API に対応すること。
- 設定の変更を管理すること。
- 関連する TCF のポリシーおよび仕様に対応すること。
通常の Cookie バナーが、自動的に TCF CMP になるわけではありません。
TCF への参加には、登録、ポリシー、技術、コンプライアンスに関する具体的な要件が伴います。
TCF と CMP の違い
TCF と CMP は関連していますが、同じものではありません。
| TCF | CMP |
|---|---|
| 業界のフレームワーク | ソフトウェア・プラットフォーム |
| ポリシーと標準を定める | プライバシー選択のワークフローを実装する |
| 標準化された目的とベンダーの概念を定める | ユーザーに情報を提示する |
| 技術的なシグナル伝達の仕組みを定める | シグナルを生成し、伝える |
| 参加の要件を定める | 実装を提供する |
| IAB Europe が技術面の協働のもとで運営する | 個々の CMP 企業が提供する |
簡単にいえば、次のとおりです。
- TCF はフレームワークです。
- CMP は、そのフレームワークを実装できるソフトウェアです。
TCF CMP は何をしますか？
TCF CMP は通常、同意プロセスのいくつかの段階を担います。
透明性
CMP が、関連する目的、ベンダー、取り扱い活動を説明します。
選択
ユーザーが、該当する同意または設定の選択を行えます。
シグナルの生成
CMP が、適切な TC String を生成します。
シグナルの提供
CMP が、参加ベンダーに関連するシグナルを利用できるようにします。
設定の管理
ユーザーは、後から該当する選択を変更または撤回できます。
技術的な実行
ウェブサイト全体の実装は、実際の取り扱いがその結果としてのプライバシーの状態と一致するようにすべきです。
この最後の点がきわめて重要です。
TC String を生成することは、許可されていない取り扱いを防止することと同じではありません。
TCF の Purposes とは何ですか？
TCF は、参加ベンダーが個人データを取り扱い、または関連する活動を行う理由を説明するために、標準化された Purposes（目的）を用います。
現行の TCF ポリシーには、次のような標準化された目的が含まれます。
- デバイス上の情報を保存し、またはアクセスする
- 限定されたデータを用いて広告を選択する
- パーソナライズド広告のためにプロファイルを作成する
- プロファイルを用いてパーソナライズド広告を選択する
- コンテンツをパーソナライズするためにプロファイルを作成する
- プロファイルを用いてパーソナライズドコンテンツを選択する
- 広告の効果を測定する
- コンテンツの効果を測定する
現行の TCF ポリシー文書は、これらの目的と関連するフレームワーク上の概念を定義しています。
この目的の構造が重要なのは、CMP のインターフェースとベンダーの宣言に標準化された語彙を提供するためです。
Special Purposes とは何ですか？
Special Purposes とは、TCF の中で定義された、別個の標準化された処理目的です。
通常の Purposes とは異なる扱いを受け、フレームワークの中で固有の要件が定められています。
したがってウェブサイトは、TCF を次のように単純化すべきではありません。
「ユーザーが Cookie を受け入れるか拒否するかだ」
TCF は、目的、ベンダー、機能、特別な目的、適法な根拠が関わる、より広い広告・データ処理のエコシステムを対象としています。
TCF の Features と Special Features とは何ですか？
TCF は、Features と Special Features も定義しています。
これらは、ベンダーによる取り扱いに関連する具体的な機能や特性を表します。
Special Features は、TCF のポリシーのもとで追加的な扱いを受けます。
この区別が重要なのは、TCF CMP が、あらゆるベンダーの活動を一律に Cookie として扱うのではなく、現行のフレームワークの要件に従って関連情報を提示し、伝えなければならないためです。
TCF における同意と正当な利益
TCF は従来、同意と正当な利益を含む複数の適法な根拠の概念に対応してきました。
もっとも、このフレームワークは時間の経過とともに大きく変化してきました。
TCF v2.2 は、Purposes 3〜6 について、適法な根拠としての正当な利益を廃止しました。
その後 TCF v2.3 は、一定の正当な利益の場面でベンダーがユーザーに開示されたかどうかについての曖昧さを解消するため、必須の Disclosed Vendors セグメントを導入しました。
ベンダーが正当な利益を宣言しているからといって、そのベンダーが自動的に個人データを無制限に取り扱う許可を得たことにはなりません。
適用される法律と具体的な取り扱い活動が、引き続き重要です。
TCF は、ユーザーが同意を与えたことを意味しますか？
いいえ。
TCF は、透明性とプライバシー選択のシグナル伝達のためのフレームワークです。
それ自体が、有効な同意を作り出すものではありません。
適合した同意のワークフローは、依然として適用される法的要件を満たす必要があります。
たとえば、同意が適法な根拠である場合、組織はその同意が次の要件を満たしているかを検討すべきです。
- 自由に与えられていること
- 特定されていること
- 情報が提供されたうえでのものであること
- 明確であること
- 適切な情報にもとづいていること
- 撤回できること
実際のユーザーインターフェースと技術的な挙動も、主張している適法な根拠と一致していなければなりません。
TCF を導入すればウェブサイトは GDPR に適合しますか？
いいえ。
TCF は、プライバシーと広告に関するコンプライアンスのワークフローの一部を支えることができますが、GDPR 適合の証明書ではありません。
IAB Europe 自身のポリシーも、TCF への参加が、各参加者が自らの法的義務について責任を負うことに代わるものではないことを明確に述べています。
より広い GDPR コンプライアンスプログラムには、次のものも必要になる場合があります。
- プライバシー通知
- 有効な同意の仕組み
- 適法な根拠の分析
- Cookie とトラッカーの管理
- データ主体の権利
- データ最小化
- データ保持
- ベンダー管理
- データ処理契約
- セキュリティの管理策
- 国際移転の保護措置
- 処理活動の記録
- ガバナンスと説明責任
TCF と GDPR
TCF は、欧州のプライバシー環境に対応して作られたものであり、参加する組織がデジタル広告エコシステムにおける一定の GDPR および ePrivacy の要件に対処できるよう支援することを意図しています。
IAB Europe は TCF を、GDPR および ePrivacy 指令の一定の規定の遵守を促進することを意図した説明責任のためのツールであると説明しています。
もっとも、次の点には注意が必要です。
組織は引き続き、自らの法的義務を判断する責任を負います。
TCF と ePrivacy 指令
TCF は、とりわけユーザーのデバイス上に情報を保存し、またはそこにアクセスする技術との関係で、ePrivacy 指令にも関係します。
つまり、欧州における広告のコンプライアンスには、複数の法的なレイヤーが関わり得ます。
個人データの取り扱い
デバイス上の保存・アクセスと関連技術
標準化された業界のシグナル伝達と説明責任のフレームワーク
TCF は、いずれの法的枠組みにも取って代わるものではありません。
TCF は Cookie をブロックしますか？
いいえ。
TCF は主に、標準化された透明性とシグナル伝達のためのフレームワークです。
TCF は、あらゆる Cookie やトラッカーの読み込みを自動的に防ぐものではありません。
ウェブサイトには、次のような追加の実行の仕組みが必要になる場合があります。
- 事前スクリプトブロッキング
- タグ管理の管理策
- Cookie の管理策
- CMP との連携
- ベンダーのブロッキング
- サーバーサイドの管理策
- 同意状態の伝播
たとえば、CMP がユーザーはある目的に同意していないことを示す TC String を正しく生成していても、設定の不備があるタグが依然として発火していることがあります。
それは実装上の問題ということになります。
TCF と事前同意
事前同意と TCF は関連していますが、異なる概念です。
事前同意とは、該当する取り扱いやデバイスへのアクセスが行われる前に同意を取得することをいいます。
TCF は、プライバシー選択のプロセスの後、またはその一部として、標準化されたシグナル伝達を提供します。
簡略化したワークフローは次のようになります。
- ユーザーの訪問
- CMP の読み込み
- プライバシー情報の表示
- ユーザーの選択
- 該当する同意状態の確立
- 許可された技術の作動
- TC String の伝達
正確な順序は、そのウェブサイトの技術アーキテクチャと適用される法律によって異なります。
TCF とプログラマティック広告
TCF は、プログラマティック広告にとってとりわけ重要です。
パブリッシャーは、次のような多数の広告・効果測定のベンダーと取引することがあります。
- SSP
- DSP
- アドエクスチェンジ
- アドサーバー
- 効果測定の提供事業者
- オーディエンスプラットフォーム
- アドベリフィケーションの提供事業者
- データ提供事業者
TCF は、これらの参加者に対し、関連するプライバシー情報を伝えるための標準化された仕組みを提供します。
これは、TCF がパブリッシャーやメディア事業にとってとりわけ価値がある主な理由の一つです。
パブリッシャーにとっての TCF
プログラマティック広告を利用するパブリッシャーは、次の事項を管理する必要がある場合があります。
- ベンダーの開示
- 目的の開示
- ユーザーの同意
- ユーザーの異議
- パブリッシャー制限
- TC String の生成
- CMP の設定
- ベンダーとの連携
- 同意の撤回
- トラッカーの作動
- プライバシーコンプライアンス
IAB Europe は、パブリッシャー、CMP、ベンダーを TCF の中核的な参加者として明確に位置づけています。
ベンダーにとっての TCF
TCF ベンダーとは、このフレームワークに参加しているテクノロジー提供事業者のことです。
ベンダーには、次のようなものが含まれ得ます。
- 広告プラットフォーム
- 効果測定の提供事業者
- DSP
- SSP
- アドサーバー
- オーディエンスの提供事業者
- その他のアドテク企業
参加ベンダーは、TCF のシグナルを用いて、自社が宣言した取り扱いに関係するプライバシーの状態を把握します。
もっともベンダーは、引き続き自らのコンプライアンス上の義務について責任を負います。
TCF の CMP API とは何ですか？
TCF の CMP API とは、参加ベンダーやその他の構成要素が TCF CMP とやり取りできるようにする、標準化された技術インターフェースです。
この API は、次の事項に関する機能に対応しています。
- CMP の利用可否
- 同意に関する情報
- TC String の取得
- 同意の更新
- プライバシー状態の伝達
TCF の技術仕様と実装ガイドラインが、該当する API の挙動を定めています。IAB Europe の現行のサポートリソースのページは、CMP API を TCF の中核的な技術仕様として挙げています。
getTCData はどうなりましたか？
TCF の技術仕様は進化してきました。
TCF v2.2 の CMP API は、getTCData コマンドを非推奨としました。
したがって、古い TCF の連携を保守している開発者は、従来の API のパターンがそのまま適切であると考えるのではなく、現行の実装ガイダンスを確認すべきです。
これは、古い TCF v2.2 の連携を現在の v2.3 の環境向けに更新する際に、とりわけ重要です。
GPP とは何ですか。TCF とはどのような関係にありますか？
Global Privacy Platform（GPP）とは、IAB Tech Lab が策定した、より広いプライバシーシグナルのフレームワークです。
TCF と GPP は関連していますが、同じものではありません。
簡略化して区別すると次のとおりです。
欧州向けの Transparency & Consent Framework
複数の法域に対応する、より広いプライバシーシグナルのフレームワーク
GPP は、地域ごとのプライバシーのセクションとあわせて TCF のセクションを含めることができます。
したがって、国際的に事業を展開する組織は、より広い GPP のアーキテクチャの中で TCF を利用することができます。
TCF と GPP の違い
| TCF | GPP |
|---|---|
| IAB Europe のフレームワーク | IAB Tech Lab のフレームワーク |
| 主に欧州の広告エコシステム | 複数法域にまたがるプライバシーのシグナル伝達 |
| TC String を用いる | GPP の文字列・セクションを用いる |
| 欧州のベンダーと目的に関する情報を標準化する | 複数の地域のプライバシーの枠組みに対応する |
| GDPR / ePrivacy の広告ワークフローと強く結びついている | より広いプライバシー規制のシグナル伝達のために設計されている |
したがって TCF と GPP は、互換的な用語として扱うべきではありません。
TCF と Google Consent Mode の違い
IAB TCF と Google Consent Mode は、それぞれ異なる課題を解決します。
TCF は、TCF のエコシステムの中でプライバシー選択のシグナル伝達を標準化します。
Google Consent Mode は、対応する Google のタグやサービスに関連する同意の状態を伝え、その状態に応じて挙動を調整できるようにします。
したがってパブリッシャーは、その両方を利用できます。
- CMP
- TCF / TC String
そして、次のとおりです。
- CMP
- Google Consent Mode
したがってこれらの技術は、競合する選択肢ではなく、相互に補完し合うものになり得ます。
TCF と GPC の違い
Global Privacy Control（GPC）とは、一定のオプトアウトの意思を伝える、ブラウザレベルまたはプライバシーツールのシグナルです。
TCF は、透明性と同意のシグナル伝達のための広告業界のフレームワークです。
両者は異なる目的を担っています。
ウェブサイトは、次のものを併せ持つことがあります。
- GPC
- TCF
- CMP
- Cookie 同意
- Google Consent Mode
- 地域ごとのプライバシールール
これらを同一のプライバシーアーキテクチャの中に併せ持つことになります。
TCF と Cookie 同意の違い
Cookie 同意バナーは、主にユーザーインターフェースです。
TCF は、そのエコシステムの中でプライバシー選択のやり取りを規律する、標準化された業界のフレームワークです。
したがって、簡略化したアーキテクチャは次のようになります。
- Cookie バナー
- TCF CMP
- TC String
- 参加ベンダー
バナーは、ユーザーが実際に操作する部分です。
TCF のフレームワークは、そのエコシステムを支える標準化されたポリシーと技術的な仕組みを提供します。
IAB TCF はどのように機能しますか？
簡略化した TCF のワークフローは次のとおりです。
参加ベンダーを特定する
パブリッシャーが、関連する TCF のベンダーを特定します。
CMP を設定する
CMP が、現行の TCF のポリシー、仕様、GVL の情報を用います。
透明性の情報を提示する
CMP が、関連する目的、ベンダーその他の必要な情報を説明します。
ユーザーの選択を取得する
ユーザーが、該当する同意または異議の選択を行います。
TC String を生成する
CMP が、関連する情報を TC String にエンコードします。
シグナルを利用可能にする
参加ベンダーが、該当する技術的な仕組みを通じてそのシグナルにアクセスできるようにします。
ベンダーがシグナルを解釈する
ベンダーが、TCF のフレームワークと自社が宣言した活動に従って、関連する取り扱いの状態を判断します。
その結果としての状態を実行する
ウェブサイトとベンダーは、実際の取り扱いが該当するプライバシーの状態と一致するようにしなければなりません。
IAB TCF の実装チェックリスト
TCF の実装を公開または更新する前に、パブリッシャーは次の事項を確認すべきです。
- CMP が現行の TCF バージョンに対応していること。
- CMP が TCF への参加のために適切に登録されていること。
- 現行の TCF のポリシーが遵守されていること。
- 現行の技術仕様が用いられていること。
- ベンダー情報が該当する GVL と同期していること。
- 正しい TCF の目的が開示されていること。
- 関連するベンダーが開示されていること。
- Disclosed Vendors セグメントが正しく実装されていること。
- 同意が適切なユーザーの操作を通じて取得されていること。
- 該当する正当な利益にもとづく取り扱いが正しく扱われていること。
- 必要な場合にパブリッシャー制限が設定されていること。
- 正しい TC String が生成されていること。
- ベンダーが関連するシグナルを取得できること。
- ユーザーの選択に反してトラッカーが作動しないこと。
- 同意の撤回が正しく機能すること。
- ベンダーとの連携がテストされていること。
- CMP API の挙動がテストされていること。
- フレームワークの更新後に実装がテストされていること。
IAB Europe は、ポリシー、技術仕様、実装ガイドライン、CMP の登録、ベンダーの登録、v2.3 関連のリソースを網羅する、現行の TCF サポートリソースを維持しています。
IAB TCF の実装でよくある誤り
TCF を GDPR コンプライアンスとして扱う
TCF は業界のフレームワークであり、法的なコンプライアンスの証明書ではありません。
ウェブサイトを TCF v2.2 のままにしておく
現行の実装は、TCF v2.3 に照らして見直すべきです。
TC String そのものを同意として扱う
TC String は、プライバシー上の選択に関する技術的な情報を表すものです。それ自体が法的に有効な同意を作り出すものではありません。
同意の前にトラッカーを読み込む
ウェブサイトには、事前同意を要する取り扱いのための適切な技術的管理策が依然として必要です。
ベンダーの挙動を無視する
正しい TC String を生成していても、ベンダーがその結果としての状態に反して取り扱いを続けているのであれば十分ではありません。
正当な利益を無制限の許可として扱う
ベンダーが宣言した適法な根拠があっても、組織が適用される法律を遵守する義務がなくなるわけではありません。
古い API のコードを使い続ける
古い TCF の連携には、getTCData のような非推奨の API メソッドが含まれていることがあります。
ベンダー情報を更新しない
ベンダー情報やフレームワークの要件は変わることがあります。
「すべて同意」だけをテストする
本格的な TCF の実装では、拒否、一部のみの選択、撤回、再訪問ユーザー、地域ごとの設定についてもテストすべきです。
TCF はどのようにテストすべきですか？
適切な TCF の監査では、CMP のインターフェースと実際の技術的な挙動の両方を確認すべきです。
ユーザーインターフェースのテスト
テスト項目:
- 初回の通知
- ベンダーの開示
- 目的の開示
- 同意のコントロール
- 拒否のコントロール
- プリファレンスセンター
- 撤回
- モバイルでの表示
- アクセシビリティ
- 多言語対応
技術面のテスト
テスト項目:
- TC String の生成
- CMP API
- ベンダーへのシグナルの伝播
- Cookie
- JavaScript の実行
- ネットワークリクエスト
- 広告ピクセル
- サードパーティリクエスト
- 同意状態の変更
- 撤回
ネガティブテスト
あわせてテストする項目:
- すべて拒否
- 一部のみの同意
- 特定のベンダーの拒否
- 特定の目的の拒否
- 操作なし
- 撤回
- 再訪問ユーザー
- 異なる地域
- 異なるブラウザ
- モバイル端末
IAB TCF と ConsentX
ConsentX は、より広いプライバシーアーキテクチャの中で、同意管理と実行のレイヤーとして機能できます。
TCF を利用する組織にとって、望ましいワークフローは次のとおりです。
- ユーザーの選択
- CMP
- TCF のシグナル
- ベンダーの制御
- 実際の取り扱い
ConsentX は、次のような領域で同意管理と技術的な実行を結びつけることを支援します。
Cookie 同意
事前スクリプトブロッキング
同意の記録
監査の証跡
地域ごとのプライバシールール
Google Consent Mode
Global Privacy Control
ベンダーとトラッカーの制御
プライバシー設定の管理
重要な原則は次のとおりです。
同意のシグナル伝達には、技術的な実行が伴うべきです。
ユーザーが特定の許可を与えていないことを示す TC String があっても、ウェブサイトが対応する取り扱いを続けているのであれば、それで十分だと考えるべきではありません。
ConsentX は IAB TCF の代わりになりますか？
いいえ。
IAB TCF と ConsentX は、それぞれ異なる役割を担っています。
TCF は、ポリシー、仕様、技術的なシグナル伝達、参加要件を含む業界のフレームワークです。
ConsentX は、プライバシー上の選択を管理するために必要なユーザー向けおよび技術的な管理策を提供できる同意管理プラットフォームです。
TCF を利用する組織は、自社の CMP の実装が該当する TCF の参加要件と技術要件を満たしているかどうかを評価すべきです。
要点
- IAB TCF とは、IAB Europe Transparency & Consent Framework のことです。
- TCF は任意参加の業界フレームワークであり、法律ではありません。
- TCF は、デジタル広告エコシステムの中でプライバシー選択のやり取りを標準化します。
- TCF v2.3 が現行のフレームワークのバージョンです。
- TCF v2.3 は、TC String に必須の Disclosed Vendors セグメントを導入しました。
- TC String は、プライバシー上の選択に関する標準化された情報を伝えます。
- Global Vendor List（GVL）は、参加ベンダーに関する標準化された情報を提供します。
- TCF CMP は、該当する同意管理のワークフローを実装します。
- TCF は、パブリッシャーとプログラマティック広告にとってとりわけ重要です。
- TCF は、ウェブサイトを自動的に GDPR に適合させるものではありません。
- TCF 自体が Cookie やトラッカーをブロックするわけではありません。
- TCF は、GPC、GPP、Google Consent Mode、一般的な Cookie バナーとは異なるものです。
- 現行の実装は、最新の TCF のポリシーおよび技術仕様に照らしてテストすべきです。
- 実効的な実装には、正しいシグナル伝達と実際の技術的な実行の両方が必要です。