サードパーティCookieがChromeブラウザで廃止になるまで約1年と数カ月。その猶予期間が刻々と終わりに近付くなか、今後も効果的なWeb広告を存続させなければならないアドテク企業やブラウザ企業は、プライバシー重視の代替策を探すのに余念がありません。これに関係するもっとも新しい提案が、先日、GoogleのチームによってGitHubに公開されました。それが「Devekey（ヒメウミスズメの意）」です。この提案は、Googleの「プライバシーサンドボックス」構想の一環であり、サイトをまたぐトラッキング機能に代えて、プライバシー優先のテクノロジーを推進し、同時にフィンガープリンティングやネットワークレベルのトラッキングなど、好ましくない迂回策の防止を図るものです。このDovekeyはどのような経緯で生まれたのでしょう？ Dovekeyは、アドテク企業のクリテオ（Criteo）が出したプライバシー提案「SPARROW（スズメの意）」に対する改善案です。そしてこのSPARROWはGoogleによる当初のプライバシー提案「TURTLEDOVE（キジバトの意）」に対して出された改善案でした。以下では、Dovekeyについて、広告主とパブリッシャーが知っておくべき基本事項を、いつもの「一問一答」形式で解説します。◆　◆　◆

――TURTLEDOVEとは何でしょう？

TURTLEDOVE、は「Two Uncorrelated Request, Then Locally-Executed Decision On Victory（無相関なふたつのリクエストの勝者を、ローカルで決定する）」の略であり、Googleの「プライバシーサンドボックス（Privacy Sandbox）」の一部をなすフレームワークです。この提案の目玉は、リアルタイム入札で実施される広告の決定を、アドサーバーではなく、すべてブラウザ内で実行する点にあります。このアプローチは、悪意ある第三者が入札ストリームのデータをかすめ取り、ユーザーのプロフィールを作成するのを阻止します。しかしこの方法では、通信速度に大きな負担がかかるのではないか。業界がそう気付くのに、それほど時間はかかりませんでした。「ブラウザで膨大な量の決定を行うというなら、ブラウザにCookieを格納するのと何が違うのか」。アドテク企業のビーズワックス（Beeswax）で最高経営責任者（CEO）を務めるアリ・パパロ氏はそう問いかけます。TURTLEDOVEは、関心グループやコンテクスチュアルターゲティングといった手法を想定する一方で、A/Bテスト、フリクエンシーキャッピング、ブランドセーフティなどがどう機能するのかについては、十分に言及されていませんでした。さらに、世界でもっとも人気の高いブラウザであるChromeを、Googleが所有していることも問題でした。「Google支配下のブラウザである限り、TURTLEDOVEは監査不可能なエンジンだ」とパパロ氏は訴えます。

――SPARROWとはどのようなものでしょう？

TURTLEDOVEが抱えるこれら諸問題に対して、仏アドテク企業のクリテオがひとつの答えを出しました。それがSPARROW、すなわち「Secure Private Advertising Remotely Run On Webserver（Webサーバー上でリモート実行される、セキュアでプライベートな広告）」です。SPARROWでは、広告オークションのプロセスとロジックを、ブラウザではなく、「ゲートキーパー」と呼ぶ独立したサードパーティが実行します。また、広告主にはリアルタイムのデータがフィードバックされます。それでも業界には、レポーティングがリアルタイムで行われることで、ゲートキーパーがユーザーデータや広告データの安全を担保するのが困難になるなど、いくつかの懸念点が挙げられました。加えて、ゲートキーパーの役割を果たせる企業の数も限られています。「ゲートキーパーの候補となる企業は、クラウド企業にしろ電気通信企業にしろ、あるいはGoogleでもFacebookでも、そのほとんどが広告部門を持っている。自身の利益に反さずに、この役目が果たせる企業など、果たしているのだろうか？」パパロ氏もそう疑問を投げかけます。

――では、Dovekeyとはどのようなものでしょう？

