# SMPPとは？SMSのセッションプロトコル

SMPPは、プラットフォームが永続的なセッションを通じてメッセージセンターとショートメッセージをやり取りするためのプロトコルです。バインドで方向を宣言し、セッションはスループットのウィンドウを持ち、配信レシートはPDUとして返ってきます。リクエスト／レスポンス型のAPIではありません。

- SMPPは、バインドの方向を宣言した永続的なセッションです。

- バインドには、スループットの割り当てと、未応答リクエストのウィンドウがあります。

- PDUは、16バイトのヘッダーとコマンド固有のボディで構成されます。

- 配信レシートはセッション上で非同期に届きます。メッセージIDで照合してください。

## 呼び出しではなく、セッション

SMPPは、自社のプラットフォームとメッセージセンターの間で接続を開いたままにします。プラットフォームは一度だけ認証し、何をしたいかを宣言したうえで、同じセッション上でメッセージを送信し、イベントを受信します。メッセージセンターは、配信レシートや着信メッセージを送るために新しいリクエストを待ちません。報告すべきことがあれば、PDUをプッシュします。
この形は、途切れなく続くメッセージの流れに適しています。セッションの状態がすでに確立されており、配信レシートのチャネルもすでに開いているため、メッセージごとのオーバーヘッドは小さくなります。一方で、HTTPクライアントにはない状態をクライアント側で管理する必要があります。バインドの状態、処理中のウィンドウ、キープアライブのタイミング、再接続の挙動です。

## バインドで方向を宣言する

バインドとは、認証済みのセッションに方向を加えたものです。トランスミッターバインドはメッセージを送信します。レシーバーバインドは、端末発信（MO）メッセージと配信レシートを受信します。トランシーバーバインドは、1つのセッションでその両方を行います。プロバイダーはバインドごとに認証情報を発行し、開けるバインドの数を制限することがあります。
規模を拡大するときは、1つのバインドを割り当て以上に押し込むのではなく、バインドを追加してください。1つのバインドには、1つのスループット割り当てと、1つの未応答リクエストのウィンドウがあります。ピーク時にそれ以上が必要なら、追加のバインドを依頼してトラフィックを分散します。1つのバインドでウィンドウを超えて送信し続けると、スロットリング、タイムアウト、再試行が発生します。これらはネットワーク障害のように見えますが、原因はクライアント側にあります。

### バインド、送信、配信レシート

セッションは一度だけ開きます。各送信にはメッセージID付きの応答が返り、配信レシートは後から同じセッションで届きます。

Alt: アプリケーションからバインド要求、メッセージセンター、submit応答、配信レシートへと続くシーケンス。

アプリケーションがバインドを開き、メッセージセンターが応答します。アプリケーションはsubmit_smでショートメッセージを送信し、メッセージID付きのsubmit_sm_respを受け取ります。その後、メッセージセンターが配信レシートを含むdeliver_sm PDUを送信します。アプリケーションはdeliver_sm_respでこれに応答します。作業が終わると、unbindでセッションを閉じます。

| Item | Value | Note |
| --- | --- | --- |
| 状態1 · 1 | アプリケーション（ESME） |  |
| 状態1 · 2 | bind_transceiver | セッションを開く |
| 状態1 · 3 | SMSC |  |
| 状態1 · 4 | submit_sm_resp | 配信受付済み |
| 状態1 · 5 | 配信確認 |  |

