Tesseractとは？読み方・日本語の精度・商用利用とPSM/OEM設定【5.5.3で実測】

Tesseract（テッセラクト）は、画像の文字をテキストに変えるオープンソースのOCRエンジンです。Apache License 2.0で配布され、無料で商用製品にも組み込めます。処理は手元のマシンで完結するため、画像を外部に送れない業務で選ばれてきました。

日本語の認識精度を調べる際は、学習データと入力画像の条件を確認します。今回の合成画像の検証でも、両者によって誤り率が変わりました。本記事では読み方・ライセンス・現行版を整理したうえで、5.5.3を実際に動かし、学習データ3系統・解像度・傾き・照明ムラ・PSM・whitelistの効き方を測った結果を示します。インストール手順とコマンドの基本はTesseract OCRの使い方｜インストール・日本語設定・コマンドとPython/C#連携【5.5.3対応】にまとめています。

まとめ：Tesseractの要点（5.5.3時点）

• 読み方は「テッセラクト」。HPが1985〜1994年に開発し、2005年にオープンソース化。現行版は2026年7月24日公開の5.5.3。
• 本体と公式の学習データ3リポジトリはいずれもApache License 2.0。無料で商用利用でき、ソース公開義務はないが、配布時のライセンス同梱と著作権表示は必要。
• 日本語は tessdata_best か tessdata_fast から評価する。標準の tessdata のjpnは、実測で半角数字25字中19〜20字を「②」のような丸数字で返した。
• 精度を最も左右したのは画像側。100dpiまではbestで誤り率1.6%に収まったが、傾き10度では出力が空になった。照明ムラには thresholding_method=2（Sauvola）が効いた。
• tessedit_char_whitelist は4.1.0以降LSTMでも効く。ただしbestのjpnは同じフォルダのjpn_vertを副言語として読み込み、その状態では出力が空になった。
• 手書き・崩れた画像・複雑なレイアウトは設定で粘らず、VLM系やクラウドのOCRへ回す。

Tesseractの読み方・開発の経緯・現行版

読み方は「テッセラクト」、語源は4次元の超立方体

英語の発音に近い表記は「テッセラクト」です。日本語の記事には「テセラクト」「テッサラクト」もありますが、同じソフトウェアを指します。tesseractは数学で4次元の超立方体（正八胞体）を表す語で、OCRの機能とは関係ありません。映画やゲームの「テッセラクト」が検索に混ざるのはこのためです。

HPで生まれ、Googleを経てコミュニティが開発を継続

公式リポジトリのREADMEによると、TesseractはHP研究所（英ブリストル）とHP（米コロラド州グリーリー）で1985〜1994年に開発され、2005年にHPがオープンソース化しました。2006年から2017年8月まではGoogleが開発し、その後はGitHubのtesseract-ocrプロジェクトで開発が続いています。メジャーバージョン5は2021年11月30日の5.0.0から始まりました。

公式の入口はGitHubのリポジトリと、ドキュメントサイト（tesseract-ocr.github.io/tessdoc）です。検索上位に出る「tesseractocr.org」は、本文に「公式の Tesseract OCR プロジェクトやそのメンテナーとは提携・承認・関係ありません」と書かれた独立サイトなので、版や仕様の確認には使わないでください。

現行版5.5.3とOS別パッケージの収録版

5.5.3は2026年7月24日公開の不具合修正リリースです。手元の版は tesseract --version で確かめます。検証に使ったHomebrew版では次のように出ました。

$ tesseract --version
tesseract 5.5.3
 leptonica-1.87.0
  libgif 5.2.2 : libjpeg 8d (libjpeg-turbo 3.1.3) : libpng 1.6.58 : libtiff 4.7.2 : zlib 1.2.12 : libwebp 1.6.0 : libopenjp2 2.5.4
 Found AVX2

Linuxのパッケージは公式の最新に追いついていないことがあります。

