Google,Microsoft,IBM各社のSpeech To Textなサービスの比較をしてみました

こんにちは!前回で作成したデータを元に、今度は、以下の3サービスの通話内容を比較してみました!

  • Google Cloud Speech API
  • IBM Watson Speech to text
  • Micrsoft Azure Bing Speech API

なお、Amazonも試したかったのですが、現状はまだ日本語未対応ということで、今回は見送りしました。。。

やったこと

上記3つのSpeech to TextなAPIサービスを、Twilioで録音した3つの音源でそれぞれテキスト化を試み、エクセルで並べて比較しました。

なお、Bing Speech APIについては、音声データが14秒までという制限があるため、14秒以上の音声ファイルがあったものについては冒頭の14秒のみの比較になっています。

留意点

各社のサービスで入力している音声ファイルについては、TwilioのMP3をそれぞれのサービスに合う形で変換しています。(多少の周波数の劣化はあるかもしれません)

  • Google Cloud Speech API → MP3ファイルそのまま
  • IBM Watson Speech to text →MP3ファイルをflacファイルに変換
  • Micrsoft Azure Bing Speech API →MP3ファイルをWAVファイルに変換

また、Twilioが電話による音声データという制限上、周波数が8,000ヘルツ程度となってしまい、例えばGoogleのおすすめする周波数帯には届かないといった課題もあります。

これらの音声ファイル上の工夫をすることによって、APIからの結果が向上される可能性は十分にあります。が、今回は単純にとってきたデータをそのまま使ってみることにしました。

結果

さっそく結果を共有してみます!(画像が見にくかったら、ごめんなさい!)
詳細はこちら(GoogleDrive)より確認することができます。

①「一般回線×一般回線」(Twilio VOICE × Twilio VOICE)

②「IP電話×IP電話」(Twilio CLIENT × Twilio CLIENT)

③「一般回線×IP電話」(Twilio VOICE × Twilio CLIENT)

総論

ざっと見た限りだと、Google Cloud Speech APIが一番精度良いかな、という感想です。ただ、音声を拾ってくれてない箇所も何箇所かありますね。
Bing Speech APIも所々精度の良さは感じますが、14秒制限がある分、片手落ちな感じはありますね。
Watsonは、うーん、どうなんでしょうか。音声を拾ってきてくれてることには間違いなさそうですし、声に出してみたときに近しい言葉を返してきてくれてるようですが、テキストだけ読むと何が何やらというのが正直なところです。

とはいえ、音声データの品質向上を行い、機械・人による学習や編集を行うことで、精度はもっと向上できそうですね!

Twilioで録音した3つの会話データをGoogle Cloud Speech APIでテキスト化してみた結果

こんにちは!今回はGoogle Cloud Speech APIの精度ってどんなもんよ?ってことで、弊社BCT環境で構築した通話サービス(Twilioを利用)で録音した結果のテキスト化がどうなるかを公開します!今回実験したのは、Twilio VOICETwilio CLIENTを使っての比較です。

弊社BCTでは、一般電話回線もIP電話サービスも両方扱っており、相互乗り入れも行なっています。そうした中で、「そもそも通話品質はどうなの?」「録音できるの?」「録音したデータのテキスト化は可能?」といったお問い合わせを多く頂きます。それらに対する現状の回答というのが今回のエントリーになります。通話品質および録音についてはサポートしておりますが、テキスト化については弊社も検証段階であり、まずは生データをAPIに入れるだけだとどうなるか、という部分を公開したいと思います。

今回使ったサービス

Google Cloud Speech API

一応念のため、簡単におさらいで、Google Cloud Speech APIは高度な音声認識を有する以下のようなサービスです。

Google Cloud Speech API では、使いやすい API で高度なニューラル ネットワーク モデルを適用し、音声をテキストに変換できます。API は 110 以上の言語と方言を認識し、グローバルなユーザーベースをサポートします。アプリケーションのマイクから入力された音声をテキストに変換する、音声による制御を行う、音声ファイルをテキストに変換するなど、さまざまな機能を利用できます。Google が自身のサービスで利用している技術を利用して、リクエストでアップロードされた音声を認識し、Google Cloud Storage の音声ストレージに統合できます。

