OCR 技術詳解：コンピュータはどのように画像から文字を読むのか

任意の画像をバイナリエディタで開いてみよう。道路標識の写真、レシート、PDF のスクリーンショット。オフセットゼロにはフォーマットヘッダーがある。数キロバイト進むとピクセルデータに到達する。RGB では 1 ピクセルあたり 3 バイト、数値のグリッドであり、(128, 52, 19) はレンガの壁、(240, 238, 220) は紙かもしれない。そのグリッドのどこかに、赤地に白の Highway Gothic で「STOP」と描かれた一時停止標識がある。人間には 4 つの文字が見える。コンピュータが見るのは、R チャンネルが 200 近辺で G と B が 40 を下回る、47 × 19 の赤みがかったピクセル領域だ。この領域を文字列「STOP」に対応付けること、それが光学文字認識（Optical Character Recognition、OCR）であり、Gustav Tauschek が 1929 年に最初の読み取り機の特許を取得して以来、未解決の研究課題であり続けている。

OCR が難しいのは、読むことがあまりに簡単だからだ。6 歳の子供は、何十ものフォント、様々なサイズ、不均一な照明、わずかな回転、部分的な遮蔽、鉛筆書きの中から文字 A を認識できる。コンピュータに必要なのはパイプラインだ。画像をきれいにし、テキスト領域を見つけ、文字またはグリフ列を分割し、それぞれを分類する。各段階には失敗モードがあり、その失敗は累積する。

OCR が難しい理由

中核的な問題は分類ではない。あらかじめ分割された 28 × 28 の文字画像を 62 クラス（A–Z、a–z、0–9）に分類するのは、1990 年代の LeNet で 99% の精度を達成できるタスクだ。難しいのは、分類器に至るまでのすべての工程である。

フォントの多様性。 文字「g」には少なくとも 4 つの一般的な構造変種がある。単階式（手書き）、二階式（ほとんどのセリフ体）、Helvetica に見られるループテール式、Futura のオープンテール式だ。Tahoma で訓練したモデルは Univers を測定可能な割合で誤読する。実世界の OCR は数百の書体に加えて手書きを扱うが、手書きには一貫した筆画トポロジーがまったく存在しない。

幾何学的歪み。 書類の写真がフラットベッドスキャンのように撮れることは稀だ。スマートフォンで撮ったレシートには、遠近による傾き、湾曲、不均一な縮尺が入り込む。本の背に近い部分の文字は曲がる。ホワイトボードの写真には撮影者の影が映り込む。10 度の傾きで Tesseract の精度は約 97% から 85% 未満に低下する（標準ベンチマーク）。傾き補正アルゴリズム（Hough 変換による直線検出、Radon 変換、投影プロファイル分析）はその損失の一部を回復するが、すべてではない。

照明とノイズ。 不均一な照明は均一な背景をグラデーションに変え、グローバルしきい値処理を破綻させる。JPEG 圧縮アーティファクトは鋭いエッジの周囲にリンギングを発生させる。OCR の文脈では、それは文字の筆画周辺のリンギングを意味する。低照度センサーからのごま塩ノイズは、空白領域を句読点のように見える暗いピクセルで埋め尽くす。コピーのコピーは細い筆画を互いに融合させ、「rn」を「m」に、「cl」を「d」に変えてしまう。

レイアウトの複雑さ。 文書には段組み、キャプション、表、ヘッダー、脚注、サイドバーがある。テキストは画像の周りを回り込む。ある言語は右から左へ書かれる。別の言語は同じ段落内で方向が混在する。読み順（どのテキストブロックがどの次に来るか）の特定は認識とは別個のレイアウト解析問題であり、これを間違えると、すべての文字が正しく分類されていても出力は崩壊する。

文脈の曖昧さ。 ピクセルパターンだけでは、「0」（数字のゼロ）、「O」（大文字の O）、「o」（小文字の o）は多くのサンセリフ体で同一である。「1」、「l」、「I」、「|」は一本の縦線を共有する。解像度は別の次元を加える。ピクセル高 12 では、「e」と「c」の違いはわずか 3 ピクセル幅の横線 1 本分だ。人間の読み手はこれを文脈から解決する。機械が同じ判断をするには、統計的または学習による言語モデルが必要である。

