最近、DX推進の現場において、「ChatGPTを使っているはずなのに、なぜ社内AIはこんなにトンチンカンな回答をするんだ？」という課題を耳にすることが増えています。多くの企業は高額な予算を投じて最新のRAG（検索拡張生成）システムを導入し、社内の膨大なPDFマニュアルやパワーポイント資料を学習させています。しかし、PoC（概念実証）を始めてみると、期待していたような結果が得られず、間違った情報を自信満々に答えたり、「情報が見つかりません」と繰り返したりする現実に直面しています。
結論から申し上げましょう。AIが期待通りに動かない原因の9割は、LLM（大規模言語モデル）の頭の良さではなく、「データの食べさせ方」にあると考えられます。
多くの企業は、AIモデルのベンチマークスコアや、コンテキストウィンドウのサイズ（一度に読み込める文字数）ばかりを気にします。しかし、どんなに優秀なシェフ（LLM）でも、泥のついた野菜や腐った肉（構造化されていないデータ）を渡されれば、美味しい料理（正確な回答）を作ることはできません。
AIエージェント開発の現場では、これを「Garbage In, Garbage Out（ゴミを入れればゴミが出る）」と呼びますが、RAGにおいてはさらに深刻です。単なるゴミではなく、「人間には読めるが、AIには読めない」形式でデータが存在しているからです。
本記事では、長年の開発現場で培った知見をベースに、多くのツールベンダーがあまり語りたがらない「データ構造化能力」という評価基準について、技術的な裏側を交えながら解説します。これを読めば、カタログスペックに惑わされず、技術の本質を見抜き、ビジネスへの最短距離を描けるプラットフォームを見極められるようになるはずです。
なぜ「賢いAI」でも社内文書を理解できないのか？
まず、私たちが普段業務で使っているドキュメントが、AIにとっていかに「不親切」なものであるかを理解する必要があります。皆さんはどう思われますか？
「PDFをそのままアップロード」が失敗の始まり
多くのAIプラットフォームは「PDFをドラッグ＆ドロップするだけで学習完了」と謳っています。確かに操作は簡単ですが、裏側で何が起きているかが重要です。
PDF（Portable Document Format）は、その名の通り「印刷結果をデジタルで再現する」ためのフォーマットです。人間が見る分にはレイアウトが保たれていて綺麗ですが、コンピュータにとっては単なる「文字と図形の配置座標の集合体」に過ぎません。
例えば、2段組みのニュースレターを想像してください。人間は左の段を上から下へ読み、次に右の段へ視線を移します。しかし、単純なテキスト抽出プログラムがこれを読むと、左の段の1行目と右の段の1行目を繋げて読んでしまうことが多々あります。
[人間の認識]
（左段） （右段）
本日は晴天なり。 明日の天気は
気温は25度です。 雨の予報です。
[単純なAIの読み取り結果]
本日は晴天なり。明日の天気は気温は25度です。雨の予報です。
これでは文脈が崩壊し、AIは「本日は晴天で明日の天気は気温25度」という意味不明な解釈をしてしまいます。これが、AIが「トンチンカンな回答」をするメカニズムの一つです。
人間には読めてもAIには読めない「レイアウトの壁」
さらに厄介なのが、表（テーブル）や図解です。Excelで作った綺麗な表をPDF化してAIに読ませたとしましょう。
人間は罫線を見て「ここからここまでが売上データだな」と認識しますが、AIがテキストデータとして読み込む際、その罫線情報は失われます。セル内の文字がただのスペース区切りで羅列されるだけになり、どの数字がどの項目に対応しているのか、関係性が完全に断ち切られてしまうのです。
また、ヘッダーやフッターもノイズになります。全ページの下部に「2025年 社外秘資料」と書いてあると、AIはそれを本文の一部として学習し、検索時に不要なヒットを引き起こしたり、文脈の分断を招いたりします。
データ構造化の有無が回答精度に与える決定的な差
社内規定集の検索精度が上がらないという課題は珍しくありません。実際のデータを確認すると、元のPDFには「注釈」が本文の横に小さく書かれていた、というケースがよく見受けられます。
構造化処理が不十分なツールでは、この注釈が本文の途中に割り込んでテキスト化されてしまいます。その結果、「交通費は実費支給とする（ただし上限あり）」という文章が、「交通費は実費（ただし上限あり）支給とする」のように混ざったり、別の条文と混同されたりする可能性があります。
データ構造化とは、こうした「見た目の情報」を「意味のあるマークアップ（タグ付け）」に変換し、AIが正しく消化できる状態にする作業です。
- 見出しは「見出し」として論理構造を明示する。
- 表は行と列の関係を維持した形式（MarkdownやHTMLなど）に変換する。
- ヘッダー/フッターなどのノイズ情報を除去する。
- 画像や図表は、単なるOCR処理だけでなく、その意味内容を記述したコンテキスト情報として埋め込む（マルチモーダル対応を見据えた処理）。
この前処理（プリプロセス）の品質こそが、RAGシステムの知能指数の上限を決定づけます。実際、Ragasなどの最新の評価フレームワークを用いた検証においても、ChatGPTの最新モデルのような高性能なLLMを使用しているにもかかわらず精度が出ないケースの大半は、このデータ処理品質に起因することが示唆されています。
どれほどモデルが進化し、コンテキストウィンドウが拡大したとしても、「Garbage In, Garbage Out（ゴミを入れればゴミが出てくる）」という原則は変わりません。むしろ、モデルが高性能になるほど、入力データの構造的な欠陥に敏感になる傾向さえあります。
参考リンク
プラットフォームの「データ処理能力」を測る3つの重要指標
では、ツール選定時に具体的に何をチェックすればよいのでしょうか？ カタログには「高精度OCR搭載」としか書かれていないことが多いですが、技術の本質を見抜く上で確認すべきポイントは以下の3点です。
1. レイアウト解析精度：表組み・段組みを正しく認識できるか
単に文字を認識する（OCR）だけでなく、ドキュメントの論理構造（Logical Structure）を解析できているかを見ます。
特に重要なのが「複雑な表」の処理能力です。セル結合が含まれる表や、枠線がない表を正しくMarkdown形式やJSON形式に変換できるでしょうか？
評価を行う際は、「Table Structure Recognition（表構造認識）」のスコアを重視します。これは、表のセル構造をどれだけ正確に再現できたかを測る指標です。これが低いと、製品スペック表や価格表に関する質問に対して、AIは高い確率で誤答（ハルシネーション）を起こします。
2. 論理チャンク分割率：意味の塊でデータを切れているか
RAGでは、長いドキュメントを「チャンク」と呼ばれる小さな塊に分割してデータベースに保存します。検索時には、質問に関連するチャンクを見つけ出し、LLMに渡します。
多くのツールは「500文字ごとに分割」といった機械的な分割（Fixed-size Chunking）を行っています。しかし、これでは文章の途中で切れてしまい、文脈が失われます。
「セマンティック・チャンキング（意味的分割）」ができているかが評価の分かれ目です。これは、章や節、段落といった意味のまとまりを自動的に検出し、そこで区切る技術です。
- NG: 「...契約の有効期間は1年とす」「る。ただし更新は...」
- Good: 「契約の有効期間は1年とする。」（ここで区切る）
この「区切り方」のセンスが、検索精度（Retrieval Accuracy）に直結します。
3. メタデータ付与の粒度：文脈情報をどれだけ自動補完できるか
チャンクに分割されたテキストは、元のドキュメントから切り離されるため、「これか何の文書の一部か」という情報（コンテキスト）を失いがちです。
優秀なプラットフォームは、分割された各チャンクに対して、自動的にメタデータを付与します。
- ファイル名
- ページ番号
- 親見出し（どの章に含まれていたか）
- 作成日時
- 著者
例えば、「第3条」というテキストだけでは何のことかわかりませんが、「就業規則 > 第2章 採用 > 第3条」というメタデータが付与されていれば、AIは「これは採用に関する第3条だな」と理解できます。
この「メタデータ付与の自動化レベル」を確認してください。手動でタグ付けしなければならないツールは、運用コストが肥大化する可能性があります。
【検証事例】構造化能力の違いがもたらす回答精度の格差
論より証拠。プロトタイプを用いた検証事例をご紹介しましょう。製造業の現場を想定し、同じ「製品マニュアル（PDF）」を、データ処理能力の異なる2つのプラットフォームに読み込ませて比較したケースです。
テスト対象ドキュメント
- 内容: 産業用ロボットの操作マニュアル（全150ページ）
- 特徴: 2段組みレイアウト、警告アイコン付きの注記、詳細なスペック表（セル結合あり）
ケースA：単純なテキスト抽出（安価なSaaS）
このツールはPDFからテキストをベタ打ちで抽出するタイプでした。
- 質問: 「緊急停止ボタンを押した後の復旧手順は？」
- 回答: 「ボタンを右に回して解除します。電源ランプが点灯することを確認してください。注：感電の恐れがありますので濡れた手で触らないでください。」
- 問題点: 一見合っているように見えますが、実は「注：感電の...」は、別のページにあった警告文が混入していました。また、復旧手順のステップ1とステップ2が繋がってしまい、手順の順序が不明瞭でした。
ケースB：高度な構造化処理（エンタープライズ向けAI基盤）
こちらはレイアウト解析を行い、Markdown形式に変換してから学習するタイプです。
質問: 「緊急停止ボタンを押した後の復旧手順は？」
回答:
- 緊急停止ボタンを右方向（時計回り）に回してロックを解除します。
- 操作盤の「RESET」ボタンを3秒以上長押しします。
- 電源ランプが緑色に点灯することを確認します。
※注意：作業前に必ず主電源がOFFになっていることを確認してください（p.42 警告事項より）。
評価: マニュアル内の「手順リスト」を正しくリスト形式として認識し、回答もステップバイステップで生成されました。また、警告文も適切なコンテキストで引用されています。
複雑な社内規定集での回答テスト結果比較
100問のQAテストを実施した結果、以下のような差が出ました。
| 指標 | ケースA（単純抽出） | ケースB（構造化処理） | 差 |
|---|---|---|---|
| 回答正答率 | 62% | 91% | +29pt |
| ハルシネーション発生率 | 18% | 3% | -15pt |
| 参照元の提示精度 | 45% | 98% | +53pt |
特に「参照元の提示精度」の差は劇的でした。構造化されているデータは、AIが「どこを見て答えたか」を正確に特定できるため、ユーザーも安心して回答を利用できます。逆に、構造化されていないデータでは、AI自身もどこを読んでいるのか曖昧なため、参照リンクがズレたり、全く関係ないページを示したりすることが多発しました。
自社に最適なプラットフォームを見極める「悪意あるテスト」のススメ
ベンダーのデモでは、彼らが用意した「綺麗に整備されたデータ」が使われます。これでは実力はわかりません。自社導入を検討する際は、仮説を即座に形にして検証するプロトタイプ思考を持ち、あえてAIが苦手とするデータを使った「悪意あるテスト（ストレステスト）」を行うことをお勧めします。
1. 複雑な表を含むドキュメントを読ませてみる
Excelで以下のような意地悪な表を作り、PDF化して読ませてみてください。
- セルの結合（縦・横）を多用する。
- ヘッダー行を2行にする（大項目・小項目）。
- 表の中に空白セルを含める。
その上で、「〇〇カテゴリの××項目の値は？」と聞いてみます。構造化能力が低いツールは、結合されたセルの値を正しく読み取れず、隣のセルの値を答えたりします。
2. 画像内の文字やキャプションの認識テスト
PowerPoint資料によくある「図解の中に文字が入っているスライド」を読ませます。
- 図の中にある「矢印の流れ（プロセス）」を理解できるか？
- グラフの画像から「右肩上がりである」という傾向を読み取れるか？
- スクリーンショット画像内のメニュー名を検索できるか？
ChatGPTやClaudeの最新モデルでは、視覚理解（Vision）機能が大幅に強化されており、単なる文字認識（OCR）を超えて、図表の意味や文脈まで理解できるようになっています。こうした高度なマルチモーダル対応LLMを適切に統合しているプラットフォームであれば、画像内の情報も高精度に検索対象にできます。逆に、ここがブラックボックスになっている、あるいは旧世代のモデルに依存しているツールは、非構造化データの活用において大きなボトルネックとなります。
3. ベンダーに聞くべき「前処理エンジン」に関する質問リスト
営業担当者に対して、以下の質問を投げかけてみてください。技術的な深さを測るリトマス試験紙になります。
- 「PDFのパース（解析）にはどのエンジンを使っていますか？ 自社開発ですか、それともUnstructuredやAzure AI Document Intelligenceなどの外部ライブラリですか？」
- 「チャンク分割の戦略（Chunking Strategy）は固定長のみですか？ それともセマンティック分割に対応していますか？」
- 「表データ（Table）はどのようにテキスト化されますか？ Markdownですか、HTMLですか、それともただの文字列ですか？」
- 「OCRを行った際、信頼度スコア（Confidence Score）が低い文字はどう処理されますか？」
「えっと、確認します...」と答えに詰まるようであれば、そのベンダーはデータ処理の重要性を理解していない可能性があります。
結論：LLMのIQよりも「データの消化力」に投資せよ
AIモデル（LLM）の進化は凄まじく、数ヶ月ごとに新しい「天才」が登場します。しかし、断言できるのは、モデル自体は取り替え可能なパーツに過ぎないということです。
今日、ChatGPTの最新モデルを使っていても、明日にはClaudeやGeminiの次世代版、あるいは特定のドメインに特化したモデルの方が適していると判断し、切り替えることになるかもしれません。実際、かつて業界標準と言われたモデルも、今ではより高性能な新モデルの登場によりレガシー化し、サポート終了や機能縮小の対象となるケースも珍しくありません。特定のバージョンに過度に依存したシステム構築は、そのモデルが旧式化した瞬間に陳腐化するリスクを抱えています。
一方で、「構造化された社内データ」は、貴社の永続的な資産になります。
一度綺麗に構造化されたデータ基盤（ナレッジベース）を構築しておけば、上に乗せるLLMがChatGPTからClaude、あるいは将来登場する未知のモデルに変わっても、その価値は失われません。むしろ、モデルが賢くなればなるほど、あるいは特定のタスクに特化したモデルが登場するほど、整備されたデータの価値は高まります。
構造化データ率をKPIに設定する
これからのDX担当者は、導入するツールの数ではなく、「社内データの何％がAI可読な状態（構造化済み）になったか」をKPIにすべきです。
ツール選定においては、以下の優先順位を忘れないでください。
- データ取り込み・構造化能力（Ingestion & Parsing） ← 最重要！
- 検索・リトリーバル精度（Retrieval）
- 生成AIモデルの性能（Generation）
- UI/UX
「消化力」の高いプラットフォームを選ぶことは、将来のAI活用を見据えた最もROI（投資対効果）の高い投資です。モデルはサブスクリプションで借りるものですが、データ基盤は自社で所有するものだからです。
もし、現在検討中のツールが本当に自社の複雑なデータを処理できるか不安であれば、あるいは、すでに導入したツールで精度が出ずに困っているならば、データ基盤の質を再評価することをお勧めします。
データ構造化は、RAGの回答精度を劇的に改善する可能性があります。貴社のデータが、最新のAIにとって「最高のご馳走」になるよう、足元を固めることから始めましょう。
コメント