メインコンテンツへスキップ

計測

認識が始まる前に、Macの音声入力が払うコスト

クラウド音声入力では、モデルが動く前に、接続のセットアップとアップロードのバイト数という固定コストがかかります。この2つのコストを1台のMacで計測し、それぞれのスクリプトを添えています。認識精度はここでは計測していません。数値で空白を埋めることはせず、そのことをこのページに明記します。

精度の数値は、まだここでは公開していません

このサイトにはVoice Typeの単語誤り率の実測値がなく、このページでも数値をでっち上げることはしません。公開する数値には、すべてそれを出したスクリプトを付けます。ただし単語誤り率のベンチマークは止まっています。アプリにヘッドレスで呼び出せる入口がないため、人がキーボードの前にいなければ、コーパスを認識エンジンに通せないからです。その入口ができるまでは、以下の数値はどれも精度の数値ではありません。通信とペイロードの数値であり、読む側が両者を取り違えないようにしてください。ベンダーが示す精度のパーセンテージは、私たちのものも含め、コーパス名と再現できるスクリプトがなければ意味がないものとして扱ってください。

クラウドへのリクエストが、音声を送る前に払う固定コスト

Apple M1 Pro、macOS 26.5.1 ビルド 25F80、自宅のWi-Fiで、2026-08-29に計測しました。エンドポイントごとに12回ずつ実行しています。APIキーも音声も送っていないため、計測した応答は認証なしの拒否応答です。推論を含まない、プロバイダのエッジまでの実際の往復にあたります。再現スクリプトは bench/connsetup.py --profile wifi --repeat 12、生データは bench/results/03-connection-setup-20260829T065129Z.json にあります。

エンドポイント音声を送る前のセットアップ時間(中央値)p95
api.openai.com30.9 ms61.0 ms
api.deepgram.com514.9 ms766.2 ms
デバイス上かかりませんかかりません

同じマシン、同じ回線、同じ時間帯で、よく運用されている2つのプロバイダの固定コストは17倍違います。Deepgramが遅いサービスというわけではありません。TCP接続の中央値252.9 msは、このMacから見てポイント・オブ・プレゼンスが遠いことを示しています。この数値には前提条件が付きます。macOSのDNSキャッシュは最初のリクエスト以降は温まっていたこと、1台のマシンで1つの回線の1時点の計測であること、そして実際のリクエストではこの下限に加えて、音声のアップロードとモデルの待ち時間も発生することです。

30分の音声入力はどれくらいの重さか

実際の音声をエンコードしてバイト数を計測しました。再現スクリプトは bench/payloadsize.py、生データは bench/results/05-payload-size-20260829T070405Z.json にあります。クラウドの認識エンジンは、最初の3行のいずれかを受け取る必要があります。デバイス上の認識エンジンは、どれも受け取りません。

30分の音声入力をアップロード量
48 kHz WAV(無加工)172.8 MB
16 kHz WAV57.6 MB
Opus 24k5.25 MB
デバイス上0バイト

非可逆圧縮の行に影響する注意点があります。この計測では人の声ではなく、合成音声の say コーパスをエンコードしました。OpusとAACは可変ビットレートなので、サイズは内容によって変わります。WAVの行には影響しません。

認識エンジンが実際に受け取るもの

Whisper系のモデルは、かなり狭い音量範囲の16 kHzモノラル音声を想定しています。一方、MacBookのマイクは、部屋の状況や座る位置で決まる音量の48 kHz音声を出力し、その下には机を叩く音や建物の低い振動音が混ざっています。この差を埋めるのが前処理の連なりです。各段階は特定の欠点を1つずつ補正し、後の段階は前の段階が実行済みであることを前提にしているため、順序が決まっています。

macOS上のVoice Typeのウィンドウ。Custom Vocabularyのペインが表示されています。Custom Wordsの欄にはカンマ区切りで用語を入力でき、Find and Replaceのリストには、open parenthesisのような話し言葉を、挿入される文字に対応づける108件の項目が入っています。
アプリのカスタム語彙と、話し言葉の句読点の置き換え。加工していないmacOS上のVoice Typeのスクリーンショットです。

各段階と、それぞれが補正する欠点

  • Silero音声区間検出: ストリーミングの音声ゲートが発話区間を見つけます。無音や一定の背景ノイズはデコードに届かず、認識エンジンが扇風機の音を文字にしようとすることはありません。
  • ハイパスフィルタ: 50 Hzのハイパスフィルタで、机を叩く音、足音、建物の低い振動音を除きます。これらは音声帯域より下にあり、ヘッドルームを食ってしまいます。
  • ラウドネスの正規化: K特性による正規化で、マイクとの距離の違いや、話の途中で背もたれに寄りかかったときの音量のぶれを補正します。目標値は経路によって異なり、ファイルの文字起こしは−14 LUFS、ライブの音声入力は既定で−16 LUFS、別構成のライブでは−18 LUFSです。
  • 帯域制限つきのリサンプリング: ローパスを通して48 kHzから16 kHzに変換します。8 kHzを超える成分が、話者が出していないエイリアシングとして音声帯域に折り返すことはありません。
  • 補正用のプロンプト層は使いません: 書き起こしに対して、強引なLLMによる整形は行いません。整形すると、出力は自信ありげに読める一方で、実際に話した内容からずれていきます。ずれが目に見えないので、これは精度の失敗の中でも最も悪質です。

この連なりのどの段階でも直せないもの

  • 質の悪いマイク: 前処理は、そこにある音の大きさを調整し、フィルタをかけるだけです。収録されなかった音声のエネルギーを取り戻すことはできません。
  • 重なって聞こえる別の話し声: ゲートが検出するのは音声です。ほかの人の話し声も音声なので、通過します。
  • モデルが見たことのない固有名詞: カスタム語彙は役立ちますが、珍しい姓や社内のコードネームは、それでも誤って出力されることがあります。
  • カテゴリの取り違え: 本当に必要なのがmacOSのハンズフリー操作なら、どの音声入力アプリも音声コントロールの代わりにはなりません。

技術的な詳細はこちら