dots.mocrとは？83.9点の実力と日本語精度・導入手順【2026年9月】

dots.mocrは、文書のテキストとチャートやUIなどのグラフィクスを1つのモデルで解析し、図版をSVGコードとして出力するオープンソースのOCRモデルです。2026年3月19日に公開され、文書解析ベンチマークのolmOCR-Benchで総合83.9点を記録しました。公式が公開した比較表では、掲載されたモデルのうち最も高い総合値です。本記事では2026年9月6日時点の公式リポジトリと評価データをもとに、スコアの内訳、日本語文書での実測値、他モデルとのコスト差、vLLMでの導入手順、ライセンス条件を整理します。公開直後から変わった点として、配布元のアカウント名が移行しています。

まとめ：dots.mocrの要点と2026年9月時点の入手先

• 配布元はGitHubがstudio-dots-ai、Hugging Faceがdots-studio。公開当初のrednote-hilabは転送で解決する
• パラメータ数は30億4千万、BF16の重みは5.66GiB。前身のdots.ocrと同一サイズで必要GPUメモリは変わらない
• olmOCR-Bench総合83.9点でdots.ocrから4.8ポイント改善。ただし劣化スキャン文書は48.2点にとどまる
• 日本語はMDPBenchで75.0点。英語87.4点とは12.4ポイント、中国語84.6点とは9.6ポイントの差がある
• ライセンスはMITに追加規約が重なる二重構造で、準拠法は中国法、紛争解決は杭州仲裁委員会

自前GPUを持つ環境で日中英の文書を大量に処理するなら、商用APIより桁で安く回せる水準に達しています。以降で、スコアの内訳と導入手順、判断が分かれる条件を具体的に見ていきます。

dots.ocrの後継としての位置づけと配布元アカウントの変更

rednote-hilabからdots studioへ移行した公式リポジトリと旧URLの転送

公開時の配布元はrednote-hilabでしたが、2026年9月6日時点でGitHubはstudio-dots-ai、Hugging Faceはdots-studioに変わっています。旧パスは転送が有効で、GitHubは301、Hugging Faceは307で新しいパスへ解決するため、READMEに残る旧表記のコマンドはそのまま動作します。ただしDockerfileやデプロイスクリプトに旧IDを固定している場合、転送に依存し続けるより新IDへ書き換えるほうが安全です。組織名は「dots studio」で、小紅書（RedNote）のモデル研究組織にあたります。ライセンス文書に記載された権利者は行吟信息科技（上海）有限公司、脆弱性の報告先も小紅書のドメインのままで、運営主体そのものは変わっていません。

dots.ocrと重みサイズが同一という実態と「dots.ocr-1.5」という呼称

前身のdots.ocrは2025年7月30日公開で、レイアウト検出と文字認識を単一の視覚言語モデルに統合した点が評価されました。よく見かける「1.7B」は言語モデル部分だけを指した数字で、ビジョンエンコーダを含む全体では30億4千万パラメータです。Hugging Faceが公開する重みのメタデータでは、dots.mocrとdots.ocrはいずれも3,039,179,264パラメータで完全に一致し、重みファイルの合計サイズも同じ5.66GiBです。つまりdots.mocrへの移行でGPUメモリ要件が増えることはなく、変わったのは学習データと出力できる形式のほうです。config.jsonのアーキテクチャ識別子もDotsOCRForCausalLM、model_typeもdots_ocrと据え置かれており、推論スタック側の互換性はこの点で保たれています。デコーダはhidden_size 1536の28層、ビジョンエンコーダは42層です。

検索でよく見かける「dots.ocr 1.5」については、LlamaIndexのParseBenchにdots_ocr_1_5_parseというパイプライン名で結果が登録されており、公開直前にこの名で扱われていた形跡が残っています。ただし公式リポジトリにdots.ocr-1.5というリリースは存在せず、入手できるのはdots.mocrとdots.mocr-svgの2つです。このほか2025年10月31日には、OCRタスク向けの基盤モデルdots.ocr.baseも公開されています。技術的な背景は論文「Multimodal OCR: Parse Anything from Documents」（arXiv:2603.13032、2026年3月13日投稿）にまとまっています。OCRの基礎から整理したい場合はOCRとは？光学文字認識の仕組み・種類・精度と実装での組み込み方を解説も参照してください。

olmOCR-Bench 83.9点の内訳と日本語文書での実測値

表組み90.7点と旧スキャン48.2点に分かれる得意・不得意

olmOCR-Benchは1,403件のPDFと7,010件のテストケースで構成される評価セットです。dots.mocrの総合は83.9点で、前身のdots.ocrの79.1点から4.8ポイント改善しました。以下は公式リポジトリが公開する内訳で、開発元の内部評価を含む値です。

伸びが最も大きいのは旧スキャンの数式で21.3ポイント改善しています。一方、劣化したスキャン文書そのものは48.2点にとどまり、最も高いヘッダ・フッタの94.0点とは45.8ポイント、次に低い微小文字の81.6点と比べても33.4ポイント低い水準です。紙の劣化した文書が主対象なら、この数字を前提に人手の校正工程を残す設計が要ります。

