同期回だが、発言・マイクは任意。チャットや共有ドキュメントへの書き込みでも参加可。カメラのオン/オフも自由。
声を出すことへの心理的ハードルをできるだけ下げる。インクルーシブな授業設計の実例でもある。
演習は20分。自分のペースでOK。Zoomで会話したい人はグループルームを開放する。
DTMF・音声認識・LLMなど、用途に応じた構成が併存する。VoiceXMLは音声認識モデルではなく、対話などを記述する規格である。
2023年のChatGPT音声モードはASR・LLM・TTSを組み合わせた構成だった。後の音声を直接扱うモデルと区別する。年は発表時点であり、現在の機能一覧ではない。
訂正・取り消し・再確認・代替入力を設計する。人への引き継ぎを一律に3回失敗とせず、タスク・利用者・実測結果で決める。
マルチターン対話では「文脈の保持」と「省略発話への対応」も重要。「じゃあそっちに変えて」のような省略に対応できるか。
オフライン動作の可否は実際の設計上の制約として大きい。地下鉄・飛行機内でも動くかどうかがユーザー体験を左右する。
待受、保存、外部送信は別の処理として説明する。認識が端末内でも、文字起こしやバックアップが外部に送られるかはアプリの構成による。
量子化の理論的な重み保存量と、実際の総メモリ・速度を区別する。Raspberry Piでの速度は機種・モデル・量子化・スレッド数・復号条件を示して測る。
犬の画像の例（犬90%、狼8%、猫2%）は教師が与える候補間の相対関係を示す概念例。公開Whisper tinyがlarge-v3から蒸留されたという説明はしない。
whisper.cpp公式READMEのtinyファイルは約75 MiBであり、実行時メモリはそれより大きい。実行時間・精度を同じ条件で評価する。Appleの端末内認識と、Apple Intelligenceのクラウド併用を区別する。
この授業自体も「マイクで話せない学生への配慮」をしているが、それがまさにアクセシビリティ設計の実例である。
高齢者を一括りにせず、聞こえ・声・操作経験などの個人差を確認する。Euphoniaの成果はASRのWER改善であり、発話能力が改善したという意味ではない。
WoZでは簡易な画面・音声のプロトタイプを使い、人が処理を代行する。バックエンド完成前に対話を検討できるが、結果を実装後の速度や認識精度と混同しない。Dahlbäckほか（1993）を参照。
WERと「実際にユーザーがタスクを完了できたか」は別物。第9回の評価指標の知識がここでつながる。
ペルソナは自由に変えてよい。自分の身近な人をモデルにしてもOK。
「エラーケース」の記述が最も重要。エラーリカバリ設計が甘いシナリオが多いので、そこを重点的にフィードバックする。
分量・形式は緩やかに設定。やれる範囲で取り組んでもらう。音声録音での提出もOKにすることで、音声技術の利用体験にもなる。