小さなフォントがOCR精度を
損なう理由 — 4つの根本原因と対策

問題はAIではなく物理にある

OCRエンジンやビジョンAIモデルが小さな文字を認識できないと、まずソフトウェアを疑うのが普通だ。しかし、本当のボトルネックはAI処理が始まる前に存在する。それは、1文字あたりに利用可能なピクセル数によって決まる。

計算式を示す。タイポグラフィにおける「ポイント」は1/72インチである。150 DPI（dots per inch、一般的なFAXや低解像度スキャナの解像度）の場合、文字のピクセル高は次のようになる：

ピクセル高 = フォントサイズ（pt）× DPI / 72

150 DPIで6ptの文字の場合：

6 × 150 / 72 = 12.5 ピクセル

12ピクセルは、OSのターミナルウィンドウで許可される最小フォントサイズの1文字の高さにほぼ等しい。このスケールで文字内部で何が起こるかを考えてみよう。「8」と「6」を区別する特徴（上部の閉じたループと下部の閉じたループ）は、せいぜい2〜3ピクセルにしか及ばない。スキャナセンサーからの1ピクセルのノイズ、わずかなページの傾き、またはスマートフォンの写真からのJPEG圧縮ブロックによって、その区別は完全に失われる。小さいサイズでは、文字「m」と「rn」のペアは同じ2〜3ピクセルの列幅を占めるため、構造的に同一になる。

これは、より優れたAIトレーニングや高度なOCR後処理で解決できる問題ではない。入力信号には、あらゆる認識システムが正しい出力を生成するために必要な情報が欠落している。この記事で紹介する後続の修正はすべて、この制約を回避するか軽減するものだが、制約自体は不可避である。

文字に実際に必要なピクセル数

小さなフォントがいつ実用的な問題になるかを理解するには、フォントサイズとスキャン解像度をピクセル高にマッピングする。類似したグリフを確実に識別するための文字認識の臨界閾値は、おおよそ20〜25ピクセルの文字高である：

✗ = 信頼不可    ⚠ = 限界    ✓ = 印刷テキストとして一般的に信頼可能。これらは文字の高さの推定値です。認識精度はストローク幅、コントラスト、フォントデザインにも依存します。

この表からパターンは明らかです。標準的な300 DPIでは、6ptのテキストは限界ラインに位置します。多くのオフィス複合機やFAX文書の解像度である200 DPIでは、10pt未満はすべて限界または信頼不可となります。150 DPI（FAXや低品質PDFで一般的）になると、12pt以上のみが信頼可能です。

原因1：スキャン解像度が200 DPI未満

小さなフォントの抽出に失敗する最も一般的な原因は、対象テキストに対してスキャン解像度が低すぎることです。問題はスキャナハードウェア自体の性能不足ではなく、スキャンワークフローが読みやすいテキスト（約10～12ポイントの本文）向けに設計されており、脚注、表セル、法的免責事項、フォームの指示などに現れる小さな文字に合わせて調整されていないことにあります。

200 DPIが危険域である理由：200 DPIでは、多くの表セルの値やフォームラベルで一般的な8ポイントの文字の高さはわずか22ピクセルになります。「e」と「c」のような文字は、開いたカウンター（文字の内部空間）が1ピクセルに潰れるため、ほぼ区別がつかなくなります。「8」のループと「6」のボウルは同じ2ピクセルの垂直スペースを占めます。これが、FAXされた請求書やスキャンされた契約書で、本文は問題なく見える一方、小さなフォントのセクションで抽出エラーが頻発する理由です。

確認すべき点：オフィスのMFP（多機能プリンター）をデフォルトの「標準品質」モードで使用してスキャンしたPDFは、ほぼ確実に200 DPIです。FAX文書は送信元の機器に応じて100～200 DPIで届きます。抽出ツールを非難する前に、入力画像の実効DPIを確認してください。任意の画像ビューアでファイルのプロパティを開き、ピクセル幅を物理的なページ幅（インチ）で割ります。結果が250 DPI未満で、文書に10ポイント未満のテキストが含まれている場合、解像度が根本原因である可能性が高いです。

画像品質が文書タイプごとの抽出精度にどのように影響するかについては、スキャン文書のOCR精度低下に関するガイドをご覧ください。

