ローカルVLMでPDF・画像をJSON化｜オープンウェイトモデル／OSSツールの選び方と必要VRAM

ローカルVLMとは、画像やPDFを手元のGPUで解析する視覚言語モデル。

社内の資料やスキャン画像の多くは、PDFやスライドの中に閉じたままです。請求書、契約書、報告書。VLMへ直接入力することもできますが、そのままでは検索、集計、データベース登録といった後段処理へつなぎにくい場合があります。そこで役立つのが、必要な情報をJSONやMarkdownなどの構造化された形式へ変換する処理です。

この記事では、外部の推論APIへ文書を送らず、手元のGPUで抽出を完結させる方法を扱います。どのオープンウェイトモデルやOSSツールを選び、VRAMは何GBあれば足りるのか。用途と実行経路を切り分けて判断できる状態を目指します。

PDF・画像をJSON化する2つのアプローチ（スキーマ駆動抽出とドキュメント解析）

「PDFをJSONにする」処理には、大きく分けて2つの主要ユースケースがあります。ここを切り分けないまま作業を始めると、目的に合わないモデルを選んでしまい、時間を無駄にします。最初にどちらを解いているのかをはっきりさせてください。

1つ目がスキーマ駆動抽出。あらかじめ欲しいフィールドを定義し、モデルがその値を埋めていく方式です。2つ目がドキュメント解析。ページのレイアウト、読み順、表、数式を丸ごと再構成し、JSONやMarkdownとして書き出します。前者は「決まった項目を取り出す」、後者は「文書そのものを構造化する」。主目的が違います。もっとも、両方に対応するツールもあるため、完全に二分できるわけではありません。

スキーマ駆動抽出が向くケース（フィールドが事前に決まっている文書）

請求書、フォーム、契約書、領収書。これらは取り出したい項目が最初から分かっています。ベンダー名、PO番号、税額、合計、残高。フィールド名と型をJSONスキーマとして渡せば、モデルはそれに沿った値だけを返します。出力の形が固定されるので、後段のシステムに流し込みやすいのが利点。決まった帳票を大量に処理する用途なら、この方式が素直です。

ドキュメント解析が向くケース（レイアウトごと構造化してRAGに渡す）

一方、何が書かれているか事前に読めない文書もあります。技術資料、論文、雑多なレポート。こうした文書をRAG（検索拡張生成）用のクリーンなコーパスに整えたいなら、ドキュメント解析の出番です。表は表として、数式は数式として、読み順を保ったまま構造化する。項目を指定するのではなく、ページの構造そのものを写し取る作業。用途がRAGやエージェント向けの前処理なら、こちらを選びます。

ローカル運用が効く理由（コストとプライバシー）

なぜわざわざ手元のGPUで動かすのか。理由は2つあります。従量課金の回避と、文書を外に出さずに済むこと。プロプライエタリなAPIは、大量のページを処理すると費用がかさみます。しかも、処理には文書を外部のサーバへ送る前提がついて回る。オープンウェイトのモデルをローカルで動かせば、この2つの制約を同時に外せます。

コスト面（従量課金 vs 手元GPUの固定費）

クラウドの抽出APIは、百万ページ規模になると費用が大きく膨らみます。ページ単価が積み上がる構造だからです。手元のGPUは初期費用こそかかりますが、そのあとは電気代が主なランニングコスト。処理量が読めていて、継続的に回すワークロードほど、固定費側が有利になります。少量のスポット処理ならクラウド、恒常的な大量処理なら手元、という分け方が現実的でしょう。

プライバシー面（オンプレ処理の適用条件と限界）

機密性の高い文書ほど、外部送信を避けたいもの。オープンウェイトをローカルで動かせば、抽出処理の中で文書を外へ送らずに済みます。ただし「ローカル＝外部に一切出ない」と無条件に言い切ることはできません。成立するのは、あくまでローカルのモデルだけで完結させ、外部モデルへの接続やクラウド連携、テレメトリー送信といった機能を無効化した場合に限られます。外部の推論APIやWeb検索機能を併用すれば、その経路からデータは出ていきます。「オフラインで動かせる」ことと「一切送信しない設定にしてある」ことは別物、と押さえておいてください。

スキーマ駆動抽出モデルの選択肢（liftを軸に）

