自己紹介
こんにちは、Fusicのハンです。
ふだんは日本語音声合成（TTS）モデルの開発や、Document AI × LLMを活用した業務効率化、その他AIにまつわる技術・相談支援をしています。
株式会社Fusicは、AWS／Web／アプリ／IoT／AIなど広範な技術領域をカバーしていて、ITの構想フェーズから開発・運用まで一気通貫で支援している会社です。
もし「AI活用したい」「ドキュメントをなんとかしたい」などご興味ありましたら、お気軽にご連絡ください！
はじめに：生成AI、うまく使えてますか？
最近では、RAG（Retrieval-Augmented Generation）やNotebookLM、ChatGPTのようなサービスの普及により、生成AIの「民主化」が進んでいます。
特に、「手元のドキュメントを読ませてChatBotを作る」、「別のドキュメントを生成する」などは、定番のユースケースになってきました。
しかし、
- サンプルのドキュメントではうまくいったのに、実際の社内資料だとうまく動かない
- 質問に全然答えてくれない、なんかズレてる
- 一見正しそうだけど、よく見ると内容が微妙に違う
…そんな経験、ありませんか？
こういった問題の多くは「LLMの性能の限界」ではなく、「ドキュメントの入力精度」＝Document AIの問題であることが多いです。
Document AIとLLMは「目」と「脳」
「生成AI＝魔法の黒箱」みたいなイメージを持たれがちですが、実際はこういった構造になっています。
ドキュメント（現実世界の情報）
↓
Document AI（目）→ デジタル化・構造化
↓
LLM（脳）→ 理解・生成
↓
回答・出力（新しい知識やドキュメント）
この中でもDocument AIは、現実世界とAIをつなぐ最初の重要なパイプです。
ケーススタディでみる「Document AIの精度がもたらす差」
ここからは実際の例を元に、Document AIの精度がLLMの出力にどう影響するかを見てみます。
※利用したモデルは Upstage Document Parse（以下、DP）。前回の記事（DifyにUpstage DPを組み込んだ話）も参考にどうぞ。
Case①：「質問には答えてるけど、全然関係ない話してない？」
- 概要：ChatGPTを用いたFAQテスト
- Dify標準テスト：ドキュメント → DP(Dify文字抽出)→ 入力
- Upstage DPテスト：ドキュメント → DP(Upstage) → 入力
- ドキュメント：清掃作業費用に関する資料（PDFだがスクショベース・AI生成）
質問：1600㎡の建物の清掃費用は？
結果
- Dify標準テスト：業界の一般価格を答える（資料を無視）
# 回答
1600m² の建物清掃の概算は、清掃の種類（定期清掃か、日常清掃か）、作業内容（床のみ／窓・トイレ・換気扇含むか）、人件費単価などで大きく変動します。一般的な参考値を整理すると以下のとおりです。
1. 単価の目安
日常清掃（簡易な床清掃・ゴミ回収・トイレ清掃など）
約 200～400円/m²・月
→ 1600m²の場合、32万～64万円/月
定期清掃（ワックス掛け・カーペット洗浄・窓ガラス清掃など）
1回あたり 100～300円/m²
→ 1600m²の場合、16万～48万円/回
・・・
（続き）
- Upstage DPテスト：資料の価格表から正確に計算して答える
# 回答
1600m²の建物を清掃する場合の概算を、提示いただいた資料に基づいて計算します。
※ここでは 平日・日中作業／特殊機材なし／エレベーターありの標準条件 を想定して算出します。
1. 基本料金
面積：1001〜2000m² → 25,000円（税抜）
（税込 27,500円）
2. 使用機材・特殊対応（標準条件）
「機材なし」を想定 → 0円
3. 階数・アクセス条件
仮に 6階未満・エレベーターあり とすると → +1,000円（税抜）
（税込 1,100円）
・・・
（続き）
原因：入力はスクリーンショットで作られたPDF
実際に、Document AI結果を確認してみました。
- （左）Dify標準テスト：テキスト抽出が全くできていない
- （右）Upstage DPテスト：OCRとレイアウト解析により、しっかり情報を読み取っている
文字抽出（Document AI/OCR等）技術はモデルによって、PDFのテキスト情報（マウスでDragしてCopyできるもの）のみ抽出する場合もあります。
この場合、LLMに渡された『情報量は０』になります。
Case②：「だいたい合ってるけど、ちょっとズレてない？」
- 概要：NotebookLMを用いたFAQテスト
- NotebookLM標準テスト：ドキュメント → NotebookLM
- Upstage DPテスト：ドキュメント → DP → NotebookLM
- ドキュメント：Fusic IR情報（複雑な構造）
質問：第4四半期累計の売上高とMSPに関する情報
結果
- NotebookLM標準テスト：MSP事業事業に関して間違った情報
第4四半期累計の売上高は19.52億円でした。
◦ これは前期比で＋8.5％の増収を達成しており、開発案件とプロダクトの成長が牽引しました。
◦ 修正後計画を上回って着地しています。
◦ 売上高は営業利益とともに過去最高業績を達成しました。
MSP事業については、以下の情報が示されています。
◦ MSPは前期比＋21.3％で着地しました。
◦ 大手インフラ等の大口顧客に対する顧客深耕が進捗しました。
◦ これにより、**顧客平均単価は前期比＋24.0％**で着地し、売上総利益率の上昇に大きく貢献しました。
- Upstage DPテスト：正しく読み取り、正確な回答
第4四半期累計の売上高は、19.52億円でした。
これは前期比で+8.5%の増収を達成しており、通期予想進捗率は101.9%に達しています。
売上高の成長は、開発案件とプロダクトの成長に牽引された結果であり、修正後の計画を上回って着地しました。
MSP事業については、第3四半期までは前年同期比で減収が続いていましたが、
第4四半期（4月〜6月）には前年同期比+2.4%の増収に転換しました。
原因：テーブルデータが構造化されてない
実際に、NotebookLMの入力情報を確認してみました。
- （左）NotebookLM標準テスト：テーブルの文字情報は認識しているが、行・列になってない
- （右）Upstage DPテスト：テーブルの構造を再現し、情報を保存
Document AIを利用する際には、『正しく情報が取れているかどうか』の確認が必要です。
一見、情報が取れていると思いがちですが、行列情報・テンプレート情報など、LLMが必要としている情報が漏れている可能性もあります。
Case③：「正しい情報に見えるが、なんか間違ってない？」
- 概要：NotebookLMを用いたFAQテスト
- NotebookLM標準テスト：ドキュメント → NotebookLM
- Upstage DPテスト：ドキュメント → DP → NotebookLM
- ドキュメント：Fusic IR情報（多数のテーブル）
質問：売上高（2025 1Q）、営業利益（2025 1Q）、営業利益（2024 3Q~2025 4Q）
結果
- NotebookLM標準テスト：チャート上の数字ではあるが、間違った回答
• 売上高（2025 1Q）：493百万円
• 営業利益（2025 1Q）：92百万円
**営業利益（2024年6月期 3Q～2025年6月期 4Q）**については、現在提供されているソースから読み取れる範囲で以下の通りです。
• 2024年6月期 3Q 営業利益：90百万円
• 2024年6月期 4Q 営業利益：99百万円
• 2025年6月期 1Q 営業利益：92百万円
• 2025年6月期 2Q 営業利益：47百万円
なお、2025年6月期 3Qおよび4Qの営業利益については、提供されたソースには具体的な数値が明記されておりません。
- Upstage DPテスト：チャート情報通りの回答
• **売上高（2025年1Q）**は、441百万円です。
• **営業利益（2025年1Q）**は、32百万円です。
• **営業利益（2024年3Q〜2025年4Q）**の推移は以下の通りです。
◦ 2024年3Q: 92百万円
◦ 2024年4Q: 0百万円
◦ 2025年1Q: 32百万円
◦ 2025年2Q: 90百万円
◦ 2025年3Q: 99百万円
◦ 2025年4Q: 47百万円
原因：チャートの概念が持っている情報が漏れている
実際に、NotebookLMの入力情報を確認してみました。
- （左）NotebookLM標準テスト：チャートのテキスト情報のみ抽出
- （右）Upstage DPテスト：（Upstage Playgroundの結果画面）
- チャート情報を認識し、テーブル情報に変換
- イメージ情報も抽出
Document AIはモデルによって、扱える対象・範囲が異なります。Upstage DPでは、
- チャートのタイプ
- チャート → テーブル化
- イメージ情報
が抽出できています。
Upstage DPでも、複雑なチャートでは正確な情報が取れてないことも確認しましたが、イメージ情報が取れるなら、
- 後処理で情報抽出
- イメージとして情報の元を確認
などの対策も考えられます。
まとめ：脳が考えられるのは『目からの情報』
本記事では、『ドキュメント → AI → 出力』ではなく、以下の視点で生成AI活用を見直してみました。
ドキュメント → Document AI（目） → デジタル・構造化 → LLM（脳） → 出力
そして、改めて実感したのは：
LLMの進化は早く、性能はもう十分強い。
でも、その力を引き出す「データの目＝Document AI」が弱いと意味がない。
生成AIのPoCや実業務導入でつまずく多くのケースは、実はこの「目」の部分が原因です。
だからこそ、
- 現状のDocument AIモデルの限界
- 自社ドキュメントの特徴（画像多い？テーブル多い？など）
- それに対する技術のマッチング
をちゃんと理解・評価することが、『本当に意味のある生成AI活用』につながるのでは？と考えています。
次回は、DifyにUpstage DPを組み込んだカスタムツールを活用し、
ユースケースを分析、『業務特徴・技術特徴』面で分析してみたいと思います。
Discussion