$ cd ../
$ cat post.metadata
OCRが日本語を読み違えるとき — 画像の“外側”の日本語トラブル①
date: 2026-06-16
OCR
日本語
考察
ここから画像の外側。画像に文字を“描く”話の裏返しが、画像から文字を“読む”OCR。日本語は読み取り側にも固有のクセがある。これは一般的に知られた課題の整理（自分の生成実験ではない）。
この記事の位置づけ
ここまでは「gpt-imageで生成して崩れを観察した」実験記事だったが、OCR・LLM・TTS の3回は
画像の外側で起きる日本語トラブルの整理（考察）。特定プロダクトの計測ではなく、日本語処理で一般に知られている課題と定石をまとめる。
1. なぜ日本語OCRは難しいのか
英数字に比べ、日本語OCRは字種が桁違いに多く（常用＋人名用＋記号＋かな）、レイアウトの自由度が高い（縦書き・段組み・ルビ）。文字を“描く”側で崩れやすい字（画数が多い・希少）は、“読む”側でも取り違えやすい。表裏一体だ。
2. トラブルの類型
| 類型 | 具体例 |
|---|
| 形が似た字の取り違え | ロ（カタカナ）/口（漢字）/0、力/カ、ー/一/—/～、ト/卜、ハ/八、シ/ツ、ソ/リ、未/末 |
| 縦書き・段組みの読み順 | 新聞・雑誌・帳票で列をまたいで行が混線。右→左を取り違える |
| ルビ（振り仮名）混入 | 本文行にルビが割り込み「漢字かんじ」のように混ざる |
| 第3・第4水準/異体字/旧字 | 髙・﨑・𠮷・德 などが別字や〓・空白に化ける（B 異体字回と同根） |
| 濁点・半濁点の取りこぼし | 低解像度・かすれで ゛゜ を拾えず「ハ」と「バ」を混同（C かな回の裏返し） |
| 全角半角・桁区切りの揺れ | 金額「1,000」/型番「ABC-12」で区切りや英数字がぶれる（A 和欧混植の裏返し） |
| 手書き・崩し字 | 続け字・略字・くずし字は活字前提モデルだと精度が落ちる |
3. 実務での対策
- 用途でエンジンを選ぶ：活字 vs 手書き、表組み・帳票対応、縦書き対応かどうか。1つで全部はまかなえない。
- レイアウト保持OCRを使い、読み順（縦書き・段組み）とルビを構造として扱う。プレーンテキスト一括は混線しやすい。
- 前処理：二値化・傾き補正・解像度確保（濁点や細部は解像度で決まる）。
- 後処理で補正：辞書・正規表現・言語モデルで「ロ→0」「未/末」などの定番誤りを文脈で直す。Unicode 正規化（NFC）で全角半角・合成済み/結合の揺れを吸収。
- 人名・住所・金額は信頼度スコアでフォールバック：低信頼は候補提示＋人手確認。異体字の人名は機械任せにしない（B 異体字回）。
- 生成画像のテキスト検査にも使う：本編③・E回の「生成→OCRで照合」。想定どおりの文字が描けたか／擬似日本語が湧いていないかの自動チェック。
まとめ
日本語OCRの難所は、似た字・縦書きの読み順・ルビ・異体字・濁点・全角半角——画像生成で崩れる要素とほぼ同じ顔ぶれ。読む側もエンジン選定 × レイアウト保持 × 正規化＆辞書後処理 × 信頼度フォールバックで守る。次はG LLMトークナイザと日本語の相性へ。
sue@blog ~ $ _