マーケティングチームが購読者データを公開せずにAI製アプリをデプロイする方法

セキュリティ研究者のJoel MargolisはWiredに、「マーケティングチームの誰かがウェブサイトを作りたいと思う。その人はエンジニアではなく、おそらくセキュリティの経験も知識もほとんどない」と語りました。同じWiredの記事によると、セキュリティ企業RedAccessは、セキュリティ対策や認証が事実上ない、バイブコーディングで作られたアプリを5,000件以上発見し、その約40％が機密データを公開していました。Wiredは、確認した個人・企業データが本物かどうかは確証を得られませんでした。

マーケティングチーム向けのAI製アプリには、この問題が特有の形で現れます。作る価値のあるツール（セグメント作成、キャンペーンダッシュボード、A/B分析、オーディエンス同期）は、購読者リストに接続され、広告アカウントにも接続されていることが多いためです。

要約

• メール配信プラットフォームのAPIキーと広告アカウントのトークンには、ツールが使う最小限の権限だけを与え、サーバー側のコードに保管します。MailchimpのMarketing APIには権限を絞ったキーがないため、読み取り専用のMailchimp作業には、キーの代わりに必要なデータのみの限定的なエクスポートを使います。
• 購読状態の正本はメール配信プラットフォームに置きます。ツールは配信停止した人を再購読させず、配信停止リクエストをプラットフォームへ渡し、自ら送信するすべてのマーケティングメールに機能する配信停止リンクを含めます。
• ハッシュ化してアップロードしたカスタムオーディエンスも個人データです。広告プラットフォームやAIサービスに何を渡すかを事前に決め、すべての配信停止を広告オーディエンスにも反映します。
• GDPRはリストの保管と利用（漏えい通知、マーケティングに無条件で異議を唱える権利）を規律し、ePrivacy/PECR、CAN-SPAM、CASLはメール送信を規律します。社内ツールから送信する場合も同じです。

購読者データの漏えいや同意違反を招くデプロイのミス

AI製マーケティングツールがリストで問題を起こすパターンは主に2つです。リストが外部に出る（キー、公開リンク、アップロード経由）か、拒否した人への利用に使われるかです。管理権限付きの広告トークンには、会社の広告アカウントで支出が発生するという別のリスクもあります。

アプリを作ったAIコーディングツールに依頼すれば、これらの修正の多くを実行できます。以下の各プロンプトは状況に合わせる出発点とし、使うものはAIツールが毎セッション読むルールファイルに保存してください。AIが変更したと報告するだけでは証拠になりません。各プロンプトの下の確認：手順が証拠です。推測せず不確実な点を示すよう求め、有効なキーや購読者のエクスポートをチャットに貼り付けないでください。

完全アクセスのメールプラットフォームキーを最小権限のキーに替える

件数だけを表示するセグメント作成ツールには、リストをエクスポートしたりキャンペーンを送ったりできるキーは不要です。しかし下記の各プラットフォームの最も広いキーには両方が可能です。保管場所も重要です。ブラウザーのコードは呼び出しにキーの値自体を必要とするため、ページを読み込む誰もが読めます（MailchimpはAPIのクライアント側利用を一切サポートしていません）。

各行は各プラットフォーム自身の文書に基づきます。MailchimpのAPIキーのヘルプ、SendGridのAPIキー権限、Klaviyoの認証ガイド、MailgunのAPIキー文書です。Listmonkの権限は後述のListmonk節で説明します。

ツールには仕事に必要な最小権限のキーを渡すか、キーを渡しません。Mailchimpの読み取り専用作業（レポート、セグメント件数）には、プラットフォーム自体のレポート機能か、アカウント所有者が必要なフィールドだけを限定してエクスポートする方法が適しています。ただし人の時間が必要で、データの鮮度はそのエクスポート時点までです。変更・送信作業はITに回すか、Mailchimp内で行います。ActiveCampaignやBrevoなど他のプラットフォームでは、まず制限付きキーがあるか調べます。