従来型 OCR パイプライン

深層学習以前の OCR は、手設計された一連の段階から成っていた。各段階は異なる研究グループによって独立に開発され、特定の劣化要因に対して調整された。そのパイプラインは次のようなものだった。

生画像 → 前処理 → 二値化 → 傾き補正 → レイアウト解析
  → 文字分割 → 特徴抽出 → 分類 → 後処理（言語モデル） → テキスト出力

前処理と二値化

カラー画像はグレースケールに変換される。ノイズ低減はしきい値処理の前に信号を平滑化する。メディアンフィルタはごま塩ノイズを処理する。ガウシアンブラーはセンサーノイズを処理する。バイラテラルフィルタはエッジ保存が重要な場合に使用される。

二値化はグレースケール画像を白背景に黒文字へと変換する。標準アルゴリズムは大津の手法（Otsu's method、1979 年）である。前景と背景のピクセル分布のクラス内分散を最小化するしきい値を網羅的に探索する。大津の手法は二峰性ヒストグラム（テキストピクセルがある強度に、背景ピクセルが別の強度に集中する）を仮定しており、制御された照明下のフラットベッドスキャンでは機能するが、影のあるスマートフォン写真では失敗する。局所適応手法（Sauvola、Niblack）は、近傍統計量に基づいてピクセルごとに異なるしきい値を計算し、不均一な照明を処理するが、エッジ付近にアーティファクトが生じる代償を伴う。

傾き補正とレイアウト解析

文書の傾きは、エッジピクセルに対する Hough 変換、または投影プロファイル分析（文書を角度範囲にわたって回転させ、水平投影のピークが最も鋭くなる角度を選択する）によって検出される。傾き角度が分かれば、アフィン変換で画像を回転して戻す。

レイアウト解析はページをテキストブロックに分割する。古典的アプローチは連結成分分析（CCA）を実行して前景ピクセルの塊を見つけ、近接度に基づいて単語にグループ化し、単語を行に、行をブロックにグループ化する。XY-cut アルゴリズムは、水平および垂直投影に沿った空白ギャップを見つけることでページを再帰的に分割し、領域の木を構築する。現代の実装はハイブリッド方式を用いる。初期の塊検出には CCA を使い、その後、学習モデルで各塊をテキスト、画像、表、または区切り線に分類する。

文字分割

機械印刷テキストの場合、分割とは単語画像を個々の文字に切り分けることを意味する。垂直投影プロファイル（列ごとの前景ピクセル数のヒストグラム）は、文字の中心でピークを、文字の境界で谷を生成する。これは二つの文字が接触している場合や、一つの文字が不連続な部分（「i」、「j」、「:」、「%」）を含む場合に破綻する。過分割（攻めすぎた分割）の後に分類器の信頼度に基づいて統合するのが一つの修正策だ。別の方法は分割を完全にスキップして単語全体を認識することであり、これが現代の系列ベースの手法のやり方である。

特徴抽出と分類

文字画像を手に入れたら、分類器のために数値的に記述する必要がある。深層学習以前の特徴には以下のものがあった。

• 生ピクセル値を平坦化ベクトルとして使用（シンプルだが、平行移動と縮尺に脆弱）
• ゾーニング（Zoning）：文字バウンディングボックスを N × N グリッドに分割し、セルごとの前景ピクセル数をカウントし、そのカウントを特徴として使用
• 勾配ベース特徴（HOG）：方向勾配ヒストグラムはエッジ方向を捉え、小さな平行移動に対してロバスト
• スケール不変特徴変換（SIFT）：スケール、回転、照明に不変なキーポイントを検出・記述

分類器は通常、RBF カーネルを持つサポートベクターマシン（SVM）で、フォントごとに数万のラベル付き文字画像で訓練された。適切に調整された SVM + HOG パイプラインは、クリーンな印刷テキストで約 98% の文字単位精度を達成できた。同じパイプラインにノイズ、傾き、手書きの入力を与えると、精度は 70–80% に低下した。

Tesseract：HP Labs から LSTM へ

