SMS認証の実装方法を開発者向けに解説｜発行〜突合のシーケンスとコード例・落とし穴チェックリスト

自社のWebサービスやアプリに、SMS（ショートメッセージ）を使った本人確認や二段階認証を組み込むことになった――。担当として最初に知りたいのは「SMS認証を実装するとは、サーバー側のコードで具体的に何を書くことなのか」ではないでしょうか。仕組みやメリットの解説はすでに読んだうえで、いま欲しいのは処理の流れと、真似できる実装の形です。

SMS認証の中身は、突き詰めると「生成・保存・送信・突合」の4つの処理に整理できます。ランダムな認証コードを生成し、有効期限付きでサーバー側に保存し、SMS送信APIで携帯電話番号に送り、ユーザーが入力したコードを突き合わせて一致すれば認証を通す――この4つをどこにどう書くか、とりわけ送ったコードと入力値をどう保持して照合するか（保存先・有効期限・試行回数）がイメージできれば、実装に着手できます。

本記事は、SMS認証をこれから実装する開発者に向けて、発行から突合までのシーケンス、写経できるコード例、サーバー側の保存設計、自前実装とVerify系APIの使い分け、実装で踏みやすい落とし穴を、NISTやOWASPのガイドラインに沿って整理したものです。最後に、送信を委ねるSMS送信APIを実装観点で選ぶための比較材料もまとめています。

SMS認証実装の全体像：認証コード発行〜突合のシーケンス

まずは、SMS認証で自分が書く処理の全体像を押さえます。特定のサービスに依存しない、どのSMS送信APIにも当てはまる一般的なワンタイムパスワード（OTP：一度だけ使える認証コード）認証の流れは、次の順序で進みます。

1. 認証コードの生成：サーバー側でランダムな数字コード（6桁が目安）を生成する。
2. コードの保存：生成したコードを、ユーザーやセッションに紐づけて有効期限とともにサーバー側に保存する。
3. SMS送信：SMS送信APIを呼び出し、ユーザーの携帯電話番号にコードを本文として送る。
4. ユーザー入力：ユーザーが受け取ったコードを画面で入力する。
5. サーバー側の突合：入力値と保存済みコードを照合し、有効期限内・試行回数内で一致すれば認証成功とし、コードを失効させる。

この流れで自分が書くのは「1・2・5」のサーバー側処理と、「3」でSMS送信APIを呼ぶ部分です。SMSの物理的な送信は自前ではできないため、送信は外部のSMS送信APIに委ねます。コードの生成・保存・突合を自前で実装するか、この一連をまとめて肩代わりするVerify系APIに任せるかで実装量が変わりますが、まずは自前で書く前提で全体像を掴むと、どの処理を外に出せるかが判断しやすくなります。

5つの処理と、それぞれの担当（サーバー／SMS送信API／ユーザー）を図にまとめると、次のとおりです。

認証コードの桁数・有効期限・使い捨ての扱いには、米国国立標準技術研究所（NIST）が公開する電子的な本人確認のガイドライン「SP 800-63B」に具体的な基準があります。SMSのような電話網（PSTN）経由のOTPについては、次のように定めています。

The verifier SHALL generate random authentication secrets that are at least six decimal digits (or equivalent) in length using an approved random bit generator as described in Sec. 3.2.12.

In all cases, the authentication SHALL be considered invalid unless completed within 10 minutes.

出典：NIST SP 800-63B-4 §3.1.3.2 Out-of-Band Verifiers｜NIST

要点は、認証コードは承認された乱数生成器で6桁以上を生成すること、そして認証は発行から10分以内に完了しなければ無効とすること。この基準を頭に置いてシーケンスを実装すると、桁数や有効期限で迷わずに済みます。

出典・参考資料（1件）

• 出典：NIST Special Publication 800-63B-4 Digital Identity Guidelines: Authentication and Authenticator Management｜NIST（https://pages.nist.gov/800-63-4/sp800-63b/authenticators/）

写経できる実装コード例

ここからは、シーケンスの各処理を実際のコードに落とし込みます。言語はPythonを例にしますが、考え方はどの言語でも共通です。SMS送信APIへのリクエストはcurlで示すので、使う言語のHTTPクライアントに置き換えてください。

事前準備：SMS送信APIのアカウントとAPIキー取得

実装の前に、SMSを送るためのSMS送信APIのアカウントを用意し、APIキー（またはトークン・接続用ID）を取得します。多くのサービスはサンドボックス（本番課金なしで動作確認できるテスト環境）を提供しているので、まずはテスト用のキーで動かすと安全です。取得したAPIキーは、後述のとおりソースコードに直接書かず、環境変数などで管理します。

認証コードの生成（乱数・桁数）

認証コードは、推測されにくい安全な乱数で生成します。Pythonなら暗号用途向けのsecretsモジュールを使い、6桁のゼロ埋め文字列を作ります。通常のrandomは予測可能なため、認証コードには使いません。

import secrets

