Segmentが実際に行うこと

Segment SDK（cdn.segment.com/analytics.jsから読み込まれる）は、グローバルなanalyticsオブジェクトを初期化し、ajs_anonymous_idというSegment所有のクッキーで訪問者を識別します。アプリケーションコードはanalytics.identify()、analytics.track()、analytics.page()、analytics.group()を呼び出し、SDKは各呼び出しをSegmentのインジェストエンドポイントに転送します。そこからSegmentはイベントを展開し、リアルタイムまたはバッチで、ソースで有効化されているすべてのデスティネーション（Google Analytics、Facebook Pixel、Customer.io、Iterable、Amplitude、Mixpanel、Snowflake、BigQueryなど数十のサービス）に送信します。

ダウンストリームデスティネーションへの各転送は、GDPRの観点から見ると個別の処理活動です。イベントをGoogle Analyticsに送信する法的根拠は、同じイベントをCustomer.ioに送信する法的根拠とは異なり、同じイベントをSnowflakeウェアハウスに書き込む法的根拠とも異なります。単一の「マーケティングに同意する」と記録する同意バナーでは、デスティネーションのカテゴリ分類が同意のカテゴリ分類と一致しない限り、これらすべてを正当に承認することはできません。

Segmentのネイティブ同意プリミティブ

Segmentは過去2年間、同意管理プリミティブに大きく投資してきました。2026年現在、プラットフォームは同意の実施に関する3つの重要な機能を提供しています。

Consent Management（旧Consent Stamping）

Consent Management機能を使用すると、Segmentが取り込むすべてのイベントに同意ペイロードを付加できます。このペイロードには、ユーザーが承認した処理カテゴリ（通常はIAB TCF v2.3文字列、GPP文字列、またはカスタムSegmentカテゴリ分類）が記録されます。ダウンストリームデスティネーションは、各イベントの同意状態に基づいて転送またはブロックするよう構成できます。

同意ゲーティング付きデスティネーションフィルター

デスティネーションフィルターを使用すると、各イベントが特定のデスティネーションに転送される前に実行される小さなJavaScriptまたはLua式を記述できます。フィルターは同意ペイロードを検査し、該当するカテゴリが付与されていない場合は転送を中止できます。これは、きめ細かいデスティネーション単位の同意実施に適したプリミティブです。

ソースレベルのintegrations設定

より大まかな制御には、ソースレベルのintegrationsオブジェクトで、イベント単位でデスティネーションを完全に無効化できます：analytics.track(event, properties, { integrations: { "All": false, "Segment.io": true } })。これは全か無かのケースに有用ですが、カテゴリレベルの粒度にはうまく対応できません。

ステップバイステップのCMP統合

信頼性の高いアーキテクチャは、CMPのカテゴリ判断をSegmentのデスティネーションカテゴリ分類にマッピングし、すべてのイベントに同意ペイロードを付加し、デスティネーションフィルターを使用してデスティネーション単位のゲーティングを実施するものです。

1. デスティネーションのカテゴリ分類

Segmentワークスペースで有効化されているデスティネーションのリストを確認し、各デスティネーションをCMPカテゴリに割り当てます。Google Analytics、Mixpanel、Amplitudeなどのデスティネーションは通常「アナリティクス」に分類されます。Facebook Pixel、TikTok、Pinterestなどのデスティネーションは通常「マーケティング」に分類されます。SnowflakeやBigQuery（自社ウェアハウス）などのデスティネーションは通常「必須」または「機能」に分類されますが、ウェアハウスのダウンストリームで処理されるアナリティクスも正しくカテゴリ分類されている場合に限ります。このマッピングをレビュー可能な場所に文書化してください。監査防御はこれに依拠します。

2. 同意判断が取得されるまでSDKの初期化を遅延させる

Segment SDKは、analytics.load()が呼び出されるまでイベントを送信しないよう構成できます。CMPがユーザーの判断を取得するまでload呼び出しを遅延させ、同意前にイベントが発火しないようにします。あるいは、イベントハンドラー自体に同意状態ゲーティングを組み込んだanalytics.ready()キューイングパターンを使用することもできます。

3. すべてのイベントに同意ペイロードを付加する

Consent Management機能を構成して、取り込まれるすべてのイベントにIAB TC string、GPP文字列、またはカスタムカテゴリ分類をスタンプします。このスタンプはSegmentのパイプラインを通じてイベントとともに移動し、デスティネーションフィルターで利用可能になります。

4. カテゴリレベル実施のためのデスティネーションフィルターを記述する

各デスティネーションに対して、同意ペイロードをそのデスティネーションが必要とするカテゴリと照合するフィルターを記述します。ユーザーがマーケティングを承認しアナリティクスを拒否した場合、マーケティングカテゴリのデスティネーションはイベントを受信し、アナリティクスカテゴリのデスティネーションはサイレントにドロップされます。フィルターロジックは通常、event.context.consent.categoryPreferencesまたは同意ペイロードスキーマの同等のパスから読み取ります。

