Guide · 10 分で読めます · Updated 4月 2026

SMS認証の仕組み — 技術的な解説

ステップ 1: OTPの生成

プラットフォームが電話番号の認証を必要とする場合、ワンタイムパスワード（OTP）が生成されます。サーバー側では次のような処理が行われます。

ユーザーが電話番号を送信 — プラットフォームのバックエンドが番号を受信し、その形式（国コード、桁数、有効なプレフィックス）を検証します。
OTPが生成される — 暗号学的にランダムなコードが作成されます。通常、4〜6桁です。ほとんどの実装では、時間ベースまたはカウンターベースのシード（RFC 6238/RFC 4226のTOTP/HOTP標準）を使用したHMAC-SHA1またはHMAC-SHA256が使用されます。
OTPが保存される — コードは有効期限のタイムスタンプ（通常60〜300秒）とともにサーバー側に保存され、電話番号に関連付けられます。
レート制限が適用される — プラットフォームは、最近この番号に対していくつのOTPがリクエストされたかを確認します。ほとんどのサービスでは、1時間あたり番号ごとに3〜5回の試行が許可されます。
SMS API呼び出しがトリガーされる — プラットフォームは、電話番号とメッセージコンテンツを指定して、SMSプロバイダーにリクエストを送信します。

OTP自体は通常、単なるランダムな番号です。プラットフォームはOTPをハッシュ化された形式でメッセージに埋め込むことはありません。プレーンテキストとしてSMS本文で送信されます。これは、SMS認証の基本的なセキュリティ上の弱点の1つです。

ステップ 2: A2P SMSエコシステム

A2PはApplication-to-Personの略で、ソフトウェアアプリケーションから人間の携帯電話に送信されるメッセージを指します。これはP2P（Person-to-Person）メッセージングとは異なります。A2Pエコシステムには独自のインフラストラクチャがあります。

SMSアグリゲーター

ほとんどのプラットフォームは、キャリアから直接SMSを送信しません。代わりに、SMSアグリゲーターを使用します。これは、世界中の何百ものキャリアとの接続を維持している企業です。主要なアグリゲーターには以下が含まれます。

Twilio — 最大のSMS APIプロバイダー。Uber、Airbnb、Stripe、その他数千の企業で使用されています。
Vonage (Nexmo) — 国際SMSルーティングで人気があります。
Sinch — エンタープライズOTP配信に強みがあります。
MessageBird — ヨーロッパ中心のアグリゲーター。
Infobip — 新興市場の主要プレイヤー。

InstagramがOTPを送信する場合、そのメッセージはキャリアに届く前に、Twilioまたは同様のアグリゲーターを経由している可能性が高いです。アグリゲーターは、ルーティング、キャリア交渉、配信確認を処理します。

SMSルーティング

アグリゲーターは、SMSを配信するための最適なルートを決定します。米国の番号の場合、次のようになります。

プラットフォームAPI呼び出し → アグリゲーター（例: Twilio）
アグリゲーター → キャリアゲートウェイ（例: AT&T、T-Mobile）
キャリアゲートウェイ → SMSC（Short Message Service Center）
SMSC → MSC（Mobile Switching Center）
MSC → ベースステーション → ユーザーの電話

国際メッセージは複雑さを増します。米国ベースのプラットフォームからインドの番号へのOTPは、宛先に到達する前に2〜3の中間キャリアを経由する場合があります。各ホップは遅延とわずかな失敗の可能性を追加します。

実際に見てみませんか？

VerifySMSを無料で試す →

仮想番号を取得してOTPをリアルタイムで受信

ステップ 3: SS7とシグナリングレイヤー

SS7（Signaling System No. 7）は、電話ネットワークがどのように通信するかを制御するプロトコルスイートです。1970年代に開発され、現在でもグローバル電話網のバックボーンとなっています。SMSが送信されると、SS7は以下を処理します。