MDPBenchの日本語75.0点が示す言語別の差

日本語の実力は公式READMEには載っておらず、モデルリポジトリに同梱された評価結果ファイルにMDPBenchのスコアが記録されています。2026年7月3日時点で総合80.5点、言語別では英語87.4点、イタリア語89.3点、中国語84.6点に対し、日本語は75.0点です。ロシア語71.2点、フランス語70.1点よりは高いものの、英語とは12.4ポイント、中国語とは9.6ポイントの差があります。縦書きやルビを含む和文の帳票では、この差がそのまま後工程の修正量に効いてきます。日本語文書だけを扱う用途なら、和文特化のエンジンと比較したうえで選ぶほうが確実で、日本語特化OCR＆文章画像解析エンジン「YomiToku」の概要と魅力が比較の起点になります。

ParseBenchのチャート0.9点と出力形式の前提

同じ評価結果ファイルには、LlamaIndexのParseBenchのスコアも含まれています。平均55.8点で、内訳は本文テキスト90.0点、表85.2点に対し、書式再現47.0点、チャート0.9点です。チャートがほぼゼロなのは能力の欠落ではなく、評価側がMarkdown中のデータ表現を期待するのに対し、dots.mocrはグラフィクスをSVGコードとして返す設計だからです。つまりSVG出力を活かすには受け側の後処理を前提にする必要があり、Markdown一本で完結させたい構成では強みが数字に表れません。RAGの前処理としてMarkdownだけを求めるなら、Marker（marker-pdf）の使い方｜PDFをMarkdown変換する手順と商用ライセンス制約のような変換特化ツールのほうが噛み合います。

PaddleOCR-VL・Mistral OCRとの精度と課金形態の比較

選定で効くのは、モデル規模・olmOCR-Benchの値・課金形態の3点です。スコアは公式リポジトリの比較表に載っている版のもので、後述する最新版の実測値ではありません。

規模あたりの効率で見ると、dots.mocrは3.0BでChandra OCRの8.8Bを上回っています。ただし表のPaddleOCR-VLとMistral OCRはいずれも旧版の値で、現行版は更新が進んでいる点に注意が必要です。

Mistral OCRは価格改定が続いています。最新のOCR 4.1は2026年7月16日提供開始で1,000ページあたり4ドル、注釈付き出力は5ドルです。同じ価格の4.0が2026年6月23日に出ており、2ドルだったのは2世代前のOCR 3（2025年12月18日提供開始）までです。10万ページを月次で流すなら4.1では400ドル前後の従量費が発生します。dots.mocrは重み5.66GiBで単一GPUに載るため、既にGPUを持つ環境なら追加費用は電力と運用工数に収まり、処理量が増えるほど差が開きます。API型との比較はmistral-document-ai-2512の基本仕様と既存OCRモデルとの位置づけの差異も参考になります。

一方でPaddleOCR-VLは0.9Bと約3分の1の規模で80.0点に達し、109言語に対応します。スループット重視や小型GPUでの運用ならこちらが有利です。2026年5月27日には1.6が公開され、更新頻度も高い状態が続いています。同じ0.9B級の選択肢としては0.9BパラメータGLM-OCRが提唱する次世代基準を詳細に、これからのドキュメント処理がどう変わるかも比較対象になります。dots.mocrを選ぶ理由は総合点の高さそのものではなく、図版をSVGコードで受け取れる点にあります。

vLLMサーバー起動からPDF一括変換までの導入手順

GPU要件とvLLMでのモデルサーバー起動

公式が推奨するのはvLLM経由の推論です。バージョン0.11.0以降はdots.ocr系のアーキテクチャがvLLM本体に統合されており、2026年8月26日公開のv0.28.0でもDotsOCRForCausalLMの実装が登録されています。公式ドキュメントにVRAMの要件は明記されていませんが、重みがBF16で5.66GiBのため、画像トークン分のKVキャッシュを見込んでも16GB級のGPU1枚が目安になります。

# 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です。後述するparser.pyは呼び出し先のモデル名の既定値がmodelのため、このフラグを落とすとリポジトリ名で提供され、変換コマンドがモデル未検出で失敗します。依存関係で詰まる場合は、公式が案内するvLLMのDockerイメージを使う方法が確実です。vLLM自体の仕組みとチューニングはvLLMとは？PagedAttentionの仕組み・使い方とOllama・TensorRT-LLMとの違いを実装者目線で解説にまとめています。

parser.pyでのPDF変換とプロンプトの切り替え

サーバーが立ち上がったら、同梱のparser.pyに画像かPDFを渡すだけで変換できます。出力はレイアウト情報を含むJSON、連結後のMarkdown、検出枠を描画した画像の3種類です。

# 単一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

プロンプトの切り替えがそのままタスクの切り替えになる設計で、SVG変換はprompt_image_to_svg、Webページ解析はprompt_web_parsingを指定します。レイアウト検出では、本文・表・数式・図・見出しなど11カテゴリを枠の座標付きで返します。数式はLaTeX、表はHTML、それ以外はMarkdownという出力形式の切り分けもプロンプト側で定義されています。