5. 同意の取り消しを伝播させる

ユーザーが同意を取り消した場合、2つのことが必要です。SDKが取り消されたカテゴリで新しいイベントの送信を停止すること（ソースレベルのintegrationsトグルで処理）と、ダウンストリームデスティネーションの既存ユーザープロファイルを更新または削除する必要があることです。SegmentのPrivacy APIは削除リクエストと抑制フラグの両方をサポートしています。取り消し時にCMPが適切なPrivacy APIエンドポイントを呼び出すよう構成してください。

よくある落とし穴

4つの統合ミスが、Segmentデプロイメントにおける監査所見の大部分を占めています。

Segmentを単一のトラッカーとして扱う

最も一般的な欠陥は、Segmentを単一のカテゴリ（通常はアナリティクス）でゲーティングし、それがダウンストリームのすべてを満たすと想定することです。実際にはそうなりません。Facebook Pixelがデスティネーションとして有効化されている場合、Facebookに転送されるイベントにはアナリティクスではなくマーケティングカテゴリの同意が必要です。デスティネーション単位のカテゴリ分類は必須です。

ウェアハウスデスティネーションの見落とし

多くのチームがSnowflakeやBigQueryをSegmentのデスティネーションとして有効化し、「社内インフラだから」としてウェアハウスを免除扱いにしています。ウェアハウス自体は社内かもしれませんが、その後の処理（BIダッシュボード、類似モデリング、顧客セグメンテーション）はマーケティングやアナリティクスの機能に供給されます。ウェアハウスの同意カテゴリ分類は、ウェアハウスデータが最終的に流入する最も許容度の高い用途を反映すべきです。

同意コンテキストのないサーバーサイドソース

Segmentはサーバーサイドソース（バックエンドがSegmentを直接呼び出す方式）をサポートしています。これらのソースからのイベントは、ブラウザ側の同意状態を自動的に継承しません。アプリケーションはイベント送信時にユーザーの同意状態を参照し、呼び出しに付加する必要があります。これがないと、サーバーサイドイベントはCMPを完全にバイパスしてしまいます。

クロスソースID統合の無視

SegmentのID解決は匿名プロファイルと識別済みプロファイルを統合し、ウェブ、モバイル、サーバーサイドのソース間でこれを実行できます。これらの面で同意状態が異なる場合、統合されたプロファイルはデフォルトで最も許容度の高い解釈を継承します。統合されたIDに対して最も許容度の高い同意状態ではなく、最も制限的な同意状態を使用するようID解決を構成してください。

監査チェックリスト

EU、UK、またはカリフォルニアのトラフィックに接するSegmentデプロイメントに対して回答すべき6つの具体的な質問です。

• デスティネーションのカテゴリ分類は文書化されているか？ 有効化されているすべてのデスティネーションに対して、どのCMPカテゴリがゲーティングしているかの記録はあるか？
• SDKは同意を待機しているか？ プライベートウィンドウでページを開き、バナーが承認される前にanalytics.track呼び出しがapi.segment.ioに発火していないことを確認する。
• 同意ペイロードはすべてのイベントにスタンプされているか？ Segmentデバッガーで取り込まれたイベントのサンプルを検査し、同意ペイロードが存在し完全であることを確認する。
• デスティネーションフィルターはカテゴリを尊重しているか？ CMPでカテゴリを無効化すると、そのカテゴリのデスティネーションにイベントが転送されなくなることを確認する。
• サーバーサイドソースは同意を保持しているか？ サーバーサイド呼び出しが送信時にユーザーの現在の同意状態を参照し付加していることを確認する。
• 取り消し時にPrivacy APIが発火するか？ CMPによって引き起こされた取り消しが、ローカルSDKのオプトアウトだけでなく、Segmentの抑制または削除APIを呼び出していることを確認する。

同意ファーストスタックにおけるSegmentの位置づけ

CDPはプライバシーアーキテクチャにおいて最もレバレッジの高いポジションを占めています。CMPバナーでの単一の判断が、それぞれ独自の法的姿勢を持つ数十のダウンストリームデスティネーションに伝播する必要があるからです。正しいアーキテクチャは、CMPをユーザーのカテゴリ選好の信頼できる情報源として扱い、Segmentが取り込むすべてのイベントにその情報を付加し、Segmentのデスティネーションフィルタープリミティブを使用して各個別デスティネーションではなくルーティングレイヤーでカテゴリレベルのゲーティングを実施するものです。正しく行えば、エンジニアリング作業はデスティネーション数に対して線形にスケールします。新しいデスティネーションの追加はカテゴリ分類の決定とフィルタールールであり、ゼロからの統合ではありません。誤って行うと、CDPはプライバシーの増幅器となり、手動監査が追いつくよりも速く、同意違反のイベントを多数のパートナーに転送してしまいます。