1. 音声認識とフロー体験
非同期音声会議
ラジオ番組支援システム
「音声インタフェースシステムの
効果的設計と評価に関する研究」より
西本卓也（東京大学）
2011-01-11
1

2. 研究の背景[第1章]
 インタフェース技術の発展
 スイッチ、キーボード、マウス、タッチ操作、3D-CG, ポストPC, ...
 音声：音声認識、音声合成、音声対話、擬人化エージェント
 課題：成功する事例は限られている
 技術は完璧ではない
 誤認識を起こすのは音声認識だけ？
 さまざまなモダリティの役割を適切に割り当てることは難しい
 新しい技術は新しいバリアを作ることもある
 Graphical User Interface と視覚障害者
 Raman (1997) Auditory User Interface 単純なモダリティ置換では不十分
 要求
 インタフェースの設計者・開発者のための「方法論」
 その「方法論」の有効性の証明、音声技術への適用
2

3. 背景：音声認識技術の原理と構成
 音響的・言語的に最も可能性の高い単語列を出力する
 隠れマルコフモデル(HMM)／ベイズ決定則／N-gramモデル
 課題：頑健性，未知語，「完璧ではない」
音声データベース テキストデータベース
学習 学習
音響モデル 発音辞書 言語モデル
入力音声 認識結果
音響分析 探索
~ P( X | W ) P(W )
W = arg max P(W | X ) = arg max
W W P( X )
3

4. 背景：テキスト音声合成技術(TTS)
 大量の音声データによる統計学習アプローチの成功
 課題：聞きやすさ，テキスト解析，「完璧ではない」
漢字かな混じり文
テキスト解析 合成単位選択 音声合成単位
読み，構文情報，アクセント型
音声信号処理
韻律制御
音声信号
読み，基本周波数パターン，
継続時間長，パワーパターン
4

5. インタフェースの理論 [1.2節]
 行為の3階層モデル [Rasmussenn]
 技能ベース、規則ベース、知識ベース
 人間の情報処理特性モデル [Card et.al.]
 知覚系、認知系、運動系
 数値的に明確化 べき法則、Fitts's Law
応用:Macのメニュー
 行為の7段階モデル [Norman]
 実行の淵
 目標を立てる、意図を形成する、 心理的
行為系列を特定化する、行為を実行する 実行の淵 世界
 評価の淵
 システムの状態を知覚、状態を解釈、 物理的 評価の淵
状態と目標を比較評価 世界
 道具型と秘書型
5

6. 提案：インタフェースの原則 [1.3節]
 インタフェースの基本原則 [小林1993] [西本1994]
 操作労力：位置移動最少、指定操作回数最少、指定操作容易性
 システムの透過性：理解容易性、手順連想容易性、フィードバック
 頑健性：誤入力防止、修復容易性
 インタフェースの構成原則 [小林1993] [西本1994]
 初心者保護、熟練者優遇、上級利用移行支援
 インタフェースの導入原則 [西本2008]
 有用性：必然性、動機付け、発見支援
 適合性：ユニバーサルデザイン、状況の考慮、邪魔をしない
 妥当性：妥当な評価、反復的な改良
原則そのものは特定の手段に依存しない主張
6

7. 音声認識：動機付けと楽しさ [西本1999]
 音声認識ゲームを用いた実験（被験者10人）
 さんすうのおけいこ（暗算ゲーム）
 あー言えばこー言う（フリートーク）
 順に述べよ！（記憶クイズ）
 いずれも「ドキュメントトーカ V3」の付属ソフトウェア (Windows 95対応)
 質問「音声認識システムを楽しいと感じたことがありますか？」
 回答 はい：7人 いいえ：3人
認識率が低くても
楽しめる人がいる
認識率が高くても
楽しめるとは限らない
7