キーはサーバー側コード（ブラウザーがダウンロードしないツール自身のバックエンド）だけに置き、環境変数として保管します。これは起動時にサーバーからアプリへ渡す値で、コードとリポジトリからは除外します。

このプロジェクトでメールプラットフォーム（Mailchimp、Klaviyo、SendGrid、Mailgun、Listmonkなど）と広告プラットフォーム（Meta、Google Ads、LinkedInなど）に使う、すべてのAPIキー、アクセストークン、パスワード、シークレットを探してください。ローカルのシークレットスキャナーかIT承認済みの方法で、コード、環境ファイル、リポジトリ履歴を調べてください。生のシークレット値、環境ファイルの内容、認証情報を含む履歴は外部AIサービスに送信しないでください。AIに渡すのは、ファイルの場所と見つかった認証情報の種類を含む、秘匿化済みの調査結果だけにしてください。それぞれについて次を報告してください。

- ファイルと行番号

- 値がコードに直接書かれているか、環境変数から読み込まれるか

- 使用するコードがサーバーで動くか、ブラウザーで動くか

値は先頭4文字だけを表示してください。完全なキーやトークンを出力しないでください。

メール送信、購読者の変更、広告アカウント管理が可能な認証情報は最優先としてください。

次に、秘密APIキーやアクセストークンが必要な呼び出しをすべてサーバー側コードへ移し、サーバー専用の環境変数から認証情報を読み込んでください。ブラウザーには文書で認められた公開クライアント側API呼び出しだけを残し、露出した秘密キーをコードから取り除き、本物のシークレットを含むファイルをリポジトリから除外してください。変更を正確に報告し、推測せず不確実だった箇所を示してください。

注：貼り付けたキーをチャットやコードから削除しても、共有を取り消したことにはなりません。失効させ（プラットフォームの設定で無効にして動作を止め）、新しいキーを作成してください。

確認：ツールを開き、F12を押してNetworkタブを選び、チームと同じように操作しながら各リクエストのドメインを読みます。メールプラットフォームの非公開APIを直接呼ぶブラウザーリクエストは警告の兆候ですが、宛先だけでシークレットの露出は証明できません。値をAIチャットにコピーせず、リクエストヘッダーとコードに秘密の認証情報がないか確認します。公開クライアント側SDKのリクエストは別で、秘密APIキーではなく公開識別子を正当に使う場合があります。Klaviyoではa.klaviyo.com/client/へのリクエストは公開キーを使い、ブラウザーでの利用が適切です。一方、ブラウザーからa.klaviyo.com/api/へのリクエストは調査が必要です。このエンドポイントは通常、秘密キーによる認証が必要なためです。実際に秘密の認証情報が送信されたかを確かめてください。

残りは人が担当します。個人に属さないアカウントから権限を絞ったキーを作り（Mailchimpはユーザーのアクセス権を取り消すとそのユーザーのAPIキーを削除します）、ツールの名前を付け（Mailchimpは連携ごとに1キーを推奨）、ITの助けを借りてツールのキー保管場所に保存します。計画的なローテーションでは、古いキーを失効させる前に新しいキーへ切り替えてください。失効したMailchimpキーは再有効化できません。侵害済みのキーは直ちに失効・交換します。有効期限も計画してください。2026年6月22日以降に生成されたMailchimp APIキーは作成から1年で期限切れになります。

広告アカウントのトークンには使う権限だけを与える

広告アカウントのトークンは支出に直結するため、マーケティングツールが持つ認証情報の中で最も影響が大きいと私は考えています。管理権限のあるMetaトークンは、会社の広告アカウントに請求されるキャンペーンを作成・変更・停止でき、支出と成果を読むこともできます。

