文字起こしで句読点が消えたときの直し方（2026年版ガイド）

句読点はどこから来るのか

最速の解決策は、API呼び出しで句読点を有効にするという、たった1つの設定変更です。 すでに文字起こし結果がある場合は、GPT-4oやClaudeに貼り付けて、単語を変えずに句読点を追加するよう指示します。すべてのジョブで問題が繰り返されるなら、句読点がデフォルトで有効になっているツールに切り替えましょう。

文字起こしにおける句読点は、音声そのものから生まれるものではありません。生の音声認識の上に、文字起こしエンジンが追加するレイヤーから生まれます。最新のエンジンは、生の単語列を言語モデルに通し、構文と韻律に基づいて句点・読点・疑問符がどこに入るべきかを予測します。このレイヤーをデフォルトで実行するエンジンもあれば、フラグが必要なエンジンもあります。まったく省略しているエンジンも少数あります。

どのレイヤーが欠けているのかを理解すれば、どこに介入すべきかが正確にわかります。

言語モデルによる後処理レイヤー

生の音声認識は、大まかなタイミング情報を持つ単語列を出力します。別のモデル（句読点復元モデルやテキスト正規化ツールと呼ばれることもあります）がその単語列を受け取り、文法、タイミングデータに含まれる抑揚の手がかり、大規模テキストコーパスからの統計的パターンに基づいて句読点を挿入します。

このレイヤーが動作すれば、読めるドキュメントになります。動作しなければ、文字の壁が残ります。

このレイヤーが機能しない理由は3つあります。設定フラグで無効化されている、セルフホスト環境に存在しない、あるいは存在しても扱う分野や言語に対してモデルが小さすぎる、のいずれかです。

文字起こしに句読点がない理由

2026年現在、句読点のない文字起こしのほぼすべては、次の3つの設定パターンで説明できます。

Deepgramで句読点が有効になっていないケース

Deepgramは、punctuateパラメータと、より広範なsmart_formatパラメータの両方がデフォルトでfalseの状態で提供されています。どちらのフラグも指定せずにAPIを呼び出すと、句読点のない単語ごとの出力になります。

smart_format=trueを設定すると、1つのフラグで句読点、段落区切り、テキスト正規化（日付、通貨、電話番号）が有効になります。句読点だけが必要なら、punctuate=trueがピンポイントな選択肢です。Deepgramのドキュメント（2026年7月時点で確認）によれば、両方は不要です。smart_format=trueだけで句読点が自動的に有効になります。

後処理のないセルフホストWhisper

OpenAIのWhisperモデルはある程度の句読点を出力しますが、一貫性がありません。モデルは30秒ごとのチャンクで独立して音声を処理するため、チャンク境界で句読点の品質が落ちます。文末の句点の欠落、位置がずれた読点、直接話法を囲む引用符の欠如は、セルフホスト環境で報告され繰り返される既知の問題です。

ホスト型のWhisper（OpenAIのgpt-4o-transcribeエンドポイント）はより良好ですが、後処理レイヤーのないセルフホスト環境では、部分的には句読点が付いているものの、全文書を通しては信頼できない出力が頻繁に生成されます。

ブラウザのWeb Speech API

Web Speech APIを基盤とするブラウザベースのツールは、句読点のサポートが限定的です。仕様にはcontinuous属性が含まれていますが、句読点の挿入はブラウザの基盤となる音声エンジンに依存します。実際には、多くのブラウザベースのツールは句読点のない、または最小限の句読点しかないテキストを返し、クライアント側の後処理で補っています。

主要エンジンごとの句読点のデフォルト挙動

即効策：事後の句読点復元

すでに句読点のない文字起こしがあり、今すぐ直したい場合、確実に機能する2つの方法があります。

LLMによる句読点復元

句読点のないテキストを、明確な指示とともにGPT-4oまたはClaudeに渡します：

Add punctuation and paragraph breaks to the following transcript.
Do not change any words. Use periods, commas, and question marks
where natural. Insert paragraph breaks when the topic shifts or
when the speaker changes.

Transcript:
[paste here]

これはモデルが十分に対応しているあらゆる言語で機能します。結果は数秒で使えるドキュメントとして得られます。OpenAI API経由で1時間分の文字起こしを処理するコストは、たまに使う程度なら無視できるほど小さいものです。

バッチ処理向けのオープンソース句読点復元

大量処理の場合、Pythonライブラリのdeepmultilingualpunctuationは、ドキュメントごとにLLMを呼び出すことなく、専用の句読点モデルをローカルで実行できます：

from deepmultilingualpunctuation import PunctuationModel
model = PunctuationModel()
result = model.restore_punctuation(unpunctuated_text)

このライブラリは英語、ドイツ語、フランス語、イタリア語に対応しています。議会演説で学習されているため、技術的な音声や会話調の音声ではドメインシフトが起きる可能性があります。本番投入前にサンプルで必ずテストしてください。

これら4言語以外が必要な場合は、LLM方式の方が広く汎用されます。

恒久策：設定で句読点を有効にする

継続的な文字起こしでは、正しい答えは毎回の復元ステップではなく、たった1回の設定変更です。

Deepgramユーザー： API呼び出しにsmart_format=trueを追加しましょう。この1つのフラグで、英語の句読点、段落区切り、テキスト正規化がカバーされます。他の言語ではsmart_formatの対応範囲が狭いため、対象言語を明示的にテストし、必要ならpunctuate=trueにフォールバックしてください。

Whisperユーザー： セルフホストしているなら、移行よりもパイプラインに句読点復元ステップを追加する方が簡単かどうか検討しましょう。deepmultilingualpunctuationを使った軽量な後処理パスや小さなLLM呼び出しは、1ステップで追加できます。ホスト型のOpenAIエンドポイントを使っているなら出力品質は向上しますが、長いファイルについてはチャンク境界の問題を引き続きテストしてください。

