OCRが文字化けする理由とは？
3つの根本原因と修正方法

文字化けが発生している場合、あなただけではありません。その「文字化け」が何語なのかを特定するためだけに存在するRedditコミュニティもあります。Adobe Acrobatのコミュニティフォーラムでは、日本語OCRで「蟷ｴ莉｣繧｢繧ｸ繧｢縺ｫ縺翫¢繧九げ繝ｭ繝ｼ繝舌Ν蛹悶�」のような文字列が出力されたという未解決のスレッドが多数あります。Pythonのftfyライブラリ（文字化け修正専用ツール）は、この業界全体で繰り返し発生する問題に対処するため、何百万回もダウンロードされています。

朗報：文字化けしたOCRテキストはランダムな破損ではありません。3つの根本的なメカニズムのいずれかによって引き起こされる、予測可能なパターンに従います。パターンを特定できれば、修正は再現可能です。

原因1 — エンコーディング不一致：最も一般的な原因

症状：アクセント記号、通貨記号、スマート引用符が複数の文字化けに変わります。スペイン語のcorazónはcorazónになります。ユーロ記号€は€と表示されます。引用符「“look like this”」のようになります。文書はほぼ読めますが、ASCII以外の文字がすべて間違っています。

原因：文字エンコーディングは、ファイルとリーダーの間でバイトを文字にマッピングするための取り決めです。OCRエンジンがあるエンコーディング（例：UTF-8）でファイルを読み取る一方で、ファイルが別のエンコーディング（例：Windows-1252）で作成されている場合、同じバイトがまったく異なる文字にマッピングされます。結果は体系的な破損です。これは、インチで描かれた地図をセンチメートルとして読むようなものです。すべての測定値が同じ倍率でずれ、その誤りのパターンから、どの変換が適用されたかがわかります。

どのエンコーディング不一致かを見分ける方法

特定の文字化けパターンは非常に特徴的で、出力を見るだけでエンコーディングエラーを診断できます。

エンコーディング不一致の修正方法

方法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エンジンが読み取るもの）です。通常、これらは一致します。しかし、品質の低いPDFでは、フォントファイルにカスタムグリフエンコーディングが含まれている場合があります。グリフの形状は正しい（ページは正常に見える）ものの、マッピング先の文字コードが非標準であったり、Unicodeマッピングが完全に欠落していたりします。

この状況は驚くほど一般的です。サブセットフォント（ドキュメントで使用される文字のみを含むフォント）は、内部マッピングに非標準の文字ID（CID）を使用することがよくあります。テキスト抽出エンジンが標準のエンコーディングテーブルを使用してこれらのCIDを解釈しようとすると、文字化けが発生します。Doclingプロジェクトで報告された問題では、まさにこれが発生しました。PDFは正常に表示され、OCRはdo_ocr=Trueに設定されていましたが、出力は'() +,- .+.. /01 02034567638469:; 4<8:=>となりました。これは、フォントの内部エンコーディングが標準のUnicodeにマッピングされていなかったためです。

フォントエンコーディングによる文字化けが発生しやすいシナリオ：

• 専門ソフトウェアで生成されたPDF：CADツール（AutoCAD、Archicad）、ERPレポートジェネレーター、またはレガシーなPrint-to-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ページを高解像度（最低300 DPI）のTIFFまたはPNGファイルとしてエクスポートし、それらの画像に対して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エンジンでも毎回完璧な推測を行うことはできません。

この種のエラーは、特に以下の場合に発生しやすくなります。

• 薄暗い場所や斜めから撮影された書類のスマートフォン写真
• ファックスや繰り返しコピーされたページで、世代を重ねるごとに詳細が失われている場合
• 歴史的記録の古いマイクロフィルムスキャン
• 小さなフォントサイズ（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が文書の視覚的・意味的構造を理解してデータを抽出します。フォント依存のテキストレイヤーも、気にするべきエンコーディングテーブルもありません。

よくある質問

文字化けOCRはランダムではない——次に取るべき対策

OCRの出力がアルファベットをでたらめに並べたように見えると、ソフトウェアのせいにして先に進みたくなるものです。しかし、ここで取り上げた3つの原因——エンコーディングの不一致、フォントエンコーディングの問題、解像度に起因する文字の混同——には、それぞれ特有の兆候と対応策があります。これらを見分ける方法を身につければ、不可解なトラブルを再現可能な診断に変えられます。

症状から始めましょう：アクセント記号周辺の複数文字の文字化け（例：é）→ エンコーディングの不一致。再エンコードまたはftfyで修正。画面上では完璧に表示されるが、OCRは無関係な字形を出力する → フォントエンコーディングの問題。画像レイヤーでのOCRを強制して修正。個々の文字が似た別の文字に置き換わる（5→S）→ 解像度の問題。前処理または文脈を考慮したツールで修正。

最後の選択肢——文字ベースのOCRからビジョンベースの抽出に切り替える——は、人間がドキュメントを読むように、ピクセルパターンの照合やエンコーディングテーブルの参照ではなく、意味を理解することで、根本原因を回避します。

文字化けしたドキュメントで実際に試してみてください。エンジンがテキストレイヤーに依存しなくなったときに問題が解消するかどうかを確認しましょう。