def generate_code() -> str:
    # 承認された乱数生成器で6桁のOTPを生成（000000〜999999のゼロ埋め）
    return f"{secrets.randbelow(1_000_000):06d}"

桁数を増やせば総当たりの難易度は上がりますが、ユーザーの入力負担も増えます。NISTの基準に沿って6桁を下限の目安とし、要件に応じて調整します。

SMS送信APIへのリクエスト（curlの実物）

生成したコードを本文に載せて、SMS送信APIに送信をリクエストします。多くのサービスはHTTPSのREST API（POSTでJSONまたはフォーム値を送る形式）を提供しており、認証はAPIキーによるBasic認証やトークンヘッダが一般的です。

以下は代表的な形のcurl例です。エンドポイントURL・パラメータ名・認証方式は各サービスで異なるため、実際の値は利用するサービスのAPI仕様書で確認してください。

curl -X POST "https://<sms-api-endpoint>/messages" \
  -u "<API_KEY>:<API_SECRET>" \
  -d "to=+819012345678" \
  -d "body=認証コードは 123456 です（10分間有効）"

宛先番号は、後述するE.164形式（+81始まりの国際表記）に正規化してから渡します。送信リクエストのレスポンスには送信ID（メッセージID）が含まれることが多く、送信の成否や到達状況を後から確認する際に使います。

発行ハンドラ：正規化・生成・ハッシュ化・保存・送信をまとめる

ここまでの部品を、コード発行のエンドポイント1本にまとめます。電話番号をE.164形式に正規化し（正規化関数は後述の落とし穴チェックリストで示します）、コードを生成してハッシュ値で有効期限付きに保存し、SMS送信APIを呼ぶ流れです。

import hashlib, json

TTL_SECONDS = 600   # 有効期限10分（NISTの上限）

def issue_code(user_id: str, phone: str) -> None:
    code = generate_code()                       # 6桁のOTPを生成
    record = {
        "code_hash": hashlib.sha256(code.encode()).hexdigest(),  # 生でなくハッシュで保持
        "attempts": 0,
    }
    # TTL付きで保存（期限切れは自動失効。store は Redis 等のインメモリストア）
    store.set(f"otp:{user_id}", json.dumps(record), ex=TTL_SECONDS)
    # ※総当たり対策の失敗カウンタはアカウント単位で別キー（例 otp_fail:{user_id}）に持ち、
    #   再発行では初期化しない（後述「試行回数カウント」。NIST: 再発行で失敗カウントをリセットしない）
    send_sms(to_e164_jp(phone), f"認証コードは {code} です（10分間有効）")  # SMS送信APIを呼ぶ

send_smsは前掲のcurlに相当するSMS送信API呼び出し、to_e164_jpは電話番号の正規化関数です。保存先・有効期限・ハッシュ化の設計判断は次章で詳しく扱います。

ユーザー入力の突合（一致判定・有効期限・試行回数）

エンドポイントの2本目は、ユーザーが入力したコードの突合です。保存済みレコードを読み出し、有効期限切れと試行回数の超過をチェックしたうえで照合します。文字列比較は、比較時間の差から値を推測されるタイミング攻撃を避けるためhmac.compare_digestで行い、一致したコードはその場で失効させて使い捨てにします（同じコードの再利用＝リプレイを防ぐため）。

import hmac, hashlib, json, time

MAX_ATTEMPTS = 5

def verify_code(user_id: str, input_code: str) -> str:
    raw = store.get(f"otp:{user_id}")
    if raw is None:
        return "expired"                    # 未発行または有効期限切れ（TTLで消滅）
    rec = json.loads(raw)
    if rec["attempts"] >= MAX_ATTEMPTS:
        store.delete(f"otp:{user_id}")       # 試行回数超過でコードを無効化
        return "too_many_attempts"
    rec["attempts"] += 1
    input_hash = hashlib.sha256(input_code.encode()).hexdigest()
    if hmac.compare_digest(rec["code_hash"], input_hash):
        store.delete(f"otp:{user_id}")       # 一致したら即失効（使い捨て＝リプレイ耐性）
        return "approved"
    store.set(f"otp:{user_id}", json.dumps(rec), keepttl=True)  # 残りTTLを維持
    return "mismatch"

ここでのポイントは、失敗するたびに試行回数を加算し、一致したコードは即座に削除することです。保存方式・有効期限の分数・試行回数のカウント方法といった設計判断は、次章でまとめて整理します。

送信テストとサンドボックス確認

実装したら、サンドボックスや自分の番号への送信テストで、コードが届くこと・突合が通ることを確認します。サンドボックスで成功しても本番でエラーになることがあるため、本番切り替え時はAPIキーの差し替えと送信元設定を改めて確認します。到達しない場合は、番号の正規化ミス・送信元の登録漏れ・キャリア側の受信拒否などを順に切り分けます。

サーバー側の保存設計：認証コードをどこに保持しどう照合するか

