電話端末を用いず PC 上で完結させる Twilio 着信挙動の検証手法：SIP クライアントを用いた自己ループ構成

はじめに

Twilio の Programmable Voice は、電話番号の取得、通話制御、音声合成など多様な機能を備え、柔軟な音声アプリケーションの構築を可能にするサービスです。開発中に着信時の Webhook 処理や TwiML の応答動作を確認するには、Twilio 上で取得した電話番号に対して実際に通話を発生させる必要があります。

しかしながら、日本国内から Twilio の米国電話番号（仮に番号 A とする）に発信しようとすると、多くの場合、通信キャリアの制限によって発信そのものが行えず、通話検証が困難となります。このような制約下で着信側の挙動をテストしたい場合、外部からの物理的な発信経路ではなく、Twilio の内部あるいは準内部の経路を用いた自己ループ型の構成が有効な代替手段となります。

本稿では、Twilio Programmable Voice における SIP インターフェース を活用し、以下のような構成を用いて通話検証を行った事例を紹介します。

対象読者

• Twilio Programmable Voice を用いた音声アプリケーションの開発に携わる方
• 通話着信時の Webhook 処理や TwiML 応答の検証を手元で行いたい開発者
• 日本国内環境から Twilio 米国番号への直接発信ができずに困っている技術者
• SIP クライアントや Twilio の SIP 機能を活用した検証方法に関心のある方

参考

• Programmable Voice SIP | Twilio Docs
• TwiML Voice: <Dial> | Twilio Docs
• Functions | Twilio Docs

検証要件

本検証の目的は、Twilio 上で取得した米国電話番号に対して実際の通話を発生させ、着信時の Webhook 処理および通話ログの生成を確認することです。TwiML の <Say> や <Play>、さらには <Gather> などを用いた着信応答の制御が、想定どおりに動作するかを手元で検証する必要があります。

必要な検証要素

• Twilio 番号 A（例：+1 123 456 7890）に対する通話着信が正常に記録されること
• 着信時に設定した Webhook が確実に呼び出され、応答が返ること
• TwiML に基づいた応答内容（例：別番号への転送）が期待どおり実行されること

構成と実装の詳細

本章では、Twilio Programmable Voice の SIP インターフェースを用いて構成した検証環境について、具体的な手順とポイントを段階的に解説します。読者が同様の環境を再現できるよう、設定手順・コード・確認結果を可能な限り明示します。

通話フローの概要

1. SIP クライアント（Linphone） は、Twilio Console 上で作成した SIP URI に対して通話を発信
2. Twilio 側で着信を受けた際、SIP ドメインに設定された Function エンドポイント に HTTP リクエストを送信
3. Function は、TwiML 応答として <Dial> を返却し、Twilio 番号 B （例: +19999999999） から Twilio 番号 A（例： +11234567890） への発信を指示
4. 結果として、番号 A に着信が発生し、Webhook の検証や通話ログの確認が可能となる

構成図

[SIP クライアント (例：Linphone)]
         │
         ▼
[Twilio SIP URI (Domain)]
         │
         ▼
[Twilio Function エンドポイント]
         │（TwiML: Dial from B to A）
         ▼
[番号 B（Caller ID）] ──▶ [番号 A（着信対象）]

この構成により、Twilio 番号 A に発信が到達した状態を仮想的に作り出し、実環境に近い形で Webhook の挙動や通話ログを確認できます。

使用したリソース

Twilio 電話番号

• 発信先番号 A（例： +11234567890）：Webhook や通話ログの確認を目的に設定
• 発信元番号 B（例： +19999999999）：Function の callerId に指定

SIP クライアント

• Linphone を使用

Twilio Function の実装

• Twilio Console にて Functions and Assets > Services よりサービスを作成

• エンドポイントを作成し、下記のように実装

  exports.handler = function (context, event, callback) {
    const response = new Twilio.Response();
    response.appendHeader('Content-Type', 'text/xml');
  
    response.setBody(
      <?xml version="1.0" encoding="UTF-8"?>
      <Response>
        <Dial callerId="+19999999999">
          <Number>+11234567890</Number>
        </Dial>
      </Response>
    .trim());
  
    callback(null, response);
  };
  

• デプロイし、エンドポイント URL を控えておく
  

Voice SIP Domain の設定

• Twilio Console にて Voide > Manage > SIP domains より、SIP Domain を作成
  
• Call Control Configuration > A CALL COMES IN の欄に Twilio Function のエンドポイントを指定
  
• SIP URI を控えておく

SIP クライアントの設定（Linphone の例）

• ホーム > アシスタント > SIP アカウントを使用する を選択
• Credential に設定したユーザー名とパスワードを入力
• SIP ドメインとして控えておいた SIP URI を入力
  
• 連絡先として ユーザー名@SIP URI を追加し発信
  

通話ログと着信検証結果

実際に構成どおりの通話を発生させたところ、Twilio Console Monitor > Logs > Calls 上で以下の点を確認することができました。

• 番号 A に対する着信ログが記録されていること
• Function で返却された TwiML に基づいて、番号 B から番号 A への転送が実行されていること
• A の Webhook に設定していたアプリケーション側のエンドポイントが正しく呼び出され、意図した応答が返されていること

これらの確認により、日本国内環境から Twilio 番号 A の着信挙動を安全かつ確実に検証することが可能となりました。

まとめ

日本国内から Twilio の米国番号に直接発信できないという課題に対し、本記事では Twilio Programmable Voice の SIP 機能と Function を組み合わせることで、Twilio 環境内に完結する着信検証フローを構築する方法を紹介しました。この方法には以下のような利点があります。

• 海外発信制限のあるネットワーク環境でも Twilio 番号の着信検証が可能
• SIP クライアントのみで検証が完結し、電話端末や協力者を必要としない

Twilio Voice アプリケーションの開発中に通話検証でつまずくケースは少なくありません。本記事の内容が、同様の課題に直面している開発者の一助となれば幸いです。