Tesseractとは？読み方・精度・商用利用とPSM/OEM設定を実務目線で解説

Tesseractは、画像から文字を抽出するオープンソースのOCRエンジンです。Apache License 2.0で配布されているため無料で商用利用でき、ローカル環境だけで完結するので画像を外部へ送信できない業務でも使えます。一方で「入れたが日本語の精度が出ない」「PSMやOEMの意味がわからない」でつまずく例が多く、その原因のほとんどはエンジンではなく学習データの選択と画像の前処理にあります。本記事では読み方とライセンスから、現行版5.5.2の中身、精度を決める要素、PSM/OEMの設定、そしてTesseractでは届かない領域の見極めまでを整理します。

まとめ：Tesseractの要点

先に結論を示します。

• 読み方は「テッセラクト」。4次元の超立方体を指す英単語が語源で、OCRエンジンとしての実体はHP Labs発・2005年にオープンソース化されたプロジェクト。
• ライセンスはApache License 2.0。商用利用・改変・再配布が可能で、ライセンス表記さえ守れば社内システムにも製品にも組み込める。
• 現行版は5.5.2（2025年12月26日リリース）。認識エンジンはバージョン4.0で導入されたLSTM（ニューラルネットワーク）が既定で、旧来のパターンマッチング方式（legacy）は特定の学習データでしか動かない。
• 日本語の精度を左右するのはエンジンではなく、traineddataの系統（fast／標準／best）と入力画像の品質。公式は300dpi以上を推奨しており、傾き・ノイズ・低解像度がそのまま誤認識に出る。
• 活字の帳票・書籍には強いが、手書きと崩れた低品質画像は構造的に苦手。ここは設定で粘らず、VLM系OCRやクラウドOCRへ切り替える判断が早い。

以下、それぞれの根拠と設定の勘所を見ていきます。OS別のインストール手順と基本コマンドはTesseract OCRの基本的な使い方と主要コマンドの解説で扱っているため、本記事では設定と精度の判断に絞ります。

Tesseractの正体：読み方・開発経緯・ライセンス

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

Tesseractは英語で「テッセラクト」と読みます。日本語の記事では「テセラクト」「テッサラクト」と表記が揺れますが、いずれも同じソフトウェアを指します。語源は正八胞体（4次元の立方体）を意味する数学用語のtesseractで、OCRの機能そのものとは関係がありません。検索で映画やアニメの「テッセラクト」が混ざるのはこのためです。

ソフトウェアとしての出自はHP Labsで、2005年にオープンソースとして公開されました。その後2006年から2018年ごろまでGoogleが開発を支援し、現在はGitHubのtesseract-ocrコミュニティが開発を継続しています。20年以上メンテナンスが続いている点は、業務システムへ組み込む際の安心材料になります。

Apache License 2.0で商用利用可、ただし表記義務は残る

ライセンスはApache License 2.0です。商用製品への組み込み、ソース改変、再配布のいずれも許諾されており、利用料は発生しません。ソースコードの公開義務があるGPL系と違い、Tesseractを組み込んだ自社アプリを非公開のまま販売できます。

ただし無条件ではありません。配布時にはライセンス全文と著作権表示を同梱する必要があり、改変した場合はその旨を明示します。またApache 2.0には特許の許諾条項が含まれるため、社内の法務レビューでは「利用料ゼロ」ではなく「Apache 2.0の条件下で無償」と説明するのが正確です。

クラウドOCRと違い画像を外部に送信しないため、個人情報や機密書類を扱う案件で選ばれるのはこの性質が大きい理由です。

現行版は5.5.2、バージョン確認は tesseract –version

2026年7月時点の最新安定版は5.5.2で、2025年12月26日にリリースされました。その前が5.5.1（2025年5月25日）、5.5.0（2024年11月10日）です。手元の環境が何を使っているかは次のコマンドで確認します。

$ tesseract --version
tesseract 5.5.2
 leptonica-1.85.0
 libgif 5.2.1 : libjpeg 8d : libpng 1.6.43 : libtiff 4.6.0 : zlib 1.3.1

2行目以降に出るLeptonica（画像処理ライブラリ）や画像コーデックのバージョンはビルド環境によって変わるため、上の値は出力の形を示す例です。注意したいのは、ディストリビューションのパッケージが最新版とは限らない点です。Ubuntu 24.04のtesseract-ocrパッケージは5.3系で、「公式ドキュメントどおりのオプションが効かない」ときは、まずここが4系や5.3系でないかを疑ってください。版を固定したいならDockerイメージで運用するのが確実です。利用可能な言語データは tesseract --list-langs で確認できます。

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

