結論から言うと、オフラインの音声入力が速く感じられるのは、「話し終えた」から「テキストが表示された」までの手順が少ないからです。 クラウドの音声入力が最適な選択になることもありますが、ローカルのワークフローにはないネットワークとアップロードのコストがかかります。
TL;DR
- オンデバイスの音声入力は、アップロードとリモート処理の経路をループから取り除きます。
- 共有履歴、サーバー側の自動化、積極的なリライトのワークフローが必要なら、クラウドツールも優れた選択肢です。
- Appleの現在のMac向けガイダンスでは、音声入力の動作は設定によって異なることが明記されています。一般的なテキストの音声入力がオンデバイスで処理されるのか、Siriのサーバーに送信されるのかは、「キーボード」設定で確認できます。
- 音声コントロールも、1回限りのダウンロード後はオフラインで使えます。
- 毎日Macで音声入力を使うなら、本当に重要なのは精度だけではありません。ワークフローの遅延、つまり発話のたびに、1日中待たされる時間です。
- 精度は、モデルの大きさと同じくらい、入力の整え方や話し方に左右されます。
本当に重要な遅延の問題
1日に200回も起動するツールにとって、モデルの品質や機能一覧は的外れな軸です。使い心地を左右するのは、もっと絞られた問いです。
話し終えたあと、いくつの手順が発生するか?
遅延はどこから来るのか
このセクションで説明するのは計測値ではなく仕組みです。目的は手順に名前を付けることで、広告ページの数字を信じるのではなく、自分のMacで何を計測すればよいかが分かるようにすることです。
オンデバイスのワークフローでは、経路は通常次のとおりです。
- 音声をローカルで取り込む、
- ローカルでチャンクを処理またはストリーミングする、
- 未完了の末尾部分を確定する、
- テキストを挿入する。
クラウドの音声入力では、これに加えてネットワーク経路が入ります。
- 音声をローカルで取り込む、
- 接続を開く(DNS解決、TLSハンドシェイク、場合によっては認証)、
- 音声をアップロードする、
- リモートでの推論を待つ、
- 結果をダウンロードする、
- 場合によっては、別のリライトや整形のレイヤーを通す。
この2つ目のリストには、振る舞いが異なる2つの性質があるので、理解しておく価値があります。
接続の確立は、リクエストごとにほぼ固定のコストです。 DNS、TLS、認証にかかるコストは、2語を話しても2分話しても同じ程度です。長い録音であればこのコストは分散されますが、5秒のメモではまったく分散されません。つまり、普段の発話が短いほど、待ち時間のうち音声認識と無関係な部分の割合が大きくなります。持続的な接続やストリーミングプロトコルがこれを減らすため、「クラウドかローカルか」というラベルよりも実装の詳細のほうが重要になります。
転送時間は音声の長さに比例します。 認識品質は一般に、圧縮の少ない音声や非圧縮の音声に有利なので、長いセッションのペイロードは小さくありません。安定した接続では気になりません。ホテルやカフェのWi-Fiでは、これが変動する要因になります。
ローカルだからといって、魔法のように一瞬で終わるわけではありません。話し終えたあとにも処理は行われています。それでも、アップロードして戻ってくるループ全体と、自分では制御できないネットワークに左右される遅延の部分を取り除けます。
発話の長さやネットワーク条件を変えられるインタラクティブなデモで、この様子を自分で確かめられます:/blog/latency-demo。
ウィンドウ処理:長いセッションでも遅くならない理由
素朴なローカル実装は、話し終えるのを待ってから録音全体を文字起こしします。これではアップロードと同じスケーリングの問題が起こります。30分の音声は30分の音声のままだからです。
ストリーミング実装では、話している間に、上限のあるバッチでデコードすることでこれを避けます。話し終えたとき、仕上げる必要があるのは最後の未完了のバッチだけです。
Voice Typeはこの方式で動作し、バッチ目標は29秒、範囲は15〜29秒に制限されています。バッチは固定長のウィンドウではありません。バッチャーは発話区間をまるごと蓄積し、境界で区間を途中で切ることはしないため、目標をまたぐことになるフレーズは次のバッチから始まります。実際上の結果として、話し終えたあとの待ち時間は、セッションの長さではなくバッチ目標で上限が決まります。2分の音声入力でも30分の音声入力でも、最後に残る作業量は同じです。
これはアーキテクチャ上の性質であり、ベンチマークではありません。最後の処理に実際にかかる時間はお使いのMacによって異なるので、ご自身のMacで計測することをおすすめします。
クラウドの音声入力:要素は増えるが、正しい選択になることもある
クラウド経路の追加ステップは、製品が価値のあることをしているなら、それだけの意味があります。
- チームの履歴、
- アカウント単位の同期、
- サーバー側のプロンプトやテンプレートのパイプライン、
- より大規模な会議やファイルの処理、
- 粗い話し言葉の入力を改善する後処理。
「クラウドは悪い」という話ではありません。クラウドにはボトルネックになりうる要素が多いという話です。
Appleの位置づけ
Apple自身のスタックも、いまやこの議論の中心にあります。
現在のサポートページから、次の2点が分かります。
- 一般的なテキストの音声入力は、設定に応じてオンデバイスで処理されるか、Siriのサーバーに送信されることがある、
- 音声コントロールは1回限りのダウンロードが必要で、その後はインターネットなしで使える。
つまり、「Macの音声入力」は固定された単一のアーキテクチャではありません。次の条件によって変わります。
- ハードウェア、
- 言語と地域、
- 使っている機能、
- 音声入力と音声コントロールのどちらを使っているか。
一般的な比較記事がすぐに古くなる理由のひとつがこれです。「Macの音声入力」を、あたかもひとつの静的な製品のように語っているのです。
日常的に使う人のほうが違いに気づきやすい理由
音声入力を週に1段落しか使わないなら、ローカルとクラウドの差はあまり気にならないかもしれません。
1日に数十回、数百回と使うなら、小さな遅延が積み重なります。
- 接続を待つ、
- アップロードの完了を待つ、
- 応答を待つ、
- テキストを「磨く」2回目の処理を待つ。
オンデバイスのワークフローが優位に立つのはここです。絶対的な遅延は必ずしも大きくありません。コストを高くするのは繰り返しです。最良のケースよりも一貫性が重要です。回線の悪いWi-Fiでも予測できるワークフローは、良いWi-Fiでは速くても悪いWi-Fiでは使い物にならないワークフローに勝ります。
精度はモデルだけの問題ではない
モデルの大きさはどの製品ページでも最初に掲げられる数字ですが、いくつかある要因のひとつにすぎません。実際の使用では、精度は次の要素に左右されます。
- マイクの品質、
- 室内のノイズ、
- エコー、
- 入力ゲイン、
- 音声のセグメント化、
- 語彙のミスマッチ、
- そして、集中を切らさずに話し続けられるワークフローかどうか。
だから「最大のモデルを使っています」という主張だけでは、Slack、Gmail、Linearの中で実際にそのアプリがどう感じられるかは分かりません。
認識の前に入力を整える
音声モデルは、特定の特性を持つ音声で学習されています。入力がその分布に近いほど、モデルが推測する部分は少なくなります。主な効果は次の3つの調整によるものです。
- ラウドネスを正規化して一定の目標にそろえます。身を乗り出して話しても、背もたれに寄りかかって話しても、言葉が同じようなレベルで届きます。
- 低周波のランブルノイズを除去します。軽いハイパスフィルタを使います。机を叩く音、空調、建物のノイズには、音声ではないエネルギーが含まれています。
- ノイズを考慮した音声区間検出(VAD)を使い、無音や背景音が言葉として認識器に渡されないようにします。
Voice Typeは、認識の前にこの3つをすべて適用します。ライブ音声入力の出荷時のデフォルトは、ラウドネス目標がマイナス16 LUFS、ハイパスが50 Hzで、どちらもアプリのオーディオ設定で確認・調整できます。考え方としては、出力にパッチを当てるより、信号を改善するほうが誠実です。プロンプトによる大がかりな「修正」は、実際に話した内容からずれていきながら、自信ありげな文字起こしに見せてしまうことがあります。
個々のコンポーネントに関する関連記事:音声区間検出、16 kHzへのリサンプリング。
この順序で行う2つのステージ。ラウドネス目標は単一の数値ではなく、音声がどの経路を通ったかによって決まります。出典:WhisperState+FileTranscription.swift、WhisperState.swift。
句読点と文の区切り
句読点は、うまくいかないときにだけ気づくものです。句点が抜ける。スペースが二重になる。固有名詞のところで文が分かれる。
その多くはセグメント化の問題に行き着きます。入力の整え方や話し方が直接影響するのはそのためです。ラウドネスの変動は文の境界と受け取られることがあります。室内のノイズは、モデルが文を確定するために使うポーズをぼやけさせます。
どのマイクでも役立つ習慣:
- 句点のところで、ほんの少し長めに間を置く。 半拍の間があれば、きれいな境界の合図になります。
- 正確さが必要なときは、リストの区切りを声に出して言う。 厳密なリストやコードでは、「comma」と声に出して言えば推測の余地がなくなります。
- 音量を一定に保つ。 大きな声を出すより、マイクに近づいて話しましょう。ボリュームが大きい信号より、きれいな信号のほうが優れています。
- カスタム単語を追加する。 一般的な辞書にない製品名や専門用語は、登録するとアンカーになり、長いメモでの修正が減ります。
- ノイズ抑制を使えるなら、弱めに保つ。 強すぎるゲートは子音を欠けさせ、欠けた子音はノイズよりもコストが大きくなります。
どんな音声入力の設定でも、自分のマシンで手軽に試す方法があります。「period」という言葉を言わずに、次の1行を空のドキュメントに向かって読み上げてください。
Aeloria and Kyran left Eldmere at dawn. They crossed the Kintara ridge before the fog rolled in. Skystack Nova ships next week.
架空の固有名詞と普通の文構造が混ざっているので、未知の語彙と文の区切りの両方を、一度に確認できます。通常の距離で一度、マイクを近づけてもう一度行い、比べてみてください。
プライバシーは機能ではなく、構造上の違い
オンデバイスの音声入力では、音声がマシンの外に出ないため、読むべき保持ポリシーも、録音を預けて信頼すべきベンダーもありません。クラウドの音声入力では、設計上、音声がマシンの外に出るので、プライバシーの問題は特定のベンダーの取り扱いの問題になります。
Voice Typeは音声入力をローカルで行います。例外はオプションのLLMリライトで、これはオプトイン方式です。テキストは当社のサーバーを経由せず、お客様が指定したキーのプロバイダーに、Macから直接送信されます。詳細はトラストセンターとプライバシーポリシーをご覧ください。
Voice Typeの位置づけ
Voice Typeは、繰り返し使うケースを中心に作られています。ホットキーを押し続けて話し、離すと、ローカルでテキストが返ってきます。前述のローリングウィンドウの動作もあります。
これは、次のような用途に注力するツールとは別の役割です。
- ファイルの文字起こし、
- 会議の録音、
- クラウドでのリライト、
- 共有されるサーバー側の履歴。
スローガンではなくカテゴリーで比較したいなら、次のページのほうが役に立ちます。
クラウドが今も優れる場面
次のような場合は、クラウドのほうが適しています。
- チーム全体で文字起こしを共有したい、
- サーバー側の保存と検索が必要、
- 長文の音声入力ドラフトに自動の後処理をかけたい、
- プライバシーよりも一元化に依存するワークフロー、
- ローカルの計算資源ではなく、マネージドなインフラを使いたい。
正直な結論は「ローカルがクラウドに勝つ」ではありません。次のとおりです。
ボトルネックが操作の速さなら、ローカルが優れます。ボトルネックが共同作業、サーバー側の処理、一元化されたワークフローなら、クラウドが優れます。
どちらを選ぶべきか
次の基準を使ってください。
| 最も重視することは… | より適した選択 | | --- | --- | | Macのアプリへの、速くて繰り返しの多い音声入力 | オンデバイス | | ローカルでのプライバシーモデル | オンデバイス | | 共有履歴とサーバー側の自動化 | クラウド | | ファイルのアップロードと文字起こしの管理 | クラウド、またはファイル文字起こしツール | | アクセシビリティ向けの音声操作 | Appleの音声コントロール |
実践的な次のステップ
まだ迷っているなら、次のことを試してください。
- 数日間、実際のマイクと実際のアプリでAppleの音声入力を使う。
- 長い録音だけでなく、短い発話のあとの遅延にも注意する。
- 不安定なネットワークで同じテストを繰り返す。2つのアーキテクチャの差が出るのはそこです。
- 内蔵ツールで十分なら、それを使い続ける。
- 書くことより、ワークフローのことばかり考えてしまうなら、専用のローカルアプリを試す。
ローカルでのMacの使い方を知りたい方は、こちらから:
出典
- Apple Support: Dictate messages and documents on Mac
- Apple Support: If Dictation on Mac doesn’t work as expected
- Apple Support: Get started with Voice Control on Mac
- OpenAI research: Whisper overview
- Paper: Robust Speech Recognition via Large-Scale Weak Supervision