第10回　音声インタフェースとUX設計¶

この回の資料

📊 スライドを開く（HTML）
📄 スライド（PDF）
形式：オンライン同期回（Zoom・録画を後日公開）

オンライン同期授業¶

授業の目標¶

音声UIの歴史的発展を概観し、現在の多様な利用文脈を把握できる
オンデバイスASRとクラウドASRのトレードオフを技術・プライバシー両面から説明できる
エッジ推論における小型化手法（量子化・プルーニング・知識蒸留）の概念を理解できる
音声インタフェースのUX設計原則に基づき、アクセシブルなシナリオを提案できる

参加方法¶

この授業は、マイクでの発話が難しい方、声を出すことに困難を感じる方も含め、さまざまな参加スタイルで学べる設計になっています。

演習・全体共有はチャット書き込み・共有ドキュメント編集でも参加できます
発言は任意です。チャットへの書き込みは発言と同等に評価します
カメラのオン/オフは自由です
質問はZoomチャット・メールのどちらでも受け付けます
録画は後日公開します。自分のペースで視聴してください

進化の視点：会話の間（ま）は、言語を越えて似ている¶

10言語の自然会話を比べた研究では、発話の重なりや長い沈黙を避ける傾向が共通し、各言語の平均応答時間の全体平均からのずれがおよそ250ミリ秒以内と報告された。これは、個々の話者交替がすべて250ミリ秒以内という意味ではない（Stiversほか2009, PNAS）。

短い応答時間を説明する処理モデルでは、相手の発話中から応答を準備し、発話の終わりを予測することが重視される。ただし、言語間の共通性だけから、その仕組みの進化的起源が確定するわけではない（Levinson & Torreira, 2015）。

技術への接続：音声インタフェースの「自然さ」は、認識精度だけでは決まらない。応答の遅れと話し終わりの検出が、体験を大きく左右する。エッジ推論やストリーミング処理が重視されるのは、この時間の制約があるからである。

問い：応答が速すぎる音声アシスタントは、自然に感じるか。

授業の流れ¶

時間	内容
0〜10分	前回の振り返り・本日の概要説明
10〜45分	スライド講義（スライド1〜7）
45〜65分	演習（UX設計）
65〜80分	全体共有
80〜90分	小課題説明・質疑・まとめ

スライド講義¶

スライド1：音声UIの歴史と現在¶

電話の自動応答：IVR（Interactive Voice Response）¶

電話を使った自動応答システム（IVR）は、音声による案内とユーザー入力を組み合わせた代表的なインタフェースです。ここではDTMF入力を使う構成を例にします。音声認識を使うIVRもあります。

「1を押すとお問い合わせ、2を押すとご予約」といったキーパッド入力ベース
音声認識ではなく、DTMFトーン（プッシュ音）で入力を識別
主に企業の電話窓口・銀行照会・航空券予約に普及
問題点：分岐が深くなると迷子になる「IVRの迷宮」現象

音声ダイアログシステム：1990年代〜2000年代¶

業務領域や認識文法を限定した音声認識・対話システム
VoiceXMLは、音声・DTMF入力、合成音声・録音音声の出力、対話の流れを記述する規格であり、音声認識モデルの名称ではない
コールセンターへの導入拡大
VoiceXML 2.0は2004年にW3C勧告となった（規格本文）

スマートスピーカー・仮想アシスタント：2010年代〜¶

製品	年	特徴
Siri（Apple）	2011	iPhone 4Sへの統合・音声による操作
Google Now	2012	検索連携・文脈理解
Alexa（Amazon Echo）	2014	ウェイクワードで起動する据置型音声アシスタント
Google Assistant	2016	対話型アシスタント。AlloやGoogle Homeなどと連携
ChatGPT音声モード	2023	ASR・LLM・TTSを組み合わせた音声対話

年は代表的な発表・導入時点を示す。以後の機能追加やサービスの継続状況とは区別する。2023年のChatGPT音声機能も、後続の音声を直接扱うモデルとは構成が異なる。参考：SiriのiPhone 4S導入、Google Assistant発表、ChatGPT音声機能の発表。

マルチモーダルUI¶

音声＋タッチ＋視線＋ジェスチャーの統合
車載インフォテインメント、AR/VRヘッドセット
音声＋画面表示の組み合わせ（Echo Show、Google Nest Hub）

考えてみよう：IVRと現代の音声アシスタントの最大の違いは何でしょうか？（チャットに書いてみてください）

スライド2：音声インタフェース設計の原則¶

