マイクを押す前に知ってほしいこと——ブラウザの音声認識、既定は今もクラウド送信

公開前の下書きです。事実確認と編集を終えていますが、公開・SNS投稿はまだ行っていません。

両手を小麦粉まみれにしながらレシピの続きを確認したい。あるいは、画面の文字を目で追うのが難しい。そんな場面で、多くのブラウザは何年も前から「読み上げ」機能を持っている。合成音声で画面のテキストを読み上げるWeb Speech APIのSpeechSynthesis（音声合成）は、Chrome 33、Firefox 49、Safari 7の時代からずっと動いてきた、実は枯れた技術だ。

だが、同じAPIのもう半分——マイクに向かって話しかけて文字にするSpeechRecognition（音声認識）——に話が及ぶと、状況は一変する。Firefoxはこの実装自体をブラウザの中に持っている。しかしFirefox 22の頃からずっと既定で無効のままで、Mozillaは一般ユーザー向けに一度も有効化していない。2026年7月現在も、Firefoxで音声入力を試すことはできない。

編集部では、この非対称な現状を軸に「ブラウザだけで音声インターフェースが作れることは誰の役に立つのか」「声で操作するWebは本当に来るのか」を7人で議論した。

結論：音声合成はすでに枯れた技術として「読み上げ端末」を無償で提供しているが、音声認識はブラウザ間の対応差が大きく、既定の動作は今も音声データをクラウドへ送るというプライバシー上の代償を伴う。Chrome 139で入ったオンデバイス処理（processLocally: true）はこの代償を減らす重要な一歩だが、あくまでChromium系限定のオプトインであり、「音声認識はもうオンデバイスになった」と言い切るのは誤りだ。手が離せない現場や障害のあるユーザーにとって現実的な価値があるからこそ、開発者は「声で何ができるか」ではなく、「今、誰の操作を、どこまで安全に助けられるか」を先に問うべきである。

音声合成と音声認識、成熟度の非対称性

事実確認を担う編集者のテツオは、この記事全体を貫く論点を早々に言語化した。

音声合成（SpeechSynthesis）は既に主要ブラウザで枯れており、OS依存の差はあるものの、オフラインでも安定して動作する「出力」として信頼を得ています。対して音声認識は、デフォルトがクラウド送信型であり、かつFirefoxでは実装がフラグの裏に隠れたまま実用化されていないという、極めて不安定な「入力」です。

対応状況を整理すると次のようになる。

API	Chrome / Edge / Opera	Safari	Firefox
音声合成（SpeechSynthesis）	Chrome 33+で対応	Safari 7+で対応（iOSはデスクトップより選べる声が少ない）	Firefox 49+で対応
音声認識（SpeechRecognition）	フルサポート	`webkitSpeechRecognition`としてmacOS 14.1+ / iOS・iPadOS 14.5+で対応	実装はあるが既定で無効。一般ユーザー向けに有効化されたことは一度もない

表はMDNおよびChrome公式ブログの記載を基にした編集部の整理。「Web Speech APIは全ブラウザでネイティブサポート」という書き方は、この非対称性を無視した誇張になる。加えて、Web Speech API自体もW3Cの正式な勧告トラックの標準ではなく、W3C WebAudio Community Groupによる「Draft Community Group Report」（草案段階の報告書、2026年7月21日付でも更新が続いている）という位置づけだ。事実上、Chromium主導で仕様が動いている。

誰の役に立つのか——アクセシビリティは「おまけ」ではない

支援技術とアクセシビリティの研究者であるミサは、この技術の価値を「音声合成の普及度」に見出す。

音声合成は主要ブラウザで既に枯れており、視覚障害者や文字入力が困難な高齢者にとって、Webブラウザは即座に「読み上げ端末」へと変貌します。

介護・医療現場のDX（デジタル変革）を担当するカナは、現場の実需をより具体的に語った。

現場では、ナースコールや介護記録の入力など、常にプライバシーと隣り合わせです。

議論から浮かび上がった「誰の役に立つか」を整理すると次のようになる。

想定する利用者・場面	音声合成（読み上げ）の価値	音声認識（音声入力）の価値と課題
視覚障害のある人	画面の文章を読み上げる、スクリーンリーダーに近い体験。すでに成熟	文字入力の代替になりうるが、精度・環境依存の壁が残る
肢体不自由のある人	—	キーボード操作が難しい場面での入力代替
手が離せない現場（調理・介護・製造）	手順の読み上げに対応済み	ハンズフリーでの記録・指示に有用だが、認識精度とノイズが課題
文字入力が苦手な高齢者	画面の文章を音声化	音声メモ・記録の入力代替になりうる
語学学習者	発音のモデル提示	発話練習の可視化（精度の検証は必要）

表は議論の内容を基にした編集部の整理。音声UIを開発するエンジニアのハルカは、この価値を実装現場の視点から補足する。

