品質を損なわずにWeb向け音声を圧縮する方法

音声が果たすべき役割から始める

音声圧縮は、ひとつの問題ではありません。ポッドキャストのクリップ、通知音、音楽プレビュー、背景の環境音ループでは、それぞれ許容できる範囲が異なります。

よくある間違いは、それらをすべて「このファイルを小さくする」として扱うことです。たいていの場合、適当なビットレートでMP3を書き出し、アップロードして、シンバルの揺れたような音や金属的な声に誰も気づかないことを願うだけになります。

より良い手順はシンプルです。

1. クリーンなマスターファイルを保持する。
2. コンテンツに適したコーデックを選ぶ。
3. 魔法の数字ではなく、ビットレートの範囲を決める。
4. 実際のデバイスと接続環境でテストする。
5. 必要な場合にだけフォールバックを出荷する。

音声は画像や動画より小さいことが多いものの、それでも重要です。6 MBの音声ファイルは操作開始を遅らせ、モバイルデータを浪費し、ページを実際以上に重く感じさせる可能性があります。フォントや画像の容量をすでに重視しているなら、音声にも同じ規律が必要です。考え方は、Webフォントのパフォーマンス改善で使うものと似ています。ページが本当に必要とするものだけを配信する、ということです。

ロスレスのマスターを保持する

圧縮済みファイルから別の圧縮済みファイルへ、何度も書き出さないでください。

MP3、AAC、Opusのような非可逆コーデックは、エンコード時に情報を削除します。MP3を編集して別のMP3として書き出し、その後さらにAACへ変換すると、各ステップでアーティファクトが追加されます。最初は目立たないかもしれませんが、蓄積していきます。

作業用のマスターは、WAVやFLACのようなロスレス形式で保持します。そのマスターからWeb配信用ファイルを生成してください。ソースがすでに非可逆の場合は、不要な編集を避け、代替手段がない限りトランスコードは1回までに抑えます。

これが特に重要なのは、次のような場合です。

• シンバル、リバーブ、ストリングス、または密度の高いミックスを含む音楽
• 背景ノイズのある音声録音
• ループしたり頻繁に繰り返されたりする短いUI音
• 後で動画やソーシャル向け形式に再利用される可能性のある音声

マスターファイルはユーザーに配信するものではありません。品質面で自分を追い込まないための保険です。

ビットレートを選ぶ前にコーデックを選ぶ

ビットレートは注目されがちですが、より大きな働きをするのはコーデックの選択です。

Opus: 通常は最良のモダンWeb向け選択肢

Opusは音声に非常に優れ、音楽にもかなり適しています。低ビットレートでも破綻しにくく、混在したコンテンツにもよく適応し、WebMやOggのような適切なコンテナで使えば、モダンブラウザで広くサポートされています。

新しいWeb音声の多くでは、まずOpusを試すべきです。

良い出発点は次のとおりです。

• 音声、モノラル: 24–40 kbps
• 音声、ステレオまたは高品質ナレーション: 48–64 kbps
• 音楽プレビュー: 96–128 kbps
• 背景の環境音: 48–96 kbps

ビットレートが高ければ常に良い、とは考えないでください。クリーンな48 kbpsのOpus音声ファイルは、エンコードの悪い96 kbpsのMP3より良く聞こえることがあります。

AAC: 実用的な互換性フォールバック

MP4またはM4AコンテナのAACは、今でも妥当なフォールバックです。古いApple環境、埋め込みWebView、保守的な企業向けデバイス群を気にする場合は特にそうです。

AACは効率がよく、広くサポートされています。レガシーなワークフローのためにMP3が明確に必要な場合を除き、通常はMP3より良いフォールバックです。

良い出発点は次のとおりです。

• 音声: 64–96 kbps
• 音楽: 128–192 kbps
• 短い効果音: 96–128 kbpsをテスト

MP3: 普遍的だが、最適なことは少ない

MP3は、ほぼあらゆる環境で再生できるため今でも有用です。しかし、特に低ビットレートではOpusやAACより効率が劣ります。MP3を使う場合は、無理に削りすぎないようにしてください。

妥当なMP3の出発点は次のとおりです。

• 音声: 96 kbps モノラル
• 音楽: 160–192 kbps ステレオ