基本原則：ユーザー中心設計（UCD）¶

音声UIでは、周囲の音、発話できる場所かどうか、応答を聞いて保持する負担など、利用文脈・状況・認知負荷を考慮する必要があります。

エラーリカバリ設計¶

音声入力では、雑音や話し方による認識誤りが起こりうるため、訂正・やり直し・別の入力手段への切り替えを設計します。

ユーザー：「明日の天気を教えて」
システム：「明後日の天気ですね、東京は晴れです」（誤認識）
ユーザー：「違う、明日」
システム：「失礼しました。明日の天気ですね。東京は曇りのち晴れ、最高気温18度です」

設計のポイント - 認識結果の読み上げ確認（コンファメーション） - 短い訂正インタラクション - 「もう一度おっしゃってください」フレーズの最適化 - 失敗が続く場合は、別の入力手段や担当者への切り替えを案内する。回数は用途・ユーザーテストに基づいて決める

確認ダイアログの設計¶

明示的確認（Explicit Confirmation）：
「○○を削除します。よろしいですか？」→ 重要・取り消し不可操作に使用

暗黙的確認（Implicit Confirmation）：
「明日の東京ですね。天気は……」→ 応答に条件を織り込み、必要なら訂正できるようにする

マルチターン対話¶

文脈の保持：前のターンの情報を活用
省略への対応：「じゃあそっちに変えて」という省略発話の解釈
対話状態管理：どの情報が埋まっていてどれが未確認かを追跡

ターン設計の原則¶

簡潔な応答：音声だけでは一覧しにくいため、重要情報を前半に置き、繰り返しや画面確認も可能にする
選択肢の整理：一度に提示する選択肢を少数にし、項目の長さ・文脈・画面の有無に応じて調整する
プロンプトの明確化：「どうぞ」より「何を検索しますか？」
沈黙のハンドリング：ユーザーの発話速度や間に対応できるタイムアウトと再プロンプトを設ける

参考：Googleの確認・訂正の設計ガイド。

スライド3：オンデバイスASRとクラウドASRの比較¶

アーキテクチャの違い¶

【クラウドASR】
音声データ → インターネット → クラウドサーバー（認識モデル） → テキスト → 端末

【オンデバイスASR】
音声データ → 端末内のプロセッサ（認識モデル） → テキスト（外部送信なし）

比較する際の条件¶

指標	クラウドASR	オンデバイスASR
応答までの時間	通信、サーバー待ち時間、推論、発話終了検出などに依存	端末性能、推論、発話終了検出などに依存。通信の往復は不要
ストリーミング認識	対応するモデル・サービスなら可能	対応するモデル・実装なら可能
オフラインでの認識	通常は不可	モデル・必要データが端末内にあれば可能
認識精度・対応言語	使用するモデル・学習データ・入力条件による	使用するモデル・学習データ・入力条件による
計算資源	サーバー側の資源を利用できる	端末のメモリ・電力・演算性能による制約がある

「ネットワーク往復時間」「文字起こし確定までの時間」「返答音声が出るまでの時間」は異なる。比較では計測の開始点・終了点、モデル、端末、回線、入力音声をそろえる。端末内で認識できても、天気検索などの機能がネット接続を必要とする場合がある。

プライバシーとセキュリティの観点¶

クラウドASRのリスク

音声データが外部サーバーに送信される
「常時マイクオン」デバイスでの意図しない録音リスク
誤ってウェイクワードを検出した音声が送信される可能性
サービス提供企業による学習利用（契約内容次第）
セキュリティ侵害時の音声データ漏洩リスク

オンデバイスASRのプライバシー上の特徴

認識処理に伴う音声の外部送信を避けられる
ただし、文字起こし結果の送信、端末内への保存、バックアップ、別サービスとの連携はアプリ全体の設計に依存する
利用分野への適合性は、オンデバイスかどうかだけでは決まらず、データの利用目的・保存・アクセス制御なども含めて判断する

ウェイクワードの待受、音声の保存、外部送信は別の処理である。「マイクが有効」と「すべての音声を常時送信している」を区別する。

データ送信リスクの評価フレームワーク¶

音声UIを評価する際の問い： 1. どの音声データが、いつ、どこに送信されるか？ 2. 送信データは暗号化されているか？ 3. サーバー側でデータはどう保存・利用されるか？ 4. ユーザーはオプトアウトできるか？

スライド4：エッジ推論 — 小型化の技術¶

ASRモデルを端末のメモリ・電力・速度の条件に収めるために、モデルの小型化や推論の最適化を用います。

