要点のまとめ

TCF v2.3 は v2.2 の進化版であり、全面的な再設計ではありません。TC String のフォーマットは互換性があり、既存の目的（purpose）や機能（feature）は維持され、多くのパブリッシャー向け UI 要件もほぼそのまま引き継がれます。意味のある変更は主に次の4つの領域に集中しています。

• ベンダー情報とデータ保持期間の提示方法に関する、より明確なルール。
• 2022年のベルギー DPA の決定以降、規制当局が求めてきた詳細なセカンドレイヤーコントロールに関する新要件。
• ダークパターン、同等の目立ち方（equal prominence）、事前にオンになっているオプションに対するポリシー執行の強化。
• Global Vendor List (GVL) のスキーマおよびベンダー開示フローの調整。

v2.3 が作られた理由

TCF の各バージョンは、3つのステークホルダーの間の調整の産物です。すなわち、マネタイズを維持したいパブリッシャー、安定した��術インターフェースを必要とするベンダー、そして具体的なコンプライアンスギャップを次々と指摘する規制当局です。v2.3 は、次の3つの圧力に直接応える形で設計されています。

1. v2.2 における「正当な利益（legitimate interest）」の乱用に対する執行。複数の欧州 DPA は、多くのベンダーが本来はコンセントが唯一の適法根拠であるべき目的に対して LI を主張していると判断しました。v2.3 では、ベンダーが宣言する法的根拠の開示が強化され、その情報がコンセント UI のより早い段階で表示されるようになります。
2. ダークパターンに関する継続的な苦情。更新されたポリシーでは、equal-prominence ルールがより明示的に定義され、セカンドレイヤーにおける事前オンのトグルに関する抜け穴が塞がれています。
3. 大規模 CMP およびパブリッシャーからの運用上のフィードバック。v2.2 では、モバイルや CTV でクリーンに実装するのが難しい必須開示項目がいくつか導入されました。v2.3 では必須開示セットが整理され、その多くをレイヤードビューに配��できるようになっています。

TC String の互換性

TC String 自体は後方互換性を維持しています。v2.3 対応の CMP は、v2.2 ベンダーが読み取れる文字列を生成し、v2.3 ベンダーは移行期間中、v2.2 の文字列を解釈できます。文字列のコアセグメント内のバージョンインジケーターが、CMP が準拠を主張するポリシーバージョンを示し、GVL バージョンのポインタはそれとは独立して進みます。

実務的な意味としては、すべてのベンダーを同時に更新する必要はなく、v2.3 をデプロイした当日に全ユーザーから再コンセントを強制的に取得する必要もありません。段階的なロールアウトが明示的にサポートされています。

主な技術的変更点

1. ベンダー開示とデータ保持

v2.3 では、CMP がレイヤード UI 内で各ベンダーの宣言するデータ保持期間を表示することが求められます。これは、別ページのベンダーリストだけに表示すればよい、という扱いではなくなります。保持期間の値自体は以前から GVL の一部でしたが、v2.2 ではユーザーが目的と並べて確認できる���うに表示することは義務付けられていませんでした。v2.3 ではこのギャップが解消されました。規制当局は、ユーザーが自分のデータがどのくらいの期間保持されるかを知らなければ、十分な情報に基づいた選択はできないと主張していたためです。

2. より厳格なセカンドレイヤーコントロール

セカンドレイヤー（「設定を管理」ビュー）では、v2.3 により、必須ではない目的およびベンダーに対するトグルはデフォルトでオフでなければならないことが明示されました。ユーザーが「同意する」を明示的にクリックしなかったとしても、事前にチェックされたボックスやオンになっているスライダーはポリシー違反となります。これまで「ソフトオプトイン」パターンに依存していた CMP は、セカンドレイヤーのレンダリングを見直す必要があります。

3. Equal Prominence の執行

equal prominence ルール自体は v2.1 から存在していましたが、v2.3 では解釈の余地が少ない形で定義されています。「すべて拒否」コントロールは、「すべて同意」と同じレイヤーにあり、同等の視覚���な重み、同じ色コントラストクラス、同じ操作ステップ数でなければなりません。リンクの背後に拒否を隠したり、小さいボタンにしたり、別画面に分けたりすることは、判断の余地のあるグレーゾーンではなく、明確なコンプライアンス違反とされます。

4. Legitimate Interest のシグナリング

v2.3 で正当な利益（legitimate interest）を法的根拠として宣言するベンダーは、どの目的について評価を行い、どの目的について Legitimate Interests Assessment を完了したかも宣言しなければなりません。CMP は、この宣言をユーザーインターフェースに反映し、ユーザーが十分な情報を得たうえで異議を唱えられるようにする義務があります。実務的には、「異議を唱える」フローにおいて、汎用的なトグルではなく、ベンダーごとの LIA ステータスが表示されるようになるということです。

5. GVL スキーマの更新

