通信量はAI英会話でどれくらい使うのか。音声データの量を公式の仕様値から計算した

公開日 2026年9月19日(土) 12:20更新日更新なし

外出先でAI英会話を使うとき、気になるのは通信量だ。

動画ほどではないだろう、という感覚はある。

ところが「どれくらい」を数字で答えている解説はあまり見かけない。

実のところ、音声の通信量は公式ドキュメントに書かれている仕様値から計算できる。

必要なのは、サンプリングレートとビット深度という2つの数字だけだ。

この記事では、AIの音声部品を売っている会社の公式ドキュメントに書かれた仕様値を材料にして、通信量の桁を計算していく。

サービスの順位づけはしない。仕組みの話だけをする。

TOC

【結論】AI英会話の通信量は「音の作り方」で何倍も変わる

先に答えを置く。

音声をそのまま送る方式（無圧縮）か、圧縮して送る方式かで、通信量は大きく変わる。

そしてどちらを使うかは、利用者ではなくサービスの作り手が決めている。

⇒ 同じ「1時間の英会話」でも、アプリによって使う通信量は同じにならない。

以下の計算は、公式ドキュメントに書かれた仕様値をもとにこちらで計算したものだ。

⛔ 各サービスが実際に使う通信量が公式に書かれているわけではない。桁を知るための目安として読んでほしい。

AI英会話の通信量を決めるのは2つの数字だけだ

Google Cloud の音声エンコーディングの公式解説は、デジタル音声の基本を2つに整理している。

サンプリングレート＝1秒あたり何回、波の高さを測るか。
ビット深度＝1回の測定を何ビットで記録するか。

そのうえで、無圧縮の代表である Linear PCM についてこう書いている。

「Linear PCM uses a sample rate of 44,100 Hz within CDs, which is appropriate for the recomposition of music; however a sample rate of 16000 Hz is more appropriate for recomposing speech.」（Audio encoding・Google Cloud）

⇒ 会話には 16000 Hz で足りる。音楽用の44,100 Hz は要らない。

ビット深度については「both standards contain 16 bits of depth」と書かれており、16ビット＝2バイトだ。

同じページには、バイトの数え方まで書いてある。「Reading a one-channel stream of bytes encoded using Linear PCM, you could count off every 16 bits (2 bytes), for example, to get another amplitude value of the waveform.」

AI英会話の通信量を実際に計算してみる

材料がそろったので、掛け算をするだけになる。

1秒あたりのバイト数＝サンプリングレート × 1回あたりのバイト数 × チャンネル数。

条件	1秒あたり	1分あたり	1時間あたり
16000 Hz・16ビット・1チャンネル	32,000バイト	約1.9MB	約115MB
24000 Hz・16ビット・1チャンネル	48,000バイト	約2.9MB	約173MB
44100 Hz・16ビット・2チャンネル（CD相当）	176,400バイト	約10.6MB	約635MB

24000 Hz を並べたのは、音声対話APIの公式設定例がその値だからだ。

公式ドキュメントの例には "rate": 24000 という指定があり、本文でも「This example uses 24 kHz PCM audio」と書かれている（Live transcription・OpenAI）。

⇒ 無圧縮のまま24kHzで送ると、片道だけで1時間あたり170MB前後の桁になる。

CD音質と比べれば軽いが、テキストのやりとりとは桁が3つ違う。

Base64で送るAI英会話は通信量がさらに増える

ここに、もうひとつ効く要素がある。

WebSocket で音声を送る場合、公式はこう書いている。

「This event requires you to send chunks of Base64-encoded audio bytes to the Realtime API over the socket.」（Managing conversations・OpenAI）

Base64 は、3バイトのデータを4文字に置き換える方式だ。

⇒ データの量はおよそ 4 ÷ 3＝約1.33倍になる。

送り方	24kHz・16ビット・1チャンネルの1時間
そのまま送る	約173MB
Base64にして送る	約230MB

同じ音でも、包み方を変えるだけで数十MBの差が出る計算になる。

なお公式は、WebRTC を使う場合は「much of the media handling … is assisted by WebRTC APIs」と書いており、音の運び方が別の仕組みに任される形になる。

AI英会話の通信量は行きと帰りの両方で発生する

見落としやすいのが、返ってくる音声ぶんだ。

公式は、返答の音声が分割されたイベントとして届くと書いている。

「you will need to listen for response.output_audio.delta events containing the Base64-encoded chunks of audio data from the model」。