Source: smpp.org：SMPPのセッションとPDUの操作 (https://smpp.org/)

## ウィンドウは守るべき取り決め

ウィンドウとは、クライアントが応答を待たずに未応答のまま保持できるリクエストの数です。目安ではありません。ウィンドウを超えて送信すると、メッセージセンターはスロットリングをかけます。同じペースで再試行を続ければ、キューは膨らみます。送信ごとに応答コードを読み、スロットリングされたら速度を落とし、次のバーストの前にウィンドウが空くのを待ってください。
キープアライブのトラフィックがセッションを維持します。enquire_linkを一度も送らないクライアントは、最初の送信が失敗するまで、切れた接続に留まり続けることがあります。切断のたびに即座に再接続するクライアントは、プロバイダーに過剰な負荷をかけることがあります。バックオフを使い、再接続の頻度に上限を設け、バインドの停止時間がトラフィックの許容範囲を超えたらアラートを出してください。

### 1つのPDUをフィールドごとに

ヘッダーは固定で、ボディはコマンドによって異なります。submit_smには、アドレス、データ符号化方式、配信レシート要求フラグが含まれます。

Alt: コマンド長、コマンドID、ステータス、シーケンス番号、ボディの各フィールドを示した、デコード済みのsubmit_sm PDU。

すべてのPDUは、4バイトのコマンド長、4バイトのコマンドID、4バイトのコマンドステータス、4バイトのシーケンス番号で始まります。その後にボディが続きます。submit_smの場合、ボディには送信元アドレスと宛先アドレス、ショートメッセージ、データ符号化方式、registered delivery（配信レシート要求）フラグが含まれます。オプションパラメーターは、TLV（タグ・長さ・値）フィールドとして送られます。

| Item | Value | Note |
| --- | --- | --- |
| command_length | 53 |  |
| command_id | 0x00000004 |  |
| command_status | 0x00000000 |  |
| sequence_number | 1 |  |
| service_type |  |  |
| source_addr_ton | 1 |  |
| source_addr_npi | 1 |  |
| source_addr | 12345 |  |
| dest_addr_ton | 1 |  |
| dest_addr_npi | 1 |  |
| destination_addr | 15551234567 |  |
| esm_class | 0x00 |  |
| protocol_id | 0x00 |  |
| priority_flag | 0 |  |
| schedule_delivery_time |  |  |
| validity_period |  |  |
| registered_delivery | 0x01 |  |
| replace_if_present_flag | 0x00 |  |
| data_coding | 0x00 |  |
| sm_default_msg_id | 0x00 |  |
| sm_length | 4 |  |
| short_message | 54657374 |  |
| テキスト | Test |  |

Source: SMPP v3.4仕様：PDUヘッダーとsubmit_sm (https://smpp.org/SMPP_v3_4_Issue1_2.pdf)

## あるメッセージの一日

クライアントはトランシーバーバインドを開き、バインド応答を読み取ります。メッセージを送信し、応答に含まれるメッセージIDを保存します。メッセージセンターは、メッセージを接続先ネットワークへルーティングします。数分後、配信レシートを含むdeliver_sm PDUが届きます。そこには元のメッセージID、状態、そして多くの場合ネットワークコードが含まれます。クライアントは配信レシートに応答し、その状態を自身の記録と突き合わせます。
各ステップには、それぞれ失敗のパターンがあります。バインドは、認証情報の誤りやインターフェースバージョンの不一致で拒否されることがあります。送信は、スロットリングされることも、拒否されることも、受け付けられた後に配信レシートで失敗となることもあります。配信レシートが、コードの有効期限が切れた後に届くこともあります。クライアントは、メッセージIDを保存し、遅れて届いた配信レシートも受け付け、ユーザーが何をしたかについてはアプリケーション自身の状態を信頼できる情報源とするように設計してください。

デコーダーはブラウザ内で動作し、貼り付けた配信レシートはブラウザ内に留まります。

[Open the tool](/ja/tools/smpp-decoder/?src=learn-what-is-smpp&scenario=dlr-example&sample=id%3A0123456789+sub%3A001+dlvrd%3A001+submit+date%3A2610181200+done+date%3A2610181201+stat%3ADELIVRD+err%3A000+text%3AYour+code+is+123456)

### ルートをデバッグする前に、配信レシートをデコードする

配信レシートを[SMPPおよびDLRデコーダー](/ja/tools/smpp-decoder/)に貼り付けて、各フィールドを読んでください。メッセージID、状態、完了日時、エラーコードを確認します。状態がDELIVRDでない場合、エラーコードをプロバイダーのコード表と照らし合わせて読むと、番号、端末、ネットワークのどれがメッセージを拒否したのかを判断する手がかりになります。プロバイダーにルートの変更を依頼する前に、これを行ってください。

## 配信レシートとデバッグ

配信レシートは非同期です。deliver_sm PDUとしてセッション上に届き、その形式はメッセージセンターによって異なります。新しい実装では、状態をmessage_state TLVフィールドで伝えます。古い実装では、id、stat、errなどのキーと値のペアを含むテキスト形式の配信レシートを、short_messageフィールドに入れます。どちらか一方を前提とせず、両方を解析してください。
到着順ではなく、メッセージIDで照合してください。1秒違いで送信した2つのメッセージの配信レシートが逆の順序で返ってくることがあり、再試行によって重複が生じることもあります。送信時にIDを保存し、配信レシートが届いたらレコードを更新し、同じIDに対する2通目の配信レシートは、状態がより新しい場合を除いて無視してください。[接続ガイド](/ja/resources/guides/smpp-http-connection/)では、これを運用手順として整理しています。

### Check what you learned

**再試行の頻度を上げるよりも、バインドを追加するほうが効果的なのはなぜですか？**

1つのバインドには1つのウィンドウがあります。バインドを追加すれば容量が増えますが、満杯のウィンドウに対して再試行しても、キューと遅延が増えるだけです。

**メッセージIDはどこから来ますか？**

メッセージセンターがsubmit_sm_respで返します。それを保存し、後から届く配信レシートをそのIDで照合してください。

**配信済みを示す配信レシートは、何を証明しますか？**

ネットワークがメッセージを受け付け、端末までの経路に配信したことです。人がそれを読んだことは証明しません。

## FAQ

**始めるのにSMPPは必要ですか？**

いいえ。HTTPなら半日で統合できます。SMPPは、安定した通信量がセッションに見合うようになってから効果を発揮します。

**バインドとは何ですか？**

方向を宣言した永続的なセッションです。方向はトランスミッター、レシーバー、トランシーバーのいずれかです。スループットの割り当てを持ち、キープアライブのやり取りによって開いた状態が維持されます。

**PDUとは何ですか？**

Protocol Data Unit（プロトコルデータユニット）の略で、SMPPがやり取りするバイナリメッセージです。すべてのPDUは、16バイトのヘッダーとコマンド固有のボディで構成されます。

**SMPPをパブリックインターネット上で使えますか？**

多くの場合は可能です。TLSとIP許可リストを併用しますが、プロバイダーに確認してください。代わりにプライベート接続を使う構成もあります。

**長いメッセージはどのように扱われますか？**

ユーザーデータヘッダー付きの連結セグメントとして、またはネットワーク側で分割されるmessage payload TLVとして扱われます。結果は端末で確認してください。

## Sources

- [smpp.org：SMPPのセッション、バインド操作、配信レシート](https://smpp.org/) — Accessed: 2026-10-19
- [SMPP v3.4仕様、Issue 1.2](https://smpp.org/SMPP_v3_4_Issue1_2.pdf) — Accessed: 2026-10-19
- [3GPP TS 23.040：ショートメッセージサービスの技術的実現](https://www.3gpp.org/ftp/Specs/archive/23_series/23.040/) — Accessed: 2026-10-19

Updated: 2026-10-19