Protected Audience APIおよびFenced Framesにおける広告クリエイティブの技術的制約とパーソナライズの実装
はじめに
ポストサードパーティCookie時代において、ユーザープライバシーを保護しつつ関連性の高い広告を提供することは、広告技術に関わる企業にとって喫緊の課題です。Google ChromeのPrivacy Sandboxプロジェクトで提案されているProtected Audience API（旧Fledge）は、ブラウザ上でのオークションを通じてリターゲティング広告を実現する技術であり、Fenced Frames APIは、オークションで落札された広告を安全に表示するための仕組みを提供します。
これらのAPIは、クロスサイトトラッキングを防ぐために厳格なプライバシー境界を設けています。これにより、広告クリエイティブの配信およびパーソナライズにも特有の技術的制約が生じます。本記事では、Protected Audience APIとFenced Frames APIにおける広告クリエイティブの取り扱い、パーソナライズを実装する上での技術的課題、および考慮事項について詳細に解説します。
Protected Audience APIにおけるクリエイティブの扱い
Protected Audience APIのオークションプロセスは、ブラウザ内で実行されるJavaScript関数 (generateBid, scoreAd, render) を中心に進められます。広告クリエイティブに関する情報は、主にgenerateBid関数内で入札データの一部として定義され、render関数で最終的に表示されるクリエイティブが決定されます。
generateBid() における広告データ構造
広告の入札ロジックを提供するバイヤー（広告主、DSPなど）は、Protected AudienceのInterest Groupに参加する際に、そのグループに関連する広告候補のリストを含めます。このリストの各項目は、広告クリエイティブに関する情報を含んだオブジェクトです。
// Interest Groupの設定例
{
name: 'custom-audience-example',
owner: 'buyer-domain.com',
biddingLogicUrl: 'https://buyer-domain.com/bidding-logic.js',
ads: [
{
renderUrl: 'https://buyer-cdn.com/ad-creative-1/index.html', // クリエイティブ本体のURL
metadata: { // クリエイティブに紐づくメタデータ
type: 'display',
size: '300x250',
productId: 'XYZ123' // パーソナライズに使用する可能性のある情報（後述の制約あり）
}
},
{
renderUrl: 'https://buyer-cdn.com/ad-creative-2/index.html',
metadata: {
type: 'display',
size: '320x50',
discount: '10%'
}
}
// ... 他の広告候補
]
}
generateBid関数は、この広告候補リストを処理し、各候補に対して入札額を計算します。ここで、adオブジェクトのmetadataプロパティを通じて、クリエイティブに紐づく追加情報を参照することが可能です。ただし、generateBid関数内で利用可能なデータは、Interest Groupに紐づくデータ (interestGroupオブジェクト) およびパブリッシャー側のコンテクスチュアルデータ (auctionSignals, sellerSignals, browserSignals) に厳しく制限されています。metadataの内容は、これらのデータと組み合わせて入札ロジックに使用されますが、複雑なクロスサイトユーザープロファイルデータに基づく動的なパーソナライズは意図されていません。
render() におけるクリエイティブの選定と表示
オークションで落札された広告は、バイヤーが提供するrenderUrlを使用して表示されます。Protected Audienceオークションでは、落札したバイヤーのbiddingLogicUrlに含まれるreportResult() 関数およびrender() 関数が実行されます。
render() 関数は、落札した広告オブジェクト (ad) を引数として受け取り、その広告を表示するために使用されるURLを返します。通常、これはad.renderUrlになります。
// 買主側のbiddingLogic.js内のrender関数例
function render(ad, moveOn) {
// ad.renderUrl をそのまま返すか、必要に応じて動的に処理
return ad.renderUrl;
}
このrenderUrlは、その後Fenced Frames APIを使用して表示されることが推奨されています（後述）。
Fenced Frames APIにおけるクリエイティブの表示
Fenced Framesは、埋め込みコンテンツ（特に広告）をホスティングページから厳密に分離するためのHTML要素 (<fencedframe>) です。Fenced Frame内のコンテンツは、親フレームや他のフレームとデータ共有を原則として行いません。これは、クロスサイトIDによるユーザー追跡を防ぐための重要なセキュリティ境界です。
Fenced Framesのセキュリティモデルとデータ分離
Fenced Frameは、window.postMessage、localStorage、cookie、indexedDBなどの標準的なウェブAPIによるデータ共有を意図的に制限または禁止しています。Fenced Frame内のコンテンツは、自身がロードされたURLのオリジンに紐づくデータにはアクセスできますが、親フレームのオリジンや他のFenced Frameのオリジンとは独立しています。
この強い分離は、広告クリエイティブを配信する上で重要な意味を持ちます。Fenced Frame内で実行される広告クリエイティブのスクリプトは、親ページで利用可能なファーストパーティデータや、ユーザーに関する詳細なクロスサイトデータを直接参照することができません。
config オブジェクトによるクリエイティブURLとデータ伝達
Protected Audience APIで落札された広告をFenced Frameで表示する場合、fencedFrame.config プロパティを使用することが推奨されています。これは、データ共有を最小限に抑えつつ、Fenced Frameに表示するコンテンツの情報を安全に渡すための仕組みです。
// Protected Audienceオークション後の表示例
const auctionResult = await navigator.runAdAuction(auctionConfig);
if (auctionResult) {
const fencedFrame = document.createElement('fencedframe');
fencedFrame.config = auctionResult; // auctionResultはrenderUrlを含むConfigオブジェクト
document.body.appendChild(fencedFrame);
}
auctionResult オブジェクトは、レンダリングに使用されるConfigオブジェクトであり、落札された広告のrenderUrlを含みます。このConfigオブジェクトを通じて、Fenced Frameはどのクリエイティブをロードすべきかを知ることができます。
Fenced Framesの仕様には、特定のユースケース（例えば、Protected Audienceオークションにおけるインタレストグループ情報の利用や、Attribution Reportingのためのデータ伝達）のために、Configオブジェクト経由での限定的なデータ伝達を可能にするPrivate Aggregation APIやShared Storage APIとの連携が提案されています。しかし、これは親フレームからFenced Frame内への自由なデータ伝達や、Fenced Frame内での詳細なユーザープロファイルへのアクセスを許可するものではありません。
Fenced Frame内でのAPI利用制限
Fenced Frame内では、多くのウェブAPIにアクセスできますが、一部のAPIは制限されています。特に、localStorage, cookie, indexedDBなど、ユーザーを識別したりクロスサイトトラッキングに悪用される可能性のあるストレージAPIへのアクセスは厳しく制限されます。また、window.postMessageによる親フレームとの通信も制限されます。
これらの制限は、クリエイティブ自体がユーザーに関する永続的な情報を保存したり、親ページから詳細なパーソナライズデータを直接受け取ったりすることを防ぎます。
プライバシー保護下でのクリエイティブパーソナライズ技術
上記のような技術的制約の中で、広告クリエイティブのパーソナライズをどのように実現できるか、あるいはどの程度のパーソナライズが許容されるかについて検討します。
コンテクスチュアル情報に基づくパーソナライズ
Fenced Frame内のクリエイティブは、親ページのコンテキストに関する情報を直接取得することはできませんが、オークション実行前に利用可能だったコンテクスチュアルデータ（例：ページのカテゴリ、キーワード）を、generateBidのauctionSignalsやsellerSignalsを通じて入札ロジックに渡し、落札された広告のmetadataに含めることは可能です。
例えば、スポーツ用品サイトのランニングシューズのページであれば、「ランニングシューズ」というコンテキスト情報をバイヤーに渡し、バイヤーはその情報とInterest Groupデータ（例：「過去にランニングシューズを購入したユーザー」）を組み合わせて、ランニングシューズの広告を入札し、その広告のmetadataに「商品カテゴリ: ランニングシューズ」という情報を付加することができます。Fenced Frame内のクリエイティブは、ロード時に自身のURLやmetadataを参照し、例えばランニングシューズの画像を動的に表示するといった、限定的なコンテクスチュアルパーソナライズを行うことが可能です。
オーディエンス情報（Protected Audience interest group data）を活用した限定的なパーソナライズ
Protected Audience APIのInterest Groupに参加する際に設定されるuserBiddingSignalsや、Interest Groupのデータ (interestGroupオブジェクト) は、generateBid関数内で参照可能です。これらのデータ（例：ユーザーが過去にサイト内で閲覧した商品のIDリスト）は、入札額の計算に利用されるだけでなく、落札した広告のmetadataとしてクリエイティブに間接的に渡すことも検討できます。
しかし、Fenced Frame内のクリエイティブがこのmetadataをどのように利用できるかには制約があります。metadata自体はFenced Frame内で利用可能ですが、その内容に基づいて、ユーザー個人の詳細な行動履歴に基づく複雑な動的クリエイティブを生成することは、技術的制約（Fenced Frame内からの外部データ取得制限、ストレージ制限）やプライバシー原則から困難です。主に、大まかなカテゴリや特定の Interest Group に関連する限定的な情報（例：「このInterest Groupのユーザー向け割引」）を示す程度に留まる可能性が高いです。
Shared Storage API等との連携可能性（制限付き）
Shared Storage APIは、クロスサイトで共有可能な、パーティション化されていないストレージを提供しますが、そのデータへのアクセスは厳格に制限されています。Stored dataは、Private Aggregation APIなどのプライバシー保護APIを通じてのみ読み出すことが可能であり、直接的な読み出しや、Stored dataに基づいた動的なクリエイティブ生成はサポートされていません。
将来的には、Shared Storageに保存されたデータ（例：過去に購入した商品のブランド情報）を基に、Private Aggregation APIを通じて集計された情報（例：最もよく購入されるブランド）をクリエイティブの表示ロジックに反映させる仕組みが検討される可能性はありますが、これも個別のユーザーデータに基づくリアルタイムかつきめ細かいパーソナライズとは性質が異なります。
実装上の技術的制約と考慮事項
Fenced Frame内での計測・外部通信制限
Fenced Frame内のクリエイティブからの直接的な外部通信（例：サードパーティトラッカーへのImpression/Clickビーコン送信）は制限されます。計測は、Attribution Reporting APIや、Fenced Frame内のPrivate Aggregation APIを利用して行われます。クリエイティブがクリック可能である場合、クリックイベントに関する情報は、オークション設定に含まれるclickAd() 関数や、Private Aggregation APIを通じて報告されることになります。これらのAPIは、集計レポートやイベントレベルレポート（特定の条件下のみ）を提供し、個々のユーザーの行動を直接追跡することは困難です。
デバッグの複雑性
Protected AudienceオークションとFenced Framesはブラウザ内部で実行されるため、デバッグが複雑になります。特にFenced Frame内のクリエイティブの挙動を確認したり、エラーを特定したりするには、ブラウザの開発者ツールの特別な機能（例えば、Chrome DevToolsにおけるFenced Framesの検査機能）を利用する必要があります。クリエイティブパーソナライズのロジックに問題があった場合、その原因究明にはこれらの特殊なツールへの習熟が求められます。
クリエイティブテンプレートとデータの分離
プライバシー保護の観点から、クリエイティブの本体（HTML/CSS/JavaScriptテンプレート）と、パーソナライズに使用するデータ（metadataに含まれる情報など）は明確に分離し、データは必要最低限に留めることが重要です。クリエイティブは汎用的なテンプレートとして作成し、レンダリング時に限定されたデータを使って表示内容を調整するアプローチが推奨されます。これは、クリエイティブ自体が過度に複雑なロジックや多数のデータソースへの依存を持つことを防ぎます。
ユーザー同意との連携
Protected Audience APIやFenced Frames APIの利用には、多くの場合、関連するデータ処理に対するユーザー同意が必要となります。CMP (Consent Management Platform) を通じて取得された同意情報は、APIの実行を制御するために、発行元サイトのコンテキストで管理されます。Protected AudienceオークションやFenced Frameでの表示を行う前に、適切な同意が取得されているかを確認し、同意がない場合はこれらのAPIを利用しないように実装する必要があります。技術的な側面だけでなく、法的な要求事項（GDPR, CCPA/CPRAなど）に基づいた同意管理の実装が不可欠です。
将来的な展望
Privacy Sandbox API群は現在も開発が進められています。Shared Storage APIやPrivate Aggregation APIなど、クリエイティブのカスタマイズに利用できる可能性のある補助的なAPIの機能拡張や連携強化が期待される可能性があります。また、広告業界全体で、プライバシーを尊重しつつ効果的なクリエイティブを配信するための新しいアプローチやベストプラクティスが継続的に模索されると考えられます。セキュアな環境下でのデータ処理技術（例：Trust Tokens APIの進化や、ローカルでの機械学習モデル利用）が、クリエイティブの関連性向上に貢献する可能性も指摘されています。
まとめ
Protected Audience APIとFenced Frames APIは、プライバシーを保護しつつリターゲティング広告を可能にするための重要な技術ですが、広告クリエイティブのパーソナライズに関しては、従来のクロスサイトトラッキングに基づく手法と比較して厳格な技術的制約が存在します。
Fenced Frameの強いデータ分離モデルは、クリエイティブがユーザーに関する詳細な情報に直接アクセスすることを防ぎます。パーソナライズは、主にProtected Audienceオークションで利用可能な限定的なデータ（コンテキスト情報、Interest Groupに紐づく集計的・限定的なユーザーシグナル）を、広告のmetadataを通じてクリエイティブに間接的に渡し、汎用的なテンプレート内で利用可能な範囲で行われることになります。
実装においては、Fenced Frame内での計測・通信制限、デバッグの複雑性、クリエイティブテンプレートとデータの分離、そしてユーザー同意管理との連携といった技術的・運用的な課題を十分に理解し、対応策を講じることが求められます。これらの制約を理解し、Privacy Sandboxの設計思想に沿った技術実装を行うことが、ポストCookie時代におけるプライバシー重視広告成功の鍵となります。