Tesseract は代表的なオープンソース OCR エンジンである。1980 年代に HP Labs Bristol での博士研究プロジェクトとして始まり、2005 年にオープンソース化され、2006 年以降 Google によってメンテナンスされている。そのアーキテクチャは二つの時代に明確に分かれる。

バージョン 3：古典的パイプライン

Tesseract 3 は従来型パイプラインをいくつかの革新とともに実装した。そのレイアウト解析は、単語バウンディングボックスを整列させてカラム境界を見つけるタブストップ検出アルゴリズムを用いた。HP が 1990 年代にスキャンしていた種類の文書向けに調整された実用的ヒューリスティックである。文字分割にはチョッパー/アソシエータ（chopper/associator）ロジックを用いた。チョッパーは単語画像を過剰に候補カットへと分割し、アソシエータは分類器の信頼度と辞書を使ってどのカットを統合するかを決定した。

分類器は 2 パス方式だった。第 1 パス（静的分類器）は、分割された塊をプロトタイプ（クラスタリングされた訓練サンプル）と最近傍探索で照合した。第 2 パス（適応分類器）は文書自体に対してファインチューニングを行い、その画像で使用されている特定のフォントを学習した。適応分類器が有効になるには約 1 ページ分のテキストが必要で、これが Tesseract 3 が道路標識やキャプションのような単一単語画像で性能が悪かった理由である。

Tesseract 3 は .traineddata ファイルを同梱した。これはプロトタイプクラスタ、文字セット定義、単語頻度辞書、混同しやすい文字ペアをマッピングする unichar 曖昧性テーブルを含むアーカイブである。新しい言語の訓練には、正解転写とペアになったテキスト画像を Tesseract に与え、各文字を囲み枠で指定し、訓練ツールを実行する必要があった。言語あたり数時間のプロセスである。

バージョン 4/5：LSTM がパイプラインを置き換える

Tesseract 4（2018 年）は、認識パス全体を単一の LSTM ニューラルネットワークに置き換えた。LSTM はテキストライン画像の垂直スライス列に対して動作する。各スライスは幅 1 ピクセル、高さはテキストライン全体の高さである。各スライスはスタックされた双方向 LSTM 層に入力される。出力は文字確率の系列であり、Connectionist Temporal Classification（CTC）損失を用いて、可変長の出力系列を事前分割された文字位置なしに正解テキストにアラインメントする。

LSTM モデルは、チョッパー/アソシエータ機構なしに、可変幅文字、接触文字、フォント多様性を処理する。テキストラインの発見には依然として Tesseract の従来型レイアウト解析に依存しているが、ライン認識はエンドツーエンドのニューラルネットワークである。ICDAR 2017 ベンチマークにおいて、Tesseract 4 は印刷英語で 4.4% の文字誤り率（CER）を達成し、Tesseract 3 の 7.2% から改善した。訓練プロセスも、従来の文字囲みツールから、テキストラインと転写テキストのペアリングに切り替わった。依然として教師あり学習だが、文字ごとではなく行ごとに 1 つのラベルで済む。

.traineddata 形式は拡張され、LSTM モデルの重み（数 MB）を従来データ（辞書、unichar テーブル）とともに単一ファイルに保持するようになった。高速 LSTM モデルをゼロから訓練するには、約 100 文字クラスのラテン文字言語で最新 GPU を用いて約 24 時間かかる。CJK 言語はより大きな文字セットのため、より長い時間を要する。

精度の特性

Tesseract 5 はバージョン 4 を改良し、より大規模な訓練コーパスとより良いデフォルトパラメータを備えるが、アーキテクチャは変わっていない。精度は入力に大きく依存する。

LSTM モデルはバージョン 3 のフォント感度問題のほとんどを取り除いたが、エンジンは依然として以下の条件で劣化する。低解像度（200 DPI 未満では、LSTM のピクセルスライス入力が筆画の詳細を失う）、手書きテキスト（モデルは印刷フォントで訓練されており、手書きは根本的に異なる筆画統計を持つ）、複雑なレイアウト（レイアウト解析は依然として従来コードパスであり、ニューラルネットワークではない）。

現代の深層学習アプローチ

