技術解説

マンガOCRエンジン徹底比較：お気に入りの作品を正確に読み取れるのはどれ？

更新 2026-08-01

一般的なOCRがマンガで失敗する理由と、特化型エンジンが縦書き日本語、密集した効果音、吹き出し単位のテキスト検出にどう対応するのかを解説します。

OCRなんてすでに解決済みの技術だと思っていませんか？ですが、いざマンガのページで試してみると、すべてが破綻します。

スマホを使って書類からテキストを抽出したことがあるなら、OCRはすでに完成された技術だと感じるかもしれません。しかし、対象を日本のマンガに変えた瞬間、難易度は跳ね上がります。しかもその理由の多くは、実際に試してみるまで気づかないことばかりです。

マンガOCRが一般的なドキュメントOCRと根本的に異なる理由は以下の通りです。

同一ページ内に縦書きと横書きが混在している。 ある吹き出しは上から下への縦書き、語り手の注釈は左から右への横書き、さらにオノマトペ（擬音・擬態語）がコマの中を斜めに飛び交っています。
変形した吹き出しに詰め込まれた複数行のセリフ。 文の途中でフォントサイズが変わり、行間は作者の気分次第、テキストは吹き出しの曲線の縁に沿って折り返されます。
オノマトペはフォントではなく「絵」として描かれている。 「ドーン」や「ゴゴゴ」といった効果音は、標準的なフォントで印字されているわけではありません。手描きされ、引き伸ばされ、歪められ、影がつけられ、背景画と一体化しています。従来のOCRエンジンはこれらをお手上げ状態で見落としてしまいます。
極小の注釈テキストが天敵。 コマの余白の書き込み、6pt相当の極小フォントで囁かれる心の中のつぶやき、コマの端にある補助的なセリフなど、一部のテキストはどんなOCRシステムにとっても判別限界ギリギリのサイズです。
背景の干渉があらゆる場所にある。 イラストの上に重ねられた文字、登場人物の絵に透けて見えるトーンのドット、セリフ枠を真っ直ぐ横切る効果線など、障害に事欠きません。

結論として、一般的なドキュメントOCRとマンガOCRは、実質的にまったく別の課題です。オフィス文書の処理用に設計されたエンジンにマンガのページを放り込んでも、出力結果は「なんとか使えるレベル」から「完全な意味不明の文字列」まで様々です。

では、実際にマンガを正しく認識できるOCRエンジンはどれなのでしょうか？そして、あなたの用途に最適なものはどれでしょうか？誇大広告ではなく、実際のデータをもとに比較してみましょう。

比較対象のエンジン

今回は、3つのカテゴリーに分けた7つのOCRソリューションを検証します。

🌐 商用クラウドAPI

エンジン	特徴・概要
Google Vision OCR	GoogleのドキュメントOCR。密度の高いテキストや手描き文字に対応。箱出し（導入直後）での安定性が抜群。
Azure Read OCR	MicrosoftのOCR。手書き文字のサポートが優秀。ファイアウォール内のコンテナ環境でも実行可能。
AWS Rekognition	Amazonの画像テキスト検出API。ただし、日本のマンガを読み取る用途には期待しない方が無難。

🛠️ オープンソース汎用エンジン

エンジン	特徴・概要
PaddleOCR	Baidu（百度）のOCRフレームワーク。ファインチューニングを行う前提であればポテンシャルは最高峰。導入直後の精度は控えめ。
Tesseract	オープンソースOCRの元祖。縦書き日本語の特殊サポートがあるが、マンガへの適応力は低い。
EasyOCR	最も手軽に始められるオープンソースOCR。ただし、CJK（中日韓）の縦書きテキストには実質非対応。

🎯 マンガ特化型ソリューション

エンジン	特徴・概要
manga-ocr	日本のマンガに特化して構築されたモデル。セリフの吹き出しに対する秘密兵器。

評価スコアボード

