📊

丸投げから役割分担へ ─ VLMを活かすPDF解析の設計

ttaro

2026/02/03に公開

 1. 導入：やりたかったこと私はKENCOPAでAIエージェントの開発業務を担当しています。
今回は、AIエージェントを実装するうえで必要だったVLMによるPDFファイル解析で得た学びを共有します。
SDS（Safety Data Sheet / 安全データシート）と呼ばれるPDFファイルから、化学物質の構成情報を抽出したいと考えていました。
SDSには以下のような情報が記載されています：

物質の親子関係（成分カテゴリと個別成分）

含有量（質量%）

CAS番号（化学物質の国際的な識別番号）
これらの情報は表形式で書かれていることもあれば、文章中に含まれていることもあります。形式は様々で、表のフォーマットも統一されていません。
これらを構造化データ（JSON）に変換し、システムで扱えるようにすることがゴールでした。
「VLMならPDFを画像として渡すだけで、E2Eで解析できるはず」
そう考えて、最新のVLMに丸投げすることにしました。

 2. 最初のアプローチ：VLMにE2Eで丸投げ → 壁にぶつかるVLMにPDFを入力として渡し、「構成情報を解析してJSONで出力して」と指示しました。

 結果検証したところ、8割程度は期待通り構造化できました。しかし、残りの失敗ケースを分析すると、そのほとんどがテーブル構造の認識ミスに起因していることがわかりました。特にマージセルを含むテーブルや罫線がないテーブルで精度が低下していました。

マージセルや罫線なしテーブルの正解例をFew-shotで提示しても、改善は見られませんでした。

 具体的な失敗例SDSのテーブルには、以下のようなマージセルを含む複雑な構造が多く見られます。
元のテーブル(※実際のSDSをもとにしたダミーデータ)
このテーブルには以下の特徴があります：
「含有量」列の「90 以上」が複数行にまたがるマージセル
「CAS 番号」列の「98765-43-2」も複数行にまたがるマージセル
VLM（GPT-5.1）にPDF全体を渡した結果
<tr>
  <td>物質A</td>
  <td>X-Y・A</td>
  <td>90 以上</td>           <!-- ここにしか値がない -->
  <td>(1)-123</td>
  <td>12345-67-8<br>98765-43-2</td>
</tr>
<tr>
  <td>物質B</td>
  <td>Z-W・B</td>
  <td></td>                  <!-- 空欄になっている -->
  <td>(2)-456</td>
  <td>23456-78-9</td>
</tr>
<!-- 以下同様に空欄が続く -->
PDF全体を渡したVLMの出力結果（HTMLテーブル表示）
問題点：
マージセル（rowspan）が認識されず、「90 以上」が1行目にしか出力されない
2〜4行目の含有量が空欄になり、データの紐付けが崩壊
「98765-43-2」が本来のマージセル位置ではなく、1行目のCAS番号に混入
結果として、どの成分がどの含有量に対応するのか、正しく紐付けられないケースが頻発しました。

 3. 原因分析：VLMの得意・不得意を理解するプロンプトを改善しても安定しない理由を探るため、VLMの特性を調べました。

 VLMは「万能ツール」ではないVLMには明確な得意・不得意があります。

 VLMが得意なこと：意味理解・推論「これは化学物質の表だ」と理解する
曖昧な指示を解釈する
文脈に基づいて推論・判断を行う

 VLMが苦手なこと：グラウンディング（具体的な位置特定）「このセルは座標(x,y)にある」と特定する
「この列は3列目まで結合している」と認識する
正確な座標値を出力する
空間的な位置関係を把握する
!グラウンディング（Grounding）とは？

