プラットフォーム

Twilio APIで音声AIを動かす4ルート|設定手順・日本料金・日本語精度

Twilio APIで音声AIを動かす4ルート|設定手順・日本料金・日本語精度

Twilioで通話音声をAIに処理させる方法は4つあり、TwiMLの書き方も単価も、日本語での制約も経路ごとに違います。経路の選び方、最初の1通話をつなぐ設定、日本語の認識精度を左右する属性、録音や留守番電話検知を足したときの料金を、Twilio公式ドキュメントと日本向け料金ページの2026年10月12日時点の値で整理します。

まとめ

電話でテキストのLLMと会話させるなら<Connect><ConversationRelay>(日本 $0.07/分)を使います。音声認識と音声合成はTwilioが担い、自分のサーバーはWebSocketでテキストをやり取りするだけです。音声そのものを自前で処理する、または音声を直接入出力する対話モデルにつなぐなら Media Streams($0.0044/分)、通話中の文字起こしだけなら<Start><Transcription>、終話後の要約や感情分析なら Conversation Intelligence (classic) を選びます。

最初につまずくのは3点です。コンソールで「Predictive and Generative AI/ML Features Addendum」に同意しないと Conversation Relay は使えません。languageの既定はen-USなので、ja-JPを明示しないと日本語が英語として認識されます。既定TTSのElevenLabsは日本語でSSMLが効かないため、読み方や間を制御したいならGoogleかAmazonへ切り替えます。料金は通話料とAI機能の単価が別々に積み上がり、国内番号で着信を受けてAIが応対すると1分あたり$0.08になります。

Twilio APIで音声をAIに渡す4つの経路

経路ごとに「Twilioが何を引き受け、自分が何を書くか」の線引きが違います。単価は日本向けProgrammable Voice料金ページの値で、通話料は別にかかります。

経路 TwiML・API 音声認識・合成 LLM 日本単価
Conversation Relay <Connect><ConversationRelay> Twilio 自前 $0.07/分
Media Streams <Start>・<Connect><Stream> 自前 自前 $0.0044/分
リアルタイム文字起こし <Start><Transcription> Twilio(認識のみ) なし $0.027/分
Conversation Intelligence (classic) Intelligence API v2 Twilio(認識のみ) Twilio(分析は別料金) 文字起こし $0.024/分

料金ページには別項目で「トランスクリプション(文字起こし)$0.0500/分」もありますが、これは録音に対する従来の文字起こしで、上の2つとは別物です。

4経路の選び方

判断は「AIに何をさせたいか」でほぼ決まります。音声認識・音声合成をTwilioに任せ、テキストでLLMと接続するなら Conversation Relay を推奨します。会話が不要でテキストだけ欲しいなら文字起こし系で、通話中に要るなら<Start><Transcription>、終話後の要約だけなら録音の一括文字起こしが安く実装も単純です。

Media Streams は、外部の分析基盤への転送や独自の話者判定に加え、音声を直接入出力する対話モデルにつなぐ場合にも候補になります。ただし、テキストでLLMにつなぐ対話エージェントを単価の安さだけで Media Streams に載せるのは勧めません。差額は月1万分でも約$656で、その代わりに割り込み検知・読み上げの中断・相づちの除去を全部自作することになります。

「Twilio Conversational AI」が指す製品群

検索で使われる「Twilio Conversational AI」は単独の製品名ではありません。TwilioのConversational AI製品ページは、Conversation Relay(音声AI)、Conversation Intelligence(会話の分析)、Conversation Orchestrator(音声・SMS・WhatsAppをまたいで会話を束ねる)、Conversation Memory(顧客ごとの文脈の保持)の4つと、自社のAIをつなぐ Agent Connect をまとめてこの名前で呼んでいます。電話のAI応対を作る部品は Conversation Relay です。Orchestrator は新しいTwilio Consoleでしか使えず、HIPAA・PCIの対象業務では有効にしてはいけないとOrchestratorのドキュメントに書かれています。

Conversation RelayでAI電話応対を動かす手順

最初の1通話に必要なのは、コンソールの設定、TwiMLを返すHTTPエンドポイント、wss://で待ち受けるWebSocketサーバーの3つです。

コンソールでのAI/ML規約への同意と電話番号の紐付け