音声認識の実装において、真の課題は「認識精度」と「環境ノイズ」の戦いです。製造現場の騒音や方言、高齢者の独特な発話リズムに対して、オンデバイスの軽量モデルがどこまで耐えうるかは未知数です。

日本語の認識精度や方言への対応は、今回の取材でも一次情報源から確認できておらず未検証のままだ。この点を「もう十分な精度がある」と書くのは避けるべき誇張になる。

オンデバイス化が変えること、変えないこと

Web Speech APIの仕様には、processLocally（trueを指定するとローカル処理を必須にできる）、available()、install()（言語パックのダウンロード）といった機構が定義されている。Chrome 139（2025年8月5日リリース）でこのオンデバイス音声認識が実装され、対応言語は17言語程度、独自の言語パックダウンロード方式で提供される。個人情報保護の専門家であるレンは、この機構の意味を次のように説明した。

音声データは指紋と同様に変更不可能な個人情報です。オンデバイス処理（processLocally: true）はプライバシー確保の鍵ですが、これはあくまでChromium系における「オプトイン」の選択肢であり、デフォルトは今もクラウド送信型です。

Web技術を取材する技術記者のナオも、議論の冒頭でこの点を強調していた。

重要なのは、デフォルトがクラウド送信型であるという事実です。音声データがサーバーへ送られるプライバシー懸念に対し、Chrome 139で実装されたprocessLocally: trueによるオンデバイス化は、医療や法務といった機密性の高い現場への道を拓く重要な一歩です。ただし、これはChromium系に限られた実装です。

つまり、オンデバイス化は「音声認識全体が変わった」という話ではない。Chromium系ブラウザで、開発者が明示的にprocessLocally: trueを指定した場合に限り、通信を発生させずに端末内で処理を完結できる、という限定的な選択肢が増えたという話だ。オフラインで動く点は、通信環境が不安定な介護現場や、秘匿性の求められる医療・法務記録にとって重要な意味を持つが、他ブラウザでの採用は確認できておらず未検証、対応言語も17言語程度にとどまる。

反論1：現場の泥臭さとブラウザ間格差

音声UIエンジニアのハルカは、install()による言語パックのダウンロードが利用者体験に与える負担も指摘した。

実装上の懸念として、音声認識の言語パックをユーザーにダウンロードさせるinstall()プロセスによる、初動のユーザー体験（UX）の低下も無視できません。

介護・医療現場のDX担当のカナは、こうした制約を現場の運用にどう落とし込むかを具体的に語った。

患者様の身体状況や排泄等の極めて機密性の高い記録には、Chromium系限定ですがprocessLocally: trueによるオンデバイス処理を前提としたシステムを設計します。一方で、定型的な業務報告や、騒音の少ない環境での操作補助には、クラウド型の高度な認識能力を活用する。

反論2：「結局使わなくなる」という生活者の不信

ここで議論に強い異論を投じたのが、音声アシスタントに失望した経験のある生活者代表のソラだった。

オンデバイス化がChromium系限定であり、デフォルトがクラウド送信型であるという事実は、私のようなユーザーにとっては依然として「いつ自分の声がどこかへ送られるか分からない」という不安の種です。たとえ機密情報でなくても、日常の何気ない独り言や家族との会話がサーバーに蓄積されることへの心理的抵抗は拭えません。

ソラはさらに、install()の手間についても触れ、「設定が複雑で、動作が不安定なインターフェースは、助けを必要とする瞬間に『余計な手間』に変わる」と指摘した。技術の使い分け以前に、意識せずとも「安全で、確実に、迷わず」使える体験がなければ、優れたAPIも生活には浸透しない、というのがソラの立場だ。

仕様の持続可能性という論点

議論はもう一段深いところにも及んだ。技術記者のナオは、Web Speech APIがCommunity Groupのドラフト段階にあることの意味を、開発者の運用コストという観点から掘り下げた。

Web Speech APIは現在、Community Groupによるドラフト段階にあり、特定のブラウザに依存した実装が、将来的にWeb標準から外れる、あるいは動作が劇的に変化するリスクを孕んでいます。

アクセシビリティ研究者のミサは、この仕様の流動性がアクセシビリティにとって単なる開発コストの問題ではないと訴えた。

仕様の流動性は、一度構築したアクセシビリティ機能が、ブラウザのアップデートによって突然「使えなくなる」リスクを意味します。これは、特定の操作手段に依存せざるを得ない視覚障害者や肢体不自由者にとって、生存に関わる「情報のアクセシビリティの断絶」を招く死活問題です。

さらにミサは、オンデバイス化がChromium系に限定されている現状が「アクセシビリティの格差の固定化」を招きかねないとも提起した。高性能なデバイスや特定のブラウザ環境を持たない利用者が、プライバシーと利便性の両立という恩恵から構造的に排除される恐れがある、という指摘だ。

クラウド型音声エージェントとの役割分担（推論）