8. フロー体験モデル
 チクセントミハイ1975 による「動機付けと楽しさ」のモデル
 没入の経験／「主体的に流れている」感覚
 挑戦と技能が均衡した状態 → 楽しさ
 技能が低いと不安 high
 技能が高いと退屈
 能力を必要とする 挑 不安 フロー
挑戦的活動が必要 戦
 フローをもたらす体験
 チェス，山登り，ダンス 無感動 退屈
 仕事：外科手術
技能 high
 ネットサーフィン
 BBS・チャット参加
 「遊びだから楽しい」とは限らない
8

9. フロー体験の構成要素
 課題を達成できる見通し
 行為への意識の集中
 明確な目標
 直接的なフィードバックの感覚
 深い没入状態
 自分の行為を統制しているという感覚
 自己と対象の融合（自己意識の消失）
 時間経過の感覚の変化
9

10. 自己目的性の性質
 音声認識を使っている感覚は各体験にどれくらい似ている？
 5段階評価、各被験者における順位を平均
 友情とくつろぎ：「いい音楽を聴く」など
 危険と運：「サメのいる海に潜る」など
 問題解決：「クイズを解く」など
 創造：「何か新しいものを設計・発見する」など
 目立つ：「大勢の観客の前で演技をする」など
 競争：「競争して走る」など
 結果
 問題解決 創造 目立つ → 類似性高い
 演技＝表現活動とも類似
 友情とくつろぎ 危険と運 競争 → 類似性低い
 「システムを親しみやすくする手段」ではない？
10

11. 音声認識における前向きな挑戦
 感じたことがある：7人 ない：3人
 なかなか認識してくれないとき
 発音やアクセント、リズム、高さを変えてみた
 何度も誤認識されたときの再入力
 だだっ子に言い聞かせるような感じ
 異国の人に向かって話し掛けている感じ
 音声認識に失望したり腹がたったことは？
 発音が悪いのでうまく認識してくれない
 自分の喋り方にがっかりした
 「問題解決」としての音声認識
 うまく認識されないときの試行錯誤＝自分に対する不満
11

12. 音声認識を「楽しむ」ためには
 認識性能が悪いことは負の要因ではない
 うまく使うための知的で前向きな努力
 フロー体験ありと回答した5人：音声認識を楽しんだと報告
 時間感覚の変化，行為の統制，フィードバック
これらのうち2つ以上の経験がある
 自己の行為の統制
 質問：自分の操作に対して明確なフィードバックが
得られていると感じたことがありますか？
 「こんな風に発音した方が認識されやすいだろうなと
意識してしゃべって、それが当たっていると感じたとき」
 「自己の行為の統制」感覚→音声認識におけるフローの存在
 行為の統制を支える「インタフェースの透明性」
 インクリメンタル音声検索の試作
12

13. 非同期音声会議システム [第3章]
リアルタイム型 非同期・蓄積型
ラジオアーカイブ
・・・
1way インターネットラジオ
音楽配信
・・・
ボイスチャット
2way 提案メディア
インターネット電話
・・・ ・・・
・・・
・・ 複数の人間が時間を共有せずに
・
音声で相互に発言し
会話をできるメディアの実現
13

14. 試作したAVMシステム
 Voyager: ユーザエージェント
 Windows上で動作／全二重録音再生機能
 Voxer: メッセージ受信サーバ／対話再生サーバ
 Windows／Perl上で動作
 データベース登録
 再生音声作成
ユーザ 送信
サーバ
メッセージ受信サーバ
登録・蓄積
クライアント
要求
録音／再生
対話再生サーバ
再生メッセージ作成
送信
14

15. 肉声によるメッセージの利用
 目的：文章入力のための音声認識の有用性を示す
 使いやすさ？／バリアフリーに貢献？
 背景＝1990年代後半：PC用音声認識（ディクテーション）ソフトの実用化
 2009年ごろ～：iPhone用音声入力Twitterクライアントの実用化
 着眼点：音声と文字によるコミュニケーションを再考
 「音声」が捨てられているために起きる失敗？
 操作労力の仮説
 肉声の録音は，キーボード文字入力と比較して，少ない労力で情報伝達
 理解容易性の仮説
 文字では実現できない豊かなコミュニケーションが可能
 発言者の確認が容易 セキュリティ向上
 頑健性の仮説
 音声を聞くことを主目的にすれば不完全な音声認識結果にも価値はある