Transformers利用時のディレクトリ名制約と速度差

Transformersだけで動かす場合は、同じコマンドに--use_hf trueを付けます。vLLMより推論は遅くなるため、公式も検証や少量処理向けと位置づけています。環境構築はPython 3.12のconda環境を作り、リポジトリを取得してpip install -e .を実行する流れです。

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 .

ここで踏みやすい落とし穴が、重みの保存先のディレクトリ名です。公式は「パスにピリオドを含めない」ことを明記しており、dots.mocrではなくDotsMOCRのような名前を使います。Transformers統合が完了するまでの暫定的な制約とされていますが、既定のままモデル名でディレクトリを作ると読み込みに失敗します。GPUを用意する前に挙動だけ確かめたい場合は、公式が dotsocr.xiaohongshu.com でオンラインデモを公開しています。

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

ライセンスはMITですが、リポジトリには「dots.mocr LICENSE AGREEMENT」が同梱され、MITを補う形で追加条件が定められています。両者が矛盾する場合はMITが優先し、MITが沈黙している事項を追加規約が埋める構成です。商用利用そのものは認められている一方、実務で確認が要る条項は次の4点です。

• 著作権で保護された出版物の無断な一括デジタル化、および無断のコンテンツ収集は禁止
• GDPRやHIPAAが保護する機微な個人データの処理は、適法根拠と匿名化措置がない限り禁止
• 改変した重みや微調整済みモデルを配布する場合、「Built with dots.mocr」の表示が必須
• 準拠法は中華人民共和国法、紛争解決は杭州仲裁委員会での仲裁

権利者は行吟信息科技（上海）有限公司です。なお重みを直接配布せずAPIとして提供する形態は、追加規約の第2.4条で適用除外とされ、別途の利用条件に従う扱いになります。日本企業が社内文書の処理に使う分には障壁になりにくい内容ですが、契約審査では準拠法と仲裁地が中国である点が論点になりやすいため、導入判断の前に法務へ共有しておくと手戻りを防げます。ライセンス条件を含めたOSS文書解析ツールの選定は、MinerUとは？PDFをMarkdownに変換するOSS文書解析ツールの使い方との比較でも同じ観点が使えます。

よくある質問

dots.mocrとdots.ocrはどちらを使うべきですか？

新規に導入するならdots.mocrです。olmOCR-Benchの総合が83.9点と79.1点で4.8ポイント高く、旧スキャンの数式では85.5点対64.2点と差が開きます。両者はパラメータ数も重みサイズも同一で、アーキテクチャ識別子も共通のため、GPUを増やすことなくdots.ocrの推論環境をそのまま流用できます。移行時の変更点はモデルIDの差し替えが中心です。SVG出力を使わない用途でも、精度面で据え置く理由は乏しいでしょう。

日本語のPDFでも実用になりますか？

MDPBenchでの日本語スコアは75.0点で、英語87.4点や中国語84.6点より低い水準です。活字中心の帳票や論文であれば実用域ですが、和文特有の縦書き・ルビ・手書き併記が多い文書では修正工数を見込む必要があります。導入前に自社の実文書100ページ程度で精度を測り、日本語特化エンジンと突き合わせてから判断するのが確実です。劣化したスキャン文書は言語を問わず48.2点まで落ちる点も併せて確認してください。

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

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

GPUなしのCPU環境でも動きますか？

公式はCPU推論の手順を参考情報として案内していますが、推奨構成ではありません。BF16の重みだけで5.66GiBあり、CPUでは実用的なスループットが出ないため、検証用と考えるのが妥当です。GPUを用意できない場合は、0.9B規模のPaddleOCR-VLのような小型モデルか、Mistral OCRのような従量課金APIを検討するほうが現実的です。API側は1,000ページあたり4ドルが目安になります。

dots.mocrとdots.mocr-svgはどう使い分けますか？

文書解析が主目的ならdots.mocr、図版のSVG化が主目的ならdots.mocr-svgです。両者は同時に公開されており、公式もSVG変換に最適化した派生モデルとしてdots.mocr-svgを位置づけています。3Bという規模の制約から、本体モデルは複雑なSVG変換で精度が伸びきらない場面があると明記されています。チャートや化学構造式をベクター表現で扱う工程が中心なら、派生モデルを併用する構成が前提になります。

関連記事

• OCRとは？光学文字認識の仕組み・種類・精度と実装での組み込み方を解説
• vLLMとは？PagedAttentionの仕組み・使い方とOllama・TensorRT-LLMとの違いを実装者目線で解説
• 0.9BパラメータGLM-OCRが提唱する次世代基準を詳細に、これからのドキュメント処理がどう変わるか
• Marker（marker-pdf）の使い方｜PDFをMarkdown変換する手順と商用ライセンス制約
• 日本語特化OCR＆文章画像解析エンジン「YomiToku」の概要と魅力