日本語の縦書きOCR：縦の列方向を維持し、ルビを処理する

日本語の縦書きOCRを行う際は、画像フィルターを変更する前に記述方向を確認してください。縦書きに対応した日本語モデルとセグメンテーション設定を使用し、意図した順序で列が並んでいるかを検証し、本文のみが必要か、ルビも必要かを判断してください。認識可能な文字で埋め尽くされたページであっても、文字の並び順が間違っていれば、使用できない文字起こしになってしまいます。

これらの判断を具体的に行うため、小さく再現可能なローカル実験を実施しました。水平方向の設定では3つの縦書き列がめちゃくちゃになり、垂直方向の設定では通常の本文が復元されましたが、ルビを追加すると2つの句読点が変わり、ルビ部分をトリミングしても句読点の誤りは解消されませんでした。

これらは意図的に小さくした合成サンプルの結果であり、すべての日本語書籍に対する精度を主張するものではありません。ここから得られる有益な教訓はより限定的で、 文字認識、読み順、注記の処理を個別に評価するということです。 単に日本語らしく見えるという理由だけで、その結果を翻訳に送らないでください。

最初に実際に必要なテキストを特定する

従来の日本語の縦書き構成では、文字は行に沿って上から下へ進み、行は右から左へと進みます。ルビはベース文字に関連付けられた小さな文字であり、一般的にルビは読み方を補足します。W3Cの 日本語レイアウト要件（Requirements for Japanese Text Layout） は、これらの記述方向とルビの関係について記述しています。

OCRを行う前に、ページの重要な領域にラベルを付けます：

• 主要な縦書き列
• 本文の横にある小さなルビ
• 横書きの見出し、キャプション、または表
• ページ番号とヘッダー
• 余白のメモまたは無関係な隣接ページ

すべての縦の帯を独立した段落として扱わないでください。 図書館 の横にある小さな仮名の帯は、 としょかんの読み方であり、次の文ではありません。

OCRを評価する前に出力ポリシーを選択する：

同じ出力が、あるタスクでは合格し、別のタスクでは失敗することがあります。私たちの実験で使用するのは 本文のみの文字起こし です。これは比較対象であり、発音学習用エディションにおいてルビの欠落を許容できるものとしては扱いません。

実際の3文のOCR実験

サンプルでは、以下の自作の文を使用しています：

朝の図書館で本を読む。
古い地図には川が見える。
明日は友人と駅で会う。

これらは、図書館での読書、古い地図での川の発見、駅での友人の待ち合わせについて描写しています。改行を削除すると、3つの日本の句点を含めて34個の本文テキストのUnicodeコードポイントがあります。

同じ本文を3つの形式でレンダリングしました：

1. 横書きテキスト.
2. 3つの縦書きの列、右から左へ読みます。
3. ルビ付きの同じ縦書きの列 の横、および 図書館, 地図, 友人、そして 駅.

これらはクリーンな教材用の画像であり、本のスキャンページではありません。レンダラーはNoto Sans CJK JP、64ピクセルの本文文字、24ピクセルのルビ、および簡略化されたグリフごとの縦方向の配置を使用しています。フォントの適切な縦書きグリフ位置を使用するのではなく、手動で選択した位置に小さなアウトライン付きの円として縦書きの句点を描画するため、句点の結果は、適切に組版された本でOCRがどのように機能するかを確立するものではありません。すべての日本語の組版規則を再現しているわけではありません。テストには、ぼれ、歪み、紙のテクスチャ、手書き文字、歴史的な活字、または混合方向のページはありません。

エンジン、モデル、設定

実験は2026年9月7日に実施され、macOS ARM64環境でTesseract.js 7.0.0およびTesseract.js-core 7.0.0をローカルで実行しました。すべての成功した呼び出しでは、公式の tessdata_fast モデルを使用しました（コミット： 87416418657359cb625c412a48b6e1d6d41c29bd、OEM 1、LSTM専用エンジンモード）。

Tesseractの公式モデルリポジトリには、個別の jpn ファイルと jpn_vert ファイルが用意されています。そのドキュメントでは、PSM 5が均一な縦書きブロック、PSM 6が均一なテキストブロックとして説明されています。認識する領域に適したセグメンテーションの前提を選択してください。詳細については、 ページセグメンテーションのドキュメント.

私たちが記録したケースでは、横書きテキストにはPSM 6を使用した jpn を、縦書きテキストにはPSM 5を使用した jpn_vert を使用し、意図的に一致させなかった jpn/PSM 6の縦書きコントロールを比較しました。2つの縦書き構成の間ではモデルとセグメンテーションの両方が変化するため、これはいずれか一方の設定の影響を単独で切り分ける実験ではなく、ワークフローの比較です。

最初の tessdata_best を使用した試行は、OCRテキストを出力する前に利用可能なWebAssemblyコアで中断されました。互換性のために公式の整数 tessdata_fast モデルに切り替え、その障害を記録しました。その切り替えから、特定のモデルファミリの精度に関する結論は導き出されません。

実際に返された結果