以下の表は、公式ドキュメント、公開ベンチマーク、および日本の開発者コミュニティによるテスト結果を総合し、5段階評価（5が最高）で実用的な選定スコアとしてまとめたものです。なお、これはラボで厳密に統制されたベンチマークではなく、エンジニアリング視点による総合評価です。現在、これらすべてを網羅した統一ベンチマークは存在せず、それ自体がこの分野の課題の一つでもあります。

エンジン	縦書き日本語	吹き出し文字	手描きオノマトペ	小さな文字 (≤8pt)	即戦力性 (OOTB)	カスタマイズ性	総合評価
manga-ocr	4.4	4.6	2.0	3.5	4.2	3.0	4.3
Google Vision	4.5	4.0	3.0	4.0	4.0	1.5	4.1
Azure Read	4.0	3.8	3.2	4.2	4.0	1.5	3.7
PaddleOCR	3.4	3.2	2.4	3.0	3.0	5.0	3.2
Tesseract	2.2	2.0	1.2	2.0	1.5	4.0	2.4
EasyOCR	1.8	2.2	1.8	2.2	2.0	4.0	2.3
AWS Rekognition	1.0	1.8	1.0	2.0	3.0	1.0	1.7

ここからすぐに読み取れる重要なポイントが3点あります。

manga-ocr と Google Vision がトップグループ。 manga-ocrはセリフの吹き出し認識で圧倒的、Google Visionは汎用的な信頼性で一歩リードしています。
Azure Read は堅実な3位。 派手さはないものの十分な実力を保持しており、エンタープライズのコンプライアンス要件が必要な場面では間違いなく最良の選択肢となります。
PaddleOCRの素のスコアの低さは誤解を生みやすい。 「3.2」という数値はあくまで追加学習なしの初期状態のスコアです。マンガ領域のデータでファインチューニングを行えば、その潜在能力はこのリストにあるどのクラウドAPIをも凌駕します。
Tesseract と EasyOCR はせいぜいベースラインレベル。 前者はマンガ特有の複雑なレイアウトに対応できず、後者の「縦書きサポート」は技術的な名ばかりにとどまっています。
AWS Rekognition が最下位となったのは、品質の問題ではない。 単に用途が合っていない（プロダクトフィットの問題）ためです。RekognitionのDetectText APIのサポート言語リストには日本語が含まれていません。要するに、一般的な自然風景の標識用テキスト検出器をマンガのOCRバトルに持ち込んでしまっている状態です。

リアルベンチマーク：データが語る真実

7つすべてのエンジンを包括的にカバーする単一のマンガOCRベンチマークは存在しません。しかし、公開されている再現可能な情報源から抽出した以下のプロキシベンチマークは、明確な実態を示しています。

日本語手書きメモテスト（NLSが高いほど高精度）

エンジン	NLS ↑	CER ↓	平均処理時間
Azure Read	0.830	0.332	4.2秒
Google Vision	0.820	0.509	2.2秒
PaddleOCR（標準モデル）	0.353	0.784	12.8秒

出典: nyosegawa/ocr-comparison

ここでの示唆は非常に明快です。ファインチューニングなしの状態では、クラウドAPIが日本語認識においてオープンソースの汎用エンジンを大幅に上回ります。 AzureとGoogleはどちらもNLS（正規化レーベンシュタイン類似度：寛容な精度指標と考えてください）で0.82以上を記録したのに対し、標準のPaddleOCRは0.353にとどまりました。これは単なる差ではなく、次元の違いと言えます。

縦書きビジュアルノベルのサンプル検証

日本の開発者 q7z 氏が、縦書き日本語テキストの単一サンプルに対して行った定性比較では以下の結果が出ています。

Google Vision: 100% 正解。 一文字の狂いもなく正確。
Tesseract: およそ半分が正解。
PaddleOCR: およそ半分が正解。

ここでも、追加学習なし（Zero-shot）の条件下におけるGoogleの縦書き日本語処理能力の高さが際立っています。

PaddleOCRの挽回劇：ドメイン特化ファインチューニングの威力

しかし、PaddleOCRをまだ見限るべきではありません。公開プロジェクトである PaddleOCR-VL-For-Manga では、Manga109-sデータセットを用いてファインチューニングを行うことで、以下の改善を達成しました。

