SICEワークショップ

先日、計測自動制御学会の「SICEライフサイエンス(生命,健康,医療,福祉)の現状と連携推進を探る」に参加しました。

午前中は、ブレインストーミングのような手法でSICE各部会の問題や今後の活動の方向性をまとめる、という場だったので、正直場違いだったかと思ったのですが、「私はSICE会員じゃないですが・・」「じゃあライフサイエンス部門に期待することを書いてください」みたいな感じで参加させていただきました。

使われたのは「ディズニーが会社を変える」(PHP研究所、2002年)に基づいて説明された「ストーリーボーディング」という手法。参加者全員がカードに自由な記述をして、それをホワイトボードや壁に貼り付けながら議論をしていく、というものでした。

本当は「どのようなライフサイエンスの研究がされているか」ということがわかるかと思ったのですが、そういう場にはならず、「SICEライフサイエンス関係者の皆様の興味や関心事」のマップが作られました。しかしその過程で、なんとなく現状も透けて見える、という感じの経験になりました。

いくつか気づいたことを書くと:

  1. WIT(福祉情報工学研究会)と問題意識や現状が似ている。例えば「組織が細分化された結果希薄になった横の連携の再構築が課題」「気持ちよさや負荷など人間の内面の測定に関心がある」「現場のニーズ発掘、医学や臨床の当事者との連携の場を求めている」など。
  2. 企画の立て方や進め方に見習うべき点あり。例えば、このストーリーボーディングの締めくくり方を「次のイベントの企画」「学会誌の特集号のテーマ」など具体的に設定して、ひとつの企画を上手に次の活動につなげておられる。
  3. 人脈と人柄。今回は産総研の小野さんのご尽力とのことでしたが、魅力的な企画に必要なものを改めて痛感しました。

それから、私がWITの幹事であることを名乗ったので、逆に「WITはどうして年6回も研究会を開催して盛況にできているのですか?」という質問を小野さんから受けました。「当事者の参加(情報保障)に配慮していること」「来ていただくだけでなく、見学会を企画するなど、こちらから出向く努力」を挙げておきました。

午後は「関連の学協会との連携を探る」というセッションでした。車いすの方もたくさん参加。ロボット、計測、制御といった分野の研究者の方々と、障害の当事者やリハビリ関係者の方々が、「どのような場があればうまく連携できるか」といった議論。私には不勉強だった分野のお話が多く、大変興味深く伺いました。

Knoppix と Ubuntu

Galatea for Linux の動作検証のために、いつも使っている Vine Linux とは違うディストリビューションを使ってみました。

USB メモリから起動する Knoppix 5.3.1 環境を作ったところ、Let’s Note で 3D が有効になり FSM が 24fps くらいで動作しました。GalateaTalk (gtalk) からのオーディオ出力で若干不都合があったり、ウィンドウマネージャ(compiz fusion)が FSM 関連で怪しかったり、いろいろ不満はありますが、USB メモリで OS ごと持ち歩けるGalatea が現実的になりつつあると感じました。

Knoppix で動いたので、同じく compiz に対応している Ubuntu Linux 8.04.1 (wubiを使用)で Galatea for Linux の動作検証を行いました。ただし3次元ウィンドウマネージャの動作を確認したら、GNOMEの設定で視覚効果を無効化した方がよいようです(FSM の不具合はこれで解決しました)。

Thinkpad の内蔵音源がうまく動かなかったですが、ALSA をアップデートするのは面倒だったので、ノートPCの内蔵音源を無効化してUSBオーディオを使ったところ、音声認識・音声合成の動作も良好でした。

SRM は Julius 4.0.x ベースになり、ALSA がデフォルトになりました。OSS で動かすためには以下の設定追加が必要でした。

[SRM/srm.init]
set Input.from = oss

最後にひとこと。Ubuntu には久々に興奮しました。ALSA の不都合が惜しいですが、ディスプレイ出力の切り替えなどノートPCに固有の機能もかなりサポートされており、全体的によくできていると思います。

VoiceXMLとRuby on Rails 続編

3月にVoiceXMLとRuby on Railsという記事を書きましたが、Ruby on Rails 2.0.2 で作り直してみました。

