sent-routing-strategist

Sent ルーティング戦略ガイド

Sent で最もコストのかかる誤解が生じるのは、ルーティングです。ほとんどの判断を左右する事実は、次の 2 つです。

1. channel 配列はブロードキャストリストであり、優先順位ではありません。 受信者が 2 人いる場合、["whatsapp", "sms"] を指定すると 4 件のメッセージが作成され、4 件分の料金が発生します。fallback フィールドも、優先順位を指定する構文もありません。
2. 自動ルーティングがフォールバックの仕組みです。 channel を省略するか、["sent"] を指定すると、プラットフォームがルートを選択し、ルートレベルの障害が発生した場合は、異なるチャネルとプロバイダーの組み合わせを最大 3 つ試して再ルーティングします。

channel の値を決める

意図	正しい値	理由
最適な方法で受信者に届ける	channel を省略するか、["sent"]	ルート選択と再ルーティングが有効になります
特定のチャネルを確実に使う	["sms"]、["whatsapp"]、または ["rcs"]	チャネルを固定すると、そのチャネルに一致するルートに限定され、別のチャネルには切り替わりません
同じ内容を複数のチャネルで意図的に配信する	["whatsapp", "sms"]	ブロードキャストです。組み合わせごとに 1 件のメッセージと 1 件分の料金が発生します
「RCS を試し、失敗したら SMS に切り替える」	channel を省略するか、["sent"]	順序付き配列ではブロードキャストになります。自動ルーティングがフォールバックを実行します

sent、sms、whatsapp、rcs 以外の値を指定すると、400 が返されます。順序付きフォールバックを求められた場合は、コードを書く前にこの誤解を明確に説明してください。失敗するとエラーではなく、重複配信と二重のコストが発生するためです。

チャネルを固定すると失われるもの

チャネルを固定すると、ルートの照合対象が指定したチャネルに限定されます。チャネル制約のないルールは引き続き一致し、固定したチャネルに解決されるため、チャネル固有のルールが存在する必要はありません。チャネルを固定した送信は別のチャネルに切り替わりませんが、ルールで許可されていれば、同じチャネル内でプロバイダーを切り替えることはあります。固定したチャネルにルートがない場合、メッセージはルートが一致しなかったため FAILED となり、暗黙にフォールバックすることはありません。

コンプライアンス、契約、またはコンテンツ上の制約により特定のチャネルが必要な場合は、チャネルを固定してください。それ以外の場合は、自動ルーティングを優先してください。

結果を確認する

POST /v3/messages は、受信者ごとの message_id 値とともに 202 を返します。自動ルーティングの場合、受信者ごとに返されるチャネルは確定したルートではなく、後から更新されることもありません。実際の状況は、次の情報から確認してください。

確認事項	根拠
実際に試行されたルート	message.routed イベント、またはルーティング後に GET /v3/messages/{id} で取得した channel
受信者のデバイスに届いたか	message.delivered
試行されたルートの順序	GET /v3/messages/{id}/activities
停止した理由	終了ステータスとチャネルの値

終了ステータスの解釈

ステータス	意味	適切な対応
FAILED	ルートの試行に失敗しました。自動ルーティングでは、次の試行がまだキューに追加される場合があります	最終結果として扱う前に、最新のメッセージ状態とアクティビティを確認してください
FILTERED	ポリシーによるブロックです。配信同意の拒否、またはルートの拒否です	再試行しないでください。配信同意の拒否はコンプライアンス上の停止です
BLOCKED	アカウントの前提条件を満たしていません。残高、オンボーディングのクォータ、未承認のテンプレートなどです	アカウントの条件を修正してから、もう一度送信してください
SCHEDULED	配信可能時間のポリシーにより保留されています	待機してください。メッセージは自動的にパイプラインに戻ります

channel が auto の結果は、ルートの試行が始まる前にメッセージが終了したことを意味します。原因は、一致するルートがないこと、テンプレートパラメーターが無効であること、配信同意によるブロック、またはアカウントの前提条件です。アカウントの前提条件は送信リクエストを拒否しません。リクエストは 202 で受け付けられ、影響を受けたメッセージは BLOCKED として表示されます。

Sent は、これらのケースについて送信時の理由コードをメッセージに内部記録しますが、API レスポンスや Webhook では返しません。そのため、診断にはステータスとチャネルの組み合わせ、およびアクティビティ履歴を利用します。確認可能な情報と根本原因の対応表は、references/routing-diagnosis.md にあります。

再ルーティングの動作

ルートの失敗が再試行されるのは、終端エラーが、別のルートなら解消できる可能性のあるルートまたはキャリアの問題を示している場合に限られます。該当するのは、このルートでは配信不能、プロバイダーのサービス停止、プロバイダーのタイムアウト、またはトランスポートエラーです。それ以外のエラーはすべて FAILED のままになります。

再ルーティングでは**同じ message_id**を再利用してパイプラインを再実行するため、message.queued と message.routed が再び発火し、同意ゲートが毎回適用され、すでに試行したルートは除外されます。初回送信とすべての再ルーティングを合わせて、異なるチャネルとプロバイダーの組み合わせは最大3つです。

お客様からよく尋ねられるWhatsAppからSMSへの動作は、この具体例です。WhatsAppメッセージが受け付けられた後、受信者側の理由で失敗すると、再ルーティングが行われ、その番号にはWhatsAppで配信できないという受信者単位のルールが記録されます。そのため、その受信者への以後の自動送信ではWhatsAppがスキップされます。この動作には自動ルーティングが必要です。WhatsAppを固定した送信では発生しません。

自動ルーティングでのルート選択方法

ルートは、送信時にプラットフォームが管理するルールによって、受信者の属性（国、番号のプレフィックス、正確な番号、キャリア、番号の種類、番号ポータビリティの状態）、送信者、テンプレートの属性、チャネル、および宛先が国際宛てかどうかを基に評価されます。優先順位は、受信者との完全一致ルール、アカウント単位のルール（グローバルルールより先）、一致の具体性、ルールの優先度、番号プレフィックスの長さ、ルールの古さの順です。無効、削除済み、期限切れ、およびしきい値未満のルールは除外されます。テンプレートのそのチャネルに対する審査ステータスが明示的に未承認である候補は除外されますが、審査記録のないチャネルはブロックされません。残った候補のうち最初のものが選択され、残りはフォールバックルートとして使用可能な状態で残ります。

チャネルの固定された優先順位はないため、「まずRCS、次にWhatsApp、最後にSMS」のような説明は決してしないでください。特定のルートが選ばれた理由について説明する前に、references/routing-model.mdをお読みください。

コストと送信量への影響

一斉送信では受信者数に応じてメッセージ数が増えるため、複数チャネルの配列を送信する前に、予想コストを確認してください。1,000人の受信者に2つのチャネルで送信すると、メッセージ数は2,000件です。1リクエストあたりの受信者数の上限は1,000人です。また、200リクエスト／分の上限内に収めるため、ドキュメントで推奨されているペースは、最大件数のバッチをおよそ1秒に1リクエストで送信することです。

現在、RCSではテキストと最大4つの候補チップが送信でき、テンプレートのボタンから割り当てられます。また、送信するRCSメッセージにはすべてSTOPチップが追加されます。リッチカード、カルーセル、メディアに依存するRCS固定のフローは設計しないでください。

範囲

確認を伴う単一の送信には sent-messaging を、同意と受信キーワードの仕様には sent-two-way-messaging を、配信率の集計上の低下の分析には messaging-performance-analyzer を使用してください。また、このスキルで説明するイベントの受信と重複排除には sent-webhook-engineer を使用してください。