Twilio

Twilioは2種類のサービスを使っています。Twilo VOICEは以下の通り、一般電話回線を利用したもの。

Twilio VOICE は、一般電話回線を使用して携帯電話、スマートフォンや固定電話への音声通話を可能にします。
一般電話回線のため音声が高品質で通話のセキュリティーも高く、安定した通信が行えます。

Twilio CLIENTは、いわゆるIP電話サービスですね。

Twilio CLIENT は、インターネット回線によってデータ通信を行い、PC のブラウザー、スマートフォン・タブレットのアプリケーションを通じて音声通話を可能にします。Twilio で提供している iPhone、Android 用アプリケーション開発ライブラリ(SDK)を使えば、モバイルアプリケーションに簡単に組み入れられます。

通話した録音データとその品質について

今回は、電話占いサービスの一部のシーンを想定して、弊社スタッフが通話を試みました(会話の拙さはご容赦ください……笑)。データ自体はTwiloを経由して弊社AWSサーバーのS3に保存されたMP3ファイルを取得しています(つまり、上述の中の質問にある「録音できるか」というご質問に対しては「できる」となります)。

通話したのは「一般回線×一般回線」「IP電話×IP電話」「一般回線×IP電話」の3パターンです。
また、通話品質については解析アプリのSPLスペクトムアナライザで簡易的に結果を求めてみました。

①「一般回線×一般回線」(Twilio VOICE × Twilio VOICE)

一般回線同士での通話データはこちらです。

解析結果:21-9991Hz

②「IP電話×IP電話」(Twilio CLIENT × Twilio CLIENT)

IP電話同士での通話データはこちらです(上記と会話内容も異なります)。

解析結果:43-11929Hz

③「一般回線×IP電話」(Twilio VOICE × Twilio CLIENT)

一般回線とIP電話での通話データはこちらです(いずれも会話内容が異なります)。

解析結果:21-9819Hz

なお、Twilioによる通話品質の公式見解は以下の通りです。
Twilioが Record動詞(録音) で作成するファイル仕様は?

■WAVE仕様
RIFF / Microsoft PCM   16bit
Mono  8000 Hz

■MP3仕様
MPEG ADTS, Layer 3   32kbps
Mono  22050 Hz

通話内容とGoogle Cloud Speech APIによる比較の結果

以下にそれぞれの通話データの内容をテキスト起こししたものと、Google Cloud Speech APIによってテキスト化された内容の比較結果を掲載します。実際通話にあったものの、Google Cloud Speech APIで拾ってくれなかったテキストは紫色フォントで、実際の通話になかったりGoogle Cloud Speech APIが誤ってテキスト化したものは赤文字フォントで記載しました。

①「一般回線×一般回線」(Twilio VOICE × Twilio VOICE)

細かな抜けや誤りはありますが、全体的には内容はカバーされている印象ですね。

②「IP電話×IP電話」(Twilio CLIENT × Twilio CLIENT)

これについては中盤から音が篭ってしまった関係もあり、通話内容を認識できずにテキスト化できなかった項目が多い結果となりました。

③「一般回線×IP電話」(Twilio VOICE × Twilio CLIENT)

これはテキスト化の誤りが多い結果となりました。ただ、通話内容と合わせてテキストを読めば修正は可能なレベルと言えそうです(とはいえ、一番最初の間違いは何でしょうね笑)

Twilioで録音した通話データをGoogle Cloud Speech APIでテキスト化した所管

  • テキスト化の精度は通話データ自体の滑舌や収録状態により、それだけで完璧なデータにはならない
  • 録音されない音声、録音されても間違ってテキスト化されるケースがある
  • 運用にあたっては、機械学習または録音データを聞いて人的に修正などの、修正をする必要がある
  • とはいえ、全て手動でテキスト化するよりは、工数短縮になる可能性が高い

