Future Architecture Guidelines

Appearance

SMS設計ガイドライン

フューチャー株式会社

本ガイドラインは、SMS送信で考慮すべき設計事項と推奨案をまとめる。

位置づけ・適用範囲・用語・免責事項は Introduction を参照。

メールと並び、ユーザーに直接情報を届けるチャネルにSMS（ショートメッセージサービス）がある。電話番号を宛先として、短いテキストメッセージを送受信でき、1990年代に携帯電話（2G/GSM）の標準機能として世界的に普及した。プッシュ通知で受信者の目に留まりやすく、開封率が高いため、以下のような即時性・確実性が求められる用途で活用されている。

  • 本人認証・二要素認証（2FA）: ワンタイムパスワード（OTP）の送付
  • 重要通知: サービス約款の更新や重要な設定変更など
  • 緊急連絡: システムの緊急メンテナンス情報、災害時の安否確認

(コラム) 巧妙化するSMSの脅威と新しい潮流

SMSは本人性が高く安全なチャネルと見なされてきたが、近年は様々な脅威が増加しており、注意が必要である。

  • スミッシング（Smishing）
    • 宅配業者・金融機関・公的機関などを装い、SMSで偽サイトへ誘導するフィッシング詐欺が増加
    • ユーザーが正規のSMSであると判断しやすい工夫（例：送信者IDの利用、URLのドメインの周知）が必要
  • 偽基地局による中間者攻撃
    • 偽の携帯電話基地局から付近の通信を傍受し、SMSの内容を盗聴したり、なりすましSMSを送信したりする「IMSIキャッチャー」という攻撃

上記のような脅威から、SMSの後継としてRCS（Rich Communication Services）が注目され、日本では「＋メッセージ」として提供されている。RCSでは、ブランドの公式マークの表示によるなりすましの軽減や、リッチなコンテンツの送受信が可能となる。RCSへ移行する流れもウォッチする必要がある。

メールとの使い分け ​

SMSとメールは、下表のように特性が異なるため、要件に応じて使い分けることが求められる。「確実性と即時性」と「情報量と費用」でトレードオフ構造がある。

観点SMSメール
到達性✅️100％近く届く✅️適切に設計すれば到達率を高められる
開封率✅️高い⚠️迷惑メールフィルタや未読で読まれない確率が高い
即時性✅️プッシュ通知されるため、すぐに気づかれやすい⚠️ユーザーがメーラーを開くまで気づかれない
情報量❌️ 少ない（通常全角70文字程度）。長文やファイル添付は不可✅️多い。HTMLによる表現やファイル添付も可能
コスト⚠️高い（1通あたり数円～十数円）✅️安い
ユーザー体験⚠️頻繁な通知は嫌われる傾向✅️比較的許容されやすい。後で読み返す用途にも向く

推奨は以下の通り。

  • SMSの利用をなるべく下げる
    • 電話番号は個人情報として扱うことが一般的であり、収集の合意・暗号化など多くの配慮が必要である。利用しなくて済むなら、利用しない
  • 特に以下の場合は、SMSではなくメールの利用が向いている
    • 情報量が多く、記録として残す必要がある、利用規約の変更などの場面
    • PDFなどのファイルを添付する必要がある、領収書・請求書などの場合
    • コストを抑えて多くのユーザーに定期的に情報を届けたいメールマガジンなどの場面
  • SMSを採用する場合は、運用費用を下げるため最小限とする
    • ログインや決済時の本人確認や、ワンタイムパスワード送信など、セキュリティが「最優先」される場面
    • 支払い期限の最終リマインドなど、ユーザーに気づいてほしい最終督促のような場面
      • SMSでも無視されることが多いとも考えられるが、開封率が高いことも事実である
      • SMSで通知したという事実が、後のサービス停止や法的措置へ移行する際にも正当性を補強する一因となる
      • 「【重要】●●よりお支払いに関するご案内です。ご登録のメールアドレスをご確認ください」というように、メールやサービスログインへの誘導にすることで、コストを抑える

電話番号 ​

電話番号は多様な形式で表現される。

形式例概要特徴
E.164形式+819012345678ITU-T（国際電気通信連合）に標準化された国際的な形式・ 「+」 「国コード」 「0を除いた国内番号」で構成される。
・記号やスペースを含まず、グローバルで番号を一意に識別できる。
・多くのクラウドサービスで標準的に採用されている
国内電話番号形式0X0-1234-5678日本国内で一般的に利用される、市外局番などから始まる形式・視認性のためにハイフンで区切られることが多い。
・国コードを含まないため、国際的なサービスでは利用できない。
・ハイフンの有無など、表記揺れが発生しやすい

ユーザーのフォーム入力時にどの形式を要求するか、システムで保持する際にどの形式へ変換するかが考慮点となる。

