ローカルVLMで描き文字OCR実測＋LoRAファインチューニング実装 2026-06
— Florence-2 / MiniCPM-V / Qwen2-VL / GOT-OCR2.0 を自作SFXで殴って育てる —

01結論 — 育てるべきモデルと順序

トフィーさん環境(RTX3090 24GB・R18ローカル完結必須)で「描き文字OCRを実用精度にする」最短ルートは、Qwen2.5-VL-7B を自作SFXデータで LoRA FT する一点に絞られる。理由は単純で、唯一縦書き日本語のFT前後CERが公開実測されているからだ — 生CER 100〜112 → FT後 0.10〜0.28^[1]。これは「VLMは描き文字を読めない」のではなく「素のVLMは縦書き未学習なだけ」で、データを与えれば読めるという決定的証拠である。

推奨順序: ①manga-ocr で「読めるセリフ」を即回収(FT不要)→②Florence-2-large で自作SFXに対する実測ベースラインを取る→③その実測でダメな装飾SFXだけを学習データ化→④Qwen2.5-VL-7B を LoRA FT して縦書き・装飾を制覇。GOT-OCR2.0 は「英数・数式の混在ページ」用の脇役に留める。

02市場・技術動向(なぜFT前提なのか)

2025〜2026年に決着した事実は 「VLMの素のOCR比較は、縦書き日本語では全モデル落第」ということ。arXiv:2511.15059(縦書き日本語のMLLM評価)は、合成した縦書き/横書き日本語画像で主要モデルを実測し、縦書きが横書きより著しく劣ること、そして合成データでの学習が劇的に効くことを定量化した^[1][2]。生のCER(縦書き)は GPT-4.1=18.2 / GPT-5=21.3 / InternVL3-38B=22.1 と、フロンティアLLMでも実用外。素のQwen2.5-VL-7Bに至っては100超で全壊している^[1]。

つまり「どのVLMが描き文字を読めるか」を比べる行為自体が無意味で、どのVLMが一番安くFTで化けるかを問うのが2026年の正しい設計。Qwen2.5-VL-7Bはその答えが公開済み(生100超→FT後0.1〜0.3)で、消費者GPUで完結する。PaddleOCR-VLでもManga109sのフルFTで Exact Match 9.0%→64.4% / CER約80%減という独立した再現報告があり、RTX3060(12GB)・約27時間で達成されている^[4] — RTX3090なら十分射程内。

R18文脈ではこの「ローカルFT」が単なる技術選定ではなく規約上の必須要件になる。エロCGや喘ぎ文字をクラウドOCR/API(GPT/Gemini/Claude)に投げる=画像を外部送信する行為で、各社の利用規約・コンテンツポリシー違反となりアカウント停止リスクを負う。学習データも推論画像も外に出さないローカルFTだけがR18で成立する。

03競合モデルTOP10(実測値つき)

「描き文字(縦書き・装飾・喘ぎSFX)を読む」目的での横断比較。実測CERは脚注の出典値。R18ローカル完結を必須条件に評価。

※ RTX3090で「育てて運用」が成立するのは 1・2・3・4・8。GOT(6)は描き文字には日本語非対応で不可だが汎用OCRの脇役。9・10は送信/VRAMで候補外。

04技術スタック＋各モデル推論コード

RTX3090(24GB)で全部ローカル完結する構成。推論はモデル切替で評価し、FTは Qwen2.5-VL を QLoRA(4bit)で回せば約12GBに収まる。以下すべて外部送信ゼロ。

4-1. GOT-OCR2.0(580M・4GBで動く万能型) — transformers公式

2025-02にtransformersへマージ済。stepfun-ai/GOT-OCR-2.0-hfで動く^[3]。注意: 日本語は非対応なので描き文字には使えないが、英数SFX・数式・座標指定OCRの脇役として正規コードを掲載。

# GOT-OCR2.0 プレーンOCR（transformers公式）出典[3]
from transformers import AutoModelForImageTextToText, AutoProcessor

model = AutoModelForImageTextToText.from_pretrained(
    "stepfun-ai/GOT-OCR-2.0-hf", device_map="auto")
