---
title: "dots.mocrとは？dots.ocrとの違いと日本語精度・vLLM導入手順【2026年10月】"
url: "https://www.issoh.co.jp/tech/details/11776/"
published: 2026-04-14
updated: 2026-10-14
categories: ["AI"]
publisher: "株式会社一創"
---

# dots.mocrとは？dots.ocrとの違いと日本語精度・vLLM導入手順【2026年10月】

dots.mocrは、小紅書（RedNote）のモデル研究組織dots studio（公開時の名義はrednote-hilab）が開発した、文書の文字と図版を1つのモデルで解析するオープンソースのOCRモデルです。前身のdots.ocrの次版として2026年2月16日に「dots.ocr-1.5」の名前で公開され、3月19日に現在の名前へ改称されました。論文は華中科技大学との共著です。パラメータ数は約30億で、文書解析ベンチマークのolmOCR-Benchは総合83.9点、多言語ベンチマークMDPBenchの日本語は75.0点です。本記事は2026年10月14日時点の公式リポジトリと評価データをもとに、dots.ocrとの違い、日本語での精度、図やグラフが出力されないときの対処、vLLMでの導入手順、商用利用の条件を整理します。

## まとめ：dots.mocrの要点と2026年10月時点の状況

- 2026年2月16日公開のdots.ocr-1.5を3月19日に改称したモデルで、重みのサイズはdots.ocrと同じ3,039,179,264パラメータ。GPU要件は変わらない
- MDPBenchの日本語75.0点は、Gemini 3 Pro（74.8点）を含め公開表に載る全モデルで最も高い。ただし撮影した文書は総合で13.3ポイント落ちる
- olmOCR-Benchは83.9点。dots.ocr-1.5としての公開（2026年2月16日）後に出たChandra OCR 2（85.8点）とMistral OCR 4（85.20点）が自社計測で上回っている
- 標準のレイアウト解析では図やグラフの中身を出力しない。図は切り出してSVG変換のプロンプトに回す
- ライセンスはMITに追加規約が重なる構成で、準拠法は中国法。商用利用は認められている

日本語の文書を自前GPUで大量に処理する用途では、2026年10月時点で最初に試す候補になります。図表の中身も取り出したい場合は、後述する2段構えの処理を前提にしてください。ただし公式もSVG化の精度は発展途上としており、数値の正確さは自社の図で確かめる必要があります。

## dots.mocrの位置づけと配布元の変更

### dots.ocr-1.5からの改称とdots.mocr-svgの位置づけ

