翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# 電話プールを使用した RCS から SMS へのフォールバック
<a name="rcs-sms-fallback"></a>

電話プールは、AWS RCS エージェントや SMS 電話番号などのメッセージング ID のコンテナであり、API リクエストと基盤となる発信元 ID の間に抽象化レイヤーを提供します。プールは、設定の変更、番号タイプの移行、および RCS-to-SMSフォールバックを簡素化します。プールに 1 回の API コールを送信すると、 AWS エンドユーザーメッセージングがチャネル選択を処理します。

この章では、RCS 配信が失敗する方法、SMS フォールバックを可能にする理由、フォールバックロジックと優先順位、請求への影響について説明します。また、pool-per-use-caseベストプラクティスと、プールから AWS RCS エージェントを追加および削除する方法についても説明します。電話プールの一般的な情報については、「」を参照してください[AWS エンドユーザーメッセージング SMS の電話プール](phone-pool.md)。AWS RCS エージェントの管理については、「」を参照してください[RCS エージェントの管理](rcs-agents.md)。

**Topics**
+ [RCS 配信が失敗する方法](#rcs-sms-fallback-how-rcs-fails)
+ [SMS フォールバックを可能にするもの](#rcs-sms-fallback-what-makes-possible)
+ [プールを使用する理由](#rcs-sms-fallback-why-pools)
+ [Pool-per-use-case モデル](#rcs-sms-fallback-pool-per-use-case)
+ [アカウントレベルの送信によるコンプライアンスリスク](#rcs-sms-fallback-compliance-risk)
+ [フォールバックロジックと優先順位](#rcs-sms-fallback-logic)
+ [SMS フォールバックの請求への影響](#rcs-sms-fallback-billing)
+ [SMS フォールバックのテスト](#rcs-sms-fallback-testing)
+ [プールでの AWS RCS エージェントの管理](#rcs-sms-fallback-pool-management)

## RCS 配信が失敗する方法
<a name="rcs-sms-fallback-how-rcs-fails"></a>

RCS 配信は、いくつかの理由で失敗する可能性があります。これらの障害モードを理解することは、フォールバック戦略を計画するのに役立ちます。
+ **キャリアは RCS をサポートしていません** — 受信者のモバイルキャリアがネットワークで RCS メッセージングを有効にしていません。
+ **デバイスは RCS をサポートしていません** — 受信者のデバイスには RCS 機能がありません (古い Android デバイスや 18 より前の iOS を実行している iPhone など）。
+ **エージェントはキャリアでアクティブではありません** — AWS RCS エージェントは受信者のキャリアによってまだ承認されていないか、エージェントがその国の PARTIAL ステータスです。
+ **デバイスに一時的に到達できない** — 受信者のデバイスは RCS をサポートしていますが、一時的にオフラインであるか、データ接続がありません。RCS メッセージには、配信用のデータ接続が必要です。

これらの条件のいずれかが発生し、プールベースまたはアカウントレベルの送信を使用している場合、 AWS End User Messaging は、同じプールまたはアカウントの電話番号を使用して SMS 配信に自動的にフォールバックします。

## SMS フォールバックを可能にするもの
<a name="rcs-sms-fallback-what-makes-possible"></a>

SMS フォールバックには、AWS RCS エージェントと、同じプール内の少なくとも 1 つの SMS 電話番号の両方が必要です。プールにメッセージを送信すると、 AWS End User Messaging は最初に RCS 配信を試みます。RCS 配信が失敗した場合、サービスは同じプールの電話番号を使用して SMS 経由でメッセージを再試行します。AWS RCS エージェントのみを持つプール (電話番号なし) は、SMS フォールバックをサポートしていません。RCS が失敗した場合、メッセージは配信されません。

**重要**  
SMS フォールバックが機能するには、プールに AWS RCS エージェントと 1 つ以上の SMS 電話番号の両方が含まれている必要があります。単一の ID タイプのみを持つプールは、クロスチャネルフォールバックを提供しません。

## プールを使用する理由
<a name="rcs-sms-fallback-why-pools"></a>

RCS だけでなく、すべてのメッセージングユースケースに電話プールを使用することをお勧めします。プールには以下の利点があります。
+ **自動 SMS フォールバック** — プールに AWS RCS エージェントと SMS 電話番号の両方が含まれている場合、 AWS エンドユーザーメッセージングは最初に RCS 配信を試みます。RCS 配信が失敗した場合 (受信者のデバイスやキャリアが RCS をサポートしていない場合など）、サービスは同じプールの電話番号を使用して SMS 経由でメッセージを自動的に再試行します。アプリケーションにフォールバックロジックを実装する必要はありません。
+ **インテリジェントルーティング** — サービスは、送信先、チャネルの可用性、スティッキー送信履歴に基づいて、プールから最適な送信元 ID を選択します。このルーティングは、`SendTextMessage`呼び出しごとに透過的に行われます。
+ **単一 API コール** — プール ID を`SendTextMessage`リクエストの送信元 ID として指定します。このサービスは、追加のロジックなしで RCS または SMS 経由で配信するかどうかを決定します。
+ **将来の変更に対する柔軟性** — アプリケーションコードを変更することなく、いつでも電話番号と AWS RCS エージェントをプールに追加または削除できます。たとえば、SMS フォールバックに通話料無料番号を追加したり、送信統合を変更せずに 10DLC 番号をスワップアウトしたりできます。
+ **コストや欠点なし** — プールを作成して送信元 ID を追加しても、追加料金は発生しません。単一の電話番号または単一の AWS RCS エージェントを使用しても、プールを使用すると、アプリケーションを変更せずに後で ID を柔軟に追加できます。

**注記**  
メッセージングには、常にプールを使用することをお勧めします。単一の送信元 ID であっても、プールの使用にコストや欠点はありません。RCS-to-SMS フォールバックの場合、プールには AWS RCS エージェントと少なくとも 1 つの SMS 電話番号の両方が含まれている必要があります。最初からプールを開始すると、送信コードを変更せずに SMS フォールバック番号または追加の AWS RCS エージェントを後で追加できます。

## Pool-per-use-case モデル
<a name="rcs-sms-fallback-pool-per-use-case"></a>

ユースケースごとに 1 つのプールを作成することをお勧めします。各プールには、すべての電話番号と、単一のメッセージング目的を果たす AWS RCS エージェントが含まれている必要があります。例えば、次のようになります。
+ AWS RCS エージェントとトランザクションメッセージングに登録された 10DLC 番号を含む、OTP コードとアカウント通知のトランザクション**プール**。
+ 同じ AWS RCS エージェント (または別のエージェント) と**、マーケティングに登録された通話料無料番号を含むプロモーションメッセージのマーケティングプール**。
+ AWS RCS エージェントと予約関連のメッセージ専用の電話番号を含む、通知をスケジュールするための予約**リマインダープール**。

このモデルにより、RCS 配信が失敗し、サービスが SMS にフォールバックすると、フォールバックメッセージが、同じユースケースに登録および承認された電話番号から送信されます。これにより、メッセージングは通信事業者の要件と登録条件に準拠し続けます。

## アカウントレベルの送信によるコンプライアンスリスク
<a name="rcs-sms-fallback-compliance-risk"></a>

アカウントレベルでメッセージを送信する場合 (プールや発信元 ID を指定しない）、 AWS End User Messaging はアカウントで使用可能なすべての ID から発信元 ID を選択します。アカウントに異なるユースケース用に複数の電話番号が登録されている場合、サービスはメッセージの内容と一致しない電話番号を選択することがあります。

**重要**  
ユースケースが混在したアカウントレベルの送信では、コンプライアンスリスクが発生します。例えば、アカウントに OTP メッセージに登録されている 10DLC 番号と、予約リマインダーに登録されている通話料無料番号がある場合、SMS にフォールバックする OTP メッセージは、予約リマインダーの通話料無料番号から送信できます。これは、その番号の登録条件に違反し、キャリアのフィルタリングや番号の停止につながる可能性があります。

このリスクを回避するには、ユースケースごとに 1 つのプールでプールベースの送信を使用します。`SendTextMessage` リクエストでプール ID を指定すると、サービスはそのプールから発信元 ID のみを選択します。プール内のすべての ID が同じユースケースに登録されるため、フォールバックメッセージは常に適切な番号から送信されます。


**送信アプローチのコンプライアンス比較**  

| 送信アプローチ | SMS フォールバック動作 | コンプライアンスリスク | 
| --- | --- | --- | 
| プールベース (推奨) | 同じユースケースに登録されている同じプール内の電話番号にフォールバックする | 低 — フォールバック番号がメッセージのユースケースと一致する | 
| アカウントレベル | アカウントで使用可能な電話番号にフォールバックします。 | 高 — 複数のユースケースがアカウントを共有する場合、フォールバック番号がメッセージのユースケースと一致しない場合がある | 
| Direct (AWS RCS エージェント ARN) | SMS フォールバックなし | なし — メッセージは RCS 経由でのみ配信されるか、まったく配信されません | 

## フォールバックロジックと優先順位
<a name="rcs-sms-fallback-logic"></a>

 AWS End User Messaging は、メッセージの発信元 ID (プールまたはすべてのアカウント ID) を選択すると、次の優先順位で ID を評価します。

1. **スティッキー ID** — 送信先の電話番号にスティッキー送信ペアが存在し、ID がまだ利用可能な場合、サービスはその ID を使用します。

1. **AWS RCS エージェント** — スティッキーペアが存在しない場合、サービスは使用可能な AWS RCS エージェントを介した RCS 配信を試みます。

1. **SMS ショートコード** — RCS が使用できない場合、サービスは SMS ショートコードを選択します。

1. **SMS 10DLC** — ショートコードがない場合、サービスは 10DLC 番号を選択します。

1. **SMS 通話料無料番号** — 10DLC 番号が利用できない場合、サービスは通話料無料番号を選択します。

1. **SMS 送信者 ID** — 他の ID が利用できない場合、サービスは送信者 ID を選択します。

この優先順位は、使用する送信パターンの範囲内で適用されます。プールベースの送信の場合、サービスは指定されたプール内の ID のみを考慮します。アカウントレベルの送信の場合、サービスはアカウント内のすべての ID を考慮します。

### 自動 SMS フォールバック
<a name="rcs-sms-fallback-automatic"></a>

プールまたはアカウントレベルでメッセージを送信すると、RCS 配信が不可能な場合、 AWS End User Messaging は自動的に SMS にフォールバックします。フォールバックは非同期です。

 AWS End User Messaging が RCS メッセージを正常に送信したが、25 秒以内に配信確認または失敗シグナルを受信しない場合、サービスは SMS にフォールバックします。これにより、RCS インフラストラクチャがメッセージを受け入れても配信が停止するケースが処理されます (たとえば、受信者のデバイスが一時的に到達できない、キャリアが RCS をサポートしていない、デバイスが RCS に対応していないなど）。

**注記**  
直接送信 (発信元 ID として AWS RCS エージェント ARN を指定) は、自動 SMS フォールバックをサポートしていません。SMS フォールバックが必要な場合は、プールベースの送信を使用します。

### スティッキー送信
<a name="rcs-sms-fallback-sticky"></a>

スティッキー送信は、配信の一貫性を向上させるルーティングの最適化です。 AWS End User Messaging が特定の発信元 ID を使用して送信先電話番号にメッセージを正常に配信すると、サービスはそのペアリングを 25 時間記憶します。25 時間以内の同じ送信先への後続のメッセージは、プールまたはアカウントで引き続き使用できる場合、同じ送信元 ID を介してルーティングされます。

スティッキー送信は、RCS 配信と SMS 配信の両方に適用されます。たとえば、メッセージが AWS RCS エージェントを介して RCS 経由で配信された場合、25 時間以内に同じ宛先への次のメッセージも同じエージェントを介して RCS 経由で試行されます。前のメッセージが SMS 経由で配信された場合 (RCS フォールバック後）、次のメッセージは同じ電話番号を介して SMS 経由で試行されます。

スティッキー ID が SMS 電話番号であっても、サービスは RCS 配信を定期的に再試行します。これにより、デバイスが RCS サポートを受ける受信者は (キャリアのロールアウトやデバイスのアップグレード後など）、手動で介入することなく RCS メッセージの受信を開始できます。

スティッキー送信の主な特徴:
+ **25 時間 TTL** — スティッキーペアリングは、最後に正常に配信されてから 25 時間後に期限切れになります。有効期限が切れると、サービスは次のメッセージの発信元 ID 優先度の順序を再評価します。
+ **自動 RCS 再試行** — スティッキー ID が SMS 電話番号であっても、サービスは定期的に RCS 配信を試みて、受信者が RCS をサポートするようになったかどうかを確認します。
+ **手動フラッシュなし** — スティッキー送信ペアリングを手動でフラッシュまたはリセットすることはできません。ペアリングは 25 時間の TTL の後に自動的に期限切れになります。

### フォールバック中の配信受信
<a name="rcs-sms-fallback-delivery-receipts"></a>

SMS フォールバックが発生すると、 AWS End User Messaging はメッセージを配信した最終チャネルの単一の配信受信を生成します。RCS フォールバック後にメッセージが SMS 経由で配信された場合、配信受信は SMS を配信チャネルとして示します。

通常の状況では、 AWS エンドユーザーメッセージングは、SMS フォールバックメッセージが配信される前に RCS メッセージを取り消します。これにより、受信者が同じメッセージを 2 回受信できなくなります。ただし、まれに、RCS メッセージと SMS フォールバックメッセージの両方が配信される場合があります。これは、25 秒のタイムアウトの後、失効が完了する前に RCS メッセージが配信された場合に発生する可能性があります。このようなまれなデュアル配信シナリオでは、両方のチャネルの配信受信を受け取ることがあります。

デュアル配信が請求に与える影響については、「」を参照してください[RCS の請求と料金モデル](rcs-billing.md)。

## SMS フォールバックの請求への影響
<a name="rcs-sms-fallback-billing"></a>

メッセージが RCS から SMS にフォールバックすると、失敗した RCS 試行ではなく、SMS 配信に対して課金されます。RCS メッセージは、受信者のデバイスに正常に配信された場合にのみ請求されます。RCS 配信が失敗し、メッセージが SMS にフォールバックする場合は、そのメッセージの SMS 料金を支払います。

まれにデュアル配信シナリオ (RCS メッセージと SMS フォールバックメッセージの両方が配信される場合) では、両方の配信に対して課金される場合があります。請求の詳細については、「」を参照してください[RCS の請求と料金モデル](rcs-billing.md)。

## SMS フォールバックのテスト
<a name="rcs-sms-fallback-testing"></a>

SMS フォールバック動作をテストして、RCS 配信が不可能な場合にメッセージが SMS 経由で配信されることを確認できます。SMS フォールバックをテストするには、承認済みの SMS 電話番号があるかどうかに応じて、2 つの方法があります。

### 承認された SMS 番号を使用しないテスト
<a name="rcs-sms-fallback-testing-without-sms"></a>

 AWS エンドユーザーメッセージングが、承認された SMS 電話番号なしでフォールバックメカニズムを正しくトリガーしていることを確認できます。承認された番号がない場合でも、SMS 経由で再試行イベントと失敗イベントを確認できます。これにより、フォールバックが機能していることを確認できます。

**承認された SMS 番号なしで SMS フォールバックをテストするには**

1. モバイルデータと Wi-Fi を無効にするか、飛行機モードを有効にして、テストデバイスをオフラインにします。

1. AWS RCS エージェント ARN を発信元 ID とする `SendTextMessage` API を使用して、テストデバイスに RCS メッセージを送信します。

1. CloudWatch またはイベント送信先のメッセージイベントを確認します。RCS 配信が不可能であり、サービスが SMS フォールバックを試みたことを示す配信失敗イベントが表示されます。

フォールバックに使用できる SMS 電話番号がないため、SMS 配信も失敗します。ただし、イベントは、 AWS エンドユーザーメッセージングがフォールバックメカニズムを正しくトリガーしたことを確認します。

### 承認された SMS 番号を使用したテスト
<a name="rcs-sms-fallback-testing-with-sms"></a>

end-to-endの SMS フォールバックテストを完了するには、承認された SMS 電話番号と AWS RCS エージェントを同じ電話プールに追加します。これにより、RCS が利用できないときにメッセージが SMS 経由で配信されることを確認できます。

**承認された SMS 番号を使用して SMS フォールバックをテストするには**

1. AWS RCS エージェントと承認された SMS 電話番号 (10DLC、通話料無料、ショートコード番号など) の両方を含む電話プールを作成します。

1. モバイルデータと Wi-Fi を無効にするか、飛行機モードを有効にして、テストデバイスをオフラインにします。

1. プール ID を発信元 ID とする `SendTextMessage` API を使用してメッセージを送信します。

1. メッセージが SMS 経由でテストデバイスに配信されていることを確認します。

1. 配信イベントをチェックして、メッセージが RCS フォールバック後に SMS チャネルを介して配信されたことを確認します。

## プールでの AWS RCS エージェントの管理
<a name="rcs-sms-fallback-pool-management"></a>

AWS RCS エージェントを使用してプールを作成する手順、既存のプールにエージェントを追加する手順、プール設定要件を理解する手順、およびプールからエージェントを削除するstep-by-stepについては、「」を参照してください[プールでの AWS RCS エージェントの管理](phone-pool-rcs-agents.md)。