そのトークンで取得できないのが、カスタムオーディエンスへアップロードした購読者リストです。Metaのカスタムオーディエンスガイドでは、人の追加と削除にSHA-256ハッシュ値（各アドレスを一方向に変換し、プラットフォームが自身の記録と比較する値）を使います。既存オーディエンスから読めるリストを返すエンドポイントは文書化されていません。

Metaの権限リファレンスは各権限を説明し、アプリに必要なものだけを選ぶよう開発者に求めています。各ツールはシステムユーザーから専用トークンを取得し、そのツールが扱う広告アカウントだけを割り当てます。これはソフトウェアが使うBusiness Manager内のアカウントを指すMetaの用語です。作成者個人のログイントークンはツールに入れず、システムユーザーのトークンはメールキー同様にサーバーに置きます。Google AdsやLinkedInへのアクセスも同様に棚卸しします。

このツールがMeta Marketing API、Google Ads、その他の広告プラットフォームに行う呼び出しを、補助ライブラリやSDK経由のものも含めてすべて列挙してください。各呼び出しについて次を示してください。

- ファイルと行番号

- エンドポイントまたはSDKメソッド

- ラベル：REPORT（指標や支出の読み取り）、MANAGE（キャンペーン、広告、予算、オーディエンスの作成・変更）、LEADS（リードフォーム回答の読み取り）のいずれか

- そのラベルに必要なプラットフォームの権限

複数のツールで共有するトークンと、トークンをブラウザーへ送るコードを指摘してください。トークンの値は出力しないでください。どのラベルが必要か判断できない呼び出しは、その旨を示してください。

確認：トークンが持つ権限を報告するMetaのトークンデバッグツールでダッシュボードのトークンを調べ、プロンプトのラベルと比較します。レポート用ダッシュボードならads_readが表示され、アカウントを管理する権限はないはずです。レポートツールにMANAGEやLEADSのラベルが付くなら要対応です。次にビジネス設定で、作成者個人のものではなくシステムユーザーのトークンを使っていることを確認します。

公開アドレスを閉じ、購読者の行はリスト管理者だけに見せる

AIツール自身のホスティング上にあるアプリは、アドレスを見つけた誰もが開けます。Wiredによると、RedAccessが調査したアプリの一部には、訪問者がどのメールアドレスでもサインインできるといった軽微な障壁しかありませんでした。そのようなホスティングは架空のアドレスでのデモに適しており、それこそが無料ホスティングやトンネルの用途です。

もう半分の問題は、入った後で誰に何を見せるかです。キャンペーンダッシュボードの仕事は、開封率、クリック率、A/B結果、セグメント規模といったキャンペーン単位の数値です。その裏にある各アドレスと同意詳細・反応履歴を含む購読者の行は個人データです。

適切に匿名化された集計数値は一般に個人データではありませんが、小さいセグメントや細かい内訳から個人を特定できることはあります。匿名の数値でも会社の競争上の情報を明かすことがあり、個人ごとの開封やクリックを保存するA/B分析ツールも個人データを保持します。チームには集計を見せ、行を見られるのはリストの管理者だけにし、サーバーが全リクエストで強制します。

このアプリのデータベース、画面、エクスポート、APIレスポンスで、購読者の個人データを保持する全フィールドを列挙してください。メールアドレス、氏名、電話番号、郵便住所、IPアドレス、所在地、購読状態、同意の取得元と日時、購読日、配信停止状態、個人ごとの開封とクリックです。各フィールドについて、表示される画面とエクスポートを示してください。推測せず不明な点を明示してください。

次に、サインイン済みアカウントから取得する2つのロールを追加し、各ページ、エクスポート、APIルートでサーバー側から確認してください。

- リスト管理者：購読者の行を閲覧し、エクスポートできる

- マーケター：キャンペーン単位の数値、セグメント件数、A/B結果のみ閲覧でき、個人の行もエクスポートも不可

それ以外は「アクセス拒否」（403）で拒否してください。各ページとルートをどのチェックが保護するか報告してください。