原因2：フォントの選択が解像度の問題を増幅

すべての8ポイントの文字が同じように作られているわけではありません。フォントデザインは、利用可能なピクセル予算のうち、実際に認識に使用できる量を決定します。

小さなサイズでのサンセリフ vs セリフ。Times New Romanのようなセリフフォントは、文字のステムの端に装飾的なストローク（セリフ）を追加します。10ポイント以上では、これらのセリフは可読性を高めます。200 DPIスキャンで6～8ポイントの場合、セリフはメインストロークに溶け込み、文字を予測不能に太らせ、隣接する文字の分離を困難にします。サンセリフフォント（Arial、Helvetica、Calibri）にはこれらの余分なストロークがないため、その単純な形状は低解像度スキャンでもよりよく耐えます。Tesseract自身のドキュメントや複数のライブラリガイドラインでは、OCRに適した文書にはサンセリフフォントを特に推奨しています。

細い/ライトなフォントウェイト。現代のブランドデザイン、財務レポートのヘッダー、ミニマルなUIで人気のあるフォントファミリーの「Light」または「Thin」ウェイトは、一般的なスキャン解像度で幅がわずか1ピクセルのストロークを使用する場合があります。ストローク幅が1ピクセルだと、ノイズ、圧縮アーティファクト、スキャナセンサーのばらつきによって、ストロークが切れたり（文字が見えなくなる）、非対称に太くなったり（文字の形状が変わる）します。同じ解像度でストローク幅が2～3ピクセルのボールドおよびレギュラーウェイトは、これらのアーティファクトに対する耐性が大幅に高くなります。

曖昧なグリフを持つフォント。特定のフォントデザインは、もともとOCRにとって難しい文字をさらに困難にします。例えばArialは、小文字の「l」（エル）と大文字の「I」（アイ）を同一にレンダリングします。唯一の識別信号はコンテキストですが、従来のOCRにはそれがありません。小さなサイズでは、残っている視覚的な違い（セリフやステムの高さの数分の1ピクセル）が完全に消えるため、この曖昧さはさらに悪化します。

実践的なパターン：文書内の小さな文字に、モダンで軽量なサンセリフ体フォント（欧州の銀行取引明細書、SaaS請求書、投資レポートで一般的）が使用されている場合、太字やセリフ体のフォントならまだ読み取り可能なサイズでも、抽出エラーが発生します。フォントの選択自体が問題を引き起こすわけではありませんが、どのピクセル高さで問題が顕在化するかを決定します。

原因3：優先順位付けをせず、すべてを抽出しようとする

これは技術的な問題というより、ワークフロー設計の問題です。しかし、小さなフォントの抽出で最もよくあるフラストレーションの原因の一つです。

多くのユーザーは、ページ上のすべて（明細行、免責事項、脚注、欄外の注釈）を抽出すべきだと考えます。銀行取引明細書の下部にある6ptの法的免責事項が文字化けすると、抽出全体が失敗したように感じられます。実際には、本文や主要な財務数値は完璧に抽出されている可能性が高く、失敗は実務上必要のないテキスト部分に限定されています。

フィールド優先順位戦略：抽出前に、文書の内容を3つのカテゴリに分類します。

• 重要フィールド（10pt以上） — 請求書番号、合計金額、日付、ベンダー名、口座番号、ポリシー番号。これらはほぼ常に読みやすいフォントサイズで設定され、財務上または運用上の重要度を持ちます。高い信頼度で抽出します。
• 補足フィールド（8-10pt） — 参照コード、部門名、税額内訳、数量フィールド。通常は300 DPIで抽出可能ですが、低解像度では限界がある場合があります。スポットチェック用にフラグを付けます。
• 付随テキスト（8pt未満） — 法的免責事項、著作権表示、利用規約、ページフッター、細かい印刷の指示。構造化データのワークフローで必要になることはほとんどありません。これらのフィールドのエラーが全体的な結果への信頼を損なうくらいなら、抽出から完全に除外することを検討します。