推奨は以下の通り。

  • ユーザー入力形式
    • グローバル利用が想定される場合は、E.164形式で入力する
      • Googleがメンテナンスする libphonenumber といったライブラリの利用が便利である
      • このライブラリは正規化だけでなく、電話番号の妥当性検証（例: 日本の携帯電話番号として有効か）も可能である
    • ただし、国内ユーザーのみ想定の場合は、「国内電話番号形式」を採用しても良い
      • ユーザー入力時はハイフンの有無を許容する方が良い
  • E.164形式でDBに保存する
    • 標準化された仕様が存在する場合、それに従っておくことがベター（ライブラリやツールなどとの親和性も高い）
    • 決済代行会社（Payment Gateway）やカード会社などでは、E.164形式で連携を求められる
    • 国内電話番号形式で入力された場合も、バックエンドで正規化処理を行う
  • ユーザーへの表示形式
    • 入力と同様の形式にする

入力は柔軟に、データは厳格に

システム入力の設計原則に、「入力は柔軟に、データは厳格に」という言葉がある。電話番号入力はこれに従い、ハイフンの有無、全角・半角などを気にせず入力できるように、システム側でライブラリを用いて正規化することで、ユーザー体験を向上できる。

E.164形式の入力フォーム

ユーザーにE.164形式 (+81X012345678) を直接入力させることは、離脱率を上げてしまう可能性が高く避けるべきである。そのため、「国選択」と「電話番号入力」を組み合わせる、 [ 日本 (+81) ▼ ] [ 9012345678 ] の形式を推奨する。

  • 国選択ドロップダウン:国を選択することで、国コード（例: +81）が自動設定される
  • 電話番号入力欄: 国内番号（日本の場合は先頭の0を除いた 9012345678）を入力してもらう。プレースホルダーで例を示すと良い。また、090-XXXX-XXXX と入力しても、先頭の0をトリムする

国内電話番号形式の入力フォーム

[ 0X0 ] - [ 1234 ] - [ 5678 ] という3つに分離した入力フォームには、オートコンプリートが効きにくいなどの課題がある。そのため、以下のように1つの入力フォームを利用することを推奨する。

html
<label for="phone">電話番号</label>
<input
  type="tel"
  id="phone"
  name="phone"
  placeholder="例: 09012345678"
  autocomplete="tel"
/>
<p>ハイフンは不要です。</p>

国内電話番号形式で入力/表示する場合の具体的な変換フロー例

  1. ユーザーがフォームに 0X0-1234-5678 と入力する。
  2. バックエンドは libphonenumber を利用してバリデーションと正規化を行う。
  3. データベースにはE.164形式の +81X012345678 として保存する。
  4. マイページなどで表示する際は、再度ライブラリを使って国内形式の 0X0-1234-5678 にフォーマットして表示する。

電話番号は名寄せに使えないことが多い

複数のサービスを運営していると、サービス品質向上のためアカウント連携したい事が良くある。この時、電話番号が名寄せに使えるのではないか？ と思い浮かぶことがある。

しかし、電話番号は利用目的の合意ができていることを前提に収集が可能であり、目的変更には再同意が必要である。そのため、安易に電話番号で名寄せを行うと規約違反の可能性がある。また、同一人物が複数番号を持つ場合や、電話番号を家族で共有している場合も考えられ、誤った名寄せになる懸念もある。そのため、ユーザーの連携率に依存するが、Google、Apple IDなどのソーシャルログインで名寄せする案がベターである。

電話番号の有効性 ​

ユーザーの入力した電話番号が、実際に使われている有効なものかを確認することで、SMS到達率の向上や、余計なコスト削減、不正利用の抑制などに繋げられる。確認方法は、以下の3つに大別される。

#方式説明メリットデメリット
1フォーマット検証電話番号の形式・桁数をチェック実装が容易番号が「現在使われているか」までは判断できない。例えば、解約済みの番号は有効と判定される
2サードパーティの電話番号検証API携帯電話ネットワークのデータベース（HLR: Home Location Register）に問い合わせ、電話番号が有効か、現在の利用キャリアを確認ユーザーアクションが不要で、コストを抑えられるTwilio Lookup、Numverify、Vonageの電話番号検証APIサービスの利用が必要。個人情報保護の観点から利用に注意が必要（個人情報保護法における委託になると考えられ、委託先の監督義務を負う）。番号が有効でも、実際にユーザーが所有しているかの確認ができない
3SMS送信による認証実際にSMSを送信し、本文に記載した認証コードの入力か、マジックリンクのクリックで疎通確認最も確実ユーザーアクションが必要。SMS送信コストが発生する

3のSMS送信による認証は、以下の2パターンが考えられる。

