# OTP SMS の配信と不正

ワンタイムパスワードは、入力された時点でその番号を管理していることを証明します。本人であることを証明するものではなく、配信レシートも人がそれを読んだことを証明するものではありません。確認が有効に機能するかどうかは、配信、傍受、番号の再利用、そして入力フォームそのものによって決まります。

- OTP が証明するのは、その時点で番号を管理していることであり、本人であることではありません。

- 配信レシートが報告するのはネットワーク上の状態であり、人がコードを読んだことではありません。

- 番号の再利用、SIM スワップ、転送、フィッシングが、コードが漏れる主な経路です。

- レート制限、送信者の登録、番号のチェックは悪用を減らしますが、いずれも本人であることを証明するものではありません。

## OTP が証明すること

OTP が答える問いは 1 つだけです。目の前の相手は、今この番号でメッセージを受け取れるか。これはアカウント復旧やログインに役立ちます。セッションを、ユーザーが管理しているものに結び付けられるからです。しかし、本人確認書類ではありません。番号は再利用されることも、新しい SIM に移されることも、転送されることも、同じ世帯の別の人に読まれることもあります。
この区別は設計の段階で重要になります。操作の重要度が低ければ、OTP は見合った手段です。送金、パスワード変更、送金先の追加といった操作であれば、コードに 2 つ目の確認を組み合わせてください。待機時間、既存セッションでの確認、既知の連絡手段へのコールバック、あるいは手動の審査です。コードは要素の 1 つであり、判断のすべてではありません。

### 経路と、コードが漏れ得る箇所

コードを届けるのと同じ連鎖が、コードを見られたり、遅延させられたり、誤った端末に送られたりし得る箇所も生み出します。

Alt: アプリケーションから端末、配信レシートまでの 7 段階の SMS 経路。コードが漏れ得る箇所が複数ある経路として示されています。

アプリケーションがコードをゲートウェイに送信し、メッセージセンターが加入者を照会し、在圏交換機が端末に配信します。レシートは同じ連鎖をたどって戻ります。コードは、アプリケーション、端末、番号そのもの、あるいは受け取った人を通じて漏れることがあります。ネットワーク経路で配信は説明できますが、コードを他人に教えてしまう人の行動は説明できません。

| Item | Value | Note |
| --- | --- | --- |
| 状態1 · 1 | アプリケーション |  |
| 状態1 · 2 | SMPPゲートウェイ |  |
| 状態1 · 3 | SMSC |  |
| 状態1 · 4 | HLR / HSS |  |
| 状態1 · 5 | MSC / MME |  |
| 状態1 · 6 | 端末 |  |
| 状態1 · 7 | 配信確認 |  |