ブラウザベースのツール： ツールがWeb Speech APIを基盤としており、一貫して句読点のない出力をするなら、問題は基盤となるエンジンにあります。設定フラグでは直りません。現実的な解決策は、代わりにサーバーサイドのAPIへ音声を送ることです。

何も設定せずにファイルを文字起こしさえできればいいという場合は、ConvertAudioToTextがアカウント登録不要で、句読点と段落区切り付きの出力をデフォルトで返します。

貧弱な句読点の症状と、さらに踏み込むべきケース

句読点の問題がすべて「句読点がまったくない」というわけではありません。句読点を付けているのに下手なツールもあります。症状はそれぞれ異なります。

意味にかかわらず、息継ぎのたびに句点が入る。 モデルは話者が息継ぎで止まる場所すべてに句点を挿入し、節の途中でも例外ではありません。その結果、自然につながった考えが細切れになった、短く途切れ途切れの文になります。これは適切な言語モデルレイヤーではなく、無音検出を使っているサインです。

読点はあるのに句点がない。 逆のパターンです。モデルは読点を挿入するものの、文の境界で文を完結させません。全体が読点でつながれたままの、長い一文が続きます。

段落区切りがない。 文の中の句読点は問題ないのに、文字起こしがひと続きのブロックになっているケースです。話題の転換や話者の交代が段落構造に反映されていません。これは可読性への影響が最も大きい問題で、手作業での修正か、段落区切りを追加するLLMベースの修正が必要になることが多いです。

疑問符が一貫して欠ける。 上昇イントネーションの平叙文として発せられた質問に、句点が付いてしまうケースです。モデルは構文を検出できても韻律を検出できていません。「質問のように読める文」を手動で探して直すか、構文で質問を見分けるよう指示したターゲットを絞ったLLMパスを実行しましょう。

特に文がつながり続けるケースでは、音読テストが有効です。文字起こしを声に出して読み、読点で区切るよりも長く自然に止まる場所に句点を挿入します。会話調の音声の文境界検出については、耳の方がモデルより信頼できます。

言語別の句読点品質

英語は、すべての主要エンジンで最も強力な句読点サポートを受けています。主要なヨーロッパ言語（スペイン語、フランス語、ドイツ語、イタリア語、ポルトガル語）はAssemblyAIとDeepgramでよくサポートされていますが、ばらつきがあります。句読点の慣習が異なるアジア言語（日本語、韓国語、中国語）は、句読点のルールが構造的に異なるため、エンジンごとのテストが必要です。低リソース言語では、句読点サポートが全体的に弱くなります。

英語以外の文字起こしでは、ルールベースのモデルよりもLLMによる復元の方が広く汎用されます。大規模言語モデルは多くの言語の句読点の慣習を重みの中に持っているからです。言語サポートが出力品質全体にどう影響するかについては、文字起こし精度の解説のガイドを参照してください。

FAQ

なぜ文字起こし結果に句点や読点がないのですか？

最も多い原因は、利用中の文字起こしAPIで句読点がデフォルトで無効になっており、有効化していないことです。例えばDeepgramのpunctuateとsmart_formatパラメータは、どちらもデフォルトでfalseです。もう1つの原因は、言語モデルによる後処理レイヤーを持たないセルフホストのWhisper環境の利用で、特に30秒チャンクの境界で句読点が劣化します。

すでにある文字起こしの句読点は直せますか？

はい。句読点のないテキストをGPT-4oやClaudeに貼り付け、単語を一切変えずに句読点を追加するようプロンプトで指示します。バッチ処理には、オープンソースのdeepmultilingualpunctuationライブラリが、トランスクリプトごとのLLM呼び出しなしで英語、フランス語、ドイツ語、イタリア語を処理できます。

AWS Transcribeは句読点のないテキストを出力しますか？

いいえ。AWSのドキュメントによれば、AWS Transcribeは対応するすべての言語で、デフォルトのまま自動的に句読点を追加します。フラグを有効にする必要はありません。AWS Transcribeの出力に句読点がない場合、原因は下流のフォーマット処理、エクスポート設定、あるいは句読点を剥がすラッパーライブラリである可能性が高いです。

使っているツールで句読点がデフォルトで有効かどうかは、どうやって確認すればよいですか？

はっきり聞き取れる話し声音声を30秒ほどツールに通してみてください。出力が句点のない長い単語の連なりであれば、そのツールは句読点がデフォルトでオフになっているか、そもそも対応していません。同じ音声をAssemblyAI（デフォルトでオン）やOpenAI Whisper APIでも処理して比較すれば、問題がツールの設定にあるのかを切り分けられます。

出典

• Deepgram Smart Formatドキュメント： https://developers.deepgram.com/docs/smart-format （2026年7月時点で確認）
• Deepgram Punctuationパラメータドキュメント： https://developers.deepgram.com/docs/punctuation （2026年7月時点で確認）
• AssemblyAI自動句読点・大文字化ドキュメント： https://www.assemblyai.com/docs/pre-recorded-audio/automatic-punctuation-and-casing （2026年7月時点で確認）
• AWS Transcribe句読点ドキュメント： https://docs.aws.amazon.com/transcribe/latest/dg/how-numbers.html （2026年7月時点で確認）
• Whisper句読点の制限に関する分析： https://prosperasoft.com/blog/openai/whisper-ai/whisper-punctuation-capitalization/ （2026年7月時点で確認）
• deepmultilingualpunctuationライブラリ： https://pypi.org/project/deepmultilingualpunctuation/ （2026年7月時点で確認）