比較では空白文字が削除され、Unicode NFC正規化が適用されます。句読点の置き換え、漢字の修正、テキストの並べ替えは 行われません 。完全な 生出力とバージョン/モデルのハッシュ, 本文比較CSV、および エラー注釈 ダウンロード可能です。

たとえば、ルビのケースでは次の1行目が返されました。

Expected: 朝の図書館で本を読む。
Observed: 朝 の 図書 館 で 本 を 読む .

スペースは言及した比較ルールの対象外ですが、最後の句読点は対象となります。検索専用のワークフローならその違いを許容できるかもしれませんが、忠実な文字起こしではそれを記録して修正すべきです。

一致しない縦方向の制御は、 明 古 昌から始まり、意図された最初の文に沿うのではなく、列の上部の文字間を飛び越えていきました。その出力は、個々のシンボルの認識が読書の順序の再構築とは異なる理由を示しています。

完了したOCRの呼び出しは全部で7回ありました。全画像ケースが4回、切り抜きが3回です。すべての出力を保持しました。あるエージェントが、作成された正解データと結果を比較し、画像を視覚的に検証しました。ブラインドによる人間によるレビューや広範なベンチマークコーパスはありません。この実験は、普遍的に最適なエンジン、書籍レベルの精度、またはお使いのスキャン文書でのパフォーマンスを確立するものではありません。

ご自身のページで領域優先のワークフローを使用する

1. ソースを維持し、難しいページを1つ選ぶ

元の画像やPDFは変更しないでください。コピーで作業し、ページ番号を記録します。解決しようとしている問題（密集したルビ、狭い行間、縦書きの上の横書きの見出し、異例に小さい文字など）が含まれるページを選択してください。

本文のページのレイアウトが異なる書籍にとって、クリーンなタイトルページは有用な受け入れテストではありません。ソースがPDFの場合、画像専用のOCRワークフローを実行する前に、信頼できるツールを使用して選択したページを抽出またはレンダリングしてください。この記事のスクリプトはPNGファイルを受け付けますが、PDFの処理や検索可能なPDFレイヤーの構築は行いません。

スキャン済みドキュメントの準備と翻訳のプロセス全体については、より広範な スキャン済みPDFのワークフローを参照してください。このガイドでは、日本語の方向、セグメンテーション、ルビ、および文字起こしの決定に焦点を当てています。

2. 小さな文字を潰さずにキャプチャの欠陥を修正する

有用なズームレベルで実際の文字を検査します。意図しない傾きを直し、無関係なページの境界線を削除し、小さな仮名や句読点を区別するのに十分なコントラストを保ちます。アグレッシブな二値化やシャープ化を自動的な改善として扱うことは避け、OCRを信頼する前に結果の画像と元の画像を比較してください。

Tesseractの 画像品質に関するガイダンス は、解像度、ノイズ、傾き、境界線を網羅しています。これらは書き方の方向とは別物です。角度をつけて撮影されたページを補正する作業は、直立した縦書きの日本語を横に回転させる作業とは異なります。

サンプルファイルには300 dpiのメタデータが含まれていますが、その数値によって欠落している詳細が作成されるわけではありません。実際の本文のグリフサイズは64ピクセルです。「300 dpi」と再ラベル付けされた低解像度の写真は、やはり同じ低解像度の写真です。

3. ページが1つのレイアウトの前提に違反している場合は領域を分離する

1回のOCRの呼び出しで横書きの見出し、縦書きの文章、イラスト、ページ番号をすべて処理しようとする前に、メインの縦書きブロックを単体で試してください。「12ページ、本文、右から1番目の列」といった簡単な領域の記録を残しておきます。その記録により、その後の組み立てを監査可能にすることができます。

混在方向の素材の場合は、適切な横書き設定で横書き領域を認識し、縦書き設定で縦書き領域を認識してから、ドキュメントが意図する順序でそれらを組み立てます。これは、ファイルでテストすることが推奨されるワークフローであり、 3つのサンプル画像によって測定された混在レイアウトの機能ではありません.

私たちの切り抜き実験では、正確に判明している座標を使用して、各合成列の隣にあるルビのストリップを除外しつつ、本文テキストと白い余白を維持しました。これは手動による領域選択のデモであり、自動のルビ削除アルゴリズムではありません。その座標を実際の書籍のページに適用しないでください。

4. 個々の文字を校正する前に列を確認する

意図された方向に沿って作業し、各列の最初と最後の本文文字を比較します。どの列も欠落、重複、逆転、または隣接する列との混同がないことを確認します。その後、列の境界部分の文を検査します。

その後に初めて、個々の漢字、仮名、句読点、数字、固有名詞の修正を行うべきです。そうしなければ、誤った段落に組み立てられる断片の推敲に時間を費やすことになってしまいます。

有用な3パスのレビュー手順は以下の通りです：

1. 領域と順序： 意図されたすべての本文領域が、重複なく順序通りに存在しているか。
2. 文字： 実際の画像とテキストを比較し、小さな句読点や仮名も含めて確認する。
3. 注釈： ルビ項目、注記、または余白のラベルのそれぞれについて、保持するか、分離するか、あるいは意図的に除外するかを決定する。

