社員指導ナレッジ化の試行錯誤｜第5回

専門用語を教えれば、文字起こしは本当に正確になるのか

前回の記事「きれいなAI整理を、正しい記録だと思っていた」では、同じ音声をNottaとGPT Transcribeで文字起こしし、その後GPTで同じように整理して比較しました。

そこで分かったのは、最終的なAI整理だけを見ると、入口の文字起こし精度の差がかなり見えにくくなるということでした。

GPTは多少崩れた文字起こしでも、前後の文脈からかなり自然な文章へ整理してくれます。

そのため、当社では現時点では、自前のレコーダーで録音した音声をGPT Transcribeへ渡し、その後GPTで整理する方法が有力ではないかと考えていました。

今回はその続きです。

GPT Transcribeを実際の技術打合せで使うなら、河川名、構造物名、設計用語などの専門用語をどう扱うかという問題があります。

専門用語をあらかじめ教えておけば、当然、文字起こし精度も上がるのではないか。

そう考えて、実際の打合せ音声を使って確認してみました。

今回は約30分の技術打合せを使った

対象にしたのは、河川護岸設計に関する実際の打合せ音声です。

会話の中では、次のような一般会話ではあまり使わない専門用語が多く出てきます。

• 支持力
• 転倒
• 積みブロック
• 護床ブロック
• 根入れ
• 仮締切

最初にGPT Transcribeで約30分の音声を全文文字起こしし、その後、音声を聞きながら人間が修正しました。

全体としてはかなり読める文字起こしでした。

一方で、細かく確認すると、一部には技術的な意味が変わる可能性のある表現もありました。

まずは、30分全体でどのくらい違ったのかを整理しました。

まず、30分全体ではどのくらい違ったのか

今回の約30分の打合せ音声について、音声を聞きながら人間が修正した文字起こしを基準に、GPT TranscribeとNottaの文字起こし結果を比較しました。

これは一般的な製品性能を示すベンチマークではありません。

今回の一つの技術打合せ音声に対して、表記をある程度そろえたうえで、文字列の近さや専門用語の一致状況を確認した結果です。

ここでいう文字編集距離率は、人間確認版へ近づけるために必要な文字の挿入・削除・置換の量を、基準となる文字数に対する割合で示したものです。値が低いほど、人間確認版に近いことを表します。

※これは一般的な製品性能を示すベンチマークではなく、今回の約30分の技術打合せ音声1件について、人間確認版を基準に比較した結果です。録音条件、話し方、専門用語の量などによって結果は変わります。

全体の文字列比較では、今回の音声についてはGPT Transcribeの方が人間確認版にかなり近い結果になりました。

特に気になったのは、単純な文字数ではなく専門用語です。

選定した37語について見ると、GPT Transcribeは25語、Nottaは17語が完全一致しました。

さらに、その37語が実際の会話中に出現した95回をすべて数えると、完全一致したのはGPT Transcribeが54回、Nottaが24回でした。

少なくとも今回のような土木設計の打合せでは、文字起こしの入口としてGPT Transcribeを使う方が有力だと感じました。

ただし、ここで一つ疑問が残りました。

全体として93％以上似ている文字起こしなら、技術記録としてそのまま信用してよいのか。

細かく音声と突き合わせてみると、必ずしもそうではありませんでした。

全体では高い一致率でも、残った数％の違いの中に、技術的な意味を変えかねない言葉が含まれていることがあります。

技術ナレッジでは、「何％合っているか」だけでなく、「どこを、どう間違えたか」の方が重要な場合があります。

GPTで整理すると、差はどこまで残るか

文字起こしのあと、GPT TranscribeとNottaの文字起こしをそれぞれ同じ条件でGPTに整理すると、最終的な議事録はどちらもかなり読みやすくなりました。

以下は、今回の打合せについて、元音声、文字起こし、GPT整理結果を見比べた実務上の評価です。

こちらも一般的な製品性能を数値化したものではなく、今回の一つの技術打合せに対する評価です。

ここで興味深かったのは、AI整理後の読みやすさは、どちらもかなり高かったことです。

入口の文字起こしでは大きな差があっても、GPTで整理すると、どちらも自然な議事録に見えます。

しかし、専門用語、数値、設計条件、元発言への忠実さまで確認すると、差は残ります。

つまり、

読みやすい議事録ができたことと、元の打合せを正しく残せたことは同じではない。

ということです。

一方で、人間が音声を聞きながら全文を確認すれば精度は上げられます。

ただ、今回約30分の音声を一語一句確認してみて、毎回この方法を続けるのは現実的ではないと感じました。

そこで目標は、

人間確認版と同じ100％の記録を毎回作ることではなく、入口の精度をできるだけ高くし、そのうえで重要な部分だけを人間が確認できる仕組みにすること。

ではないかと考えています。

そして今回、さらに気になったのが、その「精度の高い側」のGPT Transcribeでも、人間が聞いて判断しにくい曖昧な発話が残ったことでした。

