投稿者: nishimotz

ひさしぶりに研究会で発表をしてきました。

西本 卓也, 嵯峨山 茂樹, 藤原 扶美, 下永 知子, 渡辺 隆行:
“対面朗読者と視覚障害者の対話の分析とその応用,”
情報処理学会研究報告(SIG-SLP), pp.55-60, Feb 2007.
Nishimoto2007SLP02.pdf

内容は12月のWIT/HI研究会で東京女子大の学生に発表してもらった内容と
同じなのですが、原稿にはかなり手を加えました。
今回はヒューマン・インタフェース(HI)と音声言語情報処理(SLP)の共催研究会で、
特にHIの方から質問やコメントをいただいたのが嬉しかったです。

今回は、プレゼン用PCで Apache/PHP/PostgreSQL を動かしてデモをしました。
また、ALTAIR for Windows を動かして、スクリーンリーダーってこんなものです、
という紹介もちょっとしました。
かなり個性的なソフトですが、デモに使うには適していたように思います。
（本当は定番の「ホームページリーダー」などを使えばよかったのですが、
買ったはずのインストールCDが見あたらなかったのです。
新しいのを買わなくては、と思っています）。

自由と制約

話をわかりやすくするために

「自由ではないが自然なインタフェース」

というキャッチフレーズを使ってみました。
するとさっそく

「『自由』や『自然』とはどんな意味なのか定義してください」

という質問がありました。

今回の例で言うと、選択肢が最初から3つ用意されていて、この中から選んでください、
というのは「自由」とは言えません。
本当は「サラダはどれについていますか？」など、言いたいことを自由なタイミングで
自由に言えることが望まれます。
音声認識の語彙サイズを増やすのはそういうニーズに応えるためです。

私の話における「自然」とは、やりたいことを違和感なく、楽に、効率的にできる、
実用上満足できる、といったことです。本当は「自然」という言葉はぴったり
当てはまらないかも知れません。人間がやっているコミュニケーションの有り様を
そのまま実現することが「自然」とは限らない、と考えています。

こんな風に答えたのですが、後でこの質問をした方と話をしてみたら、
この方は Ruby on Rails の開発者が言っている

「制約が自由を生む」

というフレーズを連想したのだそうです。
Rails の「制約」はプログラマーに「余計なことを考えないで、
本当にやりたいことが楽にできるようになる」という意味での
「自由」を与えている、というわけです。

私の話では「自由」をむしろ「複雑さをもたらすもの」として
否定的に扱っていましたが、
私の話の中での「自由ではない」という部分が
Rails の「制約」と同じ意味になるのだと思います。
「制約があるから楽になれる」というプログラマーと、
「自然な選択肢を与えれば楽に使える」という今回の私の話は、
似ているように思います。

逆に、音声対話システムに関する研究でしばしば
「何を言えばいいか分からないから使いにくい」
というユーザの意見が紹介されているのは、
「制約が足りないことの不自由」なのかも知れません。

フォーム選択操作の詳細

視覚障害者がPCを使うためのスクリーンリーダーについての
具体的な質問をいただきました
（WITと違ってそういう質問もあるだろうと思ったのです）。

「お気に入りの選び方の詳細」はどうなっているのですか？

例えば73種類のお弁当をリスト表示して、
ひとつずつ1から順番に読み上げていきます。
ウェブのフォームを音声ブラウザで操作する一般的なやり方としては、
項目の移動はカーソルキーの上下で行います。
それぞれの項目にチェックボックスがあります。
画面を読み上げるときに
「チェックボックス、チェックあり」のように読み上げます。
キーボードのスペースキーなどでON/OFFの切り替えを行います。

じゃあタイミングでユーザーは判断する、ということですね？

タイミングというべきかどうかは分かりませんが、
カーソルがその行にあり、その行が読み上げられたときに、
チェックボックスのON/OFF操作ができる、ということです。

詳細情報の聞き方

お弁当の場合は、中身を知っているものと知らないものがあると思いますが、
詳細な情報はどのように聞くことができるのでしょう？

クリックすると詳細が出てきます。
リンクがあるということは声の違いでわかります。
ただし、ウェブブラウザのポップアップを使っているので、
ユーザの好みや音声ブラウザの機能によって使い勝手は変わってきます。

研究会を振り返って

