https://a.storyblok.com/f/270183/1368x665/95fb939938/26sep-sanitize_and_validate_phone_numbers-blog_r2.jpg

Eコマースにおける電話番号のクリーニングと妥当性チェック

最終更新日 September 24, 2026

所要時間:1 分

はじめに

電話番号の品質と有効性は、Eコマースにおいて目立たないものの、根深い問題となっています。決済時に収集される電話番号は、形式が不適切だったり、書式が統一されていなかったり、あるいはSMSを受信できない回線に属していたりすることが多く、通常は配信通知が戻ってくるまでそのことに気づかないものです。 SMSを受信できない回線に属していることが多く、通常は配送通知がバウンスして初めてその事実が判明します。

この記事では、フォーマット情報を基に電話番号データをクリーンアップする方法(すべての番号を E.164形式に正規化))に変換し、その後 current_carrier insight(その番号が通常SMSを受信できる携帯電話番号であることを確認)を使用して検証する手順について説明します。 Vonage Identity Insights API は、1回のAPI呼び出しで、正規化された電話番号と、その番号がSMSを受信可能であることの確認の両方を返します。Identity Insights APIのフォーマット機能と最新の通信事業者情報を組み合わせて使用することで、電話番号がデータベースに格納される前にすべての番号をE.164形式に正規化し、配信用の通信に利用する前にそれが携帯電話であることを確認することができます。

衛生管理およびバリデーションの不備

バックエンドでよく見られるシナリオとして、顧客がチェックアウトフォームに入力する際、自然な形式で電話番号を入力し、確認して注文を確定する場合があります。HTML5の「telephone」タイプの入力フィールドは、その形式を受け入れます。サーバーサイドの正規表現により、10桁であることが確認されます。注文はデータベースに書き込まれ、確認メールが送信され、配送通知のSMSが送信されます。

すると、何も起こらず、エラーも記録されず、再試行もトリガーされず、アラートも発火しません。数日後、顧客から「注文はどこにあるのか」と問い合わせるサポートチケットが寄せられます。この「WISMO(Where Is My Order:注文はどこ?)」の問い合わせは、チームに時間とコストを費やすことになり、しかも完全に回避できたはずのものでした。この障害には、2つの隠れた原因があります:

  • 形式の不一致:電話番号がE.164形式(+14155551234)ではなく、国内形式(4155551234)で保存されていました。

  • 検証エラー:形式が正しくても、その番号は固定電話のものか、あるいはかつては携帯電話だったものの、先月固定電話の通信事業者に番号ポータビリティされた番号です。 正規表現は10桁の数字を検出し、有効と判断します。一方、静的なルックアップテーブルは、元の通信事業者による割り当て情報を参照して「携帯電話」と判定します。その結果、SMSの配信はキューに滞留し、最終的にバウンス(配信失敗)となり、顧客の携帯電話には届きません。

電話番号の検証

電話番号の検証とは、一連の数字が、SMSや音声通話が届く実際の有効な電話番号であることを確認することを指します。 電話番号の有効性について。

正規表現は、桁数の不一致、数字以外の文字、市外局番の欠落を検出します。一方、正規表現では、携帯電話と固定電話の区別や、仮想番号・VoIP番号の検出はできません。

キャリア検索およびIDインサイトAPIの返却結果

キャリア検索とは、リアルタイムのモバイルネットワークルーティンググラフに対して、「この番号は現在どの通信事業者が所有しており、どのような回線なのか」を問い合わせるクエリのことです。 Identity Insights APIリファレンス を参照して、Identity Insights APIの呼び出しによって返される主要なフィールドについて確認できます。 正常に処理されたレスポンスは、以下のようになります:

{

  "request_id": "aaaaaaaa-bbbb-cccc-dddd-0123456789ab",

  "insights": {

    "format": {

      "country_code_iso2": "GB",

      "country_name": "United Kingdom",

      "number_international": "+447700900000",

      "number_national": "07700 900000",

      "is_format_valid": true,

      "status": { "code": "OK", "message": "Success" }

    },

    "current_carrier": {

      "name": "EE",

      "network_type": "MOBILE",

      "country_code": "GB",

      "network_code": "23430",

      "status": { "code": "OK", "message": "Success" }

    }

  }

}

注:SIMスワップや位置情報確認といったネットワークを利用した分析とは異なり、 format また、 current_carrier インサイトは、ネットワークレジストリの承認を必要としません。これらは、通信事業者による追加のオンボーディング手続きなしに、世界中で利用可能です。

