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

画像から縦書きテキストを抽出する処理で、Bedrock経由のClaude Sonnet 4.6 Visionを使っているんだけど、ちょっと気になる挙動を見つけたのでメモ。

例として本の表紙画像を読ませるケースで説明する。表紙のタイトル下に区切り記号（コロンなど）があって、その直後に続く縦書きの文字列を抽出するような処理を想定してほしい。

何が起きたか

区切り記号の直後にある特定の文字が、濁点付きの文字として誤って読まれることがある。例えば印字上は濁点なしの文字なのに、抽出結果では濁点付きになっている、というパターン。

temperature=0で呼び出していて、画像も加工せず原バイトのJPEGをそのまま送っている。なので前処理（リサイズや圧縮による劣化、二値化処理など）が原因で起きているわけではなさそう。

複数画像で確認した結果

最初は1枚の画像でしか確認できていなかったので「その画像固有のノイズかもしれない」という可能性を疑っていたけど、別の画像でも同じ位置（区切り記号の直後）で同様の現象が再現した。

ただし面白いのが、毎回同じように化けるわけではないということ。同じ条件で複数回試すと、濁点付きと判定される場合とされない場合が両方出てくる。temperature=0にしていても、結果が一致しないケースがある。

なぜ起きるか（推測、実機で完全には裏付けていない）

いくつか考えられる要因があるけど、いずれも推測の域を出ない。

• temperature=0にしても、推論基盤側の演算順序やシャーディングの都合で完全な決定論にはならない可能性がある。同じ入力でも毎回ビット単位で同一の出力になるとは限らない。
• 濁点の有無で音韻・字形が近い文字は、モデル内部の確信度が境界線上にあると考えられる。境界線上にある判断は、ちょっとしたノイズ（crop位置のわずかな差、JPEG圧縮ノイズ、周辺文脈）で転ぶか転ばないかが変わりやすい。

「毎回同じ間違い方をする」のではなく「危ういところで時々転ぶ」という挙動として理解している。

どう対応することにしたか

辞書補正・濁点の同一視・プロンプトでの事前補正、といった機械的な正規化は一切入れないことにした。

理由は単純で、印字が本当に間違っている（誤植）ケースを機械的な補正で潰してしまうリスクがあるから。ブレているものを「よくある形」に寄せる処理を入れると、その正規化ロジック自体が別の誤りを生む可能性がある。

flowchart TD
  A[抽出結果を取得] --> B{区切り記号直後の文字か}
  B -- はい --> C[要確認フラグを立てる]
  B -- いいえ --> D[そのまま採用]
  C --> E[目視で印字と突合]

区切り記号の直後に出てくる文字は、常に要確認フラグを立てて目視で印字と突合する運用にした。個別の自動修正はせず、検出だけを機械的に行う形。

実機での再現条件の絞り込み（どの字種の並びで起きやすいか等)はまだ途中で、確認が進んだら追記するかもしれない。