AIが言葉や概念を、具体的なものや実際の世界と結びつけて理解する能力のことです。
LLMの文脈では、「検索結果を利用して事実に基づいた回答を生成する」という意味で聞いたことがある方も多いかもしれません。
この「グラウンディング」という概念は画像分野でも使われます。画像分析におけるグラウンディング能力の一つは、AIが画像内で「どこに」オブジェクトが配置されているかを正確に特定する能力です。これは空間的な位置関係の理解に関わる基礎的な視覚認識能力であり、VLMが苦手とする領域です。
参考: LLMで"何でも"できる時代のAIエンジニア生存戦略 - Algomatic Tech Blog

 4. 設計判断：タスクを得意・不得意で分類する
 SDS解析タスクの分解今回のタスクを、VLMの得意・不得意に照らして分類してみました。


タスク
分類
適したモデル


テーブル領域の検出
グラウンディング
専門モデル

セル境界の特定
グラウンディング
専門モデル

マージセルの構造把握
グラウンディング
専門モデル

「これは成分表だ」と理解
意味理解・推論
VLM

親子関係の推論
意味理解・推論
VLM

JSON構造への変換
意味理解・推論
VLM

結論：テーブル構造の認識（グラウンディング）は専門モデルに任せ、意味の解釈と最終的な構造化はVLMに任せることにしました。

 新しいワークフローPDF画像
    ↓
┌─────────────────────────────┐
│ 専門モデル: テーブル構造認識 │  ← 追加
└─────────────────────────────┘
    ↓
構造化されたテーブルデータ（HTML/Markdown）
    ↓
┌─────────────────────────────┐
│ VLM: 意味解釈・JSON変換      │
└─────────────────────────────┘
    ↓
JSON
専門モデルがグラウンディング（セル境界・マージセル構造の特定）を担当し、VLMはその結果を受けて意味解釈に専念します。

 5. ツール選定：Markerの採用テーブル構造認識の専門モデルとして、Markerを採用しました。
https://github.com/datalab-to/marker
選定理由：
マージセル・罫線なしテーブルへの対応精度が良好
日本語対応
OSSで自社インフラ運用が可能

 Marker READMEで比較されているツール（表構造 + 運用面）MarkerのREADMEでは、代表的な変換系ツール（LlamaParse / Mathpix / Docling）と比較ベンチマークが公開されています。ここでは記事向けに、意思決定で効きやすい 「表構造」 と 「運用面」 に絞って要点を整理します。

 変換品質と速度（Overall PDF Conversion）

ツール
形態
平均処理時間（秒）
品質（LLM Score）


Marker
OSS（ローカル）
2.838
4.239

LlamaParse
Cloud API
23.348
3.976

Mathpix
Cloud API
6.362
4.156

Docling
OSS（ローカル）
3.699
3.704

※ Marker READMEの「Benchmarks / Overall PDF Conversion」より抜粋。LlamaParse / Mathpix は各社のクラウドサービス、Marker / Docling は同一GPU環境での計測として記載されています。

 表構造（Table Conversion / FinTabNet Avg score）

構成
位置づけ
表構造スコア（Avg score）


Marker
OSS（ローカル）
0.816

Marker + --use_llm

OSS + LLM（Hybrid）
0.907

Gemini（単体）
LLM
0.829

今回は使用しませんでしたが、Markerの --use_llm は「ページ跨ぎの表のマージ」「表の整形」などの後処理を担わせる設計で、Marker単体よりも「Marker + LLM」の方が表構造が安定することが示されています。

 運用面（ざっくり）OSS（Marker / Docling）

ローカル実行でき、機密データの扱い・コスト最適化・バッチ処理などを自前で設計しやすい。一方で、GPU/CPUリソース・実行基盤・モデル更新追従など運用設計は必要。
Cloud API（LlamaParse / Mathpix）

API統合だけで導入しやすく、スケールも任せやすい。一方で、データ持ち出し要件、従量課金、ベンダーロック、レイテンシなどを設計で吸収する必要がある。

 この分野は進化が速い（Chandra / DeepSeek-OCR など）この領域の進化はとても早く、datalab-to だけを見ても Markerに続き、複雑な文書（手書き・表・数式・フォームなど）でのOCRとレイアウト保持を前面に出した Chandra が公開されています。

