電話API（Voice API）とは｜Twilio・Vonage・NTT Comなど主要サービスの機能・料金・実装イメージを解説

自社サービスから電話を発信したい、Webで着信を受けたい、IVRや二要素認証を音声で作りたい——こうした要件を抱えて「電話 API」を調べ始める開発者・プロダクトマネージャー・DX企画者が増えています。

名前を聞くのはTwilioばかりで、他にどんな選択肢があり、日本の050や0120番号が取れるのか、料金はいくらか、コードはどう書くのかを一目でつかみたいという声も少なくありません。

この記事では、Twilio・Vonage・NTT CPaaS・Amazon Connect・U-cube CPaaS・Xoxzo・CPaaS NOW・Azure Communication Servicesの8サービスを対象に、機能・料金・日本の電話番号対応・実装の書き方までを横断して整理します。

まず選択肢の全体像を掴み、次に自社のユースケースへ絞り込む材料としてご活用ください。

電話API（Voice API）で選べる主要サービス

電話API（Voice API）とは、電話網（PSTN）を介した発信・着信・自動音声応答・通話録音などの機能を、Web APIやSDKを通じて自社アプリケーションから制御できるようにしたクラウドサービスです。CPaaS（Communications Platform as a Service）というカテゴリの中核機能で、電話回線やPBXを自前で保有せず、必要な機能をAPIで呼び出す形で利用します。

日本国内から利用しやすい主要8サービスを、提供元と位置づけとともに列挙します。海外発のCPaaSベンダー、国内キャリア系、パブリッククラウド発のPSTN対応サービス、国産の音声通信ベンダーまで、選択肢は思ったよりも多岐にわたります。

• Twilio（Twilio Inc.／日本はTwilio Japan合同会社・ソフトバンク経由の販売あり）：グローバル大手のCPaaSベンダー。Voice API・TwiML・Studio・Media Streams・ConversationRelayなど、Voice領域の機能ラインナップが広い。
• NTT CPaaS（NTTドコモビジネスX株式会社）：SMS・音声・メールをひとつのAPIプラットフォームで束ねる国内キャリア発のCPaaS。ドキュメントは日本語で、国内キャリア回線と請求書払いに対応。
• Vonage Communications API（米Vonage Holdings／Ericsson子会社。日本はKDDIウェブコミュニケーションズが「Vonage for KWC」として代理販売）：TTS・WebRTCベースのIn-App Voiceに強い海外CPaaS。日本での提供は円建て・秒課金・専任サポート付き。
• Amazon Connect（Amazon Web Services）：クラウド型のコンタクトセンター基盤で、フローデザイナーとAmazon Lex・AWS Lambdaを組み合わせて音声IVRやコールフローを組み立てられる。従量課金で東京リージョン提供。
• U-cube CPaaS（株式会社ネクストジェン）：SIP／VoIP・SBC（Session Border Controller）を自社開発する音声通信ベンダー発の国産CPaaS。音声通話・IVR・通話録音・会議通話・国内4キャリア相互接続に強い。
• Xoxzo（株式会社Xoxzo）：発信・着信・電話会議・DIN（Direct Inward Number＝050／0120／0800）取得までをシンプルなHTTP+Webhookで提供する国内小規模ベンダー。クレジット制の分課金で使いやすい。
• CPaaS NOW（株式会社ネクスウェイ／TISインテックグループ）：他7社と評価軸がやや異なり、Voice API単独ではなくSMS＋音声を束ねた認証コード配信の切り口で使う国内契約サービス。国内キャリア直収・請求書払い対応。
• Azure Communication Services（Microsoft／日本は日本マイクロソフト株式会社）：Microsoft Teamsと同じ通信基盤を開発者に開放したパブリッククラウド型です。音声・ビデオ・チャット・SMSを完全従量課金で使えます。日本のNational番号とフリーダイヤルの発着信に対応し、Azure AI連携でIVRや音声認識を組み込めます。

この後の節で、これらのサービスができること・機能と料金の横断比較・実装イメージ・音声AIボイスボットの現況・選び方の判断軸を順に整理していきます。

電話APIでできること×ユースケース対応

ここからは、電話APIでできることの引き出しを整理し、自社の業務ユースケースがどの機能に対応するかを一望できるように並べます。「うちの案件はどの機能を組み合わせれば作れるのか」を判断する土台にしてください。

電話APIの主な機能ブロック

電話APIは、以下のような機能ブロックの組み合わせで構成されます。どのブロックを持つかはサービスごとに異なるため、必要な機能から候補を絞り込むのが効率的です。

