フレームワーク活用ガイドひとことで言うと#
「画面を使わず、声だけでユーザーとシステムがやりとりする体験を設計する手法」。GUIでは「目で見て手で操作する」のに対し、VUI（Voice User Interface）では「耳で聞いて声で操作する」。画面がない分、会話の流れを自然に設計することが成功の鍵。
押さえておきたい用語#
- VUI（Voice User Interface）
- 音声で操作するユーザーインターフェースのこと。スマートスピーカーやカーナビの音声操作など、画面なしで対話するUIの総称。
- プロンプト
- システムがユーザーに対して**話しかけるセリフ（発話文）**のこと。「何名でご予約しますか？」のように、次のアクションを促す。
- ユッテランス（Utterance）
- ユーザーが発する音声入力のバリエーションを指す。「明日の天気」「明日天気どう？」「明日雨降る？」など、同じ意図の異なる言い回し。
- ウィザード・オブ・オズ法
- システムの代わりに人間が裏で応答するテスト手法のこと。プロトタイプを開発する前に対話フローの問題点を発見できる。
- ハッピーパス
- ユーザーが想定通りにスムーズに操作を完了する理想的な流れである。まずこの正常系を設計し、その後にエッジケースやエラー処理を追加する。
音声UIデザインの全体像#
こんな悩みに効く#
- スマートスピーカー向けのスキルを開発したいが、対話の設計方法がわからない
- 既存のIVR（電話の自動音声応答）がわかりにくいと苦情が来ている
- 料理中や運転中など、ハンズフリーで操作できるインターフェースを作りたい
基本の使い方#
まず、音声UIが本当に適切な解決策かどうかを判断する。
音声UIが向いているケース:
- 手がふさがっている（料理中、運転中、作業中）
- 操作が単純で、短いやりとりで完結する
- 画面を見る必要がない、または見られない状況
- 自然言語での入力が直感的（検索、質問、命令）
音声UIが向かないケース:
- 複雑な選択肢から1つを選ぶ（メニューが多い場合）
- 視覚的な比較が必要（商品の比較、地図の確認）
- プライバシーが必要な操作（公共の場での個人情報入力）
- 長い文章の入出力
ポイント: 「画面でやったほうが早い」ことを音声に置き換えても、使いにくくなるだけ。
ユーザーとシステムの会話のシナリオを設計する。
設計の手順:
- ハッピーパス: 理想的な会話の流れを書く
- エッジケース: ユーザーが想定外の発言をした場合の対応
- エラー処理: 認識できなかった場合の聞き返し方
- コンテキスト管理: 会話の文脈を維持する方法
対話設計のルール:
- 1ターンの情報量を絞る: 一度に3つ以上の選択肢を提示しない
- 確認を入れる: 重要な操作の前に確認を挟む（「◯◯でよろしいですか？」）
- エスケープを用意する: いつでも「キャンセル」「最初から」で戻れるようにする
- プログレッシブ・ディスクロージャー: 最初は簡潔に、詳細が必要なら掘り下げる
システムが話すセリフ（プロンプト）を自然な日本語で作成する。
プロンプトの原則:
- 短く: 1文は15〜20文字以内を目安に
- 明確に: 次にユーザーが何をすべきかわかるように
- 自然に: 書き言葉ではなく、話し言葉で書く
- 一貫性: システムの人格（トーン&マナー）を統一する
悪い例: 「現在、ご注文の確認画面に遷移しております。内容をご確認の上、確定ボタンを選択してください。」 良い例: 「ご注文の内容を確認します。コーヒー2杯で合計600円です。注文してよろしいですか？」
ポイント: 書いたプロンプトは必ず声に出して読む。目で読んで自然でも、耳で聞くと不自然なことがある。
実際のユーザーに使ってもらい、対話の問題点を発見・修正する。
テスト方法:
- ウィザード・オブ・オズ法: システムの代わりに人間が応答し、対話の流れを検証
- 実機テスト: プロトタイプを実機で動かし、音声認識の精度も含めて検証
- ログ分析: 実際の利用ログから、離脱ポイントやエラー発生箇所を特定
改善のポイント:
- ユーザーがどんな言い方をするかのバリエーション（ユッテランス）を追加する
- エラーが頻発する箇所のプロンプトを修正する
- 会話が長くなりすぎている箇所を短縮する
具体例#
状況: スマートスピーカー向けのレストラン予約アプリを開発。ターゲットは30〜50代の共働き世帯。「料理中に手を使わず予約したい」というニーズに応える。
対話フロー設計:
システム: 「レストラン予約へようこそ。何名でご予約しますか？」
ユーザー: 「2人で」
システム: 「2名ですね。いつのご予約ですか？」
ユーザー: 「明日の夜7時」
システム: 「明日、3月10日の19時で2名ですね。
和食、洋食、中華など、ジャンルの希望はありますか？」
ユーザー: 「イタリアンがいいな」
システム: 「イタリアンですね。渋谷エリアで3件見つかりました。
1つ目はトラットリア・ベラ、評価4.5。
詳細を聞きますか？次に進みますか？」エラー処理の設計:
| エラー状況 | 対応 |
|---|---|
| 人数が聞き取れない | 「すみません、何名でご予約ですか？」 |
| 2回連続で聞き取れない | 「うまく聞き取れませんでした。1名、2名のように数字でお答えください」 |
| 3回連続で失敗 | 「申し訳ございません。ウェブサイトからのご予約もご利用いただけます」 |
テスト結果と改善:
- 「明日の晩」「明日のディナー」など、時間表現のバリエーションを20パターン追加
- 「とりあえずなんでもいい」への対応を追加（おすすめを提案するフローへ分岐）
- 店舗情報の読み上げが長すぎたため、最初は店名と評価のみに短縮
タスク完了率48%→82%。エラー処理の充実と時間表現のユッテランス追加が特に効いた。「とりあえずなんでもいい」への対応を追加するだけで離脱が減る。
状況: 年間120万件の電話を受ける大手保険会社。IVR経由の自己解決率が22%と低く、78%がオペレーターに転送されていた。1件あたりのオペレーター対応コストは850円。
Before（改善前のIVR）:
「お電話ありがとうございます。○○保険でございます。
契約内容の確認は1を、保険金のご請求は2を、
住所変更は3を、解約のご相談は4を、
その他のお問い合わせは5を、もう一度聞くには9を押してください」→ 選択肢が多すぎてユーザーが迷い、すぐに「0」（オペレーター直通）を押す
After（改善後のVUI）:
「○○保険です。今日はどのようなご用件ですか？
たとえば『住所変更』『保険金の請求』などとお話しください」→ 自然言語で用件を言える。音声認識で意図を判定し、適切なフローに振り分ける
| 指標 | Before | After |
|---|---|---|
| IVR自己解決率 | 22% | 58% |
| オペレーター転送率 | 78% | 42% |
| 年間コスト削減 | — | 約3.7億円（転送43万件減 × 850円） |
| 顧客満足度 | 2.8/5.0 | 3.9/5.0 |
自己解決率22%→58%、年間コスト削減約3.7億円。「番号を押す」から「話しかける」に変えただけでこの差。顧客満足度も2.8→3.9に跳ね上がった。
状況: 医師1名・スタッフ3名の内科クリニック。1日平均40件の電話予約があり、スタッフの業務時間の35%を電話対応が占めていた。音声予約システムの導入を検討。
対話フロー設計:
システム: 「○○クリニックの予約受付です。
診察の予約でよろしいですか？」
患者: 「はい」
システム: 「診察券をお持ちですか？」
患者: 「持っています」
システム: 「診察券番号を4桁でお知らせください」
患者: 「1234」
システム: 「田中太郎さまですね。ご希望の日時を教えてください」
患者: 「明日の午前中」
システム: 「明日の午前は10時30分と11時が空いています。
どちらがよろしいですか？」
患者: 「10時半で」
システム: 「明日10時30分で予約しました。変更やキャンセルはいつでもお電話ください」設計のポイント:
- 選択肢は常に2つまで（3つ以上は聞き取れない）
- 名前の確認で本人認証を兼ねる
- 「明日の午前」のような曖昧な表現にも対応
- 新患（診察券なし）の場合はオペレーターに転送するエスケープを用意
| 指標 | 導入前 | 導入3ヶ月後 |
|---|---|---|
| 電話対応にかかるスタッフ時間 | 1日2.8時間 | 1日0.9時間 |
| 予約の自動完了率 | 0% | 68% |
| 患者の待ち時間（電話がつながるまで） | 平均3.2分 | 平均15秒 |
| 月間の電話料金 | 4.8万円 | 2.1万円 |
電話対応時間68%削減、初期投資120万円は8ヶ月で回収。浮いた時間を患者対応に回した結果、Google口コミ評価が3.6→4.1に。
やりがちな失敗パターン#
- 画面UIの設計をそのまま音声に移植する — GUIのメニュー構造を音声で読み上げても使えない。音声ならではの対話の流れを一から設計する
- エラー処理を後回しにする — 音声認識は完璧ではない。ユーザーが想定外の発言をすることは日常茶飯事。エラーハンドリングこそ最も重要な設計要素
- 一方的に情報を流す — システムが長々と話し続けると、ユーザーは内容を覚えられない。1ターンの情報量を最小限にし、ユーザーのペースで進められるようにする
- 声に出して検証しない — プロンプトを目で読んで「自然だ」と判断してしまう。必ず声に出して読み、耳で聞いたときの自然さを確認する。書き言葉と話し言葉は全く違う
まとめ#
音声UIデザインは、声だけで自然にやりとりできる体験を設計する手法。画面がない制約を理解し、短く明確な対話フローを設計することが成功の鍵。まずは対話シナリオを紙に書き、声に出して読むことから始めよう。ユーザーテストで実際の発話パターンを収集し、繰り返し改善することで、使いやすいボイス体験が生まれる。