さらに業界全体でも、2025年後半に DeepSeek-OCR のような新しいOCR系モデルが登場しており、単なる「文字起こし」だけでなく「構造の読み取り」までを含めて、選択肢が短期間で入れ替わる状況になっています。

 6. 結果と学び
 結果：VLM vs Markerの比較同じテーブルに対して、VLM（GPT-5.1）とMarkerの出力を比較しました。
Markerの出力
<tr>
  <td>物質A</td>
  <td>X-Y・A</td>
  <td rowspan=5>90 以上</td>    <!-- マージセルを正しく認識 -->
  <td>(1)-123</td>
  <td>12345-67-8</td>
  <td rowspan=5>98765-43-2</td> <!-- こちらも正しく認識 -->
</tr>
<tr>
  <td>物質B</td>
  <td>Z-W・B</td>
  <!-- rowspanにより含有量・CAS番号は上のセルに結合 -->
  <td>(2)-456</td>
  <td>23456-78-9</td>
</tr>
Markerの出力結果（HTMLテーブル表示）
VLMでは空欄になっていた「含有量」と「CAS番号」が、rowspan属性により正しく認識されています。これにより、どの成分がどの含有量に対応するのか、正確に紐付けられるようになりました。
結果として：
テーブル構造認識を専門モデル（Marker）に分離
VLMは構造化されたデータを受け取り、意味解釈とJSON変換に専念
全体として精度が向上し、結果が安定しました

 得られた学び1. VLMには明確な得意・不得意がある
VLMは意味理解・推論が得意な一方、グラウンディング（位置特定・空間認識）は苦手です。この特性を理解しておくことで、失敗時の原因分析がしやすくなります。
2. タスクを分解し、適材適所で役割分担する
「VLMが苦手な部分」を見極める
その部分は専門モデルに任せる
VLMは得意な領域（意味解釈・推論）に専念させる
3. まずVLMで試し、失敗パターンから役割を分離する
最初にVLMでE2Eを試すのは有効なアプローチ
失敗ケースを分析し、VLMの苦手な部分を特定する
特定できたら、その部分を専門モデルに段階的に切り出す

 補足：別のアプローチ — テーブル検出+クロップ → VLM本記事では「テーブル構造認識まで専門モデルに任せる」アプローチを採用しましたが、別の手法も提案されています。
テーブル検出とクロップまでを専門モデルで行い、構造認識はVLMに任せるというアプローチです。
QunaSysのブログ記事では、Table TransformerでPDFからテーブル領域を検出・クロップし、その画像をGPT-4Vに渡す手法が紹介されています。
ただ、PDF1ページ分の画像をそのままGPT-4Vに解析させても精度はあまり良くないようで、後述するTable Transformerを使って表部分の画像のみ抽出してから解析を行うことで、より良い結果が得られた
— Table TransformerとGPT-4Vを用いたPDF内の表の解析 - QunaSys (2024)

 参考：クロップ画像をVLMに渡した場合今回のテーブルをクロップした画像でVLM（GPT-5.1）に処理させた結果も参考として示します。
<tr>
  <td>物質A</td>
  <td>X-Y・A</td>
  <td rowspan="5">90 以上</td>  <!-- マージセルを認識！ -->
  <td>(1)-123</td>
  <td>12345-67-8</td>           <!-- ただし98765-43-2が欠落 -->
</tr>
クロップ画像を渡したVLMの出力結果（HTMLテーブル表示）
クロップにより「90 以上」のマージセルは認識できるようになりましたが、右端の「98765-43-2」は依然として欠落しています。Markerでは両方とも正しく認識できていました。

 なぜクロップするとVLMの精度が上がるのか

要因
説明


実効解像度の向上
ページ全体を固定サイズに縮小すると、テーブル部分の解像度が下がります。クロップすると同じ入力サイズでもテーブルがより多くのピクセルを占めます

ノイズの除去
周囲のテキストや図表がVLMの注意を分散させます。クロップで対象以外を除去できます