エンジンの信頼度値は、これらのチェックの代わりにはなりません。私たちの順序をシャッフルした検証でもエンジンが算出した信頼度スコアは返されましたが、だからといってその読み上げ順序が許容できるものになるわけではありません。

理由が分かるまではふりがなを削除しない

本文のみの抽出の場合、ルビが意図せず2層目の文章になってしまわないようにすべきです。しかし、小さな仮名文字列をすべて削除することが安全な一般原則というわけではありません。読みがなは、人名の曖昧さを解消したり、著者が選んだ読み方を保持したり、読者の学習作業を支援したりするのに役立ちます。

私たちのふりがな画像では、OCR出力には主要な漢字が含まれていたものの、4つの読みがなを個別の注釈セットとして返しませんでした。本文のみの検索タスクにおいて句読点の修正後であれば、それで十分かもしれません。しかし、成果物に発音情報の提供が含まれている場合は不十分です。

重要な読み方を別々に保存し、適切な出現箇所に関連付けてください。例：

Page: sample 1
Column: 1 from the right
Base text: 図書館
Reading shown: としょかん
Decision: retain body text; save reading in the annotation record

サンプルの 個別のルビ文字起こし により、その方針が明確になります。それはOCRの成功を主張するものではなく、画像と一緒に作成された正解データ（グラウンド・トゥルース）です。

OCRが仮名を単語に混入させたり、その関連性を失わせたりした場合は、画像と比較して文字起こしを修復してください。言語モデルにソースを推測させ、その推測を復元されたテキストとして提示させてはいけない。不確かな読みについては、代わりにレビュー用のマークを付けてください。

また、切り抜きの結果は、「ルビを削除すればすべてが改善される」という単純すぎる原則にも反しています。2箇所の句読点の違いが残り、影響を受けた文末も変化しました。その所見はこの特定のクリーンなフィクスチャに固有のものであり、セグメンテーション後に結果を検証すべきだということを教えてくれるものであり、切り抜きが一般的にOCRを助けるか害するかを示すものではありません。

テストを再現するか、レビューログを保持する

固定されたモデルやフォントのソース、依存関係のバージョン、ファイルの説明、およびコマンドについては、 実験のREADME をダウンロードしてください。 サンプルジェネレーター, OCRランナー、および 比較スクリプト により、画像作成、認識、評価を分離します。

ランナーは、文書化された Tesseract.jsワーカーAPIを使用します。縦書き領域における主要な設定は以下の通りです。

const worker = await createWorker("jpn_vert", 1, {
  langPath: modelDirectory,
  gzip: false,
  cacheMethod: "none",
});
await worker.setParameters({
  tessedit_pageseg_mode: "5",
  user_defined_dpi: "300",
});

modelDirectory には、ダウンロードして解凍した jpn_vert.traineddata ファイルが含まれている必要があります。これは完全なプログラムではなく抜粋であり、提供されているランナーは、生の結果を保存してワーカーを終了します。

別のOCRアプリケーションを使用する場合でも、設定名が異なるかどうかにかかわらず、ソース領域、元ファイル、モデルまたはツールのバージョン、方向、セグメンテーションの選択、実際の出力、修正されたテキスト、未解決の文字という同じエビデンスを保持してください。 レビューログのテンプレート は、ページがすでに合格していることを暗黙的に示さないように、空白になっています。

私たちのわずかな完全一致の結果を、小説全体に対する約束されたパーセンテージに変換しないでください。異なるフォント、密集した列、歴史的仮名遣い、低品質のスキャン、およびマンガの吹き出しには、それぞれ独自の代表的なテストが必要です。マンガのレイアウトと手書き文字認識はこの実験の範囲外です。

復元されたソースが信頼できる場合にのみ翻訳する

目的が検索、引用のコピー、または辞書の引き直しである場合、検証された日本語のテキストが最終的な結果になる場合があります。OCRが関与していたという理由だけで、ドキュメント全体を翻訳する必要はありません。

言語の壁によって依然として読書が妨げられており、アップロード可能な使用可能なファイルがある場合は、 PDF翻訳ワークフローに進みます。認識エラーと翻訳エラーを区別できるように、元のスキャンとチェックされた文字起こしを保持してください。サンプルランナーは自動アップロード用のPDFではなく、テキストファイルとTSVファイルを生成します。次のツールが必要とする実際の入力形式を準備してください。

BookTranslatorのOCRモードは、元の縦書きレイアウトを保証するのではなく、翻訳されたコンテンツを再構築します。ルビの関連付けをすべて維持したり、未検証の認識ミスを修復したりすると仮定しないでください。 PDF形式保持ガイド と 最終PDF QAチェックリスト.

を使用して、最終ドキュメントの読み取り順序とフォーマットを確認してください。「OCRが完了しました」ではなく、「目的の日本語テキストが存在し、その順序が確認され、注釈の処理が文書化されている」ことが確実な引き渡しとなります。