文字起こしで誤変換される名前を修正する方法(2026年版ガイド)

AI文字起こしで人名・ブランド名・地名が壊れる理由はひとつしかありません。モデルがそれらを見たことがなく、知っている中で最も近い単語に置き換えてしまうからです。 同僚のSamは「Sahm」になり、CEOのAoifeは「Eva」になり、製品のConvoは「Convoy」になってしまいます。対策は2段階です。既存の文字起こしに対する置換処理と、同じ誤りの再発を防ぐカスタムボキャブラリーの設定です。

固有名詞が他の単語と違う壊れ方をする理由

AI文字起こしモデルは、学習データに出てくる単語の分布を学習します。よく使われる単語や一般的な名前は十分にカバーされています。しかし、珍しい名前、英語圏以外の名前、技術的な製品名、作られたブランド名は、カバー率が低いか、まったく存在しません。

モデルが聞き慣れない名前を耳にすると、最も近い馴染みのある音を選びます。「Aoife」(イーファと発音されるアイルランドの名前)は「Eva」になり、「Sahm」は「Sam」になり、「Convo」は「Convoy」になります。これは言語モデルの仕組み上の特性です。出力は常にモデルが学習済みの単語であり、見たことのないトークンになることはありません。

この誤りが通常の文字起こしミスと違う点は2つあります。

• 置き換えが一貫していること。モデルはその音を聞くたびに同じ間違いをするため、長い録音では同じ誤った表記が何十回も現れます。
• 誤りが**語彙外(OOV)**であること。モデルには正しい単語の表現がまったくないため、文脈だけで置き換えを改善することはできません。

この2つの特性が、修正方法を左右します。

手軽な修正方法:検索と置換

すでに受け取った文字起こしであれば、検索と置換で5分以内に問題を解決できます。最初の数百語を読みながらリストを作成します。

Sahm → Sam
Eva → Aoife
Convoy → Convo

それぞれの置換を実行します。実践上の注意点がいくつかあります。

• 一般的な単語の中に含まれる短い名前は、大文字小文字を区別する一致を使ってください。大文字小文字を区別せずに「sam」を置換すると、「same」「sample」「Samsung」まで壊れます。
• ファイルを閉じる前に、表記の揺れがないか確認してください。モデルが同じ名前を別々の段落で2通りの綴りで書いている可能性があります(後述の「表記の不一致」のケースを参照)。

同じメンバーでの定期的なセッションでは、新しい文字起こしごとに適用する置換スクリプトを用意しておきましょう。

substitutions = {
    "Sahm": "Sam",
    "Eva": "Aoife",
    "Convoy": "Convo",
}

def fix_names(transcript: str) -> str:
    for wrong, right in substitutions.items():
        transcript = transcript.replace(wrong, right)
    return transcript

これにより、文字起こしごとの面倒な作業が一度きりのセットアップコストに変わります。スクリプトはどの長さのファイルでも数秒で実行できます。

アカウント登録なしで、この置換処理にかけるクリーンな文字起こしだけが必要な場合は、ConvertAudioToTextがログイン不要ですぐに文字起こしを開始し、プレーンテキストまたはDOCX形式でエクスポートできるので、クリーンなテキストに対して置換を実行できます。

検索と置換だけでは足りないとき

検索と置換のアプローチが破綻する具体的なケースは3つあります。

文脈の中の同音異義語。「Pat」という同僚は、文字起こし内の他の「pat」という単語を壊さずに置き換えることができません。カスタムボキャブラリーは、モデルに文脈を読み取らせ、「Pat」を動作ではなく名前として認識することを教えます。

**表記の不一致。**一部の名前はモデルを混乱させすぎて、段落ごとに出力が変わります。同じ録音の中で「Aoife」が「Eva」「Effie」「Eve」として現れることもあります。1つの置換ルールでは3つのうち2つを見逃します。カスタムボキャブラリーはモデルを一貫した1つの出力に固定します。

大文字小文字混在トークンと英数字。「Web3」「iOS」「gRPC」「GPT-4o」。検索と置換でも対応できますが、モデルが複数の大文字小文字パターンを出力するため複数のルールが必要です。カスタムボキャブラリーは推論時に期待される出力形式を固定します。