ここからは、認証コードをサーバー側でどう持つかを設計します。実装で迷いやすいのは、保存先・保存形式・有効期限・試行回数の4点です。それぞれ、なぜその方式にするのかの根拠とあわせて整理します。

保存先の選択（DB / セッション / Redis）とトレードオフ

認証コードは短命なデータなので、有効期限（TTL）を設定できるインメモリストア（RedisやMemcachedなど）に置くのが扱いやすい選択です。TTLを設定すれば、期限切れのコードが自動で消え、失効処理を自前で書く手間が減ります。

• Redis等のインメモリストア：TTLで自動失効でき、複数サーバー構成でも共有しやすい。短命データに最も向く。
• リレーショナルDB：既存テーブルに持たせられるが、期限切れレコードの削除バッチを自前で用意する必要がある。
• セッション：実装は簡単だが、サーバーをまたぐ構成やセッション固定攻撃への配慮が必要で、短命コードの保持先としては制約が出やすい。

ハッシュ化保存の要否

認証コードは短命とはいえ、保存中に漏えいすれば認証を突破されます。前掲のコードのように、生のコードではなくハッシュ値で保存し、突合時は入力値をハッシュ化して比較すると、保存データが読まれても即座には悪用されにくくなります。パスワードほど長期間保持しないため計算コストの高いアルゴリズムは不要ですが、生のまま保存するのは避けるのが無難です。

有効期限の設計（何分・失効の扱い）

有効期限は、短すぎるとSMSの到着遅延で正規ユーザーが弾かれ、長すぎると盗まれたコードの悪用余地が広がります。前掲のNISTの基準では「10分以内に完了しなければ無効」が上限です。Verify系APIの既定値も、Twilioが10分、Vonageが5分と、おおむね5〜10分に収まっています。特段の理由がなければ、有効期限は5〜10分を目安に設定するのが妥当です。

なお、解説記事によっては15分などの例も見られますが、これはNISTの上限（10分）を超える設定です。10分を超える値を採る場合は、規格上限を超える選択だと認識したうえで、リスクとあわせて判断してください。

出典・参考資料（3件）

• 出典：NIST Special Publication 800-63B-4 §3.1.3.2 Out-of-Band Verifiers｜NIST（https://pages.nist.gov/800-63-4/sp800-63b/authenticators/）
• 出典：Verify API Rate Limits and Timeouts（既定10分）｜Twilio Docs（https://www.twilio.com/docs/verify/api/rate-limits-and-timeouts）
• 出典：What is the validity period for Verify PIN codes?（既定5分）｜Vonage API Support（https://api.support.vonage.com/hc/en-us/articles/203823346）

試行回数カウント＝コード単位の総当たり失効

6桁のコードは100万通りしかないため、総当たり（ブルートフォース）で突破される余地があります。NISTは、認証コードが64ビット未満の場合はレート制限を必須（SHALL）とし、失敗回数の扱いについて次のように定めています。

If the authentication secret is less than 64 bits long, the verifier SHALL implement a rate-limiting mechanism that effectively limits the total number of consecutive failed authentication attempts that can be made on the subscriber account as described in Sec. 3.2.2. Generating a new authentication secret SHALL NOT reset the failed authentication count.

出典：NIST SP 800-63B-4 §3.1.3.2 Out-of-Band Verifiers｜NIST

実装上とくに重要なのは後半の一文で、新しいコードを再発行しても、失敗カウントをリセットしてはならないという点です。再送のたびにカウントがゼロに戻る作りだと、攻撃者は再送を繰り返して事実上無制限に総当たりできてしまいます。

そのため、総当たり対策の失敗カウントは、個々のコードのレコードとは別に、アカウント単位のキーで持ちます。前掲のverify_codeのMAX_ATTEMPTSが1つのコードに対する入力上限を担うのに対し、こちらは再発行をまたいでも初期化しないアカウント単位のカウンタです。

このアカウント単位のカウンタが上限に達したら、一定時間ロックします。NISTは連続失敗を100回までに制限し、それを超えたら当該認証手段を無効化するよう求めています。

出典・参考資料（1件）

• 出典：NIST Special Publication 800-63B-4 §3.1.3.2 / §3.2.2 Rate Limiting (Throttling)｜NIST（https://pages.nist.gov/800-63-4/sp800-63b/authenticators/）

突合エラー別のレスポンス設計（不一致・期限切れ・試行超過）

突合の結果は、単なる成功・失敗の二値ではなく、原因別に扱うと画面表示や再送導線を設計しやすくなります。前掲のverify_codeは、コードの保存状態に由来する次の結果を返しています。

• approved（一致）：認証成功。コードは即失効させる。
• mismatch（不一致）：入力ミスの可能性。試行回数を消費したうえで再入力を促す。
• expired（期限切れ／未発行）：有効期限切れ。再送を案内する。
• too_many_attempts（試行超過）：総当たりの疑い。一定時間ロックする。

