Gemini 3.5 Transcribeを試して、音声にこだわってきた理由が見えてきた
Gemini 3.5 Transcribeを実際の社内音声で試し、文字起こしだけでなく、話者分離とタイムスタンプに手応えを感じました。技術判断を後から確かめられる形で残すために、音声へこだわってきた理由を振り返ります。
Creerで実際に録音した音声を、Gemini 3.5 Transcribeで文字起こししてみました。
同じ音声をこれまで別の方法でも扱ってきたため、結果を読んだとき、
「文字起こしはここまで来たのか」
と感じました。
気になったのは、文章の正確さだけではありません。
誰が話したのかを分ける話者分離や、発言が音声のどの位置にあるかを示すタイムスタンプも含めて、仕事の記録として使う手応えがありました。
ちょうどGoogle Workspace周辺でも、声で情報を探し、文書を作り、会話を記録する機能が広がっています。
今回考えたいのは、認識した文字の正しさに加えて、誰の発言なのか、どこを聞き直せば確かめられるのかという点です。判断の経緯を残す用途では、そこも文字起こしを選ぶ基準になります。
同じ音声を試したから、変化を感じられた
Googleが2026年8月26日に発表したGemini 3.5 Transcribeは、音声を文字へ変換する新しいモデルです。
リアルタイム処理に加え、録音済み音声では話者の区別や単語単位のタイムスタンプにも対応しています。発表時点では、Gemini APIやGoogle AI Studioなどで開発者向けにパブリックプレビューとして提供されています。
当社で試したのは、紹介用のきれいなサンプルではありません。
社員との技術的な会話や説明を録音した、実際の社内音声です。
以前、同じような土木設計の音声を使い、GPT TranscribeとNottaの文字起こしを比較しました。そのときは専門用語をどこまで正しく拾えるか、曖昧な発話を無理に専門語へ寄せていないかを細かく確認しました。
今回、Gemini 3.5 Transcribeの結果を読むと、社内音声の文字起こしにかなり期待できそうだという印象を受けました。
話者分離も、試した音声ではかなり良く感じました。
社員指導の会話には、質問、説明、相づち、確認、考え直しが混ざります。
社員が質問した内容なのか、私が作業方針として伝えた内容なのかによって、同じ言葉でも意味が変わります。誰の発言か分かる形で追えることには、単なる読みやすさ以上の意味があります。
タイムスタンプにも手応えがありました。
技術記録を読んでいて、元の発言を確認したくなることがあります。音声の位置が分かれば、長い録音を最初から聞き直さなくても、確認したい部分へ戻れます。
8月2日の記事では、話者識別やタイムスタンプは当社の用途では必須ではないと書いていました。当時は誤変換や欠落への対応が中心でしたが、判断の前後を確かめる用途まで考えると、この二つの情報の価値も違って見えてきました。
読みやすい文字にするだけでなく、原音へ戻る道筋も一緒に持てる。
そこに今回の大きな変化を感じました。
もっとも、これは当社の音声を試した範囲での感触です。どの録音でも同じ結果になるとか、他のモデルより常に優れていると結論づけたわけではありません。
話すところから、次の処理までがつながり始めている
その直後の2026年9月3日には、GoogleからGmail、Docs、Keepの新しい音声機能が発表されました。
声でメールの中の情報を探す。
考えを話しながら文書の初稿を作る。
まだまとまっていない思いつきを話し、整理されたメモにする。
入力欄へ完成した文章を打ち込む前の段階から、サービスが仕事に関わる方向です。
発表時点では個人向けの一部プランから提供が始まり、法人向けGoogle Workspaceへの提供は今後の予定とされています。当社の会社アカウントで、すでに全社員が使えるという話ではありません。
会話を残す側では、Google Meetの自動メモが日本語にも対応し、会議内容をGoogle Docsへ整理して保存できます。
保存した後の処理にも動きがあります。Workspace Studioの公式ガイドには、Driveへ新しい資料が入ったことをきっかけに、内容をGemini Notebookの情報源へ追加する例が示されています。
これらを並べて見ると、
話す。
記録する。
文字にする。
整理する。
次の処理へつなぐ。
という流れが見えてきます。
もちろん、別々の機能を並べただけで、当社の運用がそのまま完成するわけではありません。音声モデルが担う処理と、会議メモや文書を扱う自動化は別のものです。
それでも、これまで自分たちでつないできた工程を、標準サービス側の機能として考えられる範囲が広がっていることは気になります。
当社は必要に迫られて音声を使い始めた
Creerでは、河川構造物の作図や数量計算、照査など、元請会社の設計実務を支援しています。
社員への説明も、図面や数量表を一緒に見ながら行うことが多くあります。
録音を始めた最初の動機は、同じ説明を何度もする時間を減らしたい、というものでした。
実際に残してみると、密度の濃い話を社員が復習する用途が見えてきました。さらに文字起こしをAIで整理し、社内ナレッジとして蓄積するようになりました。
この経緯は、以前の「なぜ当社は社員指導を録音しているのか」でも書いています。
Nottaの文字起こしで困れば辞書を試す。別の文字起こしモデルも比較する。声の拾い方が気になれば、録音環境そのものを見直す。
目の前の問題を一つずつ直した結果、録音、文字起こし、AI整理、保存、再利用という流れができてきました。
各机にマイクを置いても、すぐには定着しなかった
2026年3月頃からは、社員の机にUSBマイクも置き始めました。
HyperX DuoCastなどの、少し光るタイプのマイクです。結果として、各机にピカピカ光るマイクが並ぶ、少し不思議な土木設計会社の風景になりました。
小型スピーカーも、社員が自分で選べるようにしました。ピンク色のものや、RGBで光るタイプもあります。
単に派手な機器を置きたかったわけではありません。
AIへの音声入力を仕事へ入れるとき、問題になるのは文字起こし精度だけではなかったからです。
当社は比較的コンパクトな事務所で、社員同士の席も近くにあります。静まり返った職場というより、普通に会話しながら仕事をする環境です。
それでも、社員全員へ音声入力を広げようとすると、別の壁がありました。
人前でPCへ話しかけることへの気恥ずかしさです。
文字入力なら、周囲から見ても何をしているか分かりません。しかし音声入力は、当然ながら周囲に聞こえます。
導入当初には、少し笑える出来事もありました。
ある社員が、自分の席でAIへ小声で話しかけていました。すると隣の社員が、自分に話しかけられたと思って、
「え、何？」
と普通に返事をしました。その声までマイクが拾ってしまい、みんなで笑ったことがあります。
今振り返ると、こうした出来事も含めて、会社の中に「PCへ話しかける」という行為が入っていく途中だったのだと思います。
マイクを買えば終わりではありませんでした。音声認識の精度だけでなく、声を出して仕事をすることに人が慣れる時間も必要でした。
それでも毎日使っているうちに、少しずつ違和感はなくなっていきました。私自身も今では、PCだけでなくスマートフォンでも自然に音声入力を使っています。
残したかったのは、答えよりも判断の途中だった
蓄積した技術指導の記録を振り返ると、答えへたどり着くまでのやり取りが残っています。
配筋の寸法を確認する話では、図面に書かれた数字だけを見て作業を進めず、その寸法がどの位置から決まるのか、どの条件から決まるのか、何を基準に確認すべきなのかをたどっています。
過年度成果を確認する話では、最初に私が疑問を持った箇所について、資料を見た後で自分の見立てを修正した経緯も残っていました。
私が社員へ答えを教える場面だけでなく、私自身が確かめ直し、考えを変えている場面です。
後から結論だけを書けば、その途中は省いてしまうかもしれません。
しかし、どの資料を見た結果として考えが変わったのかまで分かれば、次に似た違和感を持ったときの確認方法として使えます。
教科書には基礎知識があります。基準書には確認すべき原則があります。
ただ、目の前の図面のどこを疑い、どの資料へ戻り、何を確認した結果として考え直したのかという、今回の仕事の経緯までは載っていません。
今は社員が相談に来ると、詳しい話を聞く前に録音を始めています。
その場で図面を見て、話し、必要なら考えを変える。その順番ごと残せることに、音声を入口にする意味があると感じます。
教科書にない判断だから、文字起こしを雑にできない
そう考えると、文字起こし精度にこだわってきた理由も見えてきます。
専門用語や数字が正しく残ることは大切です。しかし、それだけでは足りません。
「この条件では」という前提。
「ただし」という例外。
「まだ確認していない」という留保。
資料を見た後の修正。
こうした言葉も、技術判断の一部です。
条件が抜ければ、限られた場面の話が、いつでも使える指示に見えるかもしれません。「未確認」という言葉が落ちれば、確認済みの話に見えるかもしれません。
その場にいた社員なら補えることでも、後から読む別の社員やAIには、その場の記憶がありません。
残したいのは、結論を支えていた条件や、考えが変わった理由まで含む記録です。
Gemini 3.5 Transcribeの公式説明には、言い直しや言いよどみを整理する機能もあります。入力したい文章を整えるときには便利だと思います。
一方、当社の技術記録では、どの言い直しが単なる発話の修正で、どれが判断の変更なのかが気になります。
考え直す前と後が一つのきれいな文章にまとめられたとき、なぜ結論が変わったのかまで追えるのか。この点は引き続き確かめたいところです。
文字起こしの結果だけで、新しいサービスを決めない
当社では、これまで複数のサービスと自作部分を組み合わせてきました。
その流れに近いものが標準機能として使えるなら、今の構成を見直す理由になります。録音後の保存や情報源への追加など、任せられる工程が増えれば、維持する手間を減らせる可能性もあります。
ただ、会議の要点を把握するためのメモで十分な場面と、条件や判断の変更まで残したい場面では、必要な記録が違います。
Meetの要約が便利そうだからという理由だけで、今の録音・文字起こしの運用を置き換えるつもりはありません。
過去の判断を今回の仕事へ使うときも、当時との条件の違いを人が確認し、必要な事項は元請会社へ判断を求めます。
新しいサービスを見るときには、文字起こしの正確さだけでなく、次の点まで確認する必要があります。
- 誰の発言かを追えるか
- 原音の位置へ戻れるか
- 条件や留保が落ちていないか
- 判断が変わった前後を確認できるか
- 保存後に人とAIが再利用できるか
- 今の業務フローへ無理なく組み込めるか
以前は、専門用語が正しく文字になったかを中心に見ていました。今回は、記録を読んで疑問を持った人が、元の発言までたどれるかという点に手応えを感じました。
判断の途中を残したいからこそ、確認するための手掛かりも残したい。今後は、言い直しや判断変更の前後をどこまで追えるかも含めて、実際の社内音声で確かめていきたいと思います。