文全体の認識精度: 27% → 70%
文字エラー率 (CER): 約89% → 約10%

これこそが、学習可能なオープンソースフレームワークの真の価値提案です。初期状態の床は低く見えても、労力をかける気さえあれば、天井はどこまでも高くできるのです。

PaddleOCR公式マルチシーンベンチマーク（V100 GPU環境）

モデルバージョン	日本語認識スコア	縦書きテキストスコア
PP-OCRv5	0.7372	0.9314
PP-OCRv4	0.4623	0.5455

PP-OCRv5は、日本語および縦書きテキストの両方でv4のスコアをほぼ倍増させており、真の世代交代を物語っています。それでも、日本語認識スコアの0.7372は、クラウドAPIが誇る0.8以上の領域にはまだ届いていません。結論は一貫しています。ドメイン特化データがなければPaddleOCRは「そこそこ」だが、データを与えれば「極めて強力」になるということです。

各エンジンの詳細比較：得意な領域と限界

Google Vision OCR — 導入の手軽さで右に出るものなし

強み： 今すぐマンガ翻訳パイプラインにOCRを組み込みたい、かつ追加のモデル学習に手をかけたくない場合、Google Visionが最も確実な選択肢です。DOCUMENT_TEXT_DETECTION エンドポイントは高密度なテキスト向けに特化しており、自動での日本語言語検出や手書き文字認識に対応しています。さらに、ページ → ブロック → パラグラフ → 単語 → 記号という構造化された階層データで結果を返します。有志によるテストでは、縦書き日本語のサンプルにおいて**精度100%**を達成しました。

弱点： GoogleはCloud Vision OCRエンジン自体のファインチューニング手段を提供していません。再学習が可能な製品（画像分類向けのVertex AI AutoMLや、項目抽出向けのDocument AIなど）もありますが、コアとなるOCR認識エンジンそのものを再学習させることはできません。Google Visionは汎用サービスとしては極めて優秀ですが、拡張可能なプラットフォームとしては力不足です。性能の上限（天井）が決まっているため、マンガ特有のニーズがAPIの性能を超えてしまうと、それ以上の改善は見込めません。

料金： 毎月最初の1,000ユニットまでは無料。それ以降は1,000ユニットごとに1.50ドル。

注：米国法に基づき、Google CloudサービスにはGoogleのCloud Data Processing Addendum (CDPA)が適用されます。これにはGDPR、CCPA、その他のプライバシー枠組みへの準拠が含まれます。ユーザーがアップロードしたマンガのページなど、個人識別情報（PII）が含まれる可能性のあるコンテンツを取り扱う場合は、処理がCDPAの適用範囲内に収まっているかご確認ください。

Azure Read OCR — エンタープライズレベルのコンプライアンスを誇る選択肢

強み： Azureは、クラウドOCRの中でもエンジニアリング上の仕様限界が最も明確にドキュメント化されています。Microsoftの公式ドキュメントによると、1024×768ピクセルの画像において抽出可能な最小テキスト高は約12ピクセル（150 DPIでの8ptに相当）と明記されています。欄外に極小のテキストが配置されるマンガにおいて、こうした下限値が判明していることは非常に有益です。また、Azure Cognitive Servicesコンテナを使用したコンテナデプロイにも対応しており、外部ネットワークから切り離されたエアギャップ環境の企業システムでも運用可能です。日本語の手書き文字におけるNLS（Normalized Levenshtein Similarity）スコアは0.830で、Googleの0.820をわずかに上回っています。

弱点： Googleと同様、Azureの「カスタムモデル」機能は項目抽出（請求書の解析など）を目的としたものであり、Read OCRの認識エンジン自体を再学習させるものではありません。高度にデザインされた描き文字（オノマトペ）や、背景イラストと重なったテキストに遭遇した場合、数百ページ分の注釈（アノテーション）を追加したところでエンジンの根本的な挙動は変わりません。また、コストの優位性が出るのは大規模運用時に限られます。

料金： 無料枠：毎月5,000トランザクションまで。

