会員登録やログイン、決済の本人確認に、電話番号を使ったSMSのワンタイムパスワード（OTP）を導入したいと考えたとき、多くの担当者がまず突き当たるのが「自前でSMSを送って照合する仕組みは作れない」という壁です。この部分を肩代わりするのが、認証コードの送信や照合をプログラムから呼び出せるSMS認証APIです。
ただし、SMS認証APIと一口に言っても中身は分かれます。認証コードの生成から照合まで丸ごと任せられるサービスと、SMSの送信だけを担いコードの発行・照合は自社で実装するサービスがあり、料金の出し方も1通単価から認証の成功回数による課金までさまざまです。
サービス名と費用が具体的に見えないと、導入の可否も予算の見積もりも一歩も進みません。
この記事では、SMS認証APIを提供する主要サービスを料金・機能で横並びに比較し、通常のSMS送信APIとの違い、組み込みの流れと実務上の注意点、選び方、セキュリティ面の押さえどころまでを整理します。候補を2〜3社に絞り込み、資料請求や見積もりへ進むための判断材料としてご活用ください。
目次
一括ダウンロードする
SMS認証APIとは（通常のSMS送信APIとの違い）
ここでは、SMS認証APIがどういうもので、一般的なSMS送信APIと何が違うのかを整理します。SMS認証APIとは、利用者の携帯電話番号宛てに認証コード（ワンタイムパスワード、OTP）をSMSで送り、入力されたコードを照合して本人確認を行う一連の処理を、自社のシステムからプログラムで呼び出せるようにする仕組みです。
本人確認は、利用者の電話番号に使い捨ての認証コードを送り、入力されたコードを照合して行います（具体的な処理の流れは後半で解説します）。コードには有効期限があり、原則として一度しか使えません。
注意したいのは、SMS認証APIと呼ばれるサービスが、大きく2つのタイプに分かれる点です。ひとつは、コードの生成・送信・有効期限管理・照合・再入力回数の制御までをまとめて提供する「認証専用API型」です。自社でコードの管理や照合ロジックを持たずに本人認証を組み込めます。
もうひとつは、SMSの送信そのものをAPIで担い、コードの生成と照合は自社システム側で実装する「送信型」です。送信型でもSMS認証は実現できますが、開発や管理の範囲が広くなります。
どちらのタイプを選ぶかで、必要な開発工数と任せられる範囲が変わります。自社に認証ロジックを極力持ちたくない場合は認証専用API型が、送信基盤だけを柔軟に組み込みたい場合は送信型が向きます。次の比較表では、この「認証機能が内蔵されているか」を含めて、主要サービスを横並びで確認できます。
SMS認証APIを提供する主要サービスの横断比較
以下は、SMS認証（OTPの送信・照合）にAPIで対応する主要サービスの比較表です。認証機能が内蔵されているか、国内キャリアと直接接続しているか、料金はどのような体系か、といった選定に直結する観点をまとめています。料金は各社の公表状況により、具体額を示すものと要問い合わせのものが混在します。
| サービス名 | SMSLINK | オーロラSMS by メディアSMS | KDDI Message Cast | NTT CPaaS | Twilio | Infobip | Vonage Verify | Rakuten CPaaS | CM.com | 二段階認証（ジンテック） | SMSコネクト | SMS FourS | SMS Publisher | KYUSMS | Cuenote SMS | 絶対リーチ!SMS |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 認証機能内蔵 | ●オプションの認証機能で生成・照合までAPI運用 | ●認証専用API（OTP生成・照合判定） | △送信型（OTP生成・照合は自社実装） | ●2FA API（OTP生成・送信・照合。認証API機能は無料） | ●Verify API（OTP生成・送信・照合まで一元処理） | ●Authentication API（2FA・多段フェイルオーバー） | ●Verify API（PIN生成・配信・照合まで一元処理） | ●OTP（Confirm API）で二要素認証 | ●認証専用API（パスワード生成〜認証結果取得までAPIで完結） | ●生成・通知・認証・結果通知を包括処理するAPI | △送信型（OTP送信にAPI対応。2段階認証向け） | ●認証コード生成・配信・結果取得をワンストップ提供 | △SMS認証プラン（OTP送信にAPI対応） | △送信型（API連携でOTP送信。本人認証用途を明記） | △送信型（OTP送信にAPI。生成・照合は姉妹サービスCuenote Auth） | ●セキュアSMS認証（OTPを自動生成・送信。発番機能の自社開発不要） |
| 接続方式 | 国内キャリア直収（自社調べ到達率約98%） | 国内4キャリア直収（当社検証で到達率99.9%） | 国内4キャリア直収（共通番号0005） | 国内直収＋国際網（Infobip配信網） | 国際網（グローバルCPaaS）。日本向けSMSは提供 | 国際網（グローバル、800社以上の通信事業者と直結）。国内直収は公式未確認 | 国際網（グローバルCPaaS）。国内はKWC PLUS経由 | 国内4キャリア直収（SMS） | 国内直収＋国際網の両ルート | 国内発信（SMS配信は国内完結） | 国内4キャリア直収（到達率99.9%訴求） | 国内4キャリア直収 | 国内一次キャリア直収（4キャリア） | 国内4キャリア接続（国内外のキャリアと直接接続を訴求） | 国内4キャリア直収（2022年実績で到達率99.9%） | 国内直収ルート＋海外経由国内向けルート |
| 海外送信 | 公式に明記なし | 公式に明記なし | 公式に明記なし | ●200以上の国・地域 | ●グローバル対応 | ●190以上の国・地域 | ●グローバル網 | 公式に明記なし | ●199ヵ国以上 | 公式に明記なし | 公式に明記なし | 公式に明記なし | 公式に明記なし | ●海外キャリア宛に対応 | 公式に明記なし | 公式に明記なし |
| 料金（送信／認証） | 送信: SMS 1通6円〜（従量） 認証: オプション・単価は要問い合わせ | 送信: 要問い合わせ（従量・送信成功課金） 認証: 認証オールインワンに含む（別料金の明示なし） | 送信: SMS 1通9.35円（税込）〜・到達課金 認証: 送信型のため認証課金なし（自社実装） | 送信: SMS 1通10円（税込・70文字まで） 認証: 認証API機能は無料 | 送信: SMS $0.0890〜/通（USD・約13円／従量） 認証: Verify API（認証）は別料金・要確認 | 送信: 非公開（要問い合わせ・従量） 認証: Authentication APIは別・要問い合わせ | 送信: SMS 11円/通（国内KWC PLUS） 認証: 認証成功7.5円/回 | 送信: SMS 1通8.8円（税込・最低利用料なし） 認証: Confirm APIは別料金・要問い合わせ | 送信: 国内1通11円（70文字あたり・1リクエスト課金で失敗時も課金） 認証: 認証成功課金あり（金額は非公開） | 送信: 要問い合わせ 認証: 要問い合わせ（生成〜認証を包括処理するAPI） | 送信: 要問い合わせ（1通単価非公開・従量） 認証: 要問い合わせ（送信型・2段階認証向け） | 送信: 1通4.8〜7円（プラン別・配信成功課金） 認証: 認証コード生成・配信・結果取得に対応（別料金は要確認） | 送信: 要問い合わせ（成功課金） 認証: SMS認証プラン・料金は要問い合わせ | 送信: 要問い合わせ（従量・ボリューム割） 認証: 要問い合わせ（送信型・本人認証用途） | 送信: SMS 1通6円〜（配信成功課金） 認証: OTP生成・照合は姉妹サービス（別・要確認） | 送信: 1-Wayは月額1,000円〜 認証: セキュアSMS認証は要問い合わせ（成功課金） |
| 初期・月額 | 初期0円・月額0円（スタンダードプラン） | 初期0円・月額0円（従量制） | 初期0円・月額0円 | 初期0円・月額は要問い合わせ | 初期0円・月額0円（従量課金） | 要問い合わせ（非公開） | 初期0円・月額0円（国内KWC PLUS） | 初期0円・月額0円（最低利用料なし） | 初期0円／月額は要確認（5,000円〜との記載あり） | 要問い合わせ | 初期0円・月額は要問い合わせ | 初期0円・月額1,000円〜（Standard） | 初期0円〜（プランにより発生）・月額は要問い合わせ | 初期0円・月額は要問い合わせ | 初期0円・月額は要問い合わせ | 認証系プランは要問い合わせ（1-Wayは初期0円・月額1,000円） |
| 無料トライアル／サンドボックス | 公式に明記なし（要問い合わせ） | 最大2ヶ月 APIデモアカウントあり | あり（期間・通数の条件は要確認） | あり（60日間） | あり（新規登録でクレジット付与） | あり（SMS無料試用） | 公式に明記なし（要問い合わせ） | あり（3カ月・100通まで） | 即日利用可（クレカ登録）。トライアル期間の明記なし | 公式に明記なし | あり（無料デモアカウント） | テストアカウントあり（期間は要確認） | あり（最大2カ月・上限100通） | 公式に明記なし（要問い合わせ） | あり | あり（1-Wayは100通/月無料。セキュアSMS認証は0通） |
| 対応言語・SDK・日本語仕様書 | 日本語（国内）。簡易API（最短3日で開発可能） | 日本語（国内）。認証オールインワンの専用API | 日本語（国内）。HTTPS API（Salesforce/ServiceNow連携） | 日本語ドキュメント・SDK/API（SMS・音声・メール）、Webhook対応 | 各言語SDK（Python/Ruby/PHP/JS等）・TwiML 日本語ドキュメントは一部 | 各言語SDK（Java/C#/PHP/Go/Python等） 技術ドキュメントは英語主体 | 日本語の開発者ドキュメントあり（REST API） | 日本語（国内販売）。SMS/Confirm/短縮URL API | 日本語（日本法人・日本語サイト）。RESTful API | 日本語（国内）。API接続（仕様は要問い合わせ） | 日本語（国内）。HTTP(S)/SMPP対応API | 日本語（国内）。API連携 | 日本語（国内）。API連携（個別送信・一斉送信） | 日本語（国内）。API連携（Yoom連携に対応） | 日本語（国内）。RESTful API標準搭載（オンラインマニュアル） | 日本語。HTTPS Web API・SMPP v3.4（仕様書・API仕様書を提供） |
| 詳細情報 | 公式資料を見る | 公式資料を見る | 公式資料を見る | サービス詳細を見る | サービス詳細を見る | サービス詳細を見る | サービス詳細を見る | サービス詳細を見る | サービス詳細を見る | サービス詳細を見る | サービス詳細を見る | サービス詳細を見る | サービス詳細を見る | サービス詳細を見る | サービス詳細を見る | 公式サイト |
※ 料金は各社公式の公表情報（2026年10月時点）をもとにした目安です。税込・税別や通貨（Twilioは米ドル）、送信単価と認証成功課金の有無は各社で異なり、非公開の項目は「要問い合わせ」としています。
※「公式に明記なし」は海外送信などの対応可否が公式情報で確認できなかったもので、非対応と断定するものではありません。到達率は各社の自社調べで算出条件が異なり単純比較はできません。正確な金額・仕様は各社の最新情報や資料請求でご確認ください。
一括ダウンロードする
SMS認証APIの料金・課金モデルの読み方
ここからは、比較表の数字を自社の送信規模に当てはめて見積もるための、料金と課金モデルの読み方を整理します。多くのサービスは初期費用・月額基本料を0円とし、送信した通数に応じた従量課金を軸にしています。一方で、1通あたりの単価だけを見ても総額は読めません。課金の単位がサービスごとに異なるためです。
課金の単位には、主に次のような違いがあります。見積もりの際は、どの単位で費用が積み上がるのかを先に確認しておくと、想定外の請求を避けられます。
- 送信通数による従量課金：送信した通数×1通単価で積み上がる、最も一般的な方式です。
- リクエスト単位の課金：APIへのリクエスト1件ごとに課金する方式です。この場合、SMSが到達したかどうかに関わらず課金されることがあります。
- 認証成功分の追加課金：送信料とは別に、認証が成立した件数に対して課金する方式です。送信料だけで総額を見積もると不足します。
- 海外送信の国別料金：海外の電話番号へ送る場合、国ごとに単価が異なるのが一般的です。グローバルに利用するなら対象国の単価を個別に確認します。
たとえばCM.comは、公式のよくある質問で国内配信料を「1通70文字あたり11円の従量課金制」とし、それとは別に「一件ごとの認証成功費用」がかかると明記しています。さらに1リクエスト課金のため送信が失敗しても課金される、とも説明しており、到達・不到達に関わらず料金が発生する点が示されています。送信料・認証成功課金・失敗時の扱いを分けて確認する必要がある一例です。
認証成功課金を送信料と別に設ける例もあります。たとえばVonage Verifyは、国内提供（KWC PLUS経由）で認証が成功するごとに1回7.5円、これに加えてSMS送信1通あたり11円という、送信料と認証成功課金を組み合わせた料金を公開しています。送信通数だけで見積もると、この認証成功分が抜け落ちます。
一方、国内の送信を主とするサービスでは、初期費用・月額0円に加えて送信通数の従量課金で分かりやすく見積もれるものもあります。想定する月間の送信数と、認証成功課金・海外送信の有無を入れて試算すると、サービス間の総額の差が見えてきます。単価は変動するため、最終的な金額は各社の最新の料金ページや見積もりで確認してください。
出典・参考資料（1件）
- 出典：SMS認証APIサービスのよくある質問（API利用料・課金モデル）｜CM.com（https://www.cm.com/ja-jp/one-time-password）
SMS認証APIの組み込みの流れと実務の落とし穴
ここでは、SMS認証APIを自社サービスに組み込むときの処理の流れと、申し込みから本番稼働までの手順、そして後から気づきやすい実務上の注意点を見ていきます。
SMS認証APIの処理フロー（OTPの生成から照合まで）
SMS認証の処理は、次の流れで進みます。認証専用API型なら、このうちコードの生成から照合までをAPIの呼び出しで完結でき、送信型ならコードの生成・照合を自社側で実装します。
- 利用者が画面で電話番号を入力する
- システムが使い捨ての認証コード（OTP）を生成する
- 生成したコードをSMSで利用者の電話番号へ送信する
- 利用者が受け取ったコードを画面に入力する
- サーバー側でコードと有効期限を照合し、本人かどうかを判定する
- 有効期限切れや入力回数の超過を制御する（再送・再入力の制限）
認証専用API型では、コードの生成・送信・照合判定をひとつのAPIにまとめて呼び出せるため、自社で乱数生成や有効期限の管理、照合テーブルの設計を持たずに済みます。送信型を使う場合は、これらを自社システムで設計・運用することになります。
申し込みから本番までの手順と注意点
導入は、おおむね「サービスの選定→契約・認証情報の取得→開発・実装→テスト送信→本番リリース」という手順で進みます。多くのサービスはHTTPSで呼び出すREST形式のAPIを提供し、言語別のサンプルコードやSDKを用意しているため、HTTPリクエストを扱える一般的な開発環境であれば実装のハードル自体は高くありません。
一方で、申し込み直後には着手できない準備が必要なケースがあります。たとえばCM.comは、送信者名に電話番号を使う場合「法人保有の固定電話もしくは050番号のキャリア申請と設定に、営業日2〜3週間ほどのお時間をいただいております」と案内しています。送信元番号の準備に時間がかかると、開発が終わっても本番配信を始められないため、スケジュールには余裕を見ておくのが安全です。
実装時に見落としやすいのが、電話番号の形式です。国際標準のE.164形式（日本の番号なら国番号を付けて+81で始まる形式）への正規化をAPI呼び出しの前に済ませておくと、形式不正によるエラーを事前に防げます。
また、サンドボックス（検証用環境）で動いたのに本番でエラーになる場合は、まず管理画面の送信ログでエラーコードを確認し、送信元IDの扱いや本番環境のレート制限値の違いを疑うと、原因にたどり着きやすくなります。
本番移行の前には、無料トライアルや開発用アカウント、サンドボックスでテスト送信を行い、到達率や配信速度、自社システムとの接続を確認しておくことが推奨されます。
出典・参考資料（1件）
- 出典：SMS認証APIサービス（送信者名のキャリア申請・導入の流れ）｜CM.com（https://www.cm.com/ja-jp/one-time-password）
ここまでは組み込みの全体像を見てきましたが、実際のコード例やOTPの発行から突合までのシーケンス、開発でつまずきやすいポイントまで踏み込んだ実装手順は、開発者向けに別記事で詳しく解説しています。
SMS認証APIの選び方
ここからは、自社の要件に照らして候補を絞り込むための選定軸を整理します。比較表で各社の仕様を見比べたうえで、次の観点を自社の事情に当てはめると判断しやすくなります。
到達率で選ぶ（国内キャリア直収か国際網か）
認証コードが届かなければ本人確認は成立しません。到達率を左右するのが接続方式です。国内の携帯キャリアと直接接続する「キャリア直収」は、配信経路が明確で到達状況や遅延を把握しやすい傾向があります。
一方、海外事業者のネットワークを経由する「国際網接続」は、条件によってはコストを抑えられる場合がありますが、配信先キャリアのポリシーやルーティング設計の影響を受けやすく、到達率や遅延に差が出ることがあります。
国内の利用者への認証を安定させたいなら国内キャリア直収に対応したサービスが基本線です。海外の利用者にも送るなら、対応国の広さと国際網経由時の到達性を合わせて確認します。各社が公表する到達率は自社調べの数値であることが多いため、算出条件（受信拒否・圏外・電源オフを含むか）も併せて見ておくとよいでしょう。
この接続方式の違いは、実際のサービス乗り換えの相談にも表れます。特定サービスの推奨ではなく一例として、SMS配信サービス「SMSLINK」を提供する株式会社ネクスウェイへの取材から、接続方式と到達率の関係を紹介します。
当社は国内4キャリアすべてと直接接続しており、高品質で安定した通信環境を提供しています。実際に、他社サービスからのリプレイス理由として「SMSが届かない」という課題からお問い合わせをいただくことも多いです。
開発しやすさで選ぶ（仕様書・サンプルコード・SDK）
実装にかかる工数は、ドキュメントの充実度で大きく変わります。日本語のAPI仕様書があるか、自社で使う言語のサンプルコードやSDKが提供されているかを確認します。認証専用API型を選べば、コードの生成・照合ロジックを自社で持たずに済むため、送信型でゼロから認証フローを組むより開発範囲を狭められます。短期間で組み込みたい場合は、この点が選定の分かれ目になります。
サポート体制とバックアップ認証で選ぶ
導入後の運用まで見据えるなら、サポート体制と、SMSが届かなかったときの代替手段も確認しておきます。問い合わせ窓口や障害対応の体制に加えて、SMSが不達になった場合に音声通話（自動音声応答）やメールで認証コードを届けられるかどうかは、認証の取りこぼしを防ぐうえで効きます。
固定電話しか持たない利用者や、電波状況でSMSが届きにくい利用者にも本人確認を通せるかを基準に加えると、取りこぼしの少ない設計に近づきます。
SMS認証のセキュリティとコンプライアンス
SMS認証は手軽で導入しやすい本人確認の手段ですが、万能ではありません。導入後に想定外のリスクに直面しないよう、押さえておきたい論点を整理します。
SIMスワップのリスクと多要素での補完
SMSで受け取る認証コードは、携帯電話番号そのものが乗っ取られると第三者に渡ってしまいます。その代表的な手口がSIMスワップです。福岡県警察は、SIMスワップを次のように説明し、注意を呼びかけています。
「SIMスワップ」とは、正規の利用者になりすましてSIMカードの再発行手続きを行い、携帯電話番号などを乗っ取る手口です。
出典：福岡県警察「SIMスワップに注意！！ 携帯電話のSIMが狙われています!!」
こうしたリスクを踏まえ、国際的な認証ガイドラインである米国国立標準技術研究所（NIST）の「SP 800-63B-4」は、公衆交換電話網（PSTN）を使うSMS・音声の認証を「制限付き（restricted）」の手段と位置づけています。禁止ではなく、条件付きで使える手段という整理です。
同ガイドラインは、こうした手段を使う場合に、制限されていない代替の認証手段を少なくとも1つ利用者に提供すること、リスクを利用者に知らせることなどを求めています。さらに、SMSで認証コードを送る前に「device swap, SIM change, number porting」といったリスクの兆候を考慮すべきだとしています。
実務への示唆は明確です。SMS認証だけに頼らず、重要な操作には別の認証手段を併用できるようにしておくこと、そしてSIMスワップの兆候が疑われる場合に備えることが、公的な標準でも求められる水準といえます。前述のバックアップ認証（音声・メール）や、認証アプリなど他の手段との併用を検討する価値があります。
出典・参考資料（1件）
- 出典：NIST Special Publication 800-63B-4「Digital Identity Guidelines」§3.1.3.3 / §3.2.9｜米国国立標準技術研究所（https://pages.nist.gov/800-63-4/sp800-63b.html）
総当たり対策（レート制限・再入力回数制限）
認証コードは桁数が限られるため、何度も入力を試されると総当たりで突破されるおそれがあります。対策として、一定時間内の送信回数や再入力回数に上限を設ける制御が有効です。NIST SP 800-63B-4も、送信前のリスク評価と並んで、認証試行の回数に合理的な上限を設けることを求めています。
サービスによっては、特定の電話番号への送信回数の制限や、認証に一度成功したコードの再利用を禁止する設定をAPIで用意しています。導入時には、再入力の制限回数やコードの有効期限、同一番号への送信上限といったパラメータを、自社の運用に合わせて設定できるかを確認しておきます。具体的な設定値や仕様は各社のAPIドキュメントで確認してください。
電話番号の取り扱いとコンプライアンス
SMS認証では利用者の電話番号を取得・保管します。電話番号の取り扱いを考えるうえで前提になるのが、個人情報保護法上の位置づけです。個人情報保護委員会は、よくある質問で次のように説明しています。
（住所や電話番号だけで個人情報に該当しますか、という問いに対し）個別の事例ごとに判断することになりますが、他の情報と容易に照合することにより特定の個人を識別することができる場合、当該情報とあわせて全体として個人情報に該当することがあります。
出典：個人情報保護委員会「『個人情報の保護に関する法律についてのガイドライン』に関するQ&A」Q1-3
電話番号は単体で一律に個人情報となるわけではなく、他の情報と容易に照合して特定の個人を識別できる場合に、全体として個人情報に該当します。SMS認証では電話番号を利用者のアカウント（氏名やID）と結び付けて保持するのが通常であり、この「容易照合性」が成立するため、実務上は個人情報として適切に管理するのが妥当です。取得・保管・利用の各段階でプライバシーポリシーへの明記が求められます。
運用面では、APIサービスへ電話番号を送る通信経路が暗号化（TLS）されているかを確認し、ログへ電話番号を無制限に記録せずマスキングするといった配慮が有効です。認証に使ったコードは、照合が完了したら速やかに削除し、長期間保持しない設計にしておくと、漏えい時の影響を抑えられます。
出典・参考資料（1件）
- 出典：個人情報の保護に関する法律 第2条第1項｜e-Gov法令検索（https://laws.e-gov.go.jp/law/415AC0000000057）
SMS認証に使える主要サービス
ここでは、上の比較表で取り上げたサービスのうち、認証用途に対応し、国内キャリアと直接接続する主要3社を個別に紹介します。いずれも携帯電話番号宛てにSMSで認証コードを届けられ、本人確認・二段階認証に利用できます。ここで取り上げないサービスも、比較表の各行から公式情報を確認できます。
1. SMSLINK（株式会社ネクスウェイ）
SMSLINKは、FAXや郵送などの法人向けコミュニケーションを長年手がけてきた株式会社ネクスウェイ（TISインテックグループ）が提供するSMS配信サービスです。本体のSMS配信に加えて、オプションの認証機能を使うと、認証コードの生成からSMS・音声での送信、照合までの一連の処理をAPI連携だけで運用できます。
SMS送信に失敗した場合は自動で音声通話に切り替わるため、固定電話しか持たない利用者への到達も補えます。
国内の携帯キャリアと直接接続し、本人確認・認証の活用例ページでは自社調べで約98%の到達率を掲げています。不正アカウントの作成やなりすましの防止を用途として公式に示している点も、認証用途に適しています。
初期費用・月額費用は0円（スタンダードプラン）で、SMS送信は1通6円からの従量課金から始められます。認証機能はオプション提供で、最短3日で開発できる簡易APIも用意されており、電子契約の二要素認証を7日足らずで構築した導入事例もあります。
2. オーロラSMS by メディアSMS（株式会社メディア4u）
認証専用APIを前面に据えているのが、株式会社メディア4uのオーロラSMS by メディアSMSです。同社側でワンタイム認証コード（OTP）を生成し、送信先の電話番号と入力コードの合致判定までをAPIひとつで返す「認証オールインワン」の仕組みを提供しており、自社で照合ロジックを持たずに本人認証を組み込めます。
SMSが届かない場合に備えて、電話番号だけで認証を進められるIVR（自動音声応答）認証を補完手段として組み合わせられる点も特徴です。
到達面では、国内4キャリアへの直収接続により、自社検証試験で99.9%（受信拒否・圏外・電源オフを除く）の到達率を掲げています。過去の利用履歴と照らし合わせて他人名義の可能性がある番号を抽出・警告する「他人接続判定」機能もAPIで提供し、なりすまし・誤送信対策に寄与します。初期費用・月額基本料は0円の従量制で、最大2ヶ月の無料トライアルとAPIの無料デモアカウントで事前に検証できます。
3. KDDI Message Cast（KDDI株式会社）
通信事業者であるKDDI株式会社がSupership株式会社と共同運営するのが、法人向けメッセージ配信サービスのKDDI Message Castです。SMS・RCS・＋メッセージを一斉／自動配信できるプラットフォームで、HTTPS APIを通じてアプリの会員登録時の本人確認やログイン時の二段階認証に組み込めます。
認証コードの生成・検証は利用企業側のシステムで実装する送信型にあたり、SMS送信をこのサービスが担う形です。
au・NTTドコモ・ソフトバンク・楽天モバイルの携帯4社に対応する共通番号「0005」でキャリア網に直接接続し、自社調べで98%以上の到達率を掲げています。キャリア公認の共通番号や＋メッセージの認証済みマークにより、なりすまし・迷惑SMS対策を強化している点も、通信事業者ならではの特徴です。
初期費用・月額0円で、到達した分のみ課金される到達課金を採用し、SMSは1通9.35円（税込）からとなっています。
API連携に限らず、SMS認証サービス全体の仕組みや本人確認のやり方、導入メリット、おすすめサービスの比較まで広く確認したい場合は、以下の記事もあわせてご覧ください。
まとめ
SMS認証APIを選ぶときは、まず「認証コードの生成・照合まで内蔵する認証専用API型か、送信だけを担う送信型か」を押さえると、必要な開発範囲が見えてきます。そのうえで、1通単価だけでなく認証成功課金や失敗時の扱いを含めた課金モデル、国内キャリア直収による到達率、日本語仕様書やSDKの充実度、SMS不達時のバックアップ認証を自社の要件に当てはめて比較すると、候補を絞り込めます。
自社の状況から候補を絞るなら、国内の利用者向けに認証を最短で組み込みたい場合は、OTPの生成・照合まで内蔵し国内キャリア直収に対応したサービスが本命になります。海外の利用者にも送るなら、グローバル網を持つサービスを軸に、対応国と国別の料金を確認します。送信基盤だけを柔軟に使い、認証ロジックは自社で持ちたい場合は、送信型のサービスが選択肢です。
比較表で認証機能の内蔵有無・接続方式・料金を見比べ、2〜3社に絞って資料請求へ進むのが現実的です。
加えて、SIMスワップへの備えや総当たり対策、電話番号の適切な取り扱いといったセキュリティ面も、導入前に確認しておきたい論点です。気になるサービスが見つかったら、料金表やAPI仕様書の詳細を資料請求で取り寄せ、無料トライアルやサンドボックスでテスト送信を試してから社内で検討を進めるとよいでしょう。
一括ダウンロードする
よくある質問（FAQ）
Q. SMS認証APIとは何ですか？
A. SMS認証APIとは、携帯電話番号宛てに認証コード（ワンタイムパスワード、OTP）をSMSで送り、入力されたコードを照合して本人確認を行う処理を、自社システムからプログラムで呼び出せるようにする仕組みです。
認証コードの生成・送信・照合までを内蔵する「認証専用API型」と、SMSの送信だけを担いコードの生成・照合は自社で実装する「送信型」の2タイプに分かれます。どちらを選ぶかで必要な開発範囲が変わります。
Q. SMS認証にAPIは必須ですか？管理画面からの手動送信では対応できませんか？
A. SMS認証をシステムに組み込んで自動化するなら、原則としてAPIが必要です。会員登録やログインのたびに認証コードを即時送信するには、自社システムからの自動呼び出しが欠かせないためです。
一方、送信頻度が少なく担当者が手作業でSMSを送れば足りる業務であれば、管理画面からの手動送信でも対応できます。認証用途のように利用者の操作に応じてリアルタイムで送る必要がある場合に、API連携が前提になります。
Q. SMS認証APIの導入にはどれくらいの開発工数・難易度がかかりますか？
A. SMS認証APIの実装難易度は、多くのサービスがHTTPSで呼び出すREST形式のAPIと言語別のサンプルコード・SDKを用意しているため、HTTPリクエストを扱える一般的な開発環境であれば高くありません。
工数は選ぶタイプで変わります。認証専用API型ならコードの生成・有効期限管理・照合を自社で持たずに済むため開発範囲を狭められ、送信型はこれらを自社で設計・運用する分だけ工数が増えます。日本語の仕様書やサンプルコードが自社の利用言語に揃っているかを事前に確認すると、見積もりの精度が上がります。
Q. SMS認証APIの「キャリア直収」と「国際網接続」は何が違いますか？
A. キャリア直収は国内の携帯キャリアと直接接続して配信する方式で、配信経路が明確で到達状況や遅延を把握しやすいのが特長です。
一方、国際網接続は海外事業者のネットワークを経由する方式で、条件次第でコストを抑えられる反面、ルーティングや配信先ポリシーの影響で到達率・遅延に差が出やすいという違いがあります。
国内の利用者への認証を安定させたい場合は、国内キャリア直収に対応したサービスが基本線です。海外にも送るなら、対応国の広さと国際網経由時の到達性を併せて確認します。
Q. SMS認証にAPIを使うメリットと、SIMスワップなどのリスクを教えてください。
A. SMS認証APIのメリットは、携帯電話番号さえあれば利用者の追加アプリなしに本人確認を自動化でき、導入のハードルが低いことです。一方の代表的なリスクが、SIMカードを不正に再発行させて電話番号ごと乗っ取るSIMスワップで、これにより認証コードが第三者に渡るおそれがあります。
米国国立標準技術研究所（NIST）のガイドライン「SP 800-63B-4」も、SMSによる認証を「制限付き」の手段と位置づけ、代替の認証手段の提供やリスク兆候の考慮を求めています。重要な操作では、認証アプリなど他の手段との併用を検討すると安全です。
Q. SMS認証APIの料金はどのような体系ですか？
A. SMS認証APIの料金は、初期費用・月額基本料を0円とし、送信通数に応じた従量課金を軸にするサービスが多いですが、総額は1通単価だけでは読めません。課金の単位がサービスごとに異なるためです。
送信通数による従量課金のほかに、APIリクエスト1件ごとの課金（SMSが届かなくても課金される場合がある）、送信料とは別の認証成功課金、海外送信の国別料金などがあります。実際にCM.comは国内配信料を1通70文字あたり11円の従量課金としたうえで、別途の認証成功費用と、送信失敗でも発生する1リクエスト課金を公式に明記しています。見積もりでは、どの単位で費用が積み上がるかを先に確認してください。
Q. SMS認証APIは本番導入の前にテスト送信できますか？
A. SMS認証APIの多くは、無料トライアルや開発用アカウント、サンドボックス（検証用環境）を提供しており、本番契約の前にテスト送信で検証できます。
到達率や配信速度、自社システムとの接続を事前に確認しておくと、本番移行後のトラブルを減らせます。サンドボックスで動いたのに本番でエラーになる場合は、まず管理画面の送信ログでエラーコードを確認すると原因にたどり着きやすくなります。
Q. SMS認証APIで総当たり攻撃を防ぐには、再入力や送信回数を制限できますか？
A. SMS認証APIでは、一定時間内の再入力回数や同一番号への送信回数に上限を設ける制御や、一度認証に成功したコードの再利用を禁止する設定をAPIで用意しているサービスがあり、総当たり対策に使えます。
認証コードは桁数が限られるため、回数制限がないと総当たりで突破されるおそれがあります。NIST SP 800-63B-4も、認証試行の回数に合理的な上限を設けることを求めています。再入力の制限回数・コードの有効期限・同一番号への送信上限を自社の運用に合わせて設定できるかを、各社のAPIドキュメントで確認してください。
Q. SMS認証APIの送信者名（送信元）は、準備に時間がかかりますか？
A. SMS認証APIの送信者名は、電話番号を使う場合にキャリアへの申請と設定で数週間かかることがあり、申し込み直後には本番配信を始められない点に注意が必要です。
たとえばCM.comは、送信者名に電話番号を使う場合「法人保有の固定電話もしくは050番号のキャリア申請と設定に、営業日2〜3週間ほど」かかると案内しています。開発が終わっても送信元の準備待ちで配信を始められないことがあるため、スケジュールには余裕を見ておくと安全です。
Q. SMS認証APIに渡す電話番号は、E.164形式にする必要がありますか？
A. SMS認証APIに渡す電話番号は、国際標準のE.164形式（日本の番号なら国番号を付けた+81で始まる形式）へ正規化しておくのが基本で、API呼び出しの前に済ませておくと形式不正によるエラーを防げます。
電話番号の形式チェックはアプリ側でも事前に行い、実際に使われている番号かどうかの存在確認はAPI側に任せる、という役割分担にすると、エラーの発生を抑えられます。
Q. SMS認証で扱う利用者の電話番号は、個人情報として管理する必要がありますか？
A. SMS認証で扱う電話番号は、氏名やIDと結び付けて保持するのが通常で、他の情報と容易に照合して特定の個人を識別できる状態になるため、実務上は個人情報として適切に管理するのが妥当です。
個人情報保護委員会も、住所や電話番号は「他の情報と容易に照合することにより特定の個人を識別することができる場合、当該情報とあわせて全体として個人情報に該当することがある」と説明しています。取得・保管・利用の各段階でプライバシーポリシーに明記し、通信経路の暗号化（TLS）やログのマスキング、認証済みOTPの速やかな削除といった配慮が有効です。
SMS認証サービスの料金・資料を一括チェック
MCB FinTechカタログでは、SMS認証APIに対応する法人向けサービスの最新資料を無料で一括請求できます。料金・認証機能・対応キャリア・API連携のしやすさをまとめて比較できます。
一括ダウンロードする
MCB FinTechカタログに掲載しませんか？
MCB FinTechカタログでは、掲載企業様を募集しています。マネックスグループの金融実務ノウハウを活かした独自の評価軸と検索設計により、導入検討者が最適なサービスを効率的に発見できる法人向け比較プラットフォームです。掲載後は管理画面から料金表や導入事例を随時更新でき、常に最新の情報を訴求可能。まずは下記フォームより、お気軽にお問い合わせください。
マネックス証券 フィナンシャル・インテリジェンス部 暗号資産アナリスト
松嶋真倫
監修の範囲は記事の一般的な解説部分であり、比較表および各製品・サービスの紹介内容は監修の対象外です。