学術的には、OCR は 2019 年頃に CTC + LSTM パラダイムを越えた。現在、文献では三つのアーキテクチャが支配的である。

CRNN + CTC

畳み込み再帰型ニューラルネットワーク（CRNN）は、Shi らによって 2015 年に発表された。CNN 特徴抽出器と RNN 系列モデル、CTC デコーディングを組み合わせる。CNN は画像から空間特徴を抽出し、本質的には Tesseract で LSTM が手動で与えられていたもの（垂直スライス表現）を学習する。RNN は抽出された特徴間の系列依存性をモデル化する。CTC がアラインメントを処理する。CRNN-CTC は標準ベースラインとなった。エンドツーエンドで訓練可能、良好な汎化性能、高速推論（GPU で 1 行あたり約 20 ms）。

注意機構ベースのエンコーダ-デコーダ

注意機構ベースのモデルは、機械翻訳から seq2seq パラダイムを適応させた。CNN またはビジョンエンコーダが画像の特徴マップを生成する。RNN デコーダが出力テキストを 1 文字ずつ生成し、各ステップで特徴マップの関連する空間領域に注意を向ける。注意機構は CTC の単調制約を取り除く。デコーダは、言語モデルが繰り返しパターンを期待する場合に画像のより前の部分にジャンプして戻ることができる。ただし、この柔軟性は判読不能な入力に対する幻覚のリスクも導入する。注意機構ベースのデコーダは、クリーンな印刷英語で約 1.5–3% の CER を達成し、長い系列や不規則なレイアウトにおいて CTC のみのモデルを上回る。

Vision Transformer（TrOCR、Donut）

TrOCR（Microsoft、2021 年）は Transformer アーキテクチャを OCR に適用した。画像はパッチに分割され、ViT（Vision Transformer）エンコーダによってエンコードされ、テキストは Transformer テキストデコーダによって自己回帰的にデコードされる。これは標準的なマルチモーダルモデルのアーキテクチャであり、OCR 専用に訓練されている。TrOCR は、CNN 前処理、明示的言語モデル、文字レベル分割なしに、印刷テキストで最先端の結果（クリーンなスキャンで 1% 未満の CER）を達成する。

Donut（NAVER、2022 年）はこのアプローチを文書理解に拡張した。入力は文書画像全体であり、出力は視覚特徴から直接抽出された構造化 JSON である。OCR → NLP パイプラインを完全にスキップする。これは実際のアプリケーションにとって重要な形で OCR と文書解析の境界を曖昧にする。請求書の合計金額、パスポート番号、研究論文からの表の抽出が、OCR + 正規表現 + ヒューリスティクスではなく、単一のモデル呼び出しになる。

性能比較（印刷英語、クリーンな 300 DPI）

ベンチマークにおいて、Tesseract と最高の Transformer モデルとの差は実在する。実務では、ほとんどのデプロイされたシステムが Tesseract にクリーンで明るく、300 DPI の入力を与えるため、その差は縮まる。その入力では、1.8% の CER は 55 文字に 1 つの誤りを意味する。検索インデックス用途では許容範囲だが、法的文書の転写としては十分ではない。

非英語 OCR：なぜより難しいのか

英語 OCR は解決済みの問題である。大文字 26、小文字 26、数字 10、わずかな句読点で、約 70 クラス。1990 年代の LeNet の能力に十分収まる多クラス分類問題だ。世界の他の文字体系はそう寛容ではない。

CJK：文字セットの爆発

中国語、日本語、韓国語（CJK）は、文字セットの規模だけでも OCR 最大の挑戦である。簡体字中国語は約 3,500 の常用文字、一般テキストでは 6,000 以上を使用する。繁体字中国語はさらに千以上の異体字を加える。日本語は二つの音節文字（ひらがな、カタカナ：各 46 文字）に約 2,000 の常用漢字、さらにラテン文字数字を同一文内で混在させる。韓国語のハングルは音韻的に規則的（24 の基本字母が音節ブロックに結合する）だが、視覚的には密集している。単一ブロックに最大 6 つの個別 jamo コンポーネントを含み、ラテン文字 2 文字分程度のスペースに詰め込まれる。

