# SMSルートテストの仕組み

ルートテストとは、指定した日に、指定した市場の指定した端末へ、指定したルートで実際のコンテンツを送信し、何がいつ届いたかを記録するものです。テストが証明するのは、その時点のその端末でのそのルートの結果です。すべての端末、すべてのネットワーク、翌週の結果を証明するものではありません。

- ルートテストが証明するのは、ある市場のある時点で、指定した端末における指定したルートの結果です。

- テストは、すべての端末、すべてのネットワーク、将来の性能を証明するものではありません。

- 有用なレポートには、コンテンツ、端末、ルート、配信レシートの状態、日付が記載されています。

- 失敗は、その時点のルート、送信者、または端末のいずれかを指し示します。

## テストが証明すること

ルートテストが答えるのは限定された問いです。このコンテンツを、この送信者から、このルートで、この市場のこれらの端末へ今日送信した場合、何が届き、どれだけ時間がかかるか。その答えは、その組み合わせについての根拠になります。カバレッジの主張でも、予測でもありません。端末が変わる、市場が変わる、ルートが変更されるといった違いがあれば、結果も変わる可能性があります。
この限定性こそが価値です。端末、コンテンツ、日付を明記したテストは、繰り返して比較できます。到達率のパーセンテージだけを報告するテストでは、それができません。生の記録を求めてください。端末に表示された送信者文字列、配信レシートの状態、送信から配信レシートまでの時間、そしてフローに必要な場合は返信経路です。
テストの前に問いを書き出してください。「このルートは、この送信者からのOTPを、この市場の一般的な端末へ10秒以内に届けられるか」といった問いからは、使える結果が得られます。「このルートは良いか」という問いからは、意見しか得られません。

### ルートテストで記録する項目

| 確認項目 | テストで記録する内容 | 証明しないこと |
| --- | --- | --- |
| 配信 | 端末、市場、送信者、コンテンツ、配信レシートの状態 | その市場のすべての端末でメッセージが表示されること |
| 時間 | 送信から配信レシートまで（中央値と95パーセンタイル） | すべてのネットワーク、すべての時間帯の遅延 |
| 送信者 | 端末に表示された文字列 | ルート変更後もその文字列が維持されること |
| 返信 | 返信経路、返信時間、内容 | すべての受信ルートが機能すること |
| コンテンツ | 正確なテンプレート、エンコーディング、セグメント数 | すべてのフィルターがそれを通過させること |
| 再テスト | 日付と条件 | 翌月にそのルートがどう動作するか |

機種ごとに1台の端末はサンプルであり、全数調査ではありません。

## テストの実施方法

まず問いについて合意します。新しいルート、新しい送信者、新しい市場、既存ルートの変更のうち、どれを確認するのか。その問いによって、端末、コンテンツ、送信回数が決まります。次に、その市場を代表する端末を選びます。複数の機種を選び、ルートが複数のネットワークにまたがる場合は複数のネットワークを含め、トラフィックの大半を運ぶと想定されるネットワークの端末を少なくとも1台含めます。
コンテンツを固定します。実際に送信するテンプレートを使い、リンク、変数、GSM-7とUCS-2のどちらになるかを決める文字も含めます。すべての端末に同じコンテンツを送信し、送信時刻、配信レシートの時刻、状態を記録し、生データを保管します。フローに返信が必要な場合は、各端末から返信を送り、届くまでの時間を記録します。テストは閑散時間帯だけでなく、トラフィックが想定される時間帯にも実施してください。

### テストの手順

1. **問いについて合意する**

ルート、送信者、市場を明記します。合格がどのような状態かを書き出します。

2. **端末を選ぶ**

複数の機種を選び、該当する場合は複数のネットワークを選びます。機種とネットワークを記録します。

3. **コンテンツを固定する**

実際に送信するテンプレートをそのまま使います。エンコーディングとセグメント数を記録します。

4. **送信して記録する**

送信時刻、メッセージID、ルートを記録します。送信ごとにコンテンツを変えないでください。

5. **配信レシートを読む**

状態、エラーコード、完了時刻を記録します。配信済みの状態は、表示の確認ではありません。

6. **別のルートで繰り返す**

比較が必要な場合は、同じコンテンツを別のルートで実施します。変数は一度に1つだけ変えます。

7. **限界を書く**

テストが対象としなかった端末、市場、時間帯、コンテンツ、日付を明記します。

### サンプルレポートの内容