• 発信（Outbound Call）：APIから電話番号を指定して発信し、応答した相手に音声を届けたり相手のキー入力を受け取ったりします。自動架電の起点になる基本機能です。
• 着信（Inbound Call）：取得した電話番号への着信をWebhookで自社サーバーに通知し、応答内容や転送先をアプリケーション側で決めます。IVRやサポート一次受けの起点です。
• IVR（自動音声応答）：着信に対して自動音声で選択肢を案内し、DTMF（キー入力）や音声認識で分岐して転送や情報提供を行います。TwilioのTwiMLやVonageのNCCO、Azure Call Automation、Amazon Connectのフローデザイナーで組み立てます。
• 通話録音（Recording）：通話を録音し、あとから再生・文字起こし・監査に使います。保管場所やアクセス制御が事業者に委ねられるため、保管国や暗号化の要件がある業界では選定時の確認が必要です。
• TTS（音声合成）：任意のテキストを音声で読み上げます。多くのサービスが日本語を含む多言語のTTSに対応しており、動的に生成した案内文をそのまま発話できます。
• STT（音声認識）：通話音声を文字起こしします。応答の言葉を検知して分岐する会話型IVRや、通話ログの検索・要約に使われます。
• 会議通話（Conference）：3者以上の通話を同時に接続します。カスタマーサポートのエスカレーションや、営業と技術担当の同席対応などに使えます。
• WebRTC In-App Voice：ブラウザやモバイルアプリから、電話番号を介さずに直接ネットワーク越しに音声通話します。アプリ内サポートやリモートワーク向けの内線用途で採用されます。
• SMS連携／マルチチャネル配信：電話がつながらないときにSMSへフォールバックする、あるいは二要素認証コードを音声とSMSで並行配信するといった連携がAPI内で完結します。
• 音声AI連携：TwilioのMedia StreamsやConversationRelay、Azure ACSの音声ストリーミングを介して、OpenAI Realtime APIなどの大規模言語モデルに通話音声を橋渡しし、AIボイスボットを実装します。詳細は後述します。

業務ユースケース×主に使う機能ブロック

電話APIで解ける代表的な業務ユースケースと、そこで主に使う機能ブロックの対応を整理します。自分の案件がどの列に近いかを見て、必要な機能の当たりを付けてください。

※上記は代表的な組み合わせ例です。実際の設計は要件・トラフィック・法規制などにより変わります。

ユースケースの多くは、発信または着信を起点に、TTSと録音、そしてSMS連携を組み合わせて形になります。音声AIボイスボットだけは、後述するとおり通話音声をリアルタイムに外部モデルへ橋渡しする追加設計が必要で、選定時にMedia Streamsや音声ストリーミング対応の有無を確認する必要があります。

上記ユースケースのうちSMSを一次経路とする通知・督促・OTP配信を主軸にする場合はSMS送信サービス、着信認証や発信IVR認証など電話回線を使った本人確認を用途特化で選定したい場合は電話認証サービスの比較記事もあわせて参照すると、Voice APIとの役割分担が整理しやすくなります。

主要Voice APIサービスの機能・料金・日本の電話番号対応の比較

ここからは、上で挙げた8サービスの機能・料金・日本の電話番号対応を横断比較したうえで、各サービスの個別紹介に入ります。まずはサービス名と機能・料金の見どころを一覧で把握できるよう、主要項目に絞って整理しました。

主要サービスの比較表

各社の公式サイト・公式料金ページ・公式ドキュメントに明記されている情報のみを集約しています。0570（ナビダイヤル）の対応可否や代表単価は各社で開示粒度が異なるため、明記のないセルは「―」とし、詳細は各社最新ページで確認してください。

※料金・機能は2026年8月時点の各社公式情報にもとづきます。USD 建ての単価は 1 ドル = 155 円で概算換算できます。「―」は公式ページに明記なしの意で、機能非提供と同義ではありません（要問い合わせのセルを含みます）。最新条件は各社最新の料金ページ・番号ページで要確認。

CPaaS全体の網羅比較・診断ツールで絞り込みたい方へ

この記事では電話（Voice）を扱うAPIに絞って比較していますが、SMS配信・メール・チャットまでを含むCPaaS（通信機能API）全体の網羅比較や、要件から自社に合うサービスを絞り込む診断ツールは、以下の記事にまとめています。より広い視野で比較検討したい場合はあわせてご覧ください。

主要サービスの個別紹介

ここからは、各サービスの提供元・強み・料金や仕様の見どころを1社ずつ紹介します。

1. Twilio（Twilio Inc.／Twilio Japan合同会社）

Twilioは、電話の発着信・SMS・RCS・メール・ビデオといったコミュニケーション機能を、Web APIとノーコードツール（Twilio Studio）で組み込めるグローバル大手のCPaaSです。

Voice領域では、Programmable Voice・TwiML・Media Streams・ConversationRelayまで揃い、AI音声エージェントの実装レイヤーまで一気通貫でカバーしています。

日本での提供は、Twilio Japan合同会社による直接契約に加えて、2023年10月からソフトバンク経由の販売も始まっています。日本語による24時間365日のサポート窓口もソフトバンク経由で提供され、稟議で「国内サポート・請求書払い」を求められるケースでも選択肢に入りやすくなりました。

日本の電話番号は、Local 0ABJ（03などの局番付き）が月額20 USD、National（050など全国番号）が月額4.75 USD、Toll-free（0120／0800）が月額25 USDと公式料金ページに明記されています。

Voice通話は宛先国別の従量課金で、日本国内の固定・全国番号宛が0.0746 USD/分、携帯宛が0.1850 USD/分、0570（ナビダイヤル）宛は0.1200 USD/分と公式に単価が示されています。無料トライアル枠と豊富な多言語SDK（PHP／JavaScript／Python／Ruby／Java／C#）が用意されており、まず動かして肌感を掴みたい開発者に向く構成です。

出典・参考資料（3件）

• 出典：Voice Pricing for Japan｜Twilio（https://www.twilio.com/en-us/voice/pricing/jp）
• 出典：TwiML for Programmable Voice｜Twilio Docs（https://www.twilio.com/docs/voice/twiml）
• 参考資料：Twilioの取り扱いを開始｜ソフトバンク株式会社 プレスリリース（https://www.softbank.jp/corp/news/press/sbkk/2023/20231003_02/）

2. NTT CPaaS（NTTドコモビジネスX株式会社）