番号ルックアップ（HLRクエリ） — 送信キャリアは、宛先番号がどのキャリアとネットワークに属するかを判断するために、ホームロケーションレジスタに問い合わせます。
メッセージルーティング — SS7シグナルは、メッセージがネットワークを通過するパスを決定します。
配信確認 — 受信SMSCは、SS7シグナリングを通じて配信確認を返します。

SS7のセキュリティ問題

SS7は、信頼できる通信事業者のみがネットワークにアクセスできた時代に設計されました。現在では、数千のエンティティがSS7にアクセスできるため、セキュリティ上の脆弱性が生じています。

SMS傍受 — SS7アクセスを持つ攻撃者は、SMSメッセージを自分のデバイスにリダイレクトできます。これは、銀行の2FAに対する実際の攻撃で実証されています。
位置追跡 — SS7クエリは、電話の物理的な位置を明らかにすることができます。
番号なりすまし — SS7を使用すると、異なる番号から送信されたように見えるメッセージを送信できます。

これらの脆弱性により、セキュリティ専門家はSMSベースの2FAから、アプリベースの認証（TOTP）またはハードウェアキー（FIDO2）への移行を推奨しています。しかし、初期のアカウント認証（番号へのアクセス権があることを証明する）においては、SMSは最も広範囲に普及しているため、業界標準であり続けています。

ステップ 4: 仮想番号がSMSを受信する仕組み

仮想電話番号は、物理的なSIMカードと無線コンポーネントをソフトウェアに置き換えることで機能します。仮想番号がOTPを受信する仕組みは次のとおりです。

番号の割り当て — 仮想番号プロバイダーは、キャリアから番号ブロックをリースします。これらは、有効なキャリア登録を持つ実際の電話番号です。
SIMバンクまたはソフトSIM — プロバイダーは、ハードウェア（数百または数千のSIMを備えたSIMバンク）で物理的なSIMカードを運用するか、キャリアレベルのソフトウェア統合を使用してメッセージを受信します。
SMSがキャリアに到着 — OTPメッセージは、他のSMSと同様に、仮想番号に関連付けられたキャリアに配信されます。
メッセージが転送される — SIMバンクまたはキャリア統合は、受信したSMSをキャプチャし、APIを介してプロバイダーのバックエンドに転送します。
ユーザーがコードを確認 — プロバイダーのダッシュボードまたはAPIに、受信したSMSが表示されます。

重要な洞察：送信プラットフォームの観点からは、仮想番号は物理的な電話と全く同じように見えます。SMSは同じルーティングパスをたどります。違いはラストマイルにあります。電話画面に表示される代わりに、メッセージはソフトウェアによってキャプチャされます。

ステップ 5: プラットフォーム側の検証

ユーザーがOTPを受信してプラットフォームに入力した後、サーバー側の検証が行われます。

コードの比較 — プラットフォームは、送信されたコードと保存されているOTPを比較します。
有効期限のチェック — OTPが期限切れの場合（通常60〜300秒）、検証は失敗します。
試行回数のカウント — ほとんどのプラットフォームでは、検証をロックする前に3〜5回の不正な試行が許可されます。
番号の分類 — 一部のプラットフォームは、潜在的な誤用をフラグ付けするために、番号をVoIP/仮想番号データベースと比較します。
成功または失敗 — コードが一致し、期限切れでない場合、電話番号は検証済みとしてマークされます。

プラットフォームが仮想番号を検出する方法

一部のプラットフォームは仮想番号をブロックしようとします。使用される方法は次のとおりです。

検出方法	仕組み	有効性
番号タイプのルックアップ	キャリアデータベースに問い合わせて、番号がモバイル、固定電話、またはVoIPであるかを確認します	中程度 — 多くの仮想番号はモバイルとして登録されています
キャリアデータベースチェック	番号を既知のVoIPプロバイダーの範囲と比較します	中程度 — 大手プロバイダーには有効ですが、小規模なプロバイダーは見逃します
HLRルックアップ	ホームロケーションレジスタに問い合わせて、SIMカードの詳細を確認します	ソフトウェアのみの番号の検出には高い有効性がありますが、SIMバンク番号では低くなります
行動分析	同じ範囲の番号から作成されたアカウントの数を追跡します	長期的には高い有効性がありますが、データの蓄積が必要です

