← Blog
Developer Guide · 14 分で読めます · Updated 4月 2026

SMS認証APIガイド 2026: Twilio, Vonage, MessageBird, Plivo

SMS認証APIガイド 2026: Twilio, Vonage, MessageBird, Plivo

SMS認証APIとは？

SMS認証APIは、1つのタスクを実行します。それは、電話番号にワンタイムパスワード（OTP）を送信し、ユーザーがそれを正しく入力したかどうかを確認することです。これは表面的な説明です。興味深いのは、その裏にあるすべてです。

実際の認証APIは、自分で構築したくない5つのことを処理します。

主な3つの用途は、サインアップ時のOTP配信、ログイン時の二要素認証、および高リスク取引の確認です。ほとんどのチームは、これらすべてに同じAPIを使用します。一部の大規模チームは、冗長性のためにプロバイダーを分割しますが、これは後で説明します。

専用SMS認証APIを使用する理由

自分で構築することも可能です。それを否定するつもりはありません。キャリアアグリゲーターと直接契約を結び、独自のSMPPゲートウェイをセットアップし、独自のコードジェネレーターを開発できます。私たちはチームがそうするのを見てきました。また、それらのチームが18ヶ月後に静かにTwilioに移行するのを見てきました。

ほとんどのチームが管理されたAPIに料金を支払う理由は次のとおりです。

キャリアとの関係はコードよりも重要です。 Twilioは世界中の何百ものキャリアと直接的な関係を持っています。Vonage（旧Nexmo）は2010年からこの分野に取り組んでいます。これらの関係には実際のお金がかかり、構築には何年もかかります。週末に再現することはできません。

不正行為は常に変化しています。 トール詐欺攻撃（SMSポンピングとも呼ばれます）は、実際のビジネスに四半期あたり数十万ドルの損害を与えています。パターン：攻撃者はサインアップフォームを使用して、低ボリュームの国のプレミアムレート番号に認証コードを送信し、キャリアはSMSコストの一部を攻撃者に還元します。主要なAPIは、これに対する検出を調整するために長年を費やしてきました。

コンプライアンスは無視できない税金です。 インドのDLT登録だけでも数週間かかり、現地の法人が必要です。フランスのCNILルールは、フランスのユーザーがいる場合に適用されます。APIプロバイダーは、あなたが気づいていなくても、これらを処理します。

配信品質はホットルートに依存します。 「ホットルート」とは、5秒未満でメッセージを配信する高優先度のキャリアパスです。コールドルートは数分かかるか、サイレントに失敗する可能性があります。APIを介してホットルートへのアクセスを購入することは、直接交渉するよりも劇的に安価です。

したがって、月に100万件以上の認証を実行し、専用のインフラストラクチャチームがない限り、計算上はAPIを使用するのが合理的です。問題はどれを選ぶかです。

2026年トップ5SMS認証API

私たちは、米国、インド、ドイツ、ブラジルの番号にOTPを送信し、バックエンドでコードを検証するという同じワークフローで各プロバイダーをテストしました。2026年3月の30日間のウィンドウで、プロバイダーごとに国あたり100回の認証を実行しました。結果は次のとおりです。

1. Twilio Verify

Twilioが理由もなくデフォルトの選択肢ではありません。そのVerify APIは、一般的なProgrammable Messaging APIとは別に、OTPフロー専用に構築されています。この分離は、送信済みSMSと受信Webhookごとに支払うのではなく、検証ごとの均一な価格設定を提供するため重要です。

検証ごとの価格設定： 成功した検証あたり$0.05（米国）、国際的には$0.07〜$0.20、一部の国ではキャリア手数料が追加されます。これはほとんどの開発者が気にする価格です。

気に入った点： SDKの使いやすさは比類がありません。ドキュメントはゴールドスタンダードです。チャネルフォールバック（SMSから音声、メールへ）はすぐに機能します。不正検出は、何も設定しなくても、テスト期間中に2回のSMSポンピング試行を検出しました。

気に入らなかった点： 国際ルートでの価格の上昇。インド、インドネシア、ブラジルは、見出しレートが示唆するものよりも著しく高価です。一部の市場では、キャリア手数料が請求額を倍増させることがあります。

最適な用途： 米国中心のトラフィック、ドキュメントを重視するチーム、音声フォールバックが必要なすべての人。

