何が発表されたか
Googleが音声認識・文字起こしに特化したAIモデル「Gemini 3.5 Transcribe」を発表しました。従来モデルより精度が高く、85言語以上を自動的に検出するとしています。
特徴は「録音を文字に変換する」以上のところにあります。話し言葉の言い直しを自然に処理し、フィラーワードを取り除いて整形されたテキストを出力する。音声コマンドでの編集にも対応します。さらに固有の語彙や独自のつづりを学習でき、注文番号や郵便番号といった英数字混じりの文字列を正確に拾うとされています。事前録音された音声であれば、最大3人までの話者を単語単位のタイムスタンプ付きで割り当てられ、ポッドキャストの書き起こしなどが想定されています。
展開先も広い。Pixel 11シリーズなどAndroid端末の「Rambler」機能、macOS版のGeminiアプリ（ここでは他のGeminiモデルと連携してエージェント的なタスクを実行）、そしてエージェント型開発環境のGoogle Antigravityで既に利用可能です。今後はSearch Live、Gemini Live、Docs、Keep、Gmailにも展開され、Chromeではウェブページの任意の入力欄で音声入力ができるようになるとしています。返信や投稿の口述、音声によるGeminiへの指示が想定用途です。開発者向けにはAPIが提供されます。
なぜ重要か
これは「文字起こし精度が上がった」というスペック競争の話ではありません。押さえるべきはGoogleが音声を「入力方式」としてOS・ブラウザ・業務アプリの全レイヤーに敷こうとしている点です。
端末（Pixel/Android）、デスクトップOS（macOS）、ブラウザ（Chrome）、業務スイート（Docs/Keep/Gmail）、開発環境（Antigravity）、そしてAPI。この並びは、音声を単体機能ではなくキーボードと同格の入力レイヤーとして扱う設計思想を示しています。Chromeの「任意の入力欄で音声入力」がとりわけ象徴的で、これが実装されれば、Googleのサービスかどうかに関係なく、あらゆるウェブアプリのフォームが音声対応になります。自社SaaSに音声入力機能を実装していなくても、ユーザーのブラウザ側が勝手に音声対応してしまう、ということです。
実務で効く「地味な」仕様
技術記事では見落とされがちですが、事業側にとって重要なのは以下の3点です。
第一に、フィラー除去と言い直しの処理。従来の音声入力の最大の障壁は「話した通りに書き起こされるので、結局手直しが必要」でした。整形済みテキストが出るなら、口述が下書きとして成立します。
第二に、英数字混じり文字列の精度。注文番号、郵便番号、伝票番号——コールセンター、物流、フィールドサービスといった現場業務で音声入力が使い物にならなかった理由の多くはここでした。
第三に、カスタム語彙の学習。業界用語、社内の製品名、独特な人名表記が通らないことが、日本企業での音声入力導入を阻んできました。この点が改善されるなら、導入判断の前提が変わります。
なお話者分離は事前録音音声で最大3人まで、というのが公表されている範囲です。5人以上の会議やインタビューを想定している場合、現時点でこの数字が制約になる可能性があります。
💼 事業会社視点：これは自社にどう効くか
経営視点で見るべきは「自社サービスへの音声入力の作り込みが、投資対象として妥当か」の再評価です。Chromeが任意の入力欄で音声入力を提供するなら、SaaS事業者が自前で音声UIを実装する意義は薄れます。差別化はブラウザが担えない領域——業界固有語彙のチューニング、入力後のワークフロー接続、権限・監査ログ——に移ります。
EC事業者とコールセンターは短期の恩恵が大きい。注文番号や郵便番号の英数字精度が上がるなら、オペレーターの後処理入力や、通話ログからの自動要約が現実的な工数削減になります。まずは自社の頻出語彙で認識率を実測してください。
受託開発・SIerは注意が必要です。「音声入力機能の実装」を単体で受注するモデルは、APIとブラウザ標準に侵食されます。提案の軸を、音声認識そのものから「認識後のデータを基幹システムにどう流し込むか」へ移すべきです。
日本企業全般では、議事録業務が最初の検証対象になります。ただし話者分離が事前録音・最大3人という制約は、多人数会議の自動議事録には届きません。過大な期待を前提に社内展開を約束せず、APIで小さくPoCを回し、自社の語彙と会議形式で実測してから判断するのが妥当です。