仮想番号プロバイダーは、キャリアグレードの番号をモバイル回線として登録し、多様な番号プールを維持し、頻繁に番号をローテーションすることで、これらの検出を回避します。検出回避のサイクルは継続中です。

欠点にもかかわらずSMS認証が存続する理由

SMS認証にはよく知られたセキュリティ上の弱点がありますが、依然として主要な方法です。その理由は実用的です。

普遍的なリーチ — すべての電話がSMSを受信できます。アプリのインストールは不要です。これにより、フィーチャーフォンや古いデバイスを使用している数十億人のユーザーがカバーされます。
ユーザーの慣れ — 「送信されたコードを入力してください」は誰にでも理解できます。説明は不要です。
低い実装コスト — SMS APIは安価です。Twilioは米国ではSMSあたり約0.0075ドルを請求します。大規模になると、検証あたり数セントです。
許容できるセキュリティトレードオフ — ほとんどのユースケース（ソーシャルメディアサインアップ、フードデリバリーアカウント）では、SMSはハードウェアセキュリティキーを必要とせずに自動化された悪用を抑止するのに十分な摩擦を提供します。

業界はゆっくりと代替手段に移行しています。パスキー（FIDO2）、アプリベースのTOTP、プッシュ通知の採用が進んでいます。しかし、初期の電話番号認証（ユーザーが電話番号を制御していることを証明する）においては、SMSは依然として標準です。

このエコシステムにおける仮想番号の役割

仮想番号は特定のニッチを占めています。物理的なデバイスを必要とせずに、電話番号レベルのアクセスを提供します。これは、以下のような正当なシナリオに役立ちます。

プライバシー保護 — データを販売する可能性のあるプラットフォームに実際の番号を公開しないようにします。プライバシーがなぜ重要なのかについては、VerifySMS対無料SMSサイト（receive-smss.com）— 有料の方が良い理由をご覧ください。
マルチアカウント管理 — 同じプラットフォームで複数のアカウントを運用するビジネスは、それぞれに固有の番号が必要です。
国際アクセス — 現地のSIMカードを管理することなく、アメリカの仮想電話番号 — 非VoIP番号のプラットフォームのアカウントを認証します。
開発とテスト — OTPフローをテストするQAチームは、物理的なデバイスを管理することなく多くの番号を必要とします。

技術的な観点から見ると、仮想番号は、SMS認証が物理的な電話に搭載されていることではなく、番号の制御のみを証明するという事実を利用しているため機能します。番号が有効でA2Pメッセージを受信できる限り、認証は成功します。

高度: OTP配信の最適化

SMS認証を実装する開発者向けに、信頼性の高い配信のための技術的な考慮事項を以下に示します。

送信者IDを賢く使用する — アルファベット数字の送信者IDをサポートする国では、ブランド名を使用します。米国では、配信率を最適化するために専用のショートコードまたは10DLC（10桁のロングコード）を使用します。
フォールバックルーティングを実装する — 複数のSMSアグリゲーターを使用することで、1つのルートが失敗した場合でも、別のルートを通じてメッセージを再試行できます。
メッセージを短く保つ — OTPメッセージは160文字（1つのSMSセグメント）未満にする必要があります。複数セグメントのメッセージは失敗率が高くなります。
適切なタイムアウトを設定する — 120秒が最適な時間です。短すぎると誤った失敗が発生し、長すぎると傍受されたコードが使用される可能性があります。
配信確認を記録する — メッセージが配信されたか、保留中か、失敗したかを追跡します。このデータは、キャリア固有の問題を特定するのに役立ちます。

SMS認証を受信側で確認