SMS認証コードの送信・導入ガイド

SMS認証コードとは、会員登録、ログイン、パスワード再設定、決済確認などの場面で、ユーザーの携帯電話番号宛てに送る使い捨ての確認コードです。ユーザーが受信したコードを画面に入力し、システム側で照合することで、その電話番号を利用できるユーザーによる操作かを確認します。

企業が自社のWebサイトやアプリにSMS認証コードを導入する場合は、SMS送信APIを組み込むだけでは不十分です。コードを自社で生成・照合するのか、OTPサービスに任せるのかを決め、有効期限、再送信、入力失敗時の制御、未着時の対応、ログ管理まで運用フローを整理します。

先に結論

導入前に確認したいのは、APIの対応範囲、再送信・失敗時の制御、不正リクエスト対策の3点です。実装範囲と運用担当を先に決めておくと、未着調査や費用管理まで含めて設計しやすくなります。

SMS認証そのものの意味や一般的な利用方法を確認したい場合は、SMS認証とはの記事で詳しく整理しています。

SMS認証コードとは

SMS認証コードは、携帯電話番号宛てにSMSで送られる一時的なコードです。一般的には4〜6桁程度の数字が使われますが、桁数や有効期限はサービスの要件に応じて設定します。会員登録、ログイン、パスワード再設定、決済やアカウント情報の変更など、電話番号の確認や追加認証が必要な場面で利用されます。

コードは、入力した電話番号を利用している端末のメッセージアプリに届きます。認証画面には「SMSで届いたコードを入力してください」「有効期限内に入力してください」のように、受信先と次の操作を短く表示しておくと、ユーザーが迷いにくくなります。

用語の違い

「SMS認証コード」はユーザー向けの表現です。「SMS OTP」や「SMSワンタイムパスワード」は、開発やセキュリティの文脈で使われることが多く、いずれもSMSで一時的なコードを送り、入力されたコードを照合する仕組みを指します。

SMS認証コードを送信・照合する仕組み

SMS認証コードの処理では、ユーザーの操作をきっかけに、自社サービス、認証API、SMS配信基盤、認証画面が連携します。認証コードを送信しただけでは認証は完了せず、入力されたコードと対象ユーザー、有効期限、試行回数を照合する必要があります。

• 1

  ユーザーが認証を開始する

  会員登録、ログイン、パスワード再設定、決済確認などの画面で、ユーザーが電話番号を入力し、認証コードの送信を開始します。
• 2

  自社システムが認証APIを呼び出す

  自社サーバーからAPIにリクエストを送り、送信先の電話番号やテンプレートなどを指定します。
• 3

  認証コードをSMSで送信する

  OTPサービスまたはSMS配信基盤が、ユーザーの携帯電話番号宛てに認証コードを送信します。
• 4

  ユーザーがコードを入力する

  ユーザーは受信したコードを認証画面に入力します。
• 5

  コードを照合して認証を完了する

  システム側で、入力されたコード、対象ユーザー、有効期限、試行回数を確認します。条件を満たした場合だけ認証を完了し、使用済みのコードは無効にします。

SMS送信APIはメッセージの送信だけを担い、コードの生成・保存・照合は自社で実装する場合があります。OTP APIを利用する場合は、サービス側がどこまで対応するのかを確認し、自社で管理する範囲を明確にしておきましょう。

SMS認証コードを導入する前に決めること

導入前には、どの操作で認証を求めるかと、認証失敗時にどのように扱うかを決めます。会員登録やパスワード再設定では、認証の確実性と認証完了率のバランスを取ります。決済、送金、重要情報の変更では、入力試行回数の制限や追加認証など、操作のリスクに応じた制御が必要です。

実装方式にかかわらず、次の6項目を導入前に決めておきます。

SMS認証コードをAPIで導入する流れ

API導入では、接続作業を始める前に、自社で管理する範囲とAPIに任せる範囲を決めます。そのうえで、送信設定、認証画面、再送信制御、失敗ケースの順に作業を進めると、実装後の手戻りを減らしやすくなります。

• 1

  APIの対応範囲を確認する

  SMSの送信だけに対応するAPIか、認証コードの生成・照合、配信結果の確認まで含むOTP APIかを確認します。必要な機能を自社で補う場合は、担当範囲と保存するデータを整理します。
• 2

  APIと送信設定を行う

  APIキー、送信テンプレート、送信先電話番号の形式、国番号、送信元表示、コールバックなどを設定します。国や地域によって利用できる送信元やテンプレートの要件が異なる場合は、送信対象ごとに確認します。
• 3

  認証画面とSMS文面を設計する

  認証画面には、コードの受信先、有効期限、再送信までの待ち時間、未着時の操作を表示します。SMS文面にはサービス名、認証コード、用途を簡潔に入れ、不要なリンクやパスワード入力の誘導は避けます。スマートフォンでは、認証コードの自動入力候補が表示される場合があるため、サービス名と認証コードを見つけやすい位置に置きます。
• 4

  送信・照合・再送信を制御する

  有効期限、入力失敗回数、再送信間隔、旧コードの無効化を実装します。同じ電話番号やIP、端末、アカウントから短時間にリクエストが集中した場合の制限も設定します。
• 5

  正常系と失敗ケースをテストする

  正常に送信・照合できることに加え、電話番号形式の誤り、期限切れ、入力ミス、再送信、連続失敗、海外番号、通信遅延、APIエラーも確認します。失敗時にユーザーへ表示する案内と、運用担当者が確認するログをそろえておきます。

