本番送信前におけるTCPAおよびCASLの権利対応

本番送信前におけるTCPAおよびCASLの権利対応。

絶対的な本番ゲートとしての同意のエビデンス

オプトイン検証とオプトアウトの仕組みを単なる到達率の指標として扱うことは、重大なアーキテクチャ上の誤りです。北米の電気通信法において、同意は最適化スコアではなく、送信のためのバイナリの前提条件です。暗号学的に検証可能な同意記録なしに本番SMSキャンペーンを開始すると、米国の電話消費者保護法(TCPA)およびカナダのスパム対策法(CASL)に基づく法定罰則にプラットフォームがさらされます。

法的差異：TCPAの明示的な書面による同意とCASLの明示的・黙示的同意

TCPAは、すべての自動プロモーションSMSトラフィックに対して事前の明示的な書面による同意を義務付けており、特定番号への自動発信メッセージを許可する明確な書面による合意を要求します。一方CASLは、明示的同意(取り消されない限り有効)と、既存の事業関係(EBR)から派生する黙示的同意(厳格な6ヶ月または24ヶ月の期限付き)を区別しています。

ハードウェアレベルのSTOP受信処理とWebhook実行

オプトアウトのコンプライアンスは、下流の顧客ロジックに委ねるのではなく、プラットフォーム境界で強制されなければなりません。STOP、UNSUBSCRIBE、CANCEL、QUIT、ARRETなどの標準化されたキーワードを含むインバウンドMO SMSが割り当てられたE.164ルートに到達すると、コアプラットフォームは直ちにサプレッションレジストリで受信者をフラグ付けします。IOSORはサブスクライバーへ自動的に「Verify OK」確認を実行し、同時に運用エンドポイントへリアルタイムのWebhookを発信します。

大規模なテナント分離と台帳のガードレール

キャリアコンプライアンスを維持しながらサプレッション状態のテナント間漏洩を防ぐには、厳格なマルチテナント分離が必要です。オプトアウトテーブルはテナントIDごとにパーティション分割され、あるクライアントのSTOPイベントが別のクライアントの認可されたトランザクションOTPフローを妨げないようにします。すべてのルーティングと番号プロビジョニングは厳格なJITモデルに従い、番号はプリペイドのホールドおよびアサインルーチンを介して有効化され、MRC台帳から直接控除されます。

本番検証アーキテクチャとコンプライアンスリンク

トラフィックをステージングから本番に移行する前に、コンプライアンスチームはすべての専用仮想番号でドライランのオプトアウトアサーションを実行する必要があります。インバウンドのSTOP Webhookが500ミリ秒以内にクライアントのCRMレコードを更新し、キャリアDLRレポートが抑制された宛先を正確に反映していることを確認してください。スタックを強化するために、当社のテクニカルアーキテクチャを確認してください：

関連ガイド: 送信キュー滞留後のSTOP処理：配信を偽装せずスキップする原則 · STOP および HELP ポリシーはインボックスルーティングではない · 初回引き落とし前のプリペイド残高確保.

IOSORで始める

IOSORコンソールへアクセスし、インバウンドのキーワードWebhookを設定のうえ、ライブトラフィック送出前に同意台帳の検証を完了させてください。STOP、CANCEL、ARRETの各キーワードを送信するドライランを実施し、割り当てられたE.164ルーティングにおいて500ミリ秒未満での配信停止反映を確認します。すべての対象テナントにおいて下流への漏洩が一切ないことがコンプライアンスのドライランで証明されるまで、本番環境のゲートは必ずロックした状態を維持してください。

IOSORの要点

配信停止の遵守および同意の検証は、送信後の到達率最適化ではなく、妥協を許さないアーキテクチャ上のゲートです。TCPAやCASLの枠組みのもとでは、事前の書面による明示的な同意の検証を怠ったり、インバウンドのSTOPシグナル処理をイングレス層で遅延させたりすると、プラットフォームの経路は即座にキャリアブロックの対象となり、重大な法的ペナルティに直面します。

プラットフォームの境界でハードウェアレベルのキーワード実行を強制しつつ、テナントごとの配信停止台帳を確実に分離してください。本番トラフィックの開始後に非同期データベースのポーリングやアプリケーションレベルのバッチ処理に依存してオプトアウトシグナルを処理することは避けてください。