NTT CPaaSは、SMS・音声（Voice）・メールなど複数のコミュニケーションチャネルを、SDK／APIで自社システムやWebに統合できる国内キャリア発のCPaaSです。2025年1月にNTTコム オンライン（現・NTTドコモビジネスX）が提供を開始しました。

グローバルCPaaSベンダーのInfobipと共同開発しており、国内向けの通信基盤とグローバルの配信網を組み合わせています。

Voice領域の特徴は、SMS認証・音声（IVR／発信）認証・着信番号認証・メール認証といった複数の認証方式を1つのAPIプラットフォームで提供している点です。

二要素認証機能では、ワンタイムパスワード（OTP）の生成、SMS／Voice／メールいずれかのチャネルでの送信、入力値の照合までをAPIで提供します。この認証API機能自体は追加料金なしで無料提供されており、通信チャネルの送信料のみ従量課金となります。

通信チャネルの送信料は従量課金です。

公式ドキュメント（docs.nttcpaas.com）は「APIリファレンス」と「スタートアップガイド」の2セクション制で日本語提供されており、Voice・SMS・メールそれぞれについて概要・クイックスタート・オンボーディング・開発・本番運用・監視・チェックリスト・FAQのページが体系的に整備されています。

国内キャリアの通信基盤・日本語ドキュメント・請求書払いを重視する国内エンタープライズの選択肢として有力です。

出典・参考資料（2件）

• 参考資料：NTT CPaaS 公式ドキュメント（https://docs.nttcpaas.com/）
• 参考資料：NTT CPaaS 公式サイト（https://www.nttcpaas.com/）

3. Vonage Communications API（Vonage Holdings／日本はKDDIウェブコミュニケーションズ）

米Vonage Holdings（Ericsson子会社）がグローバル展開するCPaaSで、日本ではKDDIウェブコミュニケーションズが「Vonage for KWC」として代理販売しているのがVonage Communications APIです。SMS・メッセージング（WhatsApp等のマルチチャネル）・音声通話・ビデオ・本人確認（Verify）をAPIから自社プロダクトに組み込めます。

円建て請求・専任サポート・国内代理店経路が整うため、日本の商用条件（請求書払い・日本語窓口・NDA日本語版）を要件に置く企業の選択肢に入ります。

Voice APIは、TTS（音声合成）による自動応答、WebRTCベースのIn-App Voice、SIP Trunking、多人数通話、通話録音などに対応し、料金は分単位ではなく秒単位の従量課金という差別化があります。

KWCの公式料金ページでは、050番号の月額165円（税込）、0120／0800番号2,200円、0570番号11,000円、Voice API発信料は固定番号宛5.5円／分、携帯番号宛18.0円／分、着信料は050／0570番号宛0.6円／分と、日本の番号種別ごとに具体的な単価が明記されています。

実装面では、通話フローをJSON配列で宣言するNCCO（Call Control Object）方式を採ります。

公式ドキュメントには「A Call Control Object (NCCO) is represented by a JSON array. You can use it to control the flow of a Voice API call.」と明記されており、TwilioのTwiML（XML）とはスタイルの異なる、REST + Webhook系の代表例です。

ノーコードでフローを組めるAI Studioも提供されており、開発者以外がフロー設計に参加しやすい環境が整っています。

出典・参考資料（3件）

• 出典：Vonage for KWC Communications APIs 料金｜KDDIウェブコミュニケーションズ（https://kwcplus.kddi-web.com/service/vonage/price）
• 出典：Voice API｜Vonage Developer Portal（https://developer.vonage.com/en/voice/voice-api/overview）
• 出典：NCCO Reference｜Vonage Developer Portal（https://developer.vonage.com/en/voice/voice-api/ncco-reference）

4. Amazon Connect（Amazon Web Services）

AWSが提供するクラウド型のコンタクトセンター基盤がAmazon Connectで、フローデザイナー（GUI）とAmazon Lex（会話型IVR）、AWS Lambdaの組み合わせで、IVR・音声AIボット・自動架電を含むコールフローを組み立てられます。

専用のCPaaS製品というより、コンタクトセンター全体の運用基盤としてPSTN発着信・録音・キューイング・エージェント割当・分析までを内包する点が特徴です。

公式料金ページによれば、Voice通話は音声1分あたり0.038 USDに標準の電話通信料金（電話番号保持料と着発信通話料）が加算される構成で、Chatは1メッセージあたり0.010 USD、Emailは0.080 USD、SMSと3Pメッセージングは0.014 USDというマルチチャネル従量課金です。

標準の電話通信料金の目安は、日本のDID（03／050）が $0.10／日・着信 $0.003／分、フリーダイヤル（0120／0800）が $0.48／日・着信 $0.08／分です（USD建て、AWS Pricing Calculator で最新条件を要確認）。

日本の電話番号は東京リージョンで取得でき、DID（03／050）とフリーダイヤル（0120／0800）に対応します。番号保持料と通話料の実額はAWS料金アペンディックスに分散しているため、実際の想定コストはAWS Pricing Calculatorで見積もる運用になります。

実装は「フローデザイナーでコールフローをドラッグ&ドロップで組み、Lambda関数で外部システム連携、Amazon LexでNLU分岐」という設計が典型で、他のAWSサービス（S3・DynamoDB・Bedrockなど）との統合が強みです。「AWSで基幹を組んでいて、音声もその上に載せたい」場合の第一候補になります。

出典・参考資料（1件）

• 出典：Amazon Connect の料金｜AWS（https://aws.amazon.com/jp/connect/pricing/）

