テクノロジー2026年7月15日 | FlexyConsent

Amplitude プロダクトアナリティクス クッキー同意統合ガイド：2026年実装プレイブック

Amplitudeはモダンデータスタックにおいて独特の位置を占めています。タグマネージャーでも、カスタマーデータプラットフォームでも、マーケティングアナリティクスツールでもありません。デジタルプロダクトとのユーザーのすべてのインタラクションを記録し、それらのイベントをセッションとユーザージャーニーに結び付け、実験・パーソナライゼーション・収益アトリビューションにフィードバックするよう設計された行動アナリティクス製品です。この豊かさがプロダクトの価値の源泉であり、同時に同意をデプロイ時に下すべき最重要の統合意思決定にしています。正しく行えば、Amplitudeは何年にもわたって守りやすいプロダクトインサイトを提供します。誤れば、同じSDKが規制当局の執行リストで最も目につくアイテムの一つになります。同意前に起動する行動アナリティクスSDKは、EDPBのクッキーバナータスクフォース、CNIL、ICOが過去3年間ターゲットにしてきたまさにそのパターンです。

Amplitudeが同意を必要とする理由

デフォルトのAmplitude Browser SDKとAmplitudeモバイルSDKは、ページビューを記録するだけでは済みません。初期化時にファーストパーティストレージにデバイス識別子を設定し、セッション識別子を生成し、リファラーを取得し、URLからUTMとクリック識別子を解析し、オートキャプチャされたイベントのキューイングを開始します。ページビュー、要素クリック、フォームインタラクション、ファイルダウンロード、最新リリースではセッションリプレイも含まれます。またIPベースのジオロケーション、ユーザーエージェントベースのデバイスデータ、設定によってはデータパートナーからのサードパーティエンリッチメントでこれらのイベントを強化します。

これらのステップはそれぞれ別々の同意法的根拠を必要とします。デバイス識別子の保存はePrivacy指令第5条(3)に基づくストレージ・アクセス操作であり、欧州経済領域、英国、同様の基準を導入した法域では事前の自由な、具体的な、情報に基づく明確な同意が必要です。その識別子に紐付いた行動イベントの取得はGDPRに基づく個人データの処理です。サードパーティデータによるエンリッチメントは第二のコントローラー関係を導入します。CCPAとCPRAは同じ処理を、Amplitudeと適切な範囲のサービスプロバイダー契約がない限り、販売または共有として分類します。その契約は広告機能を無効にする設定が施された場合のみ利用可能です。

Amplitudeが同意前に収集するもの — 何を抑制すべきか

最も一般的な実装ミスは、Amplitudeをクッキーバナーと並行して動作できる軽量なアナリティクスツールとして扱うことです。それはできません。デフォルトのamplitude.init()呼び出しでは、ページの最初のペイント時に少なくとも1つのクッキーまたはローカルストレージエントリを書き込み、identify呼び出しを送信し、イベントのバッファリングを開始します。ユーザーが関連する同意カテゴリを明示的に受け入れるまで、これはいずれも許可されません。

準拠した統合では、CMPがアナリティクス同意カテゴリが付与されたことを通知するまでamplitude.init()を遅延させる必要があります。SDKは、CMPがさらすパーポーズ8（アナリティクス）またはパーポーズ1（ストレージとアクセス）シグナルに依存する同意ゲート付き<script>タグからは一切ロードしてはなりません。SDKをより早くロードする必要がある場合（アプリコードにバンドルされておりレイジーフェッチできないなど）、初期化呼び出しにはdefaultTracking: falseとoptOut: trueを渡して同意が記録されるまでイベントを送出しないようにし、遅延opt-inイベントでこれらのフラグを切り替えます。

Amplitudeが書き込むクッキーとストレージ

Browser SDK 2.xはデフォルトでAMP_{apiKey}という名前の単一のファーストパーティクッキーを書き込み、1年の有効期限を持ち、デバイス識別子とセッションメタデータを含みます。古いバージョンはamplitude_id_{apiKey}も書き込んでいました。モバイルSDKはアプリのサンドボックスストレージ内に同じ識別子を保持します。セッションリプレイは2つ目のクッキーAMP_MKTG_{apiKey}を追加し、実験ターゲティングやオーディエンスモジュールが有効な場合、Amplitudeのエンリッチメントパートナーが追加のサードパーティクッキーを設定することがあります。これらはすべて非必須であり、同意が必要です。

Amplitudeを同意フレームワークにマッピングする

AmplitudeはGoogle Consent Mode v2、IAB TCF、IAB Global Privacy Platformをネイティブには実装していません。これは欠陥ではなく、Amplitudeは広告テクベンダーではなくファーストパーティアナリティクスプラットフォームです。しかし統合責任はパブリッシャーにあります。実際に機能するパターンは、各Amplitudeモジュールを個別の同意ゲートとして扱い、CMPがすでに公開している特定のシグナルに紐付けることです。

機能する統合パターン