Global Vendor List のスキーマには、保持期間の粒度、LIA ステータス、および宣言された目的に対応する各ベンダーのプライバシーポリシー該当セクションへの機械可読なリンクといったフィール���が追加されます。GVL をキャッシュしている CMP は、v2.3 GVL を参照する前にスキーマパーサーを更新し、新しいフィールドを解釈できるようにしておく必要があります。

UX に影響するポリシー変更

TCF は技術仕様であると同時に、一連のポリシーでもあります。v2.3 のポリシー変更のいくつかは、コンセント UI に直接影響します。

• 「同意せずに続行」を拒否と同等の操作として扱うことの禁止 — ただし、そのボタンが見た目の上で同意ボタンと同等であり、完全拒否と同じ TC String を生成する場合を除きます。
• 言語のパリティ — コンセント通知は、サイト自体が提供されているすべての言語で利用可能でなければならず、ユーザーのブラウザ言語だけに対応していればよいというわけではありません。CMP はロケールの上書き（locale override）をサポートする必要があります。
• 恒常的なアクセス — ユーザーは、ランディングページだけでなくサイト内のすべてのページから、設定センター（プリファレンスセンター）にアクセスできなければなりません。また、そのアクセスリンクは、非専門家のユーザーでもコンセント関連であると認識できるラベルで表示される必要があります。

パブリッシャーが行うべきこと

1. CMP ベンダーの v2.3 対応状況を確認する。 v2.3 認証済みビルドが利用可能になる正確な日付と、そのビルドが報告するバージョン文字列を確認してください。
2. GVL キャッシュロジックを更新する。 GVL のミラーを自前でホスティングしている場合は、v2.3 GVL がロールアウトされる前にスキーマパーサーを更新してください。そうしないと、新しいベンダーの検証に失敗します。
3. セカンドレイヤー UI を書き直す。 すべてのトグルがデフォルトでオフになっていること、equal prominence が視覚的に担保されていること、そして保持期間が目的と並べて表示されていることを確認してください。
4. コンプライアンス監査を再実施する。 規制当局にとって最も簡単な指摘ポイントは、v2.3 で明示的に列挙されたダークパターン違反です。次回の執行レビュー前に修正しておきましょう。
5. 再プロンプト戦略を計画する。 TC String 自体は後方互換性がありますが、ポリシー上は、処理の範囲や開示内容が実質的に変わる場合には、再度コンセントを取得することが推奨されています。自社の v2.3 ロールアウトが、自社オーディエンスにとって「実質的な変更」に該当するかどうかを判断してください。

ベンダーが行うべきこと

1. LI を宣言しているすべての目的について Legitimate Interests Assessment を完了し、その結果を GVL に提出します。
2. GVL エントリを更新し、v2.3 スキーマのフィールド（保持期間の粒度、LIA 宣言、プライバシーポリシーへのディープリンク）を反映させます。
3. TC String パーサーを検証し、IAB Europe が提供する v2.3 リファレンス文字列に対してテストします。
4. CMP パートナーとカットオーバー日を調整し、最初の v2.3 文字列を含むバイヤーリクエストが、v2.2 のみ対応のベンダーに届くことがないようにします。

よくある移行時の落とし穴

• v2.3 を UI リニューアルの機会とみなしてしまうこと。 v2.3 ロールアウトと同時にブランド更新をまとめて実施したくなるかもしれませんが、それはコンプライアンステストを複雑にします。まずはコンプライアンス対応に限定した v2.3 リリースを出し、その後でデザインを改善する方が安全です。
• 保持期間表示要件の見落とし。 チームはベンダーリストビューの更新は行う一方で、保持期間を目的ごとのレイヤードビューにも表示しなければならないことを忘れがちです。
• TC String だけで十分だと考えてしまうこと。 非準拠の UI から生成された TC String は、文字列自体が形式的に正しくても、依然として非準拠です。規制当局は、文字列は問題なさそうに見えても、バナーが拒否ボタンを隠していた事例に対して繰り返し制裁を行ってきました。
• CTV とモバイルをスコープ外にしてしまうこと。 v2.3 は、TCF シグナルが生成されるあらゆる面（サーフェス）に適用されます。Web を更新しても、CTV やモバイルアプリを放置すれば、結果としてハイブリッドな非準拠環境を生み出してしまいます。

まとめ

TCF v2.3 は v2.2 からの破壊的な変更ではありませんが、欧州のプログラマティックエコシステムを支えるルールを着実に引き締めるアップデートです。方向性は明確です。より高い透明性、より少ないダークパターン、より細かなユーザーコントロール、そしてこれまで見逃されがちだったグレーゾーンに対する寛容性の低下です。v2.3 を単なる軽微なパッチとみなす CMP やパブリッシャーは、結局のところ再び規制当局の前に立たされることになるでしょう。一方で、この移行を機にセカンドレイヤー UX を整理し、正当な利益に依存した抜け道を廃し、真の equal-prominence を備えたコンセントフローを再構築する事業者は、v2.3 時代においても実際に取引が成立するインベントリを確保できるだけでなく、将来の v2.4 以降にも耐えうるコンセント体制を手に入れることができます。