項目認証コード（OTP）方式マジックリンク方式
説明ランダムなコード（例：6桁の数字）をSMSで送信し、ユーザーがフォーム入力認証用のURL（マジックリンク）をSMSで送信し、ユーザーがクリックして認証を完了
ユーザー体験❌ ユーザーがコードをコピー&ペースト、または手入力する手間が発生する
✅多くのサービスで実用されており、広く浸透している		✅ リンクをタップするだけで認証が完了し、スムーズ
⚠️リンクをタップすることに警戒心を持つユーザーも存在する
セキュリティ✅️標準的だが、フィッシングによるコードの窃取やSMSインターセプトのリスクは存在する⚠️ トークンの適切な管理（有効期限、ワンタイム利用）が必須
実装の容易さ✅ 既存ライブラリを利用しやすい❌ セキュアなトークン管理やURLの有効期限管理など、考慮事項が多く複雑になりがち
送信コスト❌ SMS送信コストが発生❌ SMS送信コストが発生（URLが長くなると複数通分になる可能性も）
互換性✅ SMSが受信できる全てのデバイス（フィーチャーフォン含む）で利用可能⚠️スマートフォンなど、SMSから直接ブラウザを開けるデバイスに限定される

推奨は以下の通り。

  • フォーマット検証はフォーム入力時に必須で行う
  • 電話番号検証APIの利用は任意とする
    • SMS送信数を減らすことの優先度が高いサービス特性の場合は、導入を検討する
    • 電話番号検証APIを挟んでも、SMS送信による認証プロセスは必ず含める
  • マジックリンク方式を第一に考える
    • 特に年齢層が上のユーザーは、OTP方式の場合に離脱率が高く、ユーザーサポートが大変になるため
  • マジックリンクは、ユーザー操作がアプリの場合は、ディープリンク形式で送信する
    • Webサービス経由の場合は、通常のリンク形式で送信する
  • 若者中心のサービスの場合は、認証コード（OTP）送信を採用しても良い
    • デジタルネイティブ世代の多くがOTP方式に慣れている
    • Twilio、Vonage、Auth0など信頼できるプラットフォームがサポートし、導入が容易かつ業界標準的である
      • ライブラリが対応しているので実装コストが低い

OTP方式の実装考慮点

セキュリティ面では以下を考慮する。

  • 安全な乱数生成器を用いる（信頼できるサードパーティ製のライブラリを用いる）
  • 桁数は最低でも6桁を推奨
  • 一度認証に成功したコードの再利用を不可にする
  • コードは短期間（例：5～10分）で無効化する
  • 同じユーザーに対する試行回数を制限する（例：3回失敗でそのコードを無効化し、再発行を促す）
  • SMS送信のレートリミットをかけ、余計な送信コストを発生させないようにする（≒ SMSボム攻撃への対応を講ずる）
  • SMS本文に 「●●（サービス名）の認証コードです。このコードを他人と共有しないでください」といった情報を含め、フィッシング詐欺から守る工夫をする

マジックリンク方式の実装考慮点

マジックリンクに含まれるトークンは、OTP方式のコードと同様の対応を取る。また、以下の点に気をつける。

  • HTTPヘッダで Referrer-Policy: strict-origin-when-cross-origin を設定する
    • マジックリンクをクリックして認証された後、ユーザーがサイト上の外部リンクをクリックすると、マジックリンクのURL（＝トークン）がRefererヘッダとして遷移先サイトへ漏洩する危険があるため

SMSコスト管理 ​

SMSはメールに比べて運用費用が高いため、コスト管理を重視すべきである。

推奨は以下の通り。

  • SMSではなくメールやアプリ通知などで代替できないかを検討する
  • 1通あたりの単価と想定送信数を基に、SMS利用の予算計画を立てる
  • 送信サービスのダッシュボードで実績値を継続的に監視し、予算超過や送信通数の急増を知らせるアラートを設定する
  • 開発・検証環境では、SMSのモック化やサンプリング（許可された特定の電話番号にのみ送信を制限）を検討する

SMSサービスの選定 ​

SMSの配信経路は、大きく分けて以下の2種類に分類される。

#（1）国際網ゲートウェイ（2）国内直収ゲートウェイ
説明海外の通信網を経由して、国内携帯キャリア網に接続される経路日本のSMS送信事業者が、国内携帯キャリアの設備と直接接続してSMSを配信する経路
到達率⚠️不安定（キャリアによるブロックがされやすい）✅️非常に高い
コスト（1通あたり）✅️安価⚠️やや高価
送信者IDの設定⚠️制限あり（多くは数字の羅列）✅️柔軟（サービス名を英数字で設定可）
配信速度⚠️不安定な場合あり✅️高速・安定

推奨は以下の通り。

  • 原則、（2）を選択する（コストよりも到達の確実性を優先する）
    • 特に本人認証や重大な通知などのクリティカルな用途では、メッセージ不達は致命的であるため
    • 送信者IDをサービス名にすることで、ユーザーが安心してSMSを開ける（ユーザー体験を向上できる）
    • 不達によるビジネス上の機会損失や、SMSが届かないといった問い合わせコストを防ぐため
  • キャリアが定める送信ルール（例：1日の上限数）を遵守する

Copyright 2026 by Future Corporation