Ubuntu 24.04の tesseract-ocr-jpn を展開すると、中の jpn.traineddata は tessdata_fast のファイルとバイト単位で一致しました。Homebrewのtesseract-langもtessdata_fastの4.1.0タグを取得します。つまりパッケージで入れた日本語データは、多くの場合fast系です。

商用利用とライセンス：Apache License 2.0の条件

本体のLICENSEはApache License 2.0で、学習データの tessdata・tessdata_best・tessdata_fast も同じApache License 2.0です。利用料はかからず、組み込んだ自社アプリのソースを公開する義務もありません。

配布時はライセンス本文の写しを添え、改変ファイルには変更を明記します。派生物をソース形式で配布する場合は関連する著作権・特許・商標・帰属表示を保持し、元の配布物にNOTICEがある場合は、その関連する帰属表示も引き継ぎます。Tesseract本体のリポジトリにNOTICEファイルはありません（2026年10月時点）。特許の許諾も含みますが、対象ソフトウェアまたはその貢献部分が特許を侵害すると主張して訴訟を起こした場合、そのソフトウェアについて本ライセンスが与える特許許諾は終了します。社内の法務確認では「Apache 2.0の条件の下で無償」と伝えるのが正確です。画像処理に使うLeptonicaは別のライセンス（BSD系）なので、製品に同梱するならこちらの表示も確認します。

認識エンジンとOEM：LSTMとlegacyの使い分け

OEMの4つの値と、legacyが動く学習データ

4.0でLSTM（ニューラルネットワーク）による行単位の認識器が入り、5系ではこれが中心です。3系までの形状パターン照合（legacy）もコードには残っていますが、動かせる学習データが限られます。

fastとbestのjpnで --oem 0 を指定すると、5.5.3ではError: Tesseract (legacy) engine requested, but components are not present in …jpn.traineddata!!で止まりました。tessdataのjpnならlegacyで動きますが、実測では誤り率5.9%で、金額・日付・管理番号の3欄はどれも正しく読めませんでした。

認識エンジンを固定する --oem 1 の指定

既定の3は学習データとビルドで利用可能な構成を選び、両エンジンを利用できる場合は併用を選択します。学習データを差し替えると認識器が変わる可能性があるため、バッチ処理で結果を再現したいなら --oem 1 を固定します。

日本語の学習データ3系統を5.5.3で実測比較

合成した日本語契約書の測定条件と評価指標

Pillowで描いた契約書風の9行（187字・半角数字25字）を、ヒラギノ角ゴシックW3とヒラギノ明朝ProN W3の2書体で、10.5pt相当の同じ大きさのまま解像度だけ変えて画像にしました。誤り率（CER）は、正解とOCR結果をNFKC正規化して空白を除き、編集距離を文字数で割った値です。NFKCは「②」を「2」に変えるため、丸数字の誤りはCERに表れません。そこで「129,800」「2026年4月1日」「KX-2026-0415」の3欄が原文どおり出たかを別に数えました。学習データは2026年10月13日に各公式リポジトリのmainから取得しました。各フォルダには横書き用のjpnと縦書き用のjpn_vertを置き、--oem 1 と既定のPSM 3で実行しています。スキャンした紙ではなく合成画像による結果です。実際の帳票では字体・汚れ・圧縮・撮影条件が異なるため、別途評価が必要です。

解像度×学習データの結果

値は「ゴシック / 明朝」のCERです。300dpiと150dpiのCERは1.1〜4.3%でした。100dpiでは標準tessdataのCERが23.5〜41.2%となり、fast・bestとの差が広がりました。bestは100dpiでも1.6%に収まりましたが、72dpiでは崩れます。72dpiの画像を4倍に拡大してから渡すと、fastは29.9%から10.2%まで戻りました。小さな文字を含む画面キャプチャでは、文字の画素数を確認し、拡大前後の認識結果を比較してください。今回の72dpiは10.5pt相当の文字を描いた画像の条件で、画面キャプチャ全般の精度を示す値ではありません。

