OCRが文字化けを起こすのはなぜ?
根本原因3つと修正方法
ドキュメントをOCRにかけたのに、きれいなテキストの代わりに é や ’、疑問符だらけの四角、あるいはキーボードを階段から落としたかのような文字列が出てきたことはありませんか?この現象——文字化け(日本語で「文字の変形」)と呼ばれるもの——には技術的な根本原因があり、それを理解すれば修正は簡単になります。

重要なポイント
éがあるべき場所に表示されるéは壊れたデータではありません。UTF-8のバイトをWindows-1252のレンズで解釈した結果であり、読み取りレンズを切り替えるだけでファイル内のすべての文字が即座に復元されます。- 文字化けしたOCRを引き起こす原因は3つ——エンコーディングの不一致、壊れたフォントマップ、低解像度による文字の置き換え——で、それぞれに診断用の特徴があり、ツールを開く前にどの修正を使うべきかがわかります。
- 最も手強い文字化けのケースは、OCRがPDF内の壊れた非表示テキストレイヤーを読み取っていて、視覚的な画像を読んでいないことが原因です。OCRにレンダリング済みページを直接読み取らせれば、文字化けは消えます。
文字化けした出力が表示されているなら、それはあなただけではありません。あるサブレディットコミュニティは、自分の文字化けが「何語なのか」を特定しようとする人々のために存在しています。Adobe Acrobatのコミュニティフォーラムには、日本語のOCRが蟷エ莉」繧「繧ク繧「縺ォ縺翫¢繧九げ繝ュ繝シ繝舌Ν蛹悶のような文字列を生成したという未解決のスレッドが数十件あります。文字化けの修正に特化したツールであるPythonのftfyライブラリは、これが業界全体で繰り返し発生する問題であるため、何百万回もダウンロードされています。
良い知らせがあります。文字化けしたOCRテキストはランダムな損傷ではありません。これは3つの根本的なメカニズムのいずれかによって引き起こされる、予測可能なパターンに従います。パターンを特定できれば、修正は再現可能です。
原因1 — エンコーディング不一致:最も一般的な原因

