文字起こしの入口をNottaからGeminiへ切り替えた――完成した記録だけでは見えなかった差
約40分の社員指導音声をNotta、GPT Transcribe、Gemini 3.5 Transcribeで比べました。整理後の記録は似ていても、専門用語や係数の残り方が違いました。文字起こしの入口を変え、辞書と数字の扱いも見直した記録です。
当社では、社員指導の音声を文字起こしし、GPTで整理して記録を蓄積しています。
これまで文字起こしはNottaで行ってきました。録音をNottaへ手でアップロードし、Zapierで文字起こしをGoogleドライブの投入箱へ送り、そこからGAS（Google Apps Script）がGPT-6 Solで整理する、という流れです。
Notta、Zapier、GASをつないで自動化した後も、文字起こしの精度はずっと気になっていました。GPT Transcribeと比較し、9月にはGemini 3.5 Transcribeも実際の社内音声で試しました。それでも、普段の処理に使う入口はNottaのままでした。
今回、同じ指導音声で文字起こしモデルと音声形式を比べ、ようやく入口をGemini 3.5 Transcribeへ切り替えました。最終的なナレッジまで通して比べると、以前の記事で書いた「きれいな整理が入口の誤りを隠す」ことを、今度は数字でも確かめることになりました。
整理後はきれいでも、入口の誤変換は残っていた
Nottaの文字起こしには、土木の専門用語や部材名の誤変換が残ります。「土羽土」が「土破土」に、「矢板」が「焼板」になる、といった具合です。
GPT-6 Solは、こうした誤りを文脈からかなり補正してくれます。誤変換の候補も毎回拾い出し、辞書として蓄積しています。そのため、完成したナレッジを読むだけでは、入口の品質の差はほとんど見えません。
ただ、8月の記事で書いたとおり、見えないことと、影響がないことは別です。最初に落ちた情報は、後から正確には戻せません。今回は、入口そのものを選び直すための比較をしました。
同じ40分の指導音声で、最後のナレッジまで比べた
比較には、実際の社員指導の録音を1本使いました。約40分で、数量区分と積算基準の照合をめぐる指導です。専門用語も数字も多く、比較にはちょうどよい録音でした。
比べたのは次の組み合わせです。
| 比べたもの | 内容 |
|---|---|
| 文字起こしモデル | OpenAI GPT Transcribe／Gemini 3.5 Transcribe（それぞれ、話者識別・時刻ありの方式も） |
| 音声形式 | WAV（現行）／Opus 48kbps／AAC 64kbps など |
| 整理 | 普段使っているGASと同じプロンプトで、GPT-6 Solに整理させる |
| 比較対象 | 同じ録音をNotta経由で整理した、比較時点で現行の社員指導ナレッジ |
手作業で一つずつ試すのは現実的ではないので、AI（Claude Code）に比較用のツールを作ってもらいました。録音を1本渡すと、形式を変換し、各モデルへ送り、結果・処理時間・費用を並べて保存します。
用語ヒントを入れると、聞こえた音が登録語に寄った
最初は、誤変換辞書から専門用語を抜き出し、文字起こしのヒントとして渡していました。
すると、先頭3分の試験だけで問題が出ました。「張り芝の生産が追いつかない」という発言が、「積算が追いつかない」と書き起こされたのです。「積算」はヒントに入れていた語でした。
これは、8月の記事で20回試して確認したことと同じ現象です。聞き取りにくい箇所ほど、登録した用語へ寄っていきます。しかも、もっともらしい専門用語になるので、読んでも誤りに気づきにくくなります。
そこで方針を決め直しました。
- 文字起こしには用語ヒントを渡さない
- 言い直しや言い淀みも消さず、聞こえたとおりに残す（verbatim）
- 辞書による補正は、後段のGPT整理だけで行う
文字起こしは「正しく直すところ」ではなく、「聞こえたものを残すところ」と位置付けました。
Geminiは専門用語に強かったが、黙って壊れることがあった
ヒントなしで今回の40分の録音を比べると、確認した専門用語や数字はGemini 3.5 Transcribeの方がよく残っていました。モデル全般の優劣を測った結果ではありません。
| 発言（推定） | GPT Transcribe | Gemini 3.5 Transcribe |
|---|---|---|
| 混合セメントB種 | 「今後セメント」 | 正しく認識 |
| 特記に書いてる | 「時に」 | 正しく認識 |
| 残土置き場 | 「山東置き場」 | 正しく認識 |
| 数量算出要領 | 「数量算数」など | 正しく認識 |
| 土羽土（どはつち。録音では「ドハド」と発音） | 「ドハ土」 | 「ドハド」 |
専門用語としては「土羽土（どはつち）」ですが、この録音では私自身が「ドハド」と発音していました。Geminiの「ドハド」は、実際に話した音をそのまま残しています。GPT Transcribeの「ドハ土」も音としては近い結果です。正しい専門用語の表記になっていないことだけで、文字起こしの失敗とは言えません。話した音を残すことと、意図した専門用語へ直すことは、分けて考える必要があります。
一方で、一度だけ深刻な失敗がありました。最初の10分の区間が、1分ほど進んだところから「盛土。はい。」の繰り返しになったのです。繰り返しは約2,400回続き、およそ9分ぶんの発言が消えていました。
しかも、APIの返事は「正常終了」でした。エラーは出ず、壊れた文字起こしがそのまま返ってきます。同じ区間を別の形式で送ったときは正常でした。ただ、音声形式が原因だったのか、実行ごとのばらつきだったのかは分かりません。
切り替え後の仕組みでは、同じ語句が一定回数以上続いたら自動で取り直すようにしました。文字起こしの精度だけでなく、失敗したことに気づけるかどうかも、選定の条件だと感じました。
話者識別の価値を感じたうえで、標準設定を考え直した
8月の記事では、当社の用途に話者識別やタイムスタンプは必須ではないと書きました。その後、Gemini 3.5 Transcribeを試し、誰の発言か分かることや、元の音声へ戻れることに価値を感じました。今回の切り替えでは、その考えも踏まえて、話者識別とタイムスタンプを付ける方式を改めて比べました。
GPT側の話者識別は、冒頭が英語になったり、相づちが細切れに並んだりして、実用に届きませんでした。Gemini側は話者がきれいに分かれ、時刻も付きました。ただ、この方式では用語の精度が一段落ちます。
指導のほとんどは、私と社員の1対1です。GPT-6 Solは、話者の区別がない文字起こしからでも、私の判断と社員の質問を読み分けていました。話者識別が役立つ場面はありますが、今回の方式では用語の精度が落ちることも確かめました。そこで、普段の社員指導では、まず発言の内容を残す方を優先し、話者識別は標準では付けないことにしました。
原音に戻る道筋は、約5分ごとの区間の開始時刻で確保しています。以前感じた話者識別や細かい時刻の価値を否定したわけではありません。音声はすべて保管しているので、誰の発言か確認したい録音には、後から話者識別をかけ直すこともできます。
Opusにしても、精度は落ちなかった
現在のレコーダーはWAVで録音しています。40分で約200MBになり、300本分を考えると保管の負担が大きくなります。
同じ録音をOpus 48kbpsに変換して比べたところ、今回確認した専門用語や数字には、明らかな悪化が見られませんでした。形式の違いより、同じ形式で2回実行したときのぶれの方が大きく見えた箇所もあります。容量は約15分の1になります。
これまでのWAV録音46本も、5.37GBから359MBになりました。
最後のナレッジは同じに見えた。ただ、一つの数字が違った
最後に、同じ録音を三つの経路で整理したナレッジを並べました。Notta経由のものは、今回の比較時点で現行の運用から作成・登録されていたナレッジです。
- 比較時点の現行ナレッジ（Notta → GPT-6 Sol）
- GPT Transcribe → GPT-6 Sol
- Gemini 3.5 Transcribe → GPT-6 Sol
判断の中心は、三つともほぼ同じでした。どういう前提で「締固めなし」を選んだのか。私が「正直わからない」と保留した箇所はどこか。何を北海道の積算基準で確認し直すか。どれも残っていました。入口の差は、GPTがかなり吸収していました。
違っていたのは、盛土法面の幅を説明した箇所の係数でした。元の音声では、私は「1.118」と話しています。
| 経路 | 係数 |
|---|---|
| 現行ナレッジ（Notta経由・比較時点） | 1.18 |
| GPT Transcribe | 係数そのものが抜けた |
| Gemini 3.5 Transcribe | 1.118 |
2割勾配の換算係数は、計算上約1.118です。30cmに掛けると約33.5cmですが、録音では大まかに「約35cm」と説明しました。一方、1.18を掛けると約35.4cmです。丸めた結果だけを見ても、この違いには気づきにくい。比較時点の現行ナレッジには、「係数約1.18」と確定した数字として残っていました。なお、GPT Transcribeの文字起こし自体にも「1.18」が出ていますが、整理後には係数が抜けていました。
完成したナレッジを読んでいるだけでは、この違いには気づけませんでした。入口で崩れた数字は、整理の段階では直りません。むしろ、きれいな文章の中で、正しい記録に見えるようになります。
録音するだけで、ナレッジの投入箱まで届くようにした
比較の結果を受けて、普段使う仕組みを次のように変えました。
- いつもどおりレコーダーで録音する（レコーダーの操作は変えない）
- 録音を止めると、パソコンに常駐する仕組みがOpusに変換し、共有ドライブへ保管する
- 約5分ごとに区切って、Gemini 3.5 Transcribeで文字起こしする（用語ヒントなし・verbatim）
- 同じ語句の繰り返しを見つけたら、自動で取り直す
- 文字起こしを投入箱へ置く。そこから先は、これまでのGASとGPT-6 Solが整理する
Nottaへの手動アップロードとZapierは、この流れから外れました。外出先でNottaメモなどに録音した音声は、共有ドライブの専用フォルダに入れれば、同じ流れで処理されます。
今回の40分の録音1本を処理した概算費用は、文字起こしが約30円、簡易版の辞書を使ったGPT-6 Solの整理が約20円でした。毎回同じ金額になるわけではありません。APIの残高不足や利用上限でつまずいた場合は、Google Chatに原因が日本語で届くようにしました。
辞書が育つほど、整理の費用も上がっていた
整理の費用を細かく見たところで、もう一つ気づいたことがあります。正直に言うと、私の頭からすっかり抜けていた部分でした。
最初に測ったとき、GPT-6 Solの整理は1件あたり約53円でした。その内訳を見ると、入力の9割近くは文字起こしの本文ではなく、毎回一緒に渡している誤変換辞書だったのです。
| 渡しているもの | 量 |
|---|---|
| 整理ルール＋誤変換辞書 | 約12万トークン |
| 指示文＋文字起こし本文 | 約1.5万トークン |
誤変換辞書は、整理のたびにGPTが候補を拾い出し、スプレッドシートを経由して自動で育っていく仕組みです。739件、13.6万字まで増えていました。辞書が育つのは良いことです。ただ、その全文を毎回GPTに渡しているので、件数が増えるほど1件あたりの整理費用もじわじわ上がっていく作りになっていました。
中身を見ると、人が読むための情報がほとんどでした。どの案件で出てきたか、なぜそう判断したかという備考、適用条件の長い説明などです。同じ補正も何度も入っていて、「キャド→CAD」は案件ごとに12回登録されていました。確度が低く「未確認」のままの参考候補も215件ありました。
そこで、GPTに渡す辞書だけを1件1行の簡易版に変えました。例えば、補正する語と条件を分けて示すと次のようになります。実際に渡す辞書は、この表ではなく1件1行です。
| 聞き取りの揺れ | 補正候補 | 扱い・条件 |
|---|---|---|
| ご飯／湖岸／法案／語岸／御案 | 護岸 | 河道内の構造物や樋門、吐口、階段などと並んで出てくる場合 |
| 稼働計画／可動計画 | 河道計画 | 河川法線、護岸設計、用地取得、縦断勾配などを説明する場合 |
「ご飯」は読めば誤りに気づきやすい一方、「稼働計画」はそれだけでも意味の通る言葉です。元の発言が「河道計画」だったとしても、整理後の文章だけでは見逃しかねません。だから、辞書に候補があるだけで一律に置き換えず、河川の計画について話していると確かめられる場合だけ補正します。
残すのは、確度が高・中の「固定置換」と「条件付き補正」だけです。案件名や備考、参考候補は、スプレッドシート側にそのまま残しています。GPTに渡す辞書は13.6万字から約1.4万字になり、今回の同じ録音を再処理した概算費用は約53円から約21円に下がりました。継続運用での費用を測った数字ではありません。
辞書を軽くしたら、また数字が消えた
ここでも、数字の話が出てきました。
簡易版の辞書で同じ文字起こしを整理すると、判断の中身はほぼ同じでした。ところが、2回試して2回とも、係数の1.118が抜けていたのです。「法面勾配を考慮した幅は片側約35cm」とだけ書かれ、途中の係数が省かれていました。
辞書を短くした試験で、計算の途中が省かれたことは確かです。ただ、辞書の長さが直接の原因かどうかは分かりません。そこで、整理の指示に次の3行を足しました。
- 数値・係数・寸法・勾配・単位・数量・測点番号・基準の項目番号は、発言どおりに省略せず残すこと
- 計算の結果だけでなく、途中で使った係数や数値も残すこと
- 聞き取りが不確かな数値も削らず、「音声上は〇〇」と書いて残し、未確認事項に挙げること
この指示の例には、今回の答えである1.118は入れていません。それでも、「係数1.118を掛け、片側約35cm、両側で約70cm」と、計算の途中まで残るようになりました。
費用を下げると、どこかで情報が薄くなることがあります。今回は、それが数字に出ました。入口の文字起こしと同じで、整理の段階でも、数字はとくに意識して守る必要があると感じています。
私がやったのは、判断と確認だけだった
ここまで書いてきた作業のほとんどは、私ではなくAIがやっています。使ったのは、Anthropic社のClaude Codeです。パソコンの上で、ファイルを読み、プログラムを書き、実行して結果を確かめるところまでをAIが進めてくれます。
Claude Codeがやったことを挙げると、次のとおりです。
- Googleドライブに入って、今のGASのコードと整理ルールを読み、仕組み全体を把握する
- 当社の技術ノートを読んで、過去の検証結果（用語ヒントが誤りを招くことなど）を方針に反映する
- 比較用のツールを作り、音声の変換、各モデルへの送信、結果と費用の集計まで自動で回す
- 40分の音声を何通りも文字起こしし、GPT-6 Solでの整理まで通して比較する
- 繰り返しの失敗を見つけて、検出と取り直しの仕組みを入れる
- 録音フォルダを見張って投入箱まで届ける常駐の仕組みを作り、テスト用のフォルダで何度も試す
- これまでのWAV 46本をOpusに変換して、共有ドライブへ移す
- GASの変更を、全部消して全部貼り付けるだけで済むファイルにして渡す
- 誤変換辞書の中身を集計し、軽くする方法を試して、費用と整理の質を比べる
途中では、私一人ではまず解決できなかったつまずきもいくつかありました。
- パソコンに入っているウイルス対策ソフトが通信を検査していて、Gemini APIへの接続だけが証明書のエラーで失敗した
- 状況確認用のバッチファイルが文字化けして、途中から動かなくなっていた
- レコーダーの起動ファイルに入っている設定を、文字起こしの仕組みまで引き継いでしまい、起動した直後に止まっていた
どれも、Claude Code自身がエラーの内容から原因を突き止めて直しています。
私がやったことは、次のくらいです。
- 方針を決める（生データで残す、話者識別は標準では付けない、WAVは残さない、など）
- Gemini APIのキーを発行して、支払いの設定をする
- GASのコードを貼り替えて、指示された関数を実行する
- Zapierを止める
- 画面を見て、おかしいところを伝える
方針を決めるところは、やはり人の役割だと感じました。たとえば「話者識別は1対1なら要らない」という判断は、当社の指導がほぼ1対1で行われているからこそ出せるものです。また、AIが作業の途中で英語で報告してきて何をしているのか分からなくなったり、全社員が見るチャットにテスト通知を送ってしまったりと、人が見ていないと困る場面もありました。それでも、手を動かす部分はほぼClaude Codeに任せ、入口の切り替えまでにかかったのは、Claude Codeが動いていた時間を含めて2時間ほどでした。私自身が操作や確認に使った時間は、合わせても数分ほどです。
GPTで作ったレコーダーを、Claude Codeがつないだ
少し面白いと思ったのは、道具の組み合わせです。
当社のCreer Recorderは、もともとGPT（Codex）で作ったものです。マイクを選び、録音し、WAVで保存するという部分は、今回も一切変えていません。
Claude Codeは、そのレコーダー本体には手を入れず、起動ファイルに一行足して、新しい文字起こしの仕組みと一緒に立ち上がるようにしました。その途中で、GPTが作ったレコーダーの起動設定と、Claude Codeが作った仕組みがぶつかって動かなくなる、という不具合が出ました。これもClaude Codeが原因を見つけて、両方が動くように直しています。
一つのAIですべてを作るのではなく、それぞれが作ったものを、別のAIがつないで直していく。そういう使い方が、自然にできるようになってきたと感じます。
仕組みを動かすGASとAI、仕組みを作ったClaude Code
もう一つ、皮肉なことがあります。
出来上がった仕組みには、GoogleのGASも残っています。文字起こしを投入箱へ置いた後は、GASが整理の処理を動かします。AIとして使っているのは、文字起こしを担うGoogleのGemini 3.5 Transcribeと、整理を担うOpenAIのGPT-6 Solです。ClaudeのAPIは使っていません。
つまり、Claude Codeは、自分以外のAIが動く仕組みを作り、比べ、直したことになります。今回の録音でOpenAIの文字起こしがGeminiより専門用語を拾えなかった結果も、そのまま報告してきました。
仕組みを作るAIと、仕組みの中で動くAIが同じである必要はありません。どの工程にどのAIを使うかを、比べて選べることの方が大事だと思っています。
気になっていた文字起こしの入口を、ようやく切り替えた
録音から整理・保存までの流れは、すでに動いていました。それでも、仕上がったナレッジを読むたびに、最初の文字起こしで何か落ちていないかが気になっていました。GPTが文章をうまく整理できることは分かっています。だからこそ、入口の誤りまで見えにくくなります。
今回、同じ40分の録音を文字起こしから整理後まで比べました。最後のナレッジだけでは似て見えたものの、文字起こしを確認すると、Geminiは複数の専門用語と、元の音声で話した係数「1.118」を残していました。確認した録音では、気になっていた入口の精度を改善できたと感じています。
用語ヒントを文字起こしから外し、辞書は後段の整理で使う形にしました。費用を調べた結果、GPTへ渡す辞書も軽くできました。どちらも今回の大事な収穫ですが、私にとって一番大きいのは、過去の記事でも書いてきた文字起こしへの疑問に、実際の録音を比べて一つ答えを出せたことです。ようやく入口を選び直せて、もやもやしていた部分が一つすっきりしました。
もちろん、これは今回確認した録音での結果です。私自身が「土羽土」を「ドハド」と話していた例もあり、文字起こしだけで専門用語の正式な表記まで確定できるわけではありません。Geminiでも発言が繰り返されて欠ける失敗がありました。切り替えて終わりとは考えていません。実際の運用で取り直しがどのくらい起きるか、整理後のナレッジで誤変換の候補がどう変わるかを見ていきます。レコーダー自体をOpusで録音する改修も進める予定です。
読みやすい記録を作ることと、元の発言をできるだけ正確に残すことは、同じではありません。今回は後者を一歩進められました。