Source: 3GPP TS 23.040：SMS のアーキテクチャ (https://www.3gpp.org/ftp/Specs/archive/23_series/23.040/)

## OTP が漏れる箇所

SIM スワップは、番号を新しいカードに移します。攻撃者は販売店やサポート窓口に自分が契約者本人だと信じ込ませ、次のコードは新しい SIM に届きます。番号の再利用は、攻撃者がいなくても同じ結果をもたらします。通信事業者が休眠番号を再割り当てし、新しい保有者が以前のアカウント宛てのコードを受け取るのです。どちらも、番号が最近 MNP で移転されたか、再割り当てされたかを確認すべき理由です。
転送や留守番電話のテキスト化は、メッセージを別の受信箱に送ります。フィッシングはフォームを複製してコードを直接収集するため、ネットワークは攻撃をまったく認識しません。ネットワーク経路上での傍受はまれで、アプリケーションの管理外にあります。実際的な対策は、コードを長くすることではなく、2 つ目の要素を加えることです。定義については [OTP の用語集項目](/ja/resources/glossary/otp/) をご覧ください。

## 有効な対策

1 つの番号、IP アドレス、デバイスがコードを要求できる頻度を制限してください。有効期間は短くし、コード 1 つにつき使用は 1 回とし、コードを要求したセッションに紐付けてください。送信者を登録し、本文はシンプルにしてください。マーケティングのように見えるコードはフィルタリングされることがあり、フィルタリングされたコードはログインではなくサポートチケットを生みます。
番号を信頼する前にチェックしてください。SMS を受信できない番号、最近 MNP で移転された番号、リセットの履歴がある番号には、2 つ目のステップを設けるべきです。重要度の高い操作には、既存のセッションまたは 2 つ目の連絡手段を必須にしてください。要求、送信、レシート、コード入力を別々のイベントとして記録すれば、配信の問題とユーザー側の問題を区別できます。
コードそのものも同じように慎重に設計してください。暗号論的に安全な乱数源から生成し、ハッシュを保存し、数分で失効させ、成功する使用は 1 回に限り、コードごと・セッションごとに試行回数の上限を設けてください。番号が存在するかどうかを明かさないでください。送信の前にアカウントのレコードを作成し、再試行によって完了しないアカウントが開設されないようにしてください。

### 5 つの指標とその定義

| 指標 | 定義 | 分かること |
| --- | --- | --- |
| 配信率 | 配信済みレシート数を送信メッセージ数で割った値 | ネットワークがメッセージを受け付けたかどうか。人が読んだかどうかではない |
| 完了率 | 入力されたコード数を配信済みメッセージ数で割った値 | メッセージとフォームがユーザーにとって機能したかどうか |
| 配信所要時間 | 送信からレシートまでの中央値と 95 パーセンタイル | ルートが遅いかどうか、ユーザーが再送信するまでどのくらい待つか |
| 再送信率 | 再送信数を配信済みメッセージ数で割った値 | ユーザーが待ちすぎているか、入力を誤っているか、最初のメッセージを見ていないか |
| ブロック率 | リスクルールで拒否された要求数を試行数で割った値 | ルールが厳しすぎるか、緩すぎるか、あるいはトラフィックが不正なものか |

市場、送信者、ルートごとに追跡してください。全体の単一平均では、失敗しているルートが見えなくなります。

## 送信ではなく、フローを測る

メッセージ ID が返された送信は、配信されたコードではありません。配信されたコードは、完了したログインではありません。自社で管理できるイベント、つまり送信、レシート、コード入力、成功からファネルを組み立ててください。そのうえで、プロバイダー側のデータと比較してください。自社の配信率とプロバイダーの配信率に差がある場合、端末に届かなかったメッセージではなく、自社のハンドラーに届かなかったレシートが原因かもしれません。
指標が動いたらフローを見直してください。配信率が安定したまま完了率が下がった場合は、フォーム、コードの有効期限、または送信者に原因があると考えられます。送信率が安定したまま配信率が下がった場合は、ルート、番号、またはコンテンツフィルターに原因があると考えられます。再送信が増えた場合は、配信所要時間に原因があると考えられます。変更しやすいステップではなく、データが示すステップを修正してください。
フロー全体の見直し日を設定してください。番号は持ち主が変わり、ルートは変わり、テンプレートは古くなります。立ち上げ時に機能していたフローが、同じコード、同じプロバイダーのまま、6 か月後に気付かないうちに失敗していることがあります。

### Check what you learned

**ユーザーがコードを友人に転送しました。そのコードはまだ本人であることを証明しますか。**

いいえ。証明するのは、その時点でその番号がコードを受信できたということです。コードを持っていれば誰でも使えます。

**レシートは配信済みと示していますが、ユーザーにはコードが表示されていません。何を確認しますか。**

端末の状態、メッセージアプリと迷惑メッセージフィルター、送信者、ルートです。配信済みのレシートはネットワーク上の状態であり、端末の表示ではありません。

**なぜ配信率より完了率のほうが役に立つのですか。**

配信はネットワークで止まります。完了にはユーザー、コードの有効期限、フォームが含まれ、ほとんどの失敗はそこに表れるからです。

## FAQ

**OTP は二要素認証と同じですか。**

OTP は 2 つ目の要素になり得ます。単独では、その時点で番号を所持しているという 1 つの要素にすぎません。

**コードが長いほど安全ですか。**

長さは推測に対しては有効ですが、SIM スワップ、転送、フィッシングは防げません。重要度の高い操作には 2 つ目の確認を加えてください。

**配信レシートで、ユーザーがコードを読んだことを証明できますか。**

いいえ。レシートが報告するのは、配信済み、期限切れ、未配信といったネットワーク上の状態です。読んだか、入力したかについては何も示しません。

**自動で再送信すべきですか。**

タイマーではなく、ユーザーの操作に応じて再送信してください。自動の再送信はコストを何倍にも増やし、ルートの問題を覆い隠すことがあります。

**何を記録すべきですか。**

要求、送信とそのメッセージ ID、レシートとその状態、コード入力の結果です。それぞれをタイムスタンプ付きの別々のイベントとして保持してください。

**レシートでは配信済みなのに、ユーザーに何も届きません。プロバイダーを切り替える前に何を確認すべきですか。**

まず自社側です。配信レシートが示すのはネットワークがメッセージを受け付けたことであり、端末に何が表示されたかではありません。テンプレートを [SMSコンテンツ事前チェック](/ja/tools/content-precheck/) にかけ、[SMSセグメントカウンター](/ja/tools/sms-segments/) でセグメント数を数え、[SMPPとDLRのコードデコーダー](/ja/tools/smpp-decoder/) で送信とレシートのコードを読み解いてください。問題がなければ、トラフィックを移す前に、届かない接続先を自社の端末でテストしてください。接続先は 1 つずつ進めます。

## Sources

- [3GPP TS 23.040：ショートメッセージサービスの技術的実現](https://www.3gpp.org/ftp/Specs/archive/23_series/23.040/) — Accessed: 2026-10-19
- [3GPP TS 23.003：番号計画、アドレス指定、識別](https://www.3gpp.org/ftp/Specs/archive/23_series/23.003/) — Accessed: 2026-10-19
- [SMPP の配信レシート：メッセージの状態](https://smpp.org/smpp-delivery-receipt.html) — Accessed: 2026-10-19

Updated: 2026-11-03