速さはfastが最も速く、300dpiの1枚でfastが0.7〜1.5秒、bestは3.8〜5.4秒でした（Core i9-9880H、モデル読み込みを含む1回の実行時間）。

標準tessdataのjpnで観測した丸数字への誤認識

標準のtessdataのjpnは、--oem 1 で半角数字25字のうち19字を、既定の3では20字を「⑫⑨.⑧00円」「KX-②0②⑥-0④①⑤」のような丸数字で出力しました。CERは2%台でも、金額・日付・管理番号は3欄とも使えません。今回と同様に金額・日付・管理番号を読む用途では、fastかbestを先に評価することを勧めます。

もう1つ、誤りの傾向として、ゴシック体の金額「129,800」はfastでもbestでも「129.800」と読まれました。後の章で示すwhitelistか、後段の形式チェックで拾う必要があります。

bestの出力に入る語間の空白

bestのjpnで読むと「業務 委託 契約 書」のように語の間に空白が入りました。学習データ内の設定を combine_tessdata -u で取り出すと、fastには preserve_interword_spaces 1 が入っており、bestには無く、代わりに tessedit_load_sublangs jpn_vert が入っています。bestでも -c preserve_interword_spaces=1 を付けると「業務委託契約書」と出ました。

画像側の条件：傾きと照明ムラを実測

合成画像の傾き別CERと10度での未検出結果

公式ドキュメントのImproveQualityは、300dpi以上の画像で最もよく動くこと、傾きが大きいと行分割の品質が大きく落ちることを書いています。300dpiの画像を回転させて測ると次のとおりでした。

10度では4条件ともテキストファイルが0バイトで、エラーも出ませんでした。バッチ処理では「空の結果」を成功として扱わず、件数チェックで止める設計にしてください。スキャナやスマートフォンで取り込んだ画像は、OCRの前に傾き補正を入れるのが確実です。

照明ムラには thresholding_method=2（Sauvola）

Tesseractは内部で画像を白黒に二値化してから読みます。5.0.0で追加された二値化方式は thresholding_method で選べ、0がOtsu（既定）、1がLeptonicaのAdaptive Otsu、2がSauvolaです。右下ほど暗くなる影を重ねた画像をbestで読むと、結果は次のようになりました。

1は影の部分を文字として拾い、「二 二 語 語」のような無関係の文字列を大量に出したため、CERが100%を超えました。この画像では、影のある書類にはSauvolaが合っていました。二値化の考え方そのものは二値化とは？しきい値の決め方と大津・適応的の使い分けをOpenCVの実装で解説で扱っています。

PSMの選択基準とCLI・Tesseract.jsの既定値の違い

PSMは0〜13の14モード、実務で使うのは4つ

PSM（Page Segmentation Mode）は、画像の中の文字をどう区切って読むかの指定です。0〜13の14モードがあり、2は未実装です。

左右2段に文章を置いた画像をPSM 3とPSM 6で読むと、どちらも左右の段を1行につなげて出力し、読み順を保てませんでした。座標が固定された帳票では、項目ごとに切り出してPSM 6や7で読み、読み順と項目の対応を確認してください。

Tesseract.jsとC++ APIの既定はPSM 6、CLIとpytesseractは3

同じ画像でも、ブラウザのTesseract.jsとコマンドラインで結果が変わることがあります。原因の1つはPSMの既定値です。本体ソースのtesseractclass.cppでは tessedit_pageseg_mode の既定が PSM_SINGLE_BLOCK（6）で、CLIのtesseract.cppだけが指定のないときに PSM_AUTO（3）へ切り替えています。pytesseractはCLIを呼ぶので3、APIを直接使うTesseract.jsのドキュメントは既定を PSM.SINGLE_BLOCK と書いています。