注：AzureのOCRサービスは、Microsoftのプロダクト条件およびOnline Services Data Protection Addendum (DPA)の適用を受けます。これらはGDPR、ISO 27001、SOC 2 Type IIへの準拠をカバーしており、EUやカリフォルニア州のデータ規制対象となるユーザー生成コンテンツをマンガOCRワークフローで扱う場合に重要となります。

PaddleOCR — 最高のポテンシャルを秘めるが、相応の投資が必要

強み： PaddleOCRは、今回比較するエンジンの中で最も高いエンジニアリングの柔軟性を誇ります。PP-OCRv5のパイプラインは、向きの分類、歪み補正（dewarping）、行方向の分類、検出、認識という5つのモジュールステージで構成されており、すべてのモジュールを個別にファインチューニングできます。 ページ全体のテキスト検出、吹き出しの読順復元、オノマトペ（SFX）認識、極小テキストの強化などを個別に最適化する必要があるマンガ処理において、このアーキテクチャは単一構造（ブラックボックス）のAPIよりもはるかに価値があります。また、Apache-2.0ライセンスであるため、商用利用でもソフトウェアライセンス費用はゼロです。

弱点： デフォルト（バニラ）状態のモデルの精度は「普通」レベルであり、「優秀」とは言えません。日本語の手書き文字におけるNLSスコアは0.353にとどまり、クラウドAPIの0.820以上と比べると見劣りします。結論として、PaddleOCRのポテンシャルは非常に高いものの、それを引き出すにはマンガ領域に特化したデータが不可欠です。 データのアノテーションやモデルの学習にリソースを割くつもりがない場合、GoogleやAzureを超える精度は得られません。

料金： 無料（オープンソース）。計算リソース、ストレージ、およびデータアノテーションの人件費・作業コストが別途発生します。

manga-ocr — 吹き出しセリフ特化型エンジン

強み： 今回比較する中で、唯一**「日本のマンガ専用」に開発された**エンジンです。横書き・縦書き、ルビ（ふりがな）、背景に重ねられた文字、多様なフォント、低画質画像にも標準で対応しています。最大の特長は、複数行にわたる吹き出し全体を、事前のテキスト行分割なしに1回のフォワードパスで処理できる点です。mokuroのようなマンガ読書ツールでも採用されており、成熟したエコシステムが形成されています。セリフの文字認識に関しては、汎用エンジンの追随を許しません。

弱点： 開発者自身もその限界を明快に認めています。manga-ocrは本格的な手書き文字の認識には失敗する可能性が高く、長文ではハルシネーション（一見正しそうだが誤ったテキストの生成）を起こすことがあります。あくまで「セリフ特化型」であり、万能ではありません。吹き出しやナレーション欄のテキストには最適ですが、オノマトペや手書きの注釈テキストには別の手段を用意する必要があります。

料金： 無料（オープンソース、GitHubで公開）。

Tesseract — 伝統的エンジンの実績と、伝統ゆえの限界

強み： 完全なオープンソース、フルオフライン対応、ファインチューニング可能、Apache-2.0ライセンス。Tesseractには縦書き日本語用の言語パック jpn_vert が同梱されており、--psm 5 オプションで縦書きテキストブロックを明示的にターゲットにできます。LSTMベースのファインチューニングに対応しているため、理論上は自前で学習させることが可能です。また動作も非常に高速で、4つのCPUスレッドがあれば十分に機能します。

弱点： Tesseractは根本的に「整然としたテキスト行」を認識するためのツールです。そのため、不安定な文字境界、複雑な背景ノイズ、多種多様な書体といったマンガ特有の難所には対応しきれません。公式ドキュメントでも警告されている通り、画像の傾きは行分割（セグメンテーション）を破綻させるため、傾き補正（deskew）が必須となります。jpn_vert や --psm 5 を使用した場合でも、国内コミュニティのテストによる認識精度は「約半分」にとどまっています。あらかじめ切り出し・傾き補正を行い、文字方向をそろえたテキストブロックに対してのみ使用してください。生のマンガページをそのまま読み込ませるのはNGです。