CJK OCR システムは認識を 70 クラス分類として扱うことはできない。日本語で最低 4,000 クラス、簡体字中国語で 6,000 クラス、繁体字中国語で 10,000 クラス以上の分類である。softmax 出力層だけでラテン文字 OCR モデル全体を超えるパラメータ数を持つ。訓練データの必要量は文字セットの規模に比例する。許容可能な精度を得るにはクラスあたり約 100 のラベル付きサンプルが必要で、中国語の訓練セットは 60 万テキスト行画像からスタートする。

Tesseract は CJK の traineddata ファイル（chi_sim、chi_tra、jpn、kor）を提供しているが、ラテンモデルよりも著しく大きい。chi_sim.traineddata は約 50 MB であるのに対し、eng.traineddata は約 15 MB であり、出力空間が大きいため認識も遅い。Tesseract 5 でのクリーンな印刷 CJK テキストの精度は 2–5% CER で、同等条件での英語の誤り率の約 2–3 倍である。

アラビア語と右から左への文字体系

アラビア語は文字セット（単語内の位置に応じて文脈的形状が変わる 28 文字）に加えて、二つの問題を追加する。第一に、右から左に書かれるため、OCR エンジンはテキスト方向を検出し出力順序を逆転させなければならない。第二に、アラビア語は筆記体である。単語内の文字はベースラインの筆画で接続されるため、分割はラテン文字やキリル文字のような主に分離した字形よりも本質的に難しい。アラビア語の単語画像は一つの連続した塊である。文字ベースの分割は事実上不可能であり、これが LSTM/CTC アプローチ（文字分割なしに単語画像上で動作する）が英語 OCR よりもアラビア語 OCR にとって大きなブレークスルーだった理由である。

ヘブライ語、ウルドゥー語、ペルシア語、パシュトー語は、これらの課題の組み合わせの一部を共有する。Tesseract はアラビア語の traineddata を提供しているが、クリーンな印刷テキストでの精度は約 5–8% CER で、同等条件での英語の約 4 倍悪い。

インド系文字：結合文字の問題

デーヴァナーガリー文字（ヒンディー語、マラーティー語、ネパール語）およびその他のブラーフミー系文字は、独特の課題を示す。書字単位は文字ではなく結合文字（conjunct）——子音、母音修飾記号、場合によってはさらに子音が視覚的に融合した塊である。Unicode デーヴァナーガリーブロックには 128 のコードポイントがあるが、可能な結合文字の数は 1,000 を超える。「シローレーカー」（単語内の文字をつなぐ水平の頭線）は、頭線が隣接文字を一つの視覚単位に統合するため、分割をより困難にする。

Tesseract のヒンディー語 traineddata（hin）は一般的な結合文字をカバーしているが、印刷テキストでの精度は英語より 3–4 倍劣る。タミル語、テルグ語、ベンガル語、その他のインドの文字はサポートがより乏しく、公式の traineddata ファイルがまったく存在しないものもある。根本原因は訓練データの量である。ヒンディー語には数百万の高品質なラベル付きテキスト行画像が存在するが、カンナダ語で利用可能なデータセットは数万の規模である。

縦書きテキストと混在方向レイアウト

日本語と繁体字中国語は時に縦書きに組まれ、行は上から下へ、列は右から左へ進む。Tesseract のレイアウト解析はテキストが水平であることを前提としており、縦書きテキストには事前の回転か別エンジンが必要である。同一ページに水平テキストと縦書きテキストが混在する場合（日本の新聞やマンガで一般的）、単一方向の前提は完全に破綻し、認識前に領域レベルの方向検出が必要となる。

小言語と訓練データ

話者数 1,000 万人未満の言語にとって、高品質な OCR 訓練データはほぼ存在しない。Unicode コンソーシアムは 150 以上の文字体系をエンコードしているが、Tesseract が traineddata を提供するのは約 120 言語であり、その多くは標準フォントでクリーンな背景にレンダリングされた合成テキストから生成されている。合成データは一般的なフォントでの印刷テキストには機能するが、それらの言語の実際の文書に見られるフォント、紙質、印刷品質には対応できない。300 DPI で合成 Arial を使って訓練されたモデルは、1970 年代のタイプ打ちアムハラ語文書を読み取れない。