なお、これらはあくまで「保存したコードとの突合」で起きるエラーです。SMSがそもそも届かない・送信APIが送信を拒否したといった送信側のエラーは性質が異なるため、後述の落とし穴チェックリストで別に扱います。

自前実装 vs Verify系API の設計判断

ここまでは、コードの生成・保存・突合を自分で実装する前提で見てきました。もう一つの選択肢が、これらをまとめて肩代わりするVerify系API（認証専用API）を使う方法です。両者は実装量とコントロールのトレードオフにあり、どちらが適するかは要件で変わります。

自前実装：SMS送信APIだけを使い、突合は自分で持つ

SMS送信APIは「送る」ことだけを担い、コードの生成・保存・有効期限・試行回数・突合は自分のコードで実装します。前章までのコードがこの形です。認証ロジックを自社で完全に制御でき、監査ログの粒度や画面挙動を細かく設計できる反面、有効期限やレート制限といったセキュリティ要件を自分で正しく実装する責任を負います。

Verify系API：突合までベンダーに任せる

Verify系APIは、コードの生成・送信・検証を単一のAPIで完結させます。開発側はコードの発行リクエストと検証リクエストの2回を呼ぶだけで、トークン管理・有効期限・レート制限はベンダー側が持ちます。送信と検証は、次のように2回のリクエストで呼び出す形が一般的です（エンドポイントやパラメータ名は各Verify系サービスで異なります）。

# コードの発行・送信（生成はVerify側が担う）
curl -X POST "https://<verify-api-endpoint>/verifications" \
  -u "<API_KEY>:<API_SECRET>" \
  -d "to=+819012345678" -d "channel=sms"

# ユーザー入力の検証（突合もVerify側が担う）
curl -X POST "https://<verify-api-endpoint>/verification-check" \
  -u "<API_KEY>:<API_SECRET>" \
  -d "to=+819012345678" -d "code=123456"
# レスポンスの status（例）: approved（一致） / pending（未検証） / max_attempts_reached（試行超過）

宛先はE.164形式が必須で、検証レスポンスのステータスにapproved（一致）やmax_attempts_reached（試行超過）が返るため、突合結果のハンドリングもステータスを見るだけで済みます。有効期限やレート制限を自前で書かずに済む一方、認証ロジックの細部はベンダーの仕様に従うことになります。

出典・参考資料（1件）

• 参考資料：Verify API – Verifications / VerificationCheck｜Twilio Docs（https://www.twilio.com/docs/verify/api/verification）

どちらを選ぶか

認証ロジックを自社で細かく制御したい、既存の認証基盤に組み込みたい、送信通数の従量課金だけに抑えたい場合は自前実装が向きます。一方、実装・運用の負荷を下げたい、有効期限やレート制限を自前で作り込むリスクを避けたい、SMS以外のチャネル（音声・アプリ認証など）にも広げたい場合はVerify系APIが向きます。

国内サービスでも、認証コードの生成・照合までをAPIで肩代わりする認証専用プランを持つものと、SMS送信に特化して突合は利用企業側に委ねるものがあり、この違いはサービス選定にも直結します。

実装の落とし穴チェックリスト

ここからは、実装前に潰しておきたい落とし穴を、なぜ危ないかとあわせてチェックリスト形式で整理します。指差し確認に使ってください。

電話番号のE.164正規化（+81・先頭0削除）

SMS送信APIの多くは、宛先番号をE.164形式（国番号を含む国際表記）で要求します。日本ネットワークインフォメーションセンター（JPNIC）は、E.164番号を「国番号を含む最大15桁の10進数字列」と定義し、日本の番号は国番号81を付けて市外局番の先頭0を除く、と説明しています。

たとえば03-5297-2311(JPNICの代表電話番号)をE.164番号にすると、日本の国番は81、市外局番03の0をとって3とし「+81-3-5297-2311」となります。

出典：インターネット用語1分解説〜E.164番号とは〜｜JPNIC

携帯番号も同様で、090-1234-5678は+819012345678になります。ユーザー入力はハイフンや空白が混じるため、数字以外を除去し、先頭の0を落として+81を付ける正規化を必ず通します。

import re

def to_e164_jp(phone: str) -> str:
    digits = re.sub(r"\D", "", phone)   # 数字以外（ハイフン・空白・+）を除去
    if digits.startswith("81"):
        return "+" + digits             # 既に国番号付き（81…）ならそのまま
    if digits.startswith("0"):
        digits = digits[1:]             # 国内表記の先頭0を除去
    return "+81" + digits               # 日本の国番号を前置

出典・参考資料（2件）

• 出典：インターネット用語1分解説〜E.164番号とは〜｜JPNIC（https://www.nic.ad.jp/ja/basics/terms/E164.html）
• 参考資料：What is E.164?｜Twilio Docs（https://www.twilio.com/docs/glossary/what-e164）

再送制御・送信間隔とレート制限（送信の外形的抑止）