15

16. 話し言葉の技能の活用
 インタフェース構成原則（熟練者優遇）からの着想
 音声コミュニケーションの熟練者はどんな効率的な会話を？
 話し言葉の「技能」を生かすべき
 漸次性
 思いつくままに次々に喋るような話し方
 共有されている情報の省略
 認知的負荷の小さい表現
 オーバラップ発話や相槌
 オーバラップ発話を前提とした会話のモデル化
 会話における相槌の役割
 非同期型音声会議システム AVM の設計
 Asynchronous Virtual Meeting system
16

17. 音声の検索や流し読みの実現
 透過性原則の要求
 音声録音ソフトにおける「透過性」の配慮
 「レベルメーター」「録音ボタン」「再生ボタン」など
 「音声」の見えない「中身」を可視化する手段が必要
 「文字の掲示板」にはスレッド表示という可視化手段がある
 提案：音声認識の利用
 GUIでは音声メッセージを文字のように操作
 音声認識は聞きたい音声を選ぶための手段
 音声で録音されたメッセージを音声で再生
17

18. 音声メッセージの相互参照
 非同期型メディアによる双方向的な議論
 発言の双方向的編集行為が不可欠
 例：読んだ発言の一部を引用しコメントする
 どの発言に対する返答であるか
 発言のどの部分に注目しているか
 オーバラップ発話を相互編集の代替として利用
 どの発言に対して、割り込みが行われたか
 発言のどの部分の再生中に、割り込みが行われたか
 音声再生中に自由なタイミングで割り込み(barge-in)を許す
 日常会話から類推しやすい操作体系
 メッセージの関連付けをユーザに委ねる
18

19. メッセージのツリー構造
 始終端検出により区切られた音声
 その音声に付随する付加情報
再生音声 おはよう。今朝も冷えますね。ところで・・
返答音声 おはよう
そうですね。
 音声の録音と同時に、再生音声との
時間的関係を示すリンク情報が追加される
そういえば、プロ野球の人数は？ わかる？
付加情報
メッセージ
はい 60人程度だと。 たしか。
そうそう
近いといえば・・・
あんまり知らない。
19

20. 再生における問題点
 時間情報に忠実に再現：完全重ね合わせ
親メッセージ 会議ですが 延期になりまして それでですね・・・
子メッセージ はい そうなんですか
 複数のメッセージが重なり合うと聞きづらくなる
 親メッセージに割り込ませる形で再生
親メッセージ 会議ですが 延期になりまして それで
子メッセージ はい そうなんですか
 聞き取りやすさは大幅に改善
 相槌のような短い発話でも親メッセージが分断されるため聞きづらくなる
20

21. 再生方法の改良
 メッセージに属性を付加
 Insertメッセージ
 長時間の発話
 再生時に親メッセージに割り込む形で再生
 Overlapメッセージ
 相槌等の短時間の発話
 再生時に親メッセージに重ねる形で再生
親メッセージ 会議ですが 延期になりまして それで
子メッセージ はい そうなんですか
Overlap Insert
21

22. 録音方法の改良
 BISP(Barge In to Stop Playing)
 システム再生中にユーザが喋ったらそれを録音する
 「相槌」（短い言葉）を喋った場合
 システムの再生音声は止まらない
 ユーザの相槌は記録される
 「非相槌」（長い文章）を喋った場合
 システムは再生音声を止めてユーザの声を聞く
 ユーザの喋った文章は記録される
 相槌も打ちやすくなり、長い発言も安心して可能
22