カスタム列抽出（必要な列名を入力するとAIが意味的に値を特定する）を備えたAI抽出ツールを使用する場合、この優先順位付けはワークフローに組み込まれています。必要なデータの列のみを定義するため、AIは要求されていない文書セクションに処理能力を浪費しません。列に小さなフォント領域の値が含まれている場合、その信頼度スコアが手動レビューの自然なフラグとなります。

同じ原則はバッチ処理にも適用されます。50件のサプライヤー見積書を抽出し、細かい条件が行ごとに混在した精度で出力される場合、それらの条件が本当にスプレッドシートに必要かどうかを検討します。多くの場合、答えは「いいえ」であり、それらを削除することで抽出速度と出力の品質認識の両方が向上します。

原因4：スクリーンショットにおけるサブピクセルレンダリングによるアーティファクト

この原因は人間の目にはほとんど見えませんが、最も混乱しやすい抽出失敗を引き起こします。影響を受けるのはスクリーンショットのみですが、ドキュメント処理のかなりの部分が画面キャプチャ（ダッシュボードのエクスポート、Webポータルの請求書、モバイルアプリのスクリーンショット）から始まる現在、ほとんどの人が認識する以上に多くのワークフローに関係します。

最新のOSは、LCD画面でのテキストの鮮明さを向上させるためにサブピクセルレンダリング（WindowsのClearType、macOSのCore Text）を使用します。この技術は、各画面ピクセル内の個々の赤、緑、青のサブピクセルを制御することで、テキストレンダリングの水平解像度を実質的に3倍にします。人間の目には、画面上の小さなテキストがシャープでくっきりと見えます。しかし、スクリーンショットをフラットな画像として処理するOCRエンジンにとっては、同じテキストが文字の境界に赤や青の縁取り（色付きのフリンジ）として現れ、エッジ検出、二値化、文字セグメンテーションを混乱させます。

認識前に画像を白黒に変換するしきい値処理に依存する従来のOCRエンジンは、このアーティファクトに特に敏感です。二値化処理が赤いサブピクセルのフリンジを持つ文字エッジに遭遇すると、そのフリンジを文字の一部または別のオブジェクトとして解釈する可能性があり、いずれにせよ文字の境界が予測不能に変化します。通常のドキュメントサイズ（10～12pt）では、アーティファクトは文字に対して小さく、OCRエンジンは正しく推測できます。6～8ptでは、サブピクセルのフリンジが文字のストローク自体と同じくらいの幅になり、テキストではなく色付きのノイズを「読み取る」ような出力を生成します。

確認方法： スクリーンショットからは結果が悪いが、同じドキュメントを300 DPIでスキャンすると問題なく機能し、かつ人間の目でも画面上で読みにくいほどテキストが小さい場合、サブピクセルレンダリングが原因である可能性があります。スクリーンショットを撮る前にブラウザやアプリケーションのズームを150%にしてみてください。これにより、文字あたりのピクセル数が増え、サブピクセルのフリンジが相対的に小さくなります。

色、コントラスト、スケーリングの問題など、スクリーンショット特有の抽出課題の詳細については、色付き背景や透かしでOCR抽出が失敗する理由をご覧ください。同じ画質の原則の多くが、小さなテキストを含むスクリーンショットにも当てはまります。

実際に効果がある方法：実用的な修正優先順位

以下の修正は、効果が高く・手間が少ない順に並んでいます。上から順に試し、ワークフローに適した精度になった時点で止めてください。

修正1：小さな文字の文書は300+ DPIを目標にする

スキャン工程を管理できる場合、これが最も効果的な対策です。10pt未満の文字が含まれる文書は、標準の300 DPIではなく400〜600 DPIでスキャンしてください。ピッツバーグ大学のOCRベストプラクティスガイドでも、小さな文字の文書には400〜600 DPIが推奨されています。欠点はファイルサイズが大きくなり処理が遅くなることですが、小さな文字の精度が重要なページでは価値があります。FAXやメール添付など、解像度を制御できない文書については、ワークフローの既知の制約として記録しておいてください。すべての文書を同じ精度で抽出できるわけではなく、期待値を適切に設定すれば問題ありません。

修正2：抽出設計でフィールドの優先順位を適用する

