共同通信デジタルとソニーによるバーチャルアナウンサー「沢村碧」

Amazonのtext-to-speech service (TTS)であるPollyを活用するBananaFMの取り組みを知って (cf. https://typeinf-memo.blogspot.com/2017/08/banana-fmaws-pollyfm.html)から数日、今度は音声に加えてキャラクターのアニメーションが付いた「バーチャルアナウンサー」の存在を知った (cf. [バーチャルアナウンサー「沢村碧」を実現する「アバターエージェントサービス」を提供開始 | 共同通信PRワイヤー](http://prw.kyodonews.jp/opn/release/201708024326/))。

バーチャルアナウンサーは「テキストを与えるだけで音声と、それに応じた (ニュース番組的な)動きが自動的に生成される」のが特徴。

YouTubeにuploadされていた動画を見たが、このTTSは自然で殆ど違和感がなかった。また、キャラクターの動きも適度に2次元寄りなのでやはり違和感がない。ここでうっかりリアル路線を求めると、いわゆる「不気味の谷」に突っ込んでしまうのだろう。

将来的には、複数の異なる「性格付け」を持つキャラクターを、例えば聞き役と解説役に分けて「対話形式」にしたりとかできたら面白そうだ。

この技術を応用して、6O & 21O (『NieR:Automata』)とか、レイシア (『BEATLESS』)とか、セリオ (『To Heart』)とか、御坂妹 (『とある魔術の禁書目録』)とかが興味のあるニュースを喋ってくれるようにならないものか……。

fcitx-skkのローマ字かな変換テーブルを改造する

fcitx-skkを使っていて、個人的に非常に使いづらかった点を修正した:

1. かな入力時に「!」を押した時に全角の「！」が出るようにした
2. かな入力時に「z 」(z+space)で全角スペース「　」を入力できるようにした

特に1.は重要で、「？」は全角なのに「！」は半角というdefaultのちぐはぐな状態は理解し難い。

手順

* 設定をhomedirにcopy
* 設定file (default.json)を修正
* fcitx-skkの設定を更新

設定例

~/.config/libskk/rules/以下に適当な名前 (MyRuleでもMyDefaultでも何でも良い)で設定をcopyする

 % cp -R /usr/share/libskk/rules/default/ ~/.config/libskk/rules/MyRule

お気に入りのtext editor (例ではvim)でdefault.jsonを修正する

 % vim ~/.config/libskk/rules/MyRule/rom-kana/default.json

ずらずらと並んでいるので、適当な場所に設定を追加したり、既存の設定を書き換える:
...
"z ": ["", "　"],

...

"!": ["", "！" ],

...

前述の通り、"!"に関しては半角の"!"から全角の"！"へ変更した。

fcitx-skkの設定を更新するには、fcitx-configtoolをterminal emulatorから叩いて実行するか、window manager (今時はdesktop environmentかな)の設定menuの何処かにそれっぽいものがある (と思う)。

configtoolにて:

* SKKを選択して設定ボタンを押す → SKKの設定windowが出る

* "Dictionary and Rule" → Dictionary Managerのwindowが出る

* Ruleのdrop-down menuの中に、適当につけた名前 (eg. MyRule)が見付かるので選択

* Windowの下の方にあるsave buttonを押す

* configtoolを閉じる

以上で設定が反映される。

CFMの役割と自動化への取り組み

CFMの役割

BananaFMの取り組み (Amazon PollyベースのTTSの導入)を知って最初に思ったのは、地元のコミュニティFM局の大雨への対応だった。

1日積算で150mmに達する激しい降水が目下発生していて、気象庁から記録的短時間大雨情報とかが出ていても、それについて何ら触れることなく通常通り録音した番組の放送をしていた。幸いにも今回は目立った被害は出なかったが、ふと「こんな状態で本当に非常時に対応できるのだろうか？」と心配になったのだ。

3.11以降各地に設立されたCFM局は「防災」をその目的の一つしたものが多いし、地域によってはCFM局を従来の (コストのかかる)防災無線代わりに使おうと取り組んでいたりしている。その場合、日頃から使い慣れていないものを非常時に使い熟せるかは疑問だ。

ただし、ずっとそのCFM局を聞き続けていた訳ではないので、何処かしらのタイミングで触れられていた可能性はある。ユーザー (リスナー)側から見れば、他に幾らでも大雨などの情報を流しているメディア (或いはチャンネル)がある筈なので、必要なら積極的にそれを探しに行けば良いだけの話でもある。

そもそも、大雨など災害が発生している最中にできることは限られている。その後の避難或いは復旧や復興の局面でCFMが果たす役割が大きいのは分かるので、情報の速報性だけで評価すべきでない。

人手が少なく小さなCFMだからこそ整えるべき「仕組み」

地域に密着した (細かい)情報を随時流せる小回りの良さこそがCFMの最も良い所なので、全国はもちろん県域局でも取り上げにくい局地的な気象変化は大規模な災害発生時の訓練になると考えて積極的に流してほしいと思う。

そのような放送の姿勢やありかたが、徐々にではあっても地域住民やリスナーの「いざという時に頼りになる」という意識を作って、日頃から協力しようとか、或いは情報を提供しようという動機になる。

そのための仕組みは、別に自動化しなければ成立しないものではない。けれど、少人数で運用されているCFMの場合は特に、一人あたりにかかる負担が大きくなる。それを可能な限り低減して人でなければならない仕事に集中できる環境を作る、或いは人が対応するのに必要な時間を稼ぐ仕組み作りは、中長期的に事業を維持するための大きな武器になる。

Pollyでも、事前録音の音声でも構わないのだが、何かしら情報を受け取ったら自動的に放送に割り込む仕組みは、人手の少ないCFMだからこそ積極的に取り入れていく必要があると思う。

ぼくのかんがえたさいきょうの災害時放送

架空の豪雨災害を例に、CFM局が災害時果たすべき役割について考えてみた。

災害発生前

* 人員の確保
* 気象情報 (大気の状態が不安定、etc)を伝える
* 避難或いは安全確保について伝える
* 無理のない範囲での情報提供を呼び掛ける (リスナーにも、提携している他業種や行政にも)

災害発生直前 (降りはじめ)

以下のアナウンス:

* 〜地区 (或いは〜市とか〜町)で大雨が降っている

* 一通りの注意事項テンプレ (田畑や川を見に行かないとか外に出ないとか)
* 気象庁が出すであろう記録的短時間大雨情報や土砂災害警戒情報

災害発生

明らかになった情報をまとめつつ随時流す:

* (大抵は提携なり出資している筈の)地域行政機関が出すであろう避難に関する情報

* 開設されている避難所の情報、或いは安全確保に関する情報

* リスナーや警察・消防からの被害情報 (道路の冠水とか通行止めとか)

避難〜復旧

何かしら被害が発生し、中長期的に避難などが必要になった場合:

* 停電などライフラインに関する被害と復旧に関する見通し
* 保険金や見舞金の支払いに関する情報
* 公共料金や税金などの猶予の情報

* 相談先がどこにあるか

Banana FMにおけるAWS Pollyの応用事例に見るコミュニティFM局の今後

和歌山県のコミュニティFM局「Banana FM」が、7/31からAmazonの提供するクラウドベースのテキスト読み上げサービス「Polly」(cf. [よくある質問 - Amazon Polly | AWS](https://aws.amazon.com/jp/polly/faqs/))を利用した「ナナコ」による放送をスタート (cf. [人工知能　ナナコの放送が始まりました｜Banana FM 87.7MHz](https://877.fm/new.php?id=94))。

慢性的に人手不足だったり、仮にそうでなくても様々な問題から24/7な対応が難しかったりする小規模なCFM局は、BananaFMの取り組みを参考にして似たような手段を取るんじゃないかと。

緊急地震速報にしても、特別警報にしても、避難に関する情報に関しても、深夜とか祝祭日とか年末年始とかに関係なく起こりうる事態すべてに、地方の小さいCFM局が対応するのは本当に難しいと思う。だからこそ、情報が出たら人間が居なくても (或いはワンオペ状態でも)自動的に流す仕組みが必要で、それとPollyのようなtext-to-speech serviceは相性が良い。

そのうち、Twitter上のbotみたく、24/7でTTSが喋り続けるラジオなんてものができたりするんだろうか (或いはもうあったりするのかも)。

非常時の情報収集手段としてのラジオ

非常時の情報収集手段としてのラジオについてちょっと考えてみる

なぜスマホだけではだめか？

東日本大震災とか、近年多発している豪雨災害とかでも、放送による情報入手で一番確実なのはラジオだと思っている。その理由は大きく2つあって、1つ目は原理的に輻輳が発生しない放送であること、2つ目は消費電力が小さいので長時間の利用が可能なこと。

スマートフォンは通信手段にもなるし、(機種によっては)ワンセグも見れるし、アプリを入れておけばラジオ番組も聞けるし、ライトにもなるしと万能だ。万能な物は日常生活では持ち物が減るなど利点が多いが、非常時は少々勝手が違ってくる。

一番の問題は電源で、モバイルブースター (大容量バッテリー)も随分普及したが、それでもバッテリーの持続時間が十分とは言えない現状がある。生存性を考えると、最低限、明り (ライト)とラジオは別口で専用品を持つ方が、機能別にデバイスを分けられる (なくしたり壊したりすることへの抵抗性)点でも、バッテリーの持ちの点でも望ましい。

理想的な電源

非常時に確実に使えることを考えると「電源が何か」はとても重要なファクターだ。非常用持ち出し袋に入れておいたラジオや懐中電灯が電池切れで使えない、なんてケースは枚挙に暇がない。電池が切れているだけならばまだマシだが、場合によっては液漏れによって故障している場合すらある。乾電池は抜いて別に保管しておくことを勧める。

ラジオで言うと、最も入手性の良いAA×1で長時間聞けるのが理想的ではある。そう言う意味で、容量は大きくても入手性の悪いD (たぶん最も悪いのはC)より、AAやAAAを電源にするのは理に適っていると思う (応用範囲も広いし)。

ちなみに、手元にあるICF-801はC×3だが、スペーサと金属製のゼムクリップ (これがないと導通しない)を使ってAA eneloop×3で運用している。

持ち歩きに向いたカードサイズのラジオ (SONY ICF-R351とか)では、AAA×1或いはAAA×2が標準的である。

日常的に使ってこそ、非日常でも頼りになる

あと重要だと思うのは、日常でラジオ (のハードウェア)を使う、ラジオを聞くことだと思う。非常時に役立つからと言っても、日頃から支えているリスナーがいなければそもそも事業として立ち行かない。また、どの局でどんな情報が得られるのか傾向を掴んでおくと情報の取捨選択もやりやすい。

東日本大震災の時は特に酷かったが、どこもかしこも自粛ムードの中で、延々と災害の情報とACのCMばかり見せられ聞かされるのは、例え直接的な被害がなくとも気が滅入る。全く関係ない日頃の番組や、音楽を聞きたくなる。そういう時に、複数のチャンネル (複数の局、時間帯、或いはメディア)を知っていることは強みになる。

SONYのラジオICF-801がdiscontinuedな模様

SONY (製造は下請けである十和田オーディオ)の日本製ラジオであるICF-801 (cf. [ICF-801 | ラジオ／CDラジオ・ラジカセ | ソニー](http://www.sony.jp/radio/products/ICF-801/))が生産完了 (discontinued)っぽいと今更ながら知った (7/18頃に発表されていた？)。

以下のページでICF-801に「生産完了」のマークがついていると確認できる → [AMラジオの番組がFM放送でも聴ける ワイドFM（FM補完放送）！ | ラジオ／CDラジオ・ラジカセ | ソニー](http://www.sony.jp/radio/radio_sony/fm/)

このモデルのように長く生産されて「時代によって証明されている」モデルは細々とでも続けて欲しいと思ってしまうけれど、企業的には儲けが出なければどうしようもないって所なのだろうか。

後継機種とされているICF-506 (cf. [ICF-506 | ラジオ／CDラジオ・ラジカセ | ソニー](http://www.sony.jp/radio/products/ICF-506/))では、基本的な操作体系に変更はないようだが、部品点数削減のためかAM/FM切り替えスイッチに電源機能が統合されていたり、表示板のバックライトが無くなっていたりと、合理性は理解できるが「なんだかなぁ」と思う点がある。一方で、電源がC×3ではなくAA×3になっている点は、稼働時間が減りはするものの、電源の入手性という点から堅実な改善点だと思う。

カードサイズのシンセサイザーチューニングラジオICF-R351もいつの間にやらカタログから消えているし (後継機種はICF-R354MかSRF-T355あたり？)、世代交代は進んでいるんだなと。SRF-T355は、ワンセグの音声が受信できるXDR-63TVと共通点が多いようで、一度使ってみたい気はする。

fcitx-skkで「ゐ」や「ゑ」を入力する方法

defaultの変換テーブルでは:

* xwi → ゐ (ヰ)
* xwe → ゑ(ヱ)

fcitx-skkはlibskkを利用しているので、defaultのかな変換テーブルは、/usr/share/libskk/rules/default/rom-kana/default.jsonにある。これを見るまで入力できることすら分からなかった。

このmappingが気に食わなければ、適当な場所にcopyして内容を変更した上でそれを使うように設定すればoverrideできる (cf. [fcitx - Omong Kosong Lagi](http://www.lapangan.net/omongkosong/tag/fcitx/))。

ちなみに、fcitxってどう読むかご存知だろうか。ファイティクス、だそうな。

Raspbianで起動時にscriptを自動実行させる

Raspberry Pi 3 Model B (RasPi3)で部屋のLED照明とか、RasPi3自身の冷却ファンのPWM制御とか、室温の計測&loggingをさせている。それらのscriptを起動時に自動実行させたくなったので調べてみた所、以下のwebpageがとても参考になった (というかそのものズバリ)。

* [Raspberry Piでプログラムを自動起動する5種類の方法を比較・解説](http://hendigi.karaage.xyz/2016/11/auto-boot/)

採用した方法と理由

題にもあるように5つの方法が紹介されているが、個人的な用途やpros/consを考えると
cronのjobとして登録する方法が一番のお勧め。

* 登録と削除がcrontab -eで出来て楽
* 起動するscriptはuser権限で起動する

cronを使う時の問題点 (2017-08-25追記)

RasPi3はRTCを持たないので再起動時した直後など暫く時刻がズレていることがある。室温・湿度などをCSV fileに記録する際にはこれが問題となり、本来時系列順であるべき所がいきなり時間が戻ったりする。

19:01:03 ...
19:01:04 ...
18:30:33 ... <--- ここから...
...
18:30:52 ... <--- ここまでおかしい
19:03:12 ... <--- NTPで補正された
19:03:13 ...

cron側でNTPで時刻が補正される迄実行しないようにできれば一番良い。試してはいないが、systemdを使っているのだから依存関係を適切に設定すればNTPの実行後にcronを立ち上げられるような気もする。

取り敢えずsensorから値を取得するscriptの冒頭で、現在時刻とlog fileのmtimeとを比較して、現在時刻がmtimeよりも前 (eg. 現在=16:30でmtime=17:00)なら異常と判断してNTPによるsyncを待つようにした。

発展

もしこれで足りなければ (super userで動かしたいとか)、/etc/rc.localに細工 (exit 0の前あたりに追記)する方法を取る。

正当なやり方はsystemdのserviceとして登録する方法なんだろうけど、たかが小さなscriptを自動実行させたいってだけであんな長ったらしい設定fileを書くのは面倒すぎる。

補足

検索時に気になったのは、あちこちに残っている古い情報が検索の上位に出て来ること。例えばRaspbianのdefault init systemがsystemdに移行したとかの事前情報が無いと、上手く起動しないとか、設定fileが無いとか、無駄に混乱する原因になりそう。