以上のような感じでしょうか。

実際に現場で運用するには、上述したように各種チューニングが必要になりますね!
Google以外にもSpeech to Textのサービスは出ていますので、比較版も作りたいですね!!

Beyond Communication Tools(及びTwilio)を用いたとある電話占いサービスのイメージ例(その2)

こんにちは!前回に引き続き、とある電話占いサービスのイメージ例の紹介になります。前回はサービス画面のイメージをお伝えしました。今回は裏側の仕組みをざっくりとご紹介します。

このサービスの場合は、以前のエントリーにあった発着信方式のうち、「(2-a) Twilio_占い師、ユーザー双方050着信の場合」を採用しています。

 

実際に鑑定をするには、WEBもしくはアプリのサービス画面から鑑定の予約を行います。その鑑定の時間になったら、Twilioからユーザー・占い師双方に050番号から発信され、両者が着信をしたら鑑定通話が行われるというものです。

まとめますと、本電話占いサービスの通話はIP Phoneおよび050(090/080)番号で発着信が行え、Androidアプリ/iOSアプリ/WEBブラウザ/電話回線での通話が行えるシステムになっています。これらはBCTの一部にtwilioのテクノロジーを活用し、実現しています。

このように、BCTを用いた電話占いサービスでは、これまでの電話占いサービスのユーザー体験は損なわれることなく(いえ、むしろUI/UXデザインについては向上させてみせます)、通信コストの削減や通話ログの取得による品質向上も行うことが可能です!事業者の皆様には是非一度ご検討頂ければ幸いです。

また、電話占い以外にも通話を用いたコミュニケーションサービスであれば、広く応用が可能ですよ!
ご興味があれば是非一度お問い合わせくださいませ!

Beyond Communication Tools(及びTwilio)を用いたとある電話占いサービスのイメージ例(その1)

こんにちは!本日は、Beyond Communication Tools(以下、BCT)を用いたとある電話占いサービスのイメージ例を紹介します!先日まで、BCTではTwilioを用いており、通信コストを削減できるといったお話をしてきました。

今日は実際のところ、どんなサービスを作ってるの?というイメージをお伝えできればと思います。
まぁ要するに、本ブログやプレスリリースでBCTでサービス作ってますと書きましたが、本当にあるの?というところが気になるところかと思いますが、ちゃんとモノがありますよ、ということをお伝えするのが今日の目的です!

電話占いサービス画面イメージ

TOPイメージ

イメージはスマホ用です。とある電話占いサービスでは、8割がすでにスマホからのアクセスだとか。もちろんPC用の画面も用意しています。BCTを用いた本電話占いサービスではレスポンシブ対応しておりますので、ユーザー様がPC/スマホいずれからアクセスしても自然に使いやすいUI/UXを目指しています。

占い師プロフィール画面イメージ

鑑定にあたっては占い師の方の待機スケジュールを確認し、予約を行ってから、予約時間帯に電話鑑定が行われるサービスを想定しています。予約した時間にTwilioから自動でユーザー側へ電話発信され、ユーザーが着信を受けたら占い師との通話が開始されるという仕組みになっています。電話鑑定以外にもメール鑑定機能も用意しています。お気に入り登録やレビュー、外部プロフィールページ(ブログ等)へのリンク掲載も行えます。

通話画面イメージ

 

こちらはどうということはないかもしれませんが(笑)、通話した際のイメージ画面です。WEB・アプリいずれも対応可能です。ちなみにスマホアプリについてはiOS10以降のCallKitに準拠してますので、ネイティブの電話アプリのようにスムーズな着信が可能になっています。

上記はサービス画面のイメージですが、こちら以外に占い師向けの管理画面、サービス運用向けの管理画面というのも用意しております。

まとめると、プラットフォームはWEB・アプリいずれも対応可能、サービス画面・管理画面は完備してますよ!ということですね。

