音声形式はAI英会話の認識にどう効くのか。圧縮と非圧縮の違いを公式仕様から分解した

AI英会話アプリに同じ英文を吹き込んでも、機械の受け取り方は音声形式によって変わる。

同じ声、同じ発音、同じマイクでも、音をどう詰めて送るかで認識の土台が変わるからだ。

そして、人間の耳には差が分からない圧縮でも、認識エンジンには差が出ると公式ドキュメントが明記している。

ここは周波数の話とは別の層にある。

どれだけ細かく音を刻むかではなく、刻んだデータをどう保存・送信するかの選択である。

この記事では、グーグル・マイクロソフト・OpenAIが公開している開発者向けドキュメントの記述だけを材料にして、音声形式の選び方を分解する。

サービスの順位づけはしない。

仕組みの話だけをする。

【結論】AI英会話の音声形式は、非圧縮か可逆圧縮を選んだときに損をしない

先に答えを置く。

グーグルの Speech-to-Text のベスト プラクティスは、録音と送信には可逆コーデックを使うことを勧め、FLAC または LINEAR16 を推奨と書いている。

そのうえで「mp3、mp4、m4a、mu-law、a-law などの非可逆コーデックを録音や送信に使うと精度が下がることがある」と続けている。

分類	代表的な形式	情報が失われるか	認識への向き
非圧縮	LINEAR16（リニアPCM）	失われない	推奨されている
可逆圧縮	FLAC	失われない	推奨されている
非可逆圧縮	MP3・MULAW・AMR など	失われる	可能なら避ける

⇒ 音声形式の選択は「音質の好み」ではなく、機械に渡す情報を削るかどうかの選択である。

AI英会話を使う側が直接いじれる項目ではないが、なぜアプリによって認識のされ方が違うのかは、ここを知ると説明が付く。

AI英会話で言う「音声形式」と「エンコード」は同じものではない

最初に混乱の元をつぶしておく。

グーグルの 音声エンコードの入門には、「オーディオ形式はオーディオ エンコードと同じではない」と明記されている。

例として挙がっているのがWAVだ。

WAVはファイルのヘッダの形を定めたものであって、それ自体はエンコードではないと書かれている。

• WAVは多くの場合リニアPCMを使うが、常にそうとは限らない。
• ヘッダを見るまで、どのエンコードかを決めつけてはいけないと書かれている。
• FLACは例外で、ファイル形式でもありエンコードでもある。

「拡張子が同じなら中身も同じ」という前提が、ここでは成り立たない。

AI英会話の音声形式は3つに分かれる（非圧縮・可逆圧縮・非可逆圧縮）

分類そのものが、公式ドキュメントの章立てになっている。

非圧縮の代表として挙げられているのがパルス符号変調（PCM）だ。

設定した間隔で音を標本化し、その時点の振幅をビット深度の分だけ数値として保存する。

公式は「リニアPCMで符号化された1チャンネルのバイト列は、16ビット（2バイト）ずつ数えれば次の振幅値が取り出せる」と説明している。

可逆圧縮は、データの並べ替えで小さくするが、元に戻したときに情報が失われない方式だ。

非可逆圧縮は、圧縮の過程で情報そのものを削る方式である。

方式	公式の説明	元に戻せるか
非圧縮（LINEAR16）	そもそも圧縮していない	戻す必要がない
可逆圧縮（FLAC）	複雑な並べ替えで縮めるが品質は劣化しない	完全に戻せる
非可逆圧縮（MP3ほか）	一部の情報を取り除いて縮める	戻せない

公式は「Cloud Speech-to-Text が対応する可逆エンコードはFLACとLINEAR16の2つ」とし、LINEAR16は圧縮自体を行わないので厳密には可逆圧縮ではないと注記している。

そして、ファイルサイズや転送量が問題になるならFLACを使うよう勧めている。

FLACには0（最速）から8（最小サイズ）までの圧縮レベルがあるが、レベルを上げても情報は失われず、変換にかかる計算量が増えるだけだと書かれている。

AI英会話の裏側が受け取れる音声形式の一覧

対応コーデックは公式ドキュメントに表として載っている。