Tesseract.js 7.0.0（2025年12月）は既定のOEMが1で、LSTM専用の 4.0.0_best_int（bestを整数化したモデル）を読み込みます。Tesseract.jsのFAQは、設定・学習データ・本体の版が同じならCLIと同じ結果になるとし、違いが出たらOEMとPSMを両方で明示して揃えるよう案内しています。精度が低いと感じたら、まずこの条件を揃えてから入力画像を比べてください。

pytesseractのconfig引数によるOCR設定

pytesseract（0.3.13）は config 引数の文字列をそのままCLIに渡します。検証ではtessdata_bestのjpn・jpn_vertと合成画像を使い、5.5.3で1行目「業務委託契約書 (第2版)」、金額欄「129,800」を確認しました。次のコードの /opt/tessdata_best はbestを置いたフォルダの例で、文書画像をcontract.png、金額欄画像をamount.pngとしています。

import pytesseract
from PIL import Image

# tessdata_bestのjpn.traineddataとjpn_vert.traineddataを置いたフォルダ
base = "--tessdata-dir /opt/tessdata_best --oem 1"

# 文書全体：日本語の語間に入る空白を抑える
doc = pytesseract.image_to_string(
    Image.open("contract.png"), lang="jpn",
    config=base + " --psm 3 -c preserve_interword_spaces=1")

# 金額欄：1行として読み、数字とカンマに絞る（副言語の読み込みを止める）
amount = pytesseract.image_to_string(
    Image.open("amount.png"), lang="jpn",
    config=base + " --psm 7 -c tessedit_load_sublangs= -c tessedit_char_whitelist=0123456789,")

# 単語行の信頼度は0〜100。単語以外の階層行には-1が入る
data = pytesseract.image_to_data(
    Image.open("amount.png"), lang="jpn", config=base + " --psm 7",
    output_type=pytesseract.Output.DICT)

信頼度には注意が要ります。bestで誤読した「129.800」の信頼度は89、正しく読めた「請求」は95でした。信頼度89でも誤読が残るので、信頼度だけを正解の保証にせず、金額・日付は正規表現などの形式チェックと組み合わせます。

LSTMのwhitelist対応と辞書の初期化設定

whitelistによる金額欄「129,800」の認識結果

tessedit_char_whitelist は、出力してよい文字を限定する設定です。4.0ではLSTMが対応しておらず、issue #751で報告されていましたが、ChangeLogの4.1.0（2019年7月7日）にImplemented support for whitelist/blacklist in LSTM engine.とあり、issueも2019年8月17日に閉じられています。5.5.3で金額欄の画像を --oem 1 --psm 7 で読んだ結果です。

fastではwhitelistがそのまま効き、ピリオドに化けていたカンマも正しく戻りました。bestは、同じフォルダにjpn_vertがあると副言語として読み込み、その状態でwhitelistを付けると出力が空になりました。-c tessedit_load_sublangs= で副言語を止めると「129,800」が返ります。標準のtessdataは数字そのものを丸数字で認識しているため、whitelistで丸数字が落ちて「,00」しか残りません。whitelistは文書全体ではなく、切り出した欄にだけ使ってください。

単語辞書の読み込みを無効にする初期化設定

型番やIDのような辞書にない文字列は、言語辞書による補正で既知の語に引き寄せられることがあります。単語辞書の読み込みは load_system_dawg と load_freq_dawg で止められますが、dict.cppを見ると、LSTM用の読み込み処理（LoadLSTM）が参照するのは load_system_dawg だけで、load_freq_dawg はlegacy用の処理でしか参照されません。数値・句読点の辞書は別の設定です。どちらも初期化時専用なので、CLIやpytesseractの -c で渡す必要があり、Tesseract.jsの setParameters では変えられません。今回の契約書画像では辞書設定を変更してもCERは1.1%のままで、この画像では無効化による改善を確認できませんでした。