23. 再生音声の作成手順
メッセージ構造 そういえば、プロ野球の人数は？ わかる？
はい
60人程度だと。 たしか。
overlap
そうそう
overlap
(1) ルートのメッセージを検索
近いといえば・・・
そういえば、プロ野球の人数は？
(2) 子となるメッセージを再帰的に検索、付加情報を元に親メッセージに挿入
ただしOverlapメッセージは無視する
そういえば、プロ野球の人数は？ 60人程度だと。 近いといえば・・・ たしか。 わかる？
(3) 元メッセージとの相対時間を元にOverlapメッセージを付加する
そういえば、プロ野球の人数は？ 60人程度だと。 たしか。 わかる？
わかる？ 近いといえば・・・ たしか。 わかる？
はい そうそう
23

24. 非同期音声会議：実験
 目的：文字BBSに対する非同期音声会議の優位性を示す
 課題：クイズを提示し、チーム内で議論し結論を出させる
 AVMとBBSの２つのシステムで実験
 AVMの音声認識にはViaVoice98(IBM)を使用
 録音された音声を実験者がリスピークしてその結果をシステムに登録
 研究室（京都工芸繊維大学）内の学生各５名１チーム
 実験後にアンケートを実施
次にあげるスポーツのうち、プロ選手登録数が1000人に
一番近いスポーツをあげてください。
競輪、競艇、騎手（中央競馬会）、ボウリング、サッカーJ1リーグ、
スノーボード、オートレース、野球、Vリーグ
24

25. 結果：音声と文字のメッセージの比較
 メッセージの分析結果
AVM BBS
被験者交替数 20 24
入力されたメッセージ数 71 24
1回あたりの平均入力メッセージ数 3.5 1
1メッセージあたりの平均文字数 32.4 235.7
全メッセージ文字数 2303 5657
 メッセージの特徴
 AVM：話し言葉的で短く簡潔、くだけた表現
例：「60人ちゃうかったっけプロ野球って」
 BBS：書き言葉的で長い文章
例：「70多くて80人が1球団の現役選手であると思います」
25

26. メッセージの文字数削減の効果
 AVMではより簡潔なメッセージでコミュニケーションが可能
60
全メッセージ中の割合[%]
50
40
AVM
30
BBS
20
10
0
0-50 51- 101- 151- 201- 251- 301- 351- 401- 451-
100 150 200 250 300 350 400 450 500
1メッセージ中の文字数[文字]
26

27. 実験結果からの考察
 AVMはBBSと同等に利用できた
 誤認識を含んだテキスト表示について
 誤認識を多く含んでいても音声メッセージの選択には非常に有用
 BISP機能
 発話区間検出の失敗が多く、使用感が低下
 本実験の用途での発言しやすさは達成されていた
 AVMによって
 [1] 話し言葉的な音声会話を非同期的に実現 … ○
 [2] 話し言葉の漸次性が活かされた … ○
 [3] BISPが発言しやすさに貢献した … △
 [4] 誤認識を含んだ認識結果も有効利用 … ○
 [5] BBSの代替として機能した … ○
27

28. AVM研究の貢献
 課題
 サーバに実装する音声認識の性能向上
 より会話しやすくするための改良
 既読発言の再生を省略する
 単語途中での分割を防ぐ
 電話回線や携帯情報端末による実現
 VoiceCafe(2000-2003) [video]
 科学技術振興事業団・平成11年度委託開発課題 （株）ネットイン京都 他
「コミュニティ形成支援機能を持つ音声会議システム」
 「ニコニコ動画」（2006年）
 投稿動画の特定の再生時間上にユーザがコメントをつけられる
 時間と空間を越えて擬似的にリアルタイム通信の感覚が得られる
 音声によるコメントは実現されていない
28