dots.ocrの[公式リポジトリのREADME](https://github.com/studio-dots-ai/dots.ocr)は、2026年2月16日の項でdots.ocr-1.5の公開を、3月19日の項で「dots.ocr-1.5をdots.mocrとして改称した」ことを記しています。検索で見かける「dots.ocr 1.5」は同じモデルの旧称で、他社の比較表でも残っています。たとえばChandra OCR 2のモデルカードは、dots.mocrと同じ83.9点の内訳を「dots.ocr 1.5」の行名で掲載しています。2月に同時公開された、図版からSVGコードへの変換に特化した派生モデルdots.ocr-1.5-svgも、同日にdots.mocr-svgへ改称されました。技術的な背景は論文[「Multimodal OCR: Parse Anything from Documents」（arXiv:2603.13032）](https://arxiv.org/abs/2603.13032)にまとまっています。

### GitHubはstudio-dots-ai、Hugging Faceはdots-studioへ移行

公開時の配布元はrednote-hilabでしたが、現在はGitHubが[studio-dots-ai/dots.mocr](https://github.com/studio-dots-ai/dots.mocr)、Hugging Faceが[dots-studio/dots.mocr](https://huggingface.co/dots-studio/dots.mocr)です。2026年10月14日に確認したところ、旧パスはGitHubが301、Hugging Faceが307で新しいパスへ転送されており、READMEに残る旧IDでも転送先から取得できます。Dockerfileやデプロイスクリプトに旧IDを固定している場合は、転送に頼り続けるより新IDへ書き換えるほうが安全です。ライセンス文書上の権利者は行吟信息科技（上海）有限公司のままで、運営主体は変わっていません。GitHubの最終コミットは2026年3月20日です。Hugging Faceの重みも2026年3月19日のアップロード以降は更新されておらず（7月4日の最終更新は評価結果の追加）、公開後に新しい版は出ていません。

## dots.ocrとの違い：重み・ベンチマーク・出力形式の比較

dots.ocrは2025年7月30日に公開された前身モデルです。レイアウト検出と文字認識を1つの視覚言語モデルにまとめた点が特徴で、論文（arXiv:2512.02498）も出ています。よく見かける「1.7B」は言語モデル部分だけの数字です。Hugging Faceが公開する重みのメタデータでは、dots.mocrとdots.ocrはどちらも3,039,179,264パラメータ、BF16の重みは5.66GiBで一致します。アーキテクチャ識別子もDotsOCRForCausalLMで共通なので、dots.ocrを動かしているGPUと推論基盤はそのまま使えます。

| 項目                               | dots.ocr      | dots.mocr           |
| -------------------------------- | ------------- | ------------------- |
| 公開日                              | 2025年7月30日    | 2026年2月16日（3月19日改称） |
| パラメータ数                           | 3,039,179,264 | 3,039,179,264       |
| olmOCR-Bench 総合                  | 79.1          | 83.9                |
| OmniDocBench v1.5 文字編集距離（低いほど良い） | 0.048         | 0.031               |
| MDPBench 総合                      | 76.5          | 80.5                |
| MDPBench 日本語                     | 70.6          | 75.0                |
| MDPBench 撮影文書                    | 72.3          | 77.2                |
| 図版のSVG出力                         | なし            | あり                  |

上の表のすべての指標でdots.mocrが上回っており、新しく導入するならdots.mocrを選ばない理由はほぼありません。それでも2026年10月14日時点の直近30日のダウンロード数は、dots.ocrが888,620回、dots.mocrが258,481回で、旧モデルのほうが3倍以上使われています。移行で変わるのはモデルIDと、パッケージ名（dots\_ocrからdots\_mocr）・重みの保存先（DotsOCRからDotsMOCR）だけで、プロンプト名は共通です。精度の差を考えると早めに切り替える価値があります。

## olmOCR-Benchの内訳に表れる得意・不得意

olmOCR-Benchは1,403件のPDFと7,010件のテストケースで構成される英語中心の評価セットです。以下は公式リポジトリが公開する内訳で、開発元の内部評価を含みます。

| カテゴリ     | dots.mocr | dots.ocr |
| -------- | --------- | -------- |
| ヘッダ・フッタ  | 94.0      | 94.1     |
| 表組み      | 90.7      | 88.3     |
| arXiv論文  | 85.9      | 82.1     |
| 旧スキャンの数式 | 85.5      | 64.2     |
| 多段組み     | 85.3      | 82.4     |
| 微小文字の長文  | 81.6      | 81.2     |
| 旧スキャン文書  | 48.2      | 40.9     |
| 総合       | 83.9      | 79.1     |

伸びが最も大きいのは旧スキャンの数式で、21.3ポイント改善しています。弱点ははっきりしていて、劣化したスキャン文書は48.2点と、次に低い微小文字の81.6点より33.4ポイント低い水準です。紙が黄ばんだ古い資料や何度もコピーした書類が主対象なら、人手の校正工程を残す設計にしてください。

なお公式READMEの比較表に載るMistral OCRは72.0点ですが、これは旧版の値です。2026年6月23日発表の[Mistral OCR 4は自社発表でolmOCR-Bench 85.20点](https://mistral.ai/news/ocr-4/)（現行は7月16日公開のOCR 4.1）、2026年3月16日公開の[Chandra OCR 2はモデルカードで85.8点](https://huggingface.co/datalab-to/chandra-ocr-2)としています。どちらも各社の自社計測ですが、英語中心のこのベンチマークでは、dots.mocrはもう首位ではありません。

## 日本語文書の精度：MDPBenchの日本語列で見る他モデルとの差

### 日本語75.0点は公開表の全モデルで最高

日本語の実力は、17言語・3,400枚の文書画像で構成される[MDPBench](https://huggingface.co/datasets/Delores-Lin/MDPBench)で測れます。dots.mocrの公式READMEには載っていませんが、データセット側の公開表に各モデルの言語別スコアが並んでいます。日本語列を抜き出すと次のとおりです。なお、MDPBenchの著者には、dots.mocrの論文にも名を連ねる華中科技大学の研究者が含まれます。

| モデル                   | 日本語  | 総合   | デジタル | 撮影   |
| --------------------- | ---- | ---- | ---- | ---- |
| dots.mocr             | 75.0 | 80.5 | 90.5 | 77.2 |
| Gemini-3-pro-preview  | 74.8 | 86.4 | 90.4 | 85.1 |
| MonkeyOCRv2-B-Parsing | 71.9 | 83.3 | 88.1 | 81.7 |
| dots.ocr              | 70.6 | 76.5 | 88.8 | 72.3 |
| PaddleOCR-VL-1.5      | 69.5 | 78.3 | 87.4 | 75.2 |
| chandra-ocr-2         | 68.8 | 79.7 | 87.8 | 77.1 |
| PaddleOCR-VL-1.6      | 68.7 | 75.0 | 82.8 | 72.6 |
| GLM-OCR               | 65.5 | 67.3 | 77.9 | 63.7 |
| Claude-Sonnet-4.6     | 63.4 | 73.1 | 85.0 | 69.3 |
| ChatGPT-5.2           | 55.8 | 68.6 | 85.6 | 63.0 |
| DeepSeek-OCR          | 49.1 | 51.8 | 80.7 | 42.2 |

dots.mocrの日本語75.0点は、汎用の大規模モデルを含めた公開表の中で最も高い値です。英語87.4点や中国語84.6点より低いのは事実ですが、それはdots.mocr自身の言語間の差で、他のモデルも日本語では軒並み点を落としています。日本語を主に扱う用途でも、オープンなモデルの中では最初の比較対象になります。一方、総合点ではGemini-3-pro-previewとMonkeyOCRv2が上で、多言語を広く扱うなら、日本語列だけで選ばず扱う言語の列も確認してください。表にない和文特化のYomiToku等とは、この表では比べられません。

### 撮影文書で13.3ポイント下がる精度

同じ表で、dots.mocrはデジタル文書90.5点に対し、スマートフォン等で撮影した文書は77.2点です。差は13.3ポイントで、Gemini-3-pro-previewの5.3ポイント差より落ち幅が大きくなっています。日本語と撮影条件を掛け合わせたスコアは公開されていないので、紙の帳票を撮影して読ませる業務では、自社の実画像で精度を測ってから導入を決めてください。なおMDPBenchのデジタル文書は電子的に作成されたページで、スキャンした画像は別に測られていません。スキャンPDFでも、olmOCR-Benchの旧スキャン文書は48.2点にとどまります。

### 日本語の実文書で報告されている誤り方

第三者の検証として、日本循環器学会の99ページのガイドラインPDFをYomiTokuと比較した[Zennの記事](https://zenn.dev/bumbushoji/articles/fcc654a52e77d8)があります。dots.mocrは見出しの階層、ページ区切り、参考文献番号の上付き文字、ローマ数字の「Ⅲ」を正しく出力した一方、「上梓」を「上枠」とするような漢字の誤認識が報告されています。構造は崩れにくく、字形の似た漢字で間違える傾向です。後段で誤字を校正する工程を置くか、固有名詞の辞書照合を入れる設計が合います。

## 図やグラフの中身が出力されない理由とSVG変換の手順

### 図の領域を画像のまま残す既定プロンプトの仕様

dots.mocrを文書RAGの前処理に使うと、グラフや図の中の数値が出力に含まれないことがあります。日本語RAG向けに4つのOCRを比べた[Qiitaの検証記事](https://qiita.com/engchina/items/6dff7010af1b28e8c30a)でも、dots.mocr（記事内の表記はdots.ocr、モデルIDはrednote-hilab/dots.mocr）は相関ヒートマップの数値を1つも返さなかったと報告されています。既定のプロンプトを使う限り、これは読み取りの失敗ではなく仕様どおりの動作です。

parser.pyの既定であるprompt\_layout\_all\_enは、[公式のprompts.py](https://github.com/studio-dots-ai/dots.mocr/blob/master/dots%5Fmocr/utils/prompts.py)で`Picture: For the 'Picture' category, the text field should be omitted.`と定義されています。図と判定した領域は文字起こしの対象外です。Markdownへの変換処理では、その領域を切り抜いて`data:image/png;base64,`で始まる画像として埋め込みます。テキストだけをベクトル化するRAGでは、図の情報が丸ごと抜け落ちたうえ、長いbase64文字列がチャンクに混ざります。取り込む前に画像の行を除去してください。

### 図の領域を切り出してprompt\_image\_to\_svgに渡す手順

図の中身を取り出すには、レイアウト解析の結果JSONからPictureの枠を切り出し、SVG変換のプロンプトprompt\_image\_to\_svgで推論し直します。次のスクリプトは公式リポジトリのモジュールを使い、1ページ分の図をSVGファイルに書き出します。

```
# figures_to_svg.py：レイアウトJSONのPicture領域を切り出し、prompt_image_to_svgでSVGに変換する
import json
import sys
from pathlib import Path

from PIL import Image
from dots_mocr.utils import dict_promptmode_to_prompt
from dots_mocr.utils.doc_utils import load_images_from_pdf
from dots_mocr.utils.svg_utils import extract_svg_from_response
from dots_mocr.model.inference import inference_with_vllm

src, layout_path = sys.argv[1], sys.argv[2]
page_no = int(sys.argv[3]) if len(sys.argv) > 3 else 0

cells = json.loads(Path(layout_path).read_text(encoding="utf-8"))
if not isinstance(cells, list):
    sys.exit("このページはJSONの解析に失敗しています（filtered）")

# 座標はparser.pyが読んだ画像基準。PDFは既定の--dpi 200で描画し直して揃える
if src.lower().endswith(".pdf"):
    page = load_images_from_pdf(src, dpi=200)[page_no]
else:
    page = Image.open(src).convert("RGB")

pictures = [c for c in cells if c["category"] == "Picture"]
for i, cell in enumerate(pictures):
    crop = page.crop(tuple(cell["bbox"]))
    prompt = (dict_promptmode_to_prompt["prompt_image_to_svg"]
              .replace("{width}", str(crop.width))
              .replace("{height}", str(crop.height)))
    svg = inference_with_vllm(crop, prompt, port=8000, model_name="model",
                              temperature=0.9, top_p=1.0)
    out = Path(layout_path).with_name(f"{Path(layout_path).stem}_fig{i}.svg")
    svg_text, ok = extract_svg_from_response(svg or "")
    out.write_text(svg_text or "", encoding="utf-8")
    print(out, cell["bbox"])
```

```
# 1. レイアウト解析（PDFはページごとに doc_page_0.json などが出る）
python3 dots_mocr/parser.py doc.pdf --output ./out
# 2. 1ページ目の図をSVGにする
python3 figures_to_svg.py doc.pdf out/doc/doc_page_0.json 0
```

温度を0.9にしているのは、公式のSVG用デモdemo\_vllm\_svg.pyが同じ値を使い、「低い温度では出力が繰り返しやループになりやすい」とコメントしているためです。parser.pyの既定は0.1なので、parser.pyに`--prompt prompt_image_to_svg`を渡すだけでは温度が低いまま推論されます。その場合は`--temperature 0.9`も付けてください。

2026年10月14日に、公式リポジトリのコードとvLLM互換の応答を返す検証用サーバーを使って、このスクリプトを画像とPDFの両方で実行しました。送信されるリクエストがモデル名model、温度0.9で、SVGの描画範囲（viewBox）が切り抜いた図の寸法に置き換わることを確認しています（実モデルでのSVGの出来は未検証です）。PDFでは解析結果の座標が200dpiで描画したページ画像を基準にするため、解像度を揃えないと枠がずれます。SVGの品質を優先するなら、dots.mocr-svgを`--served-model-name model`付きで別のポートに起動し、`port=`をそちらに向けます。

モデルリポジトリに同梱されたLlamaIndexのParseBenchの評価で、本文テキスト90.0点・表85.2点に対しチャートが0.9点にとどまるのも同じ理由です。この評価はチャートの数値とラベルを表形式の出力から照合する方式で、図を画像のまま残す既定動作では点が付きません。SVG変換まで組む前提なら、この数字だけで不採用にする必要はありません。

## PaddleOCR-VL・Chandra・Mistral OCRとの選び分け

| モデル              | 規模     | MDPBench日本語 | 提供形態            |
| ---------------- | ------ | ----------- | --------------- |
| dots.mocr        | 約3.0B  | 75.0        | 重み公開・MIT＋追加規約   |
| Chandra OCR 2    | 約5.3B  | 68.8        | 重み公開・売上等で商用制限   |
| PaddleOCR-VL 1.5 | 約0.9B  | 69.5        | 重み公開・Apache 2.0 |
| GLM-OCR          | 公称0.9B | 65.5        | 重み公開・MIT        |
| Mistral OCR 4.1  | 非公開    | 未掲載         | API・1,000ページ4ドル |

判断の分かれ目は、日本語の比重とライセンスです。日本語文書が中心で自前のGPUがあるならdots.mocrを選びます。Chandra OCR 2はolmOCR-Benchでは上ですが、[モデルのライセンス](https://huggingface.co/datalab-to/chandra-ocr-2/blob/main/LICENSE)が、前年の売上または調達額が200万ドルを超える企業の商用利用を対象外としています。多くの事業会社では別途の商用契約が必要になります。

PaddleOCR-VLは約3分の1の規模で動き、小さなGPUでスループットを稼ぎたい場合に向きます。現行の1.6は2026年5月27日公開ですが、MDPBenchでは1.5のほうが総合・日本語とも高いので、日本語用途では両方を試す価値があります。GPUを持たずに月数万ページ程度を処理するなら、Mistral OCR 4.1の従量課金が手軽です。10万ページで400ドル、Batch APIなら半額の200ドルが目安で、エンタープライズ契約ではセルフホストも提供されています。毎月それ以上の量を流すなら、5.66GiBの重みを単一GPUに載せられるdots.mocrのほうが、処理量に比例する費用を抑えられます。GPUの調達費と1ページあたりの処理時間を自社環境で測り、損益分岐を確かめてください。OCRを業務フローへ組み込む設計から検討する場合は、[当社のAI-OCR導入支援](/service/ai/ocr/)で相談を受け付けています。

## vLLMでのモデルサーバー起動とPDF一括変換の手順

### GPU要件とvllm serveでの起動

公式が推奨するのはvLLMでの推論です。vLLMは0.11.0からdots.ocr系のアーキテクチャを本体に取り込んでおり、2026年10月5日公開の0.31.0でもDotsOCRForCausalLMが登録されています。必要なVRAMは公式に明記されていません。重みだけでBF16の5.66GiBを使い、画像トークン分のKVキャッシュがこれに加わります。オンラインチュートリアルを提供するHyperAIはRTX 5090（32GB）で動かしています。

最初にPython 3.12の環境を作り、リポジトリを取得してパッケージを入れます。parser.pyと前章のスクリプトは、この環境から実行します。

```
conda create -n dots_mocr python=3.12
conda activate dots_mocr
git clone https://github.com/studio-dots-ai/dots.mocr.git
cd dots.mocr
pip install -e .
```

```
# vLLMのモデルサーバーを起動する
CUDA_VISIBLE_DEVICES=0 vllm serve dots-studio/dots.mocr \
  --tensor-parallel-size 1 \
  --gpu-memory-utilization 0.9 \
  --chat-template-content-format string \
  --served-model-name model \
  --trust-remote-code
```

`--served-model-name model`はdots.mocrのREADMEの起動例には無く、前身のdots.ocrのREADMEには書かれています。これを足しているのは、parser.pyがモデル名の既定値をmodelにしているためです。検証用サーバーで確かめたところ、parser.pyは実際にmodelという名前でリクエストを送っていました。このフラグを付けずに起動するとモデルはリポジトリ名で提供され、変換がモデル未検出で失敗します。サーバー側を変えたくない場合は、parser.pyに`--model_name dots-studio/dots.mocr`を渡しても同じ結果になります。依存関係で詰まる場合は、公式が案内するvLLMのDockerイメージ（vllm/vllm-openai:v0.17.1）を使う方法もあります。vLLM自体の仕組みは[vLLMとは？PagedAttentionの仕組み・使い方とOllama・TensorRT-LLMとの違いを実装者目線で解説](/tech/details/15786/)にまとめています。

### parser.pyでのPDF変換と出力ファイル

```
# 単一PDFを変換する（ページ数が多いときはスレッド数を上げる）
python3 dots_mocr/parser.py demo/demo_pdf1.pdf --num_thread 64

# レイアウト検出だけを行う
python3 dots_mocr/parser.py demo/demo_image1.jpg --prompt prompt_layout_only_en

# ヘッダとフッタを除いた本文テキストだけを取り出す
python3 dots_mocr/parser.py demo/demo_image1.jpg --prompt prompt_ocr
```

PDFを渡すと、ページごとにレイアウト情報のJSON、Markdown、ヘッダとフッタを除いたMarkdown（\_nohf.md）、検出枠を描いた画像の4種類が出力されます。PDFは既定の200dpiで画像化されます。注意したいのは、モデルの出力がJSONとして読めなかったページです。parser.pyは結果に`filtered: true`を付け、JSONファイルには生の応答文字列を保存します。座標付きの構造は失われるので、大量に流したあとは出力の一覧（拡張子.jsonl）でfilteredのページを数え、再実行してください。1ページの出力上限は既定で16,384トークンです。

### Transformersで動かすときのディレクトリ名の制約

vLLMを使わずTransformersだけで動かす場合は、同じparser.pyのコマンドに`--use_hf true`を付けます。推論はvLLMより遅く、検証や少量処理向けです。踏みやすいのが重みの保存先のディレクトリ名で、公式は「パスにピリオドを含めない」と明記しています。dots.mocrではなくDotsMOCRのような名前にしないと読み込みに失敗します。GPUを用意する前に挙動だけ確かめたいなら、公式のオンラインデモ（dotsocr.xiaohongshu.com）が2026年10月14日時点で公開されています。

## MITと追加規約の二重構造で決まる商用利用の条件

ライセンスはMITですが、リポジトリには「[dots.mocr LICENSE AGREEMENT](https://github.com/studio-dots-ai/dots.mocr/blob/master/dots.mocr%20LICENSE%20AGREEMENT)」が同梱され、追加の条件を定めています。両者が矛盾する場合はMITが優先します。商用利用そのものは認められており、実務で確認が要るのは次の5点です。

- 著作権で保護された出版物の無許可のデジタル化と、コンテンツの大量収集は禁止
- GDPRやHIPAAが保護する機微な個人データの処理は、同意や適法根拠と匿名化措置がない限り禁止
- 改変した重みや微調整済みモデルを配布する場合は「Built with dots.mocr.」の表示が必須
- 準拠法は中華人民共和国法で、紛争は杭州仲裁委員会の仲裁で解決
- 法令変更で規約が改訂された場合は新版へ移行する義務があり、期限は条文上`[e.g., ninety (90)] days`と雛形の表記のまま

重みを配布せずAPIとして提供する形態は、追加規約の第2.4条で規約の適用外とされ、権利者が別に定めるAPI利用条件に従います。社内文書の処理に使う分には障壁になりにくい内容ですが、契約審査では準拠法と仲裁地が論点になりやすいので、導入判断の前に法務へ共有しておくと手戻りを防げます。同じ観点でOSSの文書解析ツールを比べるなら、[MinerUとは？PDFをMarkdownに変換するOSS文書解析ツールの使い方](/tech/details/6505/)や[Marker（marker-pdf）の使い方｜PDFをMarkdownに変換する手順と商用ライセンス【2.0.0対応】](/tech/details/12109/)も参考になります。

## よくある質問

### dots.ocr 1.5とdots.mocrは同じモデルですか？

同じモデルです。dots.ocr-1.5は2026年2月16日にこの名前で公開され、3月19日にdots.mocrへ改称されました。公式のHugging Faceからdots.ocr-1.5の名前の重みは削除されており、同名で見つかるリポジトリは第三者の再アップロードです。公式に入手できるのはdots.mocrと、SVG変換に特化したdots.mocr-svgの2つです。

### dots.mocrのGitHubとHugging Faceはどこですか？

GitHubはstudio-dots-ai/dots.mocr、Hugging Faceはdots-studio/dots.mocrです。公開時のrednote-hilabのURLも転送で新しい場所に届きますが、スクリプトに書くなら新しいIDにしてください。前身のdots.ocrも同じ組織のstudio-dots-ai/dots.ocrにあります。

### GPUなしで試せる方法はありますか？

ブラウザで試すなら公式のオンラインデモが使えます。手元で動かす場合、公式はCPU推論の手順を参考情報として案内していますが、推奨構成ではありません。BF16の重みだけで5.66GiBあり、公式が案内する手順（dots.ocr向けのissueコメント）でも「非常に遅い」と注記されているため、検証用と考えるのが妥当です。継続して処理するならGPUを用意するか、Mistral OCR 4.1のような従量課金のAPIを検討してください。

### 日本語の帳票を撮影した画像でも使えますか？

使えますが、精度は下がります。MDPBenchではデジタル文書90.5点に対し撮影文書は77.2点で、13.3ポイントの差があります。日本語と撮影を掛け合わせたスコアは公開されていないため、導入前に自社の実画像で精度を測ってください。

### 商用サービスに組み込めますか？

組み込めます。MITライセンスに加えて追加規約があり、無許可の出版物のデジタル化や、適法根拠のない機微な個人データの処理が禁止されています。改変した重みを配布する場合は「Built with dots.mocr.」の表示が必要です。重みを配布せずAPIとして提供する形態は追加規約の適用外となるため、提供形態によって確認すべき条項が変わります。

## 関連記事

- [OCRとは？光学文字認識の仕組み・種類・精度と実装での組み込み方を解説](/tech/details/13582/)
- [GLM-OCRとは？0.9Bの実体と日本語精度・vLLM/Ollama導入手順とAPI料金](/tech/details/10872/)
- [DeepSeek-OCRとは？光学圧縮の仕組みとOCR 2との違い・使い方・API](/tech/details/9455/)
- [Mistral Document AI 2512とは？OCR 3との関係・料金・Foundryでの使い方](/tech/details/11221/)
- [YomiToku Studioの使い方：4つのワークスペースとPython版・商用利用の条件【v0.15.0】](/tech/details/6169/)

---

出典: [dots.mocrとは？dots.ocrとの違いと日本語精度・vLLM導入手順【2026年10月】](<https://www.issoh.co.jp/tech/details/11776/>)（株式会社一創）