比較2026年11月14日 | FlexyConsent

同意をどこに保存するか：Cookie、localStorage、サーバーサイドの記録を比較

2つの異なる仕事

訪問者が同意の選択をしたとき、2つの別々のことを行う必要があります。1つ目は、ページごとにバナーが再表示されず、タグが何を許可されているかを把握できるように、ブラウザがその選択を記憶することです。2つ目は、選択が行われたこと、訪問者に何が表示されたか、いつ行われたかを、後から証明する必要があるかもしれないことです。これらの仕事は異なる保存の仕組みで処理されることが多く、混同すると実際に問題が起きます。バナーが何度も再表示される、一部のブラウザで選択が消える、誰かに尋ねられたときに示せる記録がない、といったことです。

この比較では、ファーストパーティCookie、localStorageなどのブラウザストレージ、サーバーサイドの同意記録という3つの一般的な選択肢を取り上げ、それぞれが適する場面を検討します。

選択肢1：ファーストパーティCookie

Cookieは、同意状態の従来からの保存先です。TCF対応のCMPは通常、同意文字列をファーストパーティCookieに保存し、多くのCMPは独自の設定データもそこに保存します。

強み

サーバーから読み取れる。 Cookieはリクエストごとに送信されるため、サーバーサイドのコード、エッジのロジック、サーバーサイドのタグ付けは、JavaScriptを待たずに選択を読み取れます。
サブドメイン間で共有できる。 登録可能ドメインに設定されたCookieは、www、blog、shopといったサブドメインをカバーできます。
広く期待されている。 多くの広告テクノロジーの連携は、Cookie内に同意を探します。

弱み

サイズの制限。 ブラウザはCookieのサイズを約4 KBに制限しており、多数のベンダーを含むTCF文字列とその他の値でその上限に近づくことがあります。
リクエストのオーバーヘッド。 画像やスクリプトのリクエストを含め、自社ドメインへのすべてのリクエストがCookieを運びます。
一部のブラウザでの有効期間の上限。 SafariのIntelligent Tracking Preventionは、JavaScriptで作成されたCookieの最大有効期間を7日間に制限します。自社サーバーがHTTPレスポンスで設定したCookieは、一般にもっと寛大に扱われますが、例外もあります。

選択肢2：localStorageなどのブラウザストレージ

一部のCMPは、詳細な設定をlocalStorageに保存し、ときには小さなCookieも併用します。

強み

より多くの容量。 オリジンあたり数メガバイトあり、ベンダー単位の詳細な選択に十分です。
リクエストのオーバーヘッドがない。 サーバーには何も自動的に送信されません。

弱み

サーバーからは見えない。 サーバーサイドのコードやエッジのロジックは読み取れないため、サーバー側の判断はいずれもブラウザを待たなければなりません。
単一のオリジンに束縛される。 www.example.comのストレージはshop.example.comでは使えないため、訪問者がサブドメインごとにバナーを再び見ることがあります。
削除される可能性がある。 Safariは、ブラウザの使用で7日間ユーザーが操作していないサイトについて、localStorageを含むスクリプトで書き込み可能なストレージを削除することがあり、プライベートブラウズモードでは通常、セッション終了時に消去されます。

選択肢3：サーバーサイドの同意記録

サーバーサイドの記録は、選択が行われるたびに、自社またはCMPプロバイダーが保存するエントリーです。通常、仮名の識別子、タイムスタンプ、選択内容、表示されたバナーやポリシーのバージョン、地域などの文脈が含まれます。

強み

耐久性のある証拠。 Cookieの消去やブラウザの制限の影響を受けないため、同意が取得されたことを示すための適切な手段です。
監査可能。 選択を時系列で報告でき、特定のイベントに関する問い合わせにも答えられます。
デバイス間の可能性。 ログイン済みの読者については、そのことを説明したうえで、サーバーの記録によってデバイス間で選択を同期できます。

弱み

ローカルの状態の代わりにはならない。 ブラウザ内のタグには、依然として高速でローカルなシグナルが必要です。ページビューごとにサーバーを呼び出して同意を調べると、レイテンシーが増えます。
それ自体が個人データである。 記録には、保持期間、アクセス制御、プライバシー通知内での位置づけが必要です。
識別子への依存。 匿名の訪問者は、デバイスに保存された識別子を通じてしか記録と照合できず、結局ローカルストレージに戻ってきます。

並べて比較した要約

ウェブで選択を記憶するのに最適： ファーストパーティCookie。理想的には、安定した有効期間でサーバーが設定したもの。
ブラウザ内の詳細な設定データに最適： localStorage。サーバーが読み取れるCookieと組み合わせる。
選択の証明に最適： サーバーサイドの記録。
単独の選択肢として最も悪い： localStorageのみに頼ること。サーバーが何も見えなくなり、一部のブラウザでは選択が壊れやすくなります。

実践的な組み合わせのアプローチ

権威あるローカルのシグナル（たとえばTCF文字列とコンパクトな設定記録）を、登録可能ドメインにスコープしたファーストパーティCookieに保存する。
localStorageは、サーバーに届く必要のない補足的なデータにのみ使う。
表示されたバナーとポリシーのバージョンを含め、選択ごとにサーバーサイドの記録を書き込む。
保存された選択が消えた場合は、以前の回答があったと仮定せず、バナーを再表示する。
保存された選択の再確認の期間を設定し、ポリシーに記載する。

訪問者の同意の選択そのものを保存することは、一般に、訪問者が求めたサービス、つまりその決定を記憶することを提供するために必要なものとして扱われますが、主要な市場で適用されるガイダンスを確認してください。

重要なポイント

選択を記憶することと証明することは別の仕事であり、異なるストレージが必要になる。
Cookieはサーバーから読み取れ、サブドメイン間で共有できるが、サイズに制限があり、Safariではスクリプトで設定した場合に有効期間も制限される。
localStorageは容量があるがサーバーからは見えず、ブラウザに消去されることがある。
サーバーサイドの記録は証拠の層であり、ローカルのシグナルの代わりにはならない。
サーバーが設定するファーストパーティCookie、任意のブラウザストレージ、サーバーの記録を組み合わせる。