文字起こしの専門用語エラーを修正する：用語集パス

なぜ専門用語で文字起こしが崩れるのか

短い答え：その単語はモデルの学習分布に一度も存在しなかったからです。 AI文字起こしモデルは何百万時間もの音声から学習していますが、そのデータは日常会話に大きく偏っています。「Kubernetes」は学習発話のごく一部にしか現れません。「心電図（electrocardiogram）」はさらに少ない。そのため音響信号が届くと、モデルは知っている音的に似た単語に置き換えます。「Kubernetes」は「cuban itties」になり、「PostgreSQL」は「postgrass quill」になり、「gRPC」は余計なハイフン付きの「g-rpc」と書かれます。

この置き換えはランダムではなく予測可能です。モデルは訓練どおりのことをしているだけです：音声から最も確率の高い単語列を選んでいるのです。問題は、その確率があなたの専門分野ではなく一般英語を反映していることです。これが学習分布のギャップであり、文字化けが散発的ではなく一貫している理由を説明しています。録音の中で話者が「Kubernetes」と言うたびに、文字起こしは「cuban itties」になります。

良いニュースは、修正が構造的だということです。分布のギャップを一度解決すれば、その分野の以降のすべての文字起こしで問題はほぼ消えます。

セットアップコスト順に見る3つの修正アプローチ

方法1：検索と置換（手軽・文字起こしごと）

少数の文字化けした用語がある1つの文字起こしに対しては、検索と置換なら10分未満で済み、どんなツールにも使えます。 出力を読みながら置換リストを作成します：

cuban itties     → Kubernetes
postgrass quill  → PostgreSQL
g-rpc            → gRPC
docker compose   → Docker Compose
postgres equal   → PostgreSQL

各ペアに対して検索と置換を実行します。リストは保存しておきます。同じテーマの次の文字起こしでは、読み始める前にリストを適用します。最初の20個の置換で価値の大部分が得られます。

上限は明らかです：これは事後対応的で、文字起こしごとの対処です。一回限りの録音には適切な選択ですが、週に50本の文字起こしを producing するチームには間違ったアーキテクチャです。

方法2：カスタム語彙とキータームプロンプティング（恒久対策）

カスタム語彙は、エンジンが音声を聞く前にどの用語を優先すべきかを伝えるものです。 現在、ほとんどの本番グレードのAPIがネイティブでこれをサポートしており、セットアップは一度きりのコストです。

実装はプラットフォームごとに異なります：

確認済みの詳細で知っておく価値のあるもの：

Deepgram Nova-3のキータームプロンプティング（2026年7月確認）：クエリパラメータとしてkeyterm=TERMを渡し、用語ごとに繰り返します。Deepgramのドキュメントによると、用語はリクエストあたり合計500トークンまでに制限されており、実用的な推奨は20〜50個の高価値用語です。キータームプロンプティングはNova-3モデルとFlux固有のもので、旧世代のNova-2は別のkeywordsパラメータを使用します。

AssemblyAIのキータームズプロンプティングは現在、ストリーミング文字起こし向けにドキュメント化されており、50文字以内の用語を最大100個まで指定できます。パラメータはストリーミング設定のkeyterms_promptです。バッチ文字起こしでは、AssemblyAIのレガシーなword_boostパラメータにlow、default、highのboost_param値を組み合わせる方法が引き続き有効です。

OpenAI Whisper APIのpromptパラメータ：promptフィールドは最大224トークンを受け付け、含めた内容の表記パターンをモデルが模倣することで機能します。OpenAIのクックブック（2026年7月確認）によると、自然な文形式のプロンプトは単なるリストより優れた結果を出します。「Kubernetes, PostgreSQL」ではなく「エンジニアはKubernetesクラスタとPostgreSQLレプリケーションについて議論しました」のように書きます。モデルはあなたの表記をコピーします。音声に存在しない情報を追加することはできませんが、与えた表記を強く優先するようになります。

AWS Transcribeのカスタム語彙：S3にアップロードする4列のテーブル形式（Phrase、IPA、SoundsLike、DisplayAs）を使用します。アカウントあたり最大100ファイル、ファイルあたり50 KB、エントリあたり256文字です。医療版（Amazon Transcribe Medical）は臨床用語向けの別の語彙をサポートしていますが、米国英語のみです。

これらのいずれでも、恒久対策のためのワークフローは次のとおりです：

1. 自分の分野で繰り返し現れる30〜100個の用語のリストを作成します。
2. リストをエンジンの語彙機能にアップロードまたは渡します。
3. 以降、その分野のすべての文字起こしが恩恵を受けます。
4. 語彙の進化に合わせて四半期ごとにリストを見直し、拡張します。

APIベースのワークフローについては、2026年の音声認識API比較で、どのエンジンが最も少ない手間でカスタム語彙を扱えるかを横並びで確認できます。

方法3：ドメイン特化型モデルのトレーニング（重いセットアップ、最高の上限）