| 項目 | 内容 |
| --- | --- |
| 範囲 | ルート、送信者、市場、日付 |
| 方法 | 端末の選び方とコンテンツの固定方法 |
| 結果 | 端末ごとの配信状態、配信までの時間、送信者文字列 |
| 返信 | フローに返信が必要な場合の返信経路と時間 |
| 失敗 | 配信レシートの状態、エラーコード、端末 |
| 根拠 | 生の記録と使用したコンテンツ |
| 限界 | テストが証明しないこと、再テストすべき時期 |

コンテンツ、端末、日付のないレポートは、ただの話にすぎません。

## 失敗の読み解き方

配信レシートがないことと、配信レシートが失敗を示すことは同じではありません。配信レシートがない場合、記録が届かなかったことを意味し、メッセージ自体は端末に届いている可能性があります。失敗を示す配信レシートには状態が含まれ、多くの場合、理由を示すネットワークコードも含まれます。たとえば、加入者不明、加入者不在、メモリ不足、サービス規制（バーリング）です。ルートを変更する前にコードを読んでください。
配信済みを示す配信レシートがあるのに表示されない場合は、別の確認が必要です。端末、メッセージアプリ、迷惑メッセージフォルダー、送信者文字列を確認します。返信が届かない場合は、送信側の経路ではなく、受信ルートまたは送信者の種類が原因であることを示しています。結果が遅い場合は、ルート、キュー、またはスロットリングされたバインドが原因であることを示しています。根拠が示す段階を修正してください。
失敗も、合格と同じ項目で記録します。端末、市場、送信者、コンテンツ、ルート、時刻、状態です。これらの項目がない失敗記録は次回の実施結果と比較できません。そして修正が証明されるのは、その次回の実施です。

## レポートを信頼する前に確認すること

日付、端末、ネットワーク、正確なコンテンツを確認してください。どのルートがトラフィックを運んだか、それが直接接続かアグリゲーター経由かを確認してください。パーセンテージだけでなく、配信レシートの状態とエラーコードを求めてください。テストが対象としなかったこと、いつ再テストすべきかを確認してください。
そのうえで、レポートを自社のトラフィックと比較します。1台の端末でのテストに合格しても、別の機種、別のネットワーク、より長いテンプレートでは本番で失敗することがあります。[ルートテストのサンプルレポート](/ja/resources/downloads/route-test-sample-report/)で記録の形式を確認できます。[プロバイダー選定ガイド](/ja/resources/learn/how-to-choose-an-a2p-sms-provider/)は、結果を次のサプライヤーへの質問に落とし込みます。

最新の市場一覧はルールツールで確認してください。一覧はツールのページにのみ掲載しています。

### Check what you learned

**メキシコシティの1台の端末にテストで配信できました。何を証明したことになりますか？**

このルート、送信者、コンテンツが、その日にその市場のその端末に届いたことです。ほかの端末、ほかのネットワーク、翌週の結果は証明していません。

**配信レシートがありません。メッセージは失われたのでしょうか？**

必ずしもそうではありません。配信レシートの記録がなくても、メッセージは届いている可能性があります。再送する前に、端末とプロバイダーの記録を確認してください。

**ルート変更後には何を再テストしますか？**

新しいルートで、同じ問い、コンテンツ、端末を使って再テストします。判断が比較に左右される場合は、比較用に別のルートも加えます。

## FAQ

**テストには何台の端末が必要ですか？**

ローンチにとって重要な機種とネットワークを代表できるだけの台数です。1台の端末はサンプルであり、全数調査ではありません。

**テストで到達性を証明できますか？**

証明できるのは、その時点でテストした端末への配信です。市場全体の到達性を確認するには、本番トラフィックでの継続的な計測と繰り返しのテストが必要です。

**テストにはどのくらい時間がかかりますか？**

送信自体は数分で終わります。返信の収集と限界の記述にはそれより時間がかかります。テストを始める前に範囲について合意してください。

**テストで2社のプロバイダーを比較できますか？**

はい。両方のテストで同じコンテンツ、端末、市場、時間帯を使えば比較できます。変数は一度に1つだけ変えてください。

**テストが失敗した場合はどうすればよいですか？**

まず配信レシートの状態とエラーコードを読みます。次に送信者、端末、ルートを確認し、次回の送信の前に変数を1つだけ変えます。

## Sources

- [3GPP TS 23.040：ショートメッセージサービスの技術的実現](https://www.3gpp.org/ftp/Specs/archive/23_series/23.040/) — Accessed: 2026-10-19
- [3GPP TS 23.038：アルファベットおよび言語固有の情報](https://www.3gpp.org/ftp/Specs/archive/23_series/23.038/) — Accessed: 2026-10-19
- [SMPPの配信レシート：メッセージの状態とエラーコード](https://smpp.org/smpp-delivery-receipt.html) — Accessed: 2026-10-19

Updated: 2026-10-19