保存データがディスク上で暗号化されているかはITに確認すべき事項です。AIツールはコードを読んでも確認できません。

確認：マーケターロールのテストアカウントを作成します。そのアカウントでサインインし、キャンペーンダッシュボード（読み込める）、購読者リストページとエクスポート（どちらも「アクセス拒否」になる）を順に開きます。次に、サインアウトした状態でモバイル通信のスマートフォンからツールのアドレスを開きます。何も読み込めないか、会社のサインインページで止まるはずです。

配信停止と同意記録はメールプラットフォームに任せる

リストの独自コピーを保持し、双方向同期や先月のエクスポートの再インポートで書き戻すツールは、配信停止した人を再び購読中にし、どこで・いつ・どう登録したかの記録を失わせる可能性があります。通常、次のキャンペーンがその人に届くまで兆候はなく、届いた時点で後述の送信規則が適用されます。次の4つのルールで防げます。

1. 購読状態の正本はメールプラットフォームです。ツールはその状態を読み、既存購読者を再購読させたり上書きしたりしません。明示的な配信停止リクエストは、プラットフォーム所定の配信停止処理へ渡せます。
2. 一括インポートや同期で既存購読者の記録を置き換えたり、購読・同意情報を上書きしたりしません。レビュー済みのツールは、タグなど明示的に許可されたフィールドを購読状態を変えずに更新できます。新規登録はプラットフォーム自体の登録フォームやインポート経路を通し、そこでオプトイン処理を適用します。ツール独自の登録フォームもレビュー後なら取得元・日時・フォームとともに新規購読者を追加できますが、既存の連絡先を再購読させたり、その購読・同意情報を上書きしたりしてはいけません。
3. ツールからの送信やエクスポートは、その都度プラットフォームから状態を読み、独自コピーを使いません。エクスポートでは配信停止・配信除外済みの連絡先を省くか、送信には決して使わない送信禁止リストとして明示します。
4. ツールがコピーする記録には同意フィールド（取得元、日時、フォームまたは方法）をそのまま付けます。そうしないなら、その情報はコピーせず、保持しているとも主張しません。

ツールがメールプラットフォームや購読者リストのコピーに書き込む場所をすべて列挙してください。購読者を作成・更新するAPI呼び出し、インポート、同期、ファイルのエクスポートです。それぞれが次を行えるか示してください。

- 既存購読者の購読状態を変更する

- 既存購読者の記録を上書きする

- 配信停止・配信除外済みの連絡先を含める

メール送信や送信用リストのエクスポートを行うすべての経路について、購読状態をその時点のメールプラットフォームから読むか、ツール独自のコピーから読むか示してください。

次に、既存連絡先を再購読させず、購読状態も上書きしないよう変更してください。ただし明示的な配信停止リクエストをメールプラットフォーム所定の処理へ渡す場合は除きます。既存購読者の記録を丸ごと置き換えず、送信・エクスポートの直前にメールプラットフォームから状態を読み、コピーする記録には同意の取得元・日時・フォームを保持してください。変更点と不確実な点を報告してください。

注：古いエクスポートをリストに再インポートすると古い状態も戻るため、プラットフォームとツールのインポート処理によっては、そのエクスポート後に配信停止した人が購読中に戻る可能性があります。

確認：メールプラットフォームにテスト購読者を追加し、そこで配信停止します。ツールの同期、セグメント作成、エクスポートを実行します。プラットフォームではテスト購読者が引き続き配信停止で、ツールのエクスポートには含まれないか送信禁止と表示され、ツールが作るどの送信リストにも現れないことを確認します。

メールプラットフォームから送るか、先に配信停止経路を作る

SMTPアカウントやトランザクションメールAPIでリストに直接再アプローチメールを送るツールには、メールプラットフォームがマーケティングメールに加えるもの（配信停止リンク、郵便住所、配信除外チェック）がありません。コードでそれぞれ加える必要があります。解決策は、ツールでセグメントを作るかプラットフォームのキャンペーンを起動し、送信をプラットフォーム（またはListmonk）に任せることです。単独送信が必要なツールは送信ツールであり、次節ではITへ回します。