量子化（Quantization）¶

概念：重みや活性値を、float32などからint8・int4などの低ビット表現で近似する

float32：1パラメータ = 32ビット（4バイト）
int8   ：1パラメータ = 8ビット（1バイト）→ 重みの値の保存領域は理論上1/4
int4   ：1パラメータ = 4ビット（0.5バイト）→ 重みの値の保存領域は理論上1/8

トレードオフ - 重みの保存領域を削減できるが、スケール値・未量子化部分・実行時メモリも必要 - 速度改善や精度への影響はモデル・量子化方式・実行ハードウェアによる。精度低下が常に小さいとは限らない - 量子化誤差（Quantization Error）の管理が重要 - Post-Training Quantization（PTQ）vs. Quantization-Aware Training（QAT）

プルーニング（Pruning）¶

概念：選んだ基準で重要度が低いと判断した重み・チャネル・層などを、ゼロ化または削除する。重みの大きさは基準の一例であり、重みとニューロンは同義ではない

密なモデル（Dense）→ 疎なモデル（Sparse）
例：100個の重みのうち70個をゼロ化 → 非ゼロの重みが30個
（非構造化の場合、元の行列の形や密な保存形式はそのままの場合がある）

種類 - 非構造化プルーニング：個々の重みを削除（スパースな行列） - 構造化プルーニング：チャネルやレイヤー全体を削除（通常の密な演算でも小型化の効果を得やすい）

重みをゼロにしただけでは、通常の密な演算は速くならないことがある。疎な保存形式や対応する演算実装が必要になる。参考：PyTorch量子化解説、PyTorchプルーニング教程。

知識蒸留（Knowledge Distillation）¶

概念：大規模モデル（教師）の「知識」を小規模モデル（生徒）に転移

教師モデル（大規模な音声認識モデル）
    ↓ 教師の出力分布・生成した文字列などを学習信号にする
生徒モデル（小規模な音声認識モデル）

これは蒸留の一般的な概念図である。公開済みWhisper tinyがlarge-v3から蒸留されたモデルという意味ではない。

なぜ有効か？ - 出力確率を使う蒸留では、正解ラベル（One-hot）だけでなく、教師が与える他の候補との相対関係も学習 - 例：「犬」の画像に対し、教師は「犬:90%, 狼:8%, 猫:2%」→ この分布を学ぶ - 小規模モデルの性能改善が期待できるが、効果は教師・生徒・データ・目的関数による（知識蒸留の原論文）

その他の小型化技術¶

技術	概要
アーキテクチャ設計（Architecture Design）	層数・幅・演算などを見直して効率的なモデルを設計
重み共有（Weight Sharing）	類似した重みをグループ化して共有
低ランク近似（Low-Rank Approximation）	行列を低ランク行列の積で近似
Neural Architecture Search（NAS）	ハードウェアに最適なアーキテクチャを自動探索

スライド5：代表的なオンデバイスASRプロジェクト¶

whisper.cpp（CPU・GPUなどで動作）¶

概要 - OpenAIのWhisperモデルをC/C++で実装したオープンソースプロジェクト - CPUのみの推論に加え、対応環境ではGPUやNPUによる高速化も利用できる - GitHub: ggml-org/whisper.cpp

特徴

項目	内容
対応プラットフォーム	Mac, Linux, Windows, Raspberry Pi, iOS, Android
対応モデル	tiny, base, small, medium, large（精度とサイズのトレードオフ）
量子化対応	4-bit量子化で大幅メモリ削減
認識精度	使用するWhisperのモデル、量子化、復号条件に依存。large-v3と常に同じ出力ではない
ライセンス	MIT（商用利用可）

Whisper tinyモデルの規模感

パラメータ数：3900万
モデルファイル：約75 MiB（公式READMEの非量子化tinyの目安）
実行時メモリ：モデルファイルより大きい
認識速度：端末・モデル・量子化・スレッド数・音声長・復号条件に依存

推論時間を報告する場合は、音声長に対する処理時間の比（RTF）などを、実行条件とともに示す。RTFが1未満なら、録音の長さより短い時間で処理したことを表す。

Vosk¶

概要 - Kaldi音声認識ツールキットベースのオフラインASRライブラリ - Python・Java・C#・Node.js等、多言語バインディングを提供 - 日本語モデルも公開されている

特徴