5. U-cube CPaaS（株式会社ネクストジェン）

SIP／VoIPとSBC（Session Border Controller）を自社開発してきた音声通信の専業ベンダー、株式会社ネクストジェンが展開する国産CPaaSがU-cube CPaaS（ユーキューブ シーパース）です。その技術基盤の上に、音声通話・IVR・通話録音・会議通話・国内4キャリア相互接続を持ちます。

「国内キャリアと直接つながる音声品質」を要件に置く用途に向く選択肢です。

公式ページで確認できる主要な音声機能は、電話発信（複数番号指定・着信優先）、IVR、通話録音、多人数通話です。メッセージング側は国内4キャリア対応のSMS送受信と、テキスト・ファイル・通話機能付きのチャットの2種類で、RCS／リッチメッセージは製品ラインナップに含まれません。ノーコード・ローコードのAPI提供もうたわれており、既存システムへ音声機能を組み込むリードタイム短縮を狙っています。

料金は「要お問い合わせ」で、通話・SMSなどチャネル別の従量課金体系と推察されるものの、公式に料率の明示はありません。「国産・音声通信ベンダー母体・国内キャリア相互接続」の3点にニーズが強い場合、まず問い合わせて商用条件を確認する運用になります。

出典・参考資料（1件）

• 参考資料：U-cube CPaaS｜株式会社ネクストジェン（https://www.nextgen.co.jp/solution/dx/communication-api/u-cube-cpaas.html）

6. Xoxzo（株式会社Xoxzo）

発信・着信・電話会議・DIN（Direct Inward Number＝着信専用の電話番号）取得までを、シンプルなHTTP + Webhookで提供する国内ベンダーがXoxzoです。日本国内のスタートアップや中小規模の開発チームを主な想定利用者にしており、音声ファイル再生やTTSでの発話もAPIを呼び出すだけで扱えます。

実装はHTTP + Webhook（コールバックURL）方式で、TwilioのTwiMLのような独自マークアップは必要ありません。

料金はクレジット制で、1クレジット＝1円（税別）です。日本国内の通常発信は10クレジット／分から、ローカル発信者番号を使う場合は15クレジット／分から。DINの月額は、フリーダイヤル系（0120／0800）が2,900クレジット、050番号が650クレジットと公式料金ページに明記されています。課金は発信・着信とも1分ごとで、購入したクレジットの使用期限は取得日から90日間です。

0570（ナビダイヤル）の取得可否は公式に明示されていません。

着信は「取得番号に電話が着信すると、指定されたアクションURLにGETリクエストを投げ、そのアクションURLから返るコマンドで着信した電話を処理する」という素直なWebhookモデルです。10万クレジットを超える取引は銀行振込＋請求書、法人向けポストペイ契約（与信審査あり）も相談可能で、少額から始めて必要に応じて商用条件を切り替えられます。

「まずシンプルに国内で発着信を試したい」用途に向く構成です。

出典・参考資料（2件）

• 出典：音声通話用ウェブAPI｜Xoxzo（https://www.xoxzo.com/ja/about/voice-api）
• 出典：Voice料金｜Xoxzo（https://www.xoxzo.com/ja/about/pricing/voice/）

7. CPaaS NOW（株式会社ネクスウェイ）

CPaaS NOWは、株式会社ネクスウェイ（TISインテックグループ）が提供する、SMS・メール・郵送を1つのAPIで統合管理できる国内発のマルチチャネル配信基盤です。

ここまでの6サービスとは軸が異なり、Voice API単独ではなく「SMS＋音声」を認証コード配信の流れで束ねて使う切り口の国内契約サービスとして紹介します。純粋なVoice API機能（IVR・通話録音・多人数通話・WebRTC等）は他6社に譲る位置づけです。

認証コード機能は、コードの生成・送信（SMS／音声）・認証チェックまでの一連の認証プロセスをワンストップで提供します。国内4キャリア直収の配信網、初期費用0円・スタンダードプラン月額0円・SMS 1通6円からという分かりやすい料金体系、日本語ドキュメントと国内サポート、請求書払いへの対応が揃っており、「まず1つの契約で自社の顧客通知経路をまとめたい」場面に向きます。

専用番号プランを付けると、自社保有の電話番号を発信元として表示することもできます。

読者の中に、Voice単独APIというよりも「SMS通知＋SMS未達時の音声フォールバック」や「音声OTPを含む二要素認証」のような、業務プロセス寄りの要件を持つ担当者がいる場合、単発の資料請求からミーティング予約まで動線が短いという点でも検討しやすい選択肢です。

出典・参考資料（1件）

• 参考資料：CPaaS NOW｜株式会社ネクスウェイ（https://smslink.nexway.co.jp/cpaas/lp）

電話APIの実装イメージ（TwiMLとREST+Webhookの2系統）

電話APIの実装スタイルは、大きく分けてTwilioが採る「TwiML方式（独自XMLでフローを宣言）」と、Vonage・NTT CPaaS・Amazon Connect・Azure Communication Servicesが採る「REST + Webhook方式（HTTPで通話を制御し、着信や状態変化はWebhookで受ける）」の2系統に分けられます。

実装イメージをそれぞれ最小フローで見比べて、自社の開発スタイルに合う方式を掴んでください。

TwiML方式（Twilio系・宣言的XMLでフローを記述）

TwiML（Twilio Markup Language）は、Twilioに対して着信通話やSMSに対する処理を指示するXMLベースの命令セットです。Twilio公式ドキュメントには次のように説明されています。