4.0で入ったLSTMが既定、legacyは学習データを選ぶ

Tesseractの認識方式は、バージョン4.0を境に大きく変わりました。3系までは文字の形状をパターンマッチングで判定していましたが、4.0でLSTM（Long Short-Term Memory）ベースのニューラルネットワーク認識器が導入され、文字単位ではなくテキスト行単位で系列として認識するようになりました。5系ではこのLSTMが既定の認識器です。

誤解されやすいのは「5でlegacyが削除された」という説明です。legacyエンジン自体はコードとして残っていますが、動かせる学習データが限られます。tessdata_bestとtessdata_fastのtraineddataはLSTM用の要素しか持たないため、これらを使うと --oem 0（legacy専用）と --oem 2（legacy＋LSTM）は動作しません。legacyを動かせるのは、legacyモデルとLSTMモデルの両方を含むtessdataリポジトリの学習データだけです。「–oem 0を指定したらエラーになる」トラブルは、ほぼこの組み合わせ違いが原因です。

OEMモードの選び方：迷ったら1（LSTMのみ）

OEM（OCR Engine Mode）は認識エンジンの選択肢です。

実務では --oem 1 を明示指定するのが安全です。既定の3は「使える方を使う」挙動なので、学習データを差し替えたときに認識器が変わって結果が動くことがあります。バッチ処理で出力の再現性が要るなら、OEMは固定してください。

日本語の認識精度を決める2つの変数：traineddataと画像品質

traineddataの3系統は「速度と精度のトレードオフ」で選ぶ

日本語データ（jpn.traineddata）には配布元が3系統あり、どれを置くかで精度と処理時間が変わります。縦書き文書には別途 jpn_vert.traineddata を使います。

OSのパッケージマネージャで入れたjpnデータは多くの場合tessdata（標準）系です。精度が足りないと感じたら、まず tessdata_best のjpn.traineddataをダウンロードし、下記 TESSDATA_PREFIX が指すディレクトリの jpn.traineddata を差し替えて、同じ画像で読み比べてください。追加学習（ファインチューニング）を将来行う予定があるなら、そのベースになるのはtessdata_bestなので最初からこちらに揃えておくと手戻りが減ります。逆に大量バッチで処理時間が問題になる場面ではtessdata_fastが現実解です。

学習データの置き場所は環境変数で切り替えられます。

$ export TESSDATA_PREFIX=/usr/local/share/tessdata
$ tesseract invoice.png out -l jpn --oem 1 --psm 6

精度が出ない原因の多くは画像側にある（公式推奨は300dpi以上）

公式ドキュメントは「Tesseractは少なくとも300dpiの画像で最もよく動作する」と明記しています。スマートフォンで撮影した写真や、72dpi相当の画面キャプチャをそのまま流すと、モデルを最高精度のものに替えても結果は改善しません。まず解像度を確認し、スキャン設定を300dpi以上に上げるのが最短の改善策です。DPI情報を持たない画像には --dpi 300 を付けて明示します。

次に効くのが二値化と傾きです。Tesseractは内部でOtsu法による二値化を行いますが、公式も「背景が不均一な場合は良好な結果にならないことがある」と認めており、影やグラデーションのある紙面ではAdaptive OtsuやSauvolaといった適応的二値化を前処理で当てたほうが確実です。傾きについては、公式が「ページが傾きすぎていると行分割の品質が著しく低下する」と述べています。行分割が崩れると認識器がどれだけ優秀でも復旧できないため、傾き補正は精度対策の中で最も費用対効果が高い工程です。ノイズ除去も同様で、二値化で落ちきらない斑点は誤認識としてそのまま出力に現れます。

優先順位を付けるなら、解像度 → 傾き補正 → 二値化 → ノイズ除去 → 学習データ変更 → パラメータ調整の順です。この順序を逆から、つまりPSMやOEMの総当たりから始めると、入力画像が公式の前提（300dpi以上・傾き補正済み）を満たしていないまま設定だけを動かすことになり、改善幅が出ません。

Tesseract.jsの精度が「低い」と言われる理由

ブラウザで動くTesseract.jsは、WebAssemblyにコンパイルされた同じTesseractエンジンです。認識器が別物なわけではありません。既定の学習データは4.0.0_best_int（tessdata_bestを整数化したモデル）でLSTMのみを使います。それでも「デスクトップ版より精度が低い」と感じられるのは、ブラウザ経由で渡される画像がスクリーンショットやカメラ画像で、解像度と二値化の条件がスキャン画像より不利になりやすいからです。改善の方向は同じで、入力画像の解像度と前処理を先に整えることになります。