2. Vonage Verify（旧Nexmo）

Vonageはこの分野でほぼ誰よりも長く活動しています。そのVerify APIは成熟しており、文書化されており、サーバーでのPINチェックが組み込まれています。OTPをデータベースに保存する必要がないため、セキュリティモデルからストレージ攻撃のクラスを削除します。

検証ごとの価格設定： 成功した検証あたり$0.062（米国）、国際的には同様の段階的価格設定です。テストしたほとんどの市場で、その価格設定はTwilioよりも均一に近い価格です。

気に入った点： 二要素チェックアウトフローはクリーンです。Twilioにはない3回の再試行が同じ検証料金に含まれています。サポートチームは実際に技術的な質問に答えます。

気に入らなかった点： ダッシュボードは2018年に最後に再設計されたように見えます。Node.js SDKには、Promiseの拒否に関するいくつかの粗い部分があります。Webhook署名は2024年初頭には一貫性がありませんでしたが、現在は修正されているようです。

最適な用途： 均一な国際料金を希望し、OTPストレージを自分で管理したくないチーム。

3. MessageBird（現Bird）

MessageBirdは2023年にBirdにブランド変更し、開発者プラットフォームを再構築しました。新しいAPIはよりクリーンですが、動的なターゲットでもあります。テスト期間中に2回の破壊的変更に遭遇しました。

検証ごとの価格設定： 国によって検証あたり$0.04〜$0.08。表面的には最も安価なオプションの1つです。

気に入った点： Flow Builderを使用すると、非技術的なチームメンバーが再デプロイせずに検証フローを調整できます。欧州のキャリアルートは優れています（元々はオランダの会社です）。GDPRの姿勢は、監査した中で最も徹底的です。

気に入らなかった点： ブランド変更以来、APIの安定性は不安定でした。ドキュメントは、一部の場所で実際のAPIに遅れをとっています。一部のレガシーエンドポイントは、明確な移行パスなしで非推奨になっています。

最適な用途： EU中心のトラフィック、すぐにGDPR準拠のデフォルトが必要なチーム。

4. Plivo

Plivoは、同様の機能セットを持つTwilioの予算代替品として位置づけられています。私たちのテストでは、それはおおよそ正確ですが、いくつかの実際のトレードオフがあります。

検証ごとの価格設定： 検証あたり$0.045（米国）、国際的には段階的な料金設定です。多くの場合、高ボリュームの最も安価なオプションです。

気に入った点： ほとんどの米国およびEUトラフィックに対して、価格は実際にTwilioよりも低いです。バランスシステムはクリーンです。サポートチームは、営業時間中は1時間以内に応答します。API設計はTwilioのほぼクローンであり、移行はほぼ painless です。

気に入らなかった点： インドとブラジルの配信率は、私たちのテストではTwilioよりも測定可能に悪かったです。不正検出は、より明白な攻撃を検出できませんでした。検証APIは他のものよりも新しいため、コーナーケースがまだ発生しています。

最適な用途： 主に米国またはEUのトラフィックを持つ、コストに敏感なチーム。

5. Sinch

Sinchはエンタープライズオプションです。Inteliquent、MessageMedia、およびその他のいくつかのキャリアを買収し、他のすべての人がプレミアム料金を支払う市場で直接ルートを持っています。その価格設定はこのポジショニングを反映しています。

検証ごとの価格設定： カスタムエンタープライズ価格設定、通常はボリュームコミットメントに応じて検証あたり$0.04〜$0.10。営業担当者との会話なしでは評価が難しいです。

気に入った点： キャリアとの関係は本物です。インドの配信率は測定した中で最高でした。音声フォールバックの品質は、私たちのテストではTwilioよりも優れています。

気に入らなかった点： 透明な価格設定はありません。セルフサービスオンボーディングは競合他社よりも劣っています。APIには、他のものよりも多くのレガシーな癖があります。

最適な用途： 高ボリュームで交渉する忍耐力のあるエンタープライズチーム。

SMS認証API価格比較

ここでは、典型的な2026年の料金を並べて比較します。すべての価格は、2026年4月1日現在、成功した検証あたり、米国ルートの料金です。国際料金は国によって異なります。