前章の試行回数カウントが「入力の突合を何回まで許すか」だったのに対し、こちらは「送信そのものを何回まで許すか」です。再送ボタンを連打できると、再送スパムや、大量送信で課金を枯渇させる攻撃（SMSポンピング）の入口になります。OWASPは、SMSを使う場合の対策としてアカウント単位のレート制限を挙げ、課金を狙った攻撃について次のように指摘しています。

Calls and SMS messages may cost money to send need to protect against attackers requesting a large number of messages to exhaust funds.

出典：Multifactor Authentication Cheat Sheet｜OWASP Cheat Sheet Series

実装では、再送に一定の待機時間（たとえば60秒）を設けてUI上もその間はボタンを押せないようにし、あわせてサーバー側でも同一番号・同一アカウントあたりの送信回数を制限します。有効期限や入力の試行回数カウントは前章のサーバー側保存設計で扱ったとおりで、ここでは送信の外形的な抑止を担当します。

出典・参考資料（1件）

• 出典：Multifactor Authentication Cheat Sheet｜OWASP Cheat Sheet Series（https://cheatsheetseries.owasp.org/cheatsheets/Multifactor_Authentication_Cheat_Sheet.html）

認証情報の秘匿（公開リポジトリに置かない）

SMS送信APIのAPIキーやトークンは、ソースコードに直書きせず、環境変数やシークレット管理サービスで管理します。うっかり公開リポジトリにコミットすると、第三者に送信を悪用され、課金や不正送信の被害につながります。.envファイルは.gitignoreで除外し、キーが露出した場合は速やかにローテーション（再発行）します。

送信失敗のハンドリング（送信側エラー）

突合エラーとは別に、SMSがそもそも届かないケースに備えます。番号の誤り、解約済み番号、データ専用SIM（SMSを受信できない）、キャリア側の受信拒否など、送信側の失敗にはユーザーには再入力ではなく別手段を案内する必要があります。

送信APIのレスポンスコード（4xxはリクエスト不備、5xxは一時障害）で原因を分類し、一時障害には指数バックオフ（間隔を空けて再試行）を、恒久的な不達には音声通話やメールなどの代替経路を用意すると、正規ユーザーの離脱を防げます。

日本固有の実装事情：到達率・なりすまし・課金攻撃

日本で実装する場合、いくつか固有の事情があります。まず到達率です。国内キャリア（NTTドコモ・au・ソフトバンク・楽天モバイル）と直接接続（直収）しているSMS送信サービスは、国際回線を経由する事業者より到達率と到着速度で有利になりやすく、認証コードの不達は離脱に直結するため、サービス選定の重要な軸になります。

次に不正利用への備えです。総務省は令和7年（2025年）4月23日、電気通信事業者に対し、固定・携帯電話、SMS及びメールを悪用した特殊詐欺等への対応を要請し、その背景として特殊詐欺に利用された電話番号で国際電話が急増していることに触れています。国が電話・SMSの悪用を問題視している状況は、送信元（送信者ID）の適切な設定や、国際回線経由の番号の扱いに注意を払う実務的な理由になります。

出典・参考資料（1件）

• 出典：固定・携帯電話、SMS及びメールを悪用した特殊詐欺等に対する対応に関する要請の実施（令和7年4月23日）｜総務省（https://www.soumu.go.jp/menu_news/s-news/01kiban18_01000251.html）

SMS認証そのもののセキュリティ上の限界を知っておく

実装の前提として、SMS認証には方式としての限界があることも押さえておきます。NISTは、電話網経由のOTPを唯一の「制限付き認証手段（restricted authenticator）」と位置づけ、フィッシング耐性がないとしています。

OWASPも、SS7という電話網の信号方式を悪用した傍受や、携帯番号を乗っ取るSIMスワップ、認証する端末と同じ端末でSMSを受け取ってしまう問題を挙げ、高価値・個人情報を扱う用途ではSMSに頼りすぎないよう促しています。

Verifiers SHOULD consider risk indicators (e.g., device swap, SIM change, number porting, other abnormal behavior) before using the PSTN to deliver an out-of-band authentication secret.

出典：NIST SP 800-63B-4 §3.1.3.3｜NIST

実装レベルでは、SIMスワップや番号ポーティングの兆候を監視し、重要度の高い操作ではSMS単独に頼らず、認証アプリ（TOTP）やパスキー（WebAuthn/FIDO2）への移行も選択肢に入れておくと、方式の限界に引きずられずに済みます。

出典・参考資料（2件）

• 出典：NIST Special Publication 800-63B-4 §3.1.3 / §3.1.3.3｜NIST（https://pages.nist.gov/800-63-4/sp800-63b/authenticators/）
• 出典：Multifactor Authentication Cheat Sheet｜OWASP Cheat Sheet Series（https://cheatsheetseries.owasp.org/cheatsheets/Multifactor_Authentication_Cheat_Sheet.html）

実装を委ねるSMS送信APIの選び方