コーデック	名称	可逆か	公式の注意書き
FLAC	Free Lossless Audio Codec	可逆	ストリームでは16ビットまたは24ビットが必要
LINEAR16	リニアPCM	可逆	16ビットのリニアPCM。ヘッダにサンプルレートが必要
MULAW	μ-law	非可逆	8ビットのPCMエンコード
AMR	Adaptive Multi-Rate Narrowband	非可逆	サンプルレートは8000 Hzであること
AMR_WB	Adaptive Multi-Rate Wideband	非可逆	サンプルレートは16000 Hzであること
OGG_OPUS	Ogg コンテナに入ったOpus	非可逆	8000・12000・16000・24000・48000 Hzのいずれか
SPEEX_WITH_HEADER_BYTE	Speex wideband	非可逆	サンプルレートは16000 Hzであること
WEBM_OPUS	WebM Opus	非可逆	8000・12000・16000・24000・48000 Hzのいずれか

MP3も一覧に載っているが、公式は「MP3エンコードはベータ機能で、v1p1beta1 でのみ利用できる」と但し書きを付けている。

また、WAVファイルについては「LINEAR16またはMULAWでエンコードされた音声に対応する」と書かれている。

同じ拡張子のWAVでも、中のエンコード次第で扱いが変わるということだ。

AI英会話で非可逆圧縮が不利になる理由は、人間の耳を基準にしていることだ

この節が、この記事でいちばん大事なところだ。

公式ドキュメントは、非可逆圧縮について次のように書いている。

非可逆圧縮によるデータの除去は人間の耳で聞く分には気づかれないかもしれないが、音声認識エンジンにとってはそのデータの欠落が精度を大きく下げることがある、と。

MP3の圧縮技術は、そもそも「人間の通常の可聴域の外側の音を取り除く」ものだと説明されている。

削る基準が人間の耳なので、機械が使っていた手がかりが一緒に消えても、聞いている本人には分からない。

ビットレートで見ると差の大きさが分かる。

音源	実効ビットレート	公式の計算
CDのステレオ（16ビットのリニアPCM）	1411 kbps	44100 × 2チャンネル × 16ビット
MP3（高ビットレート）	320 kbps	公式が例示した値
MP3（中ビットレート）	128 kbps	公式が例示した値
MP3（低ビットレート）	96 kbps	公式が例示した値

MULAWについても、公式は「振幅を線形ではなく対数的に変調する8ビットのPCMエンコードで、実効的なダイナミックレンジが狭くなる」と説明している。

そのうえで、μ-lawは音声の符号化に最適化して導入されたものではあるが、16ビットのLINEAR16のほうが8ビットのμ-lawよりはるかに優れていると書いている。

ビット深度の目安も併記されており、音楽CDが16ビット、DVDオーディオが24ビット、電話機器の多くが8ビットとされている。

電話の音声が聞き取りにくいのと、機械の認識が落ちやすいのは、同じところに原因がある。

AI英会話でどうしても非可逆圧縮を使うときの順番も決まっている

帯域を節約したい事情は現実にあるので、公式もその場合の推奨を書いている。

ベスト プラクティスには、アプリケーションが帯域節約のために非可逆コーデックを使わざるを得ない場合、AMR_WB、次に OGG_OPUS の順で推奨すると書かれている。

また、対応していないエンコードの音声が手元にある場合は、可逆のFLACまたはLINEAR16へ変換するよう勧めている。

• まず可逆（FLAC / LINEAR16）を検討する。
• 帯域の制約があるなら AMR_WB。
• それでも足りなければ OGG_OPUS。

同じベスト プラクティスには、過度の背景ノイズやエコーは精度を下げることがあり、非可逆コーデックを併用しているとなおさらだという注意も書かれている。

つまり不利な条件は足し算ではなく、重なると効きが強くなる。

送信前のノイズ低減処理も、通常は認識精度を下げる。

自動ゲイン調整も、使わないほうがいい。

AI英会話の音声形式は、ヘッダの有無で扱いが変わる

形式の話には、もうひとつ実務上の落とし穴がある。

公式ドキュメントは「FLACは音声データにヘッダを含めることを求める唯一のエンコードで、それ以外のエンコードはヘッダのない音声データを指定する」と書いている。

そしてWAVとFLACについては、エンコードとサンプルレートを指定しなくてよいとされている。

省略した場合はファイルのヘッダから自動判定されるが、ヘッダの値と食い違う値を指定するとエラーが返ると明記されている。

音声の状態	設定でやること	間違えたときに起きること
ヘッダのあるファイル（WAV・FLAC）	指定を省略して自動判定に任せる	食い違う値を書くとエラー
ヘッダのないデータ	エンコードとサンプルレートを明示する	合っていないと結果が空で返り得る

グーグルの Speech-to-Text の基本にも、音声が認識できないときの典型的な原因として「言語コード、エンコード、サンプルレートの値が送った音声と一致していない」ことが挙げられている。