スキーマ駆動抽出の代表格が、Datalab製のlift（lift-pdf）です。DatalabはドキュメントツールのMarkerやSuryaを手がけているチーム。liftはそのチームによる、約9Bクラスのオープンウェイト・ビジョンモデルです。JSONスキーマを渡すと、それに一致するJSONを返します。

liftの構成（Qwen3.5-9Bベース・提供インターフェース）

liftはQwen 3.5をベースにしています。ベースとなったQwen3.5-9BはApache-2.0で2026年3月に公開されたモデル。liftの特徴の一つが、JSON Schemaに沿った構造化出力です。vLLM経路では、対応範囲内のスキーマを推論ランタイムの制約出力へ渡せます。ただし、複雑なスキーマは制約のコンパイルに失敗し、ガードレールがスキップされる場合があります。また、現行のHugging Faceバックエンドは、スキーマをプロンプトへ埋め込んで通常生成する実装です。したがって「すべてのバックエンドとスキーマで、常に妥当なJSONが機械的に保証される」とまでは言えません。実運用では、JSONのパースとスキーマ検証を後段にも置くのが安全です。複数ページの文書もシングルパスで処理し、ページをまたぐ値まで扱えます。

推論バックエンドは2系統です。モデルを同一プロセス内で読み込むHugging Face経路と、OpenAI互換のvLLMサーバへ接続する経路があります。vLLMサーバは別マシンだけでなく、手元のPC上にDockerで起動することもできます。操作インターフェースとして、CLI、Python API、Schema Studioが提供されています。Schema Studioはスキーマを組み立てて挙動を試すための画面です。導入とCLIの基本形は次の通り。

pip install lift-pdf          # 本体
pip install "lift-pdf[hf]"    # Hugging Face バックエンドを使う場合
pip install "lift-pdf[app]"   # Schema Studio (Streamlit) を使う場合

lift_extract input.pdf ./output --schema schema.json --method hf

--method には hf か vllm を指定します。この選択が後述する落とし穴に直結するので、頭の片隅に置いておいてください。

スキーマ制約デコーディングにより、出力が妥当なJSONであることを保証する。
— Datalab lift 公式モデルカードより（Hugging Face: huggingface.co/datalab-to/lift）

ただし、この保証が成立する範囲は、推論バックエンドとスキーマの対応状況に依存します。vLLM経路の制約出力が効くのは対応スキーマの場合で、現行のHugging Faceバックエンドはプロンプト埋め込みの通常生成です。

同じスキーマ駆動のカテゴリには、NuMindによるNuExtract3もあります。こちらは4BのVLMで、構造化抽出とMarkdown変換を1つにまとめた設計。ライセンスがApache-2.0と緩く、liftより小型で商用に載せやすい選択肢です。なお、liftがJSONスキーマを直接渡す設計なのに対し、NuExtract3は出力形式を表すJSONテンプレートを渡す方式で、入力仕様は同一ではありません。

スキーマ設計が精度を分ける（実務トラップの実例）

スキーマ駆動抽出は「単なるOCR」ではありません。文字を読み取るだけでなく、文書を理解して正しい項目に値を割り当てる作業。ここに実務特有の罠が潜みます。たとえば請求書なら、Bill-to（請求先）とShip-to（送付先）を取り違えないこと。小計と税込合計を混同しないこと。値が存在しない欄はnullを返すこと。残高が残っている請求書を「部分支払い＝未払い」として正しく判定すること。どれも、スキーマの切り方と検証ロジックが甘いと崩れます。

つまり精度を決めるのは、モデルの素の力だけではありません。フィールドをどう定義し、例外をどう扱うか。Datalab公表の225文書ベンチマーク（6〜64ページ、約11,000フィールドを採点）では、liftのフィールド精度は90.2%を記録しました。ただし、1文書内の全フィールドを完全に当てる「フルドキュメント精度」は20.9%にとどまります。この数字はベンダー自社公表である点を割り引く必要がありますが、傾向ははっきりしています。項目単位ではかなり当たっても、1文書を丸ごと取りこぼしゼロで抜くのは今も難しい、ということ。完全自動で全項目正確、とは言い切れません。人手の確認工程を前提に組むのが安全です。