29. ラジオ放送支援システム [西本2006]
 ラジオ＝身近で重要なメディア
 特に高齢者や視覚障害者にとって
 コミュニティFM放送局が増えている
 地域に密着できる
 災害時に重要、行政からの期待
 課題
 地域情報の提供には取材が必要
 小規模な放送局では取材活動は困難
 地域住民による投稿が重要
 「オラビー(O'ra-be)」の開発
 IPA未踏ソフトウェア創造事業
 小規模なラジオ放送局の音声投稿番組を支援
29

30. ラジオ放送現場の要求
 求められていたもの
 音声投稿を電話で常時受付
 放送前に内容確認、簡単な操作で送出
 生放送中に差し替えや並べ替えを
 現場スタッフの要求
 放送中はさまざまな作業を同時に行う
 コンピュータの専門知識を持たない
 直感的で確実なツールが必要
30

31. 音声投稿の意義
 聴取者がリアルタイムに番組参加
 従来：文字＝ファクス、電子メール
 ニュアンスの欠落や変化のおそれ
 音声投稿
 より正確に、個性などを含めて豊かに
 災害時の速報性、状況報告、安否確認
 ソーシャルネットワーキング
 地域住民が肉声で近況を伝え合う
 高齢者や障害者の生活の質向上
 ラジオ番組の制作支援ツールの提案（2001年）
 番組は「枠」で構成されている
 枠を単位としたキューシート編集支援
 対話的な録音インタフェース／音声コマンド操作の有効性
31

32. 音声投稿：技術的課題の克服
 放送＝公共性
 内容の事前チェックが必須
 電話による生放送はチェック困難
 留守番電話
 送出までに煩雑な作業
 放送中に差し替えられない
 音声ファイルの編集
 波形エディタ＝時系列
 内容という単位で編集できない
 提案システム＝ドラッグとクリックだけによる操作
 素材のダウンロードと検聴
 キューシートの作成と再生
 再生中のキューシートの変更
32

33. 素材の構成と送出
投稿された音声素材
（アイテム）
CastStudio＝素材の構成と送出
生放送中に使えるシステム
33

34. 検聴シート
（インスペクタ）
へ移動
34

35. ダウンロード完了
35

36. トリミング操作
クリック
検聴（音声の再生）
36

37. 検聴済み素材
37

38. 色の変更が可能
38

39. キューシートに配置
39

40. クリック
キューシート再生
40

41. 再生が完了した
素材（アイテム）は
自動的に
リサイクラーに移動
41

42. ジングルなど
（ステッカーアイテム）
音声素材
ステッカー：事前に作成された効果音や音楽
投稿素材の前後や間に挟む
42

43. 電話投稿受付
 要素技術＝VoiceXML + PHP
 処理の流れ
 グリーティング
 番組アクセス番号入力
 マイクテスト開始
 マイクテスト終了と音量チェック
 録音時間の報告、レベルオーバー検出
 本番録音開始
 本番録音終了
43

44. 音声素材管理
 事前に内容をチェックし準備する
 到着した素材にメモをつける
 使用しない素材を非表示にする
 在宅でも自宅でも準備可能 （Webブラウザ）
44

45. 試験運用
 2006年2月埼玉県入間市
 コミュニティＦＭ局「ＦＭ茶笛（チャッピー）」
 「なべやかんの居留守放送局」
 2月3日から24日まで毎週金曜日
 16時～17時の生放送
 放送範囲：入間市を中心としたエリア
 周波数 77.7MHz
 インターネットにて再配信（放送後1週間）
 投稿（4週合計）
 電話投稿: 約60件
 ボイスレコーダー投稿: 約20件
45

46. まとめ
 担当ディレクターの評価
 素材管理＝事前に自宅で番組の準備
 送出操作＝葉書やファクスのような感覚
 色分けが有効
 急な変更にも対応できる（組み替えの自由度）
 キューシートによる連続再生
 次のコーナーの準備の時間が確保できる
 生放送に適している
 リスナーと時間・空間を共有できる
 ラジオの歴史はリスナー参加方法の歴史
 葉書 → ＦＡＸ → メール → オラビー？
 2010年 Twitter + Ustream 時代の到来
46