ブラウザサイド OCR：Tesseract.js

WebAssembly が登場する以前は、ブラウザ内で OCR を実行することは非現実的だった。Tesseract.js は Tesseract 5（LSTM）を Emscripten 経由で WebAssembly にコンパイルし、認識タスクごとに Web Worker を実行する JavaScript API で C++ エンジンをラップする。エンジン、言語データ、Worker は静的アセットから読み込まれる。画像データのサーバーラウンドトリップは不要である。

API の表面は簡潔だ。一つ以上の言語コードで Worker を作成し、画像を与え、認識されたテキストを文字ごとの信頼度スコア付きで受け取る。複数の Worker を並列実行でき、利用可能な CPU コア数が上限となる。通常、一般消費者向けノート PC では 4 つ、最新のスマートフォンでは 6 から 8 つの並列認識ジョブが可能だ。

パフォーマンスは三つの要因によって制限される。第一に、WebAssembly はネイティブの約 50–70% の速度で動作する。ネイティブ Tesseract で 100 ms かかるテキスト行は、ブラウザでは約 160 ms かかる。第二に、traineddata ファイルはネットワーク経由で読み込まれる。eng.traineddata は約 15 MB、chi_sim.traineddata は約 50 MB であり、いずれも認識開始前に完全にダウンロードされなければならない。第三に、画像デコード（JPEG/PNG/WebP/HEIC から生ピクセルデータへ）はブラウザの内蔵デコーダを使用する。これらは高速だが、フォーマットとデバイスによって異なる。

プライバシーの利点は構造的なものだ。クライアントサイド OCR は、画像がデバイスから決して出ないことを意味する。パスポートの写真、銀行取引明細書、医療記録。ピクセルはブラウザでデコードされ、Textract 相当の処理が Web Worker 内で実行され、結果はユーザーがコピーまたは保存できるテキスト文字列となる。データセンターがその画像を処理することはない。これは機能ではなく、サーバーが存在しないことそれ自体であり、「見ない」と約束するプライバシーポリシーとは質的に異なる。

当社の Image to Text ツールはまさにこのスタックで動作する。LSTM 認識付きの Tesseract.js、並列処理用の Web Worker、12 言語の traineddata（英語、スペイン語、フランス語、ドイツ語、ポルトガル語、イタリア語、簡体字および繁体字中国語、日本語、韓国語、ヒンディー語、ロシア語）。写真をドロップして言語を選べば、テキストが得られる。このツールは JPEG、PNG、WebP、BMP、GIF の入力に対応し、解像度を考慮したプレリスケーリング（長辺が 3,000 ピクセルを超える画像は認識遅延を妥当に保つため縮小される）を適用し、画像ごとにプレーンテキストを文字ごとの信頼度付きで出力する。

画像フォーマットの選択は、実務上 OCR 品質に影響する。iPhone の HEIC 写真を OCR 前に JPEG に変換すると、テキストエッジ周辺に圧縮アーティファクトが生じ、認識精度を低下させる。HEIC を先に PNG に変換すれば（ロスレス、量子化アーティファクトなし）、LSTM が依存するシャープなエッジが保持される。当社の HEIC to JPG および HEIC to PNG コンバータは、この前処理段階をブラウザ内で直接処理する。同様に、低照度で撮影された写真は、しきい値処理の前に全階調範囲を保持するフォーマットに変換することで恩恵を受ける。JPG to PNG は、JPEG ソースが再エンコードされる際に蓄積する第 2 世代 JPEG アーティファクトを回避する。

ブラウザ OCR スタックは、スループットにおいて GPU アクセラレーション付きサーバーサイドモデルと競合できない。32 CPU コア上でネイティブ C++ の Tesseract を実行するサーバーは、ブラウザタブを常に上回る。プライバシー、ゼロインフラストラクチャ、リクエストあたりゼロコストにおいて勝るのだ。数ページ、レシート 1 枚、標識数点をスキャンする場合、200 ms と 50 ms の遅延差は知覚できない。

OCR のゆくえ