ドキュメント解析ツールの選択肢（Marker/Docling/MinerU ほか）

フィールドが決まっていない文書を、レイアウトごと構造化したい。そのときはドキュメント解析ツールを見ます。オープンソースの主な候補を、機能のカテゴリで整理しました。各ツールの正確なVRAMや精度の数値は公開情報が揃っていないため、ここでは役割の粒度で並べます。

Markerは同じくDatalab製で、PDFに加えてPPTX・DOCX・XLSX・HTML・EPUBを受け取り、Markdown・JSON・HTMLへ書き出します。文字検出とレイアウト部分にはSuryaが使われています。Doclingはレイアウト、読み順、表構造の解析に強いツール。MinerUは109言語のOCRに対応し、数式を含む科学文書で力を発揮します。Unstructuredは文書を要素に分割する前処理寄りの役割で、後段の抽出やRAGへの受け渡しを整えます。なお、クラウド型まで含めるなら、LlamaExtractのようなマネージド抽出サービスもあります。ただし、これはAPIキーで使うクラウド型で、ローカルにウェイトを置いて動かすオープンウェイトモデルやOSSツールとは別カテゴリです。まずはこの並びから、用途に合うローカル候補を当たれば十分です。

必要VRAM — 16GB枠で何が動くか

「結局、手元のGPUで動くのか」。ここが一番知りたいところでしょう。速度の実測値から入りたいところですが、当サイトの検証環境（RTX 5080 16GB・RTX 5060 Ti 16GB）はローカルLLMの計測が中心で、lift自体の抽出速度は未取得です。数値を断定する材料がないため、ここは実行経路と量子化の目安からVRAMの当たりをつけます。

9Bクラスを16GBに収める（実行経路ごとに分けて考える）

liftのVRAM要件は、公式のlift-pdf経路とコミュニティGGUF経路を分けて考える必要があります。ここを混ぜると、結論を誤ります。

公式のHugging FaceバックエンドとvLLMランチャーは、現行実装ではBF16でモデルをロードします。コミュニティ変換されたliftのBF16／F16ファイルは18.4GBあり、ウェイトだけで16GBを超えます。そのため、公式のBF16経路について「16GBに全ウェイトを常駐させて動かす」ことはできません（HFバックエンドは device_map=”auto” のため環境によっては一部をCPUへオフロードして起動できる場合がありますが、システムRAM消費と速度低下を伴います）。なお、公式のvLLMランチャーにはT4向けのバッチ設定プリセットもありますが、これはVRAM容量に応じて最大バッチトークン数や同時シーケンス数を調整する設定で、モデル自体はBF16でロードされます。このプリセットの存在だけを根拠に「1枚のT4 16GBへ収まる」とは判断できません。

一方、コミュニティGGUF版では、Q4_K_Mのモデル本体が約5.78GB、Q5_K_Mが約6.64GB、Q8_0が約9.79GBです。別途、画像処理用のmmprojファイルが約0.6〜0.9GB必要になります。さらにKVキャッシュ、画像入力、コンテキスト、ランタイム用の領域が加わりますが、Q4〜Q5であれば16GB GPUへ収まる余地は大きいと考えられます。量子化フォーマットごとの精度とサイズの兼ね合いは、Q4_K_M〜Q8・QATの選び方で整理しています。ファイルサイズがそのままVRAM使用量になるわけではない点は、念のため押さえておいてください。

したがって、正確な結論はこうです。コミュニティGGUF版をllama.cpp系ランタイムで使う場合、4bitなら16GBで動作する可能性が高い。公式lift-pdfのHF／vLLM経路はBF16なので、同じ見積もりは当てはまりません。速度や最大ページ数は未実測のため、実際の文書で確認する必要があります。

16GB級の具体的なGPUなら、RTX 5080（16GB GDDR7、TGP 360W）やRTX 5060 Ti 16GB（16GB GDDR7、TGP 180W）が挙がります。RTX 5060 Ti 16GBは、16GB VRAMを比較的安価に確保できる入口。VRAMだけで言えば、GGUF量子化版のliftを載せる余地は残ります。ただし、RTX 50系は、現行の lift_vllm --gpu プリセット一覧（T4〜RTX 4090・3090）には掲載されていません。これは互換性やサポート認証の一覧ではなく、VRAM容量に応じてバッチ設定を変えるためのコード上の選択肢です。「16GB枠内なのでGGUFの4bit運用で動作見込み」とは言えても、「公式サポート済み」「速度を実測済み」とは書けない、という線引きになります。