料金： 無料（オープンソース）。

EasyOCR — 最も手軽に始められるが、マンガ用途には不向き

強み： 非常にシンプルなインストール、幅広い言語サポート、Apache-2.0ライセンス、カスタムモデルの学習対応。OCRの迅速なプロトタイピングには最適です。

弱点： 公式のリリースノートにも明記されている通り、同ライブラリの「縦書きサポート」は横書きテキストを回転させたものに過ぎず、CJK（日中韓）の真の縦書き（縦組）には対応していません。 マンガOCRにおいて最優先される要件を満たしていないことを、開発者自身が認めているようなものです。国内コミュニティのテストでも致命的な誤認識が相次ぎ、それ以上の評価は見送られました。結論：汎用のOCRライブラリとしては優秀ですが、日本語マンガ用のエンジンとしては実用レベルに達していません。

料金： 無料（オープンソース、GitHubで公開）。

AWS Rekognition — 目的違いのツール

誤解のないよう言っておくと、これは性能の良し悪しの問題ではなく、用途が合っていない（プロダクトフィットしていない）という問題です。 Rekognitionの DetectText は、画像や動画内の「自然言語シーンテキスト（看板や標識など）」を対象としたAPIです。公式ドキュメントによると、サポートされている言語は英語、アラビア語、ロシア語、ドイツ語、フランス語、イタリア語、ポルトガル語、スペイン語であり、日本語は含まれていません。 また、1画像あたりに検出できる単語数も100個までに制限されています。日本語のマンガに対してシーンテキスト用APIを使おうとしている時点で、選定する製品カテゴリーを誤っています。AWSエコシステムにおいてドキュメントOCRの検討を始めるべきは、Rekognition DetectTextではなくTextractです。

料金： 1,000画像あたり約1.00ドル（最初の料金ティア）。

注：Rekognitionを含むAWSサービスには、AWS サービス規約およびAWS Data Processing Addendumが適用されます。これらはGDPRおよび国際的なデータ転送フレームワークをカバーしています。ユーザーがアップロードしたコンテンツを処理する場合は、該当するDPA条項に準拠しているか確認してください。

ユースケース別ガイド：あなたにとっての「最適解」はどれ？

単にスコアが「最も高い」ものを選ぶのではなく、ご自身の状況や目的に合ったエンジンを選択することが重要です。

🚀 「とにかく早くリリースしたい。学習も面倒な設定もなしで。」

→ Google Vision OCR

日本語の認識精度が成熟しており、縦書きテキストにおけるコミュニティのベンチマーク結果も優秀で、価格設定も手頃です。確かに最終的には機能的な限界（天井）にぶつかるかもしれませんが、「まずは動くものを作る」フェーズにおいては、仕様が明確な限界があること自体がメリットにもなります。

🔧 「オフライン対応・オープンソース必須。長期的に精度95%以上を目指したい。」

→ PaddleOCRをベースとしたマンガ特化のファインチューニング

デフォルトのPP-OCRv5をそのまま本番投入して満足してはいけません。正しいアプローチは、PaddleOCRを「学習可能な骨格」として扱うことです。Manga109-sやCOO、さらに自前でアノテーションしたデータをセリフ、描き文字（オノマトペ）、注釈・小文字の3カテゴリーで収集し、検出（detection）と認識（recognition）を個別にファインチューニングします。ドメイン適応によって一文単位の認識精度が27%から70%へと大幅に向上することが、公開データでも証明されています。

💬 「主にフキダシ内のセリフを読み取りたい。ローカル動作重視で最高精度を求めたい。」

→ manga-ocr

複数行のフキダシ文字に特化して構築されており、事前のセグメンテーションも不要で、マンガ読書ツールのエコシステムでも豊富な実績があります。フキダシ検出用の comic-text-detector と組み合わせることで、コミュニティで実証された信頼性の高いローカルパイプラインが完成します。ただし、手書きの描き文字や長文でのハルシネーション（誤生成）には注意が必要です。manga-ocrは「何でもこなせる万能エンジン」としてではなく、「セリフ処理専用の分岐」として利用するのが賢明です。