タスクの単純化
「テーブルを探す」というグラウンディングタスクが不要になり、構造認識に専念できます

このアプローチは、シンプルなテーブルであれば有効な選択肢になります。今回は比較検証を十分に行っていませんが、役割分担の粒度として選択肢になりうると考えています。

 まとめVLMは非常に強力ですが、「何でもできる万能ツール」ではありません。
特にグラウンディング（具体的な位置特定・空間認識）が求められるタスクでは、専門モデルとの役割分担が有効です。
今回のSDS解析では、「テーブル構造認識」というグラウンディング寄りのタスクをMarkerに任せ、「意味解釈・JSON変換」という意味理解・推論寄りのタスクをVLMに任せることで、安定した精度を実現できました。
VLMを使う際は、タスクを「意味理解・推論」と「グラウンディング」に分解し、それぞれに適したツールを選ぶ視点を持つと良いかもしれません。

 参考文献
Table TransformerとGPT-4Vを用いたPDF内の表の解析 - QunaSys (2024)

LLMで"何でも"できる時代のAIエンジニア生存戦略 - LLMのグラウンディング能力について (Algomatic Tech Blog 2025)
Marker - GitHub
Chandra - GitHub
DeepSeek-OCR - GitHub

OCR技術の変遷と日本語対応モデルの性能検証 - LayerX（日本語OCRの世代交代・評価観点の整理があり、「技術進化が早い」背景の把握に使用）

タスク	分類	適したモデル
テーブル領域の検出	グラウンディング	専門モデル
セル境界の特定	グラウンディング	専門モデル
マージセルの構造把握	グラウンディング	専門モデル
「これは成分表だ」と理解	意味理解・推論	VLM
親子関係の推論	意味理解・推論	VLM
JSON構造への変換	意味理解・推論	VLM

ツール	形態	平均処理時間（秒）	品質（LLM Score）
Marker	OSS（ローカル）	2.838	4.239
LlamaParse	Cloud API	23.348	3.976
Mathpix	Cloud API	6.362	4.156
Docling	OSS（ローカル）	3.699	3.704

構成	位置づけ	表構造スコア（Avg score）
Marker	OSS（ローカル）	0.816
Marker + `--use_llm`	OSS + LLM（Hybrid）	0.907
Gemini（単体）	LLM	0.829

要因	説明
実効解像度の向上	ページ全体を固定サイズに縮小すると、テーブル部分の解像度が下がります。クロップすると同じ入力サイズでもテーブルがより多くのピクセルを占めます
ノイズの除去	周囲のテキストや図表がVLMの注意を分散させます。クロップで対象以外を除去できます
タスクの単純化	「テーブルを探す」というグラウンディングタスクが不要になり、構造認識に専念できます

株式会社KENCOPA テックブログPublication

KENCOPAは、建設業界特化のAIエージェントの提供と共同開発・研究を通じて、多様なニーズに応じた柔軟な施工管理特化AIを提供します。

1. 導入：やりたかったこと

2. 最初のアプローチ：VLMにE2Eで丸投げ → 壁にぶつかる

結果

具体的な失敗例

3. 原因分析：VLMの得意・不得意を理解する

VLMは「万能ツール」ではない

VLMが得意なこと：意味理解・推論

VLMが苦手なこと：グラウンディング（具体的な位置特定）

4. 設計判断：タスクを得意・不得意で分類する

SDS解析タスクの分解

新しいワークフロー

5. ツール選定：Markerの採用

Marker READMEで比較されているツール（表構造 + 運用面）

変換品質と速度（Overall PDF Conversion）

表構造（Table Conversion / FinTabNet Avg score）

運用面（ざっくり）

この分野は進化が速い（Chandra / DeepSeek-OCR など）

6. 結果と学び

結果：VLM vs Markerの比較

得られた学び

補足：別のアプローチ — テーブル検出+クロップ → VLM

参考：クロップ画像をVLMに渡した場合

なぜクロップするとVLMの精度が上がるのか

まとめ

参考文献

Discussion