画像生成のVRAMとの違い（対比コラム）

同じ「視覚系」でも、画像生成と文書VLMではVRAMを左右する要因が異なります。拡散型画像生成では、モデル規模、精度、解像度、バッチ数、テキストエンコーダやVAEなどがVRAM使用量に影響します。デノイジングのステップ数は主に処理時間へ影響し、ステップごとにVRAMが蓄積するわけではありません。Krea 2のような12B級画像モデルの必要VRAMを扱う話とは、前提が別です。一方、文書VLMでは、モデルのウェイトに加えて、入力ページ数、画像解像度、視覚トークン数、コンテキスト長、出力長などがメモリ使用量を左右します。liftの公式ランチャーにも、全文書のページを1リクエストにまとめ、ページ当たり約1,000トークンを見込むコメントがあり、「VLMは1パスだからページ数によらず軽い」とは言えません。この2つは同じ物差しで並べて断定はできない、と捉えておくのが正確です。

実装の落とし穴と選び方の指針

ここまで来たら、最後にハマりどころと選び方を押さえます。他のガイドがあまり触れない、けれど実務で確実につまずくポイントがあります。

GGUF経路とCLI経路を取り違えない（依存とセットアップの違い）

liftには、Hugging Face上で複数のコミュニティ量子化版（GGUF系）が公開されています。一例として、prithivMLmodsのGGUFリポジトリには12種類の量子化モデルに加え、BF16／F16版と画像処理用のmmprojが用意されています。ここで混同が起きます。lift-pdfのCLI（lift_extract）が扱うのは --method hf|vllm、つまりHugging FaceバックエンドかvLLMサーバです。GGUF量子化版は、それとは別のランタイム経路。llama.cpp系のツールで動かすものです。同じ「lift」の名前でも、依存パッケージも重みの取り回しもセットアップも別物になります。さらに、GGUF版をllama.cppやOllamaへ読み込んだだけでは、lift-pdfのスキーマ制約出力が自動的に有効になるわけではありません。妥当なJSONを強制したい場合は、利用するランタイム側でJSON Schemaやgrammarなどの構造化出力機能を別途設定する必要があります。

用途からモデル・ツールを逆引きする

選び方はシンプルに整理できます。取り出したいフィールドが事前に決まっているなら、スキーマ駆動抽出。liftかNuExtract3を軸に、商用要件やモデルサイズで絞ります。文書の構造そのものをRAG用に整えたいなら、ドキュメント解析。Marker、Docling、MinerUから、対応形式やOCR言語で選びます。ここでカテゴリを取り違えると、そもそも解けない問題に良いモデルを当てることになる。まず「項目抽出か、フルページ変換か」を決めるのが先です。

ライセンスの確認も忘れずに。liftのコードはApache-2.0ですが、モデルウェイトには改変OpenRAIL-M条件があります。ライセンス本文では、前年売上または累計資金調達額が500万ドルを超える組織について、個人利用・研究目的を除く利用が制限されています。また、Datalabまたは関連会社の製品・サービスと競合する用途にも使用できません。加えて、モデルや出力の利用に関する帰属表示と、モデル・派生物・出力などへの同一ライセンス適用を求めるShare-Alike条項も含まれます。公式READMEには商用セルフホストにはライセンスが必要との記載もあるため、業務システムへの導入時はDatalabへの確認と法務チェックを前提にしてください。NuExtract3はApache-2.0で提供されており、ライセンス条件の単純さを重視する場合はこちらが候補になります。

なお、JSON化はゴールではなく入口です。抽出したJSONは、その先でマルチモーダルRAGに載せて、テキスト・表・数式・画像を横断検索する、といった下流工程につながっていきます。どのモデルで抜くかは、その後の使い方から逆算しても構いません。ローカルLLMを初めて触る段階なら、姉妹サイトの入門解説（ローカルLLMとは？Ollama × Gemma 4でコードを外に出さず使うAI環境）で土台を掴んでから戻ってくると、VRAMの話が読みやすくなります。コーディング用途のローカルLLM実測は、当サイトのqwen3-coder検証記事でも別途扱っています。