PSMとパラメータ設定：誤認識を減らす実務の勘所

PSMは0〜13の14モード、既定の3が合わない場面が多い

PSM（Page Segmentation Mode）は、画像内のテキストをどう区切って読むかの指定です。0から13までの14モードがあり（うち2は未実装）、既定は3（自動ページ分割、方向検出なし）です。既定のままで結果が空になったり文字が混線したりするケースの多くは、モードの選択ミスです。よく使うのは次の4つに絞られます。

帳票処理で --psm 6 が定番になるのは、あらかじめ座標で切り出した矩形を渡す設計と相性がよいためです。全面を3で読ませてから欲しい値を探すより、項目ごとに領域を切って6や7で読むほうが誤認識も後処理も減ります。逆に、複数段組の文書を6で読むと段をまたいで行がつながるので、レイアウトを見ずにモードを固定するのは危険です。

whitelistはLSTMでは効かない前提で設計する

読み取る文字種が決まっている欄では、候補文字を制限する tessedit_char_whitelist がよく紹介されます。金額欄で「0」が「O」に化けるような誤りを候補集合から排除する発想です。ただし、この設定はLSTMエンジンでは効かない、あるいは効きが安定しないことが公式リポジトリのissue（#751、#4407など）で繰り返し報告されています。既定のOEMは実質LSTMなので、指定しても素通りする可能性があると考えてください。

$ tesseract amount.png stdout -l jpn --oem 0 --psm 7 \
    -c tessedit_char_whitelist=0123456789,.-

whitelistを確実に効かせたいなら、legacyエンジン（--oem 0）とlegacyを含むtessdataリポジトリの学習データを組み合わせる必要があります。ただしlegacyはLSTMより認識精度そのものが劣るため、この選択は割に合わないことが多いのが実情です。現実的な設計は、認識はLSTMに任せ、文字種の制約は後段の正規表現バリデーションで担保することです。金額欄なら数字とカンマ・ピリオド以外を弾き、外れた項目は人の確認に回す。この形にしておけば、Tesseract側の挙動に依存せずに済みます。

一方、辞書の無効化はLSTMでも効きます。Tesseractは言語辞書を使って認識結果を補正しますが、型番・ID・専門用語のように辞書にない文字列では、この補正がかえって既知の単語へ引き寄せてしまいます。load_system_dawg と load_freq_dawg を0にすると辞書補正が外れ、記号混じりの識別子が安定します。反対に一般文書では辞書が効いているほうが精度が上がるため、常時オフにするものではありません。業界固有の語彙を足したい場合は、辞書を切るのではなくuser-wordsに登録する方が筋がよい選択です。

Pythonから使うなら pytesseract、設定は config で渡す

PythonからはpytesseractがTesseractのCLIをラップします。ライブラリを入れただけでは動かず、OS側にTesseract本体と言語データが入っている必要がある点に注意してください。

import pytesseract
from PIL import Image

config = "--oem 1 --psm 6 --dpi 300"
text = pytesseract.image_to_string(
    Image.open("invoice.png"), lang="jpn", config=config
)
print(text)

座標付きで結果が欲しい場合は image_to_data を使うと、単語ごとのバウンディングボックスと信頼度（confidence）が取れます。この信頼度は、後段で「一定値を下回った項目だけ人が目視する」という運用を組む際の判断材料に使えます。全件を人がチェックする運用から抜け出す最初の一手はここです。

Tesseractで粘るべきでない領域：手書きと低品質画像

ここは立場を明確にします。手書き文字の認識をTesseractのパラメータ調整で解決しようとするのは、時間の使い方として誤りです。TesseractのLSTMモデルは活字（印刷文字）のテキスト行を対象に学習されており、筆記体や崩し字のように字形の変動が大きい入力は想定の外にあります。PSMを総当たりしても、whitelistを詰めても、この構造的な差は埋まりません。同じことが、低解像度・強い圧縮ノイズ・複雑な背景に重なった文字にも当てはまります。

切り替えの基準はシンプルです。300dpi以上・傾き補正済み・二値化済みの画像で、代表サンプル数十枚を --oem 1 と tessdata_best で読ませてなお必要な精度に届かないなら、それはチューニングの問題ではなくエンジンの適用範囲外です。2025年以降に公開されたdots.mocrやGLM-OCRのようなVLM（視覚言語モデル）系OCRは、文字列の認識とレイアウト理解を同じモデルで行う設計で、手書きや複雑レイアウトはこちらの得意領域です。従来OCRの限界を超えるdots.mocrのマルチモーダル解析という新発想や0.9BパラメータGLM-OCRが提唱する次世代基準を詳細に、これからのドキュメント処理がどう変わるかで扱っているモデル群は、レイアウト解析込みで読み取る設計になっています。日本語の縦書き・旧字体を含む資料であれば、NDLOCR-Lite Webの使い方と精度・商用利用｜インストール不要の無料ブラウザOCRのように日本語資料に特化したOCRのほうが早く要件を満たせます。