Googleが提案するDovekeyは、クリテオのSPARROWをベースとしています。GoogleがGitHubに公開した提案で述べている通り、Dovekeyの主要なコンセプトは、「たとえ（SPARROWと違い）ゲートキーパーのサーバーを単純な参照テーブルの役割に留めても、SPARROWが提案する入札方式のメリットのほとんどは実現できる」という点です。この場合の「ゲートキーパー」について、Googleは「キーバリューサーバー」だと説明しています。これは広告サーバーを単純化したバージョンで、（Googleではなく）サードパーティ企業が運用します。このサーバーが「キー」に相当するコンテクスチュアル広告と関心グループの情報を受け取り、バリュー（ビッド）を返します。なお、Dovekeyがカバーするのは入札とオークションの要素に限られます。たとえば、広告主がファーストパーティデータを活用してプライバシーセーフな方法でリターゲティングをするようなケースなどがそうです。Dovekeyの枠組みに、測定の部分は含まれません。

　　　

――現在のリアルタイム入札より優れている理由は？

Googleのシニアプロダクトマネジャーで、ユーザーのプライバシー保護と信頼向上のための施策を担当するチェトナ・ビンドラ氏は、「もっとも重要な要素は信用だ」と述べています。基本的な考え方として、Dovekeyは広告主、Webサイトのオーナー、アドテクベンダーに個人情報の収集は一切許していません。アドサーバー企業は個人データにアクセスすることが可能ですが、Dovekeyは彼らに対し、情報漏洩を防ぐためのポリシーや制限事項の整備を提案しています。

――具体的には、どのようなポリシーや制限事項となりそうですか？

それは今後の議論次第です。ひとつ考えられるのは、業界が一体となって標準化されたポリシーを策定し、合意することです。各アドサーバーはそれぞれ監査を受けて、ルールの遵守を徹底します。あるいは、暗号プロトコルを活用するなど、もっと技術的な制限を設けるという、より複雑な方法も考えられます。多様なプライバシー保護技術を適用すれば、悪意ある第三者によるアドサーバーへの不正侵入や、ユーザーIDと特定のコンテクスチュアル広告の連携を防ぐこともできるでしょう。さらに、シングルサーバーによる「プライベート情報検索システム（PIR）」（GitHubがウィキペディアにリンクを貼るほど複雑なシステム）を設置するなど、さらに複雑な方法も考えられます。このシステムでは、サーバーは受け取るユーザーデータについて、何ひとつ学習しません。ただし、このオプションはコストが高くつく可能性があります。

――Google以外のプレイヤーたちは、Dovekeyをどのように見ているのでしょう？

クリテオのバイスプレジデントで、プロダクト、広告プラットフォーム、アナリティクスを担当するシャルルアンリ・エノ氏は、プレスリリースで次のように述べています。「SPARROWの目的は、消費者、広告主、パブリッシャーのニーズが共存できるような、広告ソリューションの構築を業界に促すことだった。Google広告のチームがDovekeyという最新の提案で、SPARROWをベースとした枠組みを提案していることに意を強くしている」。カフェメディア（CafeMedia）のポール・バニスター最高戦略責任者は、「Dovekeyは、少なくとも表面的には、SPARROWの改善案だと思われる」と述べています。「良好な進捗状況だと思う。Chromeチームが早い段階でW3C（World Wide Web Consortium）にこのプロセスを公開して価値を示し、オープンソースのアプローチを取っていることは評価できる」。バニスター氏はそう続けました。

――反対や抵抗はあるでしょうか？

何せアドテクとGoogleがからむ問題です。批判の可能性は常にあります。たとえばクリテオのエノ氏は、利用できるコンテクストの種類や数が、いまも不明な点を指摘します。それはこのアプローチの柔軟性に大きく影響する要素です。エノ氏はさらにこう続けます。「広告に対するユーザーのエンゲージメントについて、形式はどうあれ、低レイテンシでフィードバックできる仕組みがなければ、マーケターたちは何の情報もないままに、同じ関心グループに対し、絶えず同じ広告を配信するしかない」。

――次の展開は？

Googleのプライバシーサンドボックス関連の提案は得てしてそうなのですが、今回もGitHubやW3Cが主催する業界横断的なweb広告の改善に取り組むビジネスグループ（Improving Web Advertising Business Group）を通じて、業界のフィードバックを求めています。このビジネスグループがDovekey提案でまとまることができるなら、次の段階として、W3Cの適切なワーキンググループ（あるいは新設の部会）に議論を委ね、仕様の作成に着手することも考えられます。［原文：WTF is Dovekey］LARA O'REILLY（翻訳：英じゅんこ、編集：村上莞）Illustration by IVY LIU