精度の問題についてさらに深いパターンを知りたい方は、文字起こし精度の解説の記事で、単語誤り率(WER)の計算方法と誤りが集中する箇所を解説しています。

恒久的な解決策:カスタムボキャブラリー

カスタムボキャブラリーは事後対応ではなく予防策です。モデルに認識すべき用語のリストを与えると、それ以降の実行でそれらの用語は正しく文字起こしされます。実装はプラットフォームによって異なります。

各ベンダーのドキュメントに基づく(2026年7月時点で確認)。

Whisperに関する注意点として、OpenAI Whisper APIはinitial_promptパラメーターを受け付け、モデルを期待する語彙へ偏らせることができますが、プロンプトは224トークンまでに制限されており、Whisperのドキュメント自体がこの手法を「特に信頼できるものではない」と説明しています。仕事の中で固有名詞の問題が繰り返し起きるなら、プロンプトエンジニアリングでWhisperを調整するよりも、カスタムボキャブラリーを第一級でサポートするプラットフォームの方が役立ちます。

私の見解としては、ほとんどの個人ユーザーにとって、Deepgramのキータームプロンプティングが最も使いやすいでしょう。事前にリソースを作成する必要がないからです。音声リクエストと一緒に用語リストを渡すだけで、モデルがすぐに取り込みます。同じドメインの語彙で数百件の文字起こしを実行するチームには、AWS Transcribeの名前付きカスタムボキャブラリーファイル方式が、リストを一元管理し、すべてのリクエストで再利用できるので適しています。

良いボキャブラリーリストに入れるべきもの

効果的なリストにはいくつか共通の特徴があります。

• 20〜100語が実用的な範囲です。少なすぎると繰り返し現れる固有名詞を見逃し、多すぎるとモデルが本来関係ない文脈に登録済みの用語を無理やり当てはめ始めます。
• 具体的な用語であって、汎用的なものではない。「Convo」は良い登録例です。「Company」はモデルがすでにうまく扱えるため悪い登録例です。
• **珍しいものを入れ、明白なものは省く。**一般的な英語の単語であるゲストのファーストネーム(「Mark」「Kate」など)は、ボキャブラリーの助けをほとんど必要としません。英語圏以外の名前、作られたブランド名、技術的な略称は必要です。
• **コンテンツの変化に合わせて更新する。**新しいテーマを扱ったり、新しい分野のゲストを迎えたりするポッドキャストは、新しいOOV用語に遭遇します。収録前に追加しておきましょう。

具体的なワークフローへの応用

ポッドキャストのインタビュー番組

ゲスト全員のフルネームと、ゲストが言及しそうな人物(同僚、引用元の人物、共同創業者など)を追加します。技術的な話題の場合は、そのエピソード固有の製品名、会社名、専門用語も加えます。編集前に生の文字起こしに置換リストを実行してください。ポッドキャストに最適な文字起こしの記事では、録音済み音声に関する追加の精度上の考慮点を扱っています。

営業および顧客との通話

自社の製品名、顧客の名前、話題にする競合他社の名前、自社ドメイン固有の技術用語を追加します。こうしたリストは四半期ごとにかなり安定しています。会議の文字起こしでは、話者ラベルと正しい名前を組み合わせることで、後処理の時間を大幅に削減できます。Zoom会議の文字起こし方法の場合も、同じボキャブラリーリストが、録画するプラットフォームを問わず適用できます。

リサーチインタビュー

参加者全員の名前、所属機関、研究分野の専門用語を追加します。引用や参考文献として使われるコンテンツでは、人名や固有名詞の誤りは、気軽なメモの場合より深刻な影響を持ちます。

多言語コンテンツ

カスタムボキャブラリーは、モデルが間違った言語の音声体系で音訳してしまう名前の問題にも役立ちます。多言語コードスイッチングへの対処の記事で、この特定の失敗パターンについて詳しく解説しています。

実践的な段階的構築ワークフロー

多くの常連ユーザーが行き着くパターンは次のとおりです。