TwiML is a set of instructions you can use to tell Twilio what to do when you receive an incoming call or SMS.

Twilio Docs「TwiML for Programmable Voice」（https://www.twilio.com/docs/voice/twiml）

発信が成功するまでの最小手順は、公式ドキュメントの Call リソースに沿うと次の1リクエストです。取得済みの発信元番号（From）と宛先（To）、読み上げ内容を書いたTwiMLをPOSTすると、通話は受付済み（queued）の状態で受け付けられます。以後は呼出中（ringing）・通話中（in-progress）・終了（completed）と遷移します。

TWIML='<Response><Say language="ja-JP" voice="Polly.Mizuki">お電話ありがとうございます</Say></Response>'

curl -X POST https://api.twilio.com/2010-04-01/Accounts/$TWILIO_ACCOUNT_SID/Calls.json \
  -d 'To=+819012345678' -d 'From=+815012345678' -d "Twiml=$TWIML" \
  -u $TWILIO_ACCOUNT_SID:$TWILIO_AUTH_TOKEN
# 応答（抜粋）: {"sid": "CAxxxx", "status": "queued"}

SDK（Python・Node.jsなど）はこのHTTP呼び出しを各言語の関数に包んだもので、インストール後は上記と同じ3パラメータを渡すだけで発信できます。Twimlの代わりにUrlパラメータを渡すと、応答時の分岐を自社サーバーが動的に返せます。

出典・参考資料（1件）

• 出典：Call Resource｜Twilio Docs（https://www.twilio.com/docs/voice/api/call-resource）

着信があるとTwilioは事前登録されたURLにHTTPリクエストを送り、そのURLが返すXML（TwiMLドキュメント）を上から順に解釈して通話を制御します。

主要な動詞は、テキストを読み上げる<Say>、音声ファイルを再生する<Play>、他の相手を通話に追加する<Dial>、通話を録音する<Record>、キーパッド入力を収集する<Gather>などがあります。最小のTwiMLは次のような1つのXMLドキュメントです。

<?xml version="1.0" encoding="UTF-8"?>
<Response>
  <Say language="ja-JP" voice="Polly.Mizuki">お電話ありがとうございます。ご用件を1つ選んでください</Say>
  <Gather numDigits="1" action="/menu-select">
    <Say language="ja-JP" voice="Polly.Mizuki">新規のお申込みは1、既存のお問い合わせは2を押してください</Say>
  </Gather>
</Response>

この方式の強みは、通話フロー全体を1つのXMLドキュメントで宣言できることです。サーバー側は状態を持たず、Twilioが読み解いて実行するので、単純なIVRであれば数十行のXMLで完結します。逆に、分岐が深くなるとネストが増え、動的な条件分岐はWebhookから返すTwiMLを都度組み立てる必要があります。「まずシンプルなIVR・自動架電をすばやく組みたい」用途との相性が良い設計です。

REST + Webhook方式（Vonage・NTT CPaaS・Azure ACS・Xoxzo系・命令的な組み立て）

REST + Webhook方式は、通話制御をREST APIで呼び出し、着信や通話中の状態変化はWebhook（HTTP POST）で自社サーバーが受ける構成です。フローはアプリケーション側の言語（Python・Node.js・Javaなど）で書くため、既存のアプリケーションロジックに自然に統合できます。

代表例のVonageは、通話フローを「NCCO（Call Control Object）」というJSON配列で宣言します。公式ドキュメントは次のように定義しています。

A Call Control Object (NCCO) is represented by a JSON array. You can use it to control the flow of a Voice API call.

Vonage Developer Portal「NCCO Reference」（https://developer.vonage.com/en/voice/voice-api/ncco-reference）

NCCOの最小例は次のとおりです。talkアクションがテキストを読み上げ、inputでDTMFや音声入力を受け取ります。

[
  {
    "action": "talk",
    "text": "お電話ありがとうございます。ご用件を1つ選んでください",
    "language": "ja-JP"
  },
  {
    "action": "input",
    "type": ["dtmf"],
    "dtmf": {"maxDigits": 1},
    "eventUrl": ["https://example.com/menu-select"]
  }
]

Azure Communication ServicesのCall Automationも同じ系統で、REST APIで応答・転送・再生・認識・録音などのアクションを実行します。

通話中のイベント（IncomingCall／CallConnected／PlayCompleted／RecognizeCompleted／RecordingStateChangedなど）はEvent Grid経由のHTTPS Webhookで受け取ります。

NTT CPaaSも公式ドキュメント（docs.nttcpaas.com）にVoiceのREST APIリファレンスとWebhook仕様が用意されており、Xoxzoは着信時に指定URLへGETリクエストを送るシンプルなWebhookモデルです。

この方式の強みは、アプリケーション側の言語で分岐や状態管理を書けるため、複雑なコールフローや外部システム（CRM・在庫DB・LLM）との連携が素直に書ける点にあります。反面、単純なフローでもサーバー側で状態管理と複数のエンドポイントを実装する必要があるので、初期の学習コストはTwiMLよりやや高くなります。

既存のバックエンドチームがWebアプリケーション開発に慣れているなら、こちらのほうが馴染みやすいでしょう。

音声AIボイスボット（Twilio × OpenAI Realtime API）の現在地と限界

2025〜2026年の電話API周辺で最も動きがある領域が、OpenAI Realtime APIなどの音声対応LLMと組み合わせた「AIボイスボット」の実装です。10分程度で立ち上がるハンズオンが個人ブログでも次々と公開されている一方、業務利用に耐える水準にはまだ具体的な課題も残ります。本節では「いまどこまで作れるか」と「何が残るか」の両側を、電話API選定の観点から整理します。