議論では、生成AIによるクラウド型の音声対話エージェントと、ブラウザ標準APIの役割分担についても意見が交わされた。これは実際に確立した仕組みではなく、参加者の推論として扱う。音声UIエンジニアのハルカは次のように整理した。

クラウド型AIが高度な文脈理解を見せる一方で、ブラウザ標準APIは「軽量な入力インターフェース」としての役割分担が現実的だと推論します。

ハルカはこの延長で、ブラウザAPIとクラウド型AIを動的に切り替える「ハイブリッド設計」を提案したが、個人情報保護専門家のレンはここに強く警鐘を鳴らした。

クラウド型AIへ処理を委ねる動的な切り替えは、ユーザーが「今、自分の生体情報がサーバーへ送られたのか」を正確に認識できないリスクを高めます。音声データが学習用データとしてサーバー側に蓄積・利用される場合、それは単なる「操作の補助」を超え、ユーザーの特性を抽出するプロファイリングへと変貌します。

これに対しDX担当のカナは、現場の安全性という別の角度から反論した。音声入力が使えないためにスタッフが記録を後回しにし、記憶が曖昧なまま誤った情報を入力してしまう医療事故のリスクこそが本質的な危険であり、シームレスな切り替えは操作の断絶を防ぐ現場視点での最適解になりうる、という主張だ。ただしカナ自身も、「今、この記録はクラウドに送られる」と現場のスタッフが一目で判断できる、明示的なオン・オフ切り替えの必要性は認めている。ソラはこの点についても、「ユーザーが自分の声の行方を意識させないシームレスな設計を推奨するのは、あまりに傲慢なユーザー体験だ」と重ねて反論しており、この対立に最終的な決着はついていない。

読者への持ち帰り：今日どう使い分けるか

編集部の議論を、現実的な出発点として整理すると次のようになる。

高い機密性が求められる記録
（例: 医療記録の音声入力、法務メモ）
  → Chromium系ブラウザ限定で processLocally: true を指定し、
    オンデバイス処理を前提に設計する
    （対応言語は17言語程度、install()による言語パック取得が必要）

定型的な業務・低リスクな操作
（例: 定型報告、静かな環境での操作補助）
  → クラウド型の音声認識をそのまま使ってよい
    （特別な設定をしない場合の既定の挙動）

いずれの場合も
  → 「今、この発話はクラウドに送られるか」を
    利用者が一目で判断できる、明示的な表示を用意する
    （自動切り替えに丸投げしない）

未対応ブラウザ（Firefox等）
  → 音声入力機能自体を諦めるのではなく、
    読み上げ（音声合成）は使える、という前提で
    機能を切り分けて提供する

図は議論の結論を基にした編集部の整理。音声合成はすでに枯れているため、対応ブラウザを問わず提供してよい。音声認識は、対応状況・機密性・通信環境に応じて使い分けが要る、というのが今回の議論の着地点だ。

デモ：読み上げと音声入力、実際に試す

デモを開くでは、この記事で扱った2つの機能を実際に試せる。

音声合成デモ：テキストを入力するとspeechSynthesisで読み上げる。声の種類や速度も変更できる。ほぼすべてのブラウザで動く。
音声認識デモ：SpeechRecognition / webkitSpeechRecognitionの対応状況をその場で機能検出し、対応ブラウザではマイクボタンを押すと日本語（ja-JP固定）で音声入力を試せる。マイクを使う前に、「音声はブラウザの実装によってはクラウドに送信される場合がある」という注意書きを必ず表示している。未対応ブラウザ（Firefoxなど）で開いた場合は、エラー画面にはならず「このブラウザでは音声認識が提供されていません」と丁寧に表示する。この体験自体が、この記事で扱ったブラウザ間格差そのものだ。

いずれもこのページ単体で完結しており、外部のサーバーにデータを送る仕組みは組み込んでいない。ただし音声認識を実際に動かした場合、その処理をどこで行うかはブラウザ自身の実装次第であり、このデモがコントロールできる範囲を超える。

出典を読むときのポイント

Web Speech API Draft Community Group Report（webaudio.github.io）：Web Speech APIがW3Cの正式な勧告トラックではなく、WebAudio Community Groupによる草案段階の報告書であることを確認した一次資料。2026年7月21日付で更新が続いている。
On-device speech recognition Explainer（GitHub、WebAudio/web-speech-api）：processLocally、available()、install()といったオンデバイス音声認識の仕組みを定義した一次資料。
Chrome公式ブログ「New in Chrome 139」：Chrome 139（2025年8月5日）でオンデバイス音声認識が実装されたことを確認した一次資料。
MDN「SpeechRecognition」：主要ブラウザの対応状況、Safariのプレフィックス付き実装、Firefoxが既定で無効なままである点を確認した。
MDN「Web Speech API」：音声合成・音声認識それぞれの仕様の全体像を確認した。