実装の全体像が掴めたら、次は「では、どのAPIで送るか」です。SMSの送信は外部サービスに委ねるため、実装観点でサービスを選ぶことになります。ここでは、選定で見るべき比較軸を整理し、代表的なサービスを紹介します。

ここでは実装のしやすさを軸にサービスを絞って紹介します。料金やメリット、本人確認のやり方まで含めてSMS認証サービス全体を広く見比べたい場合は、以下の比較記事もあわせてご覧ください。

実装観点の比較軸

実装のしやすさと運用コストを左右するのは、次の観点です。自社が自前実装とVerify系APIのどちらで進めるかによって、重視する軸が変わります。

• API種別：HTTPSのREST APIか、各言語のSDKが提供されるか、SMPPなど専用プロトコルに対応するか。
• 認証方式：APIキー、Basic認証、IP認証、トークンなど、リクエスト認証の方式。
• OTP専用（Verify系）APIの有無：コードの生成・照合まで肩代わりする認証専用APIがあるか、送信のみで突合は自前か。
• 国内直収・到達率：国内キャリアへの直接接続の有無と、公表されている到達率。
• 料金：初期費用・月額・送信従量単価、または認証成功単位の課金か。

以下はご紹介するSMS送信・SMS認証サービスの比較表です。

※料金・機能は2026年8月時点の各社公式情報にもとづきます。「要問い合わせ」は金額・条件が公開されていない項目です。到達率は各社の公表値・訴求値で測定条件は各社により異なり、Twilio Verifyの94%はグローバル網の到達率です。Twilio VerifyはUSD建てのため円換算は為替の影響を受けます。最新の料金・API仕様は各社の公式ドキュメント・料金ページでご確認ください。

オーロラSMS by メディアSMS（株式会社メディア4u）

株式会社メディア4uが提供するSMS送信サービスのうち、本人確認・認証コード送信に特化した枠が「オーロラSMS by メディアSMS（SMS認証ソリューション）」です。認証専用のAPIを備え、ワンタイムパスワードの生成・送信・照合判定をワンステップで実装できるため、認証コードの管理・照合ロジックを自社で持たずにSMS認証を組み込めます。突合までを任せたいVerify系の使い方に向いています。

3大キャリア（NTTドコモ・au・ソフトバンク）への直接接続・直収設計により、到達率99.9%を公式に掲げています。SMSが届きにくいケースに備え、IVR（自動音声応答）による認証コード通知を補完手段として組み合わせられる点も特徴です。初期費用・月額基本料は0円で送信成功分のみの従量課金、最大2か月の無料トライアルがあり、スモールスタートしやすい料金体系です。

SMSLINK（ネクスウェイ）

ネクスウェイが手がける法人向けSMS送信サービスがSMSLINKです。提供形態は、管理画面から送るWebタイプと、既存システムやCRMと連携して自動配信するAPIタイプの2種類があります。認証機能として、認証コードの生成からSMS・音声での送信、認証チェックまでの一連をAPI連携で運用できる仕組みを公式に提供しており、二要素認証・OTP配信の用途を想定しています。

国内4キャリアすべてと直接接続し、到達率を重視した設計を掲げています。FAX・郵送・メールを長年提供してきた事業基盤を活かし、低価格帯を訴求している点も選定材料になります。まずWebタイプで小さく始め、後からAPI連携へ広げるといった段階的な導入もしやすいサービスです。

到達率が選定軸として重視される背景に、認証コードの不達が他社からの乗り換え理由になりやすいという実務の実感があります。この点について、同サービスを提供するネクスウェイの担当者は次のように述べています。

絶対リーチ！SMS（AI CROSS株式会社）

AI CROSSが提供する絶対リーチ！SMSは、プロモーションから認証まで幅広い用途に対応するSMS送信サービスです。本人認証向けには専用の「セキュアSMS認証」プランを用意し、確認コード・ワンタイムパスワードを自動生成して送信するため、利用者側で認証コードの発番機能を開発する必要がない点を明記しています。突合の実装負担を抑えたいケースに向きます。

API連携は、HTTPSのWeb APIに加え、SMPP v3.4にも対応するマルチプロトコル構成で、CRMやコンタクトセンターなど既存システムへの組み込みに幅があります。IVRを悪用した認証コードの不正取得を阻止する「セキュアSMS認証」は特許を取得した技術です。認証系プランの料金は要問い合わせのため、実費は個別に確認が必要です。

KDDI Message Cast（KDDI／Supership）

KDDIとSupershipが共同運営するKDDI Message Castは、SMS・RCS・＋メッセージを配信できる法人向けメッセージ配信サービスです。SMS送信API（HTTPS API）を経由して、会員登録時のSMS認証やログイン時の二段階認証に組み込めます。

汎用のSMS配信サービス上で認証コードを送る形態のため、コードの生成・検証ロジックは利用企業側で実装する、自前突合型の使い方になります。