OCR は 2022 年頃に独立した研究分野でなくなり、より広範なドキュメント AI およびマルチモーダルモデルの空間に融合した。三つのシフトが進行中である。

マルチモーダル LLM によるゼロショット OCR。 GPT-4V、Claude、Gemini は、明示的な OCR 訓練なしに画像からテキストを読み取ることができる。文書の写真を与えてテキストを求めれば、モデルはそれを返す。専用の OCR ヘッドがあるからではなく、数十億の画像-テキストペアでの訓練から文字認識能力が創発するからだ。品質は均一ではない。クリーンな印刷英語では、GPT-4V は約 1% CER を達成し、ファインチューニングされた TrOCR と同等である。中国語レシートの低解像度スマートフォン写真では、モデルが文脈（レシートがどのように見えるか、どんな数字が期待されるかを知っている）を活用し、ピクセルレベルの証拠のみに依存しないため、Tesseract を上回ることができる。手書きでは、訓練分布に十分な手書き画像が含まれていなかったため、ファインチューニングされた認識器よりも劣る。

トレードオフはコストと遅延である。OCR のための GPT-4V への API 呼び出しは、トークン数に応じて 1 ページあたり 1–3 セントかかり、1–3 秒を要する。Tesseract はローカルで 1 ページあたり 100–500 ms で動作し、コストはゼロである。200 ページの文書をスキャンする場合、その差は 2–6 ドルと数分の実時間に対して、ゼロと 1 分未満である。単発の利用（レシート 1 枚、ホワイトボード写真 1 枚）であれば、マルチモーダルモデルの方がシンプルで、多くの場合はより正確である。

オンデバイス推論。 サーバー OCR を支えるモデルは縮小している。ONNX Runtime Web は、量子化された CRNN と小規模 ViT モデルを WebGPU 使用時に 1 テキスト行あたり 50–100 ms でブラウザ内実行する。Apple の Vision フレームワークは、iOS および macOS 上にコンパクトな OCR モデルをオンデバイスで搭載しており、VNRecognizeTextRequest を通じてネットワーク呼び出しなしにアクセスできる。「サーバー GPU モデル」と「ブラウザモデル」のギャップは縮まりつつある。両者が同じアーキテクチャのスイートスポットに収束しているからだ。小規模 ViT エンコーダ（約 2,000 万–5,000 万パラメータ）に軽量デコーダを組み合わせ、INT8 または FP16 に量子化したものだ。

転写ではなく文書理解。 OCR の出力は文字列である。ほとんどの実世界のタスクは、その文字列から構造化情報を抽出することを含む。請求書番号、日付、合計金額、氏名、住所。従来のアプローチは、OCR を正規表現、固有表現認識、スキーママッピングとチェーンする。各段階は独自の失敗モードを持つ別個のモデルである。エンドツーエンド文書理解モデル（Donut、LayoutLMv3、Pix2Struct）は OCR をスキップし、文書画像を直接構造化出力にマッピングする。レシートでファインチューニングされた Donut モデルは、テキスト転写を生成してそれを解析したりしない。ピクセル入力から直接 {"total": "42.50", "date": "2026-07-27", "vendor": "..."} を生成する。OCR の工程、この記事が扱ってきた部分は、不可視の実装詳細となる。

これは OCR を陳腐化させるわけではない。構成要素にするのだ。パイプラインは依然としてエッジケースを処理しなければならない。暗いレストランで斜めに撮影されたレシート、黄ばんだ紙に 50 年前にタイプ打ちされた文書、大規模マルチモーダルモデルが訓練されていない言語の標識。それらの特定の分布に対して訓練された専用 OCR エンジンは、今後何年にもわたって汎用モデルを速度と性能で上回り続ける。なぜなら、インターネット全体で訓練された汎用モデルは、その容量のごくわずかな部分しか 1970 年代のアムハラ語タイプライター出力の読み取りに割り当てていないからだ。

OCR は、世界のほとんどの言語とほとんどの実世界の撮像条件にとって、解決済みの問題ではない。クリーンで 300 DPI、英語、単一カラム、機械印刷テキスト——問題空間の最も狭く、最も資金の集まった部分においてのみ解決済みである。残りは、いまだ開かれている。