“5Gの5倍” 100Gbpsの無線伝送、NTTが「OAM多重」で実現

　NTTは5月15日、OAM（Orbital Angular Momentum）多重を活用して世界初となる100Gbpsの無線伝送に成功したと発表した。現在のLTEやWi-Fiのおよそ100倍、今後普及が見込まれる5Gの5倍に当たる「5Gの次世代を実現する革新的無線通信技術」（同社）という。

　OAMは日本語で「軌道角運動量」。進行方向に対して螺旋（らせん）形状になる電波の"回転度合い"を示す。回転度合いの異なる電波は互いに交わらず、平行して進む特徴があるため、複数の電波を重ね合わせて通信容量を増やすOAM多重の研究が各所で進められている。例えば米国の南カリフォルニア大学は2016年にミリ波帯の60GHz帯を用いて32Gbpsの伝送を実験した。

　NTTは、近年広く普及したMIMO（Multiple Input Multiple Output：送信機と受信機の双方に複数のアンテナを用い、通信品質を向上させる無線信号処理技術）を組み合わせ、複数のOAM多重伝送を同時に行える送受信装置を試作。実験室で28GHz帯を使った実験を行い、11の電波を重ねて100Gbpsを実現したという。

　今後は28GHz帯の屋外実験を実施するほか、より高速な無線通信が可能なミリ波帯での実験も計画している。将来は「光ファイバーの敷設が難しい場所でも大容量通信が利用できる他、スポーツやコンサートでの非圧縮8Kや16Kリアルタイム中継も可能になる」としている。

　NTTは5月23〜25日に開催される専門展示会「ワイヤレステクノロジーパーク2018」（WTP2018、東京ビッグサイト）で同技術を展示発表する。また6月3〜6日に米国で開催されるIEEE主催の国際会議「VTC2018-Spring」で発表を行う予定だ。

「スマートスピーカー」の中にある「人工知能」は何をしているのか、作り方から理解する

　まずは、自作スマートスピーカーの概要について聞いた。開発に必要な要素は大きく、ハードウェア部分とソフトウェア部分に分かれる。以下、本人が用意したプレゼン資料の図版を交えポイントを解説しよう。

ハードはシンプルだが、ソフトはさまざまなオープンソースの組み合わせ

　スマートスピーカーのほとんどの処理は、クラウド上のサーバで実行されるので、ハードウェア自体はシンプルな作りである。必要なパーツは、小型コンピュータ（今回はRaspberry Pi）、USBマイクロフォン、USBスピーカーの3点だ。実際のスマートスピーカーはより高度なハードウェアを搭載しているが、自作する上ではRaspberry PiのUSBポートにマイクとスピーカーを接続するだけでハードウェアは完成する。

 
Raspberry PiのUSBポートにUSBマイクロフォンとUSBスピーカーを接続するだけでハードウェアは完成

　なお、栂井氏は、赤外線送受信の回路も備えたものを作成したのだが、それについては後述する。

　ハードウェアができたら、さまざまな処理を実行するためのプログラムを組まなければならない。とはいえ、インディ開発者がゼロからスマートスピーカーのプログラムを構築するのは非現実的な話だ。そこで、栂井氏は、Raspberry Pi上でLinuxを動かし、さまざまなオープンソースソフトウェア（OSS）を組み合わせることでオリジナルなスマートスピーカーを実現した。

　次の図は、スマートスピーカーに音声コマンドで指示を行い、サーバ上の処理を経て応答が返ってくるまでのプロセスをソフトウェアの構成要素の視点から段階的に示したものだ。順番に解説していこう。

 
スマートスピーカーが処理を実行する際のソフトウェアにおける構成要素

ホットワード検出

　音声認識を行うスマートスピーカーにとって、ホットワードは、極めて重要な要素である。スタンバイ状態のスマートスピーカーは、マイクで常に周囲の音を拾っている。自分が呼ばれたことを認識し、処理を開始するためには、あらかじめ特定の合言葉を決めておく必要がある。

　栂井氏は、「Snowboy Hotword Detection」を活用している。このサービスは、独自のホットワードを3回発声し登録するだけで、機械学習によって高精度な検出モデルを作成し、Raspberry Piなどの環境で利用可能にするライブラリだ。個人は無料で利用可能。

音声録音と認識