そこで、その部分だけを短く切り出し、GPT Transcribeへ与える情報を変えて、さらに検証することにしました。

人間が聞いてもはっきりしない発話だった

対象にしたのは、積みブロックの安定性について話している部分です。

前後の内容から、次の話をしていること自体は分かります。

• 支持力が足りなかった
• 転倒は問題なかった
• 地盤改良まではせず、基礎のつま先を10cm延ばした

問題は、その途中にある非常に短い発話でした。

相手の発言がかなり早く、少し噛んだのか、言い直したのかもはっきりしません。

何度か音声を聞きましたが、私には、

支持力が足りなくて、あんて、転倒は大丈夫なんですけど

のようにも聞こえます。

ただし、正直なところ、人間が聞いても一語へ確定できるほど明瞭な音声ではありませんでした。

だからこそ、このような曖昧な音声に対して、GPT Transcribe APIへ文脈や専門用語を追加すると何が起きるのかを確認することにしました。

APIへ追加する情報を変えて、合計20回試した

GPT Transcribe APIでは、音声ファイルに加えて、文字起こしの手掛かりとなる情報を追加できます。

• promptには、会話の内容や背景などの文脈を入れる
• keywordsには、正しく認識してほしい専門用語を入れる

今回は、同じ短い音声に対して、APIへ追加する情報を次の4条件に変え、それぞれ5回ずつ文字起こししました。

「支持力」と「転倒」は、すべての条件で安定して認識されました。

差が出たのは、その間の曖昧な短い音声です。

素のGPT Transcribeでは、5回すべて、

支持力が足りなくて、あんだけ転倒は大丈夫

となりました。

APIのpromptに文脈だけを追加した場合は、5回すべて、

支持力が足りなくて、あの、転倒は大丈夫

となりました。

同じ文脈をpromptへ入れ、keywordsへ「支持力」「転倒」「安定計算」の3語を追加した場合は、5回すべて、

支持力が足りなくて、安定計算、転倒は大丈夫

となりました。

「安定計算」をkeywordsから外すと消えた

そこで、promptの文脈は同じまま、keywordsから「安定計算」だけを外して、もう一度5回試しました。

すると、3回は「あんだけ」、2回は「安定」となりました。

「安定計算」という完全な語は、一度も出ませんでした。

つまり今回の音声では、

「安定計算」をkeywordsへ追加した場合だけ、5回すべてで「安定計算」と出力された。

という結果になりました。

もちろん、これだけでモデル内部の処理を断定することはできません。

また、人間でも聞き取りづらい発話なので、元の音声に「安定」に近い音が含まれていた可能性もあります。実際、「安定計算」を外しても、5回中2回は「安定」と認識されました。

今回確認したのは、一つの短い音声に対する挙動です。正解の言葉自体を人間が確定できないため、一般的な文字起こし精度を数値で比較した実験でもありません。

それでも今回の結果からは、

専門用語をAPIのkeywordsへ追加すると、曖昧な音声の出力がその専門語へ寄ることがある。

という傾向を確認できました。

専門用語が増えたから、精度が上がったとは限らない

最初は、専門用語を登録すれば文字起こし精度が上がると単純に考えていました。

今回の結果を見ると、もう少し慎重に考えた方がよさそうです。

専門用語のヒントは、確かに聞き取りにくい言葉を正しく認識する助けになる可能性があります。

一方で、音声そのものが曖昧な場合には、その曖昧な部分を登録済みの専門語として確定する方向にも働く可能性があります。

技術分野では、この違いはかなり重要です。

「支持力」「転倒」「滑動」「安定計算」は、同じ構造物の設計で出てくる言葉ですが、意味はそれぞれ違います。

しかも、間違った専門用語でも文章として自然に成立してしまう場合があります。

明らかにおかしな文字列なら人間も気付きます。

ところが、もっともらしい専門用語へ置き換わると、そのまま正しい記録だと思いやすくなります。

その後GPTへ渡して、きれいな議事録や技術ナレッジに整理すると、さらに違和感は見えにくくなります。

前回の記事で感じた、

自然な文章であることと、元の発言を忠実に残していることは同じではない。

という問題が、今回はさらに具体的に見えてきました。

辞書を使う場所と、人間が確認する場所を変える

そこで今考えているのは、全文を人間が確認する方法ではありません。

今回の結果を見ると、文字起こしの入口で専門用語を完成させようとするより、まず音声に近い文字列を残し、辞書や案件情報は後段のGPT整理で使う方が、挙動を制御しやすいのではないかと思います。

例えば、文字起こしの時点で「安定計算」と確定されると、後段のGPTには、それが音声から聞き取られた言葉なのか、keywordsの影響で補われた言葉なのか分かりません。

一方、「あんだけ」のような不自然な文字列が残っていれば、後段のGPTで周辺の文脈や専門辞書を参照し、「安定」や「安定計算」の可能性はあるが、原文だけでは確定できないと扱えます。