項目	内容
モデルサイズ	50MB〜2GB（用途に応じて選択）
ストリーミング対応	リアルタイム認識可能
日本語対応	vosk-model-small-ja-0.22 / vosk-model-ja-0.22など
対応プラットフォーム	Linux, Mac, Windows, Android, iOS, Raspberry Pi

Voskの強み - 組み込みシステムへの統合が容易 - 語彙や認識文法の変更は、モデル・辞書・グラフの構成に依存する。任意の未知語を即座に追加できるとは限らない - API本体はApache 2.0。配布モデルのライセンスはモデルごとに確認する（公式モデル一覧）

Appleのオンデバイス処理とクラウド連携¶

iOS 15（2021）の発表では、A12 Bionic以降の対応機器などで、音声モデルをダウンロードしてSiriの音声認識を端末内で実行する構成が紹介された。対応は機器・言語・機能に依存する。
音声認識が端末内でも、問い合わせへの応答やオンライン情報の取得まで、すべて端末内で完結するとは限らない。
Apple Intelligence（2024発表）も、オンデバイスモデルと、Private Cloud Computeによるサーバーモデルを組み合わせる。LLM推論がすべて端末内という説明は正しくない。

参考：iOS 15発表、Appleの端末・サーバー基盤モデル。

その他の関連プロジェクト・API¶

プロジェクト	特徴
Mozilla DeepSpeech / Coqui STT	歴史的なオープンソース例。Coqui STTは公式に活発な保守の終了を告知
sherpa-onnx	ONNX Runtimeなどを用いて、対応する音声モデルを実行
Android SpeechRecognizer	端末内認識専用の`createOnDeviceSpeechRecognizer`はAPI 31（Android 12）から。利用可能かを端末上で確認する

参考：Coqui STT公式リポジトリ、Android公式API。

スライド6：音声UIのアクセシビリティ設計¶

音声インタフェースはアクセシビリティを高めることができる一方で、新たなバリアを生む可能性もあります。設計段階から多様なユーザーを想定することが不可欠です。

発話・音声入力に関する多様な条件への配慮¶

音声入力が難しくなる条件の例 - 吃音（Stuttering） - 失語症（Aphasia） - 運動障害性構音障害（Dysarthria） - 喉頭摘出後 - 緊張・不安による一時的な発話困難 - 場所的制約（静かな図書館、電車内等）

設計上の対策

課題	対策
吃音による誤認識	タイムアウトを長めに設定、繰り返し発話への対応
声量が小さい	感度の自動調整、増幅機能
非標準的な発音	パーソナライズASR（個人の音声パターンを学習）
発話自体が困難	テキスト入力・スイッチアクセスをフォールバックとして常時提供

Google Project Euphonia - 非標準的な音声（ALS患者、脳性麻痺者等）の認識精度向上プロジェクト - ユーザーの音声サンプルで個別モデルをファインチューニング - 個人への適応により、ASRのWERが改善した研究がある。改善しているのは認識システムの成績であり、本人の発話明瞭度が上がったという意味ではない（Shorほか2019）

高齢者への配慮¶

年齢だけで能力を一括りにせず、声・聞こえ・操作経験などの個人差と、実際の利用条件を確認する。

設計上の対策 - 読み上げ速度・音量・文字サイズを調整できるようにする - 発話の間や言い直しに対応し、訂正方法を分かりやすく示す - 音声と画面・文字など、複数のフィードバックを用意する - 複雑なコマンド構文を覚えなくても操作できるようにする

非母語話者への対応¶

アクセント対応：方言・外国語アクセントへの認識精度向上
多言語コードスイッチング：「英語と日本語が混じった発話」への対応
発話速度・リズムの違い

インクルーシブデザインの原則¶

ユニバーサルデザインの原則には、利用の柔軟性、分かりやすい情報、エラーへの許容などが含まれる。あるユーザーへの配慮が他のユーザーにも役立つ場合はあるが、一つの設計ですべての人の要求が同時に満たされるとは限らない（NC State University：7原則）。

音声UIのインクルーシブデザインチェックリスト：

[ ] 音声以外の入力手段が常に利用可能か
[ ] 音声以外のフィードバック（視覚・触覚）が提供されているか
[ ] タイムアウト時間は十分か
[ ] エラーメッセージはわかりやすいか
[ ] パーソナライズ設定は簡単に変更できるか

スライド7：UXリサーチ手法¶

音声UIを設計・評価するための主要な手法を紹介します。

Wizard of Oz（WoZ）法¶

概要システムの一部または全部を人間（オペレーター）が代行し、ユーザーの行動・期待を調べる手法。画面や音声の簡易なプロトタイプを使い、認識・対話処理などの本実装に先立って検討できる。