列定義を見直し、小さな文字の付随テキストを対象とするフィールドを削除してください。6ptのフッター行にあるベンダー登録番号を実際に照合で使ったことがなければ、その列は削除しましょう。列を減らすごとに、確認不要となる低信頼度の出力が減ります。カスタム列抽出を使用する場合は、ツールの信頼度シグナルを確認してください。フィールドが一貫して低信頼度の値を返す場合、元のテキストが小さすぎてAIが推測している可能性があります。その場合は、手動確認を含めてそのフィールドを維持する価値があるか、別の方法でデータを取得できるかを判断してください。

修正3：超解像度アップスケーリング — 注意して使用

AIベースのアップスケーリング（超解像度、SR）は、150 DPIのスキャンを300 DPI相当に拡大し、既存のピクセル間に新しいピクセルを補間します。小さなフォントのテキストに対する結果はまちまちです。単純な最近傍法やバイリニア補間では新しい情報は追加されず、同じ12ピクセルを広い領域に広げるだけです。文書画像で学習したAI超解像モデル（SRGAN、ESRGAN、Real-ESRGAN）は、特に印刷された高コントラストの文字において、中程度に劣化したテキストのストロークの詳細を復元できます。しかし、すでに識別可能なピクセル特徴が不足している小さなフォントのテキストでは、SRは元々キャプチャされなかった特徴を発明できません。視覚的に滑らかな出力を生成するかもしれませんが、文字レベルの精度は実際には向上しません。SRの最も信頼できる使用例は、抽出ツールに渡す前に、すでに限界解像度のスキャン（例：200 DPIから400 DPI）のテキストを拡大することです。FAXレベルの解像度でキャプチャされたテキストをSRが救うとは期待しないでください。

アップスケーリング、二値化、傾き補正など、抽出前の前処理技術については、OCR画像前処理ガイドをご覧ください。

修正4：可能な場合はより良いソース文書を再リクエスト

多くの業務ワークフロー、特に買掛金管理、契約管理、税務文書処理では、より良いソースをリクエストするオプションがあります。ベンダーが150 DPIのFAXで請求書を送り、7ptの明細説明が一貫して読めない場合、ベンダーにデジタルPDFをメールで送ってもらうよう依頼してください。下請け業者がコピーのコピーである署名済みフォームを提出した場合、原本または鮮明な写真を依頼してください。この修正は常に利用できるわけではありません（一部のレガシーベンダーはFAXのみ、一部の政府フォームは固定印刷形式のみ）が、チームが想定するよりも頻繁に利用可能です。1回のメールリクエストのコストは、バッチ全体で50件の抽出エラーを手動修正するコストよりも低くなります。

正直な限界：7pt未満はどのシステムでも信頼できない

精度向上、ワークフロー調整、ツールのアップグレードのいずれも、200 DPIスキャンから6ptのテキストを確実に抽出できるようにはなりません。単純にピクセル予算が足りません。7pt未満の印刷テキストの認識精度は、従来のOCRでも最新のビジョン言語モデルでも、文字レベルで約60〜80%で頭打ちとなり、20〜40%の文字が誤読されます。請求書の6ptの数字を99%のフィールド精度で抽出することは不可能であり、責任ある対応は、デジタル化の物理的制約がサポートできない入力を中心にワークフローを最適化する時間を費やすのではなく、手動確認または省略を計画することです。

この限界は、現在運用中のすべてのシステムに当てはまります。Tesseractだけでなく、レガシーOCRだけでなく、Google Cloud Vision、Amazon Textract、ビジョン言語モデルベースのツールにも同様に当てはまります。小さなフォントのテキストに対するこれらのツールの違いは、桁違いではなく、数パーセントポイントの差です。ビジョンAIモデルは、周囲のコンテキストを使用して欠落した文字を推測するため、7pt未満のテキストで有利です。AIが見慣れた請求書ヘッダーの中に「Inv_ice N_mber」を認識すれば、正しい値を推測できます。しかし、このコンテキストに基づく推測には限界があります。特定のピクセルしきい値を下回る文字が真に曖昧な場合、推論はせいぜい経験に基づく推測に過ぎません。

さまざまな文書タイプと条件における精度の期待値の詳細については、OCR精度向上のための実践ガイドをご覧ください。

よくある質問