非常に大量の単一分野の文字起こしには、ファインチューニングされたモデルが最も難しい用語において語彙ヒントを上回ります。 Deepgram Nova-3 Medicalがまさにそれです：語彙リストを付けたベースモデルではなく、臨床音声で事前学習されたモデルです。AWS Transcribe Medicalも同様のアプローチを取っています。Azure Custom Speechでは自分のラベル付き音声でトレーニングできます。

コスト対効果の転換点はおおよそ次のとおりです：月5万分未満のドメイン特化音声では、強力なベースモデルでのカスタム語彙のほうがモデルトレーニングより実用的です。それを超えると、精度と保守のトレードオフがファインチューニングモデルを支持し始めます。

これを読んでいるほとんどのチームにとって、答えは方法2です。

良い語彙リストの作り方

よく作られたリストは、文字起こしツールに関係なく、分野を超えて共通の特徴を持っています。

製品名と技術名

会話で言及されるすべての製品——自社のもの、競合のもの、ベンダーのものを含みます。「Kubernetes」と「K8s」は、モデルがそれぞれ異なる音として認識するため、別々のエントリが必要かもしれません。「PostgreSQL」と「Postgres」も同じ理由で別々のエントリにする価値があります。

希望する表記のままの頭字語

モデルが展開したり台無しにしたりしがちな技術的な頭字語。文字起こしに現れるべき形そのままで書きます：「g-r-p-c」ではなく「gRPC」、「sass」ではなく「SaaS」、「duh-dos」ではなく「DDoS」、「elm」ではなく「LLM」。AWS TranscribeのDisplayAs列とDeepgramキータームの文字列形式はどちらも、出力形式を正確に指定できます。

複合語と複数単語のフレーズ

モデルが不適切に分割してしまうかもしれないフレーズ。「Test-driven development」をキータームとして渡せば、バラバラの3つの単語ではなく、その完全なフレーズが出力されます。「心筋梗塞（myocardial infarction）」をひとまとまりとして処理すると、各単語を個別に処理するより確実に文字起こしされます。

専門用語

その分野の実務者だけが日常的に使う用語。セキュリティなら：特定のCVEパターン、エクスプロイトフレームワーク、プロトコル名。医療なら：臨床名称による薬剤名（商品名だけでなく）、処置名、解剖学用語。法律なら：ラテン語のフレーズ、特定の法理、手続き上の申立ての種類。

一般的な単語に聞こえる名前

人名、企業名、技術名の中には、一般的な英単語と音が衝突するものがあります。サーバープロジェクトの「Apache」と日常語としてのapache。JavaScriptフレームワークの「Vue」。プログラミング言語の「Rust」。言語としての「Swift」。モデルが辞書的な意味として解釈しないようにするには、強い事前確率が必要です。

分野別リファレンスリスト

これらは出発点であり、完全なソリューションではありません。最初の文字起こしを読んで、モデルが間違えたものを追加してください。

ソフトウェアエンジニアリング

Kubernetes, k8s, PostgreSQL, Postgres, gRPC, GraphQL, Docker,
TypeScript, async/await, monorepo, microservices, OAuth, JWT,
SQLite, MongoDB, Cassandra, Kafka, Redis, Elasticsearch,
LangChain, OpenAI, Anthropic, Claude, GPT-4o,
WebAssembly, WASM, RAG, vector database, embedding

医療

electrocardiogram, ECG, EKG, echocardiogram, defibrillator,
endotracheal intubation, laparoscopic, cholecystectomy,
metformin, lisinopril, atorvastatin, amoxicillin, ondansetron,
hypertension, hyperlipidemia, hypothyroidism, diabetes mellitus,
osteoarthritis, atrial fibrillation, myocardial infarction

法律

voir dire, habeas corpus, prima facie, mens rea, res ipsa loquitur,
amicus curiae, certiorari, en banc, stare decisis, sub judice,
deposition, interrogatory, subpoena, discovery, motion in limine,
summary judgment, demurrer, appellate, statute of limitations

金融

EBITDA, ARR, MRR, churn, LTV, CAC, IRR, NPV, IPO, SPAC,
revenue recognition, accrual basis, deferred revenue, GAAP, IFRS,
preferred stock, common stock, dilution, cap table, term sheet,
liquidation preference, anti-dilution, mezzanine

特定の分野ではなく特定の人に属する固有名詞については、誤って文字起こしされた名前の修正で、人名の例とともに同じ仕組みを解説しています。

専門用語の多い作業ではツール選択が重要

すべての文字起こしツールが一般ユーザーに語彙コントロールを公開しているわけではありません。専門分野で使う価値のあるツール：

API経由のDeepgram Nova-3：キータームプロンプティングはドキュメントが充実しており、リクエストごとに即座に反映されます。アップロードの手間も待ち時間もありません。

API経由のAssemblyAI：バッチにはword_boost、ストリーミングにはkeyterms_prompt。どちらもリクエストレベルのパラメータです。

AWS Transcribe：カスタム語彙ファイルは使用前にS3へのアップロードと作成ステップが必要ですが、永続化され、ジョブ間で再利用できます。

AWS Transcribe Medical：臨床語彙がプリロードされ、米国英語をサポートする別製品です。医療カスタム語彙機能がそのベースに追加されます。