プロバイダー米国料金EU平均インドブラジル最低チャージ
Twilio Verify$0.05$0.07$0.18$0.14$20
Vonage Verify$0.062$0.075$0.16$0.13$10
Bird (MessageBird)$0.04$0.06$0.20$0.15$20
Plivo$0.045$0.065$0.22$0.17$25
Sinch$0.04-$0.10変動$0.11$0.12エンタープライズ

注目すべき点は2つあります。第一に、見出しの米国料金は単独では誤解を招きます。意味のある国際トラフィックがある場合、国別の料金は米国料金よりも重要です。第二に、インドとブラジルの価格設定は大きく異なります。どちらかの市場をターゲットにしている場合は、コミットする前に独自のテストを実行してください。

月に100,000回の検証を実行し、米国60％、EU 30％、その他20％に分割する高ボリュームチームの場合、現実的な月額費用は、選択するプロバイダーによって$5,200から$7,800の間になります。失敗率を含めると、最も安いオプションが常に総コストが最も低いとは限りません。

コード例：OTPの送信

ここでは、3つのプロバイダーと3つの言語での同じワークフローを示します。形状は十分に似ているため、通常はエンドポイントURLとパラメータ名を変更することで、それらの間でコードを移植できます。

Node.jsとTwilio Verify

const accountSid = process.env.TWILIO_ACCOUNT_SID;
const authToken = process.env.TWILIO_AUTH_TOKEN;
const verifyServiceSid = process.env.TWILIO_VERIFY_SERVICE_SID;
const client = require('twilio')(accountSid, authToken);

async function sendVerification(phoneNumber) {
  try {
    const verification = await client.verify.v2
      .services(verifyServiceSid)
      .verifications
      .create({ to: phoneNumber, channel: 'sms' });
    return { success: true, status: verification.status };
  } catch (error) {
    console.error('Twilio verification failed:', error.message);
    return { success: false, error: error.message };
  }
}

async function checkVerification(phoneNumber, code) {
  const result = await client.verify.v2
    .services(verifyServiceSid)
    .verificationChecks
    .create({ to: phoneNumber, code });
  return result.status === 'approved';
}

このコードに関するいくつかの注意点。verifyServiceSidはTwilioダッシュボードで一度作成され、すべての検証で再利用されます。ステータスフィールドはpending、approved、canceled、またはfailedとして返されます。それぞれを明示的に処理してください。successがapprovedを意味すると仮定しないでください。

PythonとVonage Verify

import os
import vonage

client = vonage.Client(
    key=os.environ['VONAGE_API_KEY'],
    secret=os.environ['VONAGE_API_SECRET']
)
verify = vonage.Verify(client)

def send_verification(phone_number, brand_name='YourApp'):
    response = verify.start_verification(
        number=phone_number,
        brand=brand_name,
        code_length=6,
        pin_expiry=300
    )
    if response['status'] == '0':
        return {'success': True, 'request_id': response['request_id']}
    return {'success': False, 'error': response.get('error_text')}

def check_verification(request_id, code):
    response = verify.check(request_id, code=code)
    return response['status'] == '0'

Vonageは、電話番号ではなく、検証のハンドルとしてrequest_idを使用します。これをセッションまたはデータベースにユーザーレコードと一緒に保存します。pin_expiryは秒単位です。ここでは300（5分）を使用しており、ほとんどのアプリがユーザーに表示するものと一致します。

PHP cURLとMessageBird (Bird)

<?php
$accessKey = getenv('BIRD_ACCESS_KEY');
$workspaceId = getenv('BIRD_WORKSPACE_ID');

function sendVerification($phoneNumber) {
    global $accessKey, $workspaceId;
    $url = "https://nest.messagebird.com/workspaces/{$workspaceId}/channels/sms/verify";
    $payload = json_encode([
        'recipient' => $phoneNumber,
        'codeLength' => 6,
        'expiry' => 300
    ]);

    $ch = curl_init($url);
    curl_setopt_array($ch, [
        CURLOPT_RETURNTRANSFER => true,
        CURLOPT_POST => true,
        CURLOPT_POSTFIELDS => $payload,
        CURLOPT_HTTPHEADER => [
            'Authorization: AccessKey ' . $accessKey,
            'Content-Type: application/json'
        ]
    ]);

    $response = curl_exec($ch);
    $statusCode = curl_getinfo($ch, CURLINFO_HTTP_CODE);
    curl_close($ch);

    if ($statusCode === 201) {
        return ['success' => true, 'data' => json_decode($response, true)];
    }
    return ['success' => false, 'error' => $response];
}