⇒ AIの声も、同じようにBase64の固まりとして流れてくる。

会話は交互に進むので、合計はおおよそ「自分が話した時間＋AIが話した時間」ぶんになる。

黙っているあいだも音を送り続ける作りなら、沈黙にも通信量がかかる。

ここは製品ごとの実装によるので、仕様からは決まらない。

通信量を減らしたいAI英会話に公式が勧める順番

帯域を節約したい場合の指針も、公式に書かれている。

「If your application must use a lossy codec to conserve bandwidth, we recommend the AMR_WB or OGG_OPUS codecs, in that preferred order.」（Best practices・Google Cloud）

⇒ どうしても圧縮するなら、AMR_WB、次に OGG_OPUS。

ただし同じページは、そもそも圧縮そのものが精度を下げうると書いている。

「Using mp3, mp4, m4a, mu-law, a-law or other lossy codecs during recording or transmission may reduce accuracy.」

無圧縮のまま量を減らしたいなら、ロスレス圧縮という別の道もある。

公式は「If file size or data transmission is important to you, use FLAC.」と書いており、品質を落とさずに量を減らす選択肢として FLAC を挙げている。

AI英会話の通信量は音の刻み方でも変わる

送る単位の大きさについても、公式は目安を出している。

「Any frame size is acceptable. Larger frames are more efficient, but add latency. A 100-millisecond frame size is recommended as a good tradeoff between latency and efficiency.」

⇒ 大きく刻めば効率はよくなるが、返事が遅くなる。100ミリ秒がその折り合いだ。

ここに、通信量と体感速度のトレードオフがはっきり書かれている。

細かく刻むほど、1回ごとの付随データ（ヘッダーやJSONの枠）が積み上がるからだ。

反応の速いAI英会話ほど、同じ音声量でも通信の回数が多くなる構造になっている。

AI英会話の1回の送信には15MBという上限がある

送る側の上限も明記されている。

「Each chunk cannot exceed 15 MB in size.」

先ほどの計算に当てはめると、24kHz・16ビット・1チャンネルの音声なら、15MBはおよそ5分半ぶんにあたる。

⇒ ふつうの会話で1回の送信がこの上限に当たることは、まずない。

100ミリ秒ずつ刻んで送るなら、1回あたりは数キロバイトで済む。

この上限が効いてくるのは、録音済みの長い音声を一度に投げようとしたときだ。

AI英会話の通信量を減らすために利用者側でできること

仕様の大半はサービス側が握っているが、手がないわけではない。

会話の時間そのものを短く区切る。通信量は時間に比例する形で増える。
黙って接続したままにしない。沈黙中も音を送る作りなら、その時間も加算される。
音声ではなくテキストで進められる部分は分ける。文字のやりとりとは桁が違う。
復習は録音のファイルを使う。会話をやり直すより、起こした結果を読むほうが軽い。

通信量の内訳は、英語の上達とは関係のない層にある。

だからこそ、量が読めれば使う場所と時間を選べる。

通信量とAI英会話に関するよくある質問

Q. 1時間のAI英会話で何MB使うのか。 A. サービスごとの実測値は公式に書かれていない。ただし公式の仕様値から計算すると、24000 Hz・16ビット・1チャンネルの無圧縮音声は1秒あたり48,000バイトで、1時間ではおよそ173MBになる。圧縮していれば、これより小さくなる。

Q. 音質を下げれば通信量は減るのか。 A. 通信量はサンプリングレートに比例する。公式は会話については 16000 Hz が適切だと書いており、音楽用の44,100 Hz は必要ないとしている。ただし設定を変えられるかどうかはサービス側の作り次第だ。

Q. 圧縮して送れば安心か。 A. 公式は「Using mp3, mp4, m4a, mu-law, a-law or other lossy codecs during recording or transmission may reduce accuracy.」と書いている。通信量と認識精度は逆を向く。どうしても圧縮が要る場合の推奨順として AMR_WB、次に OGG_OPUS が挙げられている。

Q. 反応が速いアプリほど通信量が多いのか。 A. 公式は「Larger frames are more efficient, but add latency.」と書き、100ミリ秒のフレームを折り合いとして勧めている。細かく刻むほど効率は落ちる方向になるが、実際にどう刻んでいるかは製品によって違う。

Q. 1回の送信に上限はあるのか。 A. 公式は「Each chunk cannot exceed 15 MB in size.」と明記している。100ミリ秒ずつ送る通常の会話では、この上限に当たることはまずない。