公式でSMS送信APIの実装ガイドやコード例が公開されるなど、開発者向けの情報が整っています。共通番号による国内キャリアへの直収接続で到達率を確保し、RCSが届かない場面ではSMSへ自動でフォールバックする仕組みも備えます。既存システムのSMS送信を担う基盤として選びやすいサービスです。

Twilio Verify（Twilio）

Twilio Verifyは、ワンタイムパスワードの生成・送信・検証を単一のAPIで完結させる認証専用APIです。開発側はトークン管理やレート制限を自前実装せずに二要素認証を組み込めます。

SMSに加え、音声・WhatsApp・TOTP（認証アプリ）・パスキーなど複数のチャネルを1つのAPIで切り替えられるマルチチャネル型で、突合までベンダーに任せたい設計にそのまま合致します。

REST APIと各言語のSDK（Node.js・Python・PHP など）が揃い、数行でOTPを組み込める設計です。生成トークンの有効期限は既定10分。料金は認証成功1回あたりの従量課金で、チャネルごとのメッセージ送信料が別途加算されます。USD建てのため、円換算では為替の影響を受けます。国内向けの単価は公式の料金ページで確認してください。

SORACOM Cloud SMS Delivery（ソラコム）

IoTプラットフォーム「SORACOM」を提供するソラコムのSMS送信サービスが、SORACOM Cloud SMS Deliveryです。すべての操作をAPIで行える設計で、自社システムからAPIを呼び出してSMSを送る、開発者向けのポジションが特徴です。

本人認証・二要素認証の用途では、ワンタイムパスワードの発行・検証を担う「SORACOM Cloud MFA」と組み合わせ、最小限のコードで認証コードの送信・検証を実装します。

国内4キャリアへ直接接続し、MVNOを含む幅広い番号に送信できます。料金は初期費用0円、月額30,000円（税抜、月5,000通を含む＝1通あたり換算6円）で、5,000通を超えた分の単価は要問い合わせです。既存のSORACOM利用者はアカウント・請求を統合して使える点も、IoT・開発者向けならではの利点です。

まとめ

SMS認証の実装は、認証コードの生成・保存・SMS送信・突合という4つの処理に整理できます。自分で書くのは生成・保存・突合のサーバー側処理で、送信は外部のSMS送信APIに委ねます。桁数は6桁以上、有効期限は5〜10分、コードは一致後に即失効させ、試行回数は再送でリセットしない――このあたりの勘所を、NISTやOWASPの基準に沿って押さえておけば、大きな穴は避けられます。

突合まで自前で持つか、Verify系APIに任せるかは、制御の細かさと実装・運用負荷のトレードオフで決めます。そのうえで、実際に送信を委ねるサービスは、API種別・認証方式・OTP専用APIの有無・国内直収と到達率・料金といった実装観点で比較して選ぶと、後戻りが少なくなります。まずは気になるサービスの資料やAPI仕様を取り寄せ、サンドボックスで送信を試すところから始めてみてください。

実装のめどが立ったら、次はサービスの選定と導入の段取りです。料金比較やAPI連携の進め方、導入までの検討手順は以下の記事でくわしく解説しています。

よくある質問（FAQ）

Q. SMS認証の認証コードは何桁にすべきですか？

A. SMS認証の認証コードは、6桁以上の数字を目安にします。NIST SP 800-63Bは、承認された乱数生成器で6桁以上を生成するよう求めています。桁数を増やすほど総当たりには強くなりますが入力負担も増えるため、通常は6桁とし、予測されにくいよう暗号用途の乱数生成器（Pythonならsecretsモジュール）で生成します。

Q. SMS認証コードの有効期限は何分が適切ですか？

A. SMS認証コードの有効期限は、5〜10分を目安にするのが妥当です。NISTは電話網経由のOTPについて発行から10分以内に完了しなければ無効とするよう定めており、Verify系APIの既定値もTwilioが10分、Vonageが5分とこの範囲に収まります。短すぎるとSMSの到着遅延で正規ユーザーが弾かれ、長すぎると盗まれたコードの悪用余地が広がるため、この範囲に収めます。

Q. SMS認証は自前実装とVerify系APIのどちらを選ぶべきですか？

A. SMS認証は、認証ロジックを細かく制御したいなら自前実装、実装・運用の負荷を下げたいならVerify系API（認証専用API）が向きます。自前実装はSMS送信APIで「送る」だけにとどめ、コードの生成・保存・有効期限・突合を自社で持つ方式で、監査ログや画面挙動を細かく設計できる反面、セキュリティ要件を自分で正しく実装する責任を負います。

Verify系APIは生成・送信・検証を1つのAPIで完結させ、有効期限やレート制限をベンダーに委ねられますが、認証ロジックの細部はベンダーの仕様に従います。

Q. SMS認証とは何ですか？

A. SMS認証とは、携帯電話のSMSに送った使い捨ての認証コード（ワンタイムパスワード）を入力させ、その電話番号の持ち主本人であることを確認する認証方式です。実装の観点では、サーバー側でコードを生成・保存し、SMS送信APIで番号に送り、ユーザーの入力値を突き合わせる4つの処理で構成されます。パスワードに加える二段階認証の2要素目として使われることが多い方式です。