Identity Insights API の利用を開始する

これを実際に確認する最も手っ取り早い方法は、 「Identity Insights 入門」 チュートリアルです。任意の電話番号を入力し、 format 「and」を選択し current_carrierを選択して、リアルタイムで応答を確認してください。実際の電話番号を使わずに試してみたい場合や、リアルタイムで応答を確認したい場合は、あらかじめ定義されたNumbersが用意されたデモモードも利用できます。実際の電話番号を使わずに試してみたい場合は、あらかじめ定義されたNumbersが用意されたデモモードも利用できます。

Screenshot of an Identity Insights app interface showing request payload, response payload, and configuration options for fraud detection.Getting Started with Identity Insights

Node.js プロジェクトで Identity Insights を設定する

今日学んだ理論を実践に移し、電話番号をE.164形式に正規化し、その番号が携帯電話番号であることを確認した上で、SMS配信のキューに入れ、この検証ステップをエクスプレスチェックアウトのフローに組み込むことができます。当社では、 Node.js 用の Vonage Identity Insights SDKをご用意しています。詳細は Vonage Identity Insights APIのドキュメント および Node.js用Identity Insights SDK を参照してください。

よくある質問

Q1. Identity Insights API での認証はどのように行えばよいですか?

Identity Insights API は、Vonage アプリケーションを介した JWT 認証を使用します。 Vonageダッシュボードでアプリケーションを作成し、秘密鍵をダウンロードして、 applicationId および private.key ファイルのパスを指定してSDKを初期化します。これは、以前のVonage APIで使用されていたAPIキー/シークレット方式とは異なります。

Q2. Identity Insights API が、私が現在使用している電話番号検証ライブラリとは異なる通信事業者を返すのはなぜですか?

Number Insight API は、静的な番号範囲割り当てテーブルではなく、リアルタイムのオペレータールーティングデータを照会します。静的ライブラリが最後に更新されてから、顧客が固定電話事業者から携帯電話事業者に番号を移行した場合、Number Insight API は現在の通信事業者を返すのに対し、静的ライブラリは元の通信事業者を返します。番号移行が行われた場合、 current_carrier が常に正しい回答となります。

Q3. チェックアウト時に、Number Insight API を使用して国際電話番号の有効性を確認することはできますか?

はい。Number Insight API は世界中の電話番号に対応しています。最適な結果を得るには、電話番号を E.164 形式( + プレフィックスおよび国コードを含む)で電話番号を指定すると、最適な結果が得られます。レスポンス内の format.number_international レスポンス内のこのフィールドには、顧客がチェックアウト時に番号をどのように入力したかに関わらず、正規化されたE.164形式の番号が表示されます。

Q4. チェックアウト時にIdentity Insights APIを呼び出すと、チェックアウトフォームの送信が遅くなりますか?

一般的な呼び出しは200~500ミリ秒で完了します。顧客が「送信」をクリックした後、データベースへの書き込みを行う前に、サーバー側でこの処理を実行してください。同じセッション内で顧客が同じ電話番号を再度参照した場合に2回呼び出しが行われないよう、結果をセッションにキャッシュしてください。 サービスが一時的に利用できない場合でも、チェックアウトを完了できるように、適切なタイムアウト設定とフォールバック機能を追加してください。

結論

電話番号が適切にクリーンアップおよび検証されていない場合、Eコマースチームにはさまざまな問題が生じる可能性があります。チェックアウト時に登録された電話番号の形式が不適切であったり、固定電話が携帯電話として偽装されていたりすると、「注文はどこ?」(WISMO)に関するサポート問い合わせが急増し、チャージバックも増加する恐れがあります。  

Vonage API を使用する際は、チェックアウトパイプラインで電話番号を E.164 形式に正規化し、現在の通信事業者を使用して通信事業者を検証してから、 Vonage Messages API に送信してSMSを配信する前に、キャリア情報を最新の状態に基づいて検証してください。 高リスクの注文に対してOTPベースの認証に切り替える必要がある場合は、 Vonage Verify API を、同じチェックアウトパイプラインに追加するのが自然な選択肢となります。

ご質問がある場合、またはあなたが作っているものを共有したい場合は、こちらをクリックしてください。

最新の開発者向けニュース、ヒント、イベント情報をお届けします。

シェア:

https://a.storyblok.com/f/270183/400x400/3f6b0c045f/amanda-cavallaro.png
Amanda Cavallaroデベロッパー・アドボケイト