現在地：Twilio × OpenAI Realtime APIで「1時間で動くボイスボット」の広がり

AIボイスボットの現在地は、Twilioの音声プリミティブとOpenAI Realtime APIの組み合わせが実装の主流になっています。TwilioにはMedia StreamsとConversationRelayという2つの通話音声用の橋渡し機構があります。Media Streamsは、次のように定義される下位プリミティブです。

Receive raw audio streams from live phone calls over WebSockets using Twilio Media Streams for AI/ML transcription and self-service automation.

Twilio Docs「Media Streams」（https://www.twilio.com/docs/voice/media-streams）

単方向のストリーミングは<Start><Stream>、双方向のストリーミングは<Connect><Stream>のTwiML動詞で開始します。音声送信先を任意のWebSocketエンドポイントに指定できる仕様で、AIチャットボットとのリアルタイム対話やconversational IVRに使う想定が公式にも記されています。

もう一方のConversationRelayは、STT（音声認識）・TTS（音声合成）・セッション管理・低遅延通信までをTwilio側で受け持ち、開発者はWebSocketエンドポイントと会話ロジックの実装だけに集中できる高位プリミティブです。

<Connect><ConversationRelay url="wss://..." welcomeGreeting="..." />を書けば、生音声の前処理をTwilioに任せてLLMとの対話部分に集中できます。

OpenAI Realtime API側は、公式ドキュメントでgpt-realtime-2.1（低遅延音声エージェント向け）、gpt-realtime-translate（リアルタイム翻訳セッション）、gpt-live-transcribe（ストリーミング字幕）といったモデルを提供しています。

接続経路はブラウザ・モバイルクライアントから直接音声を送るWebRTC、サーバー側でメディアパイプラインを組む場合のWebSocket、電話音声エージェント向けのSIPの3経路が公式にサポートされます。Twilio経由でRealtime APIに音声を橋渡しする実装は、WebSocket経路（Media Streams／ConversationRelayから中継）が中心です。

出典・参考資料（5件）

• 出典：Media Streams｜Twilio Docs（https://www.twilio.com/docs/voice/media-streams）
• 出典：ConversationRelay｜Twilio Docs（https://www.twilio.com/docs/voice/twiml/connect/conversationrelay）
• 出典：Realtime API guide｜OpenAI Developer Docs（https://developers.openai.com/api/docs/guides/realtime）
• 参考資料：OpenAI Realtime APIでAI電話を作った話｜Love from Azit（https://love-from.azit.co.jp/article/dl44az55nmn）
• 参考資料：【初心者向け】Twilio + Realtime APIで誰でもAIと電話できるボイスボットを作ってみた｜note（https://note.com/izai/n/n102aafcf3772）

残る限界と、Voice API選定への落とし込み

他方で、AIボイスボットを業務利用に投入したチームの実装記録（Twilio + OpenAI Realtime APIの物流領域MVP、Twilio + Realtime APIの1時間ハンズオンなど）からは、いくつか共通の課題も報告されています。

相槌のタイミングと間の取り方、数字や固有名詞の読み違い（例：「三田」を「さんだ」と読み上げるなど）、あらかじめ設計したフロー制御を維持し続ける難しさは、モデル本体だけでは解ききれていません。

実装事例からは「一定の水準までは実現できているが、業務で任せきりにするには相応の作り込みが要る」という2026年時点の現実的な温度感が伝わってきます（下記の参考資料に、Twilio × OpenAI Realtime API で AI 電話 MVP を作った Azit・note IZAI の実装記録があります）。

この現実を電話API選定の観点に落とし込むと、次のような確認項目が浮かびます。Media StreamsやACSの音声ストリーミングのように「双方向の生音声を外部LLMへ渡せるプリミティブ」があるか。TTS品質は日本語で耐えるか（Polly Mizuki・Neural系など、選べる音源がある方が調整余地が広がる）。通話録音は後追い改善に必要なので、保管国と保管期間を業界要件と照合できるか。

想定トラフィック規模でSLAとレイテンシが要件を満たすか。これらは前述の比較表と選び方の判断軸で確認していきます。

「10分ハンズオンで動く」勢いに乗って本番導入まで一気に進めたくなる領域ですが、まずは自社の1ユースケース（例：予約変更受付・営業時間外一次受け）に絞ってMVPを立ち上げ、限界を計測してから拡張していく進め方が、いまのAIボイスボットには向いています。

電話APIサービスを選ぶための6つの判断軸

これまでの整理を踏まえて、実際に自社に合う電話APIを選ぶための判断軸を6つに絞って示します。「機能が多いから」「有名だから」ではなく、自社の業務要件・稟議条件・運用体制と照合しやすい軸で並べます。

1. 必要な日本の電話番号種別を取得できるか

顧客向けの発信・着信では、050番号（全国番号）でよいのか、03などの局番付きLocal 0ABJが要るのか、フリーダイヤル（0120／0800）や0570（ナビダイヤル）が必要かで、選べるサービスが変わります。各社の公式料金ページで、対象の番号種別が明示されているかを確認するのが確実です。

0570の発信対応は明記のあるサービスとないサービスがあり、フリーダイヤル運用が前提の業務では特に確認が必要です。

2. 日本語TTSの品質と選べる音源