そのツールには、下の送信法令表の期限に従い、送信後も機能する配信停止リンクをすべてのマーケティングメールに設け、フッターに送信者の身元と郵便住所を載せる必要があります。独自の配信除外リストも必要で、毎回の送信前に確認し、永続的な除外記録として保管します。バックアップと復元手順では、古い購読者データベースが新しい配信停止を上書きしないようにします。CAN-SPAMではトランザクションメッセージの扱いが異なります。

大量送信者は、フッターのリンクだけでは足りない場合があります。Gmailは、個人のGmailアカウントに1日5,000件以上を送る送信者に対し、マーケティングメールと購読メッセージへのRFC 8058準拠ワンクリック配信停止対応を要求しています。見える配信停止リンクに加え、List-UnsubscribeとList-Unsubscribe-Postのメールヘッダーを追加するという意味です。ワンクリックのエンドポイントはPOSTリクエストを処理し、GETでURLを開いただけでは配信停止させないようにします。その規模で送る前にITに要件を確認してもらってください。

このツールが送るすべてのマーケティングメッセージに配信停止リンクと、その先の配信停止エンドポイントを追加してください。
Gmailの大量送信者要件が適用されるなら、有効なDKIM署名の対象となるRFC 8058ワンクリック配信停止ヘッダーと、POSTベースのエンドポイントも実装してください。URLを開いただけで配信停止しないでください。不確実な点はITレビュー向けに明示してください。
配信停止エンドポイントが有効なリクエスト（リンクのクリック、フォーム送信、API呼び出し）を受け取ったら：

- 購読者テーブルとは別に保管した配信除外リストへ、直ちにアドレスを追加する

- リクエストの日時と受信経路を記録する

- メールプラットフォームがリストを保持する場合、そこにもアドレスの配信停止を伝える

毎回の送信前に配信除外リストを確認し、一致するアドレスは除いてください。インポート、同期、データベース復元でアドレスを配信除外リストから自動削除しないでください。会社承認の保存方針に従い、配信停止を守るのに必要な最小限の除外情報だけを保管し、インポートや同期で除外済みアドレスを再追加させないでください。バックアップに除外リストを含め、購読者テーブルを復元しても変更されないようにしてください。私が埋めるプレースホルダーを使い、すべてのマーケティングメッセージのフッターに送信者名と郵便住所を追加してください。変更と対象の送信を報告してください。

確認：管理できるシードアドレスをテストリストに加え、ツールからテストキャンペーンを送り、届いたメッセージ内の配信停止リンクをクリックします。そのアドレスが配信除外リストに載ること（プラットフォームがリストを持つなら、そこでも配信停止になること）を確認します。同じテストリストに再送し、シードアドレスには何も届かないことを確かめます。

会社のメールコンプライアンス責任者が、プレースホルダーに入れる送信者名と郵便住所を提供します。

広告プラットフォームやAIツールへ渡すデータを送る前に決める

初期設定のまま購読者データを外へ送るコード経路は2つです。MetaやGoogleのカスタムオーディエンスへセグメントをアップロードする同期と、件名作成やリード評価のためAI APIへ、または分析スクリプトやWebhookへ購読者フィールドを渡す呼び出しです。

MetaとGoogleは、SHA-256でハッシュ化した連絡先識別子で顧客オーディエンスを照合できます。GoogleのData Manager APIは、送信前にメールアドレスと電話番号を正規化しハッシュ化することを要求します。一方、Google Adsの画面経由の一部アップロードは処理中にハッシュ化できます。ハッシュ化はアドレスをプロフィールと照合する仕組みで、人を匿名にはしません（FAQ参照）。