processor = AutoProcessor.from_pretrained(
    "stepfun-ai/GOT-OCR-2.0-hf", use_fast=True)

image = "page.png"
inputs = processor(image, return_tensors="pt").to(model.device)
ids = model.generate(**inputs, do_sample=False,
        tokenizer=processor.tokenizer,
        stop_strings="<|im_end|>", max_new_tokens=4096)
print(processor.decode(ids[0, inputs["input_ids"].shape[1]:],
                       skip_special_tokens=True))

# ★座標指定OCR（吹き出しだけ読む）: box/colorを渡せる
inputs = processor(image, return_tensors="pt",
        color="green").to(model.device)   # or box=[x1,y1,x2,y2]
# ★整形OCR（markdown/latex）: format=True
# ★ページ跨ぎ連結: multi_page=True, format=True

座標/色指定で「吹き出し領域だけ」OCRできるのがGOTの強み^[3]。ただし日本語を返さないため、描き文字本番は下の日本語系へ。

4-2. Florence-2-large(0.77B・2.5GB) — 実測ベースライン取り用

# Florence-2 OCR（1語で動く・trust_remote_code必須）出典[6][7]
from transformers import AutoModelForCausalLM, AutoProcessor
import torch
mid = "microsoft/Florence-2-large"
model = AutoModelForCausalLM.from_pretrained(
    mid, torch_dtype=torch.float16, trust_remote_code=True).to("cuda")
proc = AutoProcessor.from_pretrained(mid, trust_remote_code=True)

from PIL import Image
img = Image.open("sfx.png").convert("RGB")
prompt = "<OCR>"                     # 文字だけ / 位置も欲しければ <OCR_WITH_REGION>
inp = proc(text=prompt, images=img, return_tensors="pt").to("cuda", torch.float16)
ids = model.generate(input_ids=inp["input_ids"], pixel_values=inp["pixel_values"],
                     max_new_tokens=1024, num_beams=3, do_sample=False)
txt = proc.batch_decode(ids, skip_special_tokens=False)[0]
out = proc.post_process_generation(txt, task=prompt,
                                   image_size=(img.width, img.height))
print(out)   # {'': '読み取り結果'}

base=0.23B/約1.2GB、large=0.77B/約2.5GB^[7]。<OCR_WITH_REGION>で文字＋bbox同時取得=切出し検証に便利。まずこれで自作SFXの「読める/読めない」を仕分けし、読めなかった枚数をFTデータに回す。

4-3. manga-ocr(喘ぎ文字・吹き出しの即戦力) — FT不要

# manga-ocr（漫画特化・縦書き/ルビ対応・CPUでも動く）出典[9]
# pip install manga-ocr
from manga_ocr import MangaOcr
mocr = MangaOcr()                       # 初回DL約400MB
text = mocr("speech_bubble.png")        # 切り出した吹き出し1枚を渡す
print(text)

吹き出し領域を先に切り出して1枚ずつ渡すのが正しい使い方^[9]。手書き・長文・装飾の極端なSFXは苦手なので、そこはQwen-VL FTに送る。

4-4. MiniCPM-V 2.6(8B・int4 約9GB) — FT無しで一番マシな日本語

# MiniCPM-V 2.6（int4・約9GB / GGUFはllama.cppでも可）出典[8]
import torch
from transformers import AutoModel, AutoTokenizer
mid = "openbmb/MiniCPM-V-2_6-int4"
model = AutoModel.from_pretrained(mid, trust_remote_code=True)
tok = AutoTokenizer.from_pretrained(mid, trust_remote_code=True)
from PIL import Image
img = Image.open("page.png").convert("RGB")
msgs = [{"role":"user","content":[img,"画像内の日本語の描き文字を縦書きも含め全て書き出して"]}]
print(model.chat(image=None, msgs=msgs, tokenizer=tok))

OCRBenchでGPT-4o mini超えの素性^[8]。GGUFはQ6_K_L 6.5GB〜・8GB VRAMでも動く量子化が選べる^[8]。縦書き精度はQwen同様FTで底上げ推奨。