　ホットワードによって処理を開始したスマートスピーカーに対し、ユーザーは音声で指示を出す。その音声を、音声認識を行うサーバに送信するための録音処理が必要になる。音声の録音は、「SoX」を利用する。

　SoXは、コマンドラインから音声の録音・加工・変換を行うことのできるOSSだ。下図のようなコマンドを組むことで、「音量が閾値（しきいち）を超えたら録音を開始し、下回ると録音を終了する」といった、「発話による指示で動作を開始し、自動的に発話区間を検出して録音を行う」プログラムを構築できる。これにより、音声のWAVEファイルを生成し、それを音声認識サーバに送信する仕組みだ。

 
SoXは、コマンドラインで音声レベルが閾値を超えたら録音を開始するための設定が可能

　1つ驚いたのは、ユーザーの音声指示をいったん録音し、音声ファイルを生成した上でサーバに送信する点だ。筆者は、リアルタイムストリーミングでサーバに送信されると考えていたが、その理由について、栂井氏は「スマートスピーカーの機種により、ストリーミング送信する場合もあり、その方がレスポンスは優れている。ただし、技術的にハードルが高い部分もある。音声ファイルを生成後に送信する方法なら、通常のHTTP通信が可能なので作り込みもシンプルになる」と明かしてくれた。

音声認識サービスを利用してテキストへ変換

　端末内で生成した音声ファイルを音声認識サービスに送信して文字列に変換する。いわゆる「Speech to Text」の工程である。この処理は、「Cognitive Service Bing Speech API」や「Google Cloud Speech API」といった音声認識サービスを利用する。

 
日進月歩で進化している音声認識だけに、Webサービスを利用することで性能向上の恩恵を享受できる

人工知能で自然言語理解処理を行う

　前の段階で、文字列に変換されたデータを受け取ったら、次は、その文字列を人工知能に送信し、ユーザーが何を望んでいるのかを理解するための処理を行う。ここでは、「Language Understanding Intelligent Service（LUIS）」を利用して、後述する意図分類と要素抽出を行う。

意図分類

　コンピュータが人間の発話を理解するためには、単にそこに含まれる単語の意味を理解するだけではなく、全体の文脈を読み解く必要がある。この文脈を読み解くことを「発話意図分類」という。

　言うなればユーザーの「目的」が何かを理解するための手順だ。例えば、時刻を知りたい場合、「今、何時？」「時刻を教えて？」など人間の発話はブレるものだ。そのような場合でも「ユーザーは時間を知りたがっている」とコンピュータに理解させる必要がある。

 
ユーザーの発話の「目的」が何であるかをスマートスピーカーが理解するための処理

要素を抽出する

　コンピュータがユーザーの意図（目的）を理解して対話を成り立たせるためには、発話に含まれる単語が何を示しているのか、その意味を理解する必要がある。それを行うためには、文字列の中から対話の根幹を成す「要素」を抽出しなければならない。

　例えば、「新宿の明日の降水確率は？」と問い掛けると、その中から「新宿＝場所」「明日＝時間」「降水確率＝天気」という形で要素を抽出し、「新宿」には「場所」、「明日」には「時間」、「降水確率」には「天気」というラベルを付加する。ユーザーの意図に対する答えを見つけるためのキーワードを拾い上げる工程だと考えればよい。

 
ユーザーの発話の中から、要素を抽出する工程

　人工知能が意図分類と要素抽出を開発者の意図通りに行うためには、人工知能（この場合は「LUIS」）をトレーニング（機械学習）する必要がある（参考）。基本的には、例文となる文章を入力することで学習させる。前に発話の「ブレ」について説明したが、言い方を変えた例文が多ければそれだけ人工知能が賢くなるという。

対話モデルを用意する

　ユーザーからの発話によるリクエストに対し、スマートスピーカーがどのような答えを返すのかを決めるのがこの部分である。ここでは、「Watson Assistant」を使い構築する。

　前の段階でサーバから帰ってきた「意図」と「要素」に対する解答を返すために「if分岐」などでルールを記述する。「この部分は機械学習で実行する場合もあるが、まだまだ発展途上なので、ユーザーの意図に対し確実な解答を返すためにはif文を定義する必要がある」（栂井氏）という。

　ちなみに、「要素を抽出する」の手順の説明では天気についての対話モデルを例に挙げているが、天気そのものの情報は（天気情報を提供するWebサービスのAPIから取得する」（栂井氏）そうだ。

 
スマートスピーカーのソフトウェア構築のハイライトともいうべき対話モデルを構築する

