Bedrock Vision Sonnet 4.6が製品仕様書のOCRで「工」を「エ」と誤読する

この記事は、構成と文章の整理にAIを使っています。
あくまで読みやすくするための補助で、内容そのものをAIにすべて任せて書いているわけではありませんが、ところどころ相談しながら整えています。

Bedrock上でClaude Sonnet 4.6を使って製品仕様書の材質欄をOCRさせるPoCをやっていて、地味に厄介な誤読パターンにぶつかった。

何が起きたか

例えば、こんな一文があったとする。

仕様書の材質欄には、思わぬ落とし穴がある。加工アルミニウムをはじめとする各種材料の表記ルールと注意点を、現場目線でまとめた。

印字幅の都合でちょうど「加」のところで改行がかかると、

…落とし穴がある。加
工アルミニウムをはじめとする各種材料の…

という形になる。ここをSonnet 4.6にOCRさせると、行頭に残った「工」が「エ」に化ける。稀に「ェ」になることもある。印字自体は普通に漢字の「工」（U+5DE5）で、崩れてもいないし解像度が足りてないわけでもない。

原因は完全に折り返し位置。「加工」の間で改行されて「工」だけが行頭に単独で残ると、ゴシック体では「工」（横棒2本）と「エ」（横棒2本+ちょっとした角度、U+30A8）の字形がかなり近くなる。そこに追い打ちで直後が「アルミニウム」というカタカナの並びなので、「工」単体が孤立した状態だと、続くカタカナ列に引きずられてカタカナとして書き起こされる。

なぜこれが起きるか

普通の分類器ベースのOCR（1文字ずつグリフを見て当てはめるタイプ）ならこの引きずられは起きにくい。Sonnet 4.6のようなVLMはそうではなくて、画像を見ながら自己回帰でテキストを生成している。つまり「今の1文字」を、直前までに自分が生成したトークン列との整合性込みで選ぶ。

行頭の「工」は視覚的にほぼ孤立していて、かつ字形が「エ」と紛らわしい。そこに temperature=0（最尤な続きを選ぶ設定）が乗ると、「文として滑らかなカタカナの連なり」の方に倒れやすい。グリフの忠実な転写より、文脈的にもっともらしい続きを優先してしまう。分類ベースのOCRにある古典的な混同ペア（工/エ）に、生成モデル特有の文脈引きずられが上乗せされた形になる。

NFKCなどの正規化では「工」「エ」「ェ」は別コードポイントの別文字として扱われるので、正規化では吸収できない。

対応方針

プロンプト補正・辞書での事後吸収・字形の同一視、どれもやらない方針にした。理由は、印字そのものの誤記（例えば「加工」であるべきところが本当に印字ミスで別の字になっているケース）を後から辞書で握り潰してしまうと、それはそれで見落としになるから。「し」と「じ」を機械的に同一視しないのと同じ考え方。

見積書やラベル印字の検証という用途だと、モデルの読み取り結果は「読み取ったまま」で扱って、差分があれば人が見る方が安全という判断。

代わりに試す余地があるとすれば、テキスト側の補正ではなく画像側の前処理。行単位でクロップして、周辺行のカタカナ列がモデルの視野に入らないようにすれば、文脈引きずられを物理的に断てる可能性はある。ただしこれはまだ試してない。