1. 空の置換リストと空のボキャブラリーリストから始めます。
2. 最初の3〜5本の文字起こしで誤変換された名前を探し、両方のリストに追加します。
3. この初期パスの後は、繰り返し現れる固有名詞のほとんどがカバーされます。
4. 新しい人物、製品、トピックが仕事に入ってきたら、新しい名前を追加します。
5. APIアクセスがある場合は、リストをツールのカスタムボキャブラリー機能に移し、後処理ステップではなく推論時に適用されるようにします。

セットアップへの投資は小さく、役立つ初期リストの構築には1時間もかかりません。そしてリターンは恒久的です。文字起こしにドメインの略語や専門用語も含まれる場合は、専門用語(ジャーゴン)の文字起こし修正と併用してください。

FAQ

AI文字起こしはなぜ毎回同じ名前を同じように間違えるのですか?

モデルは、その音を聞くたびに、未知の名前を学習分布の中で最も近い単語に置き換えます。ランダムではなく一貫した置き換えです。モデルがある音の似た単語は学習していて、もう一方を学習していないためです。カスタムボキャブラリーは、どの単語を期待すべきかをモデルに伝えることで、この習慣を断ち切ります。

カスタムボキャブラリーはすべての文字起こしエンジンで使えますか?

ほとんどのプロフェッショナル向け・API向けツールが何らかの形で対応していますが、実装はさまざまです。Deepgram Nova-3とFluxはキータームプロンプティング(リクエストあたり最大100語、500トークン上限)をサポートしています。AssemblyAIはバッチ用のkeyterms_prompt(最大1,000語)と強度調整可能なword_boostに対応しています。Google Cloud Speech-to-Textはリクエストあたり最大5,000件のフレーズヒントを受け付けます。AWS Transcribeは名前付きカスタムボキャブラリーファイル(テーブル形式、最大50 KB)を使用します。Otter Proはユーザーごとに名前100件とその他の用語100件を提供します。OpenAI Whisper APIはinitial_promptパラメーター(最大224トークン)を受け付けますが、公式ドキュメント自体がこの手法を固有名詞については特に信頼できないと説明しています。

置換だけでは不十分で、カスタムボキャブラリーが必要になるのはどんな場合ですか?

3つの場合があります。1つ目は同音異義語です。「Pat」という人物を、一般的な単語「pat」と位置情報だけで区別できない場合、一律の置換では一般単語まで壊れてしまいます。2つ目は表記の不一致です。同じファイル内で同じ名前が「Eva」「Effie」「Eve」と出力される場合は、1つではなく複数の置換ルールが必要です。3つ目は「gRPC」や「GPT-4o」のような大文字小文字混在トークンです。モデルが複数の大文字小文字パターンを出力するため置換は脆く、すべてを拾わなければなりません。

カスタムボキャブラリーリストには何語くらい登録すればよいですか?

多くの実務者は20〜100語程度に落ち着いています。少なすぎると繰り返し現れる固有名詞を見逃し、多すぎるとモデルが本来関係ない文脈で登録済みの用語を幻覚的に出力し始めることがあります。具体的で珍しい用語、つまり汎用的な学習データではあまり出会わない名前を含めましょう。モデルがすでにうまく扱える一般的な単語は省きます。

参考資料

• Deepgramキータームプロンプティングのドキュメント: https://developers.deepgram.com/docs/keyterm(2026年7月時点で確認)
• AssemblyAIストリーミングキータームプロンプティング: https://www.assemblyai.com/blog/streaming-keyterms-prompting(2026年7月時点で確認)
• Otter.ai料金ページ、プランごとのカスタムボキャブラリー: https://otter.ai/pricing(2026年7月時点で確認)
• Google Cloud Speech-to-Textのフレーズヒント: https://cloud.google.com/speech-to-text/docs/speech-adaptation(2026年7月時点で確認)
• AWS Transcribeのカスタムボキャブラリー: https://docs.aws.amazon.com/transcribe/latest/dg/custom-vocabulary.html(2026年7月時点で確認)
• Azure Custom Speechの概要: https://learn.microsoft.com/en-us/azure/ai-services/speech-service/custom-speech-overview(2026年7月時点で確認)
• OpenAI Whisperプロンプティングガイド: https://developers.openai.com/cookbook/examples/whisper_prompting_guide(2026年7月時点で確認)