新しいGoogle Customer Match連携では、同期を作る前に対応するアップロードAPIを確認してください。2026年4月1日以降、Googleは新規利用者の旧Customer Matchアップロード方法を制限し、Data Manager APIへ案内しています。

Metaの顧客リストオーディエンス規約は、データ共有に必要な権利、許可、法的根拠を持つことを広告主に保証させます。GoogleのCustomer Matchポリシーは、プライバシーポリシーで共有を開示し、法律が求める場合は同意を得ることを要求しています。

簡素化のため、このツールではすべての配信停止を広告照合停止の要求としても扱います。これは保守的な社内方針であり、特定チャネルのメール配信停止が常に全広告オーディエンスからの削除を法的に要求するという主張ではありません。

したがってアップロード経路は、会社が広告照合用に承認したセグメントだけを対象にします。会社は、プライバシー責任者または任命済みのデータ保護責任者（DPO）がいればその助言のもと、適切な法的根拠を確立する必要があります。配信停止・配信除外済みの連絡先はどのアップロードにも含めず、配信停止を受けたらハッシュ値で各オーディエンスから削除します（理由は後述のGDPR節）。

購読者データを受け取るすべてのAI・分析サービスには会社の承認が必要です。個人データの共有前に、提供者が処理者か独立した管理者かを確認し、必要な場合のデータ処理契約など適切な契約上の保護を整えてください。

このツールの外向きの呼び出しをすべて監査してください。メールプラットフォーム、広告プラットフォーム（オーディエンスのアップロードを含む）、AI API（OpenAI、Anthropicなど）、分析ツール、Webhookです。各呼び出しで、リクエスト本文やURLに現れる購読者フィールドを正確に列挙してください。もっと少ないフィールドや、購読者データなしで目的を果たせる呼び出しを示してください。最後に外部サービスをすべて名前で列挙し、承認済み業者と照合できるようにしてください。

確認：レポートにあるAI・分析サービス向けの各購読者フィールドは業務上必要なもので、各サービスは会社の承認済みリストにあるはずです。未承認のものは業者との契約担当者に回します。

このツールでMeta、Google Ads、その他の広告プラットフォームへ連絡先をアップロードする各経路について：

- 各プラットフォームの正規化規則に従い、アップロード前にサーバーでメールアドレスと電話番号をSHA-256でハッシュ化する

- [会社が広告照合用に承認したセグメント]の連絡先だけをアップロードする

- アップロード時点で配信停止・配信除外済みの連絡先を除く

- 連絡先が配信停止したら、アップロード先の全オーディエンスにそのハッシュ値の削除を送る

- すべてのアップロードと削除について、日時、オーディエンス、連絡先件数、実行したユーザーまたはジョブを記録する

変更点を報告し、不確実な点を明示してください。

確認：アップロードしたセグメントに属するテスト連絡先を配信停止します。次の同期後、関係するすべてのオーディエンスに削除リクエストが送られたか確認します。ツールが記録・送信しただけでなく、各広告プラットフォームが削除を正常に処理したことも確認します。失敗や一部完了の削除は、再試行とITレビューのために明示します。

リストへの操作内容でツールの実行場所を決める

キャンペーン数値だけを表示するツールは、チームが管理するサーバーで動かし、プライベートネットワークからだけ到達できるようにします。購読者の行を見せるものには、ロールに必要な会社のサインインを加えます。マーケティングメールを送る、または広告オーディエンスを同期するツールは、プラットフォーム自身の機能で行うか、誰かが使う前にITに回します。

承認は各行に応じます。2つの読み取り専用の行はメールプラットフォーム管理者によるキー発行、リスト変更の行は別の確認者、送信の行はITが必要です。オーディエンスのアップロードにはプライバシーレビューも必要です。

プライベートネットワークとは、外部からのアクセスにツールが一切応答しないことです。AIが書いたログインページには誰もが到達でき、強さは背後のコード次第です。RedAccessが、どんなメールアドレスでもログインできるアプリを見つけたのはそのためです。