【セットアップ】
参加者（ユーザー役） ←音声→ マイク → [参加者から見えない別室のオペレーター]
                      ←スピーカー← 応答（オペレーターが発話）

なぜ有効か？ - バックエンドを完成させる前の早期段階から、対話や操作の設計を試せる - 設定したシナリオでの発話パターンや期待を収集できる - 技術的制約に縛られない理想のシナリオを探索できる

WoZ法の手順 1. シナリオ・タスクの定義 2. オペレーターへの応答ガイドラインの作成 3. 参加者のリクルート（多様な属性） 4. セッションの実施と録音 5. 発話データの分析（ログ分析・発話転記）

オペレーターが返せる応答や速度は完成システムと異なりうるため、WoZの成功率をそのままASRや実装後の性能とみなさない。参考：Dahlbäckほか（1993）Wizard of Oz studies — why and how。

その他のUXリサーチ手法¶

手法	概要	音声UIでの活用
Think Aloud法	操作時の考えを述べてもらう	音声操作への干渉に注意し、操作後の振り返りも検討
日記法（Diary Study）	ユーザーが日常的な利用記録をつける	自然使用文脈・使用頻度調査
発話ログ分析	実際の利用ログを分析	頻出コマンド・失敗パターン発見
A/Bテスト	条件をそろえて2つの設計を比較	無作為割付などによりプロンプト変更の効果を調べる
ヒューリスティック評価	専門家がUIを評価基準に照らして評価	設計初期の問題発見
Contextual Inquiry	ユーザーの自然な環境で観察・インタビュー	実際の使用状況把握

VoiceUIのユーザビリティ評価指標¶

指標	定義
Task Completion Rate	成功したタスク試行数÷全タスク試行数（成功条件を先に決める）
Turn Count	対話ターン数。発話ごとに数えるか、一往復で数えるかを統一する
WER（Word Error Rate）	音声認識誤り率
Time on Task	タスク完了に要した時間
Recovery Rate	回復に成功したエラー事例数÷回復対象のエラー事例数
主観的ユーザビリティ（SUS等）	ユーザーが感じる使いやすさ。タスク成功率や満足度と区別する

演習（20分）¶

「自分が使いたい音声インタフェースをUX視点で設計する」¶

目標：音声UIの設計原則（スライド2）とアクセシビリティ（スライド6）を活かし、具体的なシナリオを作成する。自分のペースで取り組んでください。

参加方法¶

チャットや共有ドキュメントへの書き込みで参加できます
Zoom参加中の場合はグループで話し合うこともできます（任意）

手順¶

STEP 1：ペルソナの決定（5分）

以下の要素を決めてください：

ペルソナ名（仮名でOK）：
年齢・職業：
音声UI利用シーン：
使用デバイス：
特別な配慮が必要な点（あれば）：

ペルソナ例のヒント（自由に変えてください）： - 視覚障害のある30代会社員が通勤中に使う音声メモアプリ - 80代の祖父母が使う薬の服用管理アシスタント - 吃音のある大学生が講義中に使う静音テキスト変換ツール - 調理中の両手がふさがっている料理人向けレシピナビ

STEP 2：シナリオの作成（10分）

以下の形式でシナリオを書いてください：

【場面設定】
（どこで・何をしているときに音声UIを使うか）

【タスク】
（達成したいこと）

【対話シナリオ（3〜5ターン）】
ユーザー：「〇〇」
システム：「〇〇」
ユーザー：「〇〇」
システム：「〇〇」
...

【エラーケース（1つ）】
（誤認識や操作ミスが起きたとき、どう回復するか）

【アクセシビリティ配慮】
（どんな多様なユーザーに対応しているか）

STEP 3：発表準備（5分）

チャットまたは共有ドキュメントに、シナリオを貼り付けてください。

全体共有（15分）¶

作成したシナリオをチャットや共有ドキュメントに投稿してください。Zoom参加中の方は口頭で紹介することもできます。

講評のポイント： - エラーリカバリは考慮されているか？ - アクセシビリティへの配慮はあるか？ - 実現可能な技術（第9回までの知識）で実現できるか？

小課題¶

提出方法：翌週末23:59までにGoogle Driveに提出（メール添付での提出も可）
形式：400字程度（超えても問題ありません）
備考：音声録音での提出、箇条書きでの提出も可。分量より内容を重視します。やれる範囲で取り組んでください。

課題内容¶

