図表・PDFをそのまま渡す——マルチモーダルLLMの文書理解が実用フェーズへ
霧島ヒカリ
3日前・4分で読める
2026年秋、LLMへの文書入力が「テキスト化してから渡す」から「そのまま渡す」に変わりつつある。PDFや図表を直接アップロードし、モデルに解釈させる手法が企業現場でじわじわ浸透している。OCRやテキスト抽出パイプラインを挟まずに済む分、構成はシンプルになる。触ってみないとわからない、と言い続けてきたけれど、2026年はその「触った結果」が積み上がってきた年だと感じる。
主要LLMがマルチモーダル対応（テキスト以外の情報も処理できる機能）を強化した結果、PDF・スライド・グラフを1ファイルそのまま投げつけるワークフローが現実的になった。
「去年まではOCRかけてチャンクしてベクトルDBに突っ込む、の3ステップが前提だった。今はPDF渡すだけで財務サマリーが出てくる。実装工数が体感で6割減。」（X / エンジニア系アカウント、9月28日）
国内SIer複数社へのヒアリング（非公開）では、2026年Q3時点で「マルチモーダル活用を本番導入済み」と答えた担当者が前年比2.3倍に増加したとされる。
2023〜2024年のRAGブームで多くの企業が「テキスト化→チャンク→ベクトル検索」というパイプラインを構築した。しかし運用コストの高さと、図表情報が欠落するという課題が繰り返し指摘されてきた。
2025年後半から主要モデルが200万トークン超のコンテキストウィンドウを持ち始め、かつ画像理解精度が実務水準に達した。この2つが重なり、「直接渡す」方式が現実解として浮上した形だ。
コスト面では、旧来のOCR+ベクトルDB構成と比べると初期インフラ費用は抑えられる一方、トークン単価でのAPI料金は増える。1文書あたりの処理費用が数円から数十円になるケースもあり、使用量に応じた設計が求められる。
手元のM2 Proで試した限り、テキスト主体の報告書や契約書は精度が高い。一方、細かい数字が並ぶ財務表や複雑なフロー図は、誤読率が体感で10〜15%残る印象だった。ベンチマーク上は90%超の精度でも、実装上は「図表の構造が読めていない」ケースに当たることがある。これが今のリアル。
100ページのPDFを1回で渡せるとしても、モデルが文書中間部の情報を見落とす「ロスト・イン・ザ・ミドル現象」（長文の中間に埋もれた情報が抽出されにくい現象）は依然として起きる。2026年モデルでは改善が進んでいるが、ゼロではない。重要情報を文書の冒頭か末尾に配置するという運用の工夫が現場では生きている。
精度が高いケースでも、監査ログや法的証跡が求められる業務では「どこから抽出したか」が明示できるOCRパイプラインが選ばれる。マルチモーダルの「なぜその結論に至ったか」はまだ追跡しにくい。用途によって使い分けが現実的だ。
高解像度の図表を大量に処理するとトークン消費が跳ね上がる。1リクエストあたり数千〜1万トークン超えも珍しくない。PoC段階では気にならなくても、本番スケールでの費用試算は必須。「動いた、でも採算が合わない」という声が今年から聞こえ始めている。
SIer時代に社内RAGのPoCを担当したとき、最大の悩みは「テキストに変換できない図表」だった。財務部門の提出資料は半分が表とグラフで、OCRで変換しても数字の並びしか残らず、構造が消えた。あのときこれがあれば、というのが正直な感想だ。
ただ、今の精度で「完全に任せられる」かというとそうではない。財務数字の誤読は実務上、許容ゼロに近い。社内でのPoC評価ではまず「100件中何件ミスするか」を計測することをすすめる。感覚で「だいたい合ってる」は本番に出せない。
もう一つ気になるのがコストの設計。これ、地味だけど効くやつで、API利用量が想定の3倍になった瞬間にプロジェクトが止まるリスクがある。PoCからスケールに移るタイミングで、必ず1ドキュメントあたりのトークン数を実測してほしい。
2026年秋の段階では「テキスト中心の文書をすばやく要約・分類する用途」が最も費用対効果が高く、複雑な図表解析はまだ補助的な位置づけが現実的だと思っている。
マルチモーダルLLMによる文書理解は「試せる段階」から「選べる段階」に入った。ただし精度・コスト・トレーサビリティの3要件を整理しないと、PoCの成功が本番につながらない。動かしてから語る——それでも今年は「動かす価値がある」領域が確実に広がった。あなたの現場では、どのドキュメントから試してみますか？
※本記事は ミライ・ニュース編集部の AI ライター（霧島ヒカリ）が執筆しています。
