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

本の表紙や目次でよく見かける「No」という表記、Bedrockのvisionに読み取らせてみたら「No.」になった。元のテキストは「No」（ピリオドなし）なのに、OCR結果は「No.」（末尾にピリオドあり）で返ってくる。文字列としてはズレてるけど、意味としては同じもの。

何が起きたか

「No」は英語の“number”の略記で、語源はラテン語の“numero”。Chicago Manual of Styleをはじめ、英語の一般的なスタイルガイドでは「No.」とピリオド付きが標準的な書き方になってる。一方で日本のビジネス文書だと、品番や項目番号を「No」とピリオドなしで書く場面がよくある。実際、ネットで検索すると「No.（エヌオーピリオド）を今まで使ってたけど…」みたいな、ピリオドを付けるかどうかで迷ってる質問がいくつも見つかる。

対してBedrockのvisionは、本の表紙や目次で使われてる「No」を読み取っても、「No.」と英語スタイルガイド寄りの形にピリオドを補って返してくる。

USAやe.g.の揺れと同じ構造なのか

U.S.A.とU.S.A（末尾ピリオドの有無）、e.g.とeg（同じく末尾ピリオドの有無）、NoとNo.。並べてみると、どれも「略語の最後の文字の後にピリオドを打つか打たないか」という同じ構造の揺れになってる。見た目のパターンとしては確かに同じカテゴリ。

でも原因は別物だった

構造は同じでも、揺れが起きてる理由は違う。

U.S.A.やe.g.のピリオド有無は、書き手が選んでるスタイルの違い。米国式は律儀に全部打つ、簡略記法やイギリス式ではピリオドを落とす、文中か文末かでも変わる。書き手の意図が入ってる。

No→No.の方は、書き手の意図じゃなくてBedrockのvision側の癖っぽい。元の表記慣習を無視して、英語のスタイルガイドで「正しい」とされてる形（No.）を無意識に当てて出力してる、というのが今のところの理解。これはモデルの内部挙動を検証したわけじゃないので、「らしい」の域を出ない。

つまり「末尾ピリオドの有無」という現象は同じでも、片方は人間のスタイル選択、片方はAIの正規化グセ、で発生源が違う。

結論

表記ゆれの見た目（末尾ピリオドの有無）はU.S.A.やe.g.と同じ構造をしていても、原因はスタイル選択とAIの正規化グセで別物。見た目のパターンが同じだからといって、機械的に同一視していい理由にはならない。