私のルールは、まずプライベートネットワークを使い、ロールに必要な場所ではさらに会社のサインインを追加することです。ログインとシークレット保管を内蔵するマネージドデプロイ基盤も、既に契約して業者をレビューしているチームには使えます。

サーバー側はITに協力を依頼する部分で、サーバーとキーの責任者を1人明確にします。ツールはVPS（チームが全面管理するレンタルサーバー）で、CoolifyやDokployのようなデプロイツールのもとで動きます。デプロイツールはコードからアプリを動かし、プラットフォームキーを含む環境変数を保管します。

プライベートネットワークは、構築が速いものの自身の調整サービスに依存するTailscale（Headscaleで置き換え可能）か、完全にセルフホストするWireGuardで用意します。会社のサインイン（会社アカウントによるシングルサインオン）にはAuthentikやKeycloakを使い、ウェブに面する場所はリバースプロキシ（CaddyやNginx Proxy Manager）でHTTPS化します。

メールエンジンをListmonkへ移す

現在のプラットフォームでキーを絞る代わりに、リストと送信をセルフホスト型リスト管理ソフトへ移し、商用プラットフォームのキーをなくす方法もあります。Listmonk（v4.0.0以降）なら各ツールに独自APIユーザーを設け、リストロールで対象リストだけに制限できます。

読み取り専用ツールには対象リストの閲覧権限を与え、送信は許可しません。campaigns:sendとtx:send（トランザクションメッセージ）は送信ツールだけに与えます。制限付きツールのロールからは、特に危険な3つの権限を外してください。リスト単位のロールを上書きするlists:get_allとlists:manage_all、そしてsubscribers:sql_queryです。Listmonkのロールと権限の文書は最後の権限について「個別のリストと購読者の権限に優先して、データベースから直接すべてのリストと購読者を問い合わせられる」と警告しています。リストに制限されたツールと呼ぶ前に、subscribers:get_all、campaigns:get_all、campaigns:manage_allなど広い権限も確認してください。各APIユーザーには業務上必要な権限だけを与えます。Listmonkは多段階の自動化ではなくキャンペーン向けです（Listmonkが適さない場合）。その種の自動化は同様のサーバーでMauticが担えます。

代償は継続的な作業です。送信ドメインの認証（SPF、DKIM、DMARC）、配送用SMTPリレー、パッチ、バックアップ、到達性をチームが管理します。リストが小さい、サーバーの責任者を置けない、現在のプラットフォームの送信評判や自動化がチームの仕事を支えている場合は、既存プラットフォームでキーを絞る方が適切です。

どちらの方法にも担当者のいるサーバーが必要で、デプロイツールとプライベートネットワークを動かし、セルフホストならListmonkとSMTPリレーも動かします。当社のLinux VPSはrootアクセスを提供し、Listmonk、Mautic、Tailscale、WireGuard、Authentikをワンクリックアプリとしてデプロイできます。ITはインストールより設定とレビューに時間を使えますが、継続的なパッチ適用はチームの担当です。

拠点にはEUのフランクフルトとアムステルダム、英国ロンドン、米国の複数都市があります。選ぶ場所がツールとリストのコピー（Listmonkではリスト自体）の保存先を決めます。所在地はDPOとの相談材料であり、相談の代わりでも、それだけでツールを準拠させるものでもありません。

マーケティングメールの同意と迷惑メール対策規則

購読者リストに対するGDPR

GDPRは、ダイレクトマーケティングの処理根拠として必ず同意を要求するわけではありません。前文47は、その処理を「正当な利益のために行われるとみなすことができる」としています。代わりに同意を根拠とする場合、第7条は、各人が同意したことを会社が「証明できる」ことと、同意と同じ容易さで撤回できることを要求します。それがメールプラットフォームにある同意の取得元と日時の役割です。