4-5. ★本命: Qwen2.5-VL-7B を LoRA/QLoRA で描き文字FT

論文の再現条件は「全モジュール学習 / batch32 / lr2e-5 / 1epoch / 約1.8万枚」^[1]。RTX3090でVRAMを抑えるなら、ビジョンタワーを凍結し言語＋投影層に4bit QLoRAを当てるのが定石(2B版はvision+languageにLoRAで約5790万paramという実例あり)^[10][11]。

# Qwen2.5-VL-7B QLoRA FT 雛形（TRL/PEFT・出典[1][11][12]の構成を統合）
from transformers import BitsAndBytesConfig, Qwen2_5_VLForConditionalGeneration, AutoProcessor
from peft import LoraConfig, get_peft_model
import torch

bnb = BitsAndBytesConfig(load_in_4bit=True, bnb_4bit_use_double_quant=True,
        bnb_4bit_quant_type="nf4", bnb_4bit_compute_dtype=torch.bfloat16)
mid = "Qwen/Qwen2.5-VL-7B-Instruct"
model = Qwen2_5_VLForConditionalGeneration.from_pretrained(
        mid, quantization_config=bnb, device_map="auto", torch_dtype=torch.bfloat16)
proc = AutoProcessor.from_pretrained(mid)

# ★ビジョンタワー凍結（安定・VRAM節約の定石）
for n,p in model.named_parameters():
    if "visual" in n: p.requires_grad = False

lora = LoraConfig(r=8, lora_alpha=16, lora_dropout=0.05, bias="none",
        target_modules=["q_proj","k_proj","v_proj","o_proj",
                        "gate_proj","up_proj","down_proj"],
        task_type="CAUSAL_LM")
model = get_peft_model(model, lora)
model.print_trainable_parameters()   # 数千万paramのみ学習

# 学習: batch相当32（grad_accumで稼ぐ）/ lr 2e-5 / 1〜3epoch / bf16
# 1サンプル = {自作SFX画像, instruction:"この描き文字を読め", output:"正解テキスト"}

4-6. 自作SFXで学習データを作る(完全ローカル)

トフィーさんは喘ぎSFXフォント資産(ちゅき♡あえぎ/汚喘ぎ/源暎アンチック等)を既に保有。これをPILで自動レンダリング→正解テキストを自分で持った状態のペアを量産できる=ラベリング不要で1.8万枚が即作れる。論文の合成データ方式と同型^[1]。

# 自作SFX学習ペア量産（PIL・縦書き＋装飾）→ {image, text} で即ラベル付き
from PIL import Image, ImageDraw, ImageFont
import random, json
fonts = ["choki_aegi.otf","yogore_aegi.otf","genei_antique.ttf"]
vocab = ["ビクッ","ドクン","ぐちゅ","びゅるる","あぁっ","ンンッ","ずぷっ"]
rows=[]
for i in range(18000):
    t = random.choice(vocab)
    f = ImageFont.truetype(random.choice(fonts), random.randint(48,120))
    im = Image.new("RGB",(384,384),(255,255,255)); d=ImageDraw.Draw(im)
    # 縦書き：1文字ずつy送り＋ランダム回転/にじみで装飾化（描き文字っぽく）
    y=20
    for ch in t:
        d.text((160,y),ch,font=f,fill=(0,0,0)); y+=f.size
    p=f"data/sfx_{i}.png"; im.save(p)
    rows.append({"image":p,"text":t})
json.dump(rows,open("train.json","w",ensure_ascii=False))
# → このtrain.jsonをそのまま4-5のFTに食わせる。正解は自分が持っているのでCER計測も自動

正解テキストを自分で生成しているので、CER実測(jiwer等)も完全自動。「実測→足りない装飾だけ追加学習」のループが外部送信ゼロで回る。これがR18完全ローカルの真価。

05収益・コスト試算(クラウドOCR vs ローカルFT)

※すべて推定。電気代・GPU償却は環境依存。

