Gatherの音声認識
Twilioは通話に対して自前のサーバから命令をTwilioに送信することで通話を制御することができます。このサーバ側アプリケーションをTwiMLアプリと呼び、応答の形式はTwiMLという名のXMLになります。という話はTwilioのユーザーならみんな知っていると思うのですが、今回はこのTwiMLの Gather について自分がハマった経験を共有します。
<?xml version="1.0" encoding="UTF-8"?>
<Response>
<Gather input="speech" action="/speech_result">
<Say>Talk nerdy to me!</Say>
</Gather>
<Redirect>https://example.com/speech_result</Redirect>
</Response>
Twilioの Gather のサンプルっていつもユーザーが無言/入力無しの場合は即座に電話が切れるものしかないので良くないですよね。上の例は、ユーザーの音声入力を待って /speech_result に遷移しますが、無言のままでも同じURIに遷移するので通話は維持されます。
Gather を使った音声認識はこれだけで実装できます。あとは /speech_result にパラメータ SpeechResult がPOSTされるので、その内容をみて次の動作に移ることができます。
Gatherの音声認識のお値段は高い
ところで、音声認識の価格ページのスクショがこちら。
ご覧の通り、15秒までの音声をSpeech to textで使うと３円かかります。一回の通話で一度くらいしか使わないのであれば問題もないかもしれませんが、それでもお高めの価格設定です。というのも、たとえばGoogleの同機能はこんなものだから。
15秒未満の音声は15秒に切り上げられるので実質15秒として、15秒の音声が60分まで（4 x 60 = 240 回の利用）までは無料、以降はドル円112円換算で0.6円/15秒のコストになります。TwilioはGoogleのおよそ5倍の値段ですね。しかも無料枠がありません。
そして、これドキュメントにないんですけど、時々このspeech to textの結果が「何じゃ|なんじゃ これは|これは 一体|いったい どういうことだ|どういうことだ」みたいな形式になることがあるので、Twilioも裏ではGの機能を使っていることがわかります。
今のところ、Twilioには音声ストリームをクライアントが受信する方法がない（ないわけじゃないけど実質的に極めて限られている）ので、同じ機能を自前で実装するのは難しく、価格にはそれなりの意味があるとは思います。いい商売ですけど。
気づかずに使ってしまうことがある
しかし、気をつけなくてはいけないのは、うっかりこの機能を使ってしまう場合のことです。
というのも、 Gather を使った音声認識には、DTMFと音声の両方を認識させる機能があるのですが、input アトリビュートに dtmf speech と記載すると、DTMFしか使わない場合でも speech を使ったものとしてきっちり3円課金されるからです。
<?xml version="1.0" encoding="UTF-8"?>
<Response>
<Gather input="speech dtmf" numDigits="4" action="/speech_result">
<Say>To talk or to push, that's your problem</Say>
</Gather>
<Redirect>https://example.com/speech_result</Redirect>
</Response>
これ、大変便利な機能で、といっても既存のIVR業者なら普通に使えるんですが、話者が受話器に向かって話せば音声認識を、ボタンを押してトーン信号を送ればトーン信号の認識を実行してくれます。昨今、音声認識自体は飛躍的に向上しましたが、まあ確実なのはやはりトーン信号によるボタンでの入力なので、うまく組み合わせると便利なサービスを構築できます。
ところが、上に書いた通り、困ったことにこの機能を使うとdtmfしか使っていなくても音声認識を使ったものとして課金されてしまいます。dtmfの認識自体は課金対象ではないので、請求が届いてからびっくりすることになります。
そして、この請求というのがちょっと厄介で、いまTwilioの管理画面から通話記録を参照しても、各通話ごとの通話料金はそれぞれ参照することが可能なのですが、通話料金以外の、例えばこの音声認識のような機能を使った場合、それが各通話に対して幾ら課金されたのかを参照することは出来ません。管理画面の詳細まで進むと総計は見られるのですが、結局個別の通話についてはわからないままなので、細心の注意を払わないと翌月の請求で初めて気づくなんてことも起こり得ます。
これについてTwilioの年次イベントの際に質問してみたのですが、裏側の実装では一旦音声としてデータを取得して、もしdtmfだったらそっちの挙動に切り替える、みたいなものになっているらしく、Twilio側の事情ではあるけれども仕方がないとのことでした。困ったものです。
まとめ
音声認識は高額になるので、意図しない箇所でうっかり使ってしまわないように気をつけなければいけません。また、使う場合には一回の通話で何度も利用できるような設計にすると思わぬ請求が発生することになります。価格自体も高いので、いつかTwilioの音声データをRTPのストリームとして取得して処理できるような機能が利用可能になるといいですが、それまでは我慢と工夫と設計でなんとか逃げましょう。既存のIVRの仕組みでは割と普通に使われる機能なので（N社系のとか…）、同じ機能を用意しろとクライアント様から要求された場合はつらいですけどね。