# routes.rb に追加 -> http://localhost:3000/weather/state1.vxml
map.connect ':controller/:action.:format'
# 001_create_region.rb
class CreateRegions < ActiveRecord::Migration
def self.up
create_table :regions do |t|
t.string :name
t.string :yomi
t.string :weather
t.timestamps
end
end
def self.down
drop_table :regions
end
end
# 002_add_test_data.rb
class AddTestData < ActiveRecord::Migration
def self.up
Region.delete_all
Region.create :name => '東京', :yomi => 'とうきょう', :weather => '晴れ'
Region.create :name => '横浜', :yomi => 'よこはま',   :weather => '曇り'
Region.create :name => '大阪', :yomi => 'おおさか',   :weather => ''
Region.create :name => '京都', :yomi => 'きょうと',   :weather => '晴れ時々曇り'
Region.create :name => '広島', :yomi => 'ひろしま',   :weather => '曇りのち雨'
end
def self.down
Region.delete_all
end
end
class Region < ActiveRecord::Base
end
class WeatherController < ApplicationController
def state1
# counter をセッションで記憶する 
if !session[:counter]
session[:counter] = 1
else
session[:counter] += 1
end
@regions = Region.find(:all)
end
def state2
if params[:region]
@region = params[:region]
@weather = Region.find_by_name(@region).weather
end
end
end
[state1.vxml.erb]
<?xml version="1.0" encoding="UTF-8"?>
<vxml version="2.0" xml:lang="ja">
<form id='ask'>
<field name='region'>
<prompt timeout='20s'>
<%= session[:counter] %>番です。
天気を聞きたい地域を、
<% @regions.each do |item| -%>
<%=h item.name %><% end -%>
から選んでください。
</prompt>
<grammar version='1.0' root='#region_rule'>
<rule id='region_rule'>
<one-of>
<% @regions.each do |item| %>
<item> <token sym="<%=h item.yomi %>" slot='region'> <%=h item.name %> </token> </item>
<% end %>
<item> <token sym='まいくてすと'>マイクテスト</token> </item>
</one-of>
</rule>
</grammar>
</field>
<block>
<submit next='<%= url_for(:action=>"state2") %>.vxml'/>
</block>
</form>
</vxml>
[state2.vxml.erb]
<?xml version="1.0" encoding="UTF-8"?>
<vxml version="2.0" xml:lang="ja">
<form id='answer'>
<block id='answer'>
<log>地域=<%=h @region %>:天気=<%=h @weather %></log>
<prompt> <%=h @region %>の天気は<%=h @weather %>です。<break /> </prompt>
</block>
<block>
<goto next='<%= url_for(:action=>"state1") %>.vxml'/>
</block>
</form>
</vxml>

以前は rxml で VoiceXML を生成してみたのですが、やはり vxml.erb の方がすっきりしました。

そして興味深いことに、同じコントローラーで html.erb も動かすことができそうです。

[state1.html.erb]
<html>
<body>
<p> <%= session[:counter] %>番です。 </p>
<% form_tag :action => 'state2' do %>
天気を聞きたい地域:
<select name="region">
<% @regions.each do |item| -%>
<option value="<%=h item.name %>"><%=h item.name %></option>
<% end -%>
</select>
<%= submit_tag "実行" -%>
<% end -%>
</body>
</html>
[state2.html.erb]
<html>
<body>
<p> <%=h @region %>の天気は<%=h @weather %>です。</p>
<%= button_to '戻る', :action => 'state1' %>
</block>
</body>
</html>

これまでISTCのマルチモーダル対話記述ワーキンググループで提案してきたアーキテクチャ階層:

  • 西本 卓也: “マルチモーダル対話システムのためのアーキテクチャ階層化,” FIT2006イベント企画「音声・マルチモーダル対話記述とその標準化」予稿集, Sep 2006. (PDF)

と対応させてみると、

  • 6層「データモデル」が ActiveRecord
  • 5層「タスク間制御」が Controller のアクション
  • 4層「タスク内制御」以下が View (html.erb または vxml.erb)

になっており、モダリティごとの View を統一的に記述する方法を見つけることが、4層と3層を分離して記述するためのステップになりそうです。ヘルパーメソッドやパーシャルなどの機能がその部品になるでしょう。また、コントローラーのモダリティ独立性という観点からも RESTful であることが重要だ思います。

音声対話と「もう一つの未来」

8月下旬に京都で行われる音声対話技術の講習会で、音声対話技術コンソーシアム(ISTC)が製作する Galatea Toolkit DVD-ROM が配付される予定です。私は主にLinux版に関する Toolkit の更新作業を担当しています。

SourceForge.JPのgalateaプロジェクトでは通称「IPAライセンス」で開発されたオープンソース成果物とその後継版を配付しています。私が開発している音声対話エンジンGalatea Dialog Studio (GDS) 2.2.2も300件以上ダウンロードしていただいているようです。

