なぜPWAは同意のエッジケースなのか

プログレッシブウェブアプリはネイティブアプリのように振る舞います — ホーム画面にインストールされ、オフラインで動作し、積極的にキャッシュします — しかし依然としてブラウザから配信されるため、Cookieとウェブストレージのルールが適用されます。まさにこのハイブリッドな性質がパブリッシャーをつまずかせます。あらゆるウェブサイトと同じGDPR同意義務が、ユーザーが拒否した後も静かにデータとスクリプトを保持しうるサービスワーカーと永続キャッシュの上に重ねられているのです。

PWAはどこにデータを保存するか

ストレージを同意で制御する前に、PWAがデータを永続化しうるすべての場所を知る必要があります：

• Cookie — 従来からの領域で、いつものように同意によって管理されます。
• LocalStorage / IndexedDB — アプリの状態によく使われますが、分析や広告識別子にも使われます。
• Cache Storage — サービスワーカーはサードパーティのスクリプト（分析、広告SDK）をキャッシュできるため、オフラインでも実行されます。
• サービスワーカー自体 — セッションをまたいで永続し、次回起動時にトラッキングを再登録しうります。

同意はこれらすべてを管理しなければならず、document.cookieだけではありません。

同意優先のサービスワーカーパターン

中心原則：サービスワーカーは、非必須のサードパーティリソースをキャッシュまたは実行する前に、同意状態を読み取らなければなりません。クリーンなパターンは次のようになります：

• 同意シグナルをサービスワーカーが読める場所に保存します — IndexedDBか、CMPが選択のたびに更新するキャッシュエントリです。
• サービスワーカーのfetchハンドラで、その目的の同意が存在しない限り、分析/広告エンドポイントのキャッシュを拒否します。
• ユーザーが同意を撤回したら、サービスワーカーにメッセージを送り、キャッシュされたトラッキングスクリプトをパージし、関連するIndexedDBストアをクリアします。

その最後のステップを省略することが、最も一般的なPWAのコンプライアンスギャップです。バナーは“拒否”と言っているのに、キャッシュされた分析スクリプトが次のオフライン起動時にサービスワーカーから発火し続けるのです。

オフラインの同意UX

PWAはネットワークなしで起動できます。あなたの同意バナーとユーザーの保存された選択は、両方ともオフラインで機能しなければなりません — CMPのUI自体をキャッシュし、同意サーバーに到達できないという理由だけで“許可”をデフォルトにしないでください。以前の選択を確認できない場合は、ユーザーを未同意として扱い、確認できるまで必須機能のみを提供してください。

広告収益への影響

広告で支えられるPWAでは、同意状態はオンラインでもオフラインでも、リクエスト時に広告SDKに届かなければなりません。正しく配線されたPWAは、通常のサイトと同じようにIAB TCF文字列とConsent Mode v2シグナルを需要パートナーに渡します。誤って設定されたものは古い“同意なし”状態をキャッシュし、あなたのeCPMを無期限に非パーソナライズレートに崩壊させます。同意の鮮度を収益指標として扱ってください。

FlexyConsentがどう役立つか

FlexyConsentは同意記録をサービスワーカーが読める形で保存し、オフライン起動を生き延びるTCFおよびConsent Mode v2シグナルを発し、キャッシュパージに接続できる撤回フックを公開します — これにより、あなたのPWAはコンプライアンスを保ち、広告スタックはあらゆる領域で可能な限り新鮮な同意シグナルを保ちます。

主なポイント

• PWAは完全なGDPR同意義務に加え、サービスワーカーとキャッシュの複雑さに直面します。
• Cookieだけでなく、Cookie、LocalStorage、IndexedDB、Cache Storageを同意で制御してください。
• 撤回時には、キャッシュされたトラッキングスクリプトをパージし、保存された識別子をクリアしてください。
• 同意状態を新鮮かつオフラインセーフに保ち、広告収益が非パーソナライズレートに張り付かないようにしてください。