🏢 「エンタープライズ導入、コンテナ対応、コンプライアンス最優先。」

→ Azure Read OCR

エアクローズド（閉域網）環境向けのコンテナサポート、最小テキスト高の閾値など明確にドキュメント化された精度の境界、そして強力なエンタープライズ向けコンプライアンス体制を備えています。単純な認識精度で常にGoogleを上回るわけではありませんが、企業利用における予測可能性・確実性という点では圧倒的に優れています。

💰 「超低予算、トリミング済みの単純なテキストブロックのみ、オフライン限定。」

→ Tesseract（フォールバック用としてのみ推奨）

事前に切り出し・傾き補正を行い、向きを揃えたテキストブロックに対して、jpn_vert かつ --psm 5 を指定して処理させます。マンガページ全体を処理するソリューションにはなり得ませんが、実用的なベースラインやフォールバック手段としては機能します。

❌ 「非推奨：AWS Rekognitionを日本語マンガOCRのメインエンジンとして使用すること」

製品の公式ドキュメントで、このユースケースが事実上除外されています。どうしてもAWS内で完結させたい場合は、代わりに Textract を検討するか、PaddleOCR / manga-ocr パイプラインをセルフホストすることを推奨します。

OCRの先にあるもの：完全な翻訳パイプラインの構築

マンガ翻訳システムの構築において、OCRは必要不可欠ですが、それだけでは十分ではありません。実用的なシステムにするには、元の作画やフキダシのレイアウトを保ちながら、フキダシ検出、文字消去（インペインティング）、機械翻訳、自動組版（タイプセッティング）、そしてテキストの再配置まで行う必要があります。これは技術的に非常に難易度の高いエンジニアリング課題です。

AI Manga Translator のようなツールは、これらのステップをエンドツーエンドのパイプラインとして統合しています。OCRエンジンの選定、フキダシのセグメンテーション、描画処理などに自前で頭を悩ませる代わりに、マンガのページをアップロードするだけで、元のレイアウトを維持した翻訳版をすぐに取得できます。新規ユーザーには10回分の無料クレジットが提供されているため、自作するか購入するかを検討する前に、完成度の高いパイプラインの挙動を気軽に試すことができます。

とは言え、内部でどのような処理が行われているかを理解しておくことは重要です。次に誰かから「マンガのOCRエンジンってどれを使えばいい？」と聞かれたら、比較表を見せながら「何を優先するかによるよ。理由はね……」と的確に答えられるようになるはずです。

結論

複雑な情報を整理しましょう。マンガOCRにおいて万能な「魔法のエンジン」は存在しませんが、明確な選択基準（意思決定ツリー）は存在します。

フキダシ内のセリフ重視 → manga-ocr
ページ全体を一括処理＆今すぐリリース → Google Vision OCR
エンタープライズのコンプライアンス＋コンテナ運用 → Azure Read OCR
長期的に自前で精度を高めたい → PaddleOCR ＋独自ファインチューニング
低予算のベースライン／フォールバック → Tesseract（切り出し済みブロックのみ）
絶対に使ってはいけない → AWS Rekognition（日本語マンガ用途において）

マンガOCRの難しさは、有名ブランドのエンジンを使えば解決するというものではありません。本当に重要な4つの要素——「縦書き」「フキダシ」「描き文字（オノマトペ）」「小さな注釈文字」——において破綻しないエンジンを選べるかどうかです。この4点をしっかりクリアできれば、マンガ翻訳パイプラインの成功率は飛躍的に高まるでしょう。

*本記事の技術比較データは、各エンジンの公式ドキュメント、公開ベンチマーク（nyosegawa/ocr-comparison）、日本の開発者コミュニティによる検証記事（q7z、Zenn）、およびManga109-s関連の研究論文を元に総合的にまとめたものです。価格情報は調査時点の各社公式料金ページに基づくものであり、最新の仕様・価格については各サービスの公式サイトをご確認ください。

漫画ページを翻訳する

画像または PDF をアップロードし、レイアウトを保ったまま翻訳します。

漫画を翻訳