症状:アクセント付き文字、通貨記号、スマート引用符が複数文字の文字化けに変わります。スペイン語のcorazónはcorazónになります。ユーロ記号の€は€として表示されます。波括弧の引用符は“このように見えますâ€。文書はほとんど読めますが、非ASCII文字はすべて間違っています。
発生理由:文字エンコーディングは、バイトを文字にマッピングする方法についてのファイルとリーダー間の取り決めです。OCRエンジンがあるエンコーディング(たとえばUTF-8)でファイルを読み取る一方で、ファイルが別のエンコーディング(たとえばWindows-1252)で作成された場合、同じバイトがまったく異なる文字にマッピングされます。結果は体系的な破損です — インチで描かれた地図をセンチメートルとして読むようなものです。すべての測定値が同じ係数だけずれ、その誤りのパターンから、どの変換が適用されたかを正確に特定できます。
どのエンコーディング不一致かを見分ける方法
特定の文字化けパターンは非常に特徴的で、出力を見るだけでエンコーディングエラーを診断できます。
| 表示される文字 | 元のエンコーディング | 誤って解釈されたエンコーディング |
|---|---|---|
é(本来は é) | UTF-8 | Latin-1 / Windows-1252 |
’(本来は ') | UTF-8 | Windows-1252 |
–(本来は –(enダッシュ)) | UTF-8 | Windows-1252 |
日本(本来は 日本) | Shift-JIS | UTF-8 または Latin-1 |
四角い記号 ▯▯▯ や ???? | Unicode | システムにフォントがない/エンコーディングが間違っている |
エンコーディング不一致の修正方法
方法1:正しいエンコーディングで保存し直す。 VS CodeやNotepad++など、エンコーディングを明示的に変更できるテキストエディタで元の文書(またはOCR出力)を開きます。「名前を付けて保存」→「UTF-8」を選択します。ファイルが元々Windows-1252だった場合、適切な文字検出を行ってUTF-8で保存し直せば、多くの場合解決します。
方法2:文字化け修復ツールを使う。 一括修正や自動修正には、ftfy Pythonライブラリ(pip install ftfy)が便利です。このライブラリは、一般的なエンコーディングエラーを自動検出して逆変換します。誤ったエンコーディングでデコードされ、再エンコードされ、さらに誤ってデコードされるという多重の破損にも対応できます。ftfy.fix_text()を1回呼び出すだけで、ほとんどの単一・二重エンコーディングミスを修正できます。
方法3:OCRエンジンにテキストレイヤーではなく画像レイヤーを再読み取りさせる。 PDFの文字化け問題の多くは、PDF自体のテキストレイヤーが壊れていたり、独自エンコーディングになっている一方で、画像レイヤーは完全に正常であることに起因します。OCRツールでページを画像として扱う設定にすると、既存のテキストレイヤーを抽出するのではなく、レンダリングされたグリフからすべての文字を再認識するため、エンコーディングの損傷を回避できます。Adobe Acrobatの場合は、OCR設定で「検索可能な画像(圧縮)」ではなく「ClearScan」または「検索可能な画像(完全)」を選択します。
重要なポイント: エンコーディング不一致による文字化けは最も修正しやすい種類です。データが失われたのではなく、間違った鍵で読み取られただけだからです。正しい鍵を見つければ、すべての文字が復元されます。
原因2 — フォントエンコーディング:グリフは正しく見えるが文字コードが間違っている場合

症状:PDFは画面上で完璧に表示されます。すべての文字が正しく見えます。しかし、テキストをコピーしたりOCRを実行すると、GLYPH<38>、9%)A:\2A、または意味のない文字列の繰り返しなど、無意味な出力が生成されます。視覚的なページはきれいなのに、テキストレイヤーはめちゃくちゃです。
原因:PDFファイルには「テキスト」の2つのレイヤーがあります。視覚的なグリフ(画面上でレンダリングされて見えるもの)と、文字とグリフのマッピング(テキスト抽出器やOCRエンジンが読み取るもの)です。通常、これら2つのレイヤーは一致します。しかし、品質の低いPDFでは、フォントファイルにカスタムグリフエンコーディングが含まれている場合があります。グリフの形状は正しい(ページは正常に見える)ものの、マッピングされる文字コードが非標準であるか、Unicodeマッピングが完全に欠落しているのです。
この状況は驚くほど一般的です。サブセットフォント(文書で使用される正確な文字だけが含まれるフォント)は、内部マッピングに非標準の文字ID(CID)を使用することがよくあります。テキスト抽出器が標準のエンコーディングテーブルを使ってこれらのCIDを解釈しようとすると、文字化けが発生します。Doclingプロジェクトで報告された問題はまさにこれを示しています。PDFは正常に表示され、OCRはdo_ocr=Trueに設定されていたのに、出力は'() +,- .+.. /01 02034567638469:; 4<8:=>でした。フォントの内部エンコーディングが標準のUnicodeにマッピングされていなかったためです。
フォントエンコーディングの文字化けが最も発生しやすいシナリオ:
- 専門ソフトウェアで生成されたPDF:CADツール(AutoCAD、Archicad)、ERPレポートジェネレーター、またはレガシーな印刷用PDFドライバーは、カスタムエンコーディングテーブルを持つフォントを埋め込むことがよくあります。Adobeフォーラムでのコミュニティディスカッションでは、ArchicadユーザーのPDFにSegoe UIが埋め込まれていたにもかかわらず文字化けが発生した事例が説明されています。埋め込むだけでは標準の文字マッピングが保証されないためです。
- PDF/Aまたはデジタル署名付き文書:コンプライアンス重視の文書形式では、変換プロセス中に文字マッピング情報が削除または変更されることがあります。
- 以前のOCR処理で非表示のテキストレイヤーが追加されたスキャン文書:以前のOCRで誤った文字が生成され、そのテキストレイヤーが埋め込まれた状態でPDFが保存された場合、その後の抽出では新しい認識を実行する代わりに、キャッシュされた誤ったテキストが読み取られます。
- 非ラテン文字を含む文書:日本語のShift-JISフォント、韓国語のEUC-KRフォント、中国語のGBエンコーディングフォントは、PDFビューアーやOCRエンジンが異なるコードページをデフォルトで使用する場合、エンコーディングの不一致の頻繁な原因となります。
フォントエンコーディングの文字化けを修正する方法
方法1: 画像レイヤーに対して強制的に新しいOCRを実行する。これが最も確実な修正方法です。OCRツールに既存のテキストレイヤーを無視させ、レンダリングされたページ画像から直接読み取るように指示します。Acrobat Proでは、ツール → スキャンとOCR → テキスト認識 → このファイル内に移動し、OCRエンジンがドキュメントをスキャン画像として扱うようにします。ocrmypdfでは、--force-ocrフラグを使用して既存のテキストレイヤーを完全に上書きします。
方法2: ロスレス画像形式に変換して再OCRする。PDFページを高解像度のTIFFまたはPNGファイル(最低300 DPI)としてエクスポートし、それらの画像に対してOCRを実行します。これにより、壊れたフォントエンコーディングのメタデータがすべて除去され、OCRエンジンにクリーンな視覚ソースが提供されます。日本語の文字化けに関するAdobe Acrobatコミュニティのスレッドでは、TIFFにエクスポートして再OCRすることで、直接PDFにOCRを実行した場合に失敗した問題が解決されたことが報告されています。
方法3: Preflightでフォントの埋め込みを確認する。Adobe Acrobat Proで、ツール → 印刷工程 → Preflightを使用し、フォント分析プロファイルを実行します。これにより、フォントが完全に埋め込まれているか、サブセット埋め込みか、欠落しているか、Unicode文字マップが含まれているかが表示されます。フォントが適切な/ToUnicodeテーブルなしでサブセット埋め込みされている場合、それが根本原因の証拠です。
原因3 — 解像度と文字の混同:画質がOCRの精度を低下させる場合