これを下回ると、水っぽい高域、にじんだトランジェント、声のもろく硬い質感といったアーティファクトが出やすくなります。

コーデックの判断は、画像でAVIFとWebPを選ぶことに似ています。最新または最小の選択肢が、すべてのオーディエンスにとって自動的に正しいわけではありません。ビジュアルアセットについて同様の判断枠組みが必要なら、2026年の画像形式のガイドをご覧ください。

コンテンツがモノラルならモノラルを使う

1本のマイクで録音された話し声に、ステレオ配信は必要ありません。

ステレオではなくモノラルで音声をエンコードすると、体感品質を下げずにファイルサイズを大きく削減できます。また、コーデックが重要な部分、つまり明瞭度、子音、声の調子、自然さを保つための余地も増えます。

ステレオが意味を持つ場合はステレオを使います。

• 音楽
• 空間的な環境音
• バイノーラル録音
• 左右の動きに意味があるサウンドデザイン

意味がない場合はモノラルを使います。

• インタビュー
• ボイスメモ
• 製品ナレーション
• ほとんどの解説音声
• シンプルな通知音

これは、コーデックに奇跡を求めずに圧縮を改善できる、最も簡単なWeb音声の改善策のひとつです。

エンコード前にラウドネスを正規化する

「圧縮が悪い」という不満の多くは、実際にはラウドネスの問題です。

あるクリップが小さすぎると、誰かが音量を上げ、ノイズやエンコードのアーティファクトを露出させてしまうかもしれません。別のクリップが大きすぎると、圧縮が始まる前に歪んでしまう可能性があります。書き出し前にソースを正規化し、整えてください。

Web向けの話し声では、ピークレベルだけでなく、知覚上のラウドネスを一定にすることを目指します。ポッドキャストや音声コンテンツでは、ステレオで約 -16 LUFS、モノラルで約 -19 LUFS が一般的な目標ですが、プロダクトの文脈によって異なる場合があります。短いUI音では、ポッドキャストの基準に合わせることより、インターフェイス全体との一貫性のほうが重要です。

エンコード前に行うこと:

• 先頭と末尾の無音をトリミングする。
• 必要に応じて低域のランブルを除去する。
• 背景ノイズは慎重に、過度ではなく低減する。
• クリッピングを避ける。
• 関連するクリップ間でラウドネスを正規化する。

圧縮は、入力が制御されているときに最もよく機能します。

ほとんどのWeb音声では可変ビットレートを優先する

可変ビットレートエンコードでは、コーデックが複雑な瞬間には多くのデータを使い、単純な部分では少なく使えます。一般的なWeb配信では、VBRが良いデフォルトです。

一定ビットレートは、予測可能なストリーミング挙動や厳密な帯域上限が必要な場合には今でも有用です。しかし、ほとんどの静的なWeb音声ファイルはVBRの恩恵を受けます。

実用的なテストはシンプルです。両方をエンコードし、ファイルサイズと品質を比較し、同じに聞こえるなら小さいファイルを選びます。静かな部屋でそれなりのヘッドホンを使って違いが聞き取れないなら、ほとんどのユーザーはオフィスのノートPCスピーカーでは気づかないでしょう。

使いやすいFFmpegの開始コマンド

FFmpegは、この作業において今でも最も実用的なコマンドラインツールです。以下は出発点であり、万能のレシピではありません。

Opusでモノラルの話し声を作る場合:

ffmpeg -i master.wav -ac 1 -c:a libopus -b:a 40k -vbr on voice.opus

WebMで高品質なナレーションを作る場合:

ffmpeg -i master.wav -ac 1 -c:a libopus -b:a 64k -vbr on narration.webm

Opusで音楽プレビューを作る場合:

ffmpeg -i master.wav -c:a libopus -b:a 128k -vbr on preview.webm

AACフォールバックの場合:

ffmpeg -i master.wav -c:a aac -b:a 128k fallback.m4a

必要な場合だけMP3フォールバックを作る場合:

ffmpeg -i master.wav -c:a libmp3lame -b:a 160k fallback.mp3

多数のファイルを準備する場合は、処理をスクリプト化し、設定をバージョン管理に入れてください。デスクトップアプリの中に隠れたランダムな書き出し設定は、後から監査するのが困難です。

