1. はじめに
本記事では、当社「DNPドキュメント構造化AI（※1）」で生成された構造化データを活用することで、表構造を含む複雑な文書からより精度の高い情報抽出が可能になることを、Difyを用いた検証を通じて紹介します。
※1「DNPドキュメント構造化AI」は、企業内の非構造化文書を、生成AIが正確に理解・活用できる"AIリーダブルなデータ"に変換する、DNP独自開発のAIソリューションです。詳細は以下サービスページをご覧ください。
👉DNPドキュメント構造化AI（AI-Ready Data）
2. 現状の課題と検証アプローチ
企業内で扱う業務文書には、表形式で整理された情報が多く含まれています。例えば、課題管理票やプロジェクト管理表では、複数の記録が表形式で管理されており、各レコードには画像ファイルへのパスやプロジェクト名などの重要な情報が含まれています。
しかし、従来の方法では以下のような課題がありました：
- 表の構造が正確に理解されない：LLMが表の行と列の関係性を正しく把握できず、誤った情報を抽出してしまう
- レコード内の属性の紐付けが曖昧になる：どの値がどの列に属するのかが混同される
- 複数レコードの情報が混在する：異なる行の情報が区別されず、誤って統合される
- Excelファイル内の画像データが扱えない：Difyではそのままではエクセルファイル内に埋め込まれた画像データを処理できない（v1.12.0ではwordやPDFファイル内の画像は扱えるようになっているようです）
そこで今回は、構造化データの活用により、これらの課題をどの程度解決できるのか検証してみました。
3. 検証
3.1 サンプルデータ
検証用に、以下のような「品質トラブル報告書」の構造化データを用意しました。全体で100行以上のレコードがあります。この文書には複数のセクションが含まれており、中には画像が添付されている項目も記載されています。
※AIに生成してもらったものなので、内容は一部違和感のある個所もございますが、検証用としては十分かと思いますのでご容赦ください・・・
このデータをDifyのナレッジベースに登録する際、以下の3つのパターンで比較検証を行いました。いずれのパターンも親子モードで最大チャンク長4000に設定していますが、チャンク識別子の設定が異なります：
パターン1: オリジナル
元の文書をそのまま登録した形式です。テキストとして連続的に記載されています。
チャンク識別子設定：親「\n\n」、子「;」
チャンクデータ例：
"None":"No";"None":"カテゴリ";"None":"ステータス";"None":"優先度";"None":"発生日";"None":"記入者";"None":"課題内容";"None":"期日";"None":"回答日";"None":"回答者";"None":"回答内容";"None":"対応日";"None":"対応内容";"None":"備考"
特徴：ヘッダー（列名）とキー（値）のマッピングが正しく行われず、列名情報が失われてしまいます。
パターン2: 構造化（xml）
XML形式で構造化したデータです。各要素がタグで明示されていますが、表構造としての関連性は明示されていません。
チャンク識別子設定：親「<section>」、子「<text>」
チャンクデータ例：
<structual-data>
<article>
<title>サンプル管理台帳</title>
<text>\n|プロジェクト名|ITインフラ改善プロジェクト|\n|:---:|:---:|\n|管理部門|情報システム部|\n|作成日|2026/1/10|\n\n</text>
<text>\n|No|カテゴリ|ステータス|優先度|発生日|記入者|課題内容|期日|回答日|回答者|回答内容|対応日|対応内容|備考|\n|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|\n|1|システム|対応中|高|2026/1/15|山田太郎|ログイン画面でエラーが発生する<img src="images/figure_0.png" />|2026/1/20|2026/1/16|佐藤花子|認証サーバーの設定を確認中です|2026/1/18|設定ファイルを修正して再起動しました[cnbr]備考に実行時のキャプチャを載せておきます||\n|2|業務改善|未着手|中|2026/1/10|鈴木一郎|月次レポートの自動化を検討したい|2026/2/15|||||検討中で予算を確保する必要があります[cnbr]データのアクセス方法について要検討（備考参照）[cnbr]||\n|3|インフラ|完了|高|2026/1/5|田中美咲|サーバーのディスク容量不足|2026/1/8|2026/1/6|高橋健太|不要ファイルの削除を提案します|2026/1/7|古いログファイルを削除し容量確保しました||\n|4|セキュリティ|対応中|高|2026/1/12|高橋健太|アクセス権限の見直しが必要|2026/1/25|2026/1/13|山田太郎|権限マトリクスを作成中です|||優先度高のため早急に対応が必要<img src="images/figure_1.png" />|\n</text>
</article>
</structual-data>
特徴：今回のタグの構成上、チャンクサイズが大きくなる傾向があります。表全体が1つのチャンクとして扱われ、一度に多くの情報が含まれる分、検索時に情報が混在しやすくなります。
パターン3: 構造化（xml+xlsx）
XMLに加えて表構造を明示的に定義したデータです。表部分を別ファイル（Excel）として切り出すことで、表の行・列構造がより明確に保持されます。
チャンク識別子設定：
- XMLファイル:親「
<section>」、子「<text>」 - Excelファイル:親「
\n\n」、子「;」
チャンクデータ例（XML部分）：
<structual-data>
<article>
<title>サンプル管理台帳</title>
<text>\n|プロジェクト名|ITインフラ改善プロジェクト|\n|:---:|:---:|\n|管理部門|情報システム部|\n|作成日|2026/1/10|\n\n</text>
<file src="サンプル管理台帳_table.xlsx">
</article>
</structual-data>
チャンクデータ例（Excel部分）：
"No":"1";"カテゴリ":"システム";"ステータス":"対応中";"優先度":"高";"発生日":"2026-01-15 00:00:00";"課題内容":"ログイン画面でエラーが発生する<img src=\"images/figure_0.png\" />";"期日":"2026-01-20 00:00:00";"回答日":"2026-01-16 00:00:00";"回答内容":"認証サーバーの設定を確認中です";"対応日":"2026-01-18 00:00:00";"対応内容":"設定ファイルを修正して再起動しました[cnbr]備考に実行時のキャプチャを載せておきます"
特徴：チャンクサイズが適切で、ヘッダー（列名）とキー（値）のマッピングが正しく保たれます。1レコード（1行）が1チャンクとして扱われるため、検索精度が向上します。
※上記パターン2においても、タグを調整する事で同様のデータを作成する事も可能です。
このように、同じ内容のデータでも構造化のレベルによってデータ表現が大きく異なります。特にパターン3では、表データが別ファイルとして切り出されており、各セル（行と列の交点）が明確に定義されているため、LLMが「どの列のどの行にどの値が格納されているか」という表の構造を正確に理解できるようになっています。
3.2 Difyワークフローの構成
今回の検証では、以下のようなDifyワークフローを構築しました。
このワークフローでは、3つのナレッジベースに対して並列に検索を実行し、それぞれの結果からLLMが情報を抽出して回答を生成します。これにより、データ形式の違いが回答精度に与える影響を明確に比較できます。
※「ナレッジ取得」コードブロックはナレッジ検索結果からファイル名とチャンク内容を抽出する処理を記載しております。今回の検証では重要ではないため詳細は割愛いたします。
Difyの設定情報
検証の再現性を確保するため、使用したDifyの設定を以下に記載します。
ナレッジベース設定
- 埋め込みモデル：
text-embedding-3-large - 検索条件：ハイブリッド検索（セマンティック 0.7、キーワード 0.3）
- TopK：10
LLM設定
- モデル：
gpt-5 - システムプロンプト：
あなたはとあるプロジェクトのPMです。ユーザからの質問に、参考資料を元に回答してください。 - ユーザプロンプト：
ユーザからの問い合わせ「{{#sys.query#}}」に対し、{{#context#}}から情報を取得して回答してください。
4. 検証結果
4.1 質問と回答の比較
以下の2つの質問を3つのパターンに投げかけ、回答精度を比較しました。
質問1: プロジェクト名と画像パスの抽出
質問: 「プロジェクト名と、備考に貼られた画像を教えて。」
元データを再掲しますが、この検証では「プロジェクト名：ITインフラ改善プロジェクト」、「画像：images/figure_1.png」と回答できるのが望ましいです。
※エクセル内の画像は画像データそのものではなく、それぞれimages/figure_1.png（No.1の課題内容欄の画像）、images/figure_1.png（No.4の備考欄の画像）とパス情報に変換しています。
オリジナルデータでの回答
- プロジェクト名: ITインフラ改善プロジェクト
- 備考に貼られた画像: 「ログイン画面でエラーが発生する」（ID: 1）の対応記録に
「備考に実行時のキャプチャを載せておきます」との記載があります。
参考資料内には画像ファイル自体のパスやファイル名は記載されていないため、
ここでは画像の中身は確認できません。
オリジナルデータでは、プロジェクト名は正しく抽出できましたが、画像情報を取得できませんでした。更に言うと、元データの対象レコードの『対応内容』欄には「備考欄にキャプチャを載せておく」と記載がありますが、実際には画像データは『課題内容』に貼られています。このように、チャンク化の際に画像情報が失われたため、誤った回答になってしまったと考えられます。
構造化（xml）での回答
プロジェクト名: ITインフラ改善プロジェクト
備考に貼られた画像: images/figure_1.png（No.4「アクセス権限の見直しが必要」の備考欄に記載）
以上が該当の情報です。
XML形式での構造化により、画像パスの抽出ができるようになりました！もちろんこの結果はシンプルで問題ないのですが、次の構造化(xml+xlsx)のパターンでは更に情報が付与されています。
構造化（xml+xlsx）での回答
構造化（xml+xlsx）：
プロジェクト名: ITインフラ改善プロジェクト
備考に貼られた画像:
No.4「アクセス権限の見直しが必要」: images/figure_1.png
補足: 上記以外の行では、備考欄に画像タグの記載は確認できませんでした（No.1は課題内容欄に images/figure_0.png の画像タグがあり、備考には「実行時のキャプチャを載せておきます」との記載のみです）。
表構造を明示的に定義した構造化データでは、更に別の行に対する情報も含めて回答してくれました。1レコードが1チャンクとして適切に分割されており、各画像が添付されているレコード（No.1、No.4）の画像パスを正確に抽出できています。
質問2: 日付属性の正確な区別
質問: 「サーバディスク容量不足のトラブルが発生した日時と解消した日時を教えて」
この質問では、表に含まれる複数の日付属性（発生日、期日、対応日など）の中から、適切な情報を抽出できるかを検証しました。こちらの適切な回答は「発生日:2026/1/5、解消日:2026/1/7」になります。
オリジナルデータでの回答
管理台帳の「サーバーのディスク容量不足」の記録によれば、
- 発生日時: 2026-01-05 00:00:00
- 解消日時: 2026-01-08 00:00:00
オリジナルデータでは、発生日は正しく抽出できましたが、解消日時が誤っています。実際の対応日は2026-01-07ですが、「期日」（2026-01-08）を解消日時として回答してしまいました。これは、チャンク化の際にヘッダーとキーのマッピングが失われており、「期日」と「対応日」という似た属性を区別できなかったためです。
構造化（xml）での回答
サーバーディスク容量不足のトラブルについて、以下の情報が管理台帳に記載されています。
- 発生日: **2026/1/5**
- 解消日: **2026/1/7**
対応内容としては、「古いログファイルを削除し容量を確保した」と記載されています。
XML形式での構造化により、発生日と解消日を正しく抽出できるようになりました。表構造が明示されたことで、LLMが「対応日」という属性を正しく認識できています。
構造化（xml+xlsx）での回答
以下の通りです（管理台帳 No.3「サーバーのディスク容量不足」より）。
- 発生日時: 2026-01-05 00:00:00
- 解消日時: 2026-01-07 00:00:00（対応日に古いログファイル削除で容量確保）
構造化（xml+xlsx）パターンでも正確で詳細な回答が得られました。発生日と解消日が正しく抽出されているだけでなく、対応内容も併せて回答されています。1レコード1チャンクの適切な分割により、該当レコード（No.3）の全ての関連情報を正確に取得できています。
4.2 検証結果の分析
2つの質問に対する3つのパターンの比較結果をまとめると、以下のようになります：
| データ形式 | Q1: 画像パス抽出 | Q2: 日付属性の区別 | 総合評価 | 主な課題 |
|---|---|---|---|---|
| オリジナル | × | × | 低 | ヘッダーとキーのマッピング喪失により、属性の区別が困難 |
| 構造化（xml） | 〇 | 〇 | 高 | 正しく画像データ情報を取得し、ヘッダーとキーのマッピングも保持 |
| 構造化（xml+xlsx） | ◎ | 〇 | 高 | 1レコード1チャンクで保持する事で属性の正確な抽出が可能 |
特に重要なポイントは以下の2点です：
-
Q1（画像パス抽出）: 構造化（xml+xlsx）パターンでは、画像情報をパスとして格納した上で、表の行と列の関係性を正確に理解できているため、「備考に画像が添付されているレコード」という条件に合致するNo.4のデータのみを抽出でき、その記録に紐づく画像パス（
images/figure_1.png）を正確に回答できています。 -
Q2（日付属性の区別）: オリジナルパターンでは「期日」と「対応日」という似た属性を区別できず、誤った日付を回答してしまいました。一方、構造化パターンでは適切なヘッダー情報により、これらの属性を正確に区別できています。
精度向上の要因
構造化（xml+xlsx）で精度が向上した主な要因は以下の通りです：
- 表構造の明示的な定義：行と列の関係性がデータ構造として明確になっている
- 属性の適切な分離：各フィールド（課題、担当者、画像パスなど）が独立した要素として扱われる
- レコード間の区別が明確：複数の記録が混同されず、それぞれが独立したエンティティとして認識される
- 適切なチャンク化/チャンクサイズ：1レコード1チャンクとなり、ヘッダーとキーのマッピングが維持される
4. まとめ
本記事では、構造化データが表構造の理解精度に与える影響について、Difyを用いた検証を行いました。
検証の結果、オリジナルデータではテキストとしての情報抽出はできても属性情報（ファイルパスなど）の取得やヘッダーとキーのマッピングが困難だったのに対し、構造化したデータであれば表の行・列の関係性を正確に理解し、該当レコードの属性を正確に抽出できる事が分かりました。
2. 業務文書への実用性
表構造を明示的に定義した構造化データを活用することで、以下のような業務シーンでの精度向上が期待できます：
- 課題管理表から特定条件に合致する記録の抽出
- 品質報告書から特定の試験結果や測定値の取得
- プロジェクト管理票から担当者や期限などの属性情報の正確な抽出
3. 今後の展望
今回の検証では、比較的シンプルな2次元表での検証を行いましたが、実際の業務文書では以下のようなより複雑なケースも存在します：
- 複数階層の入れ子構造を持つ表
- 結合セルを含む複雑なレイアウト
- 表とテキストが混在する文書
これらのより複雑な構造に対しても、DNPドキュメント構造化AIによる適切な構造化処理を施すことで、高精度な情報抽出を実現できる可能性があります。
本記事が皆様の業務文書活用の参考となれば幸いです。
ここまで読んでいただき、ありがとうございました。