症状:個々の文字が、もっともらしい代替文字に見える形で誤認識されます。5がSに、0がOに、1がl(小文字のL)に、rnがmになります。句読点が消えます。eやaなどの文字の細いストロークが欠落し、単語が省略されているように見えます。出力は完全な文字化けではなく、微妙でイライラするほど間違っています。
発生理由:OCRエンジンは、文字の形状を既知のグリフモデルと照合することで機能します。入力画像の解像度が不十分な場合、利用可能なピクセル数では視覚的に類似した文字を区別できません。72 DPIの文字Sは、垂直方向に約10〜12ピクセルを占めます。その解像度では、5のセリフとSの曲線が同一に見えることがあります。これはエンコーディングの問題ではなく、根本的な情報理論上の制約です。画像に各文字の識別特徴を表現するのに十分なピクセルが含まれていない場合、どんなに高度なOCRエンジンでも毎回完璧な推測はできません。
この種のエラーは、特に以下の状況で多く発生します:
- 暗い場所や斜めの角度で撮影した書類のスマートフォン写真
- FAXや繰り返しコピーされたページで、世代を重ねるごとに詳細が失われる場合
- 歴史的記録の古いマイクロフィルムスキャン
- 小さいフォントサイズ(8ポイント以下)で200 DPI以下でスキャンされた書類
解像度に関連する文字化けを修正する方法
方法1: 入力解像度を上げる。OCRの業界標準は最低300 DPIで、小さな文字や密集した文字には400〜600 DPIが推奨されます。スマートフォンの写真から作業する場合、画像の前処理手順(アップスケーリング、シャープ化、傾き補正など)をOCRエンジンに画像を送る前に行うと効果的です。
方法2: 従来のOCRの代わりにビジョンベースの抽出ツールを使用する。これが構造的な修正です。従来のOCRエンジン(Tesseract、ABBYY、Adobe OCR)は文字単位のパターンマッチングに依存しています。そのため、ピクセルが1つ欠けるだけで5がSに変わってしまうのです。最新のビジョン言語モデル(VLM)抽出(ImageToTable.aiや類似ツールで採用されているアプローチ)は、単語や文章全体を視覚的なオブジェクトとして読み取り、意味的な文脈を利用して曖昧さを解決します。エンジンが「Order S units」という文字と、その周囲が請求書であるという文脈を見たとき、Sはおそらく5であると理解します。これは文字の形をより良く認識するからではなく、「Order 5 units」が意味を成すのに対し、「Order S units」は意味を成さないからです。これが従来のOCRとどう違うかの説明については、OCRとは何か、その限界がどこから来るのかをお読みください。
方法3: OCRの前に画像の前処理を適用する。簡単な前処理でも文字の混同を劇的に減らすことができます。グレースケールへの変換、適応的しきい値処理によるテキストの2値化、ノイズ(斑点、背景パターン)の除去により、OCRエンジンによりクリーンな信号を与えることができます。実証済みの前処理ワークフローについては、OCR精度向上ガイドをご覧ください。
エスカレーションのタイミング: どの修正方法でも解決しない場合の対処法
エンコーディングを確認し、フォントをチェックし、画像の前処理を行っても、出力がまだ文字化けしている場合、そのツール自体がその文書タイプに適していない可能性があります。複数のスクリプトが混在する文書、装飾的なフォント、数式、または重いスタンプのオーバーレイがある文書は、従来のOCRをその設計限界を超えて押し上げます。
このような場合、実用的な解決策は、文書を全体的に読み取るテンプレート不要のビジョンAI抽出ツールに切り替えることです。ImageToTable.aiのようなツールは、ページの視覚的なレンダリングから意味を抽出するため、エンコーディングやフォントの問題を完全に回避します。既存のテキストレイヤーに依存しないからです。文書をアップロードし、抽出したい列に名前を付け、AIが文書の視覚的・意味的構造を理解してデータを抽出します。フォントに依存するテキストレイヤーも、心配するエンコーディングテーブルもありません。
よくある質問
画面ではPDFが正常に見えるのに、コピーすると文字化けするのはなぜ?
ほぼ常にフォントエンコーディングの問題(原因2)です。PDFの視覚レイヤーは正しい字形を使用していますが、文字とUnicodeのマッピングが壊れているか非標準です。PDFリーダーはグリフを正しく表示しますが、テキストをコピーしたりOCRエンジンが隠しテキストレイヤーを読み取ると、壊れたマップに従って文字化けが発生します。解決策は、既存のテキストレイヤーを無視して画像レイヤーを直接OCR処理することです。
文字化けしたOCRテキストをソフトウェアで自動修正できますか?
はい、エンコーディング不一致による文字化け(原因1)には、ftfy(Python)、iconv(Linux/macOS)、VS Codeなどのエディタの「エンコーディング検出」機能で自動的に特定・修正できます。フォントエンコーディングや解像度の問題は、バイトから文字へのマッピングではなくソースデータ自体に問題があるため、自動修復は信頼性が低くなります。その場合は、設定を変えて再処理するか、別の抽出方法が必要です。
高DPIにすれば文字化けOCRは必ず改善しますか?
高DPIは解像度関連の文字誤認識(原因3)を改善しますが、エンコーディング不一致(原因1)やフォントエンコーディングの問題(原因2)には効果がありません。/ToUnicodeテーブルが壊れたPDFを600 DPIでスキャンしても、同じ根本問題の高解像度版を作るだけです。再スキャンする前に根本原因を特定しましょう。
ImageToTable.aiは従来のOCRより文字化けに強いですか?
ImageToTable.aiは中間テキストレイヤーではなく、文書の視覚コンテンツを読み取る視覚言語モデルを使用するため、エンコーディング不一致とフォントエンコーディングの両方の原因による文字化けを回避します。AIがレンダリングされたページ画像を直接処理するため、カスタムCIDマッピング、サブセットフォント、/ToUnicodeテーブルの欠落の影響を受けません。解像度に関連する曖昧さについては、文書コンテキストの意味理解により、文字ベースのOCRにはない追加の補正レイヤーを提供します。ただし、元の画像自体が著しく劣化している場合(ぼやけ、極端に低解像度、一部判読不能)は、視覚AIを含むどの手法でも、そもそも取得されていない情報を復元することはできません。
文字化けOCRはランダムではない——次に取るべき対策
OCRの出力がアルファベットをでたらめに並べたように見えると、ソフトウェアのせいにして先に進みたくなるものです。しかし、ここで取り上げた3つの原因——エンコーディングの不一致、フォントエンコーディングの問題、解像度に起因する文字の混同——には、それぞれ特有の兆候と対応策があります。これらを見分ける方法を身につければ、不可解なトラブルを再現可能な診断に変えられます。
症状から始めましょう:アクセント記号周辺の複数文字の文字化け(例:é)→ エンコーディングの不一致。再エンコードまたはftfyで修正。画面上では完璧に表示されるが、OCRは無関係な字形を出力する → フォントエンコーディングの問題。画像レイヤーでのOCRを強制して修正。個々の文字が似た別の文字に置き換わる(5→S)→ 解像度の問題。前処理または文脈を考慮したツールで修正。
最後の選択肢——文字ベースのOCRからビジョンベースの抽出に切り替える——は、人間がドキュメントを読むように、ピクセルパターンの照合やエンコーディングテーブルの参照ではなく、意味を理解することで、根本原因を回避します。
文字化けしたドキュメントで実際に試してみてください。エンジンがテキストレイヤーに依存しなくなったときに問題が解消するかどうかを確認しましょう。