音声インタフェースの良い点・問題点をそれぞれ3つ挙げ、UX改善案を提案せよ。

解答のヒント（必ずしも従う必要はありません）¶

良い点の例： - ハンズフリーで操作できる - 文字を読むのが困難な場合の代替手段になる - 自然言語で指示できる

問題点の例： - 周囲への音の漏れ（プライバシー） - 認識エラー時の修正が難しい - 静かな場所では使いにくい

改善案を考える観点： - 技術的改善（ASRの精度向上、ノイズ除去等） - デザイン的改善（UI設計、フィードバック方法等） - 社会的・倫理的改善（データ利用ポリシー、アクセシビリティ等）

補足資料・参考文献¶

参考文献（学術）¶

Moore, R. K. (2007). Spoken Language Processing: where do we go from here? Distinguished Lecture, Chinese University of Hong Kong, 22 November. 著者所属機関の業績一覧。
Hoy, M. B. (2018). Alexa, Siri, Cortana, and more: An introduction to voice assistants. Medical Reference Services Quarterly, 37(1), 81–88.
Pradhan, A., Mehta, K., & Findlater, L. (2018). “Accessibility Came by Accident”: Use of Voice-Controlled Intelligent Personal Assistants by People with Disabilities. CHI 2018.

参考文献（実践・ウェブ）¶

Google Conversation Design：確認と訂正
Amazon Alexa Design Guide: https://developer.amazon.com/en-US/alexa/alexa-skills-kit/learn/design-guide
W3C WCAG 2.2：入力手段（Input Modalities）。Webの指針であり、独立した「音声インタフェース章」があるわけではない。

オンデバイスASR関連リソース¶

Whisper.cpp: https://github.com/ggml-org/whisper.cpp
Vosk: https://alphacephei.com/vosk/
Project Euphonia関連：個人に適応したASRの研究

次回予告¶

第11回（CBT・動画）：自然言語処理との接続（NLUと音声）

音声処理パイプライン全体（ASR → NLU → DM → NLG → TTS）
意図推定・スロット抽出・NER
LLMとの接続（Whisper + ChatGPT）
Python実習あり（Google Colab）

事前準備（任意）：
Google ColabでWhisperを動かしてみる：

!pip install openai-whisper
import whisper
model = whisper.load_model("tiny")

第10回 音声インタフェースとUX設計¶

オンライン同期授業¶

授業の目標¶

参加方法¶

進化の視点：会話の間（ま）は、言語を越えて似ている¶

授業の流れ¶

スライド講義¶

スライド1：音声UIの歴史と現在¶

電話の自動応答：IVR（Interactive Voice Response）¶

音声ダイアログシステム：1990年代〜2000年代¶

スマートスピーカー・仮想アシスタント：2010年代〜¶

マルチモーダルUI¶

スライド2：音声インタフェース設計の原則¶

基本原則：ユーザー中心設計（UCD）¶

エラーリカバリ設計¶

確認ダイアログの設計¶

マルチターン対話¶

ターン設計の原則¶

スライド3：オンデバイスASRとクラウドASRの比較¶

アーキテクチャの違い¶

比較する際の条件¶

プライバシーとセキュリティの観点¶

データ送信リスクの評価フレームワーク¶

スライド4：エッジ推論 — 小型化の技術¶

量子化（Quantization）¶

プルーニング（Pruning）¶

知識蒸留（Knowledge Distillation）¶

その他の小型化技術¶

スライド5：代表的なオンデバイスASRプロジェクト¶

whisper.cpp（CPU・GPUなどで動作）¶

Vosk¶

Appleのオンデバイス処理とクラウド連携¶

その他の関連プロジェクト・API¶

スライド6：音声UIのアクセシビリティ設計¶

発話・音声入力に関する多様な条件への配慮¶

高齢者への配慮¶

非母語話者への対応¶

インクルーシブデザインの原則¶

スライド7：UXリサーチ手法¶

Wizard of Oz（WoZ）法¶

その他のUXリサーチ手法¶

VoiceUIのユーザビリティ評価指標¶

演習（20分）¶

「自分が使いたい音声インタフェースをUX視点で設計する」¶

参加方法¶

手順¶

全体共有（15分）¶

小課題¶

課題内容¶

解答のヒント（必ずしも従う必要はありません）¶

補足資料・参考文献¶

参考文献（学術）¶

参考文献（実践・ウェブ）¶

オンデバイスASR関連リソース¶

次回予告¶

第10回　音声インタフェースとUX設計¶