全てのモジュールを統合したISTCの成果物は講習会参加者およびISTC会員に配付される予定です。コンソーシアムの活動は本年度で終了するので、その後の開発を継続するためには、これらのツールに関するオープンソースコミュニティをもっと盛り上げていく必要があるだろうと思います。

以前この日記で考察した「Ruby on Rails による VoiceXML 開発」はまだ「今後の課題」のままなのですが、Ruby on Rails の「フルスタック」という特長はGDSにとっても重要ではないかと思います。GDS は Java で実装されているのですが、いずれ JRuby によって、アプリケーションとインタプリタのフルスタック処理系に手が届くだろうと展望しています。これは、そもそも HTTP と VoiceXML という技術によって音声対話システムをサーバ・クライアント型モデルに分離したという経緯を考えると、不合理に思えるかも知れません。しかし、その理由はそのまま「フルスタック環境である Ruby on Rails の利便性」と同じなのではないかと思います。

フルスタックという言葉からもう一つ思うのは、音声対話システムがうまく動かないときに、システムが依存している全てのモジュールの設定ファイルやログの確認を行うのは非常に複雑な作業である、ということです。将来的には、全てのモジュールが統一的なリモートロギングのインタフェースを備える必要があるだろうと思います。暫定的には、全てのモジュール(音声認識、音声合成、顔画像合成)の設定ファイルを対話マネージャが動的に生成し、GDS が各モジュールのログファイルを一元的に監視する、という方向を目指しており、今日もそのための作業をすこし進めました。

音声対話あるいは音声認識について、ヒューマンインタフェースの開発者・研究者の方々は「実用にならないまま過去のものになってしまった技術」という見方をお持ちかも知れません。その一方で音声認識の研究者の方々には「もう完成されており、後は使ってもらうだけの技術」という見方もあるのではないかと思います。

西本が今年1月に研究会で発表した

  • 西本 卓也,岩田 英三郎, 櫻井 実, 廣瀬 治人: “探索的検索のための音声入力インタフェースの検討,” 情報処理学会研究報告 2008-HCI-127(2), pp.9-14, Jan 2008. (PDF)

は、そうした現状における問題提起のひとつなのですが、この予稿の中で私が提案した「インタフェースシステムの導入原則」(下記、一部加筆)があります。

(ここから)

インタフェースシステムの基本原則および構成原則(西本 1996)を踏まえて,近年のインタラクション技術の動向を反映させ,また著者の経験を反映させるための再検討を行っている.

「基本原則」および「構成原則」の視点は引き続き有効である.そのうえで,インタフェースシステムを成功させるためには,アプリケーションそのものの選択や設計により深く関与し,システムをどのような状況に適合させ,どのように評価や改良を行っていくか,というプロセスが重要になっている.インタフェース原則を補完するものとしてこれらを暫定的にまとめたものが,以下の「インタフェースの導入原則」である.

「インタフェースの導入原則」

  • a.有用性の原則: システムが使用される現場における必然性を考慮して設計と導入を行う.ユーザに動機付けを与える心地よさ・美しさ・楽しさを盛り込む(エモーショナルデザイン(Norman 2004)).
  • b.適合性の原則: あらゆる年齢や能力の人々に対して可能な限り使いやすさを提供する(ユニバーサルデザイン).システムが使われる状況・環境を考慮する.ユーザ以外の人に悪影響を与えない.ユーザが行っている他のタスクに悪影響を与えない.
  • c.妥当性の原則: 妥当な時期に妥当な尺度で評価を行う.評価の結果を生かして反復的な開発・改良を行う.

(ここまで)

インターネットにまつわる日々の雑用(その多くは、メールを読んで、メールを検索して、カット&ペーストしてメールを送ったり、ウェブのフォームを埋めることだったりしますよね)が不毛に感じられることがあります。

GUIが普及してインターネットが普及したからこそ、いまのPC利用の状況は「当たり前」にしか感じられないのですが、たまたま「音声対話システム」がなかったにも関わらず「インターネットというインフラ」は実現してしまい、「人間がやっていた仕事をコンピュータに代行させたい」というニーズが爆発的に増加してしまった。結果的に、テキスト情報と視覚的インタフェースだけで「人間の代わりをしてくれる自動応答サービス」を実現せざるを得なくなった、とは言えないでしょうか?

音声対話システムは「起きるはずだった未来」あるいは「失われた未来」ではなかったでしょうか。。

もしも、音声対話システムが「もっと上手に」実現され普及していたら、我々は今日のようなメールとウェブのフォームから解放され、もっとスマートにインターネットを使いこなせていたのではないか、と思えてきました。

いや、「失われた未来」を取り戻すのは、まだ遅くないと思うのです。いかがでしょうか。。。