音を消して遊んでもらうと、何が伝わらなくなるか:最初の30秒の無音テスト設計書
遊びをつくる執筆にClaudeを使用しています。

自作のアクションゲームを、電車の中や夜の自室など、音を出せない環境で開く人がいる場面を考えてみます。画面の端から敵が近づいてくるとき、制作中は「ピコン」という警告音が鳴っていました。ボタンを押したときの小さなクリック音も、ゴールに着いたときの短いファンファーレもあります。音を消した状態では、そのどれも届きません。遊んでいる人は、ただ画面が突然終わったように感じるかもしれません。 この記事の問いは、音で伝えていた情報のうち、画面上のほかの手段で補えていなかったものはどれかです。音の良し悪しを問うものではありません。音を消して最初の30秒を観察し、情報の抜けた場所を特定するための実験を、設計書の形で示します。結果は書きません。読者の方が自分のゲームで行えば答えが出る形にしています。
音が運んでいる情報を4つに分ける
観察の前に、音の役割を分けておきます。「音が鳴らなかった」と一括りにすると、どこを直せばよいのか見えなくなるためです。
- 確認:入力を受け付けたことを知らせる音です。ボタンのクリック音、アイテムを拾った音などです。
- 状態変化:得点が入った、ダメージを受けたといった、数値や状況が変わった瞬間の音です。
- 予告:危険や機会が近づいていることを先に知らせる音です。敵の接近音、制限時間の残りわずかを示す音などです。
- 雰囲気:BGMや環境音のように、気分を作る音です。
このうち、欠けるとゲームの進行に影響しやすいのは、確認・状態変化・予告の3つです。雰囲気は欠けても遊べることが多く、今回の観察の主対象ではありません。ただし、雰囲気の音が実は予告を兼ねていた(曲調が変わると危険の合図になる、など)場合もあるため、台帳の段階で見落とさないようにします。
準備するもの
用意するのは次のものです。
- 遊べる状態のビルド:公開前のものでも、公開済みのものでも構いません。
- 音の台帳:ゲーム内のすべての効果音と、音で変わるBGMを一覧にした表です。次の節で作り方を示します。
- テスター3〜5人:そのゲームを初めて遊ぶ人です。少人数でも、複数の人が同じ場所でつまずく問題は見つかるという考え方に基づく人数です。人数を増やして統計的な結論を出す実験ではありません。
- 画面録画:テスターの手元ではなく、ゲーム画面を録ります。後から秒単位で見返すためです。
- 音を確実に出さない手段:端末の音量をゼロにするか、ブラウザのタブをミュートします。ゲームに音のオン・オフ設定がある場合は、それに頼らず、端末側でも消します。
- ストップウォッチと記録用の表:観察者が時刻つきで書き込むためのものです。
テスターは、同じ人に「音あり」と「音なし」を続けて遊んでもらう設計にしません。先に遊んだ内容を覚えてしまい、2回目の観察が学習の結果になるためです。今回は音なしだけを、別々の人に1回ずつ遊んでもらいます。
手順
1. 音の台帳を作る
ゲーム内の音を1行ずつ書き出し、次の4列を埋めます。
- 例:警告音、鳴る場面:敵が画面外から近づいたとき、伝えている情報(確認/状態変化/予告):予告、同じ情報を伝える視覚的な手段:なし(敵は画面に入るまで見えません)
- 例:決定音、鳴る場面:ボタンを押したとき、伝えている情報(確認/状態変化/予告):確認、同じ情報を伝える視覚的な手段:ボタンの色が変わります
最後の列が「なし」の行が、観察前の時点での仮説の候補です。ここでは「ある」と書いたものも、本当にテスターの目に入るかは別の問題なので、後の読み方の節で確かめます。
コードを触れる場合は、再生処理を1か所のラッパー関数にまとめ、鳴るはずだった音を時刻つきで記録できるようにしておくと、録画との照合が楽になります。次は、考え方を示す最小の例です。
const soundLog = [];
let t0 = performance.now();
const muted = new URLSearchParams(location.search).get("mute") === "1";
// ゲーム開始の操作で呼びます(読み込み時ではなく開始時を0秒にするため)
function resetClock() { t0 = performance.now(); soundLog.length = 0; }
// すべての効果音をこの関数経由で鳴らします
function playSound(name, role) {
const sec = Number(((performance.now() - t0) / 1000).toFixed(1));
soundLog.push({ sec, name, role });
if (muted) return;
// ここに既存の再生処理を入れます
}
// テスト後にコンソールで確認します
// console.table(soundLog);URLの末尾に ?mute=1 を付けると、音を出さずにログだけが残ります。ただし、ゲームがこの形式で動くかどうかは、既存の作りによります。外部のサーバーやライブラリを使わない範囲で、自分のゲームに合わせて調整してください。このコードを使わず、録画と台帳だけで進めても実験は成立します。
2. 本当に無音になっているか確かめる
テスターを呼ぶ前に、自分で1回通しで遊び、どこからも音が出ていないことを確認します。BGM、効果音、ゲーム開始前のメニュー画面の音も対象です。1か所でも鳴ると、「音がなかった条件」ではなくなります。
3. 説明なしで最初の30秒を遊んでもらう
テスターには、「このゲームを遊んでください。説明はしません。音は出ない設定です」とだけ伝えます。操作方法の説明も、目的の説明も省きます。観察者は途中で助言をしません。質問されても「思ったようにやってみてください」と返します。
30秒としているのは、最初の理解が決まりやすい区間だからです。ゲームの種類によっては、60秒まで延ばしても構いません。ただし全員同じ長さにそろえます。
4. 時刻つきで記録する
観察者は、次の出来事が起きたときに、1件につき1行、秒単位の時刻とともに書きます。
- 止まった:2秒以上、入力が途絶えた。
- 連打した:同じ入力を短時間に繰り返した。
- 見回した:画面の別の場所を探すような視線や操作があった。
- 声が出た:「え?」「何これ」など、予想外の反応を示す声があった。
- 失敗した:ゲームオーバーや失点が起きた。
書くのは事実だけにします。「たぶん警告音が聞こえなくて焦っている」といった推測は、別の欄に分けます。
5. 直後に3つ質問する
30秒が終わったら、すぐに次の3つを聞きます。
- 今、何が起きましたか。
- (失敗した場合)なぜ失敗したと思いますか。
- このゲームを一言で説明するとどんなゲームですか。
答えは言葉をそのまま書き留めます。言い直しを促したり、正解を教えたりはしません。
結果の読み方
台帳の4列目と、観察の記録を突き合わせます。判断の目安は次のとおりです。
- 同じ場面で2人以上が止まった、読み取れること:その場面の情報が音にしか載っていない可能性が高いです、次の一手:台帳の該当行に、視覚的な手段を足す候補として印を付けます
- 同じ入力の連打が出た、読み取れること:入力が受け付けられたことが見えていません(確認の欠落)、次の一手:押した瞬間の見た目の変化を確認します
- 失敗の理由を答えられない、読み取れること:失敗の前に、予告が届いていません、次の一手:失敗の直前数秒の画面を見直します
- 台帳では視覚あり、だが観察では見落とされた、読み取れること:視覚的な手段が小さい、遅い、目立たないなどの可能性があります、次の一手:大きさ・位置・出る時間を見直します
- 台帳では視覚なし、だが誰も詰まらなかった、読み取れること:文脈や画面の動きなど、別の手がかりで補えています、次の一手:すぐには直さず、保留にします
- どの記録にも反応が出なかった音、読み取れること:装飾として働いている可能性があります、次の一手:無理に削らず、そのまま残して構いません
見分けるうえで大切なのは、「1人だけの反応」と「複数人に共通する反応」を分けることです。1人が止まっただけでは、その人の癖かもしれません。一方、台帳で「視覚なし」と書いた行と、複数人の詰まりが重なったところは、優先して直す価値が高い場所です。
直すときに、音の代わりに画面へ文字を大量に足すことは避けます。画面の色、形、動き、位置の変化で足りるかをまず考えます。足す内容は、台帳の「伝えている情報」の列が決めます。確認なら押した直後の変化、予告なら危険が近づく向きと距離が分かる見せ方、というように、必要な情報だけを足します。
公式作品で練習する
自作のゲームに手を付ける前に、公開されている作品でこの観察を一度リハーサルすることもできます。たとえば「こだまの森」は、光る葉の順番を覚えて4つの音色で返す記憶ゲームで、音なしでも遊べる作りになっています。
この作品を無音で開き、次の点を自分の目で確かめてみてください。
- 葉の光り方だけで、順番と、どの音色に対応するかが分かるか。
- 自分が押した葉に対して、正しかったか間違いだったかが、画面のどこで分かるか。
- 「聴き直し」を使ったとき、無音の状況でどのように働くか。
最後の点を含め、画面の細部や仕様は、実際に作品を開いて確かめるのが確実です。そのうえで、同じ見方を自作ゲームの台帳に当てはめます。ここで目指すのは、公式作品を評価することではありません。無音の状態で何を手がかりに進むかを、観察する練習をすることです。
誤りやすい点
無音テストは、聴覚に障害のある方の体験の代わりにはなりません。 音を出せない環境で遊ぶ人と、日常的に音を聞かずに遊ぶ人とでは、慣れも工夫も違います。アクセシビリティを本格的に考える場合は、当事者の声や専門機関の情報に当たってください。この実験は、その入り口として「音への依存を見つける」ための簡易な確認です。
テスターが音を探す動きに注意します。 端末の音量キーを押す、スピーカーに耳を近づけるといった行動は、音が出ていると思っている証拠です。その時刻を記録し、「音を探した」と書き添えます。事前の説明が足りないのではなく、そのゲームが音を期待させる作りになっていることを示している可能性があります。
観察者が助言してしまう失敗が最も多くなります。 詰まっている人を前にすると、つい口を出したくなります。我慢して、詰まっている時間そのものを記録してください。
無音のほうがよい、という結論を急がないでください。 この実験は、音を消したときに何が失われるかを調べるものです。音ありの体験が不要だと示すものではありません。音に載せる情報と、画面に載せる情報の分担を、意識して選べるようになるのが目的です。
サンプルが偏らないようにします。 制作者の友人や家族ばかりを集めると、ゲームの意図を察してしまう人が混じります。可能なら、そのジャンルに慣れている人と慣れていない人を両方入れます。
次の行動
まず自作ゲームの音を全部書き出し、台帳の4列目が「なし」になる行を数えてみてください。次に、こだまの森を無音で開いて、観察の見方を一度練習します。そのうえで、3人に最初の30秒を遊んでもらい、止まった時刻を記録します。直した後は、アソバースの公開内容の更新機能を使って反映し、別の3人でもう一度同じ手順を繰り返すと、変化を確かめられます。

