アプリ・WebサイトのUIサウンド設計入門

ボタン音や通知音は、鳴らし方を間違えると一気に「うるさいアプリ」になります。UIサウンドの目的、鳴らしどころの選び方、Webの自動再生制限まで、実装前に知っておきたい設計の基本をまとめました。

UIサウンドは「返事」である

アプリやWebサイトで鳴らす音（UIサウンド）の役割は、装飾ではなくフィードバックです。ユーザーの操作に対して「受け付けました」「完了しました」「それはできません」と返事をするのが仕事。だから設計の出発点は「どこで鳴らすと気持ちいいか」ではなく、「どの操作に返事が必要か」です。

鳴らす場面を絞る

UIサウンドで一番多い失敗は「鳴らしすぎ」です。すべてのタップで音が鳴ると、ユーザーは数分で音を切ります。優先順位の高い順に絞りましょう。

• 結果が変わる操作：送信完了、購入確定、保存成功。→ 明るく短い完了音。
• 取り消しにくい操作・エラー：削除、失敗、入力エラー。→ 完了音と明確に区別できる音。
• 状態の変化：通知の受信、タイマー終了、マッチング成立。→ 画面を見ていなくても気付ける音。
• 頻繁な操作（カーソル移動・スクロール等）：原則鳴らさない。鳴らすならごく小さく短く。

音の長さと性格

UIサウンドは0.05〜0.3秒程度の短い音が基本です。長い音は操作のテンポを邪魔します。また「成功系は上昇音・明るい音色」「エラー系は下降音・濁った音色」のように、音の性格と意味を揃えると、ユーザーは無意識に聞き分けられるようになります。当サイトのシステム音カテゴリには、決定・キャンセル・エラーなど役割別の短い音を揃えています。

必ずオフにできるようにする

どんなに良い音でも、電車の中や職場では鳴ってほしくないものです。設定でサウンドをオフにできること、そして端末のマナーモードや音量設定を尊重することは、UIサウンドを入れる際の最低限のマナーです。ゲーム以外のアプリなら「初期設定はオフ、オンにできる」という選択も十分ありです。

Webでの実装の注意点：自動再生制限

ブラウザは、ユーザー操作なしの音声再生をブロックします（自動再生制限）。ページを開いた瞬間に音を鳴らすことは基本的にできません。実装のポイントは次の通りです。

• 音の再生（またはAudioContextの生成・再開）は、クリックやタップなどユーザー操作のイベント内で開始する。
• 短いUI音を多用するなら、audioタグよりWeb Audio APIのほうが遅延が小さく、同時再生にも強い。
• 音声ファイルは事前に読み込んでおき、タップから発音までの遅延（レイテンシ）を減らす。体感では0.1秒遅れるだけで「反応が鈍い」と感じます。

ゲーム寄りの実装テクニックはゲーム開発での効果音の使い方でも詳しく解説しています。