Bird APIはURLパスにワークスペースIDを必要とします。これは、古いMessageBirdエンドポイントからの最近の変更です。レガシーAPIから移行している場合、これが最も一般的な落とし穴です。

配信ステータスのためのWebhookセットアップ

OTPの送信は仕事の半分です。もう半分は、それが実際に到着したかどうかを知ることです。すべての主要なAPIは配信ステータスのためのWebhookをサポートしていますが、実装の詳細は異なります。

ここでは、どのプロバイダーにも出発点として機能する汎用的なExpress.js Webhookハンドラーを示します。

const express = require('express');
const crypto = require('crypto');
const app = express();

app.post('/webhooks/sms-status', express.json(), (req, res) => {
  const signature = req.headers['x-provider-signature'];
  const expectedSignature = crypto
    .createHmac('sha256', process.env.WEBHOOK_SECRET)
    .update(JSON.stringify(req.body))
    .digest('hex');

  if (signature !== expectedSignature) {
    return res.status(401).send('Invalid signature');
  }

  const { messageId, status, errorCode, phoneNumber } = req.body;

  switch (status) {
    case 'delivered':
      logSuccess(messageId);
      break;
    case 'failed':
      handleFailure(messageId, errorCode, phoneNumber);
      break;
    case 'undelivered':
      retryWithFallbackChannel(phoneNumber);
      break;
    default:
      console.log(`Unhandled status: ${status}`);
  }

  res.status(200).send('OK');
});

本番環境でのWebhookに関して私たちが従ういくつかのルールがあります。常に署名を検証してください。認証されていないWebhookエンドポイントは開かれたドアです。常にすぐに200を返してください。処理に時間がかかっても、実際の作業はバックグラウンドジョブにキューに入れます。プロバイダーはタイムアウト時に再試行するため、冪等性が重要です。

消費者向けの仮想番号が必要ですか？

VerifySMSを試す →

150+カ国 · 即時アクティベーション · 検証あたり$0.10

レート制限と再試行戦略

レート制限は、ほとんどのチームが失敗する場所です。これは私たちが使用するパターンです。

電話番号ごとのレート制限。 10分間に同じ電話番号に3回以上のOTP送信は行わないでください。これにより、偶発的なリクエストループとほとんどのカジュアルな悪用が停止します。

IPごとのレート制限。 5分間に同じIPから10回以上のOTPリクエストは行わないでください。共有オフィスを妨げない程度に緩く、サインアップボットを遅くするのに十分なタイトさです。

アカウントごとのレート制限。 ユーザーアカウントが24時間以内に5回以上の認証失敗を記録した場合、アカウントをロックし、メールリセットを要求します。これは、私たちがリリースした中で最も効果的な不正防止策です。

再試行時の指数バックオフ。 APIが5xxエラーを返した場合、1秒後に1回、次に4秒後に1回再試行し、その後は諦めます。4xxエラーはほぼ常に永続的であるため、再試行しないでください。

これは実際には次のようになります。

async function sendWithRetry(phoneNumber, maxAttempts = 3) {
  for (let attempt = 1; attempt <= maxAttempts; attempt++) {
    try {
      const result = await sendVerification(phoneNumber);
      if (result.success) return result;
      if (result.statusCode >= 400 && result.statusCode < 500) {
        return result;
      }
    } catch (error) {
      if (attempt === maxAttempts) throw error;
      const delay = Math.pow(2, attempt) * 1000;
      await new Promise(resolve => setTimeout(resolve, delay));
    }
  }
}

エラー処理：配信失敗と国別ブロック

すべてのSMS APIはわずかに異なる形式でエラーを返しますが、一般的な失敗モードは普遍的です。それらを処理する方法は次のとおりです。

無効な電話番号形式。 エラーをすぐにユーザーに返します。再試行しないでください。APIクレジットを消費しないでください。

番号が「おやすみモード」リストにある。 ユーザーのキャリアが番号をマーケティングSMSのオプトアウトとしてフラグ付けしました。一部のAPIでは、これをバイパスするためにメッセージをトランザクショナルとしてフラグ付けできます。他のAPIでは、手動のキャリア介入が必要です。実際には、メールまたは音声チャネルにフォールバックします。