現時点では、次のような二段構成が当社には合いそうです。

第1段階：GPT Transcribe

できるだけ音声への忠実性を優先します。大量の専門用語をkeywordsへ入れず、必要な場合も案件種別などの短い文脈をpromptへ加える程度にします。

第2段階：GPTによる整理

ここで地名、土木用語、案件情報、過去成果などを参照させます。ただし、辞書の役割は正解への強制置換ではなく、補正候補の抽出と異常の発見です。

そのうえで、数値、固有名詞、設計条件、決定事項、判断理由など、間違うと意味が変わる部分を人間が重点的に確認します。

おかしいと思った箇所だけ原音へ戻る。

それでも確定できなければ、無理に正しい文章へ直さず、「要確認」や「未確認」として残す。

この方法の方が、現実的ではないかと思っています。

当社で作っている社内ナレッジも、単なる要約ではなく、技術判断、判断理由、確認の流れ、次の作業につながる情報を残すことを重視しています。

分からない部分をAIが勝手にもっともらしく埋めるより、「ここは分からない」と残す方が、会社の知識としては安全です。

一方で、会議記録そのものは急速に進化している

ここ数年で、文字起こしを取り巻く環境はかなり変わりました。

専用の文字起こしサービスだけでなく、Google Workspaceでも会議記録の仕組みが大きく進化しています。

Google Meetでは、Geminiによる「Take notes for me」が日本語にも対応しており、会議内容を自動で整理してGoogle Docsへ保存できます。

さらに2026年8月には、オンライン会議だけでなく、対面会議でも音声をGeminiへ渡して記録できる機能がWebとAndroidから展開され始めました。iOSは同年8月31日以降の展開予定です。

終了後には、要約、アクションアイテム、全文トランスクリプトがGoogle DocsとしてDriveへ保存されます。

つまりスマートフォンそのものが、会議録音機とAI議事録作成装置を兼ねる方向へ進んでいます。

またBusiness StandardとBusiness Plusでは、2026年9月21日以降、主催者を含む3人以上の予定済み会議で自動メモを標準で有効にする変更も予定されています。管理者や利用者は設定を変更できますが、会議の記録がこれまで以上に自動化されていく流れははっきりしています。

それでも「録れている」と「正しい」は別だと思う

Google Meetのように、会議記録そのものを自動化する機能も進んでいます。

今後は自前の録音・文字起こし構成自体が不要になる可能性もありますが、技術ナレッジとして使う以上、要約結果だけでなく、元の発言をどこまで確認できるかは引き続き見ていきたいと考えています。

ただし、今回の検証をして感じたのは、

AIが会議を自動で記録できることと、技術的に正しい記録が残ることは別の問題である。

ということです。

文字起こしの精度はこれからさらに上がると思います。

それでも、人間でも聞き取れない発話は残ります。

そしてAIが賢くなるほど、曖昧な音声を文脈からもっともらしく解釈する場面も増えるかもしれません。

だから今は、

どのサービスなら100％正しく文字起こしできるか。

だけを探すより、

AIが作った記録の中で、どこを人間が確認すべきか。

を決める方が重要ではないかと考えています。

今のところの結論

前回は、自前のレコーダーとGPT Transcribeを組み合わせる方法が、当社では現時点で有力だと考えました。

今回も、その結論自体を変えるほどではありません。

ただし、

専門用語を大量に教えれば、そのまま文字起こし精度が上がる。

という単純な話ではなさそうです。

今回の短い音声では、promptに文脈だけを追加したGPT Transcribeが、重要な「支持力」「転倒」を保持しながら、曖昧な部分を無理に専門用語へ確定していませんでした。

ここから、現時点では次の考え方が一番扱いやすいのではないかと思っています。

文字起こし側で専門語を完成させようとするより、まず音声に近い文字列を残し、専門辞書や案件情報は後段のGPT整理で使う方が、人間側で挙動を制御しやすい。

これは、素の文字起こしが必ず正しいという意味ではありません。

大切なのは、曖昧な発話を入口で無理に確定せず、後段で候補として検討できる状態を残すことです。

辞書を「文字起こし精度を上げるための強制置換」に使うのではなく、「怪しい箇所を発見し、確認するための知識」として使う。その方が、技術判断を扱う社内ナレッジには合っていると考えています。

今後は、文字起こしの100％正解を目指すより、次の点を仕組みに組み込んでいきたいと考えています。

• 重要な部分の誤りを見つけやすくすること
• 人間が確認すべき箇所を絞ること
• 確認できないものは、確認できないまま残すこと

Google Meetのようなサービスも今後さらに進化していくはずです。

自前の仕組みに固執する必要もありません。

使えるものは使いながら、

会社の技術判断を、どこまで正しく、無理なく残せるか。

そこを基準に、もう少し試していこうと思います。

---

関連記事：きれいなAI整理を、正しい記録だと思っていた