Google Cloud STT（Chirp 3）：スピーチアダプテーションのフレーズはDeepgramと同様にリクエストごとに渡されます。Chirp 3は2026年半ば時点の現行世代です。

promptパラメータ経由のOpenAI Whisper API：専用のカスタム語彙機能より弱いですが、セットアップ不要です。専門用語リストが短い場合（30用語未満）で、プロンプトが224トークンに収まる場合に有用です。

語彙の工夫にかかわらず苦戦するツール：Web Speech APIを使うブラウザベースのツール、そして語彙パラメータを一切公開していないフリーティアのサービス。

私の見解：安定した分野の語彙を持つチームには、Deepgram Nova-3のキータームプロンプティングが、文字化けからクリーンな結果への最も手間のかからない道です。語彙は即座に反映され、アップロードステップが不要で、分単位の料金以外に追加コストがかかりません。特に医療については、Nova-3 Medicalは目的特化型なので、カスタム用語なしでも臨床用語を処理できることがよくあります。

API統合を管理せずにクリーンな文字起こしだけが必要な場合は、ConvertAudioToTextの音声文字起こしツールがファイルアップロードによる直接変換に対応しています。修正後の出力を使って置換リストを作成し、用語リストが安定したらAPIレベルの語彙コントロールに移行しましょう。

AIがまだ人間に敵わないとき

一部の専門用語は、語彙コントロールがあっても、AI文字起こしには本当に手が届きません：

• どのモデルの学習カットオフよりも後に開始された臨床試験の薬剤名。
• 語彙が公的な音声コーパスに一度も現れたことのない工学の狭いサブ分野（例えば半導体プロセス化学）。
• 現代の録音にはほとんど現れない古風な法律用語。

そうしたケースでは、分野の専門知識を持つ人間の文字起こし担当者が正直な答えです。AIと人間の文字起こし比較の記事では、そのエスカレーションが金銭的に意味を持つのはいつかを扱っています。2026年のその他すべてのケースでは、強力なベースモデルでのカスタム語彙に軽い手動校正を組み合わせれば、出版品質の結果が得られます。

よくある質問

なぜモデルは一般的な単語は正しく文字起こしできるのに、専門用語では失敗するのですか？

モデルの確率推定は学習データに基づいています。一般的な英単語は数百万回出現しますが、専門用語はほとんど、あるいはまったく出現しません。モデルが「Kubernetes」を聞いたとき、音響信号は学習分布の中で正しい用語よりも「cuban itties」のほうが強く一致するため、誤った出力が勝ってしまいます。語彙コントロールは対象用語を明示的にブーストすることで、この事前確率を上書きします。

Whisper APIはカスタム語彙に対応していますか？

専用の語彙機能としては対応していません。promptパラメータ（最大224トークン）には例文を渡せますが、モデルはプロンプト内の表記に合わせようとするだけです。技術用語を本来あるべき形で使った自然な文章（「チームはPostgreSQLクラスタをKubernetesへ移行しました」など）を書くほうが、単語を羅列するより効果的です。深刻な専門用語の問題には、きちんとした語彙APIを持つDeepgramやAssemblyAIのほうが信頼できます。

語彙リストには何個くらいの用語を入れるべきですか？

最初の文字起こしで最も多くエラーが出た20〜30個の用語から始めましょう。Deepgram Nova-3は1リクエストあたり最大500トークン（約100用語）まで対応しています。AssemblyAIのストリーミングは50文字以内の用語を最大100個まで登録できます。AWS Transcribeのファイルはそれ以上も保存できますが、大きな語彙リストは音声に実際には存在しない用語の精度を下げることがあるため、絞り込んだ小さなリストのほうが詰め込んだリストより良い結果を出す傾向があります。

カスタム語彙は頭字語にも効果がありますか、それとも完全な単語だけですか？

両方です。頭字語はモデルが頻繁に展開してしまう（「SaaS」が「sass」、「gRPC」が「g rpc」になる）ため、最も価値の高い登録項目になりがちです。頭字語は希望する出力形式そのままで渡してください：gRPC、DDoS、LLM。AWS TranscribeのようにDisplayAsフィールドを指定できるプラットフォームでは、出力の大文字表記や句読点を正確に制御できます。

出典

• Deepgramキータームプロンプティングのドキュメント（2026年7月確認）：https://developers.deepgram.com/docs/keyterm
• Deepgram Nova-3 Medical発表：https://deepgram.com/learn/introducing-nova-3-medical-speech-to-text-api
• AssemblyAIストリーミングキータームズプロンプティングのブログ記事：https://www.assemblyai.com/blog/streaming-keyterms-prompting
• AWS Transcribeカスタム語彙のドキュメント（2026年7月確認）：https://docs.aws.amazon.com/transcribe/latest/dg/custom-vocabulary.html
• AWS Transcribe Medicalカスタム語彙：https://docs.aws.amazon.com/transcribe/latest/dg/vocabulary-med.html
• Google Cloud Speech-to-Textスピーチアダプテーション：https://docs.cloud.google.com/speech-to-text/docs/adaptation-model
• OpenAI Whisperプロンプティングガイド：https://developers.openai.com/cookbook/examples/whisper_prompting_guide