複数のソースは慎重に配信する

HTML audioは複数のソースファイルをサポートしています。ブラウザは再生できる最初のものを使います。

<audio controls preload="metadata">
  <source src="clip.webm" type="audio/webm; codecs=opus">
  <source src="clip.m4a" type="audio/mp4">
</audio>

好ましいモダン形式を最初に置き、その後に互換性フォールバックを置きます。習慣だけで3つも4つも形式を含めないでください。生成されるファイルが1つ増えるたびに、ストレージ、ビルド、QA、キャッシュに影響します。

音声がページの中心であることが明らかな場合を除き、preload="metadata" または preload="none" を使います。音声ファイル全体のプリロードは、特に複数のプレイヤーがあるページで、気づかないうちにパフォーマンスを悪化させることがあります。

パフォーマンスレビューでLighthouseを使う場合、音声の問題はネットワーク重量、プレイヤー周辺のメインスレッド活動、または読み込み挙動の悪さとして間接的に現れることがあります。音声が本当にボトルネックかどうか判断する際には、慌てずにLighthouseレポートを読む方法のガイドも役に立ちます。

エンコーダーではなくユーザーのように品質をテストする

波形やビットレートの数値は有用ですが、最終結果を決めるのはリスニングです。

実用的なQA手順は次のとおりです。

1. ロスレスのマスターを聴く。
2. 圧縮後のファイルを通常の音量で聴く。
3. 安価なイヤホンまたはノートPCスピーカーでもう一度聴く。
4. 一度に最初の15–30秒だけを比較する。
5. 難しい箇所に注意する。シンバル、息づかい、拍手、歯擦音、リバーブの余韻、突然のトランジェントなど。

音声では、明瞭度を優先します。声が明確で自然なままであれば、多少の音色の損失は許容できます。音楽では、高域の質感とステレオイメージに注意します。ループでは、エディタ内だけでなくブラウザ内でループポイントを確認してください。

実際のページもテストします。

• 再生はすばやく始まるか。
• コントロールのレイアウトはモバイルで機能するか。
• 操作前にファイルが不要にダウンロードされていないか。
• 期待した場所でフォールバックが実際に使われているか。
• 音声が重要な情報を含む場合、キャプションや文字起こしは用意されているか。

圧縮は配信の一部であり、独立した制作上の雑務ではありません。

避けたいよくある間違い

すべてを320 kbpsで書き出す

品質面では安全ですが、Webには無駄が多すぎます。ほとんどの音声は、それに近いビットレートを必要としません。

音声を削りすぎる

ロボットのように聞こえる小さな音声ファイルは、成功ではありません。ユーザーが内容を理解する必要があるなら、バイト削減より明瞭度が重要です。

単独話者の録音にステレオを使う

データを浪費し、低ビットレートのファイルをより悪く聞こえさせることがあります。

モバイルネットワークを忘れる

オフィスのWi-Fiでは瞬時に感じるファイルでも、混雑したモバイル接続では扱いづらく感じることがあります。

ブラウザサポートを固定的に考える

コーデックのサポートは変化します。特にユーザーに制限の厳しい企業デバイスや古いモバイルハードウェアが含まれる場合は、実際のブラウザとWebViewをテストしてください。

<!-- tool-cta:start -->

💡 お試しください: 配信形式を決定する前に、Audio Converterを使ってソースファイルのコーデックやビットレートを試してみましょう。

<!-- tool-cta:end -->

妥当なデフォルトレシピ

2026年のWeb音声に実用的なデフォルトが必要なら、ここから始めてください。

• WAVまたはFLACのマスターを保持する。
• 主要な配信にはOpusを使う。
• オーディエンスが必要とする場合はAACをフォールバックとして使う。
• 音声にはモノラルを使う。
• モノラル音声は40 kbps前後、整えられたナレーションは64 kbps、音楽は128 kbpsから始める。
• 明確な理由がない限りVBRを使う。
• audio要素には preload="metadata" または preload="none" を設定する。
• 出荷前に必ず聴く。

目標は最大限の圧縮ではありません。目標は、役割を果たしながら自分の存在を悪目立ちさせない、最小のファイルです。