試してきた神（方眼紙）エクセル解析を比較してみる。
1. 動機
帳票とか複雑なテキストの表は、企業の中ではよく見かけるのではないでしょうか。そこで、「方眼紙エクセル」からの構造化データ抽出について、２つの手法を作ってみていました。それらをそれなりに統合的にパースしたら楽できるなと基本的なお勉強をしてきました。その途中で作成した docling-markdown-generator (IBMのdoclingを使ったmarkdownによる再現) と kami_excel_extractor (VLM/LLMを使った情報抽出) を比較しました。
これまで、なんとなく、ポチポチとdebugしていましたが、それぞれの特徴があります。これらを使って簡単に評価してまとめてみます。
github.com
github.com
2. 評価手法
- 対象: 7カテゴリのダミー方眼紙エクセルファイル
- 手法 A:
docling (docling-markdown-generator)
- 手法 B:
kami (kami_excel_extractor)
- モデル B-1:
gemini-3.1-flash-lite-preview (Googleさんのgemini API)
- モデル B-2:
ollama/gemma4:latest (ローカルLLM/Ollamaなので量子化モデル)
ダミーモデル達を適当に生成して使いました。
| # |
ファイル名 |
カテゴリ |
難易度 |
特徴 |
| 1 |
01_simple_table.xlsx |
単純表形式 |
★☆☆ |
通常のヘッダー+データ行（セル結合なし） |
| 2 |
02_houganshi_form.xlsx |
方眼紙レイアウト |
★★☆ |
細かいセル結合で構成された「申請書」 |
| 3 |
03_complex_report.xlsx |
複合帳票 |
★★★ |
ヘッダー情報 + 経費明細表 + 承認欄が混在する複雑な構成 |
| 4 |
04_chart_data.xlsx |
グラフ付き |
★★★ |
月別売上データ + 埋め込み棒グラフ |
| 5 |
05_multi_sheet.xlsx |
マルチシート |
★★☆ |
複数シート（社員一覧・部署別集計・注記）のデータ参照 |
| 6 |
06_extreme_merge.xlsx |
極端な結合 |
★★★ |
100列×50行の組織図風で不規則かつ大量のセル結合 |
| 7 |
07_styled_invoice.xlsx |
スタイル重視 |
★★☆ |
罫線の太さ・背景色・フォントで視覚的に区分けされた請求書 |
3. 比較
3.1 抽出結果の具体例（03_complex_report の場合）
「複合帳票 (03_complex_report.xlsx)」の実際の抽出結果の一部を例として挙げます。
手法 A (Docling) の出力
Doclingは罫線を基準に表を認識するため、独立した複数のHTMLテーブルとして断片的に出力させています。データの関連性や帳票の階層構造は、こんなものでしょう。
<table><tbody><tr><th colspan="5">株式会社 経費報告書</th></tr></tbody></table>
<table><tbody><tr><th>項番</th><th>日付</th><th>摘要</th><th>金額</th><th>備考</th></tr></tbody></table>
<table><tbody><tr><th>合計</th></tr></tbody></table>
<table><tbody><tr><th colspan="2">課長</th><th colspan="2">部長</th><th colspan="2">承認</th></tr></tbody></table>
手法 B-1 (Kami + Gemini 3.1 Flash-Lite Preview) の出力
kamiは視覚的特徴（スタイル）とVLMによる意味理解を組み合わせています。ヘッダー、明細行、合計式、承認欄などの「帳票の論理構造」を正確にJSONとして抽出できました。また、不要な空白行（空のセルの連続）を自動的にフィルタリングしているので見やすい結果ですね。計算式は蛇足かもしれませんが、「合計」という表現を補足できるように抽出させています。
{
"title": "株式会社経費報告書",
"table_data": {
"headers": ["項番", "日付", "摘要", "金額", "備考"],
"rows": [], // 不要な空白行は文脈を読んで自動で省略される
"summary": {
"label": "合計",
"value": 0,
"formula": "=SUM(D8:D25)"
}
},
"approval_fields": {
"section_manager": "課長",
"department_manager": "部長",
"approval": "承認"
}
}
手法 B-2 (Kami + Gemma4) の出力
Gemma4（ローカル推論）でも結構頑張ります。表内の空白セル（未入力のダミー行）を null としてすべて律儀に出力してしまうなど、Geminiと比べると推論結果がやや冗長ですが、プロンプトの工夫次第な印象。ゲームPC程度のGPUで動かせるGemma4でここまでやれれば嬉しい。
{
"title": "株式会社経費報告書",
"table_data": {
"headers": ["項番", "日付", "摘要", "金額", "備考"],
"rows": [
{ "A8": null, "B8": null, "C8": null, "D8": null, "E8": null },
{ "A9": null, "B9": null, "C9": null, "D9": null, "E9": null }
// ... 以降の空白行も同様に null として出力される
],
"summary": {
"label": "合計",
"value": 0,
"formula": "=SUM(D8:D25)"
}
},
"approval_fields": {
"section_manager": "課長",
"department_manager": "部長",
"approval": "承認"
}
}
3.2 手法別再現性・精度の目視検証結果
| カテゴリ |
手法 A (Docling) |
手法 B (Kami/Gemini) |
手法 B (Kami/Gemma4) |
| 構造再現性 |
非常に高い (テーブル定義のみ) |
極めて高い (帳票の階層を理解) |
高い (一部の座標推論に揺らぎ) |
| 意味的抽出 |
不可 (テキストのみ抽出) |
良好 (項目と値を対で抽出) |
良好 (冗長な説明が含まれる場合あり) |
| レイアウト耐性 |
ルールベースで安定 |
複雑な結合セルに強い |
複雑な結合に強いが推論ミス稀有 |
3.3 結果として
1. ルールベースの限界と堅牢性 (Docling)
docling は Markdown 変換の安定性に特化して、複雑なセル結合があっても「テキスト」として漏らさず取得するという観点では優秀です。表形式をHTMLで表現させたので、Markdown式の表の表現限界を回避させるだけで使い方が広がります。帳票のフッターや注釈といった、レイアウト上の「意味的な区分」はなくなるので、２次利用の時には注意ですね。
2. VLM モデル比較 (Gemini vs Gemma4)
- Gemini 3.1 Flash-Lite Preview: さすがの文脈理解力。そこそこ複雑な結合セル群 (
06_extreme_merge) でも論理単位を的確にグループ化し、JSON 構造に落とし込んでいました。Flash-Liteでこれなら良し。
- Gemma 4 (Local): 空間推論において Gemini に肉薄し、実際の出力でも
03_complex_report のような複雑な帳票の計算式や承認欄を構造化できています。十分使えるレベルでは？
4. 運用・技術的推奨指針
| 運用フェーズ |
推奨手法 |
理由 |
| Markdownに変換したい |
Docling |
環境構築が容易で、帳票の「内容」を素早くテキスト化できるため。 |
| 抽出重視 |
Kami + Gemini |
帳票の意味を解釈し、データ抽出ミスを最小限に抑える必要があるため。 |
| コスト重視 |
Kami + Gemma4 |
外部 API に依存せず、高度な論理構造抽出（計算式の解釈や項目と値のペアリングなど）が可能であるため。 |
5. 結びに
「方眼紙エクセル」の解析は、確かに見た目の解析に目が向きます。Docling がその「形式」に着目したのに対し、Kami はその構造を考えています。構造化データを求めるのであれば Kami に優位がありそうです。要件に合わせて両手法を適切に使い分ける（あるいは組み合わせる）運用になると思います。色々な表現ができちゃうのがエクセルです。逆に言えばmarkdownの表現に限界がある以上、元データをちゃんと整理して保存しておくことが重要であると、改めて感じました。
エクセルが中途半端なWYSIWYG風なのは結構辛いですね・・・。
