SMSにおけるSMPPとHTTP (REST) APIの比較.
BroadNetはHTTP（REST）SMS APIとSMPPバインドの両方を提供しています。どちらが適しているかは、継続的な送信量と統合方法によって決まります。 REST SMS APIは、ほぼすべての現代的なエンジニアリングチームにとって最適なツールです。ファイアウォールとの親和性が高く、言語に依存せず、統合も容易です。BroadNetはRESTにおいてアカウントごとの固定レート制限を設けていません。毎秒数百メッセージを継続的に送信する場合や、永続的なバインドが必要な場合、またはバイナリ効率と完全なDLRセマンティクスを必要とするあらゆるワークロードには、SMPPが最適なツールです。ほとんどのBroadNetのお客様はRESTから開始し、ボリュームに応じてSMPPバインドを追加していきます。
12行。曖昧な表現は一切ありません。
両方の列に同じ基準を適用しています。行の内容が特定の活用事例に真に依存する場合は、表にその旨を記載しています。どちらか一方が明らかに優れたツールである場合も、同様に記載しています。
| 機能 | カラムA SMS API (REST) HTTPS / JSON | カラムB SMPP Short Message Peer-to-Peer 3.4 / 5.0 |
|---|---|---|
プロトコル | HTTPS POST + JSON | Binary TCP、持続的セッション |
デフォルトポート | 443 (TLS) | 2775（プレーン）; TLSポートはお客様のアカウントと共に提供されます |
認証 | Bearerトークン / APIキー | system_id +紐付け時のパスワード |
セッションモデル | ステートレスなリクエスト/レスポンス | 長時間維持されるバインド・トランシーバー・セッション |
スループットの上限 | アカウントごとの固定制限なし。トラフィックに合わせて拡張可能 | アカウントごとの固定制限なし。ノードあたり30,000 SMS/秒まで |
べき等性 | べき等性ヘッダーなし：返されたメッセージIDを保持し、再送前にステータスを確認してください | プロトコル内には存在しません：sequence_numberはレスポンスとそのリクエストをペアにするのみです。 |
配信レポートモデル | Webhookコールバック | 同一セッション内のdeliver_sm |
エンコーディング制御 | 自動 (GSM-7 / UCS-2) | 手動data_codingパラメータ |
連結SMSへの対応 | 自動分割 | 手動UDHまたはmessage_payload |
インバウンドMO処理 | Webhookコールバック | 同一セッション、deliver_sm |
統合にかかる工数 | 数分 (curl)から数時間 | 1-2週間（バインディングロジック、リトライ、セッションキープアライブ） |
対象 | Webアプリ、プロトタイプ、中低ボリューム | 継続的な高ボリューム、アグリゲーター、通信事業者 |
四半期ごとにレビュー済み · 修正の提出先 press@broadnet.me
bind_transceiverセッションの開始と認証bind_transceiver_respセッション承認済みsubmit_smメッセージ送信submit_sm_resp承認済み、メッセージIDを返却deliver_sm配信レポートまたは受信メッセージdeliver_sm_resp確認済みenquire_linkアイドル時のキープアライブ
各ワークロードに適した構成。
REST SMS APIを選択すべきタイミング
ワークロードが中規模で、チームがWebネイティブであり、統合のスケジュールが短い場合は、RESTを選択してください。2026年において、ほぼすべてのCPaaSのお客様にとって、RESTはデフォルトとなるモダンな選択肢です。
- リクエストごとのHTTPSオーバーヘッドがボトルネックにならない、アプリ形式のボリューム。
- スタックがすでにHTTPネイティブ（Webアプリ、サーバーレス、モバイルバックエンド）であるチーム。
- 生の処理能力よりも統合の容易さが優先されるワークロード。
- SMSがWhatsApp、RCS、および電子メールと並行して機能するマルチチャネル・オーケストレーション。
SMPPを選択すべきタイミング
継続的なスループット、完全なDLR制御、またはアグリゲーター形式の運用を検討している場合は、SMPPを選択してください。SMPPはRESTよりも歴史があり特殊ですが、通信業界で実際に稼働しているプロトコルであり、大規模運用における効率性は本物です。
- 毎秒数百メッセージの継続的な送信、または永続的なバインドが必要なワークロードなど、RESTにおいて接続確立のコストが問題になり始めるケースです。
- data_coding、有効期間、およびmessage_payloadを完全に制御する必要があるワークロード。
- 大量のインバウンドMOを運用しており、同一セッション内でdeliver_smを必要とするチーム。
- アグリゲーター、通信事業者、およびメッセージングを主要なビジネス機能として運用しているすべての企業。
BroadNetの立ち位置
単なるセールストークではなく、誠実なポジショニングを。時には、この比較の反対側を利用することこそが正解である場合もあります。その際は、弊社からお伝えします。
通信の専門家に相談する当社は両方を提供しており、お客様のチームが最も生産性を発揮できる方法から開始することをお勧めしています。Webネイティブなエンジニアリングチームの多くにとっては、それはRESTを意味します。当社のPOST /sms/sendSmsエンドポイント、OpenAPI 3.1仕様、および公式のTypeScript SDKは、SMPPに触れることなく、お客様のニーズの90%をカバーしています。
SMPPが適切な選択肢となるのは、ボリュームのしきい値、すなわち毎秒数百メッセージが継続的に送信される段階に達した時です。この段階では、リクエストごとのHTTPSハンドシェイクがレイテンシ予算の大部分を占めるようになり、コネクションプーリングの解決が必要になります。その際、当社では、お客様のトラフィックに合わせてノードあたり30,000 SMS/秒まで拡張可能な、アカウントごとの固定APIレート制限なしのTLS暗号化SMPP 3.4トランシーバーバインドを提供します。ホスト、ポート、および認証情報は、テストアクセス時に提供されます。
より新しいmessage_payloadのセマンティクス、ブロードキャスト処理、またはよりクリーンなステータスレポートを必要とするお客様向けに、SMPP 5.0もサポートしています。実際には、世界中の通信事業者のSMPPトラフィックの95%は依然として3.4であり、当社では3.4をデフォルトとして扱っています。
一般的なパターンとして、個別のOTPや通知を送信するアプリケーション層のコードにはRESTを、大量のキャンペーンやSMS一斉送信ディスパッチャーにはSMPPを使用します。どちらも同じSMSCにバインドされ、同じ配信レポートを生成し、同じ料金体系に基づいて請求されます。お客様は、これらを意識することなく組み合わせて利用できます。
よくあるご質問。
SMPPとは具体的に何ですか？
+
SMPPとは具体的に何ですか？
Short Message Peer-to-Peer Protocol — 1990年代後半に、SMSCとESME（外部ショートメッセージエンティティ、すなわちアプリケーション）の間でSMSを配信するために設計されたバイナリTCPプロトコルです。これは、アグリゲーターと通信事業者の間で、ほとんどのキャリアグレードのA2Pトラフィックが実際に利用しているプロトコルです。
SMPPの統合はRESTよりも困難ですか？
+
SMPPの統合はRESTよりも困難ですか？
より高度な技術が求められます。長期間維持されるバインドセッション、keepalive（enquire_link）ロジック、シーケンス番号の管理、エンコーディングへの対応、およびバインド状態の処理が必要です。多くのチームは既存のSMPPライブラリを使用しています。例えば、JavaにはCloudhopper、Nodeにはsmpp.js、Java向けのエンタープライズにはjSMPPが用いられます。
なぜ大量送信者は2026年になっても依然としてSMPPを使用しているのでしょうか？
+
なぜ大量送信者は2026年になっても依然としてSMPPを使用しているのでしょうか？
スループットの効率性です。接続を慎重にプールしない限り、RESTではリクエストごとに新しいTLSハンドシェイクが必要になりますが、単一のバインドされたSMPPセッションでは、トランシーバーあたり毎秒1,000件以上のメッセージを送信できます。継続的な大量送信においては、バイナリプロトコルの方が大幅に効率的です。
BroadNetでは、SMPPとRESTのどちらが優先的に提供されていますか？
+
BroadNetでは、SMPPとRESTのどちらが優先的に提供されていますか？
両方提供しています。新規登録時はRESTがデフォルトとなり、毎秒数百メッセージを維持するワークロードや永続的なバインドが必要な場合は、営業担当に相談してSMPPをご利用いただけます。どちらも背後にあるSMSCは同一であり、同一のDLRセマンティクスが適用されます。
SMPP 5.0については？
+
SMPP 5.0については？
対応しています。実際、世界中のA2P SMPPトラフィックの大部分は依然として3.4を使用しており、お客様から特に5.0の指定がない限り、新しいバインドでは3.4をデフォルトとして扱います。
同じアカウントからRESTとSMPPの両方を実行できますか？
+
同じアカウントからRESTとSMPPの両方を実行できますか？
はい、同じSMSCに対して行います。ほとんどの法人のお客様はまさにこの方法を採用しています。アプリケーション層のコードにはRESTを、大量配信を行うディスパッチャーにはSMPPを使用します。
配信レポートの取り扱いはどのように異なりますか？
+
配信レポートの取り扱いはどのように異なりますか？
RESTは、登録されたURLにWebhookコールバックを受信します。SMPPは、メッセージを送信したのと同じセッションでdeliver_smフレームを取得します。両方とも、同じDLRフィールドとBroadNetレイヤーでの同じ配信レポートペイロードを保持します。
SMPPではなくRESTを選択することで、到達率が低下しますか？
+
SMPPではなくRESTを選択することで、到達率が低下しますか？
いいえ。どちらのエンドポイントでも、同じメッセージは同じSMSCと同じ通信事業者の配信ルートを経由します。つまり、DLRの忠実度とルーティングは同一です。選択は純粋に運用上の問題であり、到達率のトレードオフではありません。