Tesseract OCR：スキャンをローカルで読み取る（ガイド フランス語)

#Tesseractとは何か、何とは違うのか

Tesseract は Apache 2.0 ライセンスで公開されている光学文字認識（OCR）エンジンです。公式リポジトリは、メンテナーによって「Tesseract Open Source OCR Engine」と説明されており、現在 GitHub 上で 70,000 スターを超えています。バージョン 4 では、行認識に特化した LSTM ニューラルネットワークベースのエンジンが追加されました。一方、文字パターンを認識する従来のエンジンは、オプションとして引き続き利用可能です。一般的な画像形式（PNG、JPEG、TIFF）を読み取り、プレーンテキスト、hOCR、PDF、または TSV を出力します。最新の安定版である 5.5.3 は 2026 年 7 月 24 日にリリースされました。実用上の注意点として、言語ファイルをインストールし、画像を適切に処理してください（300 DPI、ページがまっすぐ、コントラストが鮮明）。次に適切なセグメンテーションモードを選択し、バッチ処理を開始する前に、約 20 ページの結果を確認してください。

文書の内容を理解するツールではありません。出力するのはテキストで、位置情報が付く場合もあります。あるブロックが見出しだと判定したり、表を行と列の構造に再構成したり、読み取った内容を理解したりはしません。構造化された文書を扱う際、OCRは数ある構成要素の一つにすぎません。

#フランス語：言語ファイル

デフォルトでは、Tesseractは英語を読み取ります。フランス語のドキュメントに対しては、アクセントが失われ、単語が近似値として認識されることになります。そのため、多くの人がエンジン自体の品質が悪いと結論づけてしまいます。ドキュメントには、-lオプションを指定しない場合、英語が前提とされていることが明記されています。したがって、言語のデータファイルをインストールし、実行時に明示的に指定する必要があります。プロジェクトでは、適切なパッケージをインストールすることで、100以上の言語の認識に対応していると主張しています。

# Debian/Ubuntu : installer les données françaises
sudo apt install tesseract-ocr tesseract-ocr-fra

# macOS (Homebrew) : le moteur puis les langues supplémentaires
brew install tesseract tesseract-lang

# Reconnaître une image en français, sortie texte
tesseract scan.png sortie -l fra

# Plusieurs langues dans le même document
tesseract scan.png sortie -l fra+eng

# Sortie PDF avec couche de texte interrogeable
tesseract scan.png sortie -l fra pdf

#画像の品質がすべてを決める

これは、気づいたときには手遅れになりがちな点です。公式ドキュメントの「Improve quality」ページでは、エンジンの設定に先立つ画像処理に重点を置いています。Tesseractは内部でも処理を行っています（Leptonicaライブラリ）が、それだけでは十分でないことがあります。数行のコードで前処理するだけで、質の悪いスキャンを読み取れるようになることもよくあります。請求書抽出ソフトウェアを提供するKoncileは、2026年に公開した自社のテストで、この現象の影響の大きさを示しています。請求書がわずか3〜5度傾くだけで、正しく読み取れる割合が100％から31％に低下しました。独立した研究ではありませんが、この規模の低下は公式ドキュメントの警告と整合しています。エンジンの設定では、このような低下を補うことはできません。事前に傾きを補正することでしか改善できません。

解像度

公式ドキュメントでは、Tesseractが300dpi以上の画像でより正確に動作すると述べており、それ以外の場合はリサイズを推奨しています。

傾き補正

ドキュメントでは、ページが大きく傾いていると行の分割品質が著しく低下すると警告しています。行が水平になるように画像を回転させる必要があります。上記の数値を参照してください。

コントラストと二値化

Tesseractは内部で二値化（Otsu法）を行いますが、背景の色調が均一でない場合、結果が劣ることがあります。バージョン5.0では、thresholding_*パラメータで調整可能なAdaptive OtsuとSauvolaという2つのメソッドが追加されました。バージョン4以降のエンジンでは、明るい背景に暗いテキストが必要です。

画像の余白

余白が広すぎると認識エンジンの処理に支障が出ますが、テキストのぎりぎりまで切り抜いても同様です。ドキュメントでは、余白のない切り抜き画像の周囲に小さな白い余白（例では10ピクセル）を追加することを勧めています。

1. 01
   ページの傾きを補正する

   テキストの主な傾き角度を検出し、ほかの処理に先立って画像を回転させる。ほとんどの卓上スキャナーでは、ハフ変換に基づく簡単なスクリプトで十分です。
2. 02
   コントラストを整える

   グレースケールに変換してから二値化し、真っ白な背景にくっきりした黒が出るようにする。照明にむらがあると固定しきい値ではうまくいかないため、適応的しきい値処理を使う。
3. 03
   画像をトリミングしてOCRを実行

   スキャン画像の縁や大きな空白の余白を取り除き、テキストの周囲に細い白い余白を残してから、処理する文書の種類に適した言語とセグメンテーションモードを指定してTesseractを呼び出す。

#結果に影響を与える設定