Q. SMS認証で総当たり（ブルートフォース）攻撃を防ぐにはどうすればよいですか？

A. SMS認証の総当たりは、アカウント単位で連続失敗回数を制限し、コードを再発行しても失敗カウントをリセットしないことで防ぎます。6桁コードは100万通りしかなく、NISTは64ビット未満のコードにレート制限を必須としています。

再送のたびにカウントが0に戻る作りだと、攻撃者は再送を繰り返して事実上無制限に試せてしまうため、カウントはコードではなくアカウントに紐づけ、上限に達したら一定時間ロックします。

Q. SMS認証の電話番号のバリデーションはAPI側とアプリ側のどちらで行うべきですか？

A. SMS認証の電話番号は、アプリ側でE.164形式へ正規化したうえで、送信APIのレスポンスでも最終的な到達可否を確認する二段構えが安全です。ハイフンや先頭の0を含むユーザー入力は、アプリ側で数字以外を除去し、先頭0を落として+81を付けるE.164正規化を必ず通します。

ただし実在・到達可能な番号かどうかは送信APIのエラーレスポンスでしか分からないため、正規化はアプリ側、実到達性の判定は送信結果のハンドリングで、と役割を分けます。

Q. SMS認証コードが届かない場合はどう対処すればよいですか？

A. SMS認証コードが届かないときは、送信APIのレスポンスコードで原因を分類し、恒久的な不達には音声通話やメールなどの代替経路を案内します。番号の正規化ミス・送信元の登録漏れ・データ専用SIM（SMSを受信できない）・解約済み番号・キャリアの受信拒否などが主な原因です。

4xxはリクエスト不備、5xxは一時障害として扱い、一時障害には間隔を空けて再試行（指数バックオフ）し、恒久的な不達のユーザーには再入力ではなく別手段を用意すると離脱を防げます。

Q. SMS認証がサンドボックスでは成功するのに本番でエラーになるのはなぜですか？

A. SMS認証が本番でエラーになる主因は、APIキーの差し替え漏れと、送信元（送信者ID）や宛先番号など本番設定の登録漏れです。サンドボックスはテスト用キーと擬似的な送信で通るため、本番切り替え時は環境変数のAPIキーを本番用に差し替え、送信元設定・番号の正規化・レート制限の本番値を改めて確認します。設定が正しくても届かない場合は、キャリア側の受信拒否も順に切り分けます。

Q. SMS認証の送信元（送信者名）はどう表示されますか？

A. SMS認証の送信元は、利用するSMS送信サービスと番号の種別によって決まり、電話番号または登録した英数字の送信者ID（アルファニューメリックID）で表示されます。国内直収のサービスでは共通の番号から届くことが多く、送信者名を任意の文字列に設定できるかはサービスや国内の規制によって異なります。

詐欺対策の観点から送信元の適切な設定が求められるため、利用するサービスの仕様で表示のされ方を事前に確認します。

Q. SMS認証の実装で個人情報保護の観点から注意すべき点はありますか？

A. SMS認証では、電話番号が個人情報にあたるため、取得目的の範囲での利用・アクセス制限・保管期間の管理を徹底し、認証コード自体はハッシュ化して短期間で失効させます。番号はログや外部送信で不必要に露出させないようにし、認証コードは生のまま保存せずハッシュ値で持ち、一致後は即失効させます。

送信を委託するSMS送信サービスの安全管理体制（ISO 27001認証の有無など）も、選定時の確認点になります。

Q. SMS認証は安全ですか？SIMスワップなどのリスクはありますか？

A. SMS認証は手軽で普及していますが、フィッシング耐性がなく、SIMスワップ・番号ポーティング・SS7を悪用した傍受といった方式固有のリスクがあります。NISTは電話網経由のOTPを「制限付き認証手段」と位置づけています。

実装ではSIM変更や番号移転の兆候を監視し、重要度の高い操作ではSMS単独に頼らず、認証アプリ（TOTP）やパスキー（WebAuthn/FIDO2）への移行も選択肢に入れておくと、方式の限界に引きずられずに済みます。

SMS認証サービスの料金・仕様を一括チェック

MCB FinTechカタログでは、SMS認証サービスの最新資料をまとめて取り寄せられます。API仕様・料金・国内直収の有無などを比較しながら、自社の実装に合うサービスを効率的に検討いただけます。

MCB FinTechカタログに掲載しませんか？

MCB FinTechカタログでは、掲載企業様を募集しています。マネックスグループの金融実務ノウハウを活かした独自の評価軸と検索設計により、導入検討者が最適なサービスを効率的に発見できる法人向け比較プラットフォームです。掲載後は管理画面から料金表や導入事例を随時更新でき、常に最新の情報を訴求可能。まずは下記フォームより、お気軽にお問い合わせください。