TTSは、音源の自然さで顧客体験が大きく変わります。日本語の音源が複数選べるか、ニューラルTTSに対応するか、感情や話速の調整パラメータがあるかを、公式ドキュメントで確認します。試聴サンプルが公開されている場合はそれを聴き、自社の業務トーンに合うかを実際に判断するのが確実です。

3. 商用サポートの言語・時間帯

本番運用が始まると、通話品質のトラブル・料金の解釈・障害時の状況確認などで、サポート窓口を頼る場面が出てきます。日本語サポートの有無、対応時間（24時間365日か営業時間内か）、時差（海外本社サポートの場合は日本時間の何時に反応が返るか）を確認します。

Twilioは2024年1月以降、ソフトバンク経由で24時間365日の日本語サポートが提供されています。Vonageは日本の代理店KDDIウェブコミュニケーションズの専任サポート、NTT CPaaS・U-cube CPaaS・CPaaS NOWは国内直営という違いがあります。

4. 通話録音の保管国・保管期間・アクセス制御

金融・医療・公共分野では、通話録音の保管国・保管期間・暗号化・アクセス権限管理が事業者ごとに求められます。海外リージョンでのみ保管される場合はデータ主権の観点で稟議が難しくなることがあり、東京リージョンでの録音・保管に対応するか、要件に合う保管期間を設定できるかを確認します。監査ログの取得可否も同時にチェックしておくと安心です。

5. SLA・国内キャリアとの直接接続

通話品質・到達率・障害時の復旧SLAは、業務の停止許容度に応じて確認が必要です。国内キャリアと直接接続しているサービス（NTT CPaaS・U-cube CPaaS・CPaaS NOWなど）は、海外経由で日本のキャリア網に接続するサービスと比べて、通話品質・音声の遅延・着信ルーティングで一定の優位が期待できます。

一方、グローバルの多拠点向けにはTwilio・Vonage・Azureのような多国対応サービスが向きます。

6. 商用条件（円建て請求・請求書払い・国内代理店の有無）

稟議・経理・法務の実務では、円建て請求・請求書払い・NDAや利用規約の日本語対応・国内代理店の有無が最終的な選定に効いてきます。Twilioは直接契約に加えてソフトバンク経由の国内取扱があり、Vonageは日本ではKDDIウェブコミュニケーションズが代理販売する体制です。

国内契約の3社（CPaaS NOW・NTT CPaaS・U-cube CPaaS）は円建て・請求書払い・国内代理店の点で稟議を通しやすい構成といえます。開発体制と稟議側の両方を見て、自社に合う商用条件のサービスを選んでください。

まとめ

電話API（Voice API）は、Twilio・NTT CPaaS・Vonage・Amazon Connect・U-cube CPaaS・Xoxzo・CPaaS NOWといった多様な選択肢が並び、それぞれ機能の広さ・料金モデル・日本の番号対応・実装スタイル・商用条件が異なります。

TwiML方式でシンプルにフローを宣言するのか、REST + Webhook方式でアプリケーションに組み込むのかも、開発体制と要件で選び分ける論点です。

音声AIボイスボットは、TwilioのMedia Streams・ConversationRelayとOpenAI Realtime APIの組み合わせで1時間ハンズオンが動く段階まで来ていますが、業務利用には相槌・数字読み・フロー制御の作り込みが必要です。

まず1つのユースケースを起点にMVPを立ち上げ、必要な日本の番号種別・日本語TTS品質・商用サポート・録音要件・SLA・請求条件の6軸で自社に合う2〜3サービスに絞り、無料枠でハンズオンを走らせてから本格導入に進むのが確実です。

よくある質問（FAQ）

Q. 電話API（Voice API）とは何ですか？

A. 電話API（Voice API）とは、電話網（PSTN）を通じた発信・着信・自動音声応答（IVR）・通話録音といった機能を、Web APIやSDKから自社アプリケーションで制御できるようにしたクラウドサービスです。

回線やPBXを自前で保有せず、必要な機能をAPIコールとWebhookで組み立てて使う点が特徴で、CPaaS（Communications Platform as a Service）の中核機能に位置づけられます。

日本国内から利用しやすい代表的なサービスとしては、Twilio・NTT CPaaS・Vonage（日本はKDDIウェブコミュニケーションズ経由）・Amazon Connect・U-cube CPaaS・Xoxzo・CPaaS NOWなどがあります。

Q. 電話APIを業務利用する場合、電気通信事業者の届出は必要ですか？

A. 注文確認の自動架電や二要素認証の音声OTPのように、自社の本来業務の手段として電話APIを使う場合は、原則として電気通信事業者の届出は不要と考えられます。

総務省の「電気通信事業参入マニュアル［追補版］」は、電気通信役務を「自己の需要」として提供する使い方（＝電気通信役務の提供そのものを事業にしていない使い方）は「他人の需要に応ずるため」に該当せず、事業法上の届出対象外である旨を判定フローチャートで示しています。

電気通信事業以外の事業を行う者がその本来業務の遂行に当たって電気通信役務を提供することは含まない。電気通信役務の提供を前提としない本来業務の遂行手段として活用している場合は、電気通信役務を「自己の需要」のために提供するものであり、「他人の需要に応ずるため」に該当しない。

総務省「電気通信事業参入マニュアル［追補版］」（https://www.soumu.go.jp/main_content/000477428.pdf）

一方、電話APIを第三者向けの通信サービスとして再販するようなケースは、事業法第9条（登録）または第16条第1項（届出）の対象になり得ます。同マニュアル自体が「電気通信システム全体をみて、情報の流れに即し、個別具体的に判断することが必要である」と述べているとおり、自社の使い方が該当するかは、参入マニュアル最新版と総務省の相談窓口で確認するのが確実です。