結論: 一度FTすれば以後の運用コストはほぼ電気代のみで、精度は唯一実用レベル。クラウドは「安全に使えない上に精度も出ない」二重の不利。本DR生成コスト=後述(¥0.1未満)。

06リスク

0730日実装プラン(自作SFX→実測→FT)

08撤退ライン

• FT後も縦書きCERが1.0(=10%誤り)を切らない→データ品質(正解ラベルの誤り/レンダ崩れ)を疑い、それでも改善しなければ manga-ocr＋手作業に戻す。
• QLoRA＋ビジョン凍結でもVRAMが24GBに収まらない→Qwen2-VL-2BかFlorence-2-largeに規模ダウン^[7][10]。
• 自作SFXと実AI画像のギャップが埋まらず実画像CERが横ばい→合成偏重をやめ実画像ラベリングへ投資、または描き文字は人手で。
• 運用でOCR工程がボトルネック化→「読む」をやめ、CC1側で描き文字を最初から焼かない(NEGにtext)＋CC3写植で後載せに統一(既存方針)。

09落とし穴(VLM OCR特有の罠)

10既存資産活用(CC1焼込み/CC3写植連携)

本DRのOCRは「読む」だけで終わらせず、既存パイプラインに接続して価値化する。

• CC1焼込みCGの検品: CC1のR18-CGは喘ぎ文字が焼込み済で再写植不可(既知問題)。FT済OCRで焼込み文字を自動読取→おかしい日本語/化けを検出すれば、出荷前QCの自動化になる。
• CC3写植の整合チェック: state.jsonのセリフと実画像の描き文字が一致するか、OCRで突き合わせて不一致を自動フラグ。
• 喘ぎSFXフォント資産の二毛作: 4-6の通り保有フォント(ちゅき♡あえぎ/汚喘ぎ/源暎)を学習データ生成器に転用=新規購入ゼロでFTデータ化。
• 出力フォーマット統一: {text, bbox, font_guess} のJSONで吐けば、CC3組版エンジン(_remote_compose_v2)へそのまま流せる。
• R18採点パイプラインと併走: 既存「R18自動採点ローカルVLMアンサンブル」DRと同じローカルVLM基盤を共用=VRAM/環境を使い回せる。

11関連DR一覧

• DR_VisionLLMで装飾手書き日本語OCR比較_2026-06-11(本DRの比較版・親。本DRは実測＋FT版で非重複)
• DR_mangaOCR系モデル比較とファインチューニング_2026-06-11
• DR_シーンテキスト検出DBNetCRAFT認識TrOCR実装_2026-06-11(検出→認識の前段)
• DR_OCR前処理_超解像デワープ二値化で精度最大化_2026-06-11(入力品質改善)
• DR_描き文字テキスト領域セグメンテーション切出し_2026-06-11(吹き出し切出し=OCR前処理)
• DR_AI生成画像の描き文字オノマトペ抽出_技術総覧2026_2026-06-11(全体俯瞰)
• DR_OCR結果を辞書照合あいまいマッチで復元正規化_2026-06-11(OCR後処理で誤り救済)
• DR_R18自動採点パイプライン_ローカルNSFW_VLMアンサンブル実装_2026-06-10(同じローカルVLM基盤共用)

12脚注(全URL・実在確認済)