音声合成

　対話モデルから返されてきた「解答」は文字列の情報なので、それを音声にしてやる必要がある。いわゆる「Text to Speech」と呼ばれるAPIをRaspberry Piから叩くことになる。

　ここでは2つの選択肢がある。音声合成をサーバ側で行うのか、ローカルで行うのかの2択だ。GoogleやAWSが提供しているサーバ側で処理する音声合成APIを使うと、とても自然な発話合成を実現できるが、音声ファイルを転送するタイムラグが生じる。一方、ローカルで実施すれば転送のタイムラグは気にする必要はなくなる。

　栂井氏は「レスポンスを優先したかったので、ローカルで処理できる『OpenJtalk』を利用した。ただし、GoogleやAWSの音声合成と比較すると合成品質は落ちる」という。

 
対話モデルが返してきた解答の文字列を、音声合成を利用して音声にする

　サーバ処理とローカル処理における音声合成の品質の差を体感したければ、上記で紹介したOpenJtalkと、サーバ処理の「Amazon Polly」のサンプルデモにそれぞれ同じテキストを入力して聴き比べてみるといいだろう。

GitHubでソースコードを公開中

　ここまでが自作スマートスピーカーのソフトウェアを構築するまでの概要だが、栂井氏は、このソフトウェアのコードをGitHubで「Py Assistant」として公開しているので、参考にしてほしい。

　GitHubでは、本稿で触れていなかった赤外線送受信の回路やプログラムについても言及している。また、栂井氏が自作した赤外線付きのスマートスピーカーで自室のテレビをオン／オフする動画があるので、それも併せて紹介しておこう。

 
自作スマートスピーカーの赤外線回路。パーツ類は通販でそろえることができる

　技術者でもプログラマーでもない筆者だが、普段から利用しているスマートスピーカーがサーバと連携することでどのような処理を行っているのかを垣間見ることができとても楽しい取材だった。

　名だたる大企業がグローバルに展開するGoogle HomeやAmazon Echoが自作スマートスピーカーと同質のバックグラウンド処理を実行しているとは思わないが、基本的な考え方は同じであろう。それが理解できたことで、いつもとは違った新鮮な感情をいだきながらスマートスピーカーに向かってホットワードを語り掛ける自分がいる。

http://open-jtalk.sp.nitech.ac.jp/

https://github.com/garicchi/pyassistant

 

Pepperの手と人の“触覚”がリアルタイムにリンク——ソフトバンクと慶應大、5Gによる力触覚の伝送実験を実施

　ソフトバンクは2018年5月11日、慶應義塾大学ハプティクス研究センターと共同で、物に触れたり、持ったりしたときの「硬い」や「柔らかい」といった感覚「力触覚（りきしょっかく）」の情報を無線通信で伝送する実証実験を実施し、第5世代移動通信システム（5G）による力触覚伝送の有用性を確認したと発表した。

　今回の実証実験は、同センターが開発した、力触覚の情報を伝送して再現する「リアルハプティクス技術」をコミュニケーションロボットに応用する共同研究の一環として実施したもの。同技術では、現実の物体や周辺環境との接触情報を双方向で伝送することで、力触覚を再現するという。

　実証実験では、ソフトバンクロボティクスの人型ロボット「Pepper」が装着した力触覚伝送用のグローブと、遠隔地にいる人間が装着した遠隔操作用グローブの間で、力触覚の情報を伝送、再現する実験を、5Gと4Gの無線通信環境下で実施。

　リアルハプティクス技術では、リアルタイムかつ双方向に情報を伝送することが必須で、同期性と双方向性が成立しないと、力触覚を再現できなくなる。

　実験の結果、4Gでは遅延による影響で双方のグローブの動きにずれが発生し、正確に力触覚を再現できなかった。5Gではその特長である1ms（1000分の1秒）以下の超低遅延性により、遅延による影響を受けることなく、高精度な力触覚の伝送、再現に成功した。

　この結果、5Gによる力触覚伝送を活用することで、繊細な力加減が必要とされるロボットなどの遠隔操作が可能になることが分かったとしている。

　また、5Gではリアルタイム映像の伝送も可能なため、遠隔地から操作しながら、その様子をリアルタイムにモニターで確認するなど、今後、ロボット分野のさまざまなシーンで活用されることが期待できるという。