さて、次回はこの電話占いサービスでのシステムイメージの説明をしていきます!

Twilioを使って通信コストを削減するには? とある電話占いサービスの事例(その3)

こんにちは!前回前々回に続いてとある電話占いサービスを事例にBeyond Communication Tools(以下、BCT)とそのバックグラウンドで動いているTwilioを活用して、通信コストを削減する方法について解説していきますね。

前回までで、BCTを利用することで、通信コストが削減できることをご説明しました。ただ、電話占いサービスの場合、発着信方式が異なりますため、削減できるコストも若干変わってきます。今回は、その詳しい解説をしていきますね。

大まかには上記の画像の通り、3パターンとなります。パターン名が若干わかりにくいかもしれませんが、一つずつ解説していきますね。

(2-a) Twilio_占い師、ユーザー双方050着信の場合

こちらが一番スタンダートな利用方法かもしれません。サービスのイメージとしては、電話占いサービスの占い師プロフィールに通話鑑定ボタンがあり、ボタンをクリックしたら電話占いサービス側から占い師とユーザーにそれぞれ電話がかかってくるというものです(正確には、占い師の着信が確認できたら、電話占いサービスからユーザーへ自動発信が行われます)。この場合、ユーザーおよび占い師への通話料金負担はありません。通話料金は電話占いサービス事業者にのみ発生します。最安値は双方がアプリを利用したパターンで0.5円/分!最高値は占い師が050番号を使いユーザーが090番号を利用した場合で21.6円/分となっています。料金パターンは以下の通りです。

占い師 | ユーザー App(0.25円/分) 050番号(5.40円/分) 090番号(16.20円/分)
App(0.25円/分) 0.50円/分 5.65円/分 16.45円/分
050番号(5.40円/分) 5.65円/分 10.80円/分 21.60円/分

 

分岐条件(2-b) Twilio_ユーザー050発信、占い師050着信

こちらはユーザーが通話料金を負担するパターンです。ユーザー側から直接占い師へ通話するようなサービスインタフェースの場合には、この方式をとることになりますね。この場合の最安値はやはり双方がアプリを利用したパターンで0.5円/分!最高値はユーザーが固定回線で発信をし占い師が050番号を使う場合で6.4円/分となっています(あくまで電話占いサービス事業者の負担料金であることにご注意ください)。料金パターンは以下の通りです。

占い師 | ユーザー App(0.25円/分) 電話回線(1.00円/分)
App(0.25円/分) 0.50円/分 1.25円/分
050番号(5.40円/分) 5.65円/分 6.40円/分

 

分岐条件(2-c) Twilio_ユーザー0120発信、占い師050着信

実はこの方式はオススメしていません。というのも、0120着信は料金が高いのです。もちろんサービスのパターンとしてはあり得ますので、参考までにご確認頂ければ幸いです。なお、この方式だとユーザーは通話料金を負担しません。この場合の最安値はやはり双方がアプリを利用したパターンで0.5円/分!最高値はユーザーが電話回線で発信をし占い師が050番号を使う場合で21.6円/分となっています。料金パターンは以下の通りです。

占い師 | ユーザー App(0.25円/分) 電話回線(21.60円/分)
App(0.25円/分) 0.50円/分 21.85円/分
050番号(5.40円/分) 5.65円/分 27.00円/分

 

 選択肢(3 電話サポート

さて、こちらはあくまでオプションという形ですが、通話のログを取得するしない等のパターン分けもBCTでは行えます。ご参考までに下記のイメージをご確認いただければと思います。

以上が、BCTおよびTwilioを用いた通信コストの削減方法になります。いかがでしたでしょうか。

ちなみに、BCTを用いれば、電話占いサービスをアプリ化するにあたって気になるマーケット決済手数料の削減もすることができてしまうのです……!これについては、また別の投稿でお伝えしていきます。気になる方は、コーポレートサイトのお知らせよりお問い合わせ頂ければ幸いです。