より厳格なのがGDPR第21条です。根拠を問わず、本人は関連するプロファイリングを含めダイレクトマーケティングにいつでも異議を唱えられ、その後は「その目的で個人データを処理してはならない」とされます。同条の他の異議と違い、マーケティングには利益衡量がありません。このツールの最も安全な初期方針は、一般的なダイレクトマーケティングへの異議を、その人のデータのマーケティング用途全体（送信リスト、ツールのセグメント、広告オーディエンス）に適用することです。特定チャネルの配信停止は範囲が狭い場合があるため、会社はプライバシー責任者と希望設定の規則を定め、各要求を適切に守る必要があります。

漏えいや誤変更されたリストは個人データ侵害になり得ます。第33条は、個人にリスクを生じさせる可能性が低い場合を除き、不当な遅滞なく、可能なら認知から72時間以内に監督機関（国のデータ保護規制当局）へ通知することを要求します。英国の相当法はUK GDPRで、ICOが執行します。

送信法令：ePrivacyとPECR、CAN-SPAMとCASL

EUのePrivacy規則と英国PECRは、個人へのマーケティングメールに事前同意を要求し、既存顧客に限定的な「ソフトオプトイン」を認めます。英国には特定条件付きで慈善目的用の別のソフトオプトインもありますが、この記事は商業マーケティングに焦点を当てます。カナダCASLは明示または黙示の同意を要求します。米国CAN-SPAMは送信同意を求めませんが、10営業日以内に履行する有効な配信停止手段と、各メッセージの正確な送信者情報・郵便住所を要求します。

ePrivacy指令第13条のソフトオプトインは、販売時に取得した連絡先を自社の類似商品に使い、取得時と毎回のメッセージで無料の拒否機会を提供する場合を対象とします。英国版はPECR規則22で、ICOのメールマーケティング指針に説明があります。第13条は、送信者を偽装したり有効な配信停止要求先アドレスがなかったりするマーケティングメールも禁止します。英国ではPECR規則23が同様の規定です。

CAN-SPAMの金額はFTCのCAN-SPAMガイドによります。同ガイドは配信停止したアドレスの売却・譲渡も禁止していますが、CAN-SPAM遵守の支援を依頼した会社への提供は例外です。CASLの規則はCASL第6条と第11条、罰則はISEDのCASL概要に記載されています。

よくある質問

自作したニュースレターツールにもGDPRは適用されますか？

決めるのは会社の活動場所とツールが誰のデータを保持するかであり、作り方ではありません。第3条により、GDPRはEUに拠点を持つ会社と、EU外でもEU内の人に商品・サービスを提供したり、そこでの行動を監視したりする会社に適用されます。個別の会社が対象かはDPOに確認します。

KlaviyoのAPIキーが漏れたらどうなりますか？

Full Accessキーの保有者はリストを変更でき、Read-Onlyキーなら閲覧だけが可能です。ツールが使うスコープだけを持つ代替キーを作り（Klaviyoでは後から既存キーにスコープを追加できません。今選んでください）、漏れたキーを直ちに失効させ、ツールを新キーへ切り替え、身に覚えのないエクスポートやリスト変更を確認します。リストが読まれた可能性があれば、GDPR侵害の可能性として扱います。

ハッシュ化したメールリストも個人データですか？

GDPRでは、人と結び付けられるなら個人データです。前文26は、「追加情報を利用して自然人に帰属させられる」仮名化データを、識別可能な人に関する情報として扱います。私の解釈では、広告照合が機能するのもまさにそのためです。プラットフォームは既に持つアドレスから同じハッシュを計算できます。

B2Bのマーケティングメールも同じ規則に従いますか？

地域によります。FTCによるとCAN-SPAMは企業間メールを例外にしません。PECRのメール規則は個人を対象とし、ICOは企業へのマーケティングメールを送れるとしています。EU各国とカナダについては法律顧問に相談してください。