ローカルVLM「Qwen3.5-9B」で、運転免許証（表面）から本人確認に必要な最小項目（氏名・生年月日・住所）をJSON抽出できるか検証した。
結論は「全部読まない」こと。最小スキーマ＋推測禁止＋1行JSONで安定した。
スマホ原寸画像では待ち時間が出るため、縮小前処理と人間レビューを前提にPoCを組むのが現実解。
第1章 導入：ローカルVLMで「本人確認」が現実になってきた
ローカル環境で動くVLM（Vision-Language Model：画像＋文章を扱えるモデル）が、いよいよ「仕事に使えるかどうか」を試せる段階に入ってきた。
これまでもOCRはできた。だが現場で欲しいのは、文字列の羅列ではなく「誰の何の情報か」を崩さずに取り出すことだ。
そこで今回は、身近で様式が安定している題材として「運転免許証（表面）」を選び、本人確認に必要な情報だけを最小限で抽出するPoCを回してみる。
ここで言う「KYC」は業務用語で、要するに「本人確認」のこと。この記事では難しい話にせず、免許証から本人特定に必要な項目を、機械処理できるJSONとして安定して出せるかに絞る。
この記事でやること
この検証の狙いは、免許証を“全部読む”ことではない。むしろ逆で、事故りやすい領域は最初から切り捨てる。
やることはシンプルで、抽出対象は最小3項目だけ。
- 氏名
- 生年月日（raw と ISOの2形式）
- 住所
免許番号、交付番号、条件、有効期限、取得日テーブルなどは、今回の目的では不要なので読まない。読み間違えたときのリスクが大きいからだ。
出力は「1行のJSONのみ」。推測は禁止し、読めないものは null。
このルールで、Qwen3.5-9B（VLM）がどこまで安定するかを見ていく。
なぜこの題材がスモールビジネス向きなのか
本人確認は、スモールビジネスでも普通に出番がある。採用、業務委託、会員登録、貸出や契約など、書類を人手で確認して転記する作業は意外と残っている。
免許証は、入力（様式）が比較的安定している。
そのためPoCが再現しやすく、「まず1つ動くもの」を作る題材として相性がいい。
第2章 Qwen3.5-9B（VLM）のオーバービューと、今回の実行環境
今回使うのは Qwen3.5-9B。9Bクラスの“Small”ながら、画像も扱えるVLM（Vision-Language Model）として提供されている。モデルカードでは デフォルトのコンテキスト長が262,144トークンであることが明記されており、長い入力を扱える一方で、メモリが厳しい環境ではコンテキスト窓を縮めるよう注意が書かれている。
また、ベースモデル（pre-trained only）側のリポジトリでは、Hugging Face Transformers形式で配布され、Transformers/vLLM/SGLangなどの実行系で扱える旨が説明されている。
LM Studioでの取り回し（GGUFでのローカル検証）
本検証はローカル実行が前提なので、実行環境として LM Studio + GGUFを使った。執筆時点ではLM Studioのモデル一覧からQwen3.5系が検索でき、モデル概要・コンテキスト長・ダウンロードオプションが確認できる。
この「手元のPCで回せる」感が、スモールビジネス向けPoCと相性がいい。
なぜ「3-VL-4Bの進化比較」ではなく、ユースケースで刺すのか
同じ“画像が読める”でも、業務で欲しいのは「読めた文字」ではなく「帳票の意味として崩れない抽出」だ。
今回の本人確認PoCでは、免許証から最小項目をJSONで返せるかが本題なので、モデル比較は深追いしない。比較は1カットだけに留め、以降は仕様設計（最小項目・推測禁止・JSON固定）でどれだけ安定するかに寄せる。
第3章 「全部読まない」が正解：本人確認を最小項目に落とす
免許証は情報量が多い。だからこそ、ローカルVLMで「全部読む」をやると途端に事故りやすくなる。
読み間違いのコストが大きい項目（免許番号、交付番号、条件、有効期限、下段の表など）は、今回の目的では不要だし、PoCの段階で抱えるべきリスクでもない。
今回の狙いは「本人確認に必要な最小情報を、機械処理できる形で安定して出す」こと。
そのため、抽出対象は最小3項目に固定する。
- 氏名
- 生年月日（raw と iso）
- 住所
これだけで「この人は誰か」を確認する用途はかなりの範囲をカバーできる。年齢は便利だが、基準日の扱いで揺れやすく、モデルに計算させると不安定になりがちなので今回は切る。warnings や sample 判定も同様で、親切欄を増やすほど出力が揺れやすい。PoCはまず安定が正義だ。
本人確認（最小）プロンプト
以下が今回のミニマム版。
ポイントは「推測禁止」「JSONのみ」「キー固定」「1行」「不要項目は読まない」を徹底すること。
あなたは「日本の運転免許証（表面）」から、本人確認に必要な最小情報だけを抽出するエンジンです。
入力は免許証画像1枚です。
【目的（重要）】
本人確認に必要な最小情報のみを返してください。
免許区分、番号、交付番号、条件、有効期限、取得日テーブル、公安委員会名などは抽出しないでください。
【重要ルール】
- 推測禁止。読めない場合は null。
- 出力は JSON のみ。説明文や前置き、コードフェンスは禁止。
- 氏名は画像の表記をそのまま抽出（分割・補完・正規化禁止）。
- 住所は画像の表記をそのまま抽出（補完・正規化禁止）。
- 生年月日は raw（そのまま）と iso（YYYY-MM-DD）で返す。西暦に変換できない場合 iso は null。
- 出力は1行のJSONのみ。先頭は {、最後の文字は必ず }。
キー追加・削除禁止。
【出力フォーマット（キー追加・削除禁止）】
{"doc_type":"jp_driver_license_front_kyc_min","name":null,"birth_date":{"raw":null,"iso":null},"address":null}なぜこの形が安定するのか
自由回答に寄せるほど、モデルは「親切に埋める」方向へ走りやすい。業務ではそれが一番危ない。
最小項目に絞って、読めないところは null に落とし、機械側で必須チェックをかける。この責務分離が一番堅い。
- VLMにやらせる：抽出（見えている文字を、そのまま）
- アプリ側でやる：必須項目チェック、JSONパース、保存・審査フロー
第4章 実演：警察庁の免許証サンプルで「最小3項目」を抜く
自分の免許証で検証できたら一番リアルだけど、さすがにそれは出せない。なので今回は、警察庁が公開している免許証の見本写真を入力にして、同じ条件で再現できる形に寄せる。
警察庁: 運転免許の更新等運転免許に関する諸手続について（免許証の見本写真の引用元）
https://www.npa.go.jp/policies/application/license_renewal/index.html
入力：免許証（表面）見本画像
- 入力は画像1枚（免許証の表面）
- 今回は公開見本画像を使用（出典：警察庁）
プロンプト：本人確認（最小3項目）固定スキーマ
前章のミニマム版（キー固定・推測禁止・JSONのみ）をそのまま使う。
ここは記事内では「長い前置き」よりも、最後の固定スキーマ行が重要。
出力：最小3項目のJSON（成功例）
実際の出力はこうなった。
余計な説明が出ず、1行JSONで返ってくるのがポイント。
{"doc_type":"jp_driver_license_front_kyc_min","name":"日本花子","birth_date":{"raw":"昭和61年5月1日生","iso":"1986-05-01"},"address":"東京都千代田区霞が関2-1-2"}
- 氏名：表記どおり
- 生年月日：raw（和暦そのまま）＋iso（西暦に変換）
- 住所：表記どおり
この「raw と iso の二段構え」が効く。業務フロー的には、まず iso を主に扱い、raw は人間が最終確認するときの照合用に回すのが堅い。
速度：ボトルネックは生成ではなく“画像側”
同じプロンプトでも、画像サイズが変わると待ち時間がガラッと変わる。今回の計測では、トークン生成速度（tok/sec）は概ね同程度でも、スマホ原寸のような大きい画像は待つ。
- サンプル画像（小さめ）：約 1.15秒
- スマホ撮影（約3MB）：約 19.68秒
結論として、本番運用を想定するなら 縮小前処理を挟むのが現実的。
免許証は様式が固定なので、長辺を 1024〜1280px くらいに落としても「最小3項目」なら実用域を保ちやすい（落としすぎると番地などの細字が潰れるので、まず1280固定が無難）。
第5章 学び：安定しない原因は「モデル」より「仕様」だった
第4章の成功例だけ見ると「もう実用じゃん」と思える。
ただ、ここに“便利そうな項目”を足した途端、挙動は簡単に揺れる。今回のPoCで一番大きかった学びはこれだ。
抽出タスクは、項目を増やすほど不安定になる。
逆に言うと、最小項目に絞れば、ローカルVLMでも十分に戦える。
1) 年齢（age）が揺れるのは、モデルが悪いというより「責務が混線する」から
年齢は一見便利だけど、モデルに計算させると揺れやすい。実際にログでは、
- 38 になったり
- 39 になったり
- null になったり
が発生した。さらに厄介なのは、年齢の揺れが単なる計算ミスではなく、
- どの日付を基準にしたのか（今日？交付日？有効期限？）
- そもそも日付の取り違えが起きていないか
といった“判断”まで入り込む点だ。
ここでPoCとして一番堅い結論はシンプル。
- VLMにやらせる：氏名／生年月日／住所の抽出
- アプリ側でやる：年齢計算（必要なら）、必須チェック、保存フロー
年齢が必要な現場はある。でもそれは「抽出」ではなく「計算」なので、機械側（コード側）に寄せた方が決定的に安定する。今回、最小項目に落とした途端に安定したのは、この責務分離が効いたからだ。
2) warnings / sample 判定も「便利そうで、ノイズ源」になりやすい
warnings を入れると、モデルは“親切”に文章を書きたがる。
その結果、抽出ではなく評価・判断の方向に寄りやすい。たとえば「見本」から「有効ではない」みたいな断定に飛ぶことがある。
本人確認のPoCで欲しいのは、まず 機械が扱える安定JSON。
注意文の生成は、その次の段階で別タスクに分離した方がいい。
3) 「珍獣召喚」が教えてくれること：自由回答は盛る
この話は、免許証PoCの“対極”として分かりやすい教材になった。
自由記述で「画像内の動物を網羅して列挙して」とやると、9Bは盛りや誤混入が出やすい（いわゆる“幻獣召喚”）。
qwen/qwen3.5-9b（出力抜粋）
カメelper（クジラ類：クジラ、ホオジロザメ）
ヒippo（河馬）
ワニ（爬虫類なので除外）→ 実際は描かれていない
ワタリガエル（両生類なので除外）→ 実際は描かれていない
ここで得られる教訓は、本人確認PoCにそのまま刺さる。
- 帳票のように「出すべき項目」が定義できるタスク → 強い
- 自由回答で「網羅」「列挙」「それっぽい説明」まで求めるタスク → 盛りやすい
だからこそ、今回の本人確認は「最小項目」「固定スキーマ」「推測禁止」「null運用」が正解になる。
4) 結論：最小項目に絞った瞬間、PoCは“運用の入口”に立つ
最小項目に絞るのは、手抜きではない。
運用上の事故を避けるための設計だ。
- 欲張るほど揺れる（年齢、注意文、判定）
- 削るほど安定する（氏名、生年月日、住所）
- 必要になった機能は、後から「別タスク」として足す（責務分離）
この順番で進めると、ローカルVLMでも“現実解”になる。
第6章 速度の現実：本番（スマホ撮影）を想定するなら縮小前処理が効く
PoCは動いても、現場で使うなら「待ち時間」が効いてくる。
今回の検証で分かったのは、待ちの主因が“文章生成”ではなく、画像を読む側（Vision側）の負荷だということ。
同じ最小プロンプトでも、画像サイズが大きいだけで処理時間が跳ねる。
- 公開サンプル（小さめ画像）：約 1.15秒
- スマホ撮影（約3MBの原寸）：約 19.68秒
つまり「最小項目JSON抽出」は出力が軽い。
だからこそ、本番運用で効く最適化は 前処理（画像サイズ）になる。
縮小前処理を挟むとトータルが速くなる可能性が高い
スマホ原寸をそのまま投げると待つ。
でも本人確認（最小3項目）だけなら、フル解像度が必須とは限らない。
事実、681 x 432 px のサンプル画像でも、取りこぼしは起きなかった。
実運用の落としどころとしては、まずこれで十分。
- 画像の長辺を 1280px に縮小（まずは固定）
- 余裕があれば 1024px（速度優先）
- 潰れが出るなら 1600px（安全側）
JPEGなら品質 75〜85 程度でも実用になりやすい。3MB級の画像が数百KBになるので、読み取り側の負荷が軽くなる。
「切り抜き（クロップ）」は最強だが、PoCでは縮小だけでいい
さらに速くするなら、免許証の「氏名・生年月日・住所」が載っている領域だけを切り抜いて渡すのが強い。
ただし、クロップは実装コストが上がる。
今回の目的は「まず回るPoC」なので、
- 最小項目で安定化
- 縮小で体感改善
- 必要ならクロップへ
この順で十分に現実的。
速度面の結論
- 最小項目JSON抽出は、テキスト生成が軽い
- 待ち時間は画像側で決まりやすい
- 本番（スマホ撮影）を想定するなら、縮小前処理を挟むのが効く
第7章 実運用の注意点：ここだけは外さない
PoCが回るのと、運用に載せるのは別の話だ。
免許証の本人確認は便利な反面、扱う情報がセンシティブなので、最低限の安全策は最初から決めておく。
1) 本人の許諾がある画像のみを扱う
これは大前提。本人確認のためとはいえ、本人が提供・同意していない画像を勝手に処理するのは論外。
運用に載せるなら、同意取得の導線（書面でもチェックボックスでも）を先に作る。
2) 出力は自動確定しない（人間レビュー）
今回の最小項目でも、住所や氏名の1文字違いは普通に致命傷になる。
だから「VLMの出力＝確定」にはしない。
- JSONは“候補”
- 最終判断は人間
このワンクッションだけで事故の確率は大きく下がる。
3) ログと保存方針を決めておく
運用で詰まりやすいのはここ。
画像や抽出結果をどこに、どれくらいの期間、誰が見られる形で保存するか。PoCの段階でも「保存しない」「一定期間で削除」「アクセス制限」などの方針だけは決めておくと後が楽になる。
まとめ：Qwen3.5-9Bは“帳票抽出”の即戦力になり得る
今回の結論は派手ではないが、現場では効く。
- 免許証の本人確認は「全部読む」より「最小項目」に落とすほうが安定する
- 最小3項目（氏名・生年月日・住所）に固定すると、ローカルVLMでも現実的に回る
- 便利機能（年齢、注意文、判定）は揺れやすいので、まずは捨てる
- 本番の待ち時間は画像側が支配しやすい。縮小前処理が効く
ローカルで動くVLMが実用に近づいた、というより、“仕様を削ると実用になる”という話だ。
PoCの次の一歩は、縮小前処理とJSON検証、人間レビューを組み合わせて、事故らない形に寄せていくことになる。
参照
警察庁（免許証の見本写真）
https://www.npa.go.jp/policies/application/license_renewal/index.html
Hugging Face：Qwen3.5-9B モデルカード
https://huggingface.co/Qwen/Qwen3.5-9B
