自社のWebサービスや会員システムに、SMSを使った本人確認や二段階認証を組み込むことになった――。パスワード漏えいや不正ログインの増加を受けて、新規会員登録・パスワードリセット・重要取引の直前など、要所での本人確認強化を求める声は年々強まっています。SMS認証は導入の手間が比較的軽く、既存の会員基盤に電話番号1つで組み込めるため、二段階認証の実装手段としてまず候補に挙がる方式です。
導入検討で初期に必要になるのは、対象サービスの候補と1通あたりの費用、想定の開発工数、本番稼働までの見通し、そして他の認証手段と比べたときにSMSを選ぶ理由といった一連の材料です。
本記事は、SMS認証を自社サービスに組み込む際に必要な材料を1本にまとめたガイドです。主要SMS認証サービス7社の比較、API連携の実像、落とし穴と対策のペア、契約から本番切替までの週次WBSまでを、公式一次情報にあたって整理しています。
目次
一括ダウンロードする
主要SMS認証サービスの料金・機能比較
まず、稟議に必要な材料――どのサービスがいくらで、何を提供しているのか――を横並びで確認します。比較表は次の11列で構成しています。
1通単価・初期費用・月額固定・最低ロットは稟議シートの金額根拠に、国内キャリア直収か中継かは到達率と遅延の実効値に、API種別・API仕様公開の有無は開発工数の見積もりに、IVR（自動音声）フォールバックは不達時の代替手段の有無に、到達率の公表値・導入実績は選定の裏づけに、それぞれ直結する項目です。
特に見落としやすいのが国内直収か中継かと、API仕様が公開ドキュメントとして提供されているかの2点です。国内直収型はNTTドコモ・KDDI・ソフトバンク・楽天モバイルの4キャリアと直接接続しているため、中継事業者を経由するプランに比べて到達率と遅延で有利になる傾向があります。API仕様が公開されているサービスは、契約前にエンドポイントとレスポンスを読み込めるため、実装工数の見積もりに幅が出ません。
11列で見る主要サービス比較表
| サービス名 | オーロラSMS by メディアSMS | SMSLINK | KDDI Message Cast | 絶対リーチ！SMS | Twilio Verify | Cuenote SMS | SMS HaNa |
|---|---|---|---|---|---|---|---|
| 提供会社 | 株式会社メディア4u | 株式会社ネクスウェイ | KDDI株式会社（Supership共同運営） | AI CROSS株式会社 | Twilio Inc.（国内販売: ソフトバンク／Twilio Japan合同会社） | ユミルリンク株式会社 | 日本テレネット株式会社 |
| 1通単価 | 非公表・要問い合わせ | 6円〜（従量、通数により変動） | 9.35円（税込）〜（到達課金） | 非公表・要問い合わせ（成功課金・ボリュームディスカウントあり） | 認証成功1回0.05USD〜（USD建て・チャネル別に別途送信料が加算） | 6円〜（成功課金、プランにより変動） | 非公表・要問い合わせ |
| 初期費用 | 0円 | 0円 | 0円 | 非公表・要問い合わせ（認証系プラン） | 0円 | 0円 | 0円 |
| 月額固定 | 0円 | 0円（スタンダードプラン） | 0円 | 非公表・要問い合わせ（認証系プラン） | 0円 | 非公表・要問い合わせ | 0円 |
| 最低ロット | 非公表・要問い合わせ | 月額利用料が1,000円未満の場合は最低1,000円 | 非公表・要問い合わせ | 非公表・要問い合わせ | 最低月額なし（Pay-as-you-go） | 非公表・要問い合わせ | 最低ロットなし（月額基本料無料、送信分のみ課金） |
| 国内直収 or 中継 | 国内直収（ドコモ・au・ソフトバンク・楽天モバイルの4キャリア） | 国内直収（4キャリア直接接続を訴求、数値・キャリア名は非開示） | 国内直収（共通番号0005でau・ドコモ・ソフトバンク・楽天モバイルの4キャリア） | 国内全キャリアと直接接続 | グローバル網（200以上の国・地域、国内キャリア直収の公式明示なし） | 国内直収（ドコモ・au・ソフトバンク・楽天モバイルの4キャリア） | 国内直収（ドコモ・au・ソフトバンク・楽天モバイルの4キャリア） |
| API種別 | REST API＋認証オールインワンAPI（OTP生成・照合をワンステップで返却） | REST API＋認証機能オプション（簡易API、最短3日で開発可能） | HTTPS API＋Salesforce／ServiceNow連携版 | HTTPS Web API＋SMPP v3.4（OpenAPI仕様書を公開） | REST API＋公式SDK（Node.js／Python／Java／PHP／C#／Ruby／Go） | RESTful API（標準搭載、開発言語を問わない） | WEB-API（REST／HTTPS／GET・POST／UTF-8） |
| IVR/音声フォールバック | ●IVR（発信認証）をフォールバックとして提供 | ●SMS送信失敗時に自動で音声通話へ切替（固定電話も可） | × | ●IVR付き認証プランでSMS非対応端末を補完 | ●音声チャネル対応・到達状況に応じてチャネル自動切替 | ×Cuenote SMS単体はSMSのみ（IVR認証は姉妹サービスCuenote Auth） | ×SMSのみ（IVR／音声フォールバック機能の公式記載なし） |
| 到達率公表値 | 99.9%（自社検証試験、受信拒否・圏外・電源OFF除く） | 非公表・要問い合わせ | 98%以上（当社調べ） | 直接接続99.9%／メッセージ到達率99%（公式訴求） | 94%（グローバル、英語版製品ページ記載） | 99.9%（2022年3〜5月の自社実績、圏外・切電・受信拒否等を除く） | 99%以上（自社調べ、受信拒否・圏外・電源オフ除く） |
| 導入実績 | 7,000社超（2025年11月末時点、自治体含む） | サービスリリースから7年で3,500社超 | SMS送信サービス導入シェア第1位（2025年4月時点、Supership株式会社 プレスリリースに基づく） | 8,000社以上（時点明示なし） | Stripe・Shopify・Intuit・Deliveroo等がグローバルで採用（国内実績は非公表） | システム契約数2,800超（Cuenoteシリーズ全体、メール含む合算値） | 3,000件以上（公式サービスページ） |
| 詳細情報 | 公式資料を見る | 公式資料を見る | 公式資料を見る | 公式サイト | 公式サイト | 公式サイト | 公式サイト |
※各サービスの料金・機能は2026年8月時点の各社公式サイトによる。最新情報は各社にお問い合わせください。
月間送信数別の料金早見（月1,000通／10,000通／100,000通の概算試算）
稟議シートに転記しやすいよう、主要サービスの1通単価を月間送信数別に概算試算した早見表を用意しました。以下はいずれも「初期費用0円プラン・従量課金で段階割引なし」を前提とした単純試算で、実際は送信数帯によって段階単価が下がるサービス、月額固定＋従量のハイブリッドプランを持つサービスもあります。契約前に各社の見積を必ず取り直してください。
| サービス | 1通単価（公表値） | 月1,000通 | 月10,000通 | 月100,000通 |
|---|---|---|---|---|
| SMSLINK（ネクスウェイ） | SMS 1通6円〜／認証チェック〜2円/件（2022年発表） | 約6,000円〜 | 約60,000円〜 | 約600,000円〜（段階割引の可能性あり・要見積） |
| Cuenote SMS（ユミルリンク） | 1通6円〜（成功課金） | 約6,000円〜 | 約60,000円〜 | 約600,000円〜（同上） |
| SMS HaNa（日本テレネット） | 非公表・要問い合わせ | 要問い合わせ | 要問い合わせ | 要問い合わせ |
| KDDI Message Cast | 1通9.35円（税込）〜（到達課金） | 約9,350円〜 | 約93,500円〜 | 約935,000円〜（段階割引の可能性あり・要見積） |
| オーロラSMS by メディアSMS | 非公表・要問い合わせ | 要問い合わせ | 要問い合わせ | 要問い合わせ |
| 絶対リーチ！SMS | 非公表・要問い合わせ | 要問い合わせ | 要問い合わせ | 要問い合わせ |
| Twilio Verify（Verify API料金のみ） | 1リクエスト0.05USD〜 | 約50USD〜 | 約500USD〜 | 約5,000USD〜（ボリューム割引あり） |
| Twilio Verify（SMS送信料） | 別途加算（日本向け1通あたり数十円レンジ・要見積） | 要見積 | 要見積 | 要見積 |
※単価は2026年8月時点の各社公表値および過去プレスリリースによる。段階割引・オプション（IVRフォールバック等）・SMS配信の初期設定費は別途。Twilio Verifyは「Verify API認証料金」と「SMS送信料」の2階建て課金で、実額は上記2行の合算になります。SMSLINKの認証チェック単価は2022年発表値のため、稟議直前に必ず現行料金を要確認。実額は各社見積で確定してください。
この試算は「月間送信数が事前に読める前提」で作っています。実サービスでは新規登録・パスワードリセット・重要取引の直前など複数箇所でSMSを送るため、想定送信数の見積もりは「対象ユーザー数の月間認証回数×平均再送率（初回失敗の再送含めて1.2〜1.5倍程度）」で置くと安全側になります。
上限を超えた場合の従量課金でコストが想定外に上振れしないよう、契約時に「月間送信上限アラート」の設定可否も確認しておきましょう。
API連携の実像──シーケンス・エンドポイント・SDKまで
SMS認証のAPI設計は、認証コード発行と突合の主体を送信API側に任せるオールインワン型と、自社で発行して配信のみ委託する型の2系統に分かれます。この違いが実装工数と自社側で管理すべきロジックの量を決めるため、選定の入り口でここを見分けます。
認証コード発行の主体：オールインワン型と配信のみ委託型
オールインワン型（Twilio VerifyやオーロラSMSの認証オールインワンサービス、SMSLINKの認証機能オプションなど）は、電話番号を渡すとサービス側で認証コードを生成・送信し、ユーザーが入力したコードを検証エンドポイントに投げると照合結果を返してくれます。
自社側で保持すべきなのは「認証セッションID」程度で、コードの生成ロジック・有効期限管理・照合ロジックを外に出せる分、開発工数は最小です。
配信のみ委託型（KDDI Message Castの汎用SMS送信APIをSMS認証に使う構成、SMSLINKの単純送信APIなど）は、自社側で認証コード（例えば6桁の数字）を発行し、そのコードを本文に埋めたSMSを送信APIで飛ばして、ユーザーが入力したコードを自社DBに保持した値と照合します。
認証セッション・コード有効期限・連続失敗ロックの実装は自社側になりますが、SMSの本文レイアウトの自由度が高く、認証以外の通知（受注確認・配送通知など）にも同じAPIを使い回せます。
基本シーケンス（主体を明記）
オールインワン型と配信のみ委託型の基本シーケンスを主体つきで並べます。実装ドキュメントを読む前の当たり付けに使ってください。
| ステップ | オールインワン型 | 配信のみ委託型 |
|---|---|---|
| 1. 認証セッション開始 | 自社サーバ→SMS API（電話番号を渡す） | 自社サーバ→自社DB（コード生成・保存） |
| 2. コード生成 | SMS API側で生成 | 自社側で生成（6桁の乱数など） |
| 3. SMS送信 | SMS API→端末 | 自社サーバ→SMS API→端末（本文にコード埋め込み） |
| 4. ユーザー入力 | ユーザー→自社Web/アプリ | ユーザー→自社Web/アプリ |
| 5. コード照合 | 自社サーバ→SMS API（照合エンドポイント） | 自社サーバ→自社DB（照合ロジック） |
| 6. 認証結果返却 | SMS API→自社サーバ→ユーザー | 自社サーバ→ユーザー |
両型に共通する自社側の実装項目は、認証セッションIDの発行・保管、連続失敗回数のカウントとロック、コード有効期限のUX（残り時間表示・再送ボタン）、リプレイ攻撃対策（使用済みコードの無効化）です。オールインワン型でもこれらは自社UIで実装が要る点に注意してください。
主要サービスのAPI提供形態一覧
各社のAPI提供形態と、公開ドキュメント（サンプルコード付きの実装リファレンス）の有無を整理しました。公開ドキュメントがあるサービスは、契約前にエンドポイントとレスポンス構造を読み込んで開発工数の見積もりが立てられます。公開されていないサービスは、資料DL・営業窓口経由でAPI仕様書を取得する必要があります。
| サービス | 提供形態 | API仕様の公開 | 認証コード発行の主体 |
|---|---|---|---|
| Twilio Verify | REST API＋公式SDK（Node.js／Python／Java／C#／PHP／Ruby／Goほか） | 公開（cURL・レスポンス例あり） | オールインワン型 |
| 絶対リーチ！SMS | REST API（OpenAPI仕様） | 公開（Redocベースの仕様書） | 配信のみ／オールインワン両対応 |
| SMSLINK（ネクスウェイ） | REST API＋認証機能オプション | 非公開（資料DL・営業窓口経由） | 両対応（認証機能利用時はオールインワン相当） |
| オーロラSMS by メディアSMS | REST API＋認証オールインワンサービス | 非公開（資料DL・営業窓口経由） | 両対応 |
| KDDI Message Cast | HTTPS API＋Salesforce／ServiceNow連携版 | 非公開（資料DL・営業窓口経由） | 配信のみ委託型（自社で認証ロジック実装） |
| Cuenote SMS（Cuenote Auth） | REST API＋認証専用ブランド「Cuenote Auth」 | 非公開（資料DL・営業窓口経由） | 両対応 |
| SMS HaNa（日本テレネット） | REST API | 非公開（資料DL・営業窓口経由） | 配信のみ委託型が中心 |
Twilio Verifyと絶対リーチ！SMSは公式に仕様書を公開しているため、開発着手前に自社の要件と照合できます。それ以外の国内サービスは資料DLか営業窓口経由で仕様書を取得する運用のため、稟議書に添付するAPIの実装工数見積もりを立てる際は「見積依頼時にサンプルコード付きの仕様書開示」を条件として付けておくと、着手前後の齟齬を避けられます。
出典・参考資料（2件）
実装で押さえるべき落とし穴と対策のペア
SMS認証の運用で問題化しやすい7つの落とし穴と、実装側で打つべき対策をペアで整理します。稟議書に「SIMスワップ対策として端末変更検知の推奨を併設します」「MVNO不達に備えてIVR音声認証をフォールバックに用意します」といった一枚の説明を添えられる粒度で書いています。
攻撃技術の詳細は各種公的機関の注意喚起・NIST SP 800-63Bを参照し、対策の実装レベルは各社の機能ページで裏づけを取ってください。
不正アクセス対策の必要性は依然として高い水準にあります。警察庁の「不正アクセス行為の発生状況」（令和7年3月13日公表）によると、令和6年（2024年）の不正アクセス行為の認知件数は5,358件で、その8割超（4,342件）が「インターネットバンキングでの不正送金等」でした。認知件数は年により増減があるものの、金融・決済領域が継続してリスクの中心にあることが分かります。
SMS認証はフィッシングや不正ログインの全てを防ぐ手段ではありませんが、本人確認強化の一次的な障壁として、金融・決済領域のサービスでは実装コストの投資判断が通りやすい対策です。
出典・参考資料（1件）
| 落とし穴・攻撃手法 | 実装側で打つべき対策 |
|---|---|
| SIMスワップ攻撃：攻撃者がキャリアショップやオンライン手続きで被害者の電話番号を自分のSIMに乗り換え、SMS認証コードを奪取 | 端末変更・SIM変更の検知（キャリア連携API・端末フィンガープリント）、変更直後のSMS認証停止と代替認証への切替、重要取引前は追加要素（生体認証・秘密の質問）を併設 |
| SMSインターセプト（SS7攻撃）：電気通信ネットワークの脆弱性を突いてSMSを傍受 | 国内キャリア直収型サービスの採用（中継経路を短くする）、重要取引は SMS単独でなくTOTPアプリやFIDO等と組み合わせる |
| スミッシング（フィッシングSMS）：正規サービスを騙るSMSでユーザーを偽サイトに誘導し、認証コードを盗む | ユーザー教育（「SMSに載ったURLは踏まない」の運用告知）、送信元表示名の統一と偽装対策、認証コードSMSにURLを含めない |
| 格安SIM／MVNO不達：一部のMVNO（SMSオプション未加入プラン・IoT/データ専用SIM等）で受信不可・遅延が発生。W4で確認する主要MVNO（IIJmio・mineo・OCNモバイルONEほか）でも事業者・プランで挙動が異なる | IVR（自動音声）認証をフォールバック手段として用意、テスト送信で主要MVNOの到達確認、UI上で「SMSが届かない場合の代替手段」動線を明示。選定サービスがIVR未対応の場合（例：KDDI Message Cast）は、電話認証SaaSの別調達またはメール認証の代替導線を稟議時に併記 |
| リプレイ攻撃：一度使った認証コードを再利用 | 使用済みコードの即時無効化（サーバ側で「使用済み」フラグ）、コード有効期限を短く設定（3〜5分推奨） |
| レート制限バイパス／不正リクエストによるコスト増：同一電話番号や同一IPから大量の送信要求を投げてSMSコストを消費させる | IPホワイトリスト＋レート制限（同一番号は1分1回・1時間5回など）、CAPTCHA併用、月間送信上限アラートの設定 |
| 従量課金の想定外の上振れ：送信ボリューム急増で月額が跳ね上がる | 月間送信数上限アラート（一定閾値で通知）、送信ドライラン（意図しない再送ループの検出）、日次・週次の送信数モニタリング |
先の表のうち、金融系サービスの稟議で特に問われるSIMスワップ対策について、監修者からの実装観点コメントを添えます。
出典・参考資料（2件）
- 参考資料：NIST SP 800-63B-4 Digital Identity Guidelines（July 2025）（PSTN OOBのSIMスワップ・番号ポーティングをリスク要因として明示）
- 参考資料：企業をかたるメッセージから海外SMS送信に誘導される手口を確認｜IPA（2024年3月26日）
MVNO不達のフォールバックとしてIVR（音声）を厚めに用意したい場合や、SIMスワップの残余リスクを別チャネルで補いたい場合は、電話（音声）による認証を代替・併用手段として検討する余地があります。電話認証サービスの仕組みと主要サービスは次の記事にまとめています。
導入プロセスとリードタイム目安・契約時決定項目
導入プロセスは大きくサービス選定・API連携・テスト送信・本番切替の4ステップに分かれますが、本番稼働時期の見通しを求められた際に答えられる粒度で、標準的な週次WBSと契約時に決めておくべき項目を提示します。
週次WBS（W1〜W5の標準リードタイム目安）
SMS認証の導入は、契約から本番稼働までおおむね4〜6週間が一つの目安です。この週数は各社の訴求（SMSLINK「簡易APIは最短3日で開発可能」、KDDI Message Cast導入事例「APIドキュメントを読みながら1時間で実装」ほか）と一般的な実装工数を合算した目安で、公的な業界標準ではありません。確定リードタイムは選定候補への見積依頼時に必ず確認してください。
以下は「オールインワン型APIを採用・自社で認証セッションと連続失敗ロックを実装・PoC後に本番切替」する標準ケースの週次WBSで、既存の会員基盤に組み込みやすい規模（バックエンド1名＋フロント1名×一部週）を前提としています。
要件が複雑（マルチテナント対応・独自コード仕様など）な場合は+2〜3週間、認証を新規機能として作る場合は+1週間程度を上乗せしてください。キャリア審査を要するサービスは、W1と並行してW0相当（1〜2週間）の審査申請期間を先出しで確保しておくと後工程が詰まりません。
- W1｜契約・アカウント発行・API仕様書取得：見積依頼→契約→API利用アカウント発行→APIキー・IPホワイトリスト設定。SLA・料金体系・オプション（IVRフォールバック等）の最終確認。
- W2-3｜開発・SDK組み込み・自社側実装：認証セッション発行、コード送信・照合ロジック、連続失敗ロック、コード有効期限のUI、再送動線、失敗時のフォールバックUI。
- W4｜テスト送信・キャリア別到達確認：ドコモ・au・ソフトバンク・楽天モバイル・主要MVNO（IIJmio・mineoほか）・iOS/Android・古い機種での到達確認、遅延計測、SIMスワップ疑似シナリオ、レート制限確認。
- W5｜本番切替・監視設定：本番APIキーへの切替、送信数上限アラート・失敗率アラートの設定、運用引き継ぎ、ユーザー向けヘルプ／FAQの公開。
契約時に決める項目チェックリスト
契約書に落とす前に決めておく項目のうち、後から変更しにくいものを整理しました。運用開始後に「送信元表示名を変えたい」「NGワードのルールを変えたい」となると、キャリア審査の再申請や設定変更で1〜2週間戻ることがあります。
- 送信元表示名（送信者ID）：ブランド名・サービス名を統一。キャリア審査を要するサービスもあるため契約時に確定。
- プレフィックス（SMS本文冒頭）：「【サービス名】認証コード：」のような固定文言。フィッシング対策として統一。
- NGワード管理・本文長制限：URLの含有可否、絵文字対応、70文字／160文字の分割ルール。
- 同意取得文言・プライバシーポリシー反映：会員登録時のSMS認証利用同意文言、既存規約の改定要否。
- IPホワイトリスト・API利用元制限：本番・ステージング・開発それぞれのIPを事前登録。
- 上限送信レート：秒間・分間・日次の送信上限。CDN経由の攻撃時の防波堤。
- 失敗時のフォールバック方針：SMS不達時のIVR認証・メール認証への切替、リトライ回数と間隔。
テスト送信で確認するチェックポイント
W4のテスト送信で押さえるのは、4大キャリア＋主要MVNOでの到達確認と、OS別・機種別の表示崩れの確認です。特にMVNOは事業者ごとにSMS対応が異なるため、自社のユーザー層に応じてテスト対象を選定してください。稟議で「主要キャリア・主要MVNOで到達確認済み」と一枚で書けるだけの記録を残しておくと、稼働後の障害対応で「そもそも到達しない事業者では？」の切り分けが速くなります。
- キャリア別到達確認：ドコモ・au・ソフトバンク・楽天モバイル（4大キャリア必須）
- MVNO到達確認：ユーザー層に応じて IIJmio・mineo・OCNモバイルONEなどの主要MVNOで受信テスト（一部MVNOはSMS未対応のため要事前確認）
- OS・機種別表示確認：iOS（最新／2世代前）・Android（最新／3世代前）・古い機種の表示崩れ
- 連続失敗ロックの動作確認：3回・5回・10回の連続失敗でロック→ロック解除までの導線
- コード有効期限・再送ボタンの動作確認：期限切れ後の再送、複数回再送時の挙動
SMS認証以外の選択肢との比較──TOTP／FIDO／メールと使い分け
稟議で「なぜSMSなのか」を上司に説明する材料として、他の代表的な認証手段との比較を並べます。SMS単独で完結させる設計と、SMS＋他手段の併用設計とで、どちらを選ぶかの判断軸を最後に整理します。
SMS認証・TOTPアプリ・FIDO・メール認証の比較
| 認証手段 | 手軽さ（ユーザー側） | 到達率 | 端末依存 | 攻撃耐性 | 実装難易度 |
|---|---|---|---|---|---|
| SMS認証 | 電話番号だけで開始可能 | 国内キャリア直収で99%台後半 | 電話番号を持つ端末が必要 | SIMスワップ・SMSインターセプトに一定のリスク | 低〜中（オールインワン型なら低） |
| TOTPアプリ（Google Authenticator等） | アプリのインストールと初期設定が必要 | ネットワーク非依存で高い | 認証アプリを入れた端末が必要 | フィッシングに強い、SIMスワップ影響なし | 中（QRコード発行・シークレット管理が必要） |
| FIDO（パスキー・WebAuthn） | 初回セットアップ後は生体認証だけで完結 | ブラウザ・OS対応環境で高い | 対応ブラウザ・OSと生体センサーが必要 | フィッシング耐性最高、鍵は端末外に出ない | 高（サーバ側の実装コストが高い） |
| メール認証 | メールアドレスだけで開始可能 | 迷惑メール振り分けの影響を受ける | メールが読める端末が必要 | メールアカウント乗っ取り時に突破される | 低（既存のメール送信基盤を流用可能） |
使い分けの指針（SMS単独 vs SMS＋TOTP／FIDO併用）
結論から言うと、会員登録直後の本人確認や重要度が中程度のログイン強化はSMS単独で十分な場合が多く、金融取引・機微情報の閲覧・大口取引の直前はSMS＋TOTPアプリまたはFIDOの併用が現実的な選択です。SMSはユーザー体験が最も軽い一方、SIMスワップの残余リスクがゼロにはならないため、被害発生時の損失規模が大きい取引ではもう1要素を重ねる設計が定石となっています。
米国NIST（国立標準技術研究所）のガイドラインNIST SP 800-63B-4（2025年7月改訂）では、電話網SMS（PSTN OOB）はAAL2（Authenticator Assurance Level 2）で許可される認証要素として引き続き扱われます。
一方、§3.2.9で「Restricted Authenticator（制限付き認証手段）」に正式分類され、§3.1.3.3でSIMスワップや番号ポーティング等がリスク指標として明示されています。
Restricted Authenticator を採用する組織にはリスク受容の記録・代替認証手段の提供などが求められます。
稟議に併記する場面では「SMS認証を主として採用しつつ、大口取引や機微情報の閲覧はTOTP/FIDOへの切替を促す代替導線を用意する」という段階的な設計を示すと、上司や監査担当への説明が通りやすくなります。
出典・参考資料（1件）
- 参考資料：NIST SP 800-63B-4 Digital Identity Guidelines（July 2025） §3.1.3.3 Out-of-Band Devices（PSTN OOBの扱い）
SMS＋TOTPアプリやSMS＋FIDOのように複数の認証要素を組み合わせる設計を本格的に詰める場合は、認証要素の分類・組み合わせパターン・段階設計の考え方を扱った多要素認証（MFA）の解説記事も参考になります。
一括ダウンロードする
SMS認証サービスの個別紹介
上段の比較表で候補に挙がったサービスのうち、資料請求や個別ミーティングで詳細を詰められるサービスを個別に紹介します。稟議書の添付資料としては、公式資料の一括DLで各社の情報を横並びで揃えるのが最短です。
1. オーロラSMS by メディアSMS（株式会社メディア4u）
メディア4uが提供するSMS配信・認証サービスで、SMS認証専用の「認証オールインワンサービス」を公式に持つのが特徴です。OTPの生成・送信・照合判定を1リクエストにまとめて返す仕様で、自社側で認証ロジックを持つ必要がないため実装工数を抑えられます。
国内4キャリア直収による到達率99.9%（公式検証値）を公表しており、ISMS・Pマーク取得済み。SMS不達時のIVR（自動音声）認証フォールバックも用意されているため、MVNOユーザー比率が高いサービスでも代替手段を確保しやすい構成です。
選定時のチェックポイントは料金体系が別建てである点で、認証オールインワンAPIとSMS配信APIの料金は分けて見積を取ります。導入実績7,000社超が公式に開示されているため、稟議での実績確認がしやすい点も強みです。
2. SMSLINK（株式会社ネクスウェイ）
ネクスウェイのSMS配信サービスで、公表実績はサービスリリースから7年で3,500社超（公式ページに具体的な時点明示なし）。汎用のSMS送信APIに認証機能オプションを追加すると、コード生成・SMS/音声送信・認証チェックの一連のプロセスをAPI連携のみで完結できます。
初期0円・月額0円のスタンダードプランで、SMS 1通6円〜、認証チェック〜2円/件（2022年発表値）と実額が公表されており、金額の当たりを付けやすい特徴があります。「最短3日で開発可能」の簡易APIも用意されているため、短期リリース要件の候補にも上がります。
選定時のチェックポイントは、認証チェック単価が2022年発表値のため契約前に現行料金の再確認が必要な点です。SMS送信失敗時に自動で音声通話（固定電話も可）へフォールバックする仕組みが標準で組み込まれています。
3. KDDI Message Cast（KDDI株式会社）
KDDIグループが提供するSMS配信基盤で、SMS送信API（HTTPS API）を用いた本人認証実装が公式ページで案内されています。導入事例には「APIドキュメントを読みながら1時間ほどで実装した」という開発者コメントも公開されており、実装工数の目安になります。
Salesforce・ServiceNow連携版も別途提供されているため、既存のCRM・ITSM基盤に組み込む形でSMS認証を追加したい場合にも選択肢に入ります。認証コードは自社側で発行して本文に埋め込む配信のみ委託型のため、認証セッション・連続失敗ロックは自社実装となる点に注意してください。
選定時のチェックポイントはIVR/音声フォールバック機能が公式に提供されていない点です。MVNO不達対策として、電話認証SaaSの別調達またはメール認証への切替導線を稟議で併記する必要があります。
4. 絶対リーチ！SMS／RCS（AI CROSS株式会社）
AI CROSS株式会社が提供するSMS配信サービスで、SMS認証専用の「セキュアSMS認証」プランを持ちます。IVR悪用による認証コードの自動取得を阻止する仕組みで特許（第6434099号）を取得しており、SIMスワップやIVR悪用対策を稟議の説得材料に組み込みやすい点が特徴です。
認証コードの自動生成・自動送信により利用企業側の開発負担を軽減する設計で、ISMS取得済み。OpenAPI形式でAPI仕様書を公開しているため、契約前に自社の要件と技術仕様の照合ができます。
選定時のチェックポイントは認証系プランの料金が非公表な点で、見積依頼時に「認証系プラン単価」を明示的に指定して取得します。SMS本体に加えてRCS（次世代SMS）にも対応しているため、Androidユーザー中心のサービスで将来的にリッチ通信への切替を見据えた選定もできます。
本記事では、初期検討でまず必要になる7サービスを取り上げました。掲載サービスの詳細機能や、他のSMS認証・SMS配信サービスも含めた網羅比較は、以下の記事で解説しています。
まとめ：稟議に落とし込むための意思決定ポイント
SMS認証の導入は、選定→契約→開発→本番までの流れが標準化されており、意思決定ポイントを押さえれば稟議は通しやすくなります。上司に一枚で説明する際は、以下の順で組み立てると齟齬が生まれにくくなります。
- 金額根拠：主要サービスの1通単価と、自社の想定送信数（月◯通）を掛け合わせた月額試算。段階割引や月額固定＋従量のプランがあれば併記。
- 技術妥当性：オールインワン型か配信のみ型かの選択、公開API仕様の有無、国内キャリア直収か中継か。
- リスク対策：SIMスワップ・スミッシング・MVNO不達・レート制限バイパスに対する実装側の対策を「◯を併設します」と一枚で説明できる形に。
- リードタイム：契約から本番稼働まで4〜6週間（W1契約→W2-3開発→W4テスト→W5本番切替）を目安。
- 次アクション：候補2〜3社への資料請求と個別見積依頼。API仕様書の開示条件を見積依頼時に付ける。
本記事の比較表で候補が絞れたら、次は各社の資料を一括で取り寄せて詳細な機能・料金・SLAを横並びで確認しましょう。MCB FinTechカタログでは、SMS認証サービスの資料をワンクリックで一括ダウンロードできます。
よくある質問（FAQ）
Q. SMS認証の月間送信数がまだ確定していない場合、どのように見積もればよいですか？
SMS認証の月間送信数は、「対象ユーザー数の月間認証回数×平均再送率1.2〜1.5倍」で仮置きし、契約時に月間送信上限アラートを併設して押さえるのが実務上の安全策です。認証発生ポイント（新規登録・パスワードリセット・重要取引の直前など）ごとに月間発生回数を積み上げ、初回失敗の再送やキャリア遅延による再送を見込んで1.2〜1.5倍に膨らませた値を上限として稟議に載せます。
従量課金は上振れリスクがあるため、契約時に「月間送信上限アラート」や「日次・秒間の送信レート上限」の設定可否を必ず確認し、想定外の再送ループや不正リクエストでコストが跳ね上がらないようにしておきましょう。稼働後の実測値が固まった段階で、月額固定＋従量のハイブリッドプランへ切り替えて単価を下げる交渉余地も残しておくと安全側です。
Q. SMS認証のSIMスワップ対策として、最初のリリースで最低限やるべきことは何ですか？
SMS認証のSIMスワップ対策は、重要取引の直前にSMS認証だけで完結させず、TOTPアプリや秘密の質問など追加の要素を1つ併設することを、最初のリリースから組み込むのが最低ラインです。SIMスワップ攻撃はキャリアショップやオンライン手続きで攻撃者が被害者の電話番号を自分のSIMに乗り換え、SMS認証コードを奪う手口で、SMS単独では完全には防げません。
全対策を一度に入れる必要はありませんが、追加要素の併設は後から差し込むと画面遷移や同意取得文言の設計変更が発生するため、初回リリースに組み込んでおくと後々の追加コストが減ります。
より進んだ対策としては、キャリア連携APIや端末フィンガープリントによるSIM変更検知、変更直後のSMS認証停止と代替認証への切替がありますが、稟議段階では「重要取引前の追加要素併設を初期リリースに入れる」を明記できれば通しやすくなります。
Q. SMS認証の国内キャリア直収型と中継型で、到達率にはどれくらい差が出ますか？
SMS認証の到達率は、国内キャリア直収型が公表値で99%台後半に達するのに対し、中継型は経路上の事業者を挟むぶん到達率と遅延で不利になる傾向があります。国内直収型はNTTドコモ・KDDI・ソフトバンク・楽天モバイルの4キャリアと直接接続しているため、経路上の遅延やロスが最小化されます。
中継型は海外キャリア経由や中継事業者を挟むケースがあり、SS7攻撃などネットワーク経路上のリスクも中継が長いほど高まる傾向にあります。
稟議書に到達率の根拠を書く場合は、各社が公表する到達率の実測値と「直収か中継か」の別をセットで記載し、W4のテスト送信段階で4大キャリアと主要MVNO（IIJmio・mineoほか）まで含めた到達確認結果を添付すると、稼働後の障害切り分けにも使える説得材料になります。
Q. SMS認証ではなくTOTPアプリやFIDO（パスキー）を選ぶべきなのはどんなケースですか？
SMS認証の代わりにTOTPやFIDOを選ぶ／併用すべきなのは、金融取引・機微情報の閲覧・大口取引の直前など、被害発生時の損失規模がSMS認証の残余リスクを許容できない場面です。
米国NISTのガイドラインNIST SP 800-63Bでは、電話網SMS（PSTN OOB）をAAL2の制限付き認証手段（Restricted Authenticator）として位置づけ、SIMスワップや番号ポーティングのリスクを明示しています。
会員登録直後の本人確認や中程度のログイン強化はSMS単独で十分な場合が多い一方、金融取引・大口決済・重要データ閲覧の直前ではSMS＋TOTPアプリまたはSMS＋FIDOの併用が現実的な選択です。稟議では「SMS認証をデフォルトで採用し、大口取引はTOTP／FIDO併用に段階的に切り替える」という設計を示すと、監査担当や情報セキュリティ部門への説明も通りやすくなります。
Q. SMS認証の導入から本番稼働までの実際のリードタイムはどれくらい見ておけばよいですか？
SMS認証の導入リードタイムは、オールインワン型APIを採用する標準ケースで、契約から本番切替まで4〜6週間が目安です。内訳はW1で契約・API利用アカウント発行・API仕様書取得、W2〜W3で開発・SDK組み込み・自社側の認証セッションと連続失敗ロック実装、W4で4大キャリアと主要MVNOの到達確認・遅延計測、W5で本番切替と送信数上限アラート等の監視設定という流れが標準です。
要件が複雑（マルチテナント対応・独自コード仕様など）な場合は+2〜3週間、認証を新規機能として作る場合はUI設計分で+1週間程度を上乗せしてください。送信元表示名（送信者ID）のキャリア審査が発生するサービスでは、審査に1〜2週間かかることがあるため、W0として契約前に着手しておくと後工程が詰まりません。
SMS認証サービスの料金・手数料を一括チェック
MCB FinTechカタログでは、SMS認証サービスの最新資料を一括でダウンロードできます。複数サービスの料金・機能・API仕様を横並びで比較したい方は、以下から無料で資料請求が可能です。
一括ダウンロードする
MCB FinTechカタログに掲載しませんか？
MCB FinTechカタログでは、掲載企業様を募集しています。マネックスグループの金融実務ノウハウを活かした独自の評価軸と検索設計により、導入検討者が最適なサービスを効率的に発見できる法人向け比較プラットフォームです。掲載後は管理画面から料金表や導入事例を随時更新でき、常に最新の情報を訴求可能。まずは下記フォームより、お気軽にお問い合わせください。
出典・参考資料（5件）
マネックス証券 フィナンシャル・インテリジェンス部 暗号資産アナリスト
松嶋真倫
監修の範囲は記事の一般的な解説部分であり、比較表および各製品・サービスの紹介内容は監修の対象外です。
SIMスワップ対策は、金融系サービスの稟議で必ず問われる項目です。全対策を一度に入れる必要はありませんが、少なくとも「重要取引の直前は追加要素を併設する」（例：SMS認証＋秘密の質問、SMS認証＋TOTPアプリ）を最初のリリースから組み込んでおくと、後から追加する際の設計変更負担が減ります。実装コストとリスクのバランスを取る際は、対象取引の金額規模と被害発生時の平均損失額を稟議に併記して、追加要素の投資判断根拠を明確にしましょう。