RAGに適したデータをつくる前処理技術とは?【データ構造化ソリューション ドキュメント構造化API 詳解】
こんにちは、言語理解研究所(ILU)です。
ILUではこれまで、個社ごとのカスタム開発を前提としたデータ構造化ソリューション「laei」を提供しておりましたが、このたび、名称をデータ構造化ソリューション「DX-laei」と改め、APIとして汎用提供可能な形での正式リリースを開始いたします。
生成AIの活用は実証実験フェーズを越え、実運用における精度と業務適合性の課題解決が次の焦点となりつつあります。
なかでも最近注目されているのが「AIエージェント」。私たちが以前noteで公開した記事「AIエージェントがあればRAGはいらない?」にも大きな反響をいただきました。
この記事でも触れているように、本格的に業務で生成AIを活用するには、運用負荷や精度の観点から「RAG(検索拡張生成)」が欠かせません。
ですが、RAGを導入した企業からは、以下のような課題がよく挙げられています。
RAGの回答精度が悪く、通常通りドキュメントを探している
→ AIの検索結果をそのまま使えず、現場での確認作業が残ってしまう。質問の仕方が少し違うだけで、まったく異なる答えが返ってくる
→ プロンプトの違いによるばらつきが大きく、安定した運用が難しい。検索結果が長文で要点がつかみにくく、実務では活用しづらい
→ 情報の網羅性はあるが、実用性・要点抽出の精度が不足している。
これらは単なる使い勝手の問題ではなく、生成AIの業務活用における本質的な壁と言えます。
これらの課題の背景には、主に次の2つの要因があります。
回答の元となるドキュメントが構造化されていない
人間にとっては「読みやすく整理された資料」でも、AIにとっては「構造が曖昧で情報が錯綜している資料」になりがちです。そのため、文書には事前の構造整理や注釈付けが求められます。ユーザーの質問意図を正しく理解できていない
質問の仕方によって回答精度が大きく変わり、ユーザーにプロンプト設計の知識が求められてしまいます。
ILUでは、これらの課題に対して
AIが読みやすいドキュメント構造を整える「ドキュメント構造化API」
曖昧な質問を検索しやすい形に変換する「検索クエリ生成API」
用途に応じ様々な情報を付与・拡張する「アノテーションAPI」
以上3つのAPIでアプローチしています。
今回はそのうち、検索精度の基盤を整える「ドキュメント構造化API」にフォーカスし、仕組みと導入メリットをご紹介します。
構造化APIの概要
RAG(検索拡張生成)は、質問に対する回答を外部ドキュメントから検索し、その結果をもとにLLMが自然文で回答を生成する仕組みです。
このとき、回答の品質を左右するのは「LLMの性能」だけではありません。
検索対象となる文書の質と構造が整っているかどうかが、精度と一貫性に大きく影響します。
「ドキュメント構造化API」は、提案書やマニュアル、稟議書などの社内文書を、RAGに最適な構造に自動整形するAPIです。
7つの処理で実現する構造化プロセス
「ドキュメント構造化API」では、以下の7ステップを通じて、業務文書をRAG対応データへ整形します。
■ 前処理フェーズ
1.ファイルを読み込む
対応形式(PDF/Word/Excel/PPT)をPDF化し、ページ単位で画像化。
2.テキストを抽出する(2方式)
- AI-OCR:Markdown整形を含む構造化テキストを生成
- LLM:文脈を考慮したMarkdown整形済みのテキストを生成
■ テキスト評価フェーズ
3.最適なテキストを選定する
AI-OCRとLLMの出力を比較し、精度・文脈の自然さから適切なものを採択。
4.高精度化処理を行う
構造補正や語彙の統一処理を適用し、出力の安定性を向上。
5.出力の妥当性を検証する
補正済みのテキストの内容をチェックし、必要に応じて前の採択結果にロールバック。
■ 検索最適化フェーズ
6.シノニムマップを生成する
同義語や表記ゆれを整理し、検索時の語彙補完に活用できる辞書を自動作成。
7.テキストをチャンク分割する
意味単位での分割と、文脈保持のためのオーバーラップを設定。
次に、各工程について詳しくご説明します。
※本解説は汎用版APIを前提とした内容です。
個社対応版のドキュメント構造化APIは、事前学習やルール最適化などのカスタム処理を含むため、仕様や挙動が異なります。あらかじめご了承ください。
1.ドキュメントを読み込む
読み込まれたファイルは、構造化APIによってPDF化され、ページ単位で分割・画像化されます。
対応可能なドキュメント形式(2025年5月時点)
・Word(.doc, .docx)
・PowerPoint(.ppt, .pptx)
・Excel(.xls, .xlsx)
2.テキスト化(2パターン)
①AI-OCRによるテキスト化(+Markdown整形)
ドキュメント画像からAI-OCRを用いてテキストを抽出し、APIが自動的に見出しや段落構造をMarkdown形式で整形します。
AI-OCRは文字情報の認識精度が高く、文字中心のドキュメントに対して特に有効です。また、印刷されたスキャン文書に対して非常に高い認識精度を持つほか、人目で判別できる手書き文字であれば対応可能です。
※AI-OCRを利用した構造化についてはこちらでも触れています。
また、AI-OCRによるテキスト化においても、ILU独自辞書を活用することで認識精度をさらに向上させています。
ただし、AI-OCRは「書かれたものをそのまま読み取る」処理であるため、「フローチャート図をMermaid記法で構造的に再現する」といった作業には不向きです。
②LLMによるテキスト化
同じドキュメント画像をLLMに渡し、文脈を踏まえて見出しや段落の構造を再構成し、Markdown形式で整形されたテキストを生成します。
LLMは図やイラストの内容を推論し、補足的な説明をテキストとして付加する処理にも対応しています。
一方で、文字情報の読み取り精度そのものはあまり高くなく、画像からの正確な文字抽出には適していません。
補足:AI-OCRとLLMの使い分けについて
AI-OCRは手書き文字やスキャン文書の認識に強く、特にILUが蓄積してきた知見を活かすことで、見積書や請求書などレイアウトが一定でない文書の補正・構造化にも高精度で対応可能です。
一方、マルチモーダル対応のLLMは、図表や非定型レイアウトを含む複雑な文書に対して文脈を推測しながら柔軟に処理できる点が特長です。
3.テキスト評価と選定
上記2つのテキスト(AI-OCR/LLM)をチャンク単位で精度と文脈の自然さを総合的に評価し、「採択テキスト」としてより最適なテキストを選定します。
採択判断のルール(2025年5月現在)
1. 文書内に、Mermaid記法や視覚情報のテキスト化など、OCRでは再現できない補足情報が含まれる場合は、LLMを選択。
2. 図表が含まれる場合で、文字情報の認識精度が重要かつMarkdown記法の再現もある程度期待できるケースでは、OCRを選択。
3. 特にLLMでなければ再現できない要素が文書内に含まれない場合は、誤字の少ないOCRを優先的に選択。
4.高精度化処理
3で採択したテキストに対してさらに補正処理を行い、文構造や表記の整合性を高めた「補正テキスト」を生成します。
高精度化処理の一例(2025年5月現在)
・誤字修正(AI-OCR特有の文字誤り補正)
AI-OCRは文字精度が高いが、特定の文字種において誤認が発生しやすい傾向がある。既知のパターンに対し、LLMにより自動的に修正を実行。
(例)
①「カ」(カタカナ)と「力」(漢字)の混同
②「一」(漢字)と「―」(ダッシュ)および「1」との混同
・AI-OCR結果・LLM結果の短所部分を補う処理
AI-OCRまたはLLMいずれかの出力を主としつつ、もう一方の特性を活用するハイブリッド補正を実施。
・書式・表記統一処理
構造化テキスト全体の整合性を担保するため、出力形式に関する統一処理を追加で実施。
・Markdown形式の見出し記法(#)を、OCR・LLM問わず自動付与。
・ページ番号の表記(例:「P.1」「P.2」)を、OCR/LLMで統一。
・Mermaid記法で生成された図表内における改行喪失を補完。
5.妥当性チェック
補正テキストに対して妥当性の確認を実施します。
内容に問題がなければ4で補正を行った「補正テキスト」を採用し
問題がある場合は3で採択した「採択テキスト」を採用します。
6.シノニムマップの作成
補正テキスト(あるいは採択テキスト)をもとに、同義語や類語を整理したシノニムマップを生成します。このシノニムマップにはILUが独自に構築してきた専門語辞書・業界別用語マップを活用しています。
これにより、「売上伝票」と「売上明細書」、「作業手順」と「マニュアル」など、ドキュメントによる表記ゆれ・言い換え表現にも対応可能です。
このシノニムマップは、業務ドキュメントに特有の言い換えや表記ゆれを吸収し、検索時の取りこぼしを防ぐ語彙拡張辞書として活用されています。その結果、RAGによる検索精度と回答の一貫性が大きく向上します。
7.チャンク生成・処理
テキストを意味単位で分割(チャンキング)し、文脈保持のために一部オーバーラップを設けます。
このとき、インデックスには検索時の語彙補完に活用できるシノニムマップを登録します。
このように、構造と語彙の整備を同時に行うことで、RAG構築に先立つ前処理フェーズの再現性と効率性を支援します。
ドキュメント構造化APIを使用した
構造化の参考例
構造化の参考として以下の資料を使用しました。
Sansan株式会社 2025年5月期 第3四半期 決算説明資料
このドキュメントを読み込ませた際、このような形で構造化されます。
# 出力結果
# グループ概要「アナログからデジタル」に着目したSaaS
紙をはじめとしたアナログな業務フローが残っていることで、デジタル化による大きな効率化の余地があることに注目し、さまざまなアナログ情報をスピーディかつ正確にデジタル化し、業務の生産性の向上やデータ活用による利便性を提供
|sansan|Eight|BillOnepoweredbySansan|ContractOnepoweredbySansan|
||-|¥||
|接点情報|名刺|請求書|契約書|
|>|アナログ情報をテクノロジーと人力の組み合わせで正確にデータ化|AI+AI:入力人:手入力|人:チェック|
|||¥||
mermaid
graph TB
subgraph サービス一覧
sansan["sansan"]
Eight["Eight"]
BillOne["Bill One
powered by Sansan"]
ContractOne["Contract One
powered by Sansan"]
sansanInfo[接点情報]
eightInfo[名刺]
billInfo[請求書]
contractInfo[契約書]
sansan -- sansanInfo
Eight -- eightInfo
BillOne -- billInfo
ContractOne -- contractInfo
end
subgraph デジタル化プロセス
process[アナログ情報をテクノロジーと
人力の組み合わせで正確にデータ化]
ai[AI:入力]
human[人:手入力]
check[人:チェック]
ai -->|+| human --> check
end
sansanInfo --> process
eightInfo --> process
billInfo --> process
contractInfo --> process
@Sansan,Inc.
P.20ドキュメント構造化APIによる
構造化テキストの精度を支える3つのポイント
語彙の正確性
業務文書に特有の表現や略語にも対応できるよう、ILUが独自に構築してきた辞書を活用。読み間違いや変換ミスを最小限に抑えた、信頼性の高いテキスト抽出が可能です。表構造の再現性
表データに含まれる上下左右のセル結合や、複雑なレイアウトも正確に読み取り。構造を保持したまま、Markdown形式などの整形されたテキストとして出力できます。図解の関係性保持
フローチャートや矢印図のような図解についても、要素間の関係性を分析し、破綻のない構造で再現。人が図で把握していた情報を、AIにも理解できる形で渡すことができます。
ドキュメント構造化APIにおけるILUの独自性
RAGの構築やデータの前処理において、一定のチャンキングやテキスト抽出といった工程は多くの企業でも行われています。
ただし、実際には「PDFからそのままテキスト抽出して分割する」といったシンプルな処理に留まっているケースも多く、文書構造の保持や出力の安定性までは考慮されていないことが少なくありません。
ILUの構造化APIでは、こうした処理をより精緻に設計し、生成AIによるテキスト選定や高精度化、文脈を保ったチャンク分割などを標準化することで、再現性のあるRAG構築を支援しています。
シノニムマップ技術
なかでも、ILUの構造化APIにおける最大の差別化要素が「シノニムマップの自動生成」です。
ILUは40年にわたる日本語処理の研究と実務経験から独自の専門辞書を構築しており、この知見をもとに、業務で実際に使われる「表記ゆれ」「言い換え」「略語展開」などを網羅的にマッピングします。
シノニムマップの例
同義語
・売上伝票 = 売上明細書
・作業手順 = マニュアル
言い換え
・申請書 ⇔ 届け出書
・提出期限 ⇔ 締切日
表記ゆれ
・メール/Eメール/e-mail
略語展開
・FAQ = よくある質問
・DX = デジタルトランスフォーメーション
ローカル語・略称
・伝票処理 = 伝処
・週報 = WR(Weekly Report)
このように、ILUのシノニムマップは単なる同義語展開にとどまらず、実際の業務で起こりやすい“言葉のズレ”に総合的に対応します。
検索時にこのマッピングが活用されることで、取りこぼしのない検索結果の実現と、ユーザーごとの表現差による精度のブレを最小限に抑えることが可能になります。
一見シンプルに思える言い換え辞書の作成も、実用レベルの精度に仕上げるには、膨大な検証と語彙設計が欠かせません。
ILUの構造化APIは、こうした語彙の柔軟な処理を通じて、単なる“文書の整形”を超えた、実運用に耐えるRAG構築の基盤を提供しています。
LLMの適用とモデル選定の工夫
ドキュメント構造化APIでは、各処理工程においてタスク特性に応じたLLMを適用しています。
画像認識、自然文生成、文書構造の保持など、それぞれの処理目的に最適なモデルを選定することで、処理精度と運用時の安定性を両立しています。
モデルの選定にあたっては、単純な精度指標の高さだけではなく、再現性・運用中の安定性・メンテナンス性といった実運用での重要性を加味した実践的な評価基準に基づいています。
なお、本記事でご紹介している内容は2025年時点の構成に基づいており、
今後もLLMや関連技術の進化にあわせて、API自体も継続的に更新・改善を重ねてまいります。
また、プロンプトエンジニアリングはILUの知識辞書エンジニアが担当しており、独自の言語資産と文書構造への理解を活かして、出力のブレを最小限に抑える設計・チューニングを実施しています。
個別プロジェクトにおいては、企業ごとの文書傾向に応じた教師データの作成やカスタマイズにも柔軟に対応可能です。
まとめ
本記事では、ILUが提供する”データ構造化ソリューション 「DX-laei」ドキュメント構造化API”の仕組みと技術的特徴をご紹介しました。
本APIは、文書構造の保持から語彙ゆれの吸収、意味単位での分割までを一貫して自動化し、RAGの高精度かつ安定的な構築を支援します。
特に、独自のシノニムマップ技術は、業務ドキュメントにおける検索精度と回答の一貫性を大きく向上させる差別化要素です。
現在、お手持ちのドキュメントを用いて精度をご確認いただける無料トライアルをご提供しています。
すでに生成AIやRAGを導入済みで、「精度面に課題がある」「業務プロセスへの定着に課題を感じている」といったお悩みをお持ちの企業様へ、既存環境を活かした改善提案をご案内しています。
まずは、下記フォームよりお気軽にお問い合わせください。
次回は、データ構造化ソリューション「DX-laei」のAPIの一つ、ユーザーの質問の質を一定に保つ「検索クエリ生成API」についてご説明させて頂きます。