文書の構造化とは逆に、ローカルVLMでデスクトップ操作そのものを自動化する場合は、OmniParserのような前処理で視覚トークンの負荷を抑える工夫が要ります。

まとめ

PDF・画像のJSON化は、まず2系統の切り分けから始めます。フィールドが決まっているならスキーマ駆動抽出（lift／NuExtract3）、文書ごと構造化するならドキュメント解析（Marker／Docling／MinerU）。両方に対応するツールもあります。次にVRAM。ここは実行経路で分けて考えます。公式のlift-pdf経路（HF／vLLM）は現行実装がBF16で、コミュニティ変換のBF16／F16は約18.4GBあるため、16GB GPUへ全ウェイトを常駐させることはできません（HFバックエンドは環境によりCPUオフロードで起動できる場合がありますが、RAM消費と速度低下を伴います）。一方、コミュニティGGUF版のQ4〜Q5なら、mmprojを加えてもKVキャッシュやランタイム用メモリを残せる容量構成で、16GB GPUで動作する可能性が高いと見込めます（ページ数やコンテキスト設定を含めた実測確認は必要）。この2経路を混同しないことが肝心です。最後に経路の選択。GGUF量子化版とlift-pdf CLIは別ランタイムなので、どちらで動かすかを先に決める。速度の実機数値はモデルと環境で変わるため、最終判断は自分の文書とGPUで一度回して確かめてください。

よくある質問

Q. VRAM 16GBでローカルの抽出モデルは動きますか？

コミュニティのGGUF量子化版（Q4〜Q5）を使えば、9Bクラスのliftも16GB級GPUで動かせる見込みがあります。一方、公式のlift-pdf経路（HF／vLLM）は現行実装がBF16で、コミュニティ変換のBF16／F16は約18.4GBあるため、16GB GPUへ全ウェイトを常駐させることはできません（HFバックエンドは環境によりCPUオフロードで起動できる場合がありますが、RAM消費と速度低下を伴います）。両経路で前提が違う点に注意してください。実測速度は環境依存のため、実際の文書で確認を。

Q. スキーマ駆動抽出とドキュメント解析、どちらを選べばいいですか？

取り出したい項目が事前に決まっているなら、スキーマ駆動抽出（lift／NuExtract3）。請求書や契約書のような定型帳票が対象です。文書の構造ごとJSON/Markdown化してRAGに渡したいなら、ドキュメント解析（Marker／Docling／MinerU）。カテゴリを取り違えると、モデルが良くても目的を満たせません。両方に対応するツールもあります。

Q. ローカル運用ならデータは絶対に外部へ出ませんか？

無条件では言い切れません。外部へ出さずに済むのは、ローカルのモデルだけで完結させ、外部モデルへの接続やクラウド連携、テレメトリーを無効化した場合です。外部の推論APIやWeb検索機能を併用すれば、その経路からデータは出ていきます。「オフラインで動く」ことと「送信しない設定にした」ことは別々に確認する必要があります。

Q. GGUF版とCLI（lift-pdf）版は何が違いますか？

標準の実行環境が別です。lift-pdfのCLI（lift_extract）はHugging FaceかvLLMバックエンドを使い、–method hf|vllm で指定します。lift_extract自体にGGUFファイルを直接読み込む機能はありません。一方、コミュニティのGGUF量子化版は、llama.cpp・Ollama・LM Studioで動かすもので、依存やセットアップが異なるうえ、スキーマ制約出力を別途設定しないと有効になりません。基本は経路を分けて考えるのが安全ですが、lift-pdfのvLLMバックエンドはOpenAI互換API接続なので、互換サーバとして起動したGGUFモデルへ接続できる可能性はあります（公式の標準構成ではなく、視覚入力・レスポンス形式・スキーマ制約の互換性は個別検証が必要）。

参考資料

• Datalab lift 公式モデルカード（Hugging Face: datalab-to/lift）
• Qwen3.5-9B 公式モデル（Hugging Face, Qwen）
• NVIDIA GeForce RTX 5080 公式仕様
• GeForce RTX 50 series 仕様一覧（RTX 5060 Ti 16GB 参照）