GPT-LiveをWebアプリに組み込む｜音声UIの作り方と設計の要点
仕様確認・更新日: · 編集: 株式会社ウェステリア
Webアプリへの音声導入では、利用者が話した後に画面で何を確認できるかが重要です。マイクのボタンを追加するだけでなく、入力された条件、処理の進み具合、完了した結果が分かる画面にします。
結論から
- ブラウザ音声の入口として公式はWebRTCのサンプルを提供しています。
- APIキーはサーバーに保持し、既存のログインと機能の権限を接続します。
- 会話と画面の結果を揃え、マイクが使えない場合の操作手段も残します。
ブラウザとサーバーで役割を分ける
公式の導入ガイドでは、ブラウザのマイクと音声再生、APIキーを保持する信頼できるサーバーでWebRTC接続を作ります。ブラウザのページにはHTTPSまたはlocalhostが必要です。業務処理への依頼はバックエンドと接続します。
仕様の出典: OpenAI — GPT-Live導入ガイド / OpenAI — WebRTC接続
最初に音声化する操作を1つ選ぶ
例えば、入力項目が多い作業報告、条件を変えながら使う商品検索、予定の下書きなどを候補にします。話すことで入力が楽になるか、周囲に話してよい内容か、画面で確認したい結果があるかを検討します。
すべてのクリック操作を音声に置き換える必要はありません。音声で条件を伝え、画面で候補を比較し、確定ボタンを押すという組み合わせも考えられます。利用者が最も迷いやすい操作から試作すると評価が具体的になります。
画面に『聞いた内容』と『実行結果』を分けて出す
例えば検索結果の表示が遅れている間に条件が変わったら、最新の条件に対応した結果だけを反映します。古い検索結果が後から届いて画面を戻す問題を防ぐため、依頼と結果に対応関係を持たせます。これはアプリ側で設計する部分です。
| 表示 | 利用者が分かること |
|---|---|
| マイクの状態 | いま音声が入力されているか |
| 聞き取った条件 | 日時や人数などの訂正が反映されているか |
| 処理中の表示 | 検索や更新が終わったか |
| 確定した結果 | どの情報が保存されたか |
| エラーと次の操作 | 再試行か、手入力か、担当者への連絡か |
既存の業務APIを音声から利用する
既存アプリの機能がAPIとして独立していれば、その権限や検証を活かせるかを確認します。音声で依頼した操作にも、ボタンで実行する場合と同じ認証・権限の確認を適用します。
画面上のデータとバックエンドの状態が食い違う場合に、どちらを正とするかも決めます。予約や申請などの保存結果はサーバー側で確かめ、音声応答には確定した情報を返します。見た目の変化だけで処理完了を演出しない設計が必要です。
使い続けられる音声UIの確認項目
試作の評価では開発者のPCだけでなく、想定ユーザーの端末とブラウザを使います。業務で片手がふさがる場面や、静かな場所で声を出しにくい場面も確認すると、音声を加えるべき範囲が見えてきます。
- マイクの許可を拒否した場合に、手入力へ進める。
- 消音と通話終了を区別し、終了時にマイクと接続を解放する。
- スマートフォンでも開始・終了ボタンと結果が見つかる。
- 音声が聞けない環境でも、重要な結果を文字で確認できる。
- 通信が切れたときに、進行中の操作がどうなったか確認できる。
よくあるご質問
- 既存のWebアプリに追加できますか？
- 認証、利用中のAPI、画面構成を確認して追加範囲を決めます。まず1画面・1操作で試し、既存の入力方法と併用できる構成を検討します。
- 音声だけで操作する画面にするべきですか？
- 用途によります。検索条件は音声、結果の比較や確定は画面というように、操作ごとに使いやすい手段を選ぶことを提案します。