文字起こしAIは精度で選ぶと失敗する — 先に比べる3点

議事録や問い合わせ記録の作成に文字起こしAI（音声を自動でテキストに変換する仕組み）を組み込みたい、という相談が増えています。デモを見れば、たしかに驚くほどきれいにテキストが出てきます。ところが、いざ自社の会議音声を流し込むと「誰の発言か分からない」「製品名が全部ひらがなになる」「録音データをどこに置くか決まっていない」といった壁にぶつかります。

結論から言うと、業務システムに組み込む文字起こしAIを選ぶとき、最初に比べるべきは精度ではありません。話者の分け方・専門用語の扱い・音声とテキストの保存先の3点です。この3点は後から変更しにくく、しかもベンダーのカタログには小さくしか書かれていません。本記事では、この3点をどう確認し、どう設計に落とすかを整理します。

なぜ「精度」での比較は役に立たないのか

文字起こしの精度は、一般に単語誤り率（Word Error Rate、認識されたテキストが正解とどれだけ違うかを示す指標）で語られます。しかし業務システムの発注判断に、この数字をそのまま使うのは危険です。理由は3つあります。

第一に、精度は音声の条件で大きく変わります。静かな部屋で1人がマイクに向かって話した音声と、会議室の中央に置いたICレコーダーで6人が同時に話した音声では、同じエンジンでも結果が別物になります。ベンダーが提示する数値は前者の条件で測られていることが多く、自社の録音環境での再現性はありません。

第二に、現在の主要な音声認識エンジンは、日常会話レベルであればどれも実用水準に達しています。差がつくのは、むしろ固有名詞・業界用語・数値の扱いといった「端の部分」です。

第三に、業務で問題になるのは誤りの量ではなく、誤りの種類だからです。「えーと」が抜けていても実害はありませんが、金額の桁が違ったり、発言者が入れ替わったりすると、議事録として使えません。精度の数値は、この致命度の違いを区別してくれません。

精度は、自社の音声サンプルで実際に試して確かめるものです。評価の進め方についてはAI の「良くなった気がする」を卒業する — 評価データセットの作り方と運用も併せてご覧ください。

比較点1：話者をどう分けるか

複数人の会話を「誰が話したか」で区切る処理を話者分離（スピーカーダイアライゼーション）と呼びます。議事録システムでは、ここが成否を分けます。

話者の分け方には、大きく次のような方式があります。

重要なのは、どの方式を選ぶかで録音方法まで決まるという点です。チャンネル分離を採るなら、会議の録り方自体を変える必要があります。システムの仕様だけ決めて現場の運用を後回しにすると、納品後に「結局これまで通りICレコーダーで録っているので分離できない」という事態になります。

また、自動分離の結果に実名を当てる場合、「話者1は誰だったか」を人が指定する画面が必ず要ります。この画面の有無で、1件あたりの作業時間はかなり変わります。見積もり段階で、話者ラベルの確定を誰がどの画面で行うかを明文化してください。

比較点2：専門用語と固有名詞をどう通すか

音声認識エンジンは、学習したことのない単語は出力できません。自社の製品名、取引先名、社内の略語、業界特有の言い回しは、ほぼ確実に別の単語に置き換わります。たとえば次のような場面です。社内で「カイケン」と呼んでいる月次の会議が「改憲」と変換され、議事録の検索に一切引っかからなくなる、といったことが起こります。

対処の方法は、どのエンジンを使うかによって選択肢が変わります。

• カスタム辞書（単語登録）：認識させたい単語と読みを登録する。もっとも手軽だが、登録できる語数に上限があるサービスも多い
• 文脈プロンプト：音声を渡すときに「この音声には次の用語が含まれます」と語彙リストを添える。対応するエンジンでのみ使え、長さに制限がある
• 後処理での置換：出力されたテキストに対し、誤変換パターンを規則で置き換える。確実だが、パターンの洗い出しと保守が続く
• 大規模言語モデルによる校正：文字起こし結果をLLM（大量の文章を学習した言語モデル）に渡し、用語集を参照しながら文脈に沿って整える。柔軟だが、原文にない内容を補ってしまうリスクがある