逆に、Tesseractを選ぶ理由が明確な条件もあります。画像を外部に送信できない（オフライン処理・個人情報を含む）、処理枚数が多くクラウドOCRの従量課金が積み上がる、対象が活字の定型帳票でレイアウトが安定している。この3条件のどれかに当てはまるなら、Tesseractは今も第一候補です。すべてをどちらか一方に寄せる必要はなく、定型帳票はTesseractで処理し、手書き欄や例外書類だけをVLM系やクラウドOCRへ回すハイブリッド構成が、コストと精度の折り合いとしては現実的です。PDFを含む文書パイプラインを組むなら、MinerUとは？PDFをMarkdownに変換するOSS文書解析ツールの使い方のような文書解析ツールと組み合わせる構成も検討に値します。

よくある質問（FAQ）

Tesseractの読み方は？

英語読みは「テッセラクト」です。日本語の技術記事では「テセラクト」「テッサラクト」といった表記も見られますが、指しているソフトウェアは同じです。語源は4次元の超立方体を意味する数学用語で、OCRの機能とは無関係です。GitHubのリポジトリ名やパッケージ名は一貫して tesseract（Ubuntu/Debianのパッケージは tesseract-ocr）です。

Tesseractは無料で商用利用できますか？

できます。ライセンスはApache License 2.0で、商用製品への組み込み、改変、再配布が許諾されており、利用料は発生しません。組み込んだ自社アプリのソースを公開する義務もありません。ただし配布時にはライセンス全文と著作権表示の同梱、改変時にはその旨の明示が必要です。法務確認では「完全に自由」ではなく「Apache 2.0の条件下で無償利用可」と伝えるのが正確です。

最新バージョンはどれで、どう確認しますか？

2026年7月時点の最新安定版は5.5.2（2025年12月26日リリース）です。手元の環境は tesseract --version で確認できます。ディストリビューションのリポジトリ経由で入れた場合、5.3系など古い版が入っていることがあり、ドキュメントどおりのオプションが動かない原因になります。バージョン依存の挙動を避けたいなら、Dockerイメージで版を固定する運用が確実です。

日本語の精度を上げるには何から手を付けるべきですか？

パラメータではなく画像からです。公式が推奨する300dpi以上を満たしているかを確認し、次に傾き補正、適応的二値化、ノイズ除去の順で前処理を整えます。ここまでやってから、学習データをtessdata_best系のjpn.traineddataへ差し替え、レイアウトに合ったPSM（切り出した領域なら6や7）を指定します。縦書き資料にはjpn_vertを使います。なお文字種を絞るtessedit_char_whitelistはLSTMエンジンでは効かない報告があるため、これに頼らず後段の正規表現チェックで担保してください。

Tesseractは今も使う価値がありますか？

用途次第です。活字の定型帳票・スキャン文書で、画像を外部に送信できない（オフライン処理・個人情報を含む）、あるいは処理枚数が多くクラウドOCRの従量課金が積み上がる、という条件なら今も第一候補です。Apache License 2.0で利用料がかからず、20年以上メンテナンスが続いている点も安定材料です。一方、手書き・崩れた画像・複雑なレイアウトの文書理解が主目的なら、VLM系OCRのほうが投入した工数に対する結果が出ます。

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

実用的な精度は期待できません。TesseractのLSTMモデルは活字のテキスト行を対象に学習されており、字形の変動が大きい手書きは適用範囲の外です。パラメータ調整で埋まる差ではないため、手書き欄がある帳票では、その欄だけをVLM系OCRやクラウドOCRに回すハイブリッド構成を検討してください。活字の定型帳票については、Tesseractは今も十分な精度とコスト優位性があります。

関連記事

• Tesseract OCRの基本的な使い方と主要コマンドの解説
• NDLOCR-Lite Webの使い方と精度・商用利用｜インストール不要の無料ブラウザOCR
• 従来OCRの限界を超えるdots.mocrのマルチモーダル解析という新発想
• 0.9BパラメータGLM-OCRが提唱する次世代基準を詳細に、これからのドキュメント処理がどう変わるか
• MinerUとは？PDFをMarkdownに変換するOSS文書解析ツールの使い方