RAGでハマりがちな 「Excelの罠」を、 データの構造化で突破する ハルミ（守屋 春海） 2026/02/27　Findy株式会社主催 「RAG精度の壁を突破する-精度の壁とどう向き合う？」 

自己紹介 ハルミ（守屋春海） 某JTC / 社内SE 経歴 某大手製造メーカーで工場作業員として勤務後、 独学でITエンジニアに転身。社内転職して現在は社内SE。 社内のアナログな業務をあらゆる手を使って効率化。 　実務経験は1年半くらいでジュニアレベル。 趣味：OSS活動 / 技術発信 

今日持ち帰る結論 ○ 結論：RAGは“Retrieval”より先に、Ingestで決まる ○ Excelは“レイアウトに意味”があるので、プレーンテキスト化で関係が落ちる ○ だからレイアウトの意味を反映したドキュメントに再構築する 

現場あるある「無限に存在する文書ファイル」 文書ファイルの多様性 PDF Excel Word 画像(スキャンPDF) Excelの複雑さ 表 図形 グラフ 条件付き書式 だからこそ、Excelの前処理はRAGの精度を大きく左右する 

弊社内のRAGの制約と改善アプローチ 制約 • 外製でCMSスタイルの全社RAG基盤 • Naive RAG（BM25ベース検索） • 部署によっては独自RAG内製 • 専門用語での文書QA用途が多い • RAG知識のある技術者少ない 改善アプローチ データ前処理 プロンプト改善 比較的誰でも行える改善は、この2軸に絞られる 

問題例: 業務フローが正しく答えられない （業務フロー）お問合せフォームからの返品依頼 倉庫 事業管理部 顧客サポート課 ECシステム 顧客 受付 返品 テキスト抽出後 ・既存RAGシステムにExcelをそのまま渡す 図形内テキストが抽出されてない… 

問題例: 業務フローが正しく答えられない 倉庫 事業管理部 顧客サポート課 ECシステム 顧客 （業務フロー）お問合せフォームからの返品依頼 受 付 不具合の検知 返品の依頼 ・依頼内容：返品要望 ・理由：パーツ欠品 受付 通知 翌日まで 判断 内容確認 返送依頼 受け付けない お断りの通知 受け付ける 通知 通知 終了 返送 返 品 入荷処理 ・商品 ・返品受付票 …. テキスト抽出後 ・PDFに変換→テキスト抽出 要素間の関係性が維持できない… 

質問は簡単、でも答えがズレる 質問 「◯◯の業務フローを教えて」 結果 テキスト化後： すべてのテキストが直列に並ぶ ⇒ 関係性が消えて、答えがズレる 原因： 図形間の矢印やフローチャートの構造が失われ、 「A → B → C」という流れが「A B C」という単なる単語の羅列になってしまう 正しく答えられるかどうかはLLMの推論頼み 

フローチャートだけじゃない、多様な罠 ガントチャート 結合セルだらけ セルの色に意味がある セルの位置に意味がある テキスト抽出だけではLLMに伝わらないものが多い 

Excelの罠（なぜ精度が落ちる？） Excel = レイアウト駆動ドキュメント プレーンテキスト化で失うもの： 位置関係 色情報 結合情報 図形 グラフ 意味が欠損 → LLMが正しく理解できない → 精度低下 

じゃあ、何を保持すべきか LLM向け前処理は「意味の最小要件」を守る 座標 行・列・領域 結合 1つの意味単位 色 役割のメタ情報 図形/矢印 関係性 

解法： 中間表現を作ってから"再構築"する ✓ Excelを直接テキスト化しない ✓ 意味構造JSONを中間表現として作る ✓ 最後にLLMでMarkdownに変換して投入 Excel KB 意味構造JSON Markdown 