出典・参考資料（1件）

• 出典：電気通信事業参入マニュアル［追補版］（令和5年1月30日改定）｜総務省（https://www.soumu.go.jp/main_content/000477428.pdf）

Q. 電話APIで日本の050番号や0120番号は取得できますか？

A. 主要サービスの多くは日本の050（全国番号）・03などの局番付き（Local 0ABJ）・フリーダイヤル（0120／0800）に対応しており、番号種別ごとの月額と発着信単価が公式料金ページに明記されています。たとえばTwilioはLocal 0ABJが月額20 USD、National（050系）が4.75 USD、Toll-free（0120／0800）が25 USD。

Vonage for KWCは050が月額165円（税込）、0120／0800が2,200円、0570が11,000円。Xoxzoは050が月額650クレジット（1クレジット＝1円税別）、0120／0800が2,900クレジットです。

Azure Communication Servicesは日本のNationalとフリーダイヤルの発着信が一般提供（GA）、Amazon Connectは東京リージョンでDIDとフリーダイヤルが取得できます。

0570（ナビダイヤル）の取り扱いは各社で開示状況が異なり、公式に明記があるのはTwilio（0570宛発信0.1200 USD／分）とVonage for KWC（0570番号月額11,000円）などで、Xoxzo・Amazon Connect・Azure ACSの公式ページには2026年8月時点で明示がありません。必要な番号種別が揃うかは、選定時に各社の最新料金・番号ページで確認してください。

出典・参考資料（4件）

• 出典：Voice Pricing for Japan｜Twilio（https://www.twilio.com/en-us/voice/pricing/jp）
• 出典：Vonage for KWC Communications APIs 料金｜KDDIウェブコミュニケーションズ（https://kwcplus.kddi-web.com/service/vonage/price）
• 出典：Voice料金｜Xoxzo（https://www.xoxzo.com/ja/about/pricing/voice/）
• 出典：日本の電話番号管理｜Microsoft Learn（https://learn.microsoft.com/ja-jp/azure/communication-services/concepts/numbers/phone-number-management-for-japan）

Q. 電話APIは無料で試せますか？

A. 多くの電話APIは無料トライアルや従量課金の小額利用で試せますが、無料の範囲や電話番号取得の可否はサービスごとに違います。Twilioは無料トライアルクレジットと日本語含む多言語SDK（PHP／JavaScript／Python／Ruby／Java／C#）が用意されており、番号1つと少量の発信テストで実装感を確認できます。

Amazon Connect・Azure Communication Services・Vonage・Xoxzo・NTT CPaaSはいずれも従量課金で、AWS／Azure／各社アカウントを開設すれば少額から試験運用に入れます。

ただしAzure Communication Servicesは公式ドキュメントで「電話番号を取得するには、有料のAzureサブスクリプションが必要です。Azure無料クレジットで電話番号を取得することはできません」と明記されており、電話番号の取得だけは有料契約が前提です。

まず自社ユースケースに近い2〜3サービスを選び、番号取得の条件・代表単価・日本語TTS品質を確認したうえで無料枠に登録するのが効率的です。

出典・参考資料（1件）

• 出典：日本の電話番号管理｜Microsoft Learn（https://learn.microsoft.com/ja-jp/azure/communication-services/concepts/numbers/phone-number-management-for-japan）

Q. Twilio・Vonage・NTT CPaaSは、どんな点で選び分けますか？

A. 機能ラインナップの広さと英語圏の情報量を最優先するならTwilio、円建て・秒課金・国内代理店経由の商用条件を重視するならVonage（KDDIウェブコミュニケーションズ経由）、国内キャリア基盤・日本語ドキュメント・請求書払いをそろえたいならNTT CPaaSが有力です。

TwilioはProgrammable Voice・TwiML・Media Streams・ConversationRelayまでVoice領域のプリミティブが幅広く、AI音声エージェント実装まで単一プラットフォームで扱えます。

Vonageは秒単位課金と、日本ではKDDIウェブコミュニケーションズによる「Vonage for KWC」経由の円建て請求・専任サポート・日本語代理販売が特徴です。

NTT CPaaSはNTTドコモビジネスXが提供する国内キャリア発CPaaSで、SMS・音声（IVR／発信）認証・着信番号認証・メール認証を1つのAPIプラットフォームに束ね、日本語の公式ドキュメントと請求書払いに対応します。本文の「電話APIサービスを選ぶための6つの判断軸」を、自社の稟議条件・運用体制・必要な番号種別と照らし合わせて絞り込むと選定が進みます。

電話API（CPaaS）の料金・機能を一括チェック

MCB FinTechカタログでは、電話・SMS・メール・チャットなど複数の通信チャネルをAPIで扱えるCPaaSサービスの最新資料を、無料でまとめてダウンロードできます。機能・料金・国内サポート体制を比較しながら、自社の業務に合う電話APIを検討する際の材料としてお役立てください。

MCB FinTechカタログに掲載しませんか？

MCB FinTechカタログでは、掲載企業様を募集しています。マネックスグループの金融実務ノウハウを活かした独自の評価軸と検索設計により、導入検討者が最適なサービスを効率的に発見できる法人向け比較プラットフォームです。掲載後は管理画面から料金表や導入事例を随時更新でき、常に最新の情報を訴求可能。まずは下記フォームより、お気軽にお問い合わせください。