国が制限されている。 一部の国（キューバ、イラン、北朝鮮、クリミアの一部）は制裁リストに載っています。APIは送信を拒否します。サインアップ時にこれを検出し、ユーザーをメール認証に誘導します。

キャリアフィルタリング。 キャリアがメッセージをサイレントにドロップしました。配信確認は届きません。検証試行で90秒のタイムアウトを設定します。コードが届かない場合は、ユーザーに再試行またはチャネルの切り替えを促します。

残高不足。 事前払いクレジットがゼロになりました。ゼロではなく、残高が20％になったときにアラートを設定します。私たちはこれを痛い経験から学びました。

コスト最適化戦術

実際のボリュームを実行すると、検証ごとのコストは実際の項目になります。ここでは、私たちに役立った戦術を紹介します。

成功した検証をキャッシュする。 ユーザーが30日前に電話番号を検証し、ちょうどログインし直す場合、新しいOTPは必要ありません。長期間有効な認証トークンを使用し、疑わしいアクティビティでのみ再検証します。

高コスト市場では音声フォールバックを使用する。 音声認証は、一部の地域（特にアフリカと中東の一部）ではSMSよりも安価になる場合があります。国ごとにチャネルの優先順位を設定します。

マルチプロバイダーフェイルオーバーを実行する。 プライマリとセカンダリのプロバイダー。プライマリがエラーを返したか、30秒以内に配信されなかった場合、セカンダリで再試行します。コストのオーバーヘッドは小さく、成功率の向上は本物です。テスト市場全体で4〜6％の向上を測定しました。

予想よりも早くボリューム価格交渉を行う。 ほとんどのプロバイダーは、月あたり約10,000回の検証からボリューム割引を提供しています。割引はめったに広告されません。それを求めてください。

サービスを提供しないプレミアムレート国をブロックする。 サインアップフォームで国別許可リストを設定します。米国のみの製品の場合、200以上の国をブロックすることは、無料の不正削減になります。SMSポンピング攻撃はこの抜け穴を利用します。

知っておくべきTwilio Verifyの代替手段

上記の大手5社に焦点を当てたのは、最もよく尋ねられるものだったからです。しかし、SMS認証市場には、人々が思っているよりも多くの選択肢があり、ユースケースによってはそれらのいくつかを再検討する価値があります。

開発者フレンドリーな無料ティアについては、Termii（アフリカ市場に最適）またはTelnyx（キャリアグレードのルーティングを備えた米国中心）を試してください。純粋なAPIのシンプルさについては、Authy（現在はTwilioの一部）は依然として最もクリーンな2FA専用オプションです。セルフホストの場合は、Apache APISIXには検証プラグインがあり、ほとんどの主要なSMSゲートウェイと連携します。

消費者向けの仮想番号については、VerifySMSは私たちが構築したものです。私たちはAPIではなく、自分の実際の番号を公開せずにコードを受信するための電話番号を必要とする人々のためのiOSアプリです。認証フローを構築していて、ユーザーが個人番号を提供することに不満を持っている場合は、私たちのリンクを送信してください。

独自のSMS認証を構築すべきか？

この質問は、四半期に一度、シニアエンジニアから受けます。答えはほぼ常に「いいえ」ですが、正直なバージョンは次のとおりです。

独自のものを構築すべき場合：専用のインフラストラクチャチームがあり、月に500万件以上の認証を実行しており、少なくとも3つのターゲット市場で直接キャリアとの関係があり、事業を展開するすべての管轄区域でコンプライアンスを処理するための法的リソースがある場合。それ以外の場合、計算は成り立ちません。

独自のものを開発する隠れたコストは、コンプライアンスの維持、不正検出の調整、および24時間年中無休のキャリアエスカレーションです。それは最低3人のエンジニアが必要です。エンジニアあたり20万ドルの総コストで、それは単一のSMSを送信する前に純粋なオーバーヘッドで年間60万ドルです。Twilioに対する損益分岐点は、月額API支出約5万ドルのあたりにあります。

よくある質問

SMS認証APIとSMSゲートウェイの違いは何ですか？