今回は
podcastle
(http://podcastle.jp/)
のグループの発表が注目されましたが、
実際に音声認識や音声対話のシステムを公開運用して改良を重ねる、
というアプローチが増えてきました。
それにつれて、
「音声対話システムにはインタフェースやデザインの要素が大切」
という認識も広まりつつあるように思います。

音声の研究コミュニティがそんなふうになっているときに、
今回私は「音声対話を分析することは有用だけど、
その成果は音声対話以外のシステムに役に立つ」
というような発表をしました。

そういえば音声認識の高度なパターン認識アルゴリズムは、
文字認識や画像認識や遺伝子解析などに使われつつあります。
「音声認識の技術はとても役に立つ。ただし、音声認識以外への応用に」
という皮肉も聞かれるくらいです。

音声対話のデザインやパターンについても、
似たようなことが起きるかも知れません。
音声対話システムに対して悲観的なわけではありませんが、
音声インタフェースの研究も、
人間同士の音声対話を模倣するだけでは行き詰まりそうな気がします。

一見、人間同士の会話と全然違うように行われるけれど、
とても習熟しやすく効率的なインタフェースで、
しかも「人間同士の音声対話の分析」から得られた原理が背後に隠れている、
といったことがあるように思えてきました。

そういうことを「自由ではないが自然」と呼んでいますが、
もっとふさわしい言葉を見つけたいと思います。

「基礎的な物事を勉強し直す」「安易に新しいことに手を出さない」という今年の抱負は、例えばこういうことだったりするが、年末年始に改めてPerlの勉強をした。

簡単なテキスト処理にはずっと昔から使っているのだが、最近の動向についていけてなくて。。

perldoc-jp のドキュメントを W-ZERO3[es] に入れて旅行中に読み、やっと言語コアの部分を読み終えた。

リファレンスとかモジュールとかの記法に目が慣れてきて、やっと中級者向けの参考書や雑誌記事が読めるようになった。

Windows + ActivePerl + Apache + Postgres + Eclipse (EPIC) という環境でさっそくいろいろ試している。

動いているプログラムをちょっとずつ拡張したいときに、１行か２行書き足すだけでやりたいことができる。

誰かが似たようなことをやってるのでは、と思えばネットで検索して情報を得られる。

面白そうなモジュールを探してインストールして試してみる。

やっぱり自分に合っているプログラミング言語だということを改めて認識した。

PHP で開発していて「ここから先はお手軽には書けない」という閉塞感を何度味わったことか。。

Perlが特に優れた言語だとは、いままで思っていなかった。

いや、いまでも言語そのものが優れているのかどうか、よくわからない。

Plagger のインストールをしながら、Linux の黎明期に味わった「インストールすることが自己目的的に楽しい」というあの感覚を久しぶりに思い出して、Perlというものがプログラミング言語というよりもOSのような存在に思えた。

Perlを巡る構造で重要なのはやっぱりコミュニティなのだろう。

Perlのある部分は「ガラクタの寄せ集め的言語」なのに、ある部分が「一貫性を重視したストイックでミニマルな言語」なのは、必ずしも先見性というわけではなく、むしろ「コミュニティのニーズを適切に反映してきた成果」だと思う。

僕が初めて触ったころの Perl はまだバージョン４だった。

そのことは C や sed や awk や sh を知っている人が、その知識を生かしつつ仕事を効率化するための言語だった。

改めて言語仕様を読み返すと、例外的なルールがいろいろあるにも関わらず、不自然さを感じない。

それは、実際に行われる仕事やユーザのことをよく理解して作られた仕様だったから、なのだと思う。

その思想は最新のバージョンにも反映されているように思われる。

そしてLinuxが成熟していく過程で有効に機能した（と思われる）コミュニティの構造に似ている。

言語仕様の策定にコンピュータやソフトウェアをビジネスとする企業や、公的な組織が入っていない。

• (a) オープンソースとして開発されるコア部分の開発者
• (b) アプリケーションやライブラリをバザール的に開発して提供するコントリビュター
• (c) コアとアプリをまとめて品質や互換性を確認して配布するディストリビューター

Linux: (a)カーネルの開発者 (b)GNUアプリケーションの開発者 (c) RedHatやDebianなどのディストリ

Perl: (a)Perl コアの開発者 (b)モジュールの開発者 (c) CPANというコミュニティ

ということになるだろうか。

Perl 6 の仕様に関する議論もちょっと読んでみたが、いかにも民主的に行われている、と感じる。

そんなわけで、今年は（久しぶりに） Perl に深入りしていきたい。