公式のオンボーディング手順は、利用前に次の設定を求めています。

  1. 新しいConsoleでは Voice の Settings にある Privacy & Security を開き、「predictive and generative AI/ML features addendum」の規約に同意して保存する(旧Consoleは Voice の Settings、General で同名のAddendumをオンにする)
  2. TwiML App を作り、Voice URL に自分のエンドポイント(例 https://your.example.com/voice)を設定する
  3. 購入した電話番号の着信先に、そのTwiML AppかVoice URLを指定する

同意を忘れると、TwiMLとサーバーが正しくても Conversation Relay のセッションは始まりません。<Start><Transcription>も同じAI/ML機能の扱いなので、文字起こしだけを使う場合も先に同意しておきます。

TwiML配信とWebSocketの1ファイル実装

次のコードは、/voiceでTwiMLを返し、/wsでConversation Relayからのメッセージを受ける学習用の最小構成です。署名検証を省略しているため、外部公開する前に後述のX-Twilio-Signature検証を実装してください。ngrokなどで8080番を公開し、そのホスト名をPUBLIC_HOSTに入れて起動します。返答部分は定型文を1文字ずつ返すだけなので、ここをLLMのストリーム出力に差し替えます。

// server.mjs(Node.js 20以降・npm i ws)
import http from "node:http";
import { WebSocketServer } from "ws";

const HOST = process.env.PUBLIC_HOST; // 例: xxxx.ngrok.app

const twiml = `<?xml version="1.0" encoding="UTF-8"?>
<Response>
  <Connect action="https://${HOST}/cr-ended">
    <ConversationRelay url="wss://${HOST}/ws" language="ja-JP"
      ttsProvider="Google" voice="ja-JP-Wavenet-B"
      welcomeGreeting="お電話ありがとうございます。ご用件をどうぞ。" />
  </Connect>
</Response>`;

const server = http.createServer((req, res) => {
  if (req.url === "/voice") {
    res.writeHead(200, { "Content-Type": "text/xml" });
    return res.end(twiml);
  }
  if (req.url === "/cr-ended") {
    res.writeHead(200, { "Content-Type": "text/xml" });
    return res.end("<Response><Hangup/></Response>");
  }
  res.writeHead(404).end();
});

// LLMの代わりに定型文を1文字ずつ返す(ここをLLMのストリーム出力に置き換える)
async function* reply(text) {
  for (const ch of `「${text}」ですね。担当者から折り返します。`) yield ch;
}

const wss = new WebSocketServer({ server, path: "/ws" });
wss.on("connection", (ws) => {
  ws.on("message", async (raw) => {
    let msg;
    try {
      msg = JSON.parse(raw);
    } catch {
      return; // 解析できないメッセージは無視する(接続を閉じると通話が切れる)
    }
    if (!msg || typeof msg !== "object" || Array.isArray(msg)) return;
    if (msg.type === "setup") console.log("call", msg.callSid, msg.from);
    if (msg.type !== "prompt" || !msg.last) return;
    let pending = null;
    for await (const token of reply(msg.voicePrompt)) {
      if (pending !== null) ws.send(JSON.stringify({ type: "text", token: pending, last: false }));
      pending = token;
    }
    if (pending !== null) ws.send(JSON.stringify({ type: "text", token: pending, last: true }));
  });
});

server.listen(Number(process.env.PORT ?? 8080));

Node.js 26.5.0 と ws 8.22.0 で起動し、setupとpromptを模したメッセージを送ると、発話を「予約の変更」とした場合にtextメッセージが23個(返答の文字数と同じ)返り、最後の1個だけlast: trueになることを確認しています。WebSocketメッセージの仕様は、LLMの出力を溜めずに届いた順に送ることを推奨しています。全文を待つ間は無音になるためです。

Twilioから届くのはsetup・prompt・dtmf・interrupt・errorの5種で、こちらから送れるのはtext・play・sendDigits・language・endの5種です。<Parameter>子要素で渡した値はsetupのcustomParametersに入ります。ヘルパーライブラリ(npm の twilio 6.1.2、PyPI の twilio 9.11.2)はTwiML生成とREST操作用で、WebSocket側には不要です。

既定値の変更でつまずく属性

<ConversationRelay>の属性リファレンスは2025年5月と9月に既定値が変わっており、それ以前の手順記事とは一致しません。

属性 現在の既定 注記
language en-US 日本語はja-JPを明示
ttsProvider ElevenLabs Google・Amazonも可
transcriptionProvider Deepgram 2025年9月12日以前からの利用はGoogle
reportInputDuringAgentSpeech none 2025年5月より前はany
interruptible any 発話で読み上げを止めるか
speechTimeout auto 指定時は600〜5000ms
preemptible false 次の応答で読み上げを打ち切るか

実務で効くのはreportInputDuringAgentSpeechです。公式は「The default was any before May 2025 and it’s now none.」と明記しており、既定のままだとAIの発話中に相手が話した内容はアプリに届きません。interruptible="any"で読み上げだけは止まるため、止まるのに内容が取れない状態になります。発話内容を使うならspeechを指定します。

日本語の音声対話の精度を決める設定

既定値は英語圏向けなので、日本語の聞き取りと読み上げの品質は次の4点の選び方で決まります。

STTプロバイダーと音声認識モデルの選択

speechModelの既定は、Googleならtelephony、Deepgramなら対応言語ではnova-3-general、それ以外はnova-2-generalです。Deepgramのモデル一覧ではNova-3が日本語(ja)に対応しているので、既定のDeepgramでja-JPを指定すればNova-3で認識されます。2025年9月12日より前からの利用アカウントは既定がGoogleなので、比べるならtranscriptionProviderを明示して同じ条件で両方を試します。

話し終わりの判定も精度に効きます。speechTimeoutを長くすると言い淀みで途中送信されにくい代わりに応答が遅れます。Deepgramの会話用モデルFluxをspeechModel="flux"で選ぶと、eotThreshold(既定0.8、0.5〜0.9)で話し終わりの確信度を調整できます。Deepgram側ではFluxの多言語モデルが日本語を含みますが、Twilioはflux指定時の対応言語を明記していないので、採用前に実通話で確かめてください。Deepgram自体の料金と日本語対応はDeepgramとは?料金・日本語対応・APIの使い方を解説【2026年版】にまとめています。

hintsによる固有名詞の認識補助

社名・商品名・型番のように辞書にない語は、hints属性にカンマ区切りで並べると認識されやすくなります。公式は「ブランド名や業界用語」を例に挙げています。予約受付なら店舗名やメニュー名、保守窓口なら製品の型番を入れておくと、LLMに渡る前の聞き間違いを減らせます。

ElevenLabs既定とSSMLのen-US限定

既定TTSはElevenLabsで、音声設定ドキュメントの既定音声表でもja-JP行にElevenLabsのVoice ID 3JDquces8E8bkmvbh6Bcが割り当てられています。日本語自体は話せますが、ElevenLabsで解釈されるSSMLタグは<phoneme>だけで、しかもen-US限定です。固有名詞の読み、金額や電話番号の間の取り方を制御したいなら、ttsProviderをGoogleかAmazonに切り替えます。ElevenLabsの料金体系はElevenLabs(イレブンラボ)とは?料金6プランと無料版の商用制限・使い方【2026年9月】で扱っています。

なお音声設定ページの既定音声表は、ja-JP行のTranscription providerをGoogleと書いたままで、属性リファレンスの既定Deepgramと食い違っています。推測に任せず明示指定し、対応しない組み合わせならエラー64106が返ることを覚えておきます。

自動言語検出(multi)の組み合わせ制約

1本の通話に複数言語が混ざるなら、<Language>子要素を言語ごとに置いてlanguageメッセージで切り替えるか、Twilioに判定させるmultiを使います。multiはSTTがDeepgram、TTSがElevenLabsでないとエラーになりセッションが終わります。前項のとおりElevenLabsは日本語でSSMLが効かないため、自動言語検出とSSML制御は同じセッションでは両立しません。multiのときpromptのlangはen-USではなくenのような主要言語タグだけが入るので、地域コード込みで分岐している実装は素通りします。

料金の積み上がり方と月額の試算

Twilioの料金は、通話料・番号の月額・AI機能の分単価を足し上げる形です。LLMの利用料はTwilioの外で別にかかります。

通話と番号の単価

項目 発信 着信
ローカル・国内通話 $0.0746/分 $0.0100/分+$4.75/月
モバイル通話 $0.1850/分 –
トールフリー通話 $0.0641/分 $0.1854/分+$25.00/月
0570 $0.1200/分 –
ブラウザ・アプリ $0.0040/分 $0.0040/分

着信の$0.0100/分は月額$4.75の番号と組で表示されています。番号の料金表には別に「ローカル0ABJ番号 $20.00/月」があり、市外局番付きの番号を取ると月額は約4.2倍です。国内での調達ルートやSMSの制約まで含めた比較はVonageとTwilio比較|CPaaS選定で見る料金・提供体制・SMS制約で扱っています。

AI機能を載せた月額の試算

国内番号で着信を受け、平均3分の通話を月3,000件AIが応対する場合(月9,000分)で計算します。着信$0.0100と Conversation Relay $0.07で1分$0.08、9,000分で$720。番号の$4.75を足すと$724.75です。録音を残すなら録音$0.0025/分($22.50)と保存$0.0005/分(月間)が、通話後に言語オペレーターを走らせるなら標準$0.0040/分が加わります。外部へ発信してAIが話す用途では、通話料が国内$0.0746、携帯宛て$0.1850に変わるので、相手の大半が携帯なら1分あたりの総額は$0.255まで上がります。どれもドル建ての従量課金なので、円での予算は為替で動きます。

Media Streamsの音声形式と自前処理の要件

Media Streams は通話音声をそのままWebSocketへ流します。受け取るだけなら<Start><Stream>、こちらから音声を差し込むなら<Connect><Stream>です。音声フォーマットは固定で、受信するstartメッセージのmediaFormatはencodingがaudio/x-mulaw、sampleRateが8000です。16kHz前提の音声認識モデルへ渡すならリサンプリングが要ります。

返せるメッセージはmedia・mark・clearです。clearは再生待ちの音声を捨てる割り込み用で、相手が話し始めたら読み上げを止める処理は発話検知から自分で組みます。音声対話モデルへ直接つなぐ構成もこちらで、相手のモデルが8kHzのμ-lawを受け付けなければ変換を挟みます。

通話録音と文字起こしを同時に残す構成

AI応対の品質確認には録音とテキストの両方が欲しくなりますが、Conversation Relay は会話ログを既定で保存しません。

Conversation Relayと録音の併用

Conversation Intelligence (classic)との連携ドキュメントは「By default, Conversation Relay transcripts are not stored by Twilio.」と明記しています。intelligenceService属性にIntelligence ServiceのSIDを渡すと文字起こしが保存されますが、送られるのは発話のテキストだけで通話音声は送られません。音声も残すなら、<Connect>の前に録音を始めます。

<Response>
  <Start>
    <Recording recordingStatusCallback="https://example.com/rec" />
  </Start>
  <Connect>
    <ConversationRelay url="wss://example.com/ws" language="ja-JP"
      intelligenceService="GAxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" />
  </Connect>
</Response>

<Start><Recording>は他のTwiMLより先に録音を始め、既定は双方の音声(both)を2チャンネル(dual)で残します。2チャンネルなら、後から顧客とAIの発話を分けて聞き直せます。

リアルタイム文字起こしとフォーク上限

Conversation Relay を使わない通話(人のオペレーターが出る通話など)を文字に起こすなら、<Start><Transcription>を使います。<Transcription>のリファレンスではlanguageCodeの既定がen-USなので、ここでもja-JPの指定が必須です。transcriptionEngineの既定はリファレンス上auto(Twilioが精度や可用性をもとに選ぶ)ですが、2026年10月22日より前からリアルタイム文字起こしを使っているアカウントはgoogleが既定として維持される、と注記されています。認識結果の傾向をそろえたいならgoogleかdeepgramを明示します。結果はstatusCallbackUrlへ発話単位で届き、partialResultsを有効にすると確定前の結果に0.0〜1.0のStabilityが付きます。

見落としやすいのが1通話あたり4本のフォーク上限で、Media Streams・SIPREC・リアルタイム文字起こし・非同期の留守番電話検知で共有します。<Transcription>は既定のboth_tracksで2本を使うので、Media Streamsと併用するなら先に本数を数えておきます。

Conversation Intelligence (classic)での通話後分析

通話後の要約・感情分析・個人情報の除去を担う製品は、2024年6月17日に Voice Intelligence の名前で一般提供が始まり、改称を経て現在のドキュメント名は Conversation Intelligence (classic) です。APIの名前空間はclient.intelligence.v2.transcriptsのままなので、旧名称の時代のコードは書き換え不要です。

Intelligence Service で Auto Transcribe を有効にすると、新しい録音が自動で文字起こしされます。ただしオンボーディングガイドはこの自動処理を「Only available for Twilio Recordings.」としており、外部に置いた録音はAPIで文字起こしを依頼する形になります。分析結果をCRMへ書き戻す方法はTwilioとSalesforceの連携方法|5方式の選び方と問い合わせ履歴を自動で残す実装で扱っています。

通話録音のAmazon S3直接保存と設定範囲

録音設定のドキュメントによると、Voice の Recordings の Settings で外部ストレージを有効にし、書き込み権限を持つIAMユーザーのアクセスキーとバケットURLを登録すると、新しい録音は自社のS3バケットへアップロードされます。このときTwilio側にはコピーが残りません。設定は保存後に作られる録音にだけ効き、既存の録音は移りません。

注意すべきはサブアカウントです。外部保存はサブアカウントごとに設定が要り、認証情報のないサブアカウントで録音が始まると、録音はエラー53611で黙って破棄されます。顧客ごとにサブアカウントを切る構成では、設定漏れを先に洗い出してください。S3に入れた後の解析パイプラインの組み方は、Vonageの例ですが音声通話APIの録音をS3に保存し解析する実装|Vonageが参考になります。

留守番電話検知(AMD)の料金と精度

AIから発信する用途では、相手が人か留守番電話かを先に判定します。料金は1通話$0.0075で、分単価ではありません。AMDのドキュメントによると、発信APIのMachineDetectionにEnableを指定すると判定がつき次第AnsweredBy(human・machine_start・fax・unknown)が返り、DetectMessageEndを指定すると留守番電話の応答メッセージが終わるまで待ってから返ります。

精度について、公式FAQはDetectMessageEndを「close to 100% accurate in US destinations with default settings」としつつ、国際発信では留守番電話の発信音が国ごとに違うため「accuracy may be slightly reduced」と書いています。日本宛ての精度を示す公式の数値はありません。判定の調整はMachineDetectionTimeout(既定30秒、3〜59秒)、MachineDetectionSpeechThreshold(既定2400ms)などで行い、公式は、応答メッセージが短い留守番電話を人と誤判定する場合にMachineDetectionSpeechThresholdを下げる調整を挙げています。本番前に自社の発信リストでunknownと誤判定の割合を測ってから閾値を決めます。なおAsyncAmd=trueの非同期判定は、判定中にフォーク上限の1本を使います。

Conversation Relayの本番運用に必要な障害対策と接続制御

本番投入前に確認するのは、切断時の復旧、PCI・HIPAA対象通話の設定、接続元の署名検証です。

WebSocket切断時の非復旧仕様とエラーコード

公式は「If the WebSocket disconnects unexpectedly in Conversation Relay, we don’t reconnect, and the call disconnects with a failed status.」と書いています。Twilioは再接続しません。復旧させるには、<Connect>のactionURLへのコールバックで新しい<Connect><ConversationRelay>を返します。同じ通話かどうかはcallSidで確かめ、会話の途中経過は自前で持っておかないと再接続後は文脈がゼロから始まります。

監視するエラーは、接続できない64102、予期せず切れた64105、RTPタイムアウトの64108、同時セッション上限の64109です。64109と64105を分けて通知すれば、容量不足とネットワーク障害を切り分けられます。

PCI・HIPAA対象通話での設定制約

Conversation Relay はPCI準拠のTTS・STTプロバイダーで組めばPCI対象のワークフローに使え、適切に設定すればHIPAA適格サービスとして扱えます(BAAの締結が前提)。一方、分析側は「Conversation Intelligence (classic) is not PCI compliant and must not be enabled in Conversation Relay workflows that are subject to PCI.」とされています。カード番号を扱うPCI対象の通話では、intelligenceServiceによるConversation Intelligence (classic)との連携を無効にします。決済処理を別経路に分ける場合も、保存対象にPCIデータが入らない設計を確認します。welcomeGreeting・hints・<Parameter>の値にもカード情報を入れられません。

WebSocketの署名検証

AIエージェントを電話網に安全につなぐ要は、WebSocketの入口です。Conversation Relay は最初のハンドシェイクにX-Twilio-Signatureヘッダーを付けて送り、検証方法は通常のWebhookと同じです。Auth TokenとリクエストURLで署名を検証し、一致した接続だけを受け付けます。wss://のエンドポイントはインターネットから到達できる必要があるため、この検証を省くと第三者が自由にセッションを張れます。通話品質そのものを事前に測る方法はTwilio Preflightとは?通話品質の事前診断の実装と結果の読み方、Voice SDKの推奨設定で扱っています。

電話のAI応対を自社の業務システムやCRMと組み合わせて作る場合は、AI音声認識システム開発の支援内容もあわせてご覧ください。

よくある質問

TwilioのAPIでは何ができますか?

音声通話・SMS・メール・WhatsApp・本人確認などを、HTTPのAPIとTwiMLで操作できます。音声では発信・着信の制御に加え、文字起こしやAIエージェントとの接続までAPIで完結します。SMSや音声で認証コードを送る使い方はTwilio Verifyとは|SMS・音声認証の実装手順と日本向け料金を参照してください。

Twilioで電話の自動応対ボットは作れますか?

作れます。<Connect><ConversationRelay>を返すTwiMLと、LLMにつないだWebSocketサーバーを用意すれば、自由な発話で受け答えするボットになります。用件が「1は予約、2は解約」のように選択肢で分けられるなら、LLMを使わないIVRのほうが安く確実です。IVRとの使い分けはボイスボットとは?仕組み・IVRとの違い・導入判断の基準を解説【2026年】とIVRとは?自動音声応答の仕組み・種類と構築形態の選び方を解説で整理しています。

WhatsAppの双方向チャットボットもConversation Relayで作れますか?

作れません。Conversation Relay は音声通話のTwiMLです。WhatsAppのボットは、受信メッセージをWebhookで受けてMessaging APIで返信する構成になります。公式のクイックスタートによると、Twilio Sandbox for WhatsApp を使えば送信者の登録審査を待たずに試せます。本番では、事業者から始める送信にテンプレートが必須で、利用者からのメッセージを受けてから24時間だけ自由文で返信できる、というWhatsApp側の制約に合わせて設計します。

Twilioの音声AIで問い合わせ履歴をSalesforceに残せますか?

残せます。intelligenceServiceで会話の文字起こしを保存し、通話終了後にその結果をSalesforceへ書き込む流れが基本です。Service Cloud Voice を使うかAPIで自前に書き込むかで必要なライセンスが変わるため、方式の比較は前述のSalesforce連携の記事で確認してください。

Twilioの通話で同時通訳はできますか?

土台は作れますが、翻訳自体は自分のLLMの役割です。Conversation Relay が相手の発話をテキストにし、使う言語ごとに<Language>要素を宣言しておき、LLMが訳したテキストをtextメッセージで返すときにlangへ訳先の言語を付けると、その言語で読み上げられます。話者の言語をTwilioに判定させるmultiを使う場合は、STTがDeepgram、TTSがElevenLabsの組み合わせに固定されます。

関連記事

お気に入りに入れた記事の一覧

この記事は以下の記事からリンクされています

資料請求

今日のトレンド記事 直近 24 時間で、いつもより多く読まれている記事

  1. 2026.10.14 テックブログ Commune不正アクセス:約30.7万人漏えいの対象確認と共通署名鍵の教訓
  2. 2026.10.14 テックブログ ブックオフ不正アクセス:約638万人の対象確認と本物メールの見分け方
  3. 2026.10.15 テックブログ リゾートトラスト不正アクセス:会員2.6万件・カハラ横浜3.6万件の対象確認と窓口
  4. 2026.10.09 テックブログ ユニリタの不正アクセス:SaaS文書管理から漏れた顧客の認証情報と回す手順
  5. 2026.10.08 コラム 特定商取引法に基づく表記の書き方:必須15項目のテンプレートと置き場所

RELATED POSTS 関連記事

目次