VLMの画像読み取りが頭打ちのとき自前CNNへ切り替える判断基準

同じ画像を何度読ませても同じ場所で同じ誤りをするなら、それはVLM (画像対応LLM) 側の知覚の限界で、プロンプト改良でも多数決でも直りません。将棋アプリで盤面スクショの読み取りをClaudeから約24.5万パラメータの自前CNNに切り替えたところ、駒の正答が24/27→全問一致、処理時間が20秒超→0.5秒、API費用はゼロになりました。この記事は「どのサインを見たら見切るか」「切り替えが成立する条件は何か」を実測値つきでまとめます。

見切りのサイン: 誤りが「系統的」かどうか

判定方法は単純で、同じ画像を3回読ませて誤り箇所を突き合わせます。毎回違う場所を間違えるならランダム誤りなので、多数決 (複数回読んで一致を採る) で改善の余地があります。逆に毎回同じ場所で同じ間違いをするなら系統誤りで、読ませる回数を増やしても、プロンプトに注意書きを足しても直りません。

実際にclaude-opus-5で「盤上に駒が27枚ある局面」のスクショを3回読ませた結果は19/27・19/27・18/27で、飛車の先後の取り違えと銀の向きの誤りは3回とも同一マスで再現しました。プロンプトに「先後は駒の向きだけで判定する」と明記しても変わらず、claude-sonnet-5に至っては思考量の設定をどう変えても最大10/27でした。誤りの内容が「文字の向き」「似た字形の判別」のようなピクセル単位の分類である点がポイントで、画像全体の意味理解が得意なVLMにとって、ここは構造的に不得意な領域です。

切り替えが成立する3つの条件

自前の分類器に切り替える判断は、次の3つが揃うかで決めます。

1つ目は、タスクを「小さい領域の分類 × 多数」に分解できること。盤面読み取りは「81マスそれぞれの字形分類」に分解でき、これは小型CNNの独壇場です。2つ目は、学習データを合成できること。将棋の駒はフォントで描けるため、書体・色・劣化をランダムに組み合わせればラベル付き学習画像を無限に生成でき、実画像のラベリング作業が要りません。3つ目は、領域の切り出し (盤の格子検出など) を古典的な画像処理で書けることです。

逆に、レイアウトが自由で切り出しが定式化できない、見た目を合成で再現できない、という場合はVLM継続が妥当です。

実測の比較

比較に使ったのは詰将棋アプリの実戦形の局面で、盤上の駒は27枚 (将棋の駒は全40枚ですが、残りは持駒や取られた駒として盤上に無い状態)。CNN側の内訳: 学習データは日本語フォント91書体からの合成のみ、検証は正解を確定させた実スクショ324マス。学習はIntel MacのCPUで約30分、ONNXに変換して約1MBです。opus-5の「13〜96秒」のブレは自動で入る思考 (thinking) の暴走によるもので、難しい画像ほど遅くなります。

VLMは捨てずにフォールバックへ回す

CNNは前提が崩れると全滅します。格子が検出できない画像 (実物の盤を斜めから撮った写真など) では1マスも読めません。一方VLMは精度こそ頭打ちでも、初見のレイアウトに対して「そこそこ読める」頑健さがあります。そこで、まずCNNで読み、格子検出に失敗した画像だけVLMに投げる構成にしました。切り替えは二者択一ではなく、得意領域の住み分けとして設計する方が実用的です。