規制当局のレビューを通過する参照実装には4つの動的要素があります。ユーザーが同意を変更したときリアルタイムイベントを公開するCMP、関連カテゴリのイベント発火後にのみAmplitudeをフェッチする遅延SDKローダー、法律が許す範囲でユーザーの以前の匿名デバイス識別子を失わずにopt-outを尊重するセッションレベルのガード、そして同意に関係なく本当に収集が必要なイベント（セキュリティテレメトリや不正検知など）を独自の法的根拠を持つ別のエンドポイント経由でルーティングするサーバーサイドブリッジです。

Web実装

Webでは、CMPの同意状態をwindow.__cmp_consentオブジェクトまたは標準の__tcfapiコールバックで公開し、小さなブートストラップスクリプトが同意の変更をサブスクライブするのが最もクリーンなパターンです。アナリティクス同意がfalseからtrueに変わったとき、ブートストラップはCMP管理のCDNからAmplitude SDKをフェッチし、amplitude.init(apiKey, undefined, { defaultTracking: true })を呼び出し、同意待機中にメモリにキューされていたイベントをリプレイします。同意がfalseに戻ったとき、ブートストラップはamplitude.setOptOut(true)を呼び出し、document.cookieの期限切れを通じてAMP_クッキーをクリアし、メモリ内の状態を削除します。ブートストラップはバナーレンダリングと同じリクエストフローでAmplitudeをレイジー初期化してはなりません。SDKは明示的な許可を待つ必要があります。

モバイル実装

iOSでは、Amplitudeフレームワークをインポートした状態に保ちつつ、アプリ内同意フローが肯定的なアナリティクスシグナルを返すまでAmplitude.instance().initialize(apiKey: apiKey)を遅延させるのが同等の処理です。ATTプロンプトは別の問題です。ATTはIDFAを管理し、AmplitudeのIDはアプリサンドボックスに保存されたSDK自身のUUIDです。どちらもEEAでは同意が必要ですが、法的根拠とプロンプトは異なります。AndroidではSDKバージョンに応じてAmplitude.getInstance().initializeApolloClient()または同等の呼び出しで同じロジックが適用されます。

サーバーサイドモード

AmplitudeはHTTP V2 APIを介したサーバーサイドインジェスチョンをサポートします。サーバーサイドイベントは同意から免除されません。法的根拠はトランスポートではなくデータに従います。しかしサーバーサイドインジェスチョンはパブリッシャーがどのフィールドを送信するかを完全に制御できるため、部分的な同意を尊重しやすくなります。一般的なパターンは、正当な利益に基づいてサーバーサイドで最小限の必須イベントセットを取得し、クライアントでユーザーがアナリティクス同意を付与した後にのみそれらのイベントを行動詳細でエンリッチすることです。

統合の検証

検証ステップはパブリッシャーが最も頻繁にスキップし、規制当局が最も頻繁に確認するものです。正しく統合されたAmplitudeデプロイメントは4つのチェックをパスする必要があります。第1に、同意バナーが表示されているが選択がなされていないブラウザはapi.amplitude.comまたはapi.eu.amplitude.comへのリクエストをゼロ、document.cookieのAMP_クッキーをゼロにする必要があります。第2に、アナリティクスカテゴリを拒否した場合その状態を維持する必要があります。イベントなし、クッキーなし、AMP_プレフィックスのローカルストレージエントリなし。第3に、アナリティクスを受け入れるとイベントトラフィックに先行して単一のidentifyが生成され、AMP_クッキーはパブリッシャーのCMPポリシーと一致するSameSite属性付きで表示されるべきです。第4に、事後に同意を撤回するとさらなるイベントが即座に停止し、保存された識別子がクリアされる必要があります。遅延したクリーンアップは指摘事項です。

監査証跡は別途重要です。EDPBの2023年クッキーバナーガイドラインと2026年タスクフォースの優先事項の更新に基づき、規制当局はパブリッシャーがAmplitudeプロジェクト内の任意のイベントについて、それを生成したユーザーが取得時点で有効な同意を与えていたことを証明できることを期待しています。そのためにはCMPの同意ログがデバイス識別子またはセッション識別子でクエリ可能であること、そしてAmplitudeイベントペイロードがそのログに紐付く同意バージョンフィールドを持つことが必要です。すべてのイベントにカスタムユーザープロパティとして同意文字列を保存することが、そのリンクを監査可能にする最も簡単な方法です。

適切なリージョンとデータレジデンシーの選択

Amplitudeは米国（api.amplitude.com）とEU（api.eu.amplitude.com）の2つの本番リージョンを運営しています。EEAと英国のトラフィックにはEUリージョンが適切なデフォルトです。データをEEA内に保ち、Schrems II判決とEU-US Data Privacy Frameworkがすべてのアナリティクスレビューの中心にした転送リスクの表面積を縮小します。リージョンの切り替えは遡及的ではありません。既存のデータは最初にインジェストされた場所に残ります。CMPのロールアウトを計画しているパブリッシャーはスケールアップ前にリージョンを確認し、プライバシーポリシーにその選択を記録して収集からストレージまでの法的根拠チェーンを明確にすることが重要です。正しく選択されたリージョンと正しくゲートされたSDK、クエリ可能な同意ログの組み合わせが、Amplitudeデプロイメントを規制リスクからアナリティクススタックの守りやすい部分へと変換します。

← ブログ すべて読む →