SMSゲートウェイは、電話番号に一般的なSMSメッセージを送信します。認証APIは、SMSゲートウェイの上にOTP生成、検証、再試行ロジック、および不正検出を処理する、より高レベルのサービスです。検証にゲートウェイを使用できますが、OTPレイヤーは自分で構築する必要があります。

ユーザーフローを壊さずにSMS認証プロバイダーを切り替えることはできますか？

はい、ただし移行期間を計画してください。最もクリーンなアプローチは、プロバイダーを独自の内部APIの背後に抽象化することです。これにより、ユーザー向けのコードは、基盤となるプロバイダーではなく、独自の認証サービスのみを認識します。私たちは、まさにこれを行うことで、ユーザーに見えるダウンタイムなしでTwilioとVonageの間で本番トラフィックを移行しました。

サインアップフォームでのSMSポンピング攻撃をどのように防ぐことができますか？

3つのこと：サービスを提供しない国からのサインアップをブロックする、IPごとおよび電話番号ごとにレート制限を設定する、および新規ユーザーの電話番号入力フィールドにCAPTCHAを実装する。この組み合わせは、ほとんどのポンピング攻撃を95％以上削減します。すでに攻撃を受けている場合は、すぐにプロバイダーの不正チームにエスカレートしてください。彼らは数時間以内に宛先キャリアをブラックリストに登録できます。

ユーザーが認証アプリを持っている場合でもSMS APIは必要ですか？

ほとんどの製品では、はい。SMSは依然として新規ユーザーにとって最も摩擦の少ない2番目の要素であり、多くのユーザーは認証アプリをインストールしていません。機能するパターンは次のとおりです。摩擦を減らすためにサインアップ時にSMS認証を提供し、その後、ユーザーに最初の週内に認証アプリまたはパスキーにアップグレードするように促します。SMSはアカウントリカバリのフォールバックになります。

有効期限ウィンドウを過ぎて検証コードが到着した場合はどうなりますか？

APIは検証チェックで遅延したコードを拒否します。ユーザーは新しいコードを要求する必要があります。有効期限を5分に設定していますが、これはほとんどのユーザーが電話を見つけるのに十分な長さであり、リプレイ攻撃を制限するには十分に短い時間です。長すぎる（15分以上）と、実際のセキュリティリスクが生じます。短すぎる（90秒未満）と、サポートチケットが急増します。

お金をかけずにCIパイプラインでSMS認証をテストするにはどうすればよいですか？

すべての主要なAPIにはサンドボックスまたはテストモードがあります。Twilioには常に成功を返すマジックテスト電話番号があります。Vonageには検証呼び出しにテストモードフラグがあります。Birdにはサンドボックスワークスペースがあります。CIではこれらを使用してください。自動テストで本番番号に対して実際の認証を実行しないでください。

結論

最も簡単な方法を求め、トラフィックが米国中心の場合はTwilio Verifyを選択してください。均一な国際料金とサーバーサイドOTPストレージを希望する場合はVonageを選択してください。EU中心でGDPRのデフォルトを気にする場合はBirdを選択してください。価格に敏感で、トラフィックが主に米国またはEUの場合はPlivoを選択してください。エンタープライズボリュームがあり、交渉する忍耐力がある場合はSinchを選択してください。

コンシューマー認証を構築していて、ユーザーが個人電話番号を提供せずにアカウントを検証する方法を常に尋ねている場合、それはVerifySMSが満たすギャップです。私たちは上記のAPIと競合しません。私たちは方程式の反対側に座り、ユーザーにコードを受信するためのクリーンな電話番号を提供します。

どちらのルートを選択するにしても、最初に行うべきことは、実際のトラフィックミックスに対して30日間の測定ウィンドウを実行することです。見出し価格は比較が最も簡単な数字であり、総コストの予測としては最悪です。あなたにとって適切なプロバイダーは、最低のステッカー価格ではなく、実際の市場で最も高い成功率を持つプロバイダーです。

一度構築し、毎月測定し、12ヶ月ごとに選択を見直してください。SMS市場は、ほとんどの人が思っているよりも速く変化します。

消費者向けの仮想番号が必要ですか？

iOSでVerifySMSを試す →

即時アクティベーション · 150+カ国 · KYC不要 · 自動返金

日本語のさらなる記事

日本語のすべてのブログ記事 →

>関連記事