認識が空で返るのは、必ずしも発音の問題ではないということだ。

AI英会話のモデルを鍛える側では、音声形式の要件がさらに細かい

認識させるときより、学習データを渡すときのほうが要件は厳しい。

マイクロソフトの トレーニングとテストのデータセットには、カスタム音声プロジェクトが求める音声ファイルのプロパティが表で示されている。

プロパティ	求められる値
サンプル形式	PCM、16 ビット
チャンネル数	モノラル（1チャンネル）
サンプル レート	16,000 Hz または 8,000 Hz
ファイル形式	RIFF (WAV)
アーカイブ形式	.zip

ここでも指定されているのはPCMの16ビットで、非可逆圧縮された音声は選択肢に入っていない。

同じページには、既存の音声を要件に合わせるためのSoXのコマンド例まで載っている。

マイクロソフトの 音声を認識する方法でも、既定の形式は「16 ビット、16 kHz のモノラル パルス コード変調 (PCM) データ」と書かれている。

会社が違っても、既定として置かれている形式はほぼ同じところに収束している。

AI英会話をリアルタイムでつなぐときに指定する音声形式

リアルタイムの会話になると、形式の指定はセッションの設定の中に入る。

OpenAIの Realtime conversations のドキュメントでは、セッション更新の例として入力側に "type": "audio/pcm" と "rate": 24000 が示されている。

出力側の例には audio/pcm のほか audio/pcmu も登場する。

一方、録音済みのファイルを丸ごと投げる経路では、受け付ける形式の一覧が示されている。

OpenAIの ファイルの文字起こしのドキュメントには、「ファイルは最大25 MBまで。対応する入力形式は mp3、mp4、mpeg、mpga、m4a、wav、webm」と書かれている。

• リアルタイム経路＝生のPCMをそのまま流す設計になっている。
• ファイル経路＝非可逆圧縮された形式も受け付ける。
• 受け付けることと、精度が最良になることは別の話である。

AI英会話のリアルタイム会話が生のPCMを前提にしているのは、途中で情報を削らないためだと読める。

AI英会話の音声形式に関するよくある質問

Q. 手元の録音がMP3しかない。変換したほうがいいのか。 A. 公式は、対応していないエンコードの音声は可逆のFLACまたはLINEAR16へ変換するよう勧めている。ただしMP3から変換しても、すでに削られた情報は戻らない。

Q. 聞いた感じでは差が分からない。それでも形式は関係するのか。 A. 公式ドキュメントは、非可逆圧縮によるデータの除去は人間の耳では気づかれないかもしれないが、音声認識エンジンにとっては精度を大きく下げることがあると書いている。

Q. FLACの圧縮レベルを上げると音が悪くなるのか。 A. 公式は、FLACの圧縮レベルは0（最速）から8（最小サイズ）で、レベルを上げても低いレベルと比べて情報は失われないと書いている。

変わるのは計算量だ。

Q. WAVで渡せば安心か。 A. WAVはヘッダの形式であってエンコードではないと公式が明記している。

Cloud Speech-to-Text が対応するのはLINEAR16またはMULAWでエンコードされたWAVだと書かれている。

Q. スマホのマイクで話すとき、使う側が形式を選べるのか。 A. 通常はアプリ側が決めている領域だ。ここで書いた内容は、使う側が設定する手順ではなく、認識の差がどこから来るのかを読み解くための材料である。

まとめ｜AI英会話の音声形式は、機械に渡す情報を削るかどうかの選択だ

もう一度整理する。

• 公式が推奨するのは可逆コーデックで、名指しされているのはFLACとLINEAR16だ。
• 非可逆圧縮は人間の耳を基準に情報を削るため、認識エンジンが使っていた手がかりも一緒に消えると公式が書いている。
• 帯域の都合でやむを得ない場合の推奨順はAMR_WB、次にOGG_OPUSと明記されている。
• WAVは形式であってエンコードではない。ヘッダと食い違う指定はエラーになる。
• 学習データ側の要件はRIFF (WAV)・16,000 Hz または 8,000 Hz・モノラル・PCM 16ビットと具体的に定められている。

⇒ 音声形式は音質の話に見えて、実際には「機械に届く情報量」の話だ。

AI英会話で認識のされ方に差を感じたとき、その差が声ではなく経路の側にある可能性は、公式ドキュメントの記述から十分に読み取れる。

※本記事の一次ソースは、各公式ドキュメントを2026-09-16および2026-09-18に取得した生テキストで確認した。

仕様は更新されるため、最新は各公式ドキュメントで確認してほしい。