SMS認証コードが届かない・遅い時に企業側で確認すること

認証コードが届かない場合は、ユーザーに再送信を繰り返してもらう前に、入力された電話番号とAPIの処理結果を確認します。原因を切り分けられるように、送信リクエスト、配信結果、失敗理由、再送信履歴を追える状態にしておくことが重要です。

画面には「数分待ってから再送信してください」「再送信すると前回のコードは使えなくなります」など、実際の制御と一致する案内を表示します。表示内容とシステムの挙動が異なると、ユーザーの混乱や問い合わせにつながります。

SMS認証コード送信のセキュリティと不正利用対策

SMS認証コードは導入しやすい認証方法ですが、コードを送るだけでは不正利用を防げません。コードの推測、短時間の連続送信、フィッシング、第三者へのコード共有などを想定し、送信要求から照合完了まで、各段階に制限と監視を設ける必要があります。

米国NISTのデジタルIDガイドラインでは、SMSや音声通話を使う公衆電話網（PSTN）経由の認証を制限付きの認証手段として扱っています。利用する場合は、代替となる認証手段を用意したうえで、SIM変更や番号移行の兆候を確認するよう求めています。

国内の脅威情報として、IPAの「情報セキュリティ10大脅威 2024」は、SIMスワップによってSMS認証コードやワンタイムパスワードが第三者に取得され、二要素認証が突破されるおそれを挙げています。

• 使用済み・旧コードを無効にする：認証が完了したコードや、再送信前に発行したコードを再利用できない状態にします。
• 入力試行と再送信を制限する：一定回数の入力失敗や短時間の連続送信が発生した場合は、コードを無効化する、待機時間を設けるなどの制御を行います。
• 複数の情報で異常を検知する：電話番号だけでなく、IP、端末、アカウント、国・地域なども確認し、不自然なリクエストの増加を検知します。
• SMS文面で用途を明示する：サービス名と認証の用途を記載し、コードやパスワードを第三者に共有しないよう注意を促します。
• 送信量と費用の変化を確認する：通常時と比べて送信件数や失敗件数が急増していないかを監視し、必要に応じて国・地域やリクエスト元を制限します。
• 高リスク操作はSMSだけに依存しない：決済、送金、重要情報の変更などでは、SMS以外の認証方法を組み合わせるか、操作のリスクに応じて認証方法を使い分けます。

第三者が認証画面を悪用して大量のSMSを送信させるSMSポンピングにも注意が必要です。仕組みと対策は、SMSポンピングとはの記事で詳しく解説しています。

EngageLab OTPでSMS認証コードを送信・検証する

OTPの生成・照合を自社で管理する負担を抑えたい場合や、SMS以外の認証チャネルも利用したい場合は、OTPサービスが候補になります。導入前に、自社で保持するデータ、APIが対応する範囲、利用するチャネルを整理しておきましょう。

EngageLab OTPは、認証コードの配信と検証に利用できるAPIを提供しています。公式ドキュメントでは、テンプレートに基づく認証コードの生成・配信、入力されたコードの検証、SMS・メール・WhatsApp・音声チャネルの設定、送信履歴の確認方法が案内されています。

• OTP配信API：テンプレート設定に基づいて認証コードを生成し、指定した配信チャネルへ送信します。
• OTP認証API：ユーザーが入力した認証コードを検証し、認証結果を確認します。
• 複数チャネルの設定：テンプレートではSMS、メール、WhatsApp、音声を指定できます。組み合わせ条件はチャネルによって異なるため、利用前にドキュメントで確認します。
• 送信履歴の確認：送信時刻、送信先、メッセージステータスや、配信状況の推移（配信ライフサイクル）を管理画面で確認できます。

実装方法は、OTP配信APIとOTP認証APIのドキュメントで確認できます。

SMS認証コードに関するよくある質問

SMS認証コードの有効期限と再送信回数はどう決めますか？

一律の設定値はなく、操作のリスクと、ユーザーが入力を完了するまでに必要な時間に合わせて決めます。再送信には待機時間と上限回数を設け、再送信後は前のコードを無効にする設計が一般的です。入力失敗が続いた場合のロック条件もあわせて設定します。

SMS認証だけで十分ですか？

SMS認証は、多くのユーザーが利用しやすい一方で、フィッシングや電話番号の乗っ取りなどのリスクがあります。決済、送金、重要情報の変更では、パスキーや認証アプリなどを組み合わせる方法も検討します。SMS認証コードを入力せずに電話番号を確認する方法を検討している場合は、サイレント認証（Silent Auth）も選択肢になります。

SMS認証コード送信の費用は何で決まりますか？

主な変動要因は、送信件数、送信先の国・地域、SMS単価、初期費用や月額費用、再送信件数、代替チャネルの利用です。単価だけでなく、失敗時や再送信時の課金条件、送信上限、費用アラートの有無まで確認しておくと、運用時の総費用を把握しやすくなります。

まとめ

SMS認証コードを導入する際は、最初に利用場面と実装範囲を決めます。そのうえで、コードの生成・送信・照合、有効期限、再送信、入力失敗、未着時の対応を一つの運用フローとして設計する必要があります。

APIの対応範囲を確認するときは、送信だけに対応するのか、生成・照合や履歴確認まで含むのかを確認しましょう。運用開始後は、配信結果、認証結果、送信量の変化を継続して確認します。不正利用の兆候や認証途中の離脱要因を早めに把握できる体制を整えましょう。