Excelデータ解析の具体的アプローチ ○ Office Open XML直解析 ○ ClosedXML(C#) ○ openpyxl/pandas ○ Excel Add-In ○ Excel COM API Excelは蓋を開ければ 超複雑なxmlファイル群をzip圧縮 したもの → COM インタフェースを使えば比較的簡単にアクセス可能 ❌ 地獄 ❌ Drawing 系（図形・チャート等）は弱い ❌ 図形取得非対応 ❌ 処理パイプラインに組み込みづらい ✔ 生データにほぼアクセス可能、楽 → → → → → ※ COM = Compute Object Model 

xlwingsでExcel COM APIを操作 import xlwings as xw with xw.App(visible=False) as app: wb = app.books.open("sample.xlsx") ws = wb.sheets[0].api # Excel COM Worksheet for i in range(1, ws.Shapes.Count + 1): shp = ws.Shapes.Item(i) name = shp.Name kind = shp.Type box = (shp.Left, shp.Top, shp.Width, shp.Height) # optional: 図形テキスト（取れない形状もある） text = "" try: if shp.TextFrame2.HasText: text = shp.TextFrame2.TextRange.Text except Exception: pass print(name, kind, box, text[:30]) wb.close() ExcelVBAチックな簡単なAPIでほぼ全ての 要素にアクセス可能 ✓ 図形 ✓ グラフ ✓ SmartArt ✓ 印刷範囲 ✓ 条件付き書式 ✓ etc… デメリット: Windows + Excel必須 

① Excel解析して意味構造化データを作る "shapes": [ { "text": "受付", "l": 3, "t": 87, "kind": "arrow", "begin_arrow_style": 1, "end_arrow_style": 1, "direction": "N" }, { "id": 1, "text": "不具合の検知 ", "l": 445, "t": 110, "kind": "shape", "type": "AutoShape-FlowchartTerminator" }, { "id": 2, "text": "返品の依頼 ", "l": 454, "t": 156, "kind": "shape", "type": "AutoShape-FlowchartProcess" … 

② LLMでMarkdownに変換 "shapes": [ { "text": "受付", "l": 3, "t": 87, "kind": "arrow", "begin_arrow_style": 1, "end_arrow_style": 1, "direction": "N" }, { "id": 1, "text": "不具合の検知 ", "l": 445, "t": 110, "kind": "shape", "type": "AutoShape-FlowchartTerminator" }, { "id": 2, "text": "返品の依頼 ", "l": 454, "t": 156, "kind": "shape", "type": "AutoShape-FlowchartProcess" … ## （業務フロー）お問合せフォームからの返品依頼 ```mermaid flowchart TD A([不具合の検知 ]) --> B[返品の依頼] B -->|お問合せフォーム \n依頼内容：返品要望 \n理由：パーツ欠品 | C[受付\n顧 客サポート課] C --> D[内容確認] D --> E{判断} E -->|受け付ける| F[返送依頼\n顧客サポート課 ] E -->|受け付けない | G[お断りの通知 \n顧客サポート課 ] G -->|通知| H([終了]) F -->|通知\n商品・返品受付票 | I[返送\n顧客] I --> J[入荷処理\n倉庫] J --> K[検品\n倉庫] K --> L[返品登録依頼 \n倉庫] L --> M[返品登録\n事業管理部] M -->|商品No・返品理由・検品結果 | N[[在庫反映\nECシステム]] N --> O[(在庫\n倉庫)] O --> P{品質判定} P -->|良品| Q[[在庫反映\nECシステム]] P -->|不良品| R([月次「廃棄・メーカー返品」へ ]) Q -->|更新：商品No・販売可能数・販売しきい値 | S[(販売在庫\nECシステム)] S -->|反映：商品No・販売可能数・販売しきい値 | T[[商品ページ\nECシステム]] T --> U([終了]) ``` 

結果 ◯◯の業務フローを教えて ◯◯の業務フローは以下の通りです。 フェーズ1：受付 1. 顧客が商品の不具合を検知し、お問合せフォームから返品を依頼する ○ 依頼内容：返品要望／理由：パーツ欠品 2. 顧客サポート課がフォームからの通知を受けて受付（翌日まで） 3. 顧客サポート課が内容確認を行う 4. 顧客サポート課が判断する ………… Excel文書に対する回答の正確性が大幅に向上 

文字列一致ではPDF優位、データ欠損耐性では意味構造JSON優位 📝 文字列忠実度 （Exact/Normalized） 指標 PDF 意味構造 JSON 差分 acc (Exact) 0.608 0.584 -0.024 acc_norm 0.857 0.836 -0.021 ※ 厳密な文字列マッチではPDFが僅差で上 🛡 データ欠損耐性 （Raw/Precision） 指標 PDF 意味構造 JSON 差分 acc_raw 0.875 0.876 +0.002 raw_precision 0.909 0.934 +0.025 md_precision 0.776 0.796 +0.020 💡 RAGで効くのは「情報の欠損を防ぐ」こと → 構造保持・精度の高さで 意味構造JSON が優位 条件：n=12 Excel documents / methods: exstruct, openpyxl, pdf, html, image_vlm / model: gpt-4o / temperature=0.0 公開：benchmark/public/REPORT.md（再現用）・評価は「文字列一致」と「欠損耐性」の2軸で追跡 (GitHub: harumiWeb/exstruct) 

銀の弾丸ではない（選び分け） 文書タイプで最適解が変わる。ハイブリッドや使い分けが大事。 シンプル文書 ↓ PDFでも十分 画像多め ↓ VLMでMarkdown化 神エクセル 構造が肝 ↓ COM＋構造化 その他検討できる手法： 手法 評価 MarkItDown 図形なしの文書ならかなり使いやすい HTML化 RAGと相性良いが汎用的な最適化に工夫必要 Azure AI Document Intelligence PDFにめっぽう強いがExcel解析は限定的 

実務への落とし込み KB投入だけじゃない LLMに優しいデータにすることは 社内データ活用の基盤 データ構造化による恩恵 : Agentic Search データ分析 レポート生成 ワークフロー 自動化 前処理の品質向上 = あらゆる生成AI活用の底上げ 

まとめ Excel精度低下は、だいたい欠損 解決は、意味構造を残す前処理 データ構造化は生成AI時代の効率化の鍵 ExStruct github.com/harumiWeb/exstruct ご清聴ありがとうございました！