何が起きたか

Googleが「Gemini 3.5 Transcribe」を公開しました。名称のとおり3.5系列に属するモデルですが、本命とされるGemini 3.5 Proはまだ登場しておらず、音声認識モデルが先行して出てきた格好です。

このモデルの特徴は、単に音声を文字に起こすのではなく、話し言葉を整えた状態で出力する点にあります。発話中の「えーと」「あー」といったフィラーを除去し、話者が言い直せばテキスト側もその場で書き換わります。ユーザーが専門用語リスト（カスタム語彙）を渡せば、業界固有のジャーゴンも拾えます。対応は85言語、録音済み音声なら最大3話者まで区別できます。

性能面では、音声から最終テキスト化までが約70%高速化。ライブ音声のエラー率は5.5%で、従来エンジンのChirp 3（Google計測で7.32%）から改善しています。すでにPixel 11のGboardにある「Rambler」で動いており、今後Googleのエコシステム全体へ展開される見込みです。

なぜ重要か

従来の音声入力は「正確に文字起こしする」ことがゴールでした。だからこそ、出てくるのは「えーと、あの、それでですね」まで含んだ生の話し言葉で、人間が後から整形する工程が必ず残っていました。この後工程こそが、音声入力が業務で定着しなかった最大の理由です。

Gemini 3.5 Transcribeは、その後工程をモデル側に取り込みました。つまりこれは認識精度の勝負ではなく、「文字起こし」と「編集」の境界を消しにいった製品です。エラー率7.32%から5.5%という改善幅そのものより、70%の高速化と整形済み出力という組み合わせのほうが、業務フローに与える影響は大きいでしょう。

見落としてはいけない論点

ただし、この設計には構造的なトレードオフがあります。Ars Technicaが指摘するとおり、このモデルは技術的には発言の文言を変えているからです。フィラー除去も言い直しの反映も、「AIが話者の意図を正しく汲めている」という前提の上に成り立ちます。

短い文章の整形では実用的だとされる一方、これは用途を選ぶという意味でもあります。議事録の下書きやメモ、チャット入力なら整形されたほうが便利です。しかし発言の一言一句が意味を持つ場面――取締役会の正式記録、コンプライアンス調査のヒアリング、医療や法務の記録、労務トラブルの当事者聴取――では、「AIが整えたテキスト」は原本になりません。ここを混同すると、後から証跡として使えないことに気づく事態が起こり得ます。

カスタム語彙への対応は、逆に企業導入を強く意識した機能です。自社製品名・型番・社内略語をあらかじめ登録できるかどうかは、実務での使い物になるかを分ける現実的な分岐点だからです。

💼 事業会社視点：これは自社にどう効くか

日本企業にとって、まず効くのは受託開発・SIerです。要件定義のヒアリングや客先打ち合わせの議事録作成は、いまも人手の後処理コストが乗っている領域で、整形済み出力が使えれば納品前の下書き工数がそのまま削れます。ただし「議事録は整形版、合意事項の確認は録音原本」という二層運用を先に決めておくべきです。

カスタマーサポートを持つEC・SaaS事業者は、通話ログの扱いを再設計する好機です。85言語対応と最大3話者の分離は、越境ECの多言語対応やオペレーター＋顧客の会話分析に直結します。一方で、クレーム対応の記録をフィラー除去済みテキストだけで残すのは危険で、原音声の保存ポリシーとセットで議論する必要があります。

音声認識を売りにしてきたSaaSにとっては、より厳しい話です。「文字起こし＋整形」がOSとキーボードのレイヤーに降りてくるなら、その機能単体では課金根拠になりません。差別化は、業種特化の語彙、社内システムへの連携、記録の証跡性といった「整形の後」に移ります。

経営者が今動くべきことは一つ、議事録・通話記録に関する社内規程の棚卸しです。AIが文言を変える前提の記録をどこまで正式文書として認めるか。ツール導入より先に、この線引きを決めておくべきです。