Tesseractで粘るべきでない場面と切り替え先

手書き文字をTesseractのパラメータで解決しようとするのは、時間の使い方として誤りです。LSTMモデルは活字のテキスト行で学習されており、Tesseract.jsのFAQも、モデルは印刷文字にしか当てはまらない前提で作られており、手書きはどのオプションを組み合わせても大きくは改善しないと説明しています。傾き10度で出力が空になったように、画像が前提から外れると設定だけでは戻りません。

切り替えの目安はこうです。300dpi以上・傾き補正済み・二値化方式を合わせた画像の代表サンプル数十枚を、--oem 1 とbestで読んでも必要な精度に届かないなら、領域切り出しとPSMも確認したうえで、別のOCRとの比較評価へ進みます。日本語の帳票や縦書きならYomiToku Studioの使い方：4つのワークスペースとPython版・商用利用の条件【v0.15.0】やNDLOCR-Lite Webの使い方｜Web AI版との違い・精度・商用利用【2026年9月】、レイアウト込みで読むならGLM-OCRとは？0.9Bの実体と日本語精度・vLLM/Ollama導入手順とAPI料金のようなVLM系のOCRが候補になります。

反対に、対象がレイアウトの安定した活字帳票で要求精度を満たせ、そのうえで画像を外部に送れない、または処理枚数が多くクラウドOCRの従量課金がかさむなら、Tesseractは今も有力な候補です。定型帳票はTesseractで読み、手書き欄や例外書類だけを別のOCRに回す構成がコストと精度の折り合いを付けやすく、こうした振り分けの設計はAI-OCR導入支援でも相談を受けています。

よくある質問

Tesseractの読み方は？

「テッセラクト」です。「テセラクト」「テッサラクト」と書かれることもありますが、同じソフトウェアです。パッケージ名は tesseract（Ubuntu/Debianでは tesseract-ocr）です。

Tesseractはいくらかかりますか？商用利用できますか？

無料です。本体と公式の学習データはApache License 2.0で、商用製品への組み込み・改変・再配布ができます。配布時にはライセンス本文の同梱と著作権表示、改変したファイルへの変更の明記が必要です。

Tesseractは日本語に対応していますか？

対応しています。横書きはjpn、縦書きはjpn_vertの学習データを使います。数字を含む帳票なら、まずtessdata_bestかtessdata_fastで評価してください。標準のtessdataのjpnは今回の実測で数字を丸数字で出力しました。

Tesseract.jsの精度がデスクトップ版より低いのはなぜですか？

エンジンは同じで、既定の学習データはbestを整数化した4.0.0_best_intです。比較時は、PSMの既定（Tesseract.jsは6、CLIは3）に加え、OEM、学習データ、本体のバージョン、入力画像を揃えてください。画面キャプチャは文字の画素数も確認します。

tessedit_char_whitelistが効かないのはなぜですか？

4.0の頃はLSTMが非対応でしたが、4.1.0から対応しています。5.5.3で効かない場合は、bestのjpnがjpn_vertを副言語として読み込んでいないかを疑い、-c tessedit_load_sublangs= を付けて試してください。

手書き文字は認識できますか？

実用的な精度は期待できません。LSTMモデルは活字の行で学習されています。手書き欄はVLM系やクラウドのOCRに回し、活字部分だけをTesseractで読む分担が現実的です。

関連記事

• Tesseract OCRの使い方｜インストール・日本語設定・コマンドとPython/C#連携【5.5.3対応】
• OCRとは？光学文字認識の仕組み・種類・精度と実装での組み込み方を解説
• 二値化とは？しきい値の決め方と大津・適応的の使い分けをOpenCVの実装で解説
• YomiToku Studioの使い方：4つのワークスペースとPython版・商用利用の条件【v0.15.0】
• GLM-OCRとは？0.9Bの実体と日本語精度・vLLM/Ollama導入手順とAPI料金