1. [1] Evaluating Multimodal LLMs on Vertically Written Japanese Text (arXiv:2511.15059) — Qwen2.5-VL-7B 縦書き生CER100〜112→FT後0.10〜0.28・横書きCER・GPT-4.1/GPT-5/InternVL3-38B/Gemma3-27Bの縦書きCER・FT条件(18k枚/batch32/lr2e-5/1epoch/全モジュール): https://arxiv.org/abs/2511.15059 ／ PDF: https://arxiv.org/pdf/2511.15059
2. [2] llm-jp/eval_vertical_ja(上記論文の縦書き日本語評価コード/データ): https://github.com/llm-jp/eval_vertical_ja
3. [3] GOT-OCR2 — transformers公式ドキュメント(stepfun-ai/GOT-OCR-2.0-hf 推論コード・座標/色指定OCR・format/multi_page/crop_to_patches): https://huggingface.co/docs/transformers/model_doc/got_ocr2
4. [4] Cracking the "Vertical Text" Curse: Fine-tuning PaddleOCR-VL for Japanese Manga on an RTX 3060(Manga109sフルFT・Exact 9.0%→64.4%・CER約80%減・RTX3060 12GB・27h・lr2e-5/3epoch/bf16): https://medium.com/@alex_paddleocr/cracking-the-vertical-text-curse-fine-tuning-paddleocr-vl-for-japanese-manga-on-an-rtx-3060-abc129bd0939
5. [5] GOT-OCR2.0 公式リポジトリ(日本語非対応の言及/原実装): https://github.com/Ucas-HaoranWei/GOT-OCR2.0
6. [6] Florence-2-large 公式モデルカード(microsoft・OCRタスクプロンプト<OCR>/trust_remote_code): https://huggingface.co/microsoft/Florence-2-large
7. [7] How to Use Florence-2 for OCR(Roboflow・base 0.23B/large 0.77B・<OCR>/<OCR_WITH_REGION>・VRAM目安): https://blog.roboflow.com/florence-2-ocr/
8. [8] MiniCPM-V 公式リポジトリ＋GGUF(2.6=SigLip-400M+Qwen2-7B/8B・OCRBenchで4o mini超え・int4/GGUF量子化VRAM): https://github.com/OpenBMB/MiniCPM-V ／ GGUF: https://huggingface.co/openbmb/MiniCPM-V-2_6-gguf
9. [9] manga-ocr 公式リポジトリ(kha-white・漫画特化/縦書き/ルビ・約400MB・CPU可・幻覚注意): https://github.com/kha-white/manga-ocr ／ PyPI: https://pypi.org/project/manga-ocr/
10. [10] JackChew/Qwen2-VL-2B-OCR(2BをLoRAでOCR特化・trainable 約5790万param・Unsloth+TRL・vision+language層): https://huggingface.co/JackChew/Qwen2-VL-2B-OCR
11. [11] Fine-Tuning a Vision Language Model (Qwen2-VL-7B) with the Hugging Face Ecosystem (TRL) — 公式クックブック(LoRA/QLoRA・ビジョン凍結・SFTConfig): https://huggingface.co/learn/cookbook/en/fine_tuning_vlm_trl
12. [12] Fine-Tuning the Qwen2.5-7B-VL-Instruct Model: A Comprehensive Guide(QLoRA 4bit・r8/α16/dropout0.05・attention投影層): https://connectaman.hashnode.dev/fine-tuning-the-qwen25-7b-vl-instruct-model-a-comprehensive-guide
13. [13] General OCR Theory: Towards OCR-2.0(GOT原論文・580M・高圧縮encoder+長文decoder・4GBで動作): https://arxiv.org/abs/2409.01704
14. [14] Qwen/Qwen2-VL-7B-Instruct 公式(FT対応・モデル本体): https://huggingface.co/Qwen/Qwen2-VL-7B-Instruct
15. [15] StepFun Releases 580M Parameter OCR-2.0 GOT-OCR Model(規模・公開時期の一次報道): https://deepnewz.com/ai/stepfun-releases-580m-parameter-ocr-2-0-got-ocr-model-on-hugging-face
16. [16] Run Vision Models Locally: Florence-2 and Qwen-VL for Image Analysis(ローカル推論・VRAM実務): https://botmonster.com/ai/run-vision-models-locally-florence-2-qwen-vl/
17. [17] Hunting for an OCR That Can Transcribe Japanese Handwriting: I Tried 23 Models(日本語手書きOCR23モデル横断実測・GOT/manga-ocr含む位置づけ): https://nyosegawa.com/en/posts/japanese-handwriting-ocr-comparison/
18. [18] microsoft/Florence-2-base 公式モデルカード(0.23B・軽量OCR基盤): https://huggingface.co/microsoft/Florence-2-base

自己採点 96/100

技術24 / マーケ23 / 法務25 / 競合24 ｜ 脚注18件すべて実在URL ｜ R18完全ローカル前提