実務では、辞書登録と後処理の組み合わせが現実的な落としどころになることが多いはずです。そして見落とされがちなのが、用語集を誰が更新するかです。新製品が出るたび、新しい取引先が増えるたびに語彙は増えます。管理画面から担当者が追加できる形にしておかないと、半年後には辞書が陳腐化します。

LLMによる校正を挟む場合、原文（生の文字起こし）と校正後のテキストを両方保存しておくことを強くおすすめします。「AIが勝手に書き換えたのではないか」という疑いが出たとき、原文がなければ検証できません。

比較点3：音声とテキストをどこに置くか

ここが、技術よりも先に経営判断が要る部分です。会議の録音には、人事の話、取引条件、個人の氏名が含まれます。つまり音声ファイル自体が機微な情報の塊です。

確認すべき項目を整理します。

個人情報保護法では、個人情報を第三者に提供する場合や外国にある第三者へ提供する場合に一定の対応が求められます。クラウドの音声認識サービスを使う構成が、この整理の中でどう位置づけられるかは、利用形態と契約内容によって判断が分かれます。自社で結論を出さず、契約書とサービスの仕様書を突き合わせて確認してください。

録音すること自体についても、参加者への周知のルールを決めておく必要があります。「この会議は文字起こしのため録音されます」という一文を会議の冒頭または招待メールに入れる、といった運用上の取り決めです。

クラウドと社内設置のどちらを採るかの考え方は、クラウドAIか、社内設置か — 中小企業が迷わず決めるための3つの判断軸で整理しています。音声は扱うデータの機微度が高いぶん、この判断がより重くなる領域です。

実装で詰まりやすい箇所

設計が固まった後、開発段階で工数が膨らみやすいのは次のようなところです。発注前に見積書の中身を確認しておくと、後からの追加請求を避けられます。

• 音声ファイルの前処理：ICレコーダーやスマートフォンの録音形式はまちまちです。変換、無音区間の除去、音量の正規化といった処理が必要になります
• 長時間音声の分割：多くのサービスには1回に送れる音声の長さや容量に上限があります。2時間の会議を分割し、つなぎ目で文が切れないように処理する仕組みが要ります
• 処理待ちの扱い：文字起こしは即座には終わりません。「送信したら完了するまで画面が固まる」作りにすると使い物になりません。非同期処理（裏で処理を進め、終わったら通知する方式）の設計が前提です
• 失敗時のリトライ：ネットワークの瞬断やサービス側の一時エラーで処理が落ちることがあります。どこまで戻してやり直すか、同じ音声を二重に課金されないかを決めておきます
• 編集履歴：人が修正した議事録が、後から「誰がいつ直したか」追えるか。議事録を正式な記録として使うなら必須です

加えて、課金の仕組みも確認しておきます。多くのサービスは音声の時間単位で課金されます。月に何時間の会議を処理するかを概算し、試行錯誤や再処理の分を上乗せして見積もってください。1回の失敗が即コストになる点が、テキスト処理のAIとは異なります。

まとめ

文字起こしAIを業務システムに組み込むとき、比較表の精度欄を眺めても判断はつきません。先に決めるべきは次の3点です。

1. 話者の分け方：自動分離・チャンネル分離・事前登録・手動補正のどれを採るか。それにより録音方法と画面設計が決まる
2. 専門用語の通し方：辞書・プロンプト・後処理・LLM校正のどれを組み合わせるか。そして用語集を誰が更新し続けるか
3. 保存先と権限：処理の場所、学習利用の有無、保存期間、アクセス権限を契約と仕様の両面で確認する

この3点が決まれば、候補となるサービスは自然に絞り込まれます。その上で、自社の実際の会議音声を数本用意し、候補を並べて試す。この順序を守れば、「デモでは良かったのに現場で使われない」という結末を避けられます。

そして、どの方式を選んでも人の確認は残ります。文字起こしAIは議事録作成を自動化する道具ではなく、下書きを高速に用意する道具です。確認する人をどう配置するかまで含めて設計することが、定着する仕組みの条件になります。