セグメンテーションモードは、最も見落とされがちな設定です。ドキュメントにもあるように、Tesseractはデフォルトで1ページのテキストを想定しているため、小さな領域を読み取るには別のモードを選ぶ必要があります。画像に1行だけが含まれている場合、モード7はそれを単一の行として処理します。ラベルが点在するスクリーンショットのように、特定の順序がなくテキストが散在している場合も、対応するモードを選べば同じ問題を回避できます。一方、エンジンモードを変えても結果が変わることはめったにありません。これには実際上の理由があります。従来のエンジンはtessdataリポジトリの言語ファイルにしか含まれておらず、ほとんどのディストリビューションが提供する高速版や高精度版には含まれていないためです。

鮮明で、適切にフレーム内に収められた印刷テキストでは、Tesseractは今も十分な競争力があります。クラウド型の代替サービスを販売するオンラインOCRサービスFastOCRによると、鮮明な英語テキストでの精度はTesseract v5が95〜97.2％、Google Cloud Visionが98.2〜99.1％です。これは利害関係のある事業者による数値で、測定手順は公開されていません。測定結果としてではなく、おおよその目安として受け止めてください。エンジンは、実際に扱う文書の性質に応じて選ぶべきです。鮮明な印刷文書ならTesseractで十分ですが、傷んだ文書、手書き文書、構造が複雑に詰め込まれた文書では、処理全体の弱点になります。

#Tesseractまたはビジョンモデル

この最後の行は、あらゆる文書チェックで重要です。Tesseractは文字を取り違えることで誤りを起こしますが、画像認識モデルは、形式上は完全に整っていても誤った数値を生成することがあります。この違いは絶対的ではありません。金額の0を8と読み違えても、それだけでは気づけないからです。ただし、不自然なテキストは、もっともらしく捏造された値よりも、OCRエンジンの誤りを見抜く手がかりになることが多いのです。2026年に公開された比較記事は、こうした状況の変化をまとめています。本当の代替手段は、もはや従来のOCRエンジンではなく、オープンソースの視覚言語モデルであり、その一つとしてPaddleOCR-VLが名指しされています。ただし、代わりに必要な計算資源は増えます。Tesseractは一般的なCPUで動くのに対し、これらのモデルにはGPUが必要です。

• ローカルのマルチモーダルモデルで読み取れるもの
• 請求書からデータを抽出する：処理の全工程
• Doclingを使用して構造化されたドキュメントを変換
• PaddleOCR：複雑なレイアウトに対応するエンジン

• ソース：GitHub上のTesseract公式リポジトリ
• 出典：Koncile（請求書データ抽出ソフトの提供元）による Tesseract 比較記事（2026 年）
• 出典：Tesseractのマニュアルページ（--psmおよび--oemオプション）
• 出典：Tesseractドキュメント、品質向上
• 出典：Tesseractドキュメント、データファイル

#Tesseractプロジェクトの実際のコスト

エンジン自体は無料なので、OCRプロジェクトで実際にどこに時間がかかるのかが見えにくくなりがちです。本当に手間がかかるのは、エンジンの前後の作業です。画像の前処理（傾き補正、二値化、縁の処理）と、結果の確認が必要になります。現実的な予算を立てるなら、最初のバッチで期待外れの結果が出てからこの2つの工程に気づくのではなく、最初から両方に必要な時間を見込んでおきます。

スキャナー、またはスマートフォンで撮影した写真

フラットベッドスキャナーなら、手持ちで撮影した写真よりも、傾きが少なく照明が均一なページ画像を得られます。処理する量が多く、スキャナーを使うだけの価値がある場合は、スキャナーを優先する。

出力フォーマット

インデックス化にはプレーンテキストで十分です。hOCR形式は位置情報を保持するため、元のインターフェースで抜粋をハイライトするのに役立ちます。

品質チェック

スキャンソースの変更ごとに手動でサンプルを確認し、全体に影響を与える前にずれを検出します。

処理量と並列化

Tesseract はデフォルトでマルチスレッド（OpenMP）で実行されますが、大量の処理には適していません。プロジェクトのよくある質問（FAQ）では、OMP_THREAD_LIMIT=1 と設定してコアごとにプロセスを起動することを推奨しており、マルチスレッドの追加コストを回避できます。

最後に、見落とされがちな項目が、生成ファイルの命名です。数千ページを扱う場合、どのテキストがどのスキャンに対応するかを確認できる必要があります。画像と認識されたテキストで同じベース名を使えば、この問題を最初から解消できます。

#ローカルの処理パイプラインに組み込む

ローカルのドキュメント管理環境において、Tesseract が関与するのは単一の箇所です。テキストレイヤーを持たないドキュメントに対して、インデックス作成の直前です。自動化すべきテストは単純です。PDF のテキスト抽出で、1 ページあたりの文字数が数十文字未満（閾値はコーパスに合わせて調整してください）の場合、おそらくスキャン画像であり、OCR に回します。このテストがないと、ドキュメント全体が空のままインデックスに静かに取り込まれ、ユーザーが疑問を抱くまで誰も気づきません。

傾き補正と二値化は、ページごとに個別に判断するのではなく、この同じパイプライン内で自動化するのがよいでしょう。主な傾きの角度を検出し、エンジンを呼び出す前に補正するスクリプトを使えば、前述の想定外の問題の多くを避けられます。同じスキャナーと同じ種